Identity Defined Networking

Identity defined networking grants network connections based on verified user or workload identity. You set it up by linking your network routing rules to your identity provider. Most engineering teams start by moving away from static IP allowlists and shared VPNs. Instead, they map SSO groups to specific cloud network zones and target servers. When teams grant broad group permissions, one developer can still reach sensitive production databases. Broad network access creates risk if an attacker steals a valid developer session.

How identity defined networking works in practice

Traditional networks trust any traffic that comes from an approved office IP address. This model fails when developers work from home and cloud workloads scale up. An identity-based network checks who the user is before opening a network path. First, a developer logs in through a central identity provider like Okta. The identity provider checks the user password and runs a multi-factor check. Next, the system checks the device health and assigns a cryptographic identity token. Network enforcement points read this token before they let any packet pass through. If the user role matches the rule, the network opens a direct path. Other ports and servers stay hidden from the user on that same network. Workloads also get their own identity tokens based on their cloud service accounts. A backend app can talk to a payment service only if rules allow it. If a rogue container starts up without the right identity, the network drops its traffic.

What native network identity solves and what it misses

Setting up network rules by identity stops lateral movement across your cloud subnets. Attackers who breach one web server cannot scan the rest of the network. You also stop managing long lists of static IP rules in cloud firewalls. When someone leaves the company, disabling their SSO account cuts off network reach. Still, network identity setups only decide who can open a port or log in. Once the network tunnel opens, the network layer stops checking the actual work. It does not inspect individual SQL statements, shell commands, or API requests in flight. Two developers in the same engineering group often share the same database role. The network sees a valid user token and lets the traffic flow through. It cannot tell a safe read query apart from a table drop command. It also cannot mask sensitive fields like emails, phone numbers, or card numbers. Network logs show that a connection happened, along with bytes sent and received. They do not record the exact query or command that changed production data.

Steps to plan your rollout

Start by listing every human group and machine service in your identity provider. Clean up old groups that give broad access to all cloud subnets at once. Map each active team to the exact services they need for daily work. Test your new network rules on staging systems before moving to production workloads. Check your connection logs to find services that still rely on static IPs. Once network paths are locked down, look at what happens inside active sessions. Combine network identity rules with controls that inspect commands and mask sensitive results.

Govern statements and responses across databases and APIs

Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.

First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.

Frequently asked questions

How does identity defined networking differ from a standard VPN?

A standard VPN places authenticated users onto a broad internal network subnet. Identity defined networking checks user roles first and opens paths only to approved resources.

Can machine workloads use network identity rules?

Yes, cloud workloads and containers use service identities or short-lived certificates to verify themselves. The network checks these workload identities before allowing service-to-service traffic to flow.

Does network identity control what queries a developer runs?

No, network identity only controls whether a user can reach a host port. It does not inspect database queries, block dangerous commands, or rewrite sensitive data fields.

Related guides

• User-to-machine Authentication
• Turn on Conditional Access
• Subversion Management