Requested Pod
To reach a requested pod in Kubernetes, you grant role permissions for the pod resource. Then, the cluster API lets you open a shell or forward a port. Most teams set up cluster roles that match groups in their identity tool. When teams share broad admin roles, anyone can run risky commands on live apps. This wide permission model creates big security gaps during daily work. How Kubernetes routes traffic to a requested pod A user starts by sending a command to the Kubernetes API server. The A
K8s Pod Security Standards: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To reach a requested pod in Kubernetes, you grant role permissions for the pod resource. Then, the cluster API lets you open a shell or forward a port. Most teams set up cluster roles that match groups in their identity tool. When teams share broad admin roles, anyone can run risky commands on live apps. This wide permission model creates big security gaps during daily work.
How Kubernetes routes traffic to a requested pod
A user starts by sending a command to the Kubernetes API server. The API server checks who the user is with a token or certificate. Next, the role system checks if that user can reach the requested pod. Every action needs permission on the main pod resource and its subresources. For example, opening a shell uses the exec subresource on the target container. Forwarding a local port uses the portforward subresource in the same namespace. If the role allows the call, the API server talks to the node agent. The node agent runs on the host machine and manages the local containers. It opens a stream between the user and the container process. All terminal input and output now flow through this live network stream. Teams often scope these role rules to a single namespace to limit reach. Some admins also lock roles down to specific pod names. Still, pod names change every time a deployment rolls out a new build. Because names change, teams fall back to granting access to all pods in a namespace.
What native pod roles solve and what they miss
Native Kubernetes roles are great at deciding who can start a session. They block unknown users at the cluster edge before a stream opens. They also help teams split dev namespaces from live production namespaces. You can give an engineer read rights without giving them shell rights. This basic split stops many simple mistakes across the cluster.
Still, native role checks stop working the moment the shell stream opens. Once inside a requested pod, the user acts as the container OS user. Many containers still run as the root user by default. Kubernetes does not check or log the shell commands typed inside that stream. The cluster audit log only shows that a user opened an exec session. It does not record which files they read or which scripts they ran. If an app container holds database keys in memory, the user can read them. If the pod has a mounted secret volume, those files sit in plain text. Native roles also cannot mask sensitive data like emails or card numbers in terminal output. When a database client runs inside the pod, raw query results print to the screen. Phone numbers and national IDs flow straight to the local laptop. Native roles decide who gets in, not what commands or data move in flight.
Why shared namespace roles create risk over time
Engineers need quick ways to fix broken apps during an outage. Waiting for a custom role change slows down the whole response team. To save time, platform teams leave exec rights turned on all day. These standing rights stay active long after the ticket closes. If an attacker steals a developer laptop token, they gain those same standing rights. They can jump into any pod in that namespace right away. From there, they can read app memory, pull service tokens, and move around. Reviewing these actions later is hard when audit logs miss the inner commands. Teams need a way to inspect commands and hide private fields on the fly.
K8s Pod Security Standards: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Why can I list pods but not open a shell in a requested pod?
Listing pods only requires read permission on the base pod resource. Opening a shell requires extra write permission on the pods exec subresource in your role.
Does the Kubernetes audit log record commands run inside a pod shell?
No, standard cluster audit logs only record that the exec session started. They do not capture the actual shell commands or terminal output inside the container.
How can teams stop static secrets from leaking during pod debugging?
Teams should avoid storing raw keys in container variables and limit full shell access. Inspecting commands and rewriting sensitive fields like emails or card numbers in output reduces leaks.