Clearnet Isolation
You set up clearnet isolation by removing public IP addresses from your private systems. You then route all traffic through private networks and strict firewall rules. Most teams build this setup with virtual private clouds and private subnets. They also use VPNs or peering links so staff can log in. Still, broad network roles often give users full reach across the whole private zone. Once someone is inside the network, they can still run bad commands on databases. How clearnet isolation works
K8s Namespace Isolation: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up clearnet isolation by removing public IP addresses from your private systems. You then route all traffic through private networks and strict firewall rules. Most teams build this setup with virtual private clouds and private subnets. They also use VPNs or peering links so staff can log in. Still, broad network roles often give users full reach across the whole private zone. Once someone is inside the network, they can still run bad commands on databases.
How clearnet isolation works in practice
A standard clearnet isolation setup starts at the network edge. You place your databases and internal apps inside private subnets. These subnets have no route to the public web. Internet traffic cannot reach your servers directly, and your servers cannot talk out.
Next, the team sets up a private entry path for engineers and services. Teams often use a site-to-site VPN or a private network link. Network admins write route tables that allow traffic only between known internal IP ranges. Security groups and firewall rules check the source IP and port of every packet.
If the packet comes from the right subnet, the firewall lets it pass. After the network check passes, the user or app reaches the database port. The user then logs in with a database role, a password, or a key. Cloud IAM roles can also control which services can talk over these private links.
What network rules solve and what they miss
This network setup solves a huge problem by hiding your systems from public scanners. Bots on the public web cannot try passwords against your database ports. Unapproved networks cannot send packets to your private apps. It shrinks the outside attack surface down to your private entry points.
Still, network boundaries leave a major gap during daily work. A firewall only decides which IP address can open a port. A database role only decides who can log in at the start. Neither tool checks what each SQL query or CLI command does in flight.
An engineer on the VPN often uses a shared admin role to fix bugs. That role lets them run any read or write query without a peer check. If they run a broad select query, the database returns raw emails and card numbers. Data masking rules are rarely set up on those shared roles to rewrite fields.
K8s Namespace Isolation: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Worse, a careless script on a private host can drop a table in seconds. Network logs only show bytes and IP addresses, not the exact commands that ran. Security teams cannot see which user ran which statement across the private link.
Why teams need controls beyond the network
Relying only on network walls creates friction when teams grow. Network admins must update IP lists every time a new app or user joins. To save time, teams often open wide subnet ranges inside the private network.
This means any compromised host inside the private zone can reach every database. When auditors ask who read customer phone numbers or national IDs, network logs fail. You need controls that inspect and log each action after the user logs in.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Does clearnet isolation stop insiders from reading sensitive data?
No, it only blocks traffic from the public internet. Once an approved user logs into the private network, they can still query tables. Without field masking, queries return raw emails, phone numbers, and card numbers in results.
How is clearnet isolation different from an air gap?
An air gap means a system has zero network links to outside systems. Clearnet isolation removes public internet routes, but still allows private links like VPNs. Engineers can still log in remotely over those private paths to do work.
Why are firewall logs not enough for database audits?
Firewall logs only record source IPs, target ports, and packet counts. They do not show the user identity or the SQL statements or CLI commands executed. Auditors need to see exact commands to verify who touched private data.