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

Feature: pod security admission #165

Merged
merged 14 commits into from
Mar 8, 2023

Conversation

feloy
Copy link
Contributor

@feloy feloy commented Feb 20, 2023

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:

  • updating the k8s dependencies to latest version, to be able to use the latest version of k8s.io/pod-security-admission
  • update to go 1.19, to be able to use the latest k8s dependencies
  • A new method 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/GetInitContainers
  • GetDeployment now accepts a podSecurityTemplate instead of containers, initContainers and volumes (these 3 values are now marked as deprecated)

Which 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.

  • Open new test/doc issues under the devfile/api repo
  • Check each criteria if:
  • There is a separate tracking issue. Add the issue link under the criteria
    or
  • test/doc updates are made as part of this PR
  • If unchecked, explain why it's not needed

How to test changes / Special notes to the reviewer:

Signed-off-by: Philippe Martin <phmartin@redhat.com>
@feloy feloy force-pushed the feature-pod-security-admission branch 2 times, most recently from eef21a1 to 8572863 Compare February 20, 2023 12:38
@codecov
Copy link

codecov bot commented Feb 20, 2023

Codecov Report

Patch coverage: 67.42% and project coverage change: +0.65 🎉

Comparison is base (4f0ff68) 59.67% compared to head (2239fa9) 60.33%.

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     
Impacted Files Coverage Δ
pkg/devfile/parser/data/v2/header.go 100.00% <ø> (ø)
pkg/devfile/parser/data/v2/projects.go 94.73% <ø> (ø)
pkg/devfile/parser/parse.go 59.01% <ø> (+5.14%) ⬆️
pkg/devfile/parser/sourceAttribute.go 85.91% <ø> (ø)
pkg/util/util.go 38.69% <ø> (ø)
pkg/devfile/generator/policy.go 64.10% <64.10%> (ø)
pkg/devfile/generator/generators.go 63.09% <69.47%> (-2.14%) ⬇️
pkg/devfile/generator/utils.go 90.90% <100.00%> (+0.28%) ⬆️
... and 1 more

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.
📢 Do you have feedback about the report comment? Let us know in this issue.

@feloy feloy force-pushed the feature-pod-security-admission branch from a3c1ec6 to 4ed8ec6 Compare February 20, 2023 13:00
Signed-off-by: Philippe Martin <phmartin@redhat.com>
Signed-off-by: Philippe Martin <phmartin@redhat.com>
Signed-off-by: Philippe Martin <phmartin@redhat.com>
@feloy feloy force-pushed the feature-pod-security-admission branch 6 times, most recently from 3bd8f3f to a7af25b Compare February 21, 2023 14:03
@feloy feloy marked this pull request as ready for review February 21, 2023 14:13
@openshift-ci openshift-ci bot requested a review from elsony February 21, 2023 14:14
@feloy feloy changed the title [wip] Feature pod security admission Feature pod security admission Feb 22, 2023
@feloy feloy changed the title Feature pod security admission Feature: pod security admission Feb 23, 2023
@elsony
Copy link

elsony commented Feb 23, 2023

To maintain backward compatibility, we need to keep the old functions and create new ones to provide the new function

@feloy feloy force-pushed the feature-pod-security-admission branch 2 times, most recently from 5fd63a3 to 12f8332 Compare February 23, 2023 13:27
@feloy feloy changed the title Feature: pod security admission [wip] Feature: pod security admission Feb 23, 2023
…ace calls to GetContainers + GetInitContainers)

Signed-off-by: Philippe Martin <phmartin@redhat.com>
@feloy feloy force-pushed the feature-pod-security-admission branch from 12f8332 to 497d2a0 Compare February 23, 2023 14:24
Signed-off-by: Philippe Martin <phmartin@redhat.com>
@feloy feloy force-pushed the feature-pod-security-admission branch from 88bd295 to d797fca Compare February 23, 2023 14:36
@feloy feloy changed the title [wip] Feature: pod security admission Feature: pod security admission Feb 23, 2023
@feloy feloy requested review from rm3l and removed request for elsony, yangcao77 and maysunfaisal February 23, 2023 14:37
pkg/devfile/generator/generators.go Outdated Show resolved Hide resolved
pkg/devfile/generator/generators.go Outdated Show resolved Hide resolved
@@ -16,7 +16,7 @@ jobs:
- name: Setup Go environment
uses: actions/setup-go@v2.1.3
with:
go-version: 1.16
go-version: 1.19
Copy link
Member

@rm3l rm3l Feb 28, 2023

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.

Copy link
Member

@rm3l rm3l Feb 28, 2023

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
Copy link
Member

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?

Copy link
Contributor Author

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"
Copy link
Member

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?

pkg/testingutil/k8sClient.go Outdated Show resolved Hide resolved
@openshift-ci
Copy link

openshift-ci bot commented Feb 28, 2023

@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 <phmartin@redhat.com>
Signed-off-by: Philippe Martin <phmartin@redhat.com>
@feloy feloy force-pushed the feature-pod-security-admission branch from 2b29e22 to 5985a28 Compare March 1, 2023 08:54
@feloy feloy requested a review from rm3l March 1, 2023 08:55
Copy link
Member

@rm3l rm3l 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!

@openshift-ci
Copy link

openshift-ci bot commented Mar 1, 2023

@rm3l: changing LGTM is restricted to collaborators

In response to this:

LGTM - thanks!

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{})
Copy link
Collaborator

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?

Copy link
Contributor Author

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

return nil, errors.New("InitContainers, Containers and Volumes cannot be set when PodTemplateSpec is set in parameters")
}

deploySpecParams = deploymentSpecParams{
Copy link
Collaborator

Choose a reason for hiding this comment

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

dup with

deploySpecParams = deploymentSpecParams{
PodTemplateSpec: *podTemplateSpec,
PodSelectorLabels: deployParams.PodSelectorLabels,
Replicas: deployParams.Replicas,
, can be move out side of the if-else block?

}

return deployment, nil
getContainerByName := func(name string) (*corev1.Container, bool) {
Copy link
Collaborator

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) {
, and set DevfileOptions.FilterByName = <the containerName>

Copy link
Contributor Author

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.

@feloy feloy requested a review from yangcao77 March 8, 2023 13:11
@feloy
Copy link
Contributor Author

feloy commented Mar 8, 2023

Thanks @yangcao77 for you review

Signed-off-by: Philippe Martin <phmartin@redhat.com>
@feloy feloy force-pushed the feature-pod-security-admission branch from a2a2790 to 2239fa9 Compare March 8, 2023 13:13
Copy link
Collaborator

@yangcao77 yangcao77 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 making this change, generally looks good to me

@openshift-ci
Copy link

openshift-ci bot commented Mar 8, 2023

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants