You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
The Ingress Controller currently requires cluster-wide access to secrets. Given the exposure of Pomerium pods to untrusted actors, it's highly undesirable to grant Pomerium access to all cluster secrets. For example, arbitrary code execution in a compromised Pomerium pod could enable an attacker to obtain encryption keys and database credentials for all other workloads running on the cluster.
I couldn't find documentation of which secrets the controller needs access to, but I imagine it's a combination of Pomerium's own secret (encryption keys and possibly others) and downstream applications' TLS certificates.
Describe the solution you'd like
Pomerium's access to secrets should be limited to the specific secrets required by Pomerium to act as an identity-aware proxy for downstream applications. In this scenarion, Pomerium's service account would be associated with namespaced roles that grant read access to named secrets. This would effectively impose least-privilege on Pomerium with respect to secrets access.
As a fallback, in case Pomerium really needs list permissions, Pomerium's access to secrets should at least be limited to secrets stored in namespaces used by downstream applications. In this case, Pomerium's service account would be associated with namespaced roles that grant list and read access to all secrets in those namespaces. This at least would mean that only applications relying on Pomerium as their ingress controller are vulnerable.
Describe alternatives you've considered
I attempted to implement the "fallback solution" described above for Pomerium's own secrets, but that results in the following errors:
W0210 17:09:51.083224 1 reflector.go:424] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:169: failed to list *v1.Secret: secrets is forbidden: User "system:serviceaccount:pomerium:pomerium-controller" cannot list resource "secrets" in API group "" at the cluster scope
E0210 17:09:51.083319 1 reflector.go:140] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:169: Failed to watch *v1.Secret: failed to list *v1.Secret: secrets is forbidden: User "system:serviceaccount:pomerium:pomerium-controller" cannot list resource "secrets" in API group "" at the cluster scope
Explain any additional use-cases N/A
Additional context N/A
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
The Ingress Controller currently requires cluster-wide access to secrets. Given the exposure of Pomerium pods to untrusted actors, it's highly undesirable to grant Pomerium access to all cluster secrets. For example, arbitrary code execution in a compromised Pomerium pod could enable an attacker to obtain encryption keys and database credentials for all other workloads running on the cluster.
I couldn't find documentation of which secrets the controller needs access to, but I imagine it's a combination of Pomerium's own secret (encryption keys and possibly others) and downstream applications' TLS certificates.
Describe the solution you'd like
Pomerium's access to secrets should be limited to the specific secrets required by Pomerium to act as an identity-aware proxy for downstream applications. In this scenarion, Pomerium's service account would be associated with namespaced roles that grant
read
access to named secrets. This would effectively impose least-privilege on Pomerium with respect to secrets access.As a fallback, in case Pomerium really needs
list
permissions, Pomerium's access to secrets should at least be limited to secrets stored in namespaces used by downstream applications. In this case, Pomerium's service account would be associated with namespaced roles that grantlist
andread
access to all secrets in those namespaces. This at least would mean that only applications relying on Pomerium as their ingress controller are vulnerable.Describe alternatives you've considered
I attempted to implement the "fallback solution" described above for Pomerium's own secrets, but that results in the following errors:
Explain any additional use-cases
N/A
Additional context
N/A
The text was updated successfully, but these errors were encountered: