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-2579: Pod Security GA plan #3310

Merged
merged 5 commits into from
May 18, 2022
Merged

KEP-2579: Pod Security GA plan #3310

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
da76cd0
Pod Security GA plan
tallclair May 11, 2022
32dc2c4
Add test coverage sections
tallclair May 12, 2022
eb19756
Clarify API changes
tallclair May 12, 2022
e2224f8
Add prod-readiness approvers file
tallclair May 12, 2022
026a9f6
Fix dates
tallclair May 12, 2022
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
35 changes: 22 additions & 13 deletions keps/sig-auth/2579-psp-replacement/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -735,15 +735,25 @@ We are targeting Beta in v1.23.

#### GA

<<[UNRESOLVED]>>
Targeting GA in v1.25.

We are targeting GA in v1.24 to allow for migration off PodSecurityPolicy before it is removed in
v1.25.
**Conformance:**
- Enabling the admission controller with the "default-default" enforcing mode of privileged is
essentially a no-op without adding namespace labels, so it doesn't have any impact on
conformance.
- E2E framework has been updated to explicitly label test namespaces with the appropriate
enforcement level, using the `NamespacePodSecurityEnforceLevel` framework value. For GA,
conformance tests should be updated to use the most restrictive level possible.
- Pod Security Admission is *not* required for conformance.

- Examples of real world usage and positive user feedback.
- [Conformance test plan](#conformance)
**User Experience Improvements:**
- [Warn when labeling exempt namespaces](https://github.com/kubernetes/kubernetes/issues/109549)
- [Dedupe overlapping forbidden messages](https://github.com/kubernetes/kubernetes/issues/106129)
- [Aggregate identical warnings for multiple pods in a namespace](https://github.com/kubernetes/kubernetes/issues/103213)
- [Add context to failure messages](https://github.com/kubernetes/kubernetes/pull/105314)

<<[/UNRESOLVED]>>
**API Changes:**
- Add `pod-security.admission.config.k8s.io/v1` with no changes from the `v1beta1` API.
tallclair marked this conversation as resolved.
Show resolved Hide resolved

### Upgrade / Downgrade Strategy

Expand Down Expand Up @@ -910,6 +920,8 @@ previous answers based on experience in the field._
There will be a hard cap on the number of pods analyzed, and a timeout for the review of those pods
that ensures evaluation does not exceed a percentage of the time allocated to the request.
See [Namespace policy update warnings](#namespace-policy-update-warnings).
- Timeout: minimum of 1 second or (remaining request deadline / 2)
- Max pods to check: 3000 ([benchmarks](https://github.com/kubernetes/kubernetes/pull/104588) indicate that 3000 pods should evaluate in under 10ms)

* **Will enabling / using this feature result in introducing new API types?**
- No.
Expand Down Expand Up @@ -1046,13 +1058,10 @@ templated pod resources. This could be useful in CI/CD pipelines and tests.

### Conformance

As this feature progresses towards GA, we should think more about how it interacts with conformance.

- Enabling the admission controller with the "default-default" enforcing mode of privileged is
essentially a no-op without adding namespace labels, so it shouldn't have any impact on
conformance.
- If we want a more restricted version to still be considered conformant, we might need to
explicitly label namespaces in the conformance tests with the privilege level the tests require.
Clusters requiring baseline or restricted Pod Security levels should still be able to pass
conformance. This might require
[Conformance Profiles](https://github.com/kubernetes/enhancements/tree/master/keps/sig-architecture/1618-conformance-profiles)
to be feasible.

## Implementation History

Expand Down
8 changes: 4 additions & 4 deletions keps/sig-auth/2579-psp-replacement/kep.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,26 +29,26 @@ see-also:
replaces: []

# The target maturity stage in the current dev cycle for this KEP.
stage: beta
stage: stable

# The most recent milestone for which work toward delivery of this KEP has been
# done. This can be the current (upcoming) milestone, if it is being actively
# worked on.
latest-milestone: "v1.23"
latest-milestone: "v1.25"

# The milestone at which this feature was, or is targeted to be, at each stage.
milestone:
alpha: "v1.22"
beta: "v1.23"
stable: TBD
stable: "v1.25"

# The following PRR answers are required at alpha release
# List the feature gate name and the components for which it must be enabled
feature-gates:
- name: PodSecurity
components:
- kube-apiserver (PodSecurity admission plugin)
disable-supported: true
disable-supported: false

# The following PRR answers are required at beta release
metrics:
Expand Down