I think you might be hitting this issue https://bugzilla.redhat.com/show_bug.cgi?id=1708202, a temporary workaround is just like you've noticed to create a copy of the SCC.
On Wed, Feb 12, 2020 at 10:49 AM Joel Pearson <japear...@agiledigital.com.au> wrote: > Hi Samuel, > > Thanks for pointing that out, didn't realise that privileged mode was a > kubernetes specific thing as opposed to an openshift thing. That'd explain > why it barely gets a passing reference in the docs. I found some > information on the kubernetes website: > https://kubernetes.io/docs/concepts/policy/pod-security-policy/#privileged > > The cluster I was trying this out on is a lab cluster that only I use, but > thanks for the tip about being careful copying scc's. > > Thanks, > > Joel > > On Wed, 12 Feb 2020 at 20:37, Samuel Martín Moro <faus...@gmail.com> > wrote: > >> Hi, >> >> >> In addition to granting your ServiceAccount with permissions to use the >> privileged SCC, you should add some securityContext.privileged: true to >> your Pod definition. Otherwise, the restricted SCC first matches your Pod >> securityContext, privileged would not be considered. >> >> I couldn't find this in 4.x docs, though you'ld have it in 3.11: >> >> https://docs.openshift.com/container-platform/3.11/admin_guide/manage_scc.html#grant-a-service-account-access-to-the-privileged-scc >> >> >> Changing priorities could indeed be a way to work around this. >> Though probably not something to recommend. >> >> If you made a copy of the existing privileged SCC, then there's good >> chances you kept its lists of allowed users / groups. >> This means that when Pods relying on those SA would next restart, while >> not including a securityContext.privileged in their definition: they would >> mistakenly start as root. Rolling this back could require chowning files >> back on persistent volumes. >> >> While it is unlikely OpenShift core components would include >> ServiceAccounts running both privileged and unprivileged Pods (not >> certain/to check), it could still be a surprise for users in your cluster. >> This is not a big deal, on a lab, if you're just testing something on >> your own, ... though I would avoid this on real-life clusters, or warn >> other admins at least, ideally make sure only your Jira SA may use that SCC. >> >> >> Regards. >> >> >> On Wed, Feb 12, 2020 at 4:36 AM Joel Pearson < >> japear...@agiledigital.com.au> wrote: >> >>> Hi, >>> >>> I have been trying to use the privileged scc in OpenShift 4.2.16 >>> >>> I follow the normal way adding an scc to a service account. >>> >>> oc create sa jira >>> oc adm policy add-scc-to-user privileged -z jira >>> >>> But it always ends up using the restricted scc. However, anyuid gets >>> applied successfully. >>> >>> I read about SCC prioritisation >>> <https://docs.openshift.com/container-platform/4.2/authentication/managing-security-context-constraints.html#scc-prioritization_configuring-internal-oauth> >>> and made >>> a copy of privileged scc and set "priority: 10", and then I was able to use >>> it. >>> >>> What is the proper way to use the privileged scc? Or is this by design? >>> >>> PS. I realise using privileged is not recommended, and in my case to >>> make jira work I managed to use a customised version of anyuid that >>> contained the AUDIT_WRITE capability so that "su" would work. However, I >>> figured it would be good to know why privileged kept getting overridden by >>> "restricted" >>> >>> Thanks, >>> >>> Joel >>> _______________________________________________ >>> users mailing list >>> users@lists.openshift.redhat.com >>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users >>> >> >> >> -- >> Samuel Martín Moro >> {EPITECH.} 2011 >> >> "Nobody wants to say how this works. >> Maybe nobody knows ..." >> Xorg.conf(5) >> > > > _______________________________________________ > users mailing list > users@lists.openshift.redhat.com > http://lists.openshift.redhat.com/openshiftmm/listinfo/users >
_______________________________________________ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
