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

feat: setup securityContext on plugins #362

Merged

Conversation

nerzhul
Copy link
Contributor

@nerzhul nerzhul commented Jul 19, 2022

At Veepee we only permit pods to run as non root. Plugin works properly as non root, add variables to setup it as non root and permit to customize UID

Description

Ref #121

Checklist

  • I've read the guidelines for contributing to this repository.
  • I've added tests that prove my fix is effective or that my feature works.
  • I've updated the documentation with the relevant information (if needed).
  • I've added usage information (if the PR introduces new options)
  • I've included a "before" and "after" example to the description (if the PR is a user interface change).

@CLAassistant
Copy link

CLAassistant commented Jul 19, 2022

CLA assistant check
All committers have signed the CLA.

@nerzhul nerzhul force-pushed the feat/trivy_scan_securitycontext branch 2 times, most recently from c35ff36 to ca40568 Compare July 19, 2022 16:18
@nerzhul nerzhul marked this pull request as ready for review July 19, 2022 16:19
@nerzhul nerzhul force-pushed the feat/trivy_scan_securitycontext branch from ca40568 to 4d80194 Compare July 20, 2022 07:41
@nerzhul
Copy link
Contributor Author

nerzhul commented Jul 20, 2022

I just fixed tests, it's now mergeable, if you can review and release when you can, we'd glad to do more test on our 200 nodes cluster :)

@chen-keinan chen-keinan self-requested a review July 20, 2022 08:49
@@ -50,6 +50,7 @@ To change the target namespace from all namespaces to the `default` namespace ed
| `scanJob.tolerations`| N/A| JSON representation of the [tolerations] to be applied to the scanner pods so that they can run on nodes with matching taints. Example: `'[{"key":"key1", "operator":"Equal", "value":"value1", "effect":"NoSchedule"}]'`|
| `scanJob.annotations`| N/A| One-line comma-separated representation of the annotations which the user wants the scanner pods to be annotated with. Example: `foo=bar,env=stage` will annotate the scanner pods with the annotations `foo: bar` and `env: stage` |
| `scanJob.templateLabel`| N/A| One-line comma-separated representation of the template labels which the user wants the scanner pods to be labeled with. Example: `foo=bar,env=stage` will labeled the scanner pods with the labels `foo: bar` and `env: stage`|
| `scanJob.podSecurityContext`| N/A| One-line JSON representation of the template securityContext which the user wants the scanner pods to be secured with. Example: `{"RunAsUser": 1000, "RunAsGroup": 1000, "RunAsNonRoot": true}`|
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will only "One-line JSON representation" be supported by this? I think it would be nice to support YAML-format - if possible, as this will be a better UX IMO. But probably not possible?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you mean people must setup a multine YAML instead of a single line JSON in the string variable passed in the config ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this configured from a configmap? But I see that the similar property scanJob.templateLabel (also a typo; should be Labels) is using a simple string. I'll leave this decision up to the maintainers....

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's the configmap key exact, i use JSON because GetScanJobTolerations uses also a JSON to be consistent

pkg/vulnerabilityreport/builder_test.go Outdated Show resolved Hide resolved
pkg/trivyoperator/config.go Outdated Show resolved Hide resolved
pkg/trivyoperator/config.go Outdated Show resolved Hide resolved
@erikgb
Copy link
Contributor

erikgb commented Jul 20, 2022

@nerzhul Thanks for this PR! I have added a few comments. We run on Openshift, and it is really picky about securityContext. It has it's SCC that want to control all that.

@nerzhul nerzhul force-pushed the feat/trivy_scan_securitycontext branch from 4d80194 to a63979e Compare July 20, 2022 12:21
@nerzhul
Copy link
Contributor Author

nerzhul commented Jul 20, 2022

@erikgb i addressed your concerns, except the one on the format, let's wait for maintainers, but it kept consistency with tolerations, both are JSON unmarshaled.

For Openshift, you have specific things. On our side we use PSP and PodSecurities on all namespaces, then it's not possible to run root pods. With this patch pods runs perfectly as UID > 1000 users and creates reports, on a vanilla Kubernetes with just PSP/PS

@erikgb
Copy link
Contributor

erikgb commented Jul 20, 2022

For Openshift, you have specific things.

I am not against adding this new feature, but I don't think it should break the existing operator. :-)

@nerzhul nerzhul force-pushed the feat/trivy_scan_securitycontext branch from a63979e to 49fdc70 Compare July 20, 2022 12:33
@nerzhul
Copy link
Contributor Author

nerzhul commented Jul 20, 2022

no problem @erikgb , now it's more close to the original one, regarding the tests on other parts :)
Tests on our dev cluster shows it's fine.
I just amened the helm chart to make helm chart use YAML syntax and let it transform to JSON like tolerations

@nerzhul nerzhul force-pushed the feat/trivy_scan_securitycontext branch from 49fdc70 to 8f82e2a Compare July 20, 2022 12:36
@nerzhul
Copy link
Contributor Author

nerzhul commented Jul 20, 2022

@chen-keinan any opinion about this very attended PR (on our use case :) ?

pkg/trivyoperator/config.go Outdated Show resolved Hide resolved
At Veepee we only permit pods to run as non root. Plugin works properly as non root, add variables to setup it as non root and permit to customize UID
@nerzhul nerzhul force-pushed the feat/trivy_scan_securitycontext branch from 8f82e2a to 3b57fdf Compare July 20, 2022 13:13
@erikgb
Copy link
Contributor

erikgb commented Jul 20, 2022

This LGTM now, but I think the maintainers should take a decision regarding the config UX. At some point we should probably review the "plugin" architecture for this. We currently have just a single plugin in this project, and I am not sure if the plugin approach gives more benefits than harm. But that will be breaking tho.

@nerzhul
Copy link
Contributor Author

nerzhul commented Jul 20, 2022

Okay i hope we can merge this before you change the whole architecture :) who are maintainers ? in the changelog it seems you are 2 currently active people

@erikgb
Copy link
Contributor

erikgb commented Jul 20, 2022

Okay i hope we can merge this before you change the whole architecture :) who are maintainers ? in the changelog it seems you are 2 currently active people

@chen-keinan is the maintainer here. I have brought in some ideas from our custom in-house image scanner lately. 😉 Looking to replace it with trivy-operator.

@josedonizetti
Copy link
Collaborator

@nerzhul Thanks for the PR, didn't have time to look/test this yet, but I think your change here is addressing what was asked here? #121

@chen-keinan
Copy link
Collaborator

chen-keinan commented Jul 20, 2022

@nerzhul thanks you for contributing , I'm fine with keeping the podSecurityContext in json format to be consist with this type of data.
I'll approve it later after I'll test it and make sure it works fine.

@chen-keinan
Copy link
Collaborator

I assume it will solve the most cases where it is required in pod level however not if it is required for a specific init container

Copy link
Collaborator

@josedonizetti josedonizetti left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! But I do have a comment/question. Considering trivy will scan and report misconfiguration for pods not having a security context with runAsUser, runAsGroup and runAsNonRoot.

https://avd.aquasec.com/misconfig/kubernetes/general/avd-ksv-0012/
https://avd.aquasec.com/misconfig/kubernetes/general/avd-ksv-0020/
https://avd.aquasec.com/misconfig/kubernetes/general/avd-ksv-0021/

Why don't we have a default value for podTemplateSecurityContext considering the AVDs above?

Copy link
Collaborator

@josedonizetti josedonizetti left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll create an issue to discuss further if we should have default or not. :)

@josedonizetti josedonizetti merged commit 6916d7b into aquasecurity:main Jul 20, 2022
@nerzhul nerzhul deleted the feat/trivy_scan_securitycontext branch July 21, 2022 10:07
@nerzhul
Copy link
Contributor Author

nerzhul commented Jul 21, 2022

@josedonizetti it's a very good comment, i think we should have best security options by default, i just kept compat with existing when writing this pr :)

@erikgb
Copy link
Contributor

erikgb commented Jul 21, 2022

@josedonizetti it's a very good comment, i think we should have best security options by default, i just kept compat with existing when writing this pr :)

It will be a breaking change for users on Openshift, but I do not oppose adding a default according to K8s security best practices. In this case, I think Openshift can improve. 😉 But it should be mentioned in the release notes as a breaking change IMO.

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.

None yet

5 participants