https://docs.openshift.com/container-platform/4.3/authentication/managing-security-context-constraints.html * There isn't an example of using the role for which the creation is described * We lost the example of setting SCCs for SAs (see OCP3: https://docs.openshift.com/container-platform/3.6/admin_guide/manage_scc.html#how-do-i) * There isn't a good example of setting a pod to run as a specific SCC anywhere
@Maru Newby also shared this blog post [1], which contains some additional helpful information to consider including in the product docs. [1] https://www.openshift.com/blog/introduction-to-security-contexts-and-sccs
Customer case input: Customer Ford (case id 02659139) ran into some SCC issues and requested SCC docs to be improved with respect to the following. 1. While troubleshooting the issue and trying to reproduce, it was not clear from the docs that the fsGroup is not part of the SCC restrictiveness criteria and that led to some confusion. 2. Also, our suggestion to the customer to resolve the issue is as described in the blog that Maru shared above. i.e list the required capabilities in the POD definition and not worry about the named SCC. Customer commented that this is not captured in openshift docs and wanted it to be reflected in the docs officially. 3. The customer kept thinking that the SCC linked to SA will be the SCC that a pod will get and it is not clear from the docs that despite linking, OCP at runtime selects the most restrictive SCC policy
Hi Andrea Customer "Ford" is asking when this doc issue would be fixed. Any tentative timeline we can project? thanks Anand
WIP PR: https://github.com/openshift/openshift-docs/pull/24247 Preview: https://bz-1830392--ocpdocs.netlify.app/openshift-enterprise/latest/authentication/managing-security-context-constraints.html Initial improvements started in above PR; still more that we want to add.
We could also use some documentation on how to change the cluster default SCC.
Hi Erik - I asked engineering about this and they said that you can't change the default SCC for the cluster.
Sounds like we need a tremendous amount of additional documentation that helps customers understand how to affect the default behaviors, then. If the default SCC is restricted and you can't change the default SCC to be something else, and you aren't supposed to edit the shipped SCCs, how do you ensure that the "default" behavior when someone simply runs `oc new-app foo` ends up doing the right thing?
@andrea, I think what Erik was going for in https://bugzilla.redhat.com/show_bug.cgi?id=1830392#c5 is documentation that makes it clear to a customer what steps are required in order to configure the cluster so that SCC custom-foo is automatically assigned to every workload deployed on the cluster. Or, at a minimum, all the workloads that would otherwise have gotten the restricted SCC. The first step would be to create the custom SCC. After that, would the user need to set the priority to 10 in order to not override the anyuid SCC selection when running with an admin role? Or, would it be better to set the priority higher? Would the user need to bind that SCC to all non-admin users?
Thanks @Kirsten, that's helpful. I'll go back and will have another chat on this.
Andrea - Is this bug fixed? Is the bug fix required in 4.7.z+ versions? If yes, then please make the required changes in the doc, else, please close this bug at the earliest. Thank you!
Sorry for the delay Latha. I did incorporate a lot of the changes from that old PR into a newer PR and merged that last year: https://github.com/openshift/openshift-docs/pull/30617 Let me connect with the auth team again to look into whether we can add docs for changing the default SCC used by the cluster.
The move of all the control plane and infrastructure binaries into pods that are actually running in the cluster made the platform very sensitive to changes in SCCs and we've been seeing that for the couple years 4.x exists. We are planning on improving the situation in a future release, but until then I would rather not document how to replace the "default" SCC in the cluster as that might cause the platform instability.
Thanks Standa! Based on Standa's comment above, I am closing this BZ as WONTFIX.