Allow access to sealed secret services/proxy to any authenticated user #208
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
atomatt
approved these changes
Jul 31, 2019
controller.jsonnet
Outdated
| ], | ||
| resourceNames: [ | ||
| 'http:sealed-secrets-controller:', // kubeseal uses net.JoinSchemeNamePort when crafting proxy subresource URLs | ||
| 'sealed-secrets-controller', // but often services are referred by name only, let's not make it unnecessary cryptic |
|
@atomatt as I mentioned in the PR description, even before this RBAC change leaking secrets was a terrible idea. That said, it doesn't hurt to add such a warning in the code |
This allows kubeseal to fetch the certificate public key (and perform other actions such as /verify and /rotate endpoints) even if the caller doesn't have otherwise the rights to access the kube-system namespace (or any other namespace where the sealed-secrets controller might have been deployed), as it often happens that users are not granted such broad permissions on production clusters. We historically suggested users to just distribute the certificate out of bound and use the `--cert` flag. However, with the advent of master key rotation, this is becoming increasingly more cumbersome, especially since it's critical that users end up using the right certificate (i.e. the certificate has to be authenticated). Master key rotation also requires users to periodically rotate the secrets, which requires access to the /rotate endpoint. This change includes a fine-grained RBAC rule that allows access to the sealed-secrets controller HTTP API to any authenticated user in the cluster. Users are still free to disable this feature by applying an override during deployment, but our default RBAC config should include it. The controller currently exposes the following endpoints: - `/healthz' - `/v1/verify` - `/v1/rotate` - `/v1/cert.pem` The controller already must not expose any secrets via the HTTP endpoint, since while RBAC would prevent end-users to access the service via the proxy, nothing prevents any unprivileged workload in the cluster unless admins have explicitly configured a strict network policy rule set. Closes #166
|
bors r+ |
bors bot
added a commit
that referenced
this pull request
Jul 31, 2019
208: Allow access to sealed secret services/proxy to any authenticated user r=mkmik a=mkmik This allows kubeseal to fetch the certificate public key (and perform other actions such as /verify and /rotate endpoints) even if the caller doesn't have otherwise the rights to access the kube-system namespace (or any other namespace where the sealed-secrets controller might have been deployed), as it often happens that users are not granted such broad permissions on production clusters. We historically suggested users to just distribute the certificate out of bound and use the `--cert` flag. However, with the advent of master key rotation, this is becoming increasingly more cumbersome, especially since it's critical that users end up using the right certificate (i.e. the certificate has to be authenticated). Master key rotation also requires users to periodically rotate the secrets, which requires access to the /rotate endpoint. This change includes a fine-grained RBAC rule that allows access to the sealed-secrets controller HTTP API to any authenticated user in the cluster. Users are still free to disable this feature by applying an override during deployment, but our default RBAC config should include it. The controller currently exposes the following endpoints: - `/healthz' - `/v1/verify` - `/v1/rotate` - `/v1/cert.pem` The controller already must not expose any secrets via the HTTP endpoint, since while RBAC would prevent end-users to access the service via the proxy, nothing prevents any unprivileged workload in the cluster unless admins have explicitly configured a strict network policy rule set. Closes #166 Rel #137 Co-authored-by: Marko Mikulicic <mkm@bitnami.com>
Build succeeded |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This allows kubeseal to fetch the certificate public key (and perform other actions such as /verify and /rotate endpoints) even if the caller doesn't have otherwise the rights to access the kube-system namespace (or any other namespace where the sealed-secrets controller might have been deployed), as it often happens that users are not granted such broad permissions on production clusters.
We historically suggested users to just distribute the certificate out of bound and use the
--certflag.However, with the advent of master key rotation, this is becoming increasingly more cumbersome, especially since
it's critical that users end up using the right certificate (i.e. the certificate has to be authenticated).
Master key rotation also requires users to periodically rotate the secrets, which requires access to the /rotate endpoint.
This change includes a fine-grained RBAC rule that allows access to the sealed-secrets controller HTTP API to any authenticated user in the cluster.
Users are still free to disable this feature by applying an override during deployment, but our default RBAC config should include it.
The controller currently exposes the following endpoints:
/v1/verify/v1/rotate/v1/cert.pemThe controller already must not expose any secrets via the HTTP endpoint, since while RBAC would prevent
end-users to access the service via the proxy, nothing prevents any unprivileged workload in the cluster unless
admins have explicitly configured a strict network policy rule set.
Closes #166
Rel #137