Using Kubernetes authentication with Vault CLI in Pods?

Can the Vault CLI read a default service account token from the time limited Kubernetes secret which is mounted (by default) to a Pod? It looks like it should be able to retrieve a cached token, when the server uses any of the Kubernetes auth backend variants )
(Or OIDC).

From the commandline and environment variables the only option I see is using a credential helper or specifying manually the Kubernetes token as the vault token.

1 Like

Are you trying to manually perform a vault login from within a pod? I don’t think that works with the Kubernetes auth method. From the error message below, some auth methods are only available through the HTTP API.

 vault login -method=kubernetes \
  role=demo \
  jwt=@/var/run/secrets/kubernetes.io/serviceaccount/token

Unknown auth method: kubernetes. Use "vault auth list" to see the complete
list of auth methods. Additionally, some auth methods are only available via
the HTTP API.

You can however use the HTTP API, using something like curl to obtain a token manually.

TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)

curl -sX POST "http://vault:8200/v1/auth/kubernetes/login" --data "{\"role\": \"demo\", \"jwt\": \"$TOKEN\"}" | jq .auth

{
  "client_token": "hvs.CAESIB2U6F6KDpjnSc6L4Qv0qoNg10tZC7bG190C9L3LehcPGh4KHGh2cy4xWVJxWXdFTG9PM2YyRUNOM3BzM3l2Vlc",
  "accessor": "l1okQDLnl9kWAMxZ3yfZFmzF",
  "policies": [
    "default"
  ],
  "token_policies": [
    "default"
  ],
  "metadata": {
    "role": "demo",
    "service_account_name": "demo",
    "service_account_namespace": "default",
    "service_account_secret_name": "",
    "service_account_uid": "b2b9ad7c-5354-41b2-bd04-65ce09f7adfd"
  },
  "lease_duration": 30,
  "renewable": true,
  "entity_id": "6ebc83c4-7df6-60ec-83f0-7ac7a18bea6f",
  "token_type": "service",
  "orphan": true,
  "mfa_requirement": null,
  "num_uses": 0
}

Yes, well my main question is why the vault cli can’t do auto discovery for tokens/workload identity like all the usual tools . Seems odd I have to script the login, especially given the sensitive nature of those tokens.

But I am ok with the confirmation it’s not possible, I just could not believe it :slight_smile: (it’s also strange that the -method does not work, but I can debug that, thanks)

I don’t know go, but would it make sense to offer a patch which can read the token?

(Ah correction, the @ syntax is a good hint,
so might not even need a new flag/optiion)

The Vault CLI is really meant for human users, and the Kubernetes auth method is meant for machines and applications. That’s probably why the login command fails.

If you’re on Kubernetes, there are better integrations with Vault that I would recommend over manually authenticating with curl. Such as:

  • Vault Agent/Proxy
  • Vault Agent Sidecar Injector
  • Vault Secrets Operator

The curl command above was a way to show how these applications authenticate to Vault on Kubernetes.

If you manually authenticate with curl, you then must manage the auth token lifecycle (renewals/reauth) as well as any secret lifecycles if you’re pulling dynamic credentials.

No, Vault CLI cannot directly read the default service account token from the mounted Kubernetes secret. You must explicitly provide the token via a credential helper or manually set it as the Vault token. However, if the Vault server is configured with the Kubernetes auth backend (or OIDC), it can retrieve and cache the token for authentication.