scc in Openshift

[hanakric]

Hi,
 
there is a problem in scc on Openshift . In scc is setup:

runAsUser:
  type: MustRunAsRange

 
but without uidRange. In my opinion the better code is:

runAsUser:
  type: MustRunAsRange
  uidRangeMax: 4096
  uidRangeMin: 4096

 
without uidRange pods are not created, because user 4096 is not from namespace range
    openshift.io/sa.scc.uid-range: 1002...
 

[aandryashin]

It is openshift policy and ihmo cannot be overiden abd set to 4096, you have to set user id from allowed range in moon config. ср, 19 февр. 2025 г., 12:10 hanakric ***@***.***>:

…

Hi, there is a problem in scc on Openshift . In scc is setup: runAsUser: type: MustRunAsRange but without uidRange. In my opinion the better code is: runAsUser: type: MustRunAsRange uidRangeMax: 4096 uidRangeMin: 4096 without uidRange pods are not created, because user 4096 is not from namespace range openshift.io/sa.scc.uid-range: 1002... — Reply to this email directly, view it on GitHub <#277>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKY23M3VWOY3CKWPSTMUHL2QRDAPAVCNFSM6AAAAABXNUQNQ2VHI2DSMVQWIX3LMV43ASLTON2WKOZSHA3DENRYGM2DSNI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> [image: hanakric]*hanakric* created an issue (aerokube/charts#277) <#277> Hi, there is a problem in scc on Openshift . In scc is setup: runAsUser: type: MustRunAsRange but without uidRange. In my opinion the better code is: runAsUser: type: MustRunAsRange uidRangeMax: 4096 uidRangeMin: 4096 without uidRange pods are not created, because user 4096 is not from namespace range openshift.io/sa.scc.uid-range: 1002... — Reply to this email directly, view it on GitHub <#277>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKY23M3VWOY3CKWPSTMUHL2QRDAPAVCNFSM6AAAAABXNUQNQ2VHI2DSMVQWIX3LMV43ASLTON2WKOZSHA3DENRYGM2DSNI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[bukovjanmic]

Openshift by default assigns a random range for UIDs (e.g. 10002001) for each namespace.

However, most browser images that we tested will not run under any other UID than 4096, because browser in the pods create some temporary data in overlay on the image file system and will fail if the directory in the image is not writable.

Therefore, we need to set user.id and group.id in Config object to 4096.

However, the moon SCC policy that is assigned will not allow to run the Pods under those UID, as hanakric points out, so we need to manually patch the Moon SCC with the above.

There are 3 solution to this:

1. Do what hanakric suggests and specifiy uidrangeMin and uidRangeMax in moon SCC. These need not be new values in values.yaml, we can just use the values of user.id (and group.id) respectively
2. Even better, we can use MustRunAs directly, as moon.aerokube.com/Config allows to specify only single value anyway (likewise for groupFS)
3. Alternatively, we could use MustRunAsNonroot or MustRunAsAny, but this is presumably less secure. Maybe this could be a fallbcak if no user.id or group.id is specified in values.yaml when installing the Helm chart.

[aandryashin]

We will consider that and update you. ср, 19 февр. 2025 г., 17:24 bukovjanmic ***@***.***>:

…

Openshift by default assigns a random range for UIDs (e.g. 10002001) for each namespace. However, most browser images that we tested will not run under any other UID than 4096, because browser in the pods create some temporary data in overlay on the image file system and will fail if the directory in the image is not writable. Therefore, we need to set user.id and group.id in Config object to 4096. However, the moon SCC policy that is assigned will not allow to run the Pods under those UID, as hanakric points out, so we need to manually patch the Moon SCC with the above. There are 3 solution to this: 1. Do what hanakric suggests and specifiy uidrangeMin and uidRangeMax in moon SCC. These need not be new values in values.yaml, we can just use the values of user.id (and group.id) respectively 2. Even better, we can use MustRunAs directly, as moon.aerokube.com/Config allows to specify only single value anyway (likewise for groupFS) 3. Alternatively, we could use MustRunAsNonroot or MustRunAsAny, but this is presumably less secure. Maybe this could be a fallbcak if no user.id or group.id is specified in values.yaml when installing the Helm chart. — Reply to this email directly, view it on GitHub <#277 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKY23JD6POHKXR2RHU5IXD2QSHZPAVCNFSM6AAAAABXNUQNQ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNRYHAYDMOJZHA> . You are receiving this because you commented.Message ID: ***@***.***> [image: bukovjanmic]*bukovjanmic* left a comment (aerokube/charts#277) <#277 (comment)> Openshift by default assigns a random range for UIDs (e.g. 10002001) for each namespace. However, most browser images that we tested will not run under any other UID than 4096, because browser in the pods create some temporary data in overlay on the image file system and will fail if the directory in the image is not writable. Therefore, we need to set user.id and group.id in Config object to 4096. However, the moon SCC policy that is assigned will not allow to run the Pods under those UID, as hanakric points out, so we need to manually patch the Moon SCC with the above. There are 3 solution to this: 1. Do what hanakric suggests and specifiy uidrangeMin and uidRangeMax in moon SCC. These need not be new values in values.yaml, we can just use the values of user.id (and group.id) respectively 2. Even better, we can use MustRunAs directly, as moon.aerokube.com/Config allows to specify only single value anyway (likewise for groupFS) 3. Alternatively, we could use MustRunAsNonroot or MustRunAsAny, but this is presumably less secure. Maybe this could be a fallbcak if no user.id or group.id is specified in values.yaml when installing the Helm chart. — Reply to this email directly, view it on GitHub <#277 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKY23JD6POHKXR2RHU5IXD2QSHZPAVCNFSM6AAAAABXNUQNQ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNRYHAYDMOJZHA> . You are receiving this because you commented.Message ID: ***@***.***>

[aandryashin]

Are these changes are you asking? #279 ср, 19 февр. 2025 г. в 22:53, Alexander Andryashin ***@***.***>:

…

We will consider that and update you. ср, 19 февр. 2025 г., 17:24 bukovjanmic ***@***.***>: > Openshift by default assigns a random range for UIDs (e.g. 10002001) for > each namespace. > > However, most browser images that we tested will not run under any other > UID than 4096, because browser in the pods create some temporary data in > overlay on the image file system and will fail if the directory in the > image is not writable. > > Therefore, we need to set user.id and group.id in Config object to 4096. > > However, the moon SCC policy that is assigned will not allow to run the > Pods under those UID, as hanakric points out, so we need to manually patch > the Moon SCC with the above. > > There are 3 solution to this: > > 1. Do what hanakric suggests and specifiy uidrangeMin and uidRangeMax > in moon SCC. These need not be new values in values.yaml, we can just use > the values of user.id (and group.id) respectively > 2. Even better, we can use MustRunAs directly, as > moon.aerokube.com/Config allows to specify only single value anyway > (likewise for groupFS) > 3. Alternatively, we could use MustRunAsNonroot or MustRunAsAny, but > this is presumably less secure. Maybe this could be a fallbcak if no > user.id or group.id is specified in values.yaml when installing the > Helm chart. > > — > Reply to this email directly, view it on GitHub > <#277 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAKY23JD6POHKXR2RHU5IXD2QSHZPAVCNFSM6AAAAABXNUQNQ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNRYHAYDMOJZHA> > . > You are receiving this because you commented.Message ID: > ***@***.***> > [image: bukovjanmic]*bukovjanmic* left a comment (aerokube/charts#277) > <#277 (comment)> > > Openshift by default assigns a random range for UIDs (e.g. 10002001) for > each namespace. > > However, most browser images that we tested will not run under any other > UID than 4096, because browser in the pods create some temporary data in > overlay on the image file system and will fail if the directory in the > image is not writable. > > Therefore, we need to set user.id and group.id in Config object to 4096. > > However, the moon SCC policy that is assigned will not allow to run the > Pods under those UID, as hanakric points out, so we need to manually patch > the Moon SCC with the above. > > There are 3 solution to this: > > 1. Do what hanakric suggests and specifiy uidrangeMin and uidRangeMax > in moon SCC. These need not be new values in values.yaml, we can just use > the values of user.id (and group.id) respectively > 2. Even better, we can use MustRunAs directly, as > moon.aerokube.com/Config allows to specify only single value anyway > (likewise for groupFS) > 3. Alternatively, we could use MustRunAsNonroot or MustRunAsAny, but > this is presumably less secure. Maybe this could be a fallbcak if no > user.id or group.id is specified in values.yaml when installing the > Helm chart. > > — > Reply to this email directly, view it on GitHub > <#277 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAKY23JD6POHKXR2RHU5IXD2QSHZPAVCNFSM6AAAAABXNUQNQ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNRYHAYDMOJZHA> > . > You are receiving this because you commented.Message ID: > ***@***.***> >

[bukovjanmic]

Yes, this should work for us;

• there is a typo on l. 36 in scc.yaml - uidRangeMax should be uidRangeMin
• maybe you could reuse .Values.configs.default.user.id, as it should be always the same value - if not, it will not work anyway.

[aandryashin]

Will check. чт, 20 февр. 2025 г., 15:02 bukovjanmic ***@***.***>:

…

Yes, this should work for us; - there is a typo on l. 36 in scc.yaml - uidRangeMax should be uidRangeMin - maybe you could reuse .Values.configs.default.user.id, as it should be always the same value - if not, it will not work anyway. — Reply to this email directly, view it on GitHub <#277 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKY23KV3QL2R5O56DXP6B32QW75XAVCNFSM6AAAAABXNUQNQ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZRGI4TOMRTHA> . You are receiving this because you commented.Message ID: ***@***.***> [image: bukovjanmic]*bukovjanmic* left a comment (aerokube/charts#277) <#277 (comment)> Yes, this should work for us; - there is a typo on l. 36 in scc.yaml - uidRangeMax should be uidRangeMin - maybe you could reuse .Values.configs.default.user.id, as it should be always the same value - if not, it will not work anyway. — Reply to this email directly, view it on GitHub <#277 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKY23KV3QL2R5O56DXP6B32QW75XAVCNFSM6AAAAABXNUQNQ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZRGI4TOMRTHA> . You are receiving this because you commented.Message ID: ***@***.***>