Nu se poate prelua Tokenul Vault pentru contul de serviciu Pod

Folosesc Vault CSI Driver pe Charmed Kubernetes v1.19 unde încerc să recuperez secrete din Vault pentru un pod care rulează într-un spațiu de nume separat (aplicație web) cu propriul cont de serviciu (webapp-sa) urmând pașii din blog.

După cum am reușit să înțeleg până acum, Pod-ul încearcă să se autentifice la API-ul Kubernetes, pentru ca ulterior să poată genera un token Vault pentru a accesa secretul din Vault.

$ kubectl obțineți pe aplicația web
STAREA NUMELE GATA REINCEPE VARSTA
webapp 0/1 ContainerCreating 0 22m

Mi se pare că există o problemă la autentificarea cu API-ul Kubernetes.

Podul rămâne blocat în starea Container Creating cu mesajul - nu s-a putut crea un simbol de cont de serviciu pentru solicitarea podului

Evenimente:
  Introduceți Motivul Vârsta din mesaj
  ---- ------ ---- ---- -------
  Programator normal de 35 m programator implicit Webapp/webapp a fost atribuită cu succes gazdei-03

  Avertisment FailedMount 4m38s (x23 peste 35m) kubelet MountVolume.SetUp a eșuat pentru volumul „secrets-store-inline”: eroare rpc: code = Unknown desc = eșuat la montarea obiectelor din depozitul de secrete pentru pod webapp/webapp, err: rpc error: code = Desc necunoscut = eroare la efectuarea cererii de montare: **nu s-a putut crea un simbol de cont de serviciu pentru solicitarea pod** {webapp xxxx webapp webapp-sa}: serverul nu a putut găsi resursa solicitată

Pot obține simbolul seifului folosind cli în spațiul de nume pod:

$ vault write auth/kubernetes/login role=database jwt=$SA_JWT_TOKEN
Valoare cheie
--- -----
jeton <snipped>

Obțin și jetonul seifului folosind API-ul:

$ curl --request POST --data @payload.json https://127.0.0.1:8200/v1/auth/kubernetes/login
    {
       "request_id":"1234",
       <decupat>
       „auth”:{
          "client_token":"XyZ",
          "accessor":"abc",
          "politici":[
             "Mod implicit",
             "politica aplicației web"
          ],
          „politici_token”:[
             "Mod implicit",
             "politica aplicației web"
          ],
          "metadate":{
             "rol":"bază de date",
             "service_account_name":"webapp-sa",
             "service_account_namespace":"aplicație web",
             "service_account_secret_name":"webapp-sa-token-abcd",
             "service_account_uid":"123456"
          },
          <decupat>    
       }
    }

Referinţă: https://www.vaultproject.io/docs/auth/kubernetes

Conform documentației seifului, am configurat Vault cu Token Reviewer SA după cum urmează:

$ cat seif-auth-service-account.yaml
---
apiVersion: rbac.authorization.k8s.io/v1
fel: ClusterRoleBinding
metadate:
  nume: role-token-review-binding
  spatiu de nume: seif
rolRef:
  apiGroup: rbac.authorization.k8s.io
  fel: ClusterRole
  nume: system:auth-delegator
subiecte:
  - fel: ServiceAccount
    nume: vault-auth
    spatiu de nume: seif

Vault este configurat cu JWT de la Token Reviewer SA, după cum urmează:

$ vault write auth/kubernetes/config \
    token_reviewer_jwt="< Cont de serviciu TOKEN Reviewer JWT>" \
    kubernetes_host="https://$KUBERNETES_PORT_443_TCP_ADDR:443" 
    [email protected]

Am definit un rol de seif pentru a permite webapp-sa acces la secret:

$ vault write auth/kubernetes/role/database \
    bound_service_account_names=webapp-sa \
    bound_service_account_namespaces=webapp \
    policies=politica aplicației web \
    ttl=72h
Succes! Date scrise pe: auth/kubernetes/role/database

The webapp-sa este permis accesul la secret conform Politicii Vault definită după cum urmează:

$ politică seif scrie webapp-policy - <<EOF
> calea „secret/date/db-pass” {
> capabilități = [„citește”]
> }
> EOF
Succes! Politica încărcată: webapp-policy

Pod și SA sunt definite după cum urmează:

$ cat webapp-sa-and-pod.yaml
fel: ServiceAccount
apiVersion: v1
metadate:
  nume: webapp-sa
---
fel: Pod
apiVersion: v1
metadate:
  nume: aplicație web
specificație:
  serviceAccountName: webapp-sa
  containere:
  - imagine: registry/jweissig/app:0.0.1
    nume: aplicație web
    volumMonturi:
    - nume: secrets-store-inline
      mountPath: „/mnt/secrets-store”
      readOnly: adevărat
  volume:
    - nume: secrets-store-inline
      csi:
        driver: secrets-store.csi.k8s.io
        readOnly: adevărat
        volumAtribute:
          providerName: seif
          secretProviderClass: „bază de date seif”

• Are cineva vreo idee de ce Pod-ul nu se autentifică cu API-ul Kubernetes?
• Trebuie să activez semnalizatoarele pe kube-apiserver pentru ca API-ul Token Review să funcționeze?
• Este activat în mod implicit pe Charmed Kubernetes v1.19?

Mi-ar fi recunoscător pentru orice ajutor.

Salutari, Sana