Reputation: 2982
I am trying to create a statefulset that runs zookeper, but I want it to run as non-root (i.e. under the zookeper user).
This is the image used for this:
https://github.com/kubernetes-retired/contrib/blob/master/statefulsets/zookeeper/Dockerfile
This is how I am trying to mount the volumes (Apparently I need a init container according to this):
initContainers:
# Changes username for volumes
- name: changes-username
image: busybox
command:
- /bin/sh
- -c
- |
chown -R 1000:1000 /var/lib/zookeeper /etc/zookeeper-conf # <<<<--- this returns
# cannot change ownership, permission denied
# read-only filesystem.
containers:
- name: zookeeper
imagePullPolicy: IfNotPresent
image: my-repo/k8szk:3.4.14
command:
- sh
- -c
- |
zkGenConfig.sh # The script right here requires /var/lib/zookeper to be owned by zookeper user.
# Initially zookeeper user does own it as per the dockerfile above,
# but when mounting the volume, the directory becomes owned by root
# hence the script fails.
volumeMounts:
- name: zk-data
mountPath: /var/lib/zookeeper
- name: zk-log4j-config
mountPath: /etc/zookeeper-conf
I also tried to add the securityContext: fsGroup: 1000
with no change.
Upvotes: 6
Views: 8990
Reputation: 1112
This can be configured using the security context, e.g.
securityContext:
runAsUser: 1000
runAsGroup: 1000
fsGroup: 1000
Then you don't need the initContainer at all - Kubernetes will handle the recursive chown as part of making the volume ready.
One issue here is the Dockerfile linked doesn't container a USER
statement, so Kubernetes doesn't know to start the pod as the correct user - the runAsUser
will fix that.
The reason the initContainer
hack you're trying isn't working is because you're also trying to change the ownership of the read-only config directory. ConfigMaps are mounted read-only, you can't chown them. (This used to be different, but was changed for security reasons)
Upvotes: 12