-
Notifications
You must be signed in to change notification settings - Fork 40k
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
Add PSP support for seccomp profiles #28300
Conversation
// SeccompProfiles is a slice of allowed profiles that may be set for the pod or | ||
// container's seccomp annotations. The wildcard '*' may be used to allow all. When | ||
// used to generate a value for a pod the first non-wildcard profile will be used as | ||
// the default. |
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.
If this is unset, what happens? Describe 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.
Unset and also empty.
With all the annotation trouble. I wonder why we don't add the actual seccomp fields in the internal representation and translate it back to annotations on conversion. |
That works (we do it for init container) but it will break apply. On Jul 1, 2016, at 7:25 AM, Dr. Stefan Schimanski notifications@github.com With all the annotation trouble. I wonder why we don't add the actual — |
@smarterclayton which apply? kubectl-apply? Do you have a hint why it breaks? |
@sttts - are you going to change the internal type? If so I'll hold off on changes until I can rebase on that. I'd like to get this finished up this week and back ported to Origin, so that's what I'm shooting for. |
@pweil- don't worry. just go ahead. I will adapt my code when your PR goes into master. |
kubectl-apply - it breaks because roundtripping the annotations through marshal and unmarshal loses the original formatting in the annotation (user provides I'm making that argument that for an alpha feature that's acceptable (users can work around it) and the problem is resolved once the feature is out of annotations. |
@sttts @smarterclayton comments addressed in code or responses here. @sttts I spent some time rewriting the strategy since, as you pointed out, it was a little confusing to read. Let me know if you think the new code is easier to follow. It also now supports a missing pod level annotation so long as all containers have their own annotation that is valid. |
@sttts @timstclair - updated to better match the app armor implementation. There were two places I deviated that I want to call out:
Let me know what you think or if I've forgotten anything we talked about. |
// NewStrategy creates a new strategy that enforces seccomp profile constraints. | ||
func NewStrategy(pspAnnotations map[string]string) Strategy { | ||
var allowedProfiles map[string]bool | ||
allowAnyProfile := false |
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.
So by default, no seccomp is disabled? Is that the desired behavior? I would expect lack of AllowedProfilesAnnotationKey
to imply AllowAny
(that's how it works with AppArmor).
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 was thinking about that today and I think it breaks the upgrade experience. Lacking the key, if we default to all enabled, we're running in a less restricted mode than we were previously. If we imply that it is 'allow none' you can safely upgrade to the new behavior without having to make changes to your api objects.
WDYT?
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.
Yeah, that makes sense.
faa4f4b
to
555aa93
Compare
GCE e2e build/test passed for commit faa4f4bc7078c9b6e14f65dcb726b186f2149ffe. |
@sttts @timstclair any other remaining items 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.
LGTM
lgtm |
@k8s-bot test this [submit-queue is verifying that this PR is safe to merge] |
Jenkins GCI GKE smoke e2e failed for commit 49e1474. Full PR test history. The magic incantation to run this job again is |
Automatic merge from submit-queue |
Seccomp support for PSP. There are still a couple of TODOs that need to be fixed but this is passing tests.
One thing of note, since seccomp is all being stored in annotations right now it breaks some of the assumptions we've stated for the provider in terms of mutating the passed in pod. I've put big warning comments around the pieces that do that to make sure it's clear and covered the rollback in admission if the policy fails to validate.
@sttts @pmorie @erictune @smarterclayton @liggitt
This change is