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

Add the ability to specify a security context to the deployment #289

Merged
merged 21 commits into from
Sep 20, 2023

Conversation

drustan
Copy link
Contributor

@drustan drustan commented Jul 21, 2023

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")

@drustan drustan requested a review from a team July 21, 2023 13:28
@hashicorp-cla
Copy link

hashicorp-cla commented Jul 21, 2023

CLA assistant check
All committers have signed the CLA.

@drustan drustan requested a review from a team as a code owner August 22, 2023 15:47
@drustan
Copy link
Contributor Author

drustan commented Aug 23, 2023

Is there any reason this is not accepted? Just asking so that I can make any necessary corrections.

Copy link
Contributor

@tomhjp tomhjp left a 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.

@drustan
Copy link
Contributor Author

drustan commented Aug 23, 2023

I'm really not sure about the unit tests…

@drustan drustan requested a review from tomhjp August 28, 2023 12:26
@drustan
Copy link
Contributor Author

drustan commented Sep 7, 2023

This addresses issue #311

Copy link
Contributor

@tomhjp tomhjp left a 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

@drustan
Copy link
Contributor Author

drustan commented Sep 14, 2023

Thanks for the suggestions <3

Copy link
Contributor

@tomhjp tomhjp left a 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 }}
Copy link
Contributor

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?

Copy link
Contributor

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.

@tomhjp tomhjp linked an issue Sep 19, 2023 that may be closed by this pull request
@kschoche
Copy link
Contributor

Hi @drustan -
Thanks for posting this PR!
I had a chat with @tomhjp today about this and I think that we are close but maybe we can clean up the UX a little.
Is there a reason to keep the securityContext settings separate in the containers? I can't envision needing the kubeRbacProxy to be more permissive than the controller (manager) and afaik they don't have any different requirements to be able to run?
Does it make the most sense to just create:
.Values.controller.securityContext and apply it to both manager and kubeRbacProxy ?

drustan and others added 4 commits September 20, 2023 09:08
…inct container security contexts for kubeRbacProxy and manager containers. Let's set only one for both.
@drustan
Copy link
Contributor Author

drustan commented Sep 20, 2023

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.

Copy link
Contributor

@tomhjp tomhjp left a 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 👍

Comment on lines 52 to 55
# Configures the Container Security Context
# https://kubernetes.io/docs/tasks/configure-pod-container/security-context
securityContext:
allowPrivilegeEscalation: false
Copy link
Contributor

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.

Copy link
Contributor Author

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 }}
Copy link
Contributor

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)
@drustan
Copy link
Contributor Author

drustan commented Sep 20, 2023

I don't see your commit f6a5aa8 in the PR. It's not as obvious as accepting suggestions

Copy link
Contributor

@tomhjp tomhjp left a 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.

@drustan
Copy link
Contributor Author

drustan commented Sep 20, 2023

Thanks @tomhjp for the clarifications. Hope these last commits will wrap this up :)

Copy link
Contributor

@tomhjp tomhjp left a 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.

Copy link
Contributor

@kschoche kschoche left a 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!

@tomhjp tomhjp merged commit a5eda32 into hashicorp:main Sep 20, 2023
@benashz benashz added this to the v0.3.0 milestone Sep 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[helm] Allow override pod securityContext with Helm values
5 participants