ability to set automountServiceAccountToken to false

[EliranTurgeman]

What problem are you trying to solve?

To Meet Security Standards for not automatically mounting service accounts
for compliance in Gov Clouds
Note: That the service account token can be mounted manually as a volume

How should the problem be solved?

Helm Chart should, by default, set automountServiceAccountToken to true for all Linkerd Pods (to not change the current behavior)
but will have the option to change it to "false"

Any alternatives you've considered?

None; it's part of compliance tasks
https://learn.microsoft.com/en-us/azure/governance/policy/samples/built-in-policies
https://www.azadvertizer.net/azpolicyadvertizer/kubernetes_block-automount-token.html

How would users interact with this feature?

Set it to true in the helm chart for LInkerd to harden the security of the cluster to

Would you like to work on this feature?

maybe

[alpeb]

The pod's in linkerd's control plane require that token in order to connect to the kube-api, as do the proxies in the data plane in order to bootstrap their identity. If mounting those is disabled, I understand they could be mounted manually, but how would you get them? Retrieving them from the SA's secrets? Can you clarify what would the process be and what's the benefit of doing that manually? Wouldn't this be applicable only for those cases where the token is not used?

[EliranTurgeman]

The main reason we want this feature is to mount the same staff that auto mount needed, so the behavior will remain

This will help in terms of security, since the mounting are explicitly set and its help to avoid any malicious attacks by this section

As said before the want to be in compliance with some FedRamp regulations and this is one of them

[olix0r]

Can you elaborate on what you mean by:

Note: That the service account token can be mounted manually as a volume

Are you asking that the Linkerd helm charts do this? If so, would it make sense to simply always use a projected volume without adding new configuration?

Or are you suggesting that the helm chart should leave control plane components with no kube api token and you'd like to handle volume mounting yourself?

[Aransh]

@olix0r the standard approach we've seen with other charts is to allow disabling automountServiceAccountToken, and allow adding additional volumes and volumeMounts, and by that add a projected volume for the service account token.

This basically has the same exact outcome, but for government cloud compliance purposes, this would pass validation as it's more explicit ("This pod needs Kube API access to function, so it is supplied directly", as opposed to "This pod has Kube API access coincidentally as this is default behavior, leaving it potentially vulnerable").

Example:

automountServiceAccountToken: false
volumes:
 - name: kube-api-access
   projected:
     defaultMode: 420
     sources:
     - serviceAccountToken:
         expirationSeconds: 3607
         path: token
     - configMap:
         items:
         - key: ca.crt
           path: ca.crt
         name: kube-root-ca.crt
     - downwardAPI:
         items:
         - fieldRef:
             apiVersion: v1
             fieldPath: metadata.namespace
           path: namespace
 volumeMounts:
 - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
   name: kube-api-access
   readOnly: true

[olix0r]

Is it a viable solution for Linkerd to simply always disable automountServiceAccountToken and to update the charts to include the required projected volumes?

It substantially increases the maintenance and support burden for us to make our helm charts needlessly generic, so it's preferable if we can just update the charts to use the most robust broadly-viable configuration.

I understand the general need to avoid automountServiceAccountToken; but what parameters do you actually need to be configurable as an operator?

[Aransh]

I suppose that'll do, yes

[EliranTurgeman]

@olix0r
Do you know if we have a decision here?

In the end, our goal is to have the option to mount the volume explicitly rather than automatically, as it is today.
The implementation approach only matters a little. We are okay with anything implementation that will make it happen

Thank you so much!

[olix0r]

Given that token projection has been stable since Kubernetes 1.20, I think we'd accept a PR that implements the change I described. Otherwise, this enhancement will be added to our unprioritized backlog and we'll get to it as time permits.

[Aransh]

@olix0r Opened PR for this change - #13186
From my tests all is working as expected 😁

Basically I disabled automountServiceAccountToken, and then mounted the projected volume on each container that was failing since it wasn't able to connect to kube API (which was basically all containers except the init containers)