This repository was archived by the owner on Jul 26, 2022. It is now read-only.
Improve out-of-the-box compatibility with clusters running PodSecurityPolicy #361
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.
Background
We run our EKS clusters with locked-down
PodSecurityPolicy
by default; that is we drop all privileges and change the default EKS policy to one that is essentially unprivileged.kubernetes-external-secrets
does not appear to require any particular privileges that are from the set.This makes two changes to allow the chart/image to work out of the box without configuration on the user side.
changes the
Dockerfile
to indicate the user asuid
1000 rather thannode
, which is required to indicate K8S that it's not running as root (when running under Docker, at least) - consistent with the base node imagesMinimal workaround on
3.2.0
without the change in this PR is avalues.yaml
override ofchanges the defaults to include a
securityContext
that specifies the non root requirement.This second change is a little more debatable and I am interested in feedback however it seems a sensible idea to give an indication to chart users the actual requirements of
kubernetes-external-secrets
pods so they can craft custom policies if necessary; and understand any possible additional attack surface required for running a security-sensitive tool like this in their cluster (which I would argue is minimal given the pod requirements).A possible follow-up step would be to allow to specify the container
securityContext
rather than just the pod-level; which would allow us to specifyThis has been tested to work fine and automatically select a relatively unprivileged "secure-by-default" PSP like the below