authentication: add enhancement on PSa autolabeling #1010
Conversation
enhancements/authentication/pod-security-admission-autolabeling.md
Outdated
Show resolved
Hide resolved
enhancements/authentication/pod-security-admission-autolabeling.md
Outdated
Show resolved
Hide resolved
enhancements/authentication/pod-security-admission-autolabeling.md
Outdated
Show resolved
Hide resolved
enhancements/authentication/pod-security-admission-autolabeling.md
Outdated
Show resolved
Hide resolved
enhancements/authentication/pod-security-admission-autolabeling.md
Outdated
Show resolved
Hide resolved
enhancements/authentication/pod-security-admission-autolabeling.md
Outdated
Show resolved
Hide resolved
enhancements/authentication/pod-security-admission-autolabeling.md
Outdated
Show resolved
Hide resolved
| mechanism is left to privileged users only and the workloads of the rest | ||
| of the users keeps working. | ||
|
|
||
| Simply updating the `Project` template is not enough to keep older workloads |
There was a problem hiding this comment.
This is critical information that you should start with.
There was a problem hiding this comment.
I'd suggest framing the proposal such that it's clear that this will be done in 2 stages, where:
- stage 1 (n-1) - introduce this functionality mode in non-breaking mode
- stage 2 (n) - introduce this in breaking mode
is that accurate or am I misreading something?
There was a problem hiding this comment.
Additionally, I'm missing answers to the following:
- I'm a current SCC user how that impacts me?
- I haven't used SCC in the past and I don't care, does this impacts me?
- I want to use PS over SCC how do I do that?
Not sure if I missed something else, but it would be good to describe different options.
enhancements/authentication/pod-security-admission-autolabeling.md
Outdated
Show resolved
Hide resolved
enhancements/authentication/pod-security-admission-autolabeling.md
Outdated
Show resolved
Hide resolved
enhancements/authentication/pod-security-admission-autolabeling.md
Outdated
Show resolved
Hide resolved
| In order to be able to map SCCs to PSa level automatically, it is necessary to | ||
| introspect each field of such an SCC. | ||
|
|
||
| SCC fields each tell the SCC authorizer how to either: |
There was a problem hiding this comment.
Have you written this mapping down somewhere?
There was a problem hiding this comment.
I've got a small PoC which shows some SCC shortcomings that need to be addressed (see FIXMEs in that project): https://github.com/stlaz/sccpsaconversion
There was a problem hiding this comment.
I think describing this mapping here is worthwhile.
There was a problem hiding this comment.
I'm going to open a follow-up PR for that
|
I like the design. It's straightforward |
stlaz
force-pushed
the
scc_psp
branch
4 times, most recently
from
73cd1a8
to
c191e48
Compare
|
|
||
| ### Open Questions | ||
|
|
||
| 1. Should we have a way to completely disable SCC admission per namespace |
There was a problem hiding this comment.
I think we can worry about this at a later date.
|
|
||
| ### Test Plan | ||
|
|
||
| The tests shall include these scenarios: |
There was a problem hiding this comment.
make sure you include checking the build tests for each build strategy.
|
Inactive enhancement proposals go stale after 28d of inactivity. See https://github.com/openshift/enhancements#life-cycle for details. Mark the proposal as fresh by commenting If this proposal is safe to close now please do so with /lifecycle stale |
openshift-ci
bot
added
the
lifecycle/stale
|
/remove-lifecycle stale |
openshift-ci
bot
removed
the
lifecycle/stale
|
@deads2k @s-urbaniak I added a paragraph on how the controller evaluates roles in order to determine access of SAs to SCCs. |
|
This is still missing the details about how given an SCC, a pod security label value is chosen. How about starting with the default list SCCs and where they map and then handle every SCC field and how it impacts the pod security label value. |
This is critical for determining if the plan laid out here will work. As I recall, while determining this, you hit a snag. |
A couple. The seccomp profiles are already fixed (openshift/kubernetes#1218), and it seems that we've been able to drop "ALL" capabilities for some time, only we never enforced that. The next issue is that with our default SCCs, there is not a single one that would map to restricted, we are "baseline" at best. We'll want to address that. I can include the SCC mapping and its caveats in this PR, then. |
|
Added more information on the SCC->PSa level mapping, the new sections also debate caveats and points of interest of the method used. |
| workload would break by this step because most of the platform users very likely just | ||
| went with the platform defaults and did not perform further steps in order to | ||
| tighten their workloads to their actual needs. To solve this issue, new | ||
| `*-v2` (e.g. `restricted-v2`, `nonroot-v2`) SCCs with tighter security policies |
There was a problem hiding this comment.
My first blush opinion is that this is ok.
| tighten their workloads to their actual needs. To solve this issue, new | ||
| `*-v2` (e.g. `restricted-v2`, `nonroot-v2`) SCCs with tighter security policies | ||
| should be introduced for the `restricted` SCC and SCCs derived from it. The `restricted` | ||
| SCC will also drop `system:authenticated` from its `Groups` field in favour of adding |
There was a problem hiding this comment.
only for new installs, correct?
There was a problem hiding this comment.
Yes, we should not backport this change. Since the current SCCs are create-only, changing this in the CKAO manifests won't perform any changes to the current SCC on an upgraded cluster.
|
/lgtm |
|
/lgtm |
|
/lgtm |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mfojtik 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 |
openshift-ci
bot
added
the
approved
|
@stlaz: all tests passed! Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
|
/lgtm |
Introduces the controller to synchronize Pod Security admission labels on namespaces.
/assign @s-urbaniak
/cc @soltysh
/cc @deads2k
/cc @openshift/openshift-team-auth-maintainers