Sdp Features
You set up core sdp features by checking user identity and device trust first. Then you open a one-to-one network path to the exact resource they need. Most teams start by linking their identity store to a central controller. They assign network rules to broad job groups like developers or support staff. When those group rules are too wide, one bad laptop exposes whole server subnets. An attacker who steals one login can still reach many back-end databases and apps. How core sdp features work
Linkerd Security Features: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up core sdp features by checking user identity and device trust first. Then you open a one-to-one network path to the exact resource they need. Most teams start by linking their identity store to a central controller. They assign network rules to broad job groups like developers or support staff. When those group rules are too wide, one bad laptop exposes whole server subnets. An attacker who steals one login can still reach many back-end databases and apps.
How core sdp features work in practice
A Software-Defined Perimeter hides your internal servers from public network scans. By default, every port drops traffic from unknown sources right away. Before a user sends any data, a local agent checks their identity and device. It looks at the user login, the operating system, and local security software.
Next, the central controller checks these details against your team rules. If the user passes the check, the controller signals the target network node. That node opens an encrypted tunnel for that single user and that single service. Other apps on the same subnet stay hidden and unreachable during the session.
This workflow replaces old virtual private networks that joined whole networks together. Instead of trusting an IP address, the system trusts the verified user and device. When the user logs out, the controller closes the network path right away. If the device fails a security check mid-session, the tunnel drops as well.
What network rules solve and what they miss
Setting up a perimeter around each user stops outside port scans cold. It also stops attackers from moving sideways across your network subnets. You gain a clear log of who opened a tunnel and when it closed. Network teams no longer need to manage huge firewall lists for remote workers.
Still, network rules only decide who can open a socket to a server. Once the tunnel is open, the perimeter is blind to what happens inside. It cannot read the database queries or shell commands moving through the pipe. A developer with valid tunnel rights can still run a bad delete command.
Linkerd Security Features: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Network checks also do not solve the problem of shared database logins. Teams still pass around static database passwords or long-lived keys to run queries. Also, a network tunnel cannot mask sensitive data like emails or card numbers. If a user runs a broad select query, raw phone numbers and national IDs return. Masking must rewrite matched fields in results at the command level, not the packet level. To control individual statements and protect live data, you need controls above the network.
How to plan your rollout
Start by listing your high-risk databases, internal apps, and cloud servers. Group these targets by the exact tasks your engineers perform each day. Avoid copying old VPN group rules into your new perimeter controller. Old groups almost always grant far more reach than a user needs today.
Test your device checks with a small pilot team before a full launch. Make sure the agent works well across all laptops your staff members use. Watch your connection logs for blocked traffic to spot missing app rules early. Once network paths are tight, look at how users log in to target databases. Pair your network tunnels with command-level checks to close the last security gap.
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 do sdp features differ from a standard VPN?
A standard VPN connects a user to a whole network subnet at once. SDP checks identity and device posture first, then opens a path to one app. Other servers on that same network remain hidden and blocked from the user.
Do network perimeters inspect database queries or shell commands?
No, a network perimeter only manages the encrypted tunnel between the user and server. It decides who can reach the port, not what commands they run inside. You need command-level controls to inspect queries or rewrite sensitive fields in results.
What happens if a user device falls out of compliance during work?
The local agent sends constant health updates back to the central controller. If a user turns off their local firewall, the controller spots the change fast. It then cuts the active network tunnel until the user fixes the device issue.