Support ServiceAccount token volume projection

[l0rd]

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]

@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]

@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]

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

[devstudio-release]

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

• Support for ServiceAccount token projection devfile/devworkspace-operator#1065
• feat: configure DWOC ServiceAccount tokens from devEnvironments.serviceAccountTokens che-operator#1643