-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Scorecard container is not config as restricted and would violate the Pod Security Standard #5939
Comments
This was referenced Sep 15, 2022
jmrodri
changed the title
Scorcard container is not config as restricted and would violate the Pod Security Standard
Scorecard container is not config as restricted and would violate the Pod Security Standard
Oct 12, 2022
I have a solution for this, and will post it shortly. If you'd like to assign this to me, that'd be fine. |
bcrochet
added a commit
to bcrochet/operator-sdk
that referenced
this issue
Nov 15, 2022
The test pod is not yet created in accordance with the Pod Security Standard enforced in k8s 1.24. For compliance, the main pod security context needs: RunAsNonRoot: true SeccompProfile: Type: RuntimeDefault And each container needs: SecurityContext: AllowPrivilegeEscalation: false Capabilities: Drop: 'ALL' Fixes operator-framework#5939 Signed-off-by: Brad P. Crochet <brad@redhat.com>
2 tasks
bcrochet
added a commit
to bcrochet/operator-sdk
that referenced
this issue
Nov 16, 2022
The test pod is not yet created in accordance with the Pod Security Standard enforced in k8s 1.24. For compliance, the main pod security context needs: RunAsNonRoot: true SeccompProfile: Type: RuntimeDefault And each container needs: SecurityContext: AllowPrivilegeEscalation: false Capabilities: Drop: 'ALL' Fixes operator-framework#5939 Signed-off-by: Brad P. Crochet <brad@redhat.com>
bcrochet
added a commit
to bcrochet/operator-sdk
that referenced
this issue
Nov 18, 2022
The test pod is not yet created in accordance with the Pod Security Standard enforced in k8s 1.24. For compliance, the main pod security context needs: RunAsNonRoot: true SeccompProfile: Type: RuntimeDefault And each container needs: SecurityContext: AllowPrivilegeEscalation: false Capabilities: Drop: 'ALL' Fixes operator-framework#5939 Signed-off-by: Brad P. Crochet <brad@redhat.com>
bcrochet
added a commit
to bcrochet/operator-sdk
that referenced
this issue
Nov 18, 2022
The test pod is not yet created in accordance with the Pod Security Standard enforced in k8s 1.24. For compliance, the main pod security context needs: RunAsNonRoot: true SeccompProfile: Type: RuntimeDefault And each container needs: SecurityContext: AllowPrivilegeEscalation: false Capabilities: Drop: 'ALL' Fixes operator-framework#5939 Signed-off-by: Brad P. Crochet <brad@redhat.com>
bcrochet
added a commit
to bcrochet/operator-sdk
that referenced
this issue
Nov 18, 2022
The test pod is not yet created in accordance with the Pod Security Standard enforced in k8s 1.24. For compliance, the main pod security context needs: RunAsNonRoot: true SeccompProfile: Type: RuntimeDefault And each container needs: SecurityContext: AllowPrivilegeEscalation: false Capabilities: Drop: 'ALL' Fixes operator-framework#5939 Signed-off-by: Brad P. Crochet <brad@redhat.com>
7 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug Report
What did you do?
Run the scorecard tests for the sample
./testdata/go/v3/memcached-operator/bundle/
What did you expect to see?
No alerts or WARNS regards the scorecard containers would be violating the Pod Security Standards
What did you see instead? Under which circumstances?
The containers violate the definition and cannot run as restricted
Environment
Operator type:
/language go
/language ansible
/language helm
Kubernetes cluster type:
Kind 'k8s 1.24
$ operator-sdk version
$ operator-sdk version
operator-sdk version: "v1.22.0-21-ge7c9b74e-dirty", commit: "e7c9b74e20ab2dd17ab246c8c9e867b8c9b5b079", kubernetes version: "v1.24.1", go version: "go1.18.3", GOOS: "darwin", GOARCH: "amd64"
$ go version
(if language is Go)go 1.18
Possible Solution
Ensure that the Pod/Containers used for Scorecard can run as restricted:
However, if the Scorecard image used does not define a USER we might check the following error:
"container has runAsNonRoot and image will run as root …
Then, in this case, we can define a USER in the Dockerfile instead of using runAsUser in the security context, such as:
Additional context
https://master.sdk.operatorframework.io/docs/best-practices/pod-security-standards/
The text was updated successfully, but these errors were encountered: