⚠️ (kustomize/v1,v2): applying restrictive SCC for all containers scaffolded by the tool (k8s versions < 1.19 does not work with) #2700
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
k8s-ci-robot
added
cncf-cla: yes
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: camilamacedo86 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 |
k8s-ci-robot
added
the
approved
camilamacedo86
changed the title
k8s-ci-robot
added
the
do-not-merge/work-in-progress
|
/retest |
camilamacedo86
changed the title
k8s-ci-robot
removed
the
do-not-merge/work-in-progress
camilamacedo86
changed the title
camilamacedo86
force-pushed
the
containers-created-with-restrictive
branch
from
3821225
to
7f34aae
Compare
camilamacedo86
commented
May 26, 2022
k8s-ci-robot
added
the
do-not-merge/hold
|
/hold cancel |
k8s-ci-robot
removed
the
do-not-merge/hold
|
/lgtm |
k8s-ci-robot
added
the
lgtm
camilamacedo86
changed the title
camilamacedo86
pushed a commit
to camilamacedo86/operator-sdk
that referenced
this pull request
May 29, 2022
Signed-off-by: Camila Macedo <cmacedo@redhat.com> - For Golang/Ansible/Helm language-based operators (go/v3, ansible/v1 and helm/v1): applying restrictive SCC for all containers scaffolded by the tool (`k8s versions < 1.19 will no longer work with`). ([More info](kubernetes-sigs/kubebuilder#2700)) - For Golang-based language (go/v2) fix the issue introduced by removing the GO111MODULE=on from Dockerfile. ([More info](kubernetes-sigs/kubebuilder#2678)) - For Golang/Ansible/Helm language-based operators (go/v3, ansible/v1 and helm/v1 language (go/v3), add a new comment with the option `leaderElectionReleaseOnCancel` ((More info)[kubernetes-sigs/kubebuilder#2596]) Only to get the changes from what we currently use in SDK from kubebuilder. - Ensure that scaffolds begin to be performed with a restrive Security Context - Be able to do specific follow up PR so we can discuss properly how we will consume the new additions on Kubebuilder - Make eaiser the process to keep SDK updated, otherwise, it is hard to properly review if we wait to do a big PR with all. - Ensure that SDK features can work with the latest changes performed in Kubebuilder **Extra info** You can check the latest changes on Kubebuilder by looking: kubernetes-sigs/kubebuilder@v3.4.1...master Note that SDK users Kubebuilder as a LIB. So that all that is currently important is updated by default when we bump. However, all that was added to Kubebuilder but still not imported/used in SDK will not be added here. Therefore we can do follow up PRs to get the additions. Why? we have significant changes and additions for example adding the support for the phase 2 plugin, but if we try to do it all in the same PR it will be very hard to get properly reviewed.
camilamacedo86
pushed a commit
to camilamacedo86/operator-sdk
that referenced
this pull request
May 29, 2022
Signed-off-by: Camila Macedo <cmacedo@redhat.com> - For Golang/Ansible/Helm language-based operators (go/v3, ansible/v1 and helm/v1): applying restrictive SCC for all containers scaffolded by the tool (`k8s versions < 1.19 will no longer work with`). ([More info](kubernetes-sigs/kubebuilder#2700)) - For Golang-based language (go/v2) fix the issue introduced by removing the GO111MODULE=on from Dockerfile. ([More info](kubernetes-sigs/kubebuilder#2678)) - For Golang/Ansible/Helm language-based operators (go/v3, ansible/v1 and helm/v1 language (go/v3), add a new comment with the option `leaderElectionReleaseOnCancel` ((More info)[kubernetes-sigs/kubebuilder#2596]) Only to get the changes from what we currently use in SDK from kubebuilder. - Ensure that scaffolds begin to be performed with a restrive Security Context - Be able to do specific follow up PR so we can discuss properly how we will consume the new additions on Kubebuilder - Make eaiser the process to keep SDK updated, otherwise, it is hard to properly review if we wait to do a big PR with all. - Ensure that SDK features can work with the latest changes performed in Kubebuilder **Extra info** You can check the latest changes on Kubebuilder by looking: kubernetes-sigs/kubebuilder@v3.4.1...master Note that SDK users Kubebuilder as a LIB. So that all that is currently important is updated by default when we bump. However, all that was added to Kubebuilder but still not imported/used in SDK will not be added here. Therefore we can do follow up PRs to get the additions. Why? we have significant changes and additions for example adding the support for the phase 2 plugin, but if we try to do it all in the same PR it will be very hard to get properly reviewed.
camilamacedo86
pushed a commit
to camilamacedo86/operator-sdk
that referenced
this pull request
May 29, 2022
Signed-off-by: Camila Macedo <cmacedo@redhat.com> - For Golang/Ansible/Helm language-based operators (go/v3, ansible/v1 and helm/v1): applying restrictive SCC for all containers scaffolded by the tool (`k8s versions < 1.19 will no longer work with`). ([More info](kubernetes-sigs/kubebuilder#2700)) - For Golang-based language (go/v2) fix the issue introduced by removing the GO111MODULE=on from Dockerfile. ([More info](kubernetes-sigs/kubebuilder#2678)) - For Golang/Ansible/Helm language-based operators (go/v3, ansible/v1 and helm/v1 language (go/v3), add a new comment with the option `leaderElectionReleaseOnCancel` ((More info)[kubernetes-sigs/kubebuilder#2596]) Only to get the changes from what we currently use in SDK from kubebuilder. - Ensure that scaffolds begin to be performed with a restrive Security Context - Be able to do specific follow up PR so we can discuss properly how we will consume the new additions on Kubebuilder - Make eaiser the process to keep SDK updated, otherwise, it is hard to properly review if we wait to do a big PR with all. - Ensure that SDK features can work with the latest changes performed in Kubebuilder **Extra info** You can check the latest changes on Kubebuilder by looking: kubernetes-sigs/kubebuilder@v3.4.1...master Note that SDK users Kubebuilder as a LIB. So that all that is currently important is updated by default when we bump. However, all that was added to Kubebuilder but still not imported/used in SDK will not be added here. Therefore we can do follow up PRs to get the additions. Why? we have significant changes and additions for example adding the support for the phase 2 plugin, but if we try to do it all in the same PR it will be very hard to get properly reviewed.
camilamacedo86
pushed a commit
to camilamacedo86/operator-sdk
that referenced
this pull request
Jun 7, 2022
Signed-off-by: Camila Macedo <cmacedo@redhat.com> - For Golang/Ansible/Helm language-based operators (go/v3, ansible/v1 and helm/v1): applying restrictive SCC for all containers scaffolded by the tool (`k8s versions < 1.19 will no longer work with`). ([More info](kubernetes-sigs/kubebuilder#2700)) - For Golang-based language (go/v2) fix the issue introduced by removing the GO111MODULE=on from Dockerfile. ([More info](kubernetes-sigs/kubebuilder#2678)) - For Golang/Ansible/Helm language-based operators (go/v3, ansible/v1 and helm/v1 language (go/v3), add a new comment with the option `leaderElectionReleaseOnCancel` ((More info)[kubernetes-sigs/kubebuilder#2596]) Only to get the changes from what we currently use in SDK from kubebuilder. - Ensure that scaffolds begin to be performed with a restrive Security Context - Be able to do specific follow up PR so we can discuss properly how we will consume the new additions on Kubebuilder - Make eaiser the process to keep SDK updated, otherwise, it is hard to properly review if we wait to do a big PR with all. - Ensure that SDK features can work with the latest changes performed in Kubebuilder **Extra info** You can check the latest changes on Kubebuilder by looking: kubernetes-sigs/kubebuilder@v3.4.1...master Note that SDK users Kubebuilder as a LIB. So that all that is currently important is updated by default when we bump. However, all that was added to Kubebuilder but still not imported/used in SDK will not be added here. Therefore we can do follow up PRs to get the additions. Why? we have significant changes and additions for example adding the support for the phase 2 plugin, but if we try to do it all in the same PR it will be very hard to get properly reviewed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
(kustomize/v1,v2): applying restrictive SCC for all containers scaffolded by the tool
Note
If applied on clusters < 1.19 the error
unknown field "seccompProfile" in io.k8s.api.core.v1.PodSecurityContextwill be faced. Users still able to remove the seccompProfile if they need to provide patch releases for old versionsMotivation
Following good practices and ensuring containers are restrictive. (We want to ensure that all scaffold by default is restrictive independently if the cluster-admin enable or not for example SeccompDefault)
More info: https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted
Nice to know: from 1.22 was introduced for the SeccompDefault feature in kubelet, which allows cluster admins also set it for all pods, see: https://kubernetes.io/docs/tutorials/security/seccomp/#enable-the-use-of-runtimedefault-as-the-default-seccomp-profile-for-all-workloads