Kubernetes Ingress Privilege Escalation
Kubernetes Ingress privilege escalation is not theory. It’s a chain of missteps that can turn a border router into a root shell. Ingress is meant to route external traffic into cluster services. When misconfigured, it can route power into hands that should not hold it.
The common path starts with overly broad permissions. An Ingress controller with cluster-admin rights is a loaded weapon. Add a weak RBAC policy and the controller can modify Service definitions, ConfigMaps, or Secrets. From there, attackers pivot deeper — replacing routes, injecting malicious pods, or exfiltrating data without triggering alerts.
TLS mismanagement adds another door. If certificates are stored in plain text within the Ingress namespace and that namespace is accessible, the traffic you think is secure becomes a key to the kingdom. Combined with insecure annotations that execute custom Lua or NGINX snippets, privilege boundaries collapse fast.
Multi-tenant clusters are especially exposed. A user with Ingress access in a shared environment can override paths and hostnames, intercepting traffic meant for other namespaces. Without strict ingressClass isolation and admission controls, your cluster is a patchwork of trust waiting to rip.
Mitigation is direct:
- Lock down RBAC so Ingress controllers only get specific, minimal permissions.
- Segregate namespaces and force ingressClass enforcement.
- Store TLS secrets in restricted, encrypted locations.
- Audit every custom annotation and plugin.
- Monitor Ingress changes with immutable logs.
Kubernetes gives you speed. Ingress privilege escalation takes it away — along with control. Prevent it before someone makes your cluster theirs.
See how to secure, test, and break-proof your Ingress in minutes at hoop.dev.