-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Seccomp GA #1747
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
Seccomp GA #1747
Conversation
saschagrunert
left a comment
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.
Looks pretty good and I like the deprecation of the docker/default profile.
/lgtm
tallclair
left a comment
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.
Thanks for working on this!
evrardjp
left a comment
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 see this as a positive improvement.
I agree with @tallclair on the need to clarify the LocalhostProfile section, for posterity.
I am looking forward to see more eyes on the Localhost Profile Validation section too.
|
@palnabarun I have added the PRR as you asked. There are a few points TBC, but the majority should be there now. |
|
@johnbelamaric Can you please have a look at the PRR questions once? 🙂 |
tallclair
left a comment
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.
Added a few clarifications, but this basically lgtm
|
/lgtm /hold |
|
Also @derekwaynecarr for KEP approval. |
keps/sig-node/20190717-seccomp-ga.md
Outdated
| // LocalhostProfile must be 100 characters or less, beginning and ending with an alphanumeric | ||
| // character ([a-z0-9A-Z]). It may include forward slashes (/), underscores (_), dashes (-) and dots (.) | ||
| // between alphanumeric characters. |
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 more restrictive than the current annotation... what happens to annotations that do not fit inside these restrictions?
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.
the annotation validation also disallows .. path segments, and does not allow starting with a /
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.
how was the 100 character limit selected?
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.
The character limit selected was mostly to decrease the likelihood of going over the max file path in some systems. After reviewing this point, I realised that the limitation on most FSs is around file name length, which would fit the current rules.
I will revert this, to keep the existing validation and simply formalise it on the documentation.
keps/sig-node/20190717-seccomp-ga.md
Outdated
| migrated, the same warning annotation will be added to the controller as for pods: | ||
|
|
||
| ``` | ||
| warning.kubernetes.io/seccomp: "Seccomp set through annotations. Support will be dropped in v1.22" | ||
| warning.kubernetes.io/seccomp: "Seccomp set through annotations. Support will be dropped in v1.23" |
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 a bit unusual... I'm not sure we want to annotate like this. There's not a great central place to sweep all workload objects that contain pod templates to get them to mutate this correctly.
- Would we warn if a workload object had both the annotation and the seccomp field set?
- If an update dropped the seccomp annotation, would we clear the warning?
- Would tying this to an actual warning make more sense once that mechanism is available in 1.19?
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.
That is reasonable. I have added a reference to the warning mechanism.
Given that today is KEP freeze, and this is the only open point, I wonder whether it would be OK to leave as is (with the reference) and I will follow up with a new PR with the details around the warning?
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.
Reword this to commit to avoid committing to a specific warning method. You can mention possible mechanisms like a metric, an audit annotation, an annotation on the object, an event, or a warning as described in KEP 1693
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.
Added reference to the different mechanisms and removed the previous example.
derekwaynecarr
left a comment
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 would like to clarify that the flag @liggitt noted is also promoted to GA.
keps/sig-node/20190717-seccomp-ga.md
Outdated
| Promoting LocalhostProfile to GA signals to the community that this is a feature they can use and rely on, | ||
| until a better option materializes. If and when that happens, a new KEP will be created accordingly. |
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.
since we are trying to do a kep per feature, any enhancement post GA is new feature and new kep, so agree that we dont need to promise future enhancements.
| ## Alternatives | ||
|
|
||
| ### Localhost profiles | ||
| The localhost feature currently depends on an alpha Kubelet flag. We could therefore label the |
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 would like this clarified as well.
the kubelet uses this to build a path like localhost/<some-dir>/<name> when passing the seccompfile path down to sandbox creation flows.
|
Covered all the open points and squashed the commits. PTAL @tallclair @derekwaynecarr @liggitt |
| ### Seccomp root path configuration | ||
|
|
||
| The existing kubelet (alpha) flag `--seccomp-profile-root` allows for seccomp root path configuration. | ||
| This flag will be marked as deprecated as of v1.19, and will be removed on v1.23. | ||
| The seccomp root path will then be derived from the kubelet root path, which is defined by `--root-dir`. | ||
|
|
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.
@derekwaynecarr @liggitt @tallclair this is the new paragraph on '--seccomp-profile-root' being deprecated.
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.
nit: note that the default value for the --seccomp-profile-root is <root-dir>/seccomp. So the proposal is to make the default behavior the only behavior.
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.
Added that information to the same section.
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 am happy with that.
|
Spoke with @liggitt offline, and he convinced me that we should drop the PodSecurityPolicy API changes for now. Basically, the PSP implementation needs to be updated to enforce the policy on the new pod fields, but the API on the PSP will still be through annotations. If PSP sticks around, we can always add the API back later. Rather than deleting everything we have about the PSP API, can you just move it to the "alternatives considered" section? |
|
@tallclair okie dokie, making the changes now. |
|
@liggitt @tallclair moved the PSP API changes to alternatives. |
|
/lgtm |
derekwaynecarr
left a comment
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.
/approve
/lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: derekwaynecarr, pjbgf, tallclair 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 |
|
Based on feedback I marked it as implementable. |
GA flag. Update validation. Update warnings. Move PSP API to alternatives
|
/lgtm I think @derekwaynecarr gets the final say as sig-node lead. |
|
/hold cancel |
Amendments around RuntimeProfile and LocalhostProfile on Tim's initial KEP. The goal remains unchanged: to do the bare minimum to clean up the feature, without blocking future enhancements.
/sig-node
/sig-auth
/priority important-longterm
/assign @liggitt @dchen1107 @derekwaynecarr @tallclair
/cc @jessfraz