vault/website/content/api-docs/auth/kubernetes.mdx

---
layout: api
page_title: Kubernetes - Auth Methods - HTTP API
description: This is the API documentation for the Vault Kubernetes auth method plugin.
---

# Kubernetes auth method (API)

@include 'x509-sha1-deprecation.mdx'

This is the API documentation for the Vault Kubernetes auth method plugin. To
learn more about the usage and operation, see the
[Vault Kubernetes auth method](/vault/docs/auth/kubernetes).

This documentation assumes the Kubernetes method is mounted at the
`/auth/kubernetes` path in Vault. Since it is possible to enable auth methods at
any location, please update your API calls accordingly.

## Configure method

The Kubernetes auth method validates service account JWTs and verifies their
existence with the Kubernetes TokenReview API. This endpoint configures the
public key used to validate the JWT signature and the necessary information to
access the Kubernetes API.

| Method | Path                      |
| :----- | :------------------------ |
| `POST` | `/auth/kubernetes/config` |

### Parameters

- `kubernetes_host` `(string: <required>)` - Host must be a host string, a host:port pair, or a URL to the base of the Kubernetes API server.
- `kubernetes_ca_cert` `(string: "")` - Optional PEM encoded CA cert that the TLS client can use to talk with the Kubernetes API.
  **Every line must end with a newline `\n`.**
  If `kubernetes_ca_cert` is unset, the TLS client uses the local CA cert if Vault is running in a Kubernetes pod.
  If `kubernetes_ca_cert` is unset and `disable_local_ca_jwt` set to true, the TLS client uses the system's trusted CA certificate pool.
- `token_reviewer_jwt` `(string: "")` - A service account JWT (or other token) used as a bearer
  token to access the TokenReview API to validate other JWTs during login. If not set,
  the local service account token is used if running in a Kubernetes pod, otherwise
  the JWT submitted in the login payload will be used to access the Kubernetes TokenReview API.
- `pem_keys` `(array: [])` - Optional list of PEM-formatted public keys or certificates
  used to verify the signatures of Kubernetes service account
  JWTs. If a certificate is given, its public key will be
  extracted. Not every installation of Kubernetes exposes these
  keys.
- `disable_local_ca_jwt` `(bool: false)` - Disable defaulting to the local CA cert and service account JWT when running in a Kubernetes pod.
- `use_annotations_as_alias_metadata` `(bool: false)` - Use annotations from the client token's associated service account
  as alias metadata for the Vault entity. Only annotations with the
  `vault.hashicorp.com/alias-metadata-` key prefix are targeted as alias metadata and
  your annotations must be 512 characters or less due to the Vault alias
  metadata value limit. For example, if you configure the annotation
  `vault.hashicorp.com/alias-metadata-foo`, Vault saves the string "foo" along
  with the annotation value to the alias metadata. **To save alias metadata,
  Vault must have permission to read service accounts from the Kubernetes API**.

### Deprecated parameters

-> The following fields have been deprecated and will be removed in a future release:

- `disable_iss_validation` `(bool: true)` **Deprecated** Disable JWT issuer validation. Allows to skip ISS validation.

- `issuer` `(string: "")` **Deprecated** Optional JWT issuer. If no issuer is specified, then this plugin will use `kubernetes/serviceaccount` as the default issuer.
See [these instructions](/vault/docs/auth/kubernetes#discovering-the-service-account-issuer) for looking up the issuer for a given Kubernetes cluster.

### Caveats

If Vault is running in a Kubernetes Pod, the `kubernetes_ca_cert` and
`token_reviewer_jwt` parameters will automatically default to the local CA cert
(`/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`) and local service
account JWT (`/var/run/secrets/kubernetes.io/serviceaccount/token`).

If you override the default local CA cert behavior by setting `disable_local_ca_jwt` to `true`,
the plugin's TLS client will automatically default to using the system's trust store for TLS certificate verification.

### Sample payload

```json
{
  "kubernetes_host": "https://192.168.99.100:8443",
  "kubernetes_ca_cert": "-----BEGIN CERTIFICATE-----\n.....\n-----END CERTIFICATE-----",
  "pem_keys": "-----BEGIN CERTIFICATE-----\n.....\n-----END CERTIFICATE-----"
}
```

### Sample request

```shell-session
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/auth/kubernetes/config
```

## Read config

Returns the previously configured config, excluding credentials.

| Method | Path                      |
| :----- | :------------------------ |
| `GET`  | `/auth/kubernetes/config` |

### Sample request

```shell-session
$ curl \
    --header "X-Vault-Token: ..." \
    http://127.0.0.1:8200/v1/auth/kubernetes/config
```

### Sample response

```json
{
  "data":{
    "kubernetes_host": "https://192.168.99.100:8443",
    "kubernetes_ca_cert": "-----BEGIN CERTIFICATE-----.....-----END CERTIFICATE-----",
    "pem_keys": ["-----BEGIN CERTIFICATE-----.....", .....],
    "disable_local_ca_jwt": false,
    "token_reviewer_jwt_set": false
  }
}
```

## Create/Update role

Registers a role in the auth method. Role types have specific entities
that can perform login operations against this endpoint. Constraints specific
to the role type must be set on the role. These are applied to the authenticated
entities attempting to login.

| Method | Path                          |
| :----- | :---------------------------- |
| `POST` | `/auth/kubernetes/role/:name` |

### Parameters

- `name` `(string: <required>)` - Name of the role.
- `bound_service_account_names` `(array: <required>)` - List of service account
  names able to access this role. If set to "\*" all names are allowed.
- `bound_service_account_namespaces` `(array: [])` - List of namespaces
  allowed to access this role. If set to "\*" all namespaces are allowed.
- `bound_service_account_namespace_selector` `(string: "")` - A label selector for Kubernetes
  namespaces allowed to access this role. Accepts either a JSON or YAML object. The value
  should be of type
  [LabelSelector](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.24/#labelselector-v1-meta). Currently, label selectors with `matchExpressions` are not supported.
  To use label selectors, **Vault must have permission to read namespaces** on the Kubernetes
  cluster. If set with `bound_service_account_namespaces`, the conditions are `OR`ed.
- `audience` `(string: "")` - Audience claim to verify in the JWT. Will be required in Vault 1.21+.
- `alias_name_source` `(string: "serviceaccount_uid")` - Configures how identity aliases are generated.
  Valid choices are: `serviceaccount_uid` and `serviceaccount_name`.

  When you specify `serviceaccount_uid`, Vault uses a machine generated UID from
  the service account as the identity alias name. Using a service account UID is
  both the default and the recommended method as it the more secure option.

  When you specify `serviceaccount_name`, Vault uses the name and namespace from
  the service account as the identity alias name (e.g., `vault/vault-auth`). You
  should only use `serviceaccount_name` if you consider the risk acceptable or
  can mitigate the risk with strong controls around the creation/deletion/access
  of your Kubernetes service accounts and need one of the following capabilities:

    1. fine-grained control over the mapping between Kubernetes service accounts
      and Vault identities.
    1. a simpler process for setting entity aliases before creating Kubernetes
      service account creation.

  See the [Create an Entity Alias](/vault/api-docs/secret/identity/entity-alias#create-an-entity-alias) document
  which further expands on the potential security implications mentioned above.

@include 'tokenfields.mdx'

### Sample Payload 1

```json
{
  "bound_service_account_names": "vault-auth",
  "bound_service_account_namespaces": "default",
  "policies": ["dev", "prod"],
  "max_ttl": 1800000
}
```

### Sample Payload 2

```json
{
  "bound_service_account_names": "vault-auth",
  "bound_service_account_namespace_selector": "\"{\"matchLabels\":{\"stage\":\"dev\",\"vault-role\":\"dev-role\"}}",
  "policies": ["dev", "prod"],
  "max_ttl": 1800000
}
```

### Sample Request

```shell-session
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/auth/kubernetes/role/dev-role
```

## Read role

Returns the previously registered role configuration.

| Method | Path                          |
| :----- | :---------------------------- |
| `GET`  | `/auth/kubernetes/role/:name` |

### Parameters

- `name` `(string: <required>)` - Name of the role.

### Sample request

```shell-session
$ curl \
    --header "X-Vault-Token: ..." \
    http://127.0.0.1:8200/v1/auth/kubernetes/role/dev-role
```

### Sample response

```json
{
  "data": {
    "bound_service_account_names": "vault-auth",
    "bound_service_account_namespaces": "default",
    "max_ttl": 1800000,
    "ttl": 0,
    "period": 0,
    "policies": ["dev", "prod"]
  }
}
```

## List roles

Lists all the roles that are registered with the auth method.

| Method | Path                              |
| :----- | :-------------------------------- |
| `LIST` | `/auth/kubernetes/role`           |
| `GET`  | `/auth/kubernetes/role?list=true` |

### Sample request

```shell-session
$ curl \
    --header "X-Vault-Token: ..." \
    --request LIST \
    http://127.0.0.1:8200/v1/auth/kubernetes/role
```

### Sample response

```json
{
  "data": {
    "keys": ["dev-role", "prod-role"]
  }
}
```

## Delete role

Deletes the previously registered role.

| Method   | Path                          |
| :------- | :---------------------------- |
| `DELETE` | `/auth/kubernetes/role/:role` |

### Parameters

- `role` `(string: <required>)` - Name of the role.

### Sample request

```shell-session
$ curl \
    --header "X-Vault-Token: ..." \
    --request DELETE \
    http://127.0.0.1:8200/v1/auth/kubernetes/role/dev-role
```

## Login

Fetch a token. This endpoint takes a signed JSON Web Token (JWT) and
a role name for some entity. It verifies the JWT signature to authenticate that
entity and then authorizes the entity for the given role.

| Method | Path                     |
| :----- | :----------------------- |
| `POST` | `/auth/kubernetes/login` |

### Parameters

- `role` `(string: <required>)` - Name of the role against which the login is being
  attempted.
- `jwt` `(string: <required>)` - Signed [JSON Web
  Token](https://tools.ietf.org/html/rfc7519) (JWT) for authenticating a service
  account.

### Sample payload

```json
{
  "role": "dev-role",
  "jwt": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}
```

### Sample request

```shell-session
$ curl \
    --request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/auth/kubernetes/login
```

### Sample response

```json
{
  "auth": {
    "client_token": "62b858f9-529c-6b26-e0b8-0457b6aacdb4",
    "accessor": "afa306d0-be3d-c8d2-b0d7-2676e1c0d9b4",
    "policies": ["default"],
    "metadata": {
      "role": "test",
      "service_account_name": "vault-auth",
      "service_account_namespace": "default",
      "service_account_secret_name": "vault-auth-token-pd21c",
      "service_account_uid": "aa9aa8ff-98d0-11e7-9bb7-0800276d99bf"
    },
    "lease_duration": 2764800,
    "renewable": true
  }
}
```