-
Notifications
You must be signed in to change notification settings - Fork 566
[WIP] PSA Updates #2810
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
[WIP] PSA Updates #2810
Conversation
* Update ci artifact collection Signed-off-by: perdasilva <perdasilva@redhat.com> * Update e2e test images to use FBC Signed-off-by: perdasilva <perdasilva@redhat.com> * Update CatalogSource Pod security context Signed-off-by: perdasilva <perdasilva@redhat.com>
* Update unpack job security Signed-off-by: perdasilva <perdasilva@redhat.com> * Refactor catsrc pod creation to use security package Signed-off-by: perdasilva <perdasilva@redhat.com>
Signed-off-by: perdasilva <perdasilva@redhat.com>
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: perdasilva The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
| serviceAccountName: olm-operator-serviceaccount | ||
| securityContext: | ||
| runAsNonRoot: true | ||
| runAsUser: 1001 |
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.
This one cannot be qualified to access restricted-v2 because of the runAsUser
That will requires access to anyuid SCC. However, if we test in k8s env that can run in a restricted ns and is qualified under the k8s rules to be restricted. See:
Therefore, do we really need to define userId?
Leave the runAsUser field empty, or provide a value that falls within the specific user range for the namespace. provide a value in the ranges: [1000680000, 1000689999
| WORKDIR /build | ||
|
|
||
| # install dependencies and go 1.16 | ||
| # install dependencies and go 1.17 |
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.
Any reason for we are not using 1.18 yet?
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.
We probably should move to 1.18 here - though I think it should be done in another PR
| RunAsNonRoot: pointer.Bool(runAsNonRoot), | ||
| RunAsUser: pointer.Int64(runAsUser), | ||
| SeccompProfile: &corev1.SeccompProfile{ | ||
| Type: corev1.SeccompProfileTypeRuntimeDefault, |
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.
Signed-off-by: perdasilva <perdasilva@redhat.com>
|
|
||
| var expectedPodSecurityContext = &corev1.PodSecurityContext{ | ||
| RunAsNonRoot: &expectedRunAsNonRoot, | ||
| RunAsUser: &expectedRunAsUser, |
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.
| } | ||
|
|
||
| // Update pod security | ||
| security.ApplyPodSpecSecurity(&pod.Spec, security.WithRunAsUser(1001)) |
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.
| expectedReadOnlyRootFilesystem := false | ||
| expectedAllowPrivilegeEscalation := false | ||
| expectedRunAsNonRoot := true | ||
| expectedRunAsUser := int64(1001) |
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.
Same here
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.
We need to use RunAsUser for the catalog source pods for now. Otherwise, only catalogs based off the latest opm image will work. We may need to handle this like a deprecation or something like that giving people some time to rebuild their catalogs.
Signed-off-by: perdasilva <perdasilva@redhat.com>
|
/hold until we figure out how to migrate. These changes are only valid from k8s >= 1.19. Should we cut a release before merging and only support 1.19 going forward? |
Signed-off-by: perdasilva <perdasilva@redhat.com>
Signed-off-by: perdasilva <perdasilva@redhat.com>
|
@perdasilva: PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
/close as this is out of date. |
|
@anik120: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Description of the change:
This PR updates the namespace and operator deployment resources and the catalog source and bundle unpacker job to enforce the PSA
restrictedprofile.NOTE These changes will break sqlite-based catalog sources due to a bug in opm fix, in which a copy of the database was made on the root of the filesystem.
Motivation for the change:
Upstream k8s is rolling out the new Pod Security Admission (PSA) mechanism to improve cluster security and substitute the Pod Security Policies feature link.
Architectural changes:
None
Testing remarks:
Manually tested on kind with k8s 1.24
Reviewer Checklist
/doc[FLAKE]are truly flaky and have an issue