-
Notifications
You must be signed in to change notification settings - Fork 36
Feature: pod security admission #165
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
Conversation
Signed-off-by: Philippe Martin <[email protected]>
eef21a1
to
8572863
Compare
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #165 +/- ##
==========================================
+ Coverage 59.67% 60.33% +0.65%
==========================================
Files 36 37 +1
Lines 4226 4369 +143
==========================================
+ Hits 2522 2636 +114
- Misses 1557 1571 +14
- Partials 147 162 +15
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
a3c1ec6
to
4ed8ec6
Compare
Signed-off-by: Philippe Martin <[email protected]>
Signed-off-by: Philippe Martin <[email protected]>
Signed-off-by: Philippe Martin <[email protected]>
3bd8f3f
to
a7af25b
Compare
To maintain backward compatibility, we need to keep the old functions and create new ones to provide the new function |
5fd63a3
to
12f8332
Compare
…ace calls to GetContainers + GetInitContainers) Signed-off-by: Philippe Martin <[email protected]>
12f8332
to
497d2a0
Compare
Signed-off-by: Philippe Martin <[email protected]>
88bd295
to
d797fca
Compare
@@ -16,7 +16,7 @@ jobs: | |||
- name: Setup Go environment | |||
uses: actions/[email protected] | |||
with: | |||
go-version: 1.16 | |||
go-version: 1.19 |
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 guess we also need to update the Go version in codecov.yml
? I can see that this workflow is not triggered on PRs, but only upon a push on main
, which makes me think that this may no longer pass on main
once this PR is merged.
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.
Also, wondering if we should not update the version in go.mod
to reflect this? This way, all calls to the setup-go
action could simply use the version declared in go.mod
(see https://github.com/actions/setup-go#getting-go-version-from-the-gomod-file). But I am not sure about the implications on consumers of the library if the Go version in go.mod
is updated. This might be a different issue, that said..
podTemplateSpec.Spec.SecurityContext = &corev1.PodSecurityContext{} | ||
} | ||
podTemplateSpec.Spec.SecurityContext.RunAsNonRoot = pointer.Bool(true) | ||
// No need to set the value as true for containers, as setting at the Pod level is sufficient |
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.
To me (and per https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-container), security settings at the Container level override settings made at the Pod level when there is an overlap. So I think, we don't need to set the value as true
to containers only if they are not specified at the container level.
So we should still visit all containers and set the field to true
, no?
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.
To me (and per https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-container), security settings at the Container level override settings made at the Pod level when there is an overlap. So I think, we don't need to set the value as
true
to containers only if they are not specified at the container level.
I agree up to here.
So we should still visit all containers and set the field to
true
, no?
By design, we know the field at container level will never be set (because they could be set only from the library, and they are not). For this reason, we only need to set it at pod level.
if podTemplateSpec.Spec.SecurityContext.SeccompProfile == nil { | ||
podTemplateSpec.Spec.SecurityContext.SeccompProfile = &corev1.SeccompProfile{} | ||
} | ||
podTemplateSpec.Spec.SecurityContext.SeccompProfile.Type = "RuntimeDefault" |
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.
Similar point here: I think we should visit all containers and set the field too..
To me (and per https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-container), security settings at the Container level override settings made at the Pod level when there is an overlap. So I think, we don't need to set the value to containers only if they are not specified at the container level.
So we should still visit all containers and set the field, no?
@rm3l: changing LGTM is restricted to collaborators 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. |
Signed-off-by: Philippe Martin <[email protected]>
Signed-off-by: Philippe Martin <[email protected]>
2b29e22
to
5985a28
Compare
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!
@rm3l: changing LGTM is restricted to collaborators 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. |
// - patches the pod template and containers to satisfy PodSecurityAdmissionPolicy | ||
// - patches the pod template and containers to apply pod and container overrides | ||
func GetPodTemplateSpec(devfileObj parser.DevfileObj, podTemplateParams PodTemplateParams) (*corev1.PodTemplateSpec, error) { | ||
containers, err := GetContainers(devfileObj, common.DevfileOptions{}) |
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.
the GetContainers
and GetInitContainers
are being called by this new function introduced. which means the two functions are still in use, and need to be updated upon any changes to GetContainers/GetInitContainers behaviors. why mark the two functions as deprecated?
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.
IMO, the GetContainers/GetInitContainers could be removed later from the library interface, by renaming them as getContainers/getInitContainers
pkg/devfile/generator/generators.go
Outdated
return nil, errors.New("InitContainers, Containers and Volumes cannot be set when PodTemplateSpec is set in parameters") | ||
} | ||
|
||
deploySpecParams = deploymentSpecParams{ |
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.
dup with
library/pkg/devfile/generator/generators.go
Lines 209 to 212 in 5985a28
deploySpecParams = deploymentSpecParams{ | |
PodTemplateSpec: *podTemplateSpec, | |
PodSelectorLabels: deployParams.PodSelectorLabels, | |
Replicas: deployParams.Replicas, |
} | ||
|
||
return deployment, nil | ||
getContainerByName := func(name string) (*corev1.Container, bool) { |
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.
you do not need to introduce a new function for this purpose.
should use
func (d *DevfileV2) GetComponents(options common.DevfileOptions) ([]v1.Component, error) { |
DevfileOptions.FilterByName = <the containerName>
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.
Are you sure? getContainerByName
finds a specific container from the containers
passed as parameter, but the method you mentions would find a component from the Devfile.
Thanks @yangcao77 for you review |
Signed-off-by: Philippe Martin <[email protected]>
a2a2790
to
2239fa9
Compare
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 making this change, generally looks good to me
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: feloy, rm3l, yangcao77 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 |
What does this PR do?:
This PR adds the possibility to get a patched PodTemplate based on a Pod Security Admission policy, so the Pod can be accepted by the Pod Security Admission controller.
Prior to being able to do this, some refactoring has been done:
GetPodTemplateSpec
has been added, that will handle the Pod Security patching and the container/pod overrides in an atomic way (instead of making them in different places), to be used instead of GetContainers/GetInitContainersWhich issue(s) this PR fixes:
redhat-developer/odo#6339
PR acceptance criteria:
Testing and documentation do not need to be complete in order for this PR to be approved. We just need to ensure tracking issues are opened.
Unit/Functional tests
QE Integration test
Documentation
Client Impact
Gosec scans
How to test changes / Special notes to the reviewer: