1. Proposed title of this feature request

Addition of a new, default SCC that is more restricted than "restricted".

2. What is the nature and description of the request?

Presently, the "restricted" SCC is provided by default as the most restrictive of the SCCs that ship with OpenShift.

Due perhaps to mostly historical reasons (the common theme that gets mentioned is that it was needed for ping to work, though this is no longer true) this has "allowPrivilegeEscalation: true". Because of this, setuid binaries may run inside the container

However, due to allowPrivilegeEscalation being set to true, setuid binaries may run even in pods admitted via the restricted SCC.

My proposal for an enhancement is as follows:

• create a new SCC (I don't have a better name than "veryrestricted" or "restricted-nosetuid") with this disabled
• add this to the default SCCs available for non-administrative users. this step will be entirely non-breaking. Any workloads that can be admitted by "veryrestricted" will do so. The rest that were admitted by "restricted" in the past will continue to be admitted.
• option #1 - alert well in advance (2 or 3 OCP "y" releases?) and then remove "restricted" from the default RBAC for non administrative users
• option #2 - make a prominent mention in the docs of how cluster owners can do this directly. At the moment, any owners who wish to do so will need to perform all the steps, not just enable a feature.

3. Why does the customer need this? (List the business requirements here)

The customer may reasonably be confused into thinking that "restrictive" is actually the most restrictive available and only by delving into the specific details will they understand that a more restrictive SCC is possible, and probably suitable for a good majority of their workloads.

Due to the fact this will break existing workloads that depend on the functionality, we cannot just disable it again. However, with the upstream kube changes regarding the upcoming PSP Replacement (see https://github.com/kubernetes/enhancements/issues/2579) it may behoove us to co-ordinate with those changes in order to add some improvements in our own SCCs at a good time.

4. List any affected packages or components.

-

5. Additional Notes

(editing to add) I feel like if above (allowPrivilegeEscalation) is disabled, it could be mostly non-disruptive to user workloads. There is another flag in the SCC (readOnlyRootFilesystem) which from a best practice standpoint would be good to enable by default, but which I expect would be disruptive to any workloads not specifically adapted to take it into account (pid files, log files etc in /tmp or an emptyDir). As we give thought to changing allowPrivilegeEscalation I'd like to suggest we also keep readOnlyRootFilesystem in consideration. Even if it doesn't make sense to bundle them in the same change today, our roadmap should be consideration for doing them both.