Add PSP support for seccomp profiles#28300
Conversation
There was a problem hiding this comment.
If this is unset, what happens? Describe here
|
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 [email protected] 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.
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.
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?
faa4f4b to
555aa93
Compare
|
GCE e2e build/test passed for commit faa4f4bc7078c9b6e14f65dcb726b186f2149ffe. |
|
@sttts @timstclair any other remaining items here? |
|
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