-
Notifications
You must be signed in to change notification settings - Fork 41.1k
Description
What happened?
We have a container which needs to start as root today (because we install packages, mount a docker socket and the like). But then we change uid to a lower privilege user for the rest of time.
That user needs access to a projected serviceAccountToken to access another service. The user cannot read the file because its mode is rw-------.
So, we set defaultMode on the projected volume definition, but this has no effect.
We also had readOnly: true in the mount definition, and that seems to not have effect either, as the mode was still rw------- not r--------.
Sample Pod definitions
apiVersion: v1
kind: Pod
metadata:
name: with-mode
namespace: robertc-scratch
spec:
containers:
- command:
- sleep
- "604800"
image: ubuntu
imagePullPolicy: IfNotPresent
name: test
securityContext:
allowPrivilegeEscalation: false
runAsUser: 0
volumeMounts:
- mountPath: /secrets/token
name: token
volumes:
- name: token
projected:
defaultMode: 292
sources:
- serviceAccountToken:
path: token
---
apiVersion: v1
kind: Pod
metadata:
name: with-readonly
namespace: robertc-scratch
spec:
containers:
- command:
- sleep
- "604800"
image: ubuntu
imagePullPolicy: IfNotPresent
name: test
securityContext:
allowPrivilegeEscalation: false
runAsUser: 0
volumeMounts:
- mountPath: /secrets/token
name: token
readOnly: true
volumes:
- name: token
projected:
sources:
- serviceAccountToken:
path: token
The test I did in making a SSCCE was to run this:
kubectl --namespace robertc-scratch exec -ti with-mode -- ls -l /secrets/token/..data/
total 4
-rw------- 1 root root 1414 Jan 3 17:45 token
@rbtcollins ➜ /workspaces/infrastructure (rbt/agent-permissions-3) $ kubectl --namespace robertc-scratch exec -ti with-mode -- ls -l /secrets/token/..data/
total 4
-rw------- 1 root root 1414 Jan 3 17:45 token
We checked the documentation and it describes defaultMode with no restrictions on its relevance to difference sources. The API reference is no more useful.
What did you expect to happen?
I expected the defaultMode setting to apply to the serviceAccountToken. All the same reasons one might want a different mode for a projected secret or config map also apply to a projected serviceAccountToken.
How can we reproduce it (as minimally and precisely as possible)?
See above.
Anything else we need to know?
Probably not ;) .
Kubernetes version
$ kubectl version
Client Version: v1.27.16
Kustomize Version: v5.0.1
Server Version: v1.30.5-gke.1699000
Cloud provider
OS version
I don't have access to the node OS itself, sorry.