Closed l0rd closed 1 year ago
@l0rd do you know if the name
field in spec.devEnvironments.serviceAccountTokens
should be propagated to both the volume
and volumeMount
name in the pod spec?
For example, the given spec.devEnvironments.serviceAccountTokens
:
spec:
devEnvironments:
serviceAccountTokens:
- name: dev-token
mounthPath: /var/run/secrets/tokens
audience: openshift
expirationSeconds: 3600
would result in:
kind: Pod
(...)
spec:
(...)
containers:
(...)
volumeMounts:
- mountPath: /var/run/secrets/tokens
name: dev-token
volumes:
(...)
- name: dev-token
projected:
sources:
- serviceAccountToken:
path: dev-token
expirationSeconds: 3600
audience: openshift
This is the approach I'm currently taking, though perhaps the name fields should be generated based on the workspace ID, as we do for other areas of DWO.
@AObuchow yes, the serviceAccountToken name
should be used for:
spec.containers[].volumeMounts[].name
spec.volumes[].name
I don't think there is any reason we should use the workspaceid (i.e. 2 workspaces can have SA tokens with the same name).In my original proposal, in the serviceAccountToken
, we could not specify the path
, so I updated that. And I also clarified that the name
should be usd in both volumeMounts
and volume
sync'd to Red Hat JIRA https://issues.redhat.com/browse/CRW-4345
Is your enhancement related to a problem? Please describe
The default ServiceAccount token mounted in workspaces Pods:
This can be problematic in scenarios such as workload identity federation where the token audience needs to be specified.
Describe the solution you'd like
A new CheCluster
spec.devEnvironments.serviceAccountTokens
property:that, if set, will result in the workspaces pods specifying the corresponding service account token volumes projections: