-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
⚠️ (kustomize/v1,v2): applying restrictive SCC for all containers scaffolded by the tool (k8s versions < 1.19 does not work with) #2700
Merged
k8s-ci-robot
merged 2 commits into
kubernetes-sigs:master
from
camilamacedo86:containers-created-with-restrictive
May 28, 2022
Merged
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
[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 |
/retest |
3821225
to
7f34aae
Compare
camilamacedo86
commented
May 26, 2022
/hold cancel |
/lgtm |
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
Labels
approved
Indicates a PR has been approved by an approver from all required OWNERS files.
cncf-cla: yes
Indicates the PR's author has signed the CNCF CLA.
lgtm
"Looks good to me", indicates that a PR is ready to be merged.
size/L
Denotes a PR that changes 100-499 lines, ignoring generated files.
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.PodSecurityContext
will 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