Bug 2100429 - [apiserver-auth] default SCC restricted allow volumes don't have "ephemeral" caused deployment with Generic Ephemeral Volumes stuck at Pending
Summary: [apiserver-auth] default SCC restricted allow volumes don't have "ephemeral" ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Storage
Version: 4.11
Hardware: All
OS: All
high
high
Target Milestone: ---
: 4.13.0
Assignee: Jan Safranek
QA Contact: Penghao Wang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-06-23 10:44 UTC by Penghao Wang
Modified: 2023-05-17 22:47 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-05-17 22:46:53 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift cluster-kube-apiserver-operator pull 1380 0 None open Bug 2100429: Allow ephemeral volumes in all SCCs 2022-09-30 16:22:53 UTC
Red Hat Product Errata RHSA-2023:1326 0 None None None 2023-05-17 22:47:12 UTC

Comment 1 jackevans43 2022-08-19 14:12:07 UTC 
I had this in 4.10 - just needed to add ephemeral to the restricted SCC and then it worked. Or am I missing something?
Comment 10 david.gabrysch 2022-11-28 08:40:12 UTC 
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.
Comment 11 Jan Safranek 2022-11-28 09:44:35 UTC 
> 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.
Comment 12 david.gabrysch 2022-11-28 13:42:50 UTC 
(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?
Comment 14 Jan Safranek 2023-03-06 12:42:27 UTC 
Unfortunately, this cannot be backported to older releases. Updating existing SCCs manually (such as `restricted`) is an acceptable fix for this issue.
Comment 17 errata-xmlrpc 2023-05-17 22:46:53 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.