-
Notifications
You must be signed in to change notification settings - Fork 113
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
Add the ability to specify a security context to the deployment #289
Conversation
…od and containers
Is there any reason this is not accepted? Just asking so that I can make any necessary corrections. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay reviewing, I think this looks like a good addition, thank you! Would you be able to add some tests in https://github.com/hashicorp/vault-secrets-operator/blob/main/test/unit/deployment.bats please? With that and the other comment in this review addressed, I think this will look in a good place to get merged.
I'm really not sure about the unit tests… |
This addresses issue #311 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for adding the tests! They look good to me, just 2 quick fixes needed and then I think this is ready to land
Co-authored-by: Tom Proctor <[email protected]>
Thanks for the suggestions <3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the updates! I took another pass and found a few more minor fixes to make, alongside one more trivial test fix.
volumeMounts: | ||
- mountPath: /var/run/podinfo | ||
name: podinfo | ||
securityContext: | ||
runAsNonRoot: true | ||
{{- toYaml .Values.controller.podSecurityContext | nindent 8 }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this PR was opened, we've added a pre-delete hook that runs the same image as the manager container further down in this file. I think we should probably apply the .Values.controller.podSecurityContext
and .Values.controller.manager.securityContext
settings to the pod and container respectively in that job. WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I pushed a commit that includes some test updates to better illustrate this suggestion: f6a5aa8. If your environment has a requirement for setting securityContext
on all pods, I think it will be required.
Hi @drustan - |
Co-authored-by: Tom Proctor <[email protected]>
Co-authored-by: Tom Proctor <[email protected]>
Co-authored-by: Tom Proctor <[email protected]>
…inct container security contexts for kubeRbacProxy and manager containers. Let's set only one for both.
Hello @kschoche! I guess you guys are right. I committed the changes, let me know if this is what you guys expected further to your chat. I'm still not very comfortable with the unit tests, but I'm not sure they need any amend following these changes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I think the updated values.yaml looks good other than some tidy-up 👍
chart/values.yaml
Outdated
# Configures the Container Security Context | ||
# https://kubernetes.io/docs/tasks/configure-pod-container/security-context | ||
securityContext: | ||
allowPrivilegeEscalation: false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this one can be deleted now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I overlooked that one sorry.
volumeMounts: | ||
- mountPath: /var/run/podinfo | ||
name: podinfo | ||
securityContext: | ||
runAsNonRoot: true | ||
{{- toYaml .Values.controller.podSecurityContext | nindent 8 }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I pushed a commit that includes some test updates to better illustrate this suggestion: f6a5aa8. If your environment has a requirement for setting securityContext
on all pods, I think it will be required.
…tainer specific configuration values (.cf #58b3a087)
Co-authored-by: Tom Proctor <[email protected]>
I don't see your commit f6a5aa8 in the PR. It's not as obvious as accepting suggestions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry about that, I couldn't add suggestions for the changes needed in the pre-delete hook because the PR doesn't touch that area of the code at all yet, so I thought the commit would be easier. I rolled the test changes up into GH suggestion comments, so that just leaves the deployment.yaml changes, which is applying exactly the same changes as you've already got to the pod spec at the bottom of the file.
i.e. after line 153, insert:
securityContext:
{{- toYaml .Values.controller.podSecurityContext | nindent 8 }}
And after line (currently) 165:
securityContext:
{{- toYaml .Values.controller.securityContext | nindent 10 }}
LMK if any of that doesn't quite make sense.
…lues Co-authored-by: Tom Proctor <[email protected]>
…lues Co-authored-by: Tom Proctor <[email protected]>
…xt test with default values Co-authored-by: Tom Proctor <[email protected]>
…xt test with example values Co-authored-by: Tom Proctor <[email protected]>
…to the pre-delete job
Thanks @tomhjp for the clarifications. Hope these last commits will wrap this up :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thanks for your patience through the multiple rounds of feedback. I'll leave merging to @kschoche so he gets a chance to review too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work on this, thank you for submitting and helping us all converge on a design!
This aims to allow the secret operator deployment in a restricted policy applied namespace. It adds the securityContext and podSecurityContext to avoid the following error :
58s Warning FailedCreate replicaset/vault-secrets-operator-controller-manager-ccbf4f6db Error creating: pods "vault-secrets-operator-controller-manager-ccbf4f6db-kmd5p" is forbidden: violates PodSecurity "restricted:latest": unrestricted capabilities (containers "kube-rbac-proxy", "manager" must set securityContext.capabilities.drop=["ALL"]), seccompProfile (pod or containers "kube-rbac-proxy", "manager" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")