Support ServiceAccount token volume projection

eclipse-che / che

Kubernetes based Cloud Development Environments for Enterprise Teams

http://eclipse.org/che

Eclipse Public License 2.0

6.99k stars 1.19k forks source link

Support ServiceAccount token volume projection #22012

Closed l0rd closed 1 year ago

l0rd commented 1 year ago

Is your enhancement related to a problem? Please describe

The default ServiceAccount token mounted in workspaces Pods:

doesn't have an audience set
is always mounted under the same path
has an hardcoded expirationSeconds

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:

spec:
  devEnvironments:
    serviceAccountTokens:
      - name: <name>
        mounthPath: <mount-path>
        audience: <audience>
        expirationSeconds: <expiration>
        path: <path>

that, if set, will result in the workspaces pods specifying the corresponding service account token volumes projections:

kind: Pod
(...)
spec:
(...)
  containers:
    (...)
    volumeMounts:
    - mountPath: <mount-path>
      name: <name>
  volumes:
  (...)
  - name: <name>
    projected:
      sources:
      - serviceAccountToken:
          path: <path>
          expirationSeconds: <expiration>
          audience: <audience>

AObuchow commented 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.

l0rd commented 1 year ago

@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

max-cx commented 1 year ago

sync'd to Red Hat JIRA https://issues.redhat.com/browse/CRW-4345

devstudio-release commented 1 year ago

sync'd to Red Hat JIRA https://issues.redhat.com/browse/CRW-4345