Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Limit RBAC access to Secrets #521

Open
g-psantos opened this issue Feb 10, 2023 · 0 comments
Open

Limit RBAC access to Secrets #521

g-psantos opened this issue Feb 10, 2023 · 0 comments
Assignees
Labels
backend help wanted Extra attention is needed

Comments

@g-psantos
Copy link

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

@wasaga wasaga self-assigned this Feb 13, 2023
@wasaga wasaga added the help wanted Extra attention is needed label Apr 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backend help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants