I had this in 4.10 - just needed to add ephemeral to the restricted SCC and then it worked. Or am I missing something?
We have this in 4.11.7 simply extending the default restricted SCC does not sound like a good solution since this can be overriden with a cluster update.
> We have this in 4.11.7 simply extending the default restricted SCC does not sound like a good solution since this can be overriden with a cluster update. OCP does not touch SCCs during upgrade and your changes should not be overwritten (at least in 4.0-4.12). We might add some logic to "merge" SCC fixes like this during a cluster upgrade, but it's hard to tell that a SCC misses a permission because cluster admin did not care or cluster admin explicitly does not want the permission in their cluster. If this is ever implemented, it will be definitely announced by a release note.
(In reply to Jan Safranek from comment #11) > > We have this in 4.11.7 simply extending the default restricted SCC does not sound like a good solution since this can be overriden with a cluster update. > > OCP does not touch SCCs during upgrade and your changes should not be > overwritten (at least in 4.0-4.12). We might add some logic to "merge" SCC > fixes like this during a cluster upgrade, but it's hard to tell that a SCC > misses a permission because cluster admin did not care or cluster admin > explicitly does not want the permission in their cluster. If this is ever > implemented, it will be definitely announced by a release note. Sounds reasonable. Can adding "ephemeral" to the volumes section of the default "restricted" SCC be seen as a valid / supported workaround for this issue?
Unfortunately, this cannot be backported to older releases. Updating existing SCCs manually (such as `restricted`) is an acceptable fix for this issue.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Important: OpenShift Container Platform 4.13.0 security update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2023:1326
@Jan you were saying > We'll backport it to 4.12 shortly, 4.11 might be a good candidate too, however, it will fix only new OCP installations. Customers need update their SCCs manually in existing clusters, because OCP does not sync SCCs during cluster upgrade. However the KB article at https://access.redhat.com/articles/6967808 only recommends to create a *new* SCC allowing the ephemeral volume mount and *not allowing* the system:authenticated virtual group to use the new scc, which is orthogonal to your recommandation. Can you confirm it is that now considered safe to update the built-in openshift SCCs manually for existing clusters, using your patch in https://github.com/openshift/cluster-kube-apiserver-operator/pull/1380/files as the basis of what to do ? If yes we should then update the KB article at https://access.redhat.com/solutions/6967807 to reflect that.
Yes, it is safe to update the built-in SCCs. There were plans to sync SCCs during OCP upgrade, so they would get new permissions, and that would overwrite any user changes. Since the sync was not implemented (yet?) *and* it would only add permissions to use ephemeral volumes, it's safe in this case. In general case, custom SCCs are better.
BTW, would you be willing to update the KCS? I am not sure about OSD note there.