Skip to content
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.

Sign up for GitHub

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

Jump to bottom

KEP for promoting seccomp to GA #1148

Merged
merged 10 commits into from
May 6, 2020
Merged

KEP for promoting seccomp to GA #1148

Changes from 1 commit
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
0e21d25
KEP for promoting seccomp to GA
tallclair Jul 17, 2019
82f393e
Add section about PSP application
tallclair Jul 18, 2019
8d37151
Address feedback
tallclair Jul 30, 2019
cc0e931
Update seccomp GA API
tallclair Sep 26, 2019
098ac44
Fill in approvers/reviewers
tallclair Sep 16, 2019
26b8a4f
Mark KEP as implementable
tallclair Oct 3, 2019
da67380
Iterate on KEP review
tallclair Jan 17, 2020
da1bbc6
revert to provisional status
tallclair May 5, 2020
81059c3
Regenerate TOC
tallclair May 5, 2020
b32550c
Update unresolved section format
tallclair May 5, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Add section about PSP application
  • Loading branch information
@tallclair
tallclair committed Jul 18, 2019
commit 82f393e90571fcad61eb5b80e2de49bdcd35b922
17 changes: 14 additions & 3 deletions keps/sig-node/20190717-seccomp-ga.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -36,6 +36,7 @@ status: provisional
- [Pod Update](#pod-update)
- [PodSecurityPolicy Creation](#podsecuritypolicy-creation)
- [PodSecurityPolicy Update](#podsecuritypolicy-update)
- [PodSecurityPolicy Enforcement](#podsecuritypolicy-enforcement)
- [PodTemplates](#podtemplates)
- [Test Plan](#test-plan)
- [Graduation Criteria](#graduation-criteria)
Expand Down Expand Up @@ -237,9 +238,6 @@ to the API fields. The cases to consider are: pod create, pod update, PSP create
All API skew is resolved in the API server. New Kubelets will only use the seccomp values specified
in the fields, and ignore the annotations.

The PodSecurityPolicy admission controller **must continue to check for annotations** if the fields
are unset, in order to handle upgrade & version skew scenarios.

#### Pod Creation
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the expected behavior if the CRI runtime doesn't support seccomp? The pod should be created without seccomp (as in the current alpha annotation) or should result in an error?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to maintain the backwards compatible behavior of ignoring it (I'll add a line to be explicit about this). Going forward, I left space in the API for a FailureStrategy which could dictate how to handle that situation (e.g. some applications may depend on seccomp application to run securely, while others might accept a best-effort best-practices approach).

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No application should depend on a policy; a policy can be applied as a non privileged operation by any code, so if it requires it then it can just apply it.


If no seccomp annotations or fields are specified, no action is necessary.
Expand Down Expand Up @@ -299,6 +297,19 @@ corresponding fields & annotations (even if one was previously unset).
If both the fields _and_ annotations are changed, the new values MUST match. Enforced in API
validation.

#### PodSecurityPolicy Enforcement

The PodSecurityPolicy admission controller must continue to check the PSP object for annotations if
the fields are unset, in order to handle upgrade & version skew scenarios.

When setting default profiles, PSP only needs to set the field. The API machinery will handle
setting the annotation as necessary.

When enforcing allowed profiles, the PSP should check BOTH the annotations & fields. In most cases,
they should be consistent. On pod update, the seccomp annotations may differ from the fields. In
that case, the PSP enforcement should check both values as the effective value depends on the node
version running the pod.

#### PodTemplates
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

consider how cluster operators will know they have things that need updating. a metric that fires on any podtemplate object with seccomp annotations, and (once we drop pod field -> annotation defaulting) any pod with a seccomp annotation might be helpful for tracking this

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea. It could be any combination of:

  • Metric counter
  • Log line
  • Event (on the controller)
  • Warning annotation (on the controller or created pod)

A metric seems too hidden, if you don't know to look for it. I like the event, except it will disappear if you don't notice it right away. I'm leaning towards an annotation on both the controller object and the pod:

warning.kubernetes.io/seccomp: "Seccomp set through annotations. Support for setting seccomp through annotations will be dropped in v1.X"

We may also want to consider forbidding setting the seccomp annotation after we drop support, so that pods aren't being run unconfined unexpectedly. That would be more likely to break users, but follows the secure failure principle.


PodTemplates (e.g. ReplaceSets, Deployments, StatefulSets, etc.) will be ignored. The
Expand Down