В общем, если вдруг на кластер\namespace’s прилетела политика

automountServiceAccountToken: false

Этот параметр может быть установлен как в Pod’e, так и в Service Account’е

Это означает, что в поды с этой настройкой не будет прокидываться SA-токен. По умолчанию каждому поду цепляется SA (если не указан конкретный, прокидывается Default для NameSpace, где поднимается под) и его данные (собственно сам токен и ca.crt кластера) прокидываются в директорию /var/run/secrets/kubernetes.io/serviceaccount/

Эти credentials используются приложениями в pod’е для доступа к Kubernetes API.

Настройка параметра automountServiceAccountToken - хорошая практика в настройки безопасности кластера. Ибо зачем обычным приложениям доступ к Kubernetes API в их Pod'ах?

Так вот. Если эта политика включена по умолчанию, а вам нужен доступ к Kubernetes API нужно сделать следующее:

<aside> 💡 Первым делом - обратитесь к безам и запросите у них сделать исключение для вашего NameSpace или POD’а. Это самый быстрый и правильный способ, ибо то, что я опишу ниже - по факту продублирует логику, если выставить значение true для automountServiceAccountToken с небольшим улучшением

</aside>

1. Необходимо настроить RBAC с нужными нам правами. Например:

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: name-sa
     namespace: namespace
   automountServiceAccountToken: false
   
   ---
   apiVersion: v1
   kind: Secret
   metadata:
     name: name-sa-token
     namespace: namespace
     annotations:
       kubernetes.io/service-account.name: name-sa
   type: kubernetes.io/service-account-token
   
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: name-cr
     namespace: namespace
   rules:
   - apiGroups:
     - ""
     resources:
     - secrets
     - pods
     verbs:
     - get
     - list
     - watch
   
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: name-crb
     namespace: namespace
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: name-cr
   subjects:
   - kind: ServiceAccount
     name: name-sa
     namespace: namespace
   

   Обратите внимание, что мы явно создаем Secret для Service Account’a, в котором будут хранится ca.crt и token. (Дефолтный secret для SA тоже создатся, но его неудобно использовать, например в helm, т.к. мы не можем заранее знать его имя

2. Правильно маунтим созданные сущности в pod:

   spec:
     ...
     template:
       ...
       spec:
         automountServiceAccountToken: false
         containers:
         - ...
           volumeMounts:
           - mountPath: /var/run/secrets/kubernetes.io/serviceaccount/
             name: token-ca
         ...
         volumes:
         - name: token-ca
           projected:
             defaultMode: 420
             sources:
             - serviceAccountToken:
                 audience: <https://kubernetes.default.svc.cluster.local>
                 expirationSeconds: 86400
                 path: token
             - secret:
                 items:
                 - key: ca.crt
                   path: ca.crt
                 name: name-sa-token
   

   Стоит обратить внимание на serviceAccountToken. Мы НЕ МАУНТИМ токен из нашего сикрета, а маунтим токен с ротацией. При такой настройке внутри pod’а токен будет ротироваться в соответствии с настройкой expirationSeconds.

В итоге мы получим токен (с ротауией) и ca.crt в той же директории, куда бы ее примонтировал бы Kubernetes, если бы мы использовали true в automountServiceAccountToken