Summary
A security issue in ingress-nginx allows a user with permission to create or update Ingress objects to use the spec.rules[].http.paths[].path field of an Ingress object in the networking.k8s.io or extensions API group to obtain the credentials of the ingress-nginx controller. By crafting the path value to reference the controller's service account token file, the attacker retrieves the token. In the default configuration, that credential has access to all secrets in the cluster.
Impact
Any user who can create or update Ingress objects in a cluster running ingress-nginx prior to v1.2.0 can exploit this vulnerability to read the ingress-nginx service account token directly. Because the default service account has cluster-wide access to secrets, the effective impact is full read access to all Kubernetes secrets in the cluster. Multitenant environments where non-admin users hold Ingress create or update permissions are most at risk.
Detection
Audit which users and service accounts hold the create or update verbs on networking.k8s.io/ingresses or extensions/ingresses, and inspect Ingress objects for path values that reference filesystem paths. If you find evidence that this vulnerability has been exploited, contact security@kubernetes.io.
Mitigation
Upgrade ingress-nginx to v1.2.0 (or the release candidate v1.2.0-beta.0) or later, which adds sanitization of the path field to block references to sensitive files.
If an immediate upgrade is not possible, implement an admission policy that restricts the spec.rules[].http.paths[].path field on networking.k8s.io/Ingress resources to a known safe character set. The ingress-nginx project documents a suggested annotation-value-word-blocklist ConfigMap setting that provides a reference blocklist pattern for this purpose.