In Kubernetes, Ingress is that gate. It routes traffic from the outside world into your services. But too many Ingress controllers run with broad permissions no one audits. That’s a mistake. Least privilege isn’t optional—especially here.
Kubernetes Ingress least privilege means giving your Ingress controller only the rights it needs. No cluster-wide write access. No sweeping role bindings. No ability to alter unrelated deployments or secrets. A compromised Ingress with excessive rights can pivot anywhere in the cluster. Attackers exploit over-permissioned roles as their entry point.
Start with RBAC. Define a dedicated ServiceAccount for your Ingress controller. Bind it to a Role with the smallest set of verbs and resources required for routing: read access to its namespace’s Services and Endpoints, config read for Secret references, and nothing else. Avoid ClusterRoles unless routing demands cross-namespace visibility—and even then, scope them narrowly.
Limit namespace scope. Run multiple Ingress controllers if needed, each isolated to its own namespace. Segment workloads so that a breach in one path doesn’t spill over. Audit roles with kubectl describe role and kubectl get rolebinding to ensure permissions match their purpose.