-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
SCC seccomp support #9715
SCC seccomp support #9715
Conversation
@smarterclayton @liggitt ready for review. I want to do some final manual testing before merge but this is the back port of the proposed changes upstream in a 1.3 compatible way. A good question here is if we really care about this control in the alpha phase and if we should maybe be disabling seccomp altogether until it is out of alpha. Some items to consider:
Scenario: currently all seccomp annotations are ignored. If someone adds an annotation before the upgrade process happens it is an unvalidated annotation and can contain In any case, this gives admin control of validation and defaulting but does not protect against the above scenario. |
[test] |
re[test] |
re[test] |
@smarterclayton @liggitt can we have this reviewed asap? it is 3.3 blocker :) |
flake #9959 re[test] |
@@ -81,6 +81,7 @@ func GetBootstrapSecurityContextConstraints(sccNameToAdditionalGroups map[string | |||
SupplementalGroups: kapi.SupplementalGroupsStrategyOptions{ | |||
Type: kapi.SupplementalGroupsStrategyRunAsAny, | |||
}, | |||
SeccompProfiles: []string{"*"}, |
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.
Why are we not making this restrictive? Do we have a value that is actually secure that we can use 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.
This is the privileged SCC. I left the other SCCs as is for 3.3 which means no seccomp value can be specified and the kubelet default will be used.
The discussion upstream is to change the kubelet default to docker/default but since that is untested I was thinking that the better option is to leave this up to the administrator.
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.
oh, and this was changed specifically because the seccomp feature conformance tests need to be able to specify the annotation.
flake #9959 re[test] |
re[test] |
LGTM |
re[test] |
flake #10080 re[test] |
Evaluated for origin test up to 54550af |
continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/7387/) |
tests are green. Last call 🍻 |
[merge] On Tue, Aug 2, 2016 at 12:58 PM, Paul Weil [email protected] wrote:
|
continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/7387/) (Image: devenv-rhel7_4730) |
Evaluated for origin merge up to 54550af |
Support for kube 1.3 alpha seccomp feature.