Notifications
Clear all
Topic starter
19/08/2026 3:36 pm
TL;DR: Kubernetes IP addresses are too fragile to prove workload identity, so ngrok adds pod metadata to Traffic Policy on Kubernetes-bound endpoints in v0.22.1, enabling namespace-scoped deny rules and fail-closed handling when identity cannot be resolved. The real shift is from network-location trust to Kubernetes-attested workload identity, which changes how teams govern internal access.
NHIMG editorial — based on content published by ngrok: pod identity variables for Kubernetes Traffic Policy
By the numbers:
- 69% of organisations now have more machine identities than human ones.
- Only 5.7% of organisations have full visibility into their service accounts.
- 57% of organisations lack a complete inventory of their machine identities.
Questions worth separating out
Q: Why do workload identities matter in Kubernetes security decisions?
A: Because a pod compromise often becomes a credential problem within minutes.
Q: Why do IP-based controls fail for Kubernetes workload access?
A: IP-based controls fail because pods are ephemeral, addresses are reused, and a transport address does not identify the workload behind the connection.
Q: What should teams do when pod identity cannot be resolved?
A: Default to fail-closed for sensitive services and deny the connection until the caller can be identified.
Practitioner guidance
- Define namespace-scoped allow rules Use pod namespace as the first policy boundary for Kubernetes-bound endpoints, and deny any connection whose namespace does not match the service's trust boundary.
- Fail closed when identity cannot be resolved Treat conn.k8s.pod.metadata.error_code as a deny condition for sensitive services so transient registration gaps or CNI issues do not create silent bypasses.
- Restrict policies to Kubernetes-bound endpoints Apply pod identity enforcement only where kubernetes binding exists, and document that public or internal endpoints do not receive these variables.
What's in the full article
ngrok's full post covers the operational detail this post intentionally leaves for the source:
- The exact Traffic Policy expressions for namespace allowlisting and deny conditions.
- The full list of pod identity variables available under conn.k8s.pod.* and how each one behaves.
- Guidance for handling resolution failures, hostNetwork edge cases, and rollout choices between fail-open and fail-closed.
- Examples of allowlisting specific pods by name and using annotations in multi-tenant cluster designs.
👉 Read ngrok's pod identity guide for Kubernetes Traffic Policy details →
Kubernetes pod identity variables: are your service controls keeping up?
Explore further
19/08/2026 4:17 pm
Pod identity is becoming the minimum viable control for Kubernetes workload trust. IP-based trust collapses as soon as workloads are ephemeral and namespace boundaries matter. Once policy can evaluate the pod that initiated the connection, the identity plane can finally distinguish between workloads that share infrastructure but should not share access. Practitioners should treat pod identity as a baseline control for service-to-service governance.
A few things that frame the scale:
- 69% of organisations now have more machine identities than human ones, according to The Critical Gaps in Machine Identity Management report.
- 57% of organisations lack a complete inventory of their machine identities, which makes policy enforcement and ownership assignment incomplete.
A question worth separating out:
Q: How do namespace-scoped policies change Kubernetes access governance?
A: They turn namespace into an enforceable boundary rather than a naming convention. That helps teams align platform segmentation with identity policy, but only if the namespace value is controlled, reviewed, and used consistently across services and environments.
👉 Read our full editorial: Kubernetes pod identity variables tighten service-to-service access
