Getting
spec.securityContext.supplementalGroups: Invalid value: []int64{}: unable to validate empty groups against required ranges
on single user pod deployment by kubespawner with pod security policy.
Have not set anything related in the values.yaml.
The reason seems to be this is generated in the pod spec:
‘security_context’: {‘fsGroup’: 100, ‘supplementalGroups’: []},
but I have no idea where the second part comes from, looks fine here
# | - | windowsOptions | Pod and Container |
#
# ref: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
# ref: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.20/#securitycontext-v1-core (container)
# ref: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.20/#podsecuritycontext-v1-core (pod)
#
psc = {}
# populate with fs_gid / supplemental_gids
if fs_gid is not None:
psc["fsGroup"] = int(fs_gid)
if supplemental_gids is not None:
psc["supplementalGroups"] = [int(gid) for gid in supplemental_gids]
if pod_security_context is not None:
for key in pod_security_context.keys():
if "_" in key:
raise ValueError(
f"pod_security_context's keys should have k8s camelCase names, got '{key}'"
)
psc.update(pod_security_context)
if not psc:
psc = None
Anyone an idea where this comes from or why it changed with 1.0.0 ?
Edit:
seems to come from this change -
jupyterhub:master
← cyrilcros:security_context_dict
opened 03:34PM - 03 Feb 21 UTC
This PR adds `container_security_context` and `pod_security_context` configurati… on options.
__Old vs new options__
The new options `container_security_context` and `pod_security_context` updates the partial security contexts built from the following older options:
- `supplemental_gids` (pod)
- `fs_gid` (pod)
- `privileged` (container)
- `allow_privilege_escalation` (container)
- `uid` (container)
- `gid` (container).
__Related__
Fixes #454 - pod/container security contexts can now be configured
Related to #478 - exposes fsGroupChangePolicy through pod security context, but doesn't provide a default value.
supplemental_gids must be [] instead of None - but dont see why … well, maybe thats just how the traitlet init works …
Have logged it as an issue on KubeSpawner :
opened 10:09AM - 19 Jun 21 UTC
bug
### Bug description
psc["supplementalGroups"] gets a default value of [] instea… d of None since this change :
https://github.com/jupyterhub/kubespawner/pull/480/files.
This conflicts with clusters having pod security policies, see here for more background:
https://discourse.jupyter.org/t/singleuser-pod-fails-after-1-0-0-upgrade-on-supplementarygroups-with-psp/9660
#### Expected behaviour
previous behaviour, supplementalGroups=None
### How to reproduce
Deploy z2jh 1.0.0 to cluster with psp's enabled.
### Your personal set up
z2jh 1.0.0 , no relevant entries in values.yaml
# paste relevant logs here, if any
```
Error on deployment:
spec.securityContext.supplementalGroups: Invalid value: []int64{}: unable to validate empty groups against required range
In log , deployment descriptor:
'security_context': {'fsGroup': 100, 'supplementalGroups': []},
( a workaround is to set c.KubeSpawner.supplemental_gids explicitly to eg [100])
Thanks,
Chris
Ah! This is a bug in KubeSpawner. It specifies supplementalGroups even if it is an empty list just because it checks not None
.
I’ll fix that in KubeSpawner and make it be part of z2jh 1.1.0.