Introduce support for Projected Volumes kubernetes ServiceAccount Tokens

[JJotah]

Add support for Projected Volumes kubernetes ServiceAccount Tokens. In some cloud providers we can't change the expiration token and linkerd is adding the projected volumes. So the install-cni should watch like istio did checking the serviceaccount token

[wmorgan]

Thanks @JJotah , we will take a look.

[alpeb]

Fixes linkerd/linkerd2#12573

[alpeb]

I did some more research on this, thinking it's been a while since k8s injects projected kube-api-access volumes, so why is linkerd-cni still working past the token expiration (1 hour by default)? Inspecting the linkerd-cni pod we see the injected volume:

  - name: kube-api-access-729gv
    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

I could also observe how the token file got indeed recycled every hour. But actually inspecting those tokens revealed they're good for one year! So even if the token file gets renewed, linkerd-cni keeps on using the first one, which will continue to be valid. Turns out the reason is kube-api's flag --service-account-extend-token-expiration:

Turns on projected service account expiration extension during token generation, which helps safe transition from legacy token to bound service account token feature. If this flag is enabled, admission injected tokens would be extended up to 1 year to prevent unexpected failure during transition, ignoring value of service-account-max-token-expiration.

This flag still shows as default true in the docs, which explains the above. But obviously we can't rely on that, thus the importance of this PR.

[alpeb]

Superseded by #440