Vaultauth , service Account and Service Account token

[raydenz]

Hello

I don't know if it is a bug or if i did not figure out how it exactly works.

I have installed vault secret (url : https://mysecret.local.com/) and vault secret operator I have configured a kubernetes authentification method

I created a namespace called "myapp" (corresponding to "App Namespace" in the diagram) and the 2 custom resources in "myapp" namespace : VaultAuth and VaultStaticSecret

Below the Vault Auth CR

apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultAuth
metadata:
  name: static-auth
  namespace: myapp
spec:
  method: kubernetes
  mount: kubernetes
  kubernetes:
    role: monapp
    serviceAccount: myapp-vault-sa 
    audiences:
      - https://mysecret.local.com/

Everything works well! My understanding is that vault operator will use the service account "myapp-vault-sa " to authenticate on Vault (via the Kubernetes authentification method), and Vault need the token corresponding to that service account to validate it on the API Server.

My question : I can't figure out how Vault can validate the token of my service account "myapp-vault-sa" whereas i did not create a token/secret for the service account "myapp-vault-sa ". It works but i don't know how is it possible without creating a token for the service account. (i already checked "kubectl get secret" etc.. ) How does it work exactly?

Please help

thank you ! :slight_smile:

[ChristianCiach]

You should read up on https://developer.hashicorp.com/vault/docs/auth/kubernetes

In short:

• VSO uses the TokenRequest API of Kubernetes to retrieve short-lived tokens (1h TTL by default). The same happens implicitly when you project ServiceAccounts token into your pods, btw. Long-lived service-account tokens (as static Secrets) are not recommended anymore.
• The VSO then sends these short-lived tokens to the Vault API.
• When using the kubernetes auth method, Vault cannot validate the service-account tokens on its own (in contrast to the jwt auth method). Instead, Vault calls back to your Kubernetes-API to let Kubernetes itself validate the token by using the TokenReview API. That's why you have to configure the kubernetes auth method with the URL to your Kubernetes-API. In contrast to the jwt auth method, this allows tokens to be revoked immediately if the owner of a token (ServiceAccount or Pod) gets deleted.

Dear maintainers: Maybe you should enable the "Discussion" feature of GitHub for this project? I have the feeling questions like these are better suited as a discussion.

[raydenz]

hello @ChristianCiach

Thank you for you response. I have read the documentation but let's take an example (which is my real implementation) :

• VAULT is installed on the k8s cluster "A"
• Vault operator + my application namespace are on the k8s cluster "B"

In my Application namespace i have this Custom Resources :

apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultAuth
metadata:
  name: static-auth
  namespace: myapp
spec:
  method: kubernetes
  mount: kubernetes
  kubernetes:
    role: myapp-role
    serviceAccount: myapp-vault-sa 
    audiences:
      - https://mysecret.local.com/

My application pod is not aware of Vault, it is just mounting the secret dynamically created by the VSO

I guess, VSO connect to VAULT on behalf of my pod using the service account "myapp-vault-sa" specified in the CR VaultAuth (this Service account has no token)

Is it right to say :

• VSO will get a short-lived token (1h ttl for example) for the service account "myapp-vault-sa" on the k8s cluster "B" API
• Then it will authenticate with it to the VAULT (which is on k8s cluster "A")
• VAULT will validate this token with the API of the k8s cluster "B" (it has the right to do it because i configure this before :

$ vault write auth/kubernetes/config \
    token_reviewer_jwt="<your reviewer service account JWT>" \
    kubernetes_host=<API SERVER OF THE K8S CLUSTER "B"> \
    kubernetes_ca_cert=@ca.crt

• VAULT accept the authentification and give it a role because i configure this before :

  $ vault write auth/kubernetes/role/myapp-role\
  bound_service_account_names=myapp-vault-sa \
  bound_service_account_namespaces=myapp \
  policies=myapp-role \
  ttl=1h

regards,

[ChristianCiach]

• Then it will authenticate with it to the VAULT (which is on k8s cluster "B")

You mean "cluster A", right? If yes, then yes, this is how I understand this to work.

[raydenz]

• Then it will authenticate with it to the VAULT (which is on k8s cluster "B")

You mean "cluster A", right? If yes, then yes, this is how I understand this to work.

you are right i change it now you can refresh the page i added more details

[ChristianCiach]

I am sure that is all correct. I just want to add that the fact that your Vault runs inside a cluster is irrelevant to this example. Our Vault doesn't run inside kubernetes and it doesn't change a thing.

[raydenz]

I am sure that is all correct. I just want to add that the fact that your Vault runs inside a cluster is irrelevant to this example. Our Vault doesn't run inside kubernetes and it doesn't change a thing.

Yes you are right, this is just an example of my installation. I try to find a documentation that validate my statement "VSO will get a short-lived token (1h ttl for example) for the service account "myapp-vault-sa" on the k8s cluster "B" API"

Thank you very much.

[ChristianCiach]

I try to find a documentation that validate my statement "VSO will get a short-lived token

See https://developer.hashicorp.com/vault/docs/platform/k8s/vso/sources/vault#supported-vault-authentication-methods

Relies on short-lived Kubernetes ServiceAccount tokens for Vault authentication

[ChristianCiach]

Looks like the default tokenExpirationSeconds is 10 minutes, not an hour (which would be the kubernetes default for projected pod tokens). My bad!

[raydenz]

Looks like the default tokenExpirationSeconds is 10 minutes, not an hour (which would be the kubernetes default for projected pod tokens). My bad!

No problem. Thank you for the help ! :)

ps : you are right this be in the "Discussion" section of Github