RFE: Namespace's sa.scc.uid-range should support a list of ranges
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 8.7k
- Forks
- 4.8k
- Avg merge
- 4d 10h
- Merged PRs (30d)
- 53
Description
A typical namespace:
kind: Namespace
metadata:
annotations:
openshift.io/sa.initialized-roles: "true"
openshift.io/sa.scc.mcs: s0:c1,c0
openshift.io/sa.scc.supplemental-groups: 1000000000/10000
openshift.io/sa.scc.uid-range: 1000000000/10000
...
My existing nfs export dir has an owner of 99 and GID of 5555. I want a non-root pod to access this nfs mount, so I add securityContext.runAsUser: 99 to my pod spec. But the pod fails with this error:
Error from server: error when creating "nfs-pod1.yaml": Pod "nfs-pod1" is forbidden: unable to validate against any security context constraint: [provider restricted: .spec.containers[0].securityContext.securityContext.runAsUser: invalid value '99', Details: UID on container nfs-busybox does not match required range. Found 99, required min: 1000000000 max: 1000009999]
Today, ignoring SCCs for the moment and just relying on the namespace's default IDs, I have to change the sa.scc.uid-range to something like 90/110 or 99-99 so that the runAsUser id is allowed.
IMO, a better approach is to support appending ",99-99" to the existing openshift.io/sa.scc.uid-range value, making UID ranges work the same as supplemental-groups. I expect that the code for supplemental-groups ranges can be leveraged to handle a list of user id ranges.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.