Add AppArmor validation logic #29812
Conversation
timstclair
added
the
release-note-none
k8s-github-robot
added
the
size/L
timstclair
force-pushed
the
aa-validation
branch
from
0b3398f to
e38ece9
Compare
|
Rebased and updated boilerplate (again!). |
|
Reassigning review to Dawn since I'm blocked on this. |
|
/cc @Amey-D |
| return fmt.Errorf("could not read loaded profiles: %v", err) | ||
| } | ||
|
|
||
| for _, container := range pod.Spec.Containers { |
There was a problem hiding this comment.
If pod has initContainers, should we validate its profile too?
|
@dchen1107 ping :) |
| return nil | ||
| } | ||
|
|
||
| func (v *validator) getLoadedProfiles() (map[string]bool, error) { |
There was a problem hiding this comment.
I don't know if the format here is guaranteed
There was a problem hiding this comment.
I looked into it a bit, and couldn't find the profiles format documented anywhere (AppArmor documentation seems scarce), but I did find the kernel implementation, and the parsing done by the aa-status tool. I updated the parsing to be a bit more precise.
timstclair
force-pushed
the
aa-validation
branch
from
88058d5 to
283c63f
Compare
|
Thanks @jfrazelle |
|
LGTM |
jessfraz
added
the
lgtm
|
LGTM overall except one comment which should be addressed through doc, and outside this pr: Based on current proposed design, app profile is opaque to Kubernetes, including kubelet, which is good. But ubuntu apparmor has more features (more "hooks") than the upstream one which we are validating today through GCI image. But if the customers bring apparmor profiles from their ubuntu installations, in which case the profiles may not work correctly on GKE/GCI. This is a portability issue, and we should document it. Please squash the commits, we are ready to go. |
dchen1107
removed
the
lgtm
|
@jfrazelle Thanks for reviewing this. I temporarily removed lgtm label so that @timstclair can have enough time to squash his commits. :-) Tim, please feel free to readd the label once you are done with squash. |
timstclair
force-pushed
the
aa-validation
branch
from
283c63f to
336b7fa
Compare
|
Squashed. Thanks all! |
timstclair
added
the
lgtm
|
oh so sorry!! On Wed, Aug 10, 2016 at 3:08 PM, Dawn Chen notifications@github.com wrote:
|
The validation checks the prerequisites described in the [AppArmor proposal](https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/apparmor.md#prerequisites)
timstclair
force-pushed
the
aa-validation
branch
from
336b7fa to
bdc306b
Compare
|
Rebased. |
timstclair
added
lgtm
|
GCE e2e build/test passed for commit bdc306b. |
|
@k8s-bot test this [submit-queue is verifying that this PR is safe to merge] |
|
GCE e2e build/test passed for commit bdc306b. |
|
Automatic merge from submit-queue |
Automatic merge from submit-queue Implement AppArmor Kubelet support Includes PR #29812 Implements the Kubelet logic for AppArmor based on the alpha API proposed [here](https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/apparmor.md). Also adds an E2E test, and I ran manual tests. Remaining work: PodSecurityPolicy support, profile loader daemon, documentation, (maybe) beta API. /cc @jfrazelle @Amey-D @kubernetes/sig-node *Note on release-note-none: I am implementing AppArmor over multiple PRs. I will submit a single release note once the implementation is done to cover all of them.*
The validation checks the prerequisites described in the AppArmor proposal.
In order to unblock the AppArmor implementation from waiting on the APIs to merge, this PR uses 2 helper stubs for handling the Pod API.
This change is