2019-05-01 21:11:23 +00:00
---
2020-04-07 18:55:19 +00:00
layout: docs
2022-09-23 21:04:00 +00:00
page_title: Kubernetes Auth Method
2020-04-07 18:55:19 +00:00
description: >-
2022-09-23 21:04:00 +00:00
Use the Kubernetes auth method type to authenticate to Consul with a Kubernetes service account token. Learn how to configure auth method parameters using this reference page and example configuration.
2019-05-01 21:11:23 +00:00
---
# Kubernetes Auth Method
2020-05-13 19:14:03 +00:00
-> **1.5.0+:** This feature is available in Consul versions 1.5.0 and newer.
2019-05-01 21:11:23 +00:00
The `kubernetes` auth method type allows for a Kubernetes service account token
to be used to authenticate to Consul. This method of authentication makes it
easy to introduce a Consul token into a Kubernetes pod.
This page assumes general knowledge of [Kubernetes](https://kubernetes.io/) and
the concepts described in the main [auth method
2022-01-10 23:36:16 +00:00
documentation](/docs/security/acl/auth-methods).
2019-05-01 21:11:23 +00:00
## Config Parameters
2022-03-30 21:16:26 +00:00
The following auth method [`Config`](/api-docs/acl/auth-methods#config)
2019-05-01 21:11:23 +00:00
parameters are required to properly configure an auth method of type
`kubernetes`:
- `Host` `(string: <required>)` - Must be a host string, a host:port pair, or a
2020-04-06 20:27:35 +00:00
URL to the base of the Kubernetes API server.
2019-05-01 21:11:23 +00:00
- `CACert` `(string: <required>)` - PEM encoded CA cert for use by the TLS
client used to talk with the Kubernetes API. NOTE: Every line must end with a
2020-05-13 19:14:03 +00:00
newline (`\n`). If not set, system certificates are used.
2019-05-01 21:11:23 +00:00
- `ServiceAccountJWT` `(string: <required>)` - A Service Account Token
2020-04-06 20:27:35 +00:00
([JWT](https://jwt.io/ 'JSON Web Token')) used by the Consul leader to
2019-05-01 21:11:23 +00:00
validate application JWTs during login.
2020-04-06 20:27:35 +00:00
2020-05-06 18:48:04 +00:00
- `MapNamespaces` `(bool: <false>)` <EnterpriseAlert inline /> -
2022-03-30 21:16:26 +00:00
**Deprecated in Consul 1.8.0 in favor of [namespace rules](/api-docs/acl/auth-methods#namespacerules).**
2020-05-06 18:48:04 +00:00
Indicates whether the auth method should attempt to map the Kubernetes namespace to a Consul
2020-01-14 15:09:29 +00:00
namespace instead of creating tokens in the auth methods own namespace. Note
that mapping namespaces requires the auth method to reside within the
`default` namespace.
2022-03-30 21:16:26 +00:00
Deprecated in Consul 1.8.0 in favor of [namespace rules](/api-docs/acl/auth-methods#namespacerules).
2020-04-06 20:27:35 +00:00
2020-05-06 18:48:04 +00:00
- `ConsulNamespacePrefix` `(string: <optional>)` <EnterpriseAlert inline /> -
2022-03-30 21:16:26 +00:00
**Deprecated in Consul 1.8.0 in favor of [namespace rules](/api-docs/acl/auth-methods#namespacerules).**
2020-05-06 18:48:04 +00:00
When `MapNamespaces` is enabled, this value will be prefixed to the Kubernetes
2020-01-14 15:09:29 +00:00
namespace to determine the Consul namespace to create the new token within.
2022-03-30 21:16:26 +00:00
Deprecated in Consul 1.8.0 in favor of [namespace rules](/api-docs/acl/auth-methods#namespacerules).
2020-01-14 15:09:29 +00:00
2020-04-23 22:13:18 +00:00
- `ConsulNamespaceOverrides` `(map: <string:string>)` <EnterpriseAlert inline /> -
2022-03-30 21:16:26 +00:00
**Deprecated in Consul 1.8.0 in favor of [namespace rules](/api-docs/acl/auth-methods#namespacerules).**
2020-01-14 15:09:29 +00:00
This field is a mapping of Kubernetes namespace names to Consul namespace
names. If a Kubernetes namespace is present within this map, the value will
be used without adding the `ConsulNamespacePrefix`. If the value in the map
is `""` then the auth methods namespace will be used instead of attempting
to determine an alternate namespace.
2022-03-30 21:16:26 +00:00
Deprecated in Consul 1.8.0 in favor of [namespace rules](/api-docs/acl/auth-methods#namespacerules).
2019-05-01 21:11:23 +00:00
### Sample Config
```json
{
...other fields...
"Config": {
"Host": "https://192.0.2.42:8443",
"CACert": "-----BEGIN CERTIFICATE-----\n...-----END CERTIFICATE-----\n",
"ServiceAccountJWT": "eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9..."
}
}
```
## RBAC
The Kubernetes service account corresponding to the configured
2022-01-10 23:36:16 +00:00
[`ServiceAccountJWT`](/docs/security/acl/auth-methods/kubernetes#serviceaccountjwt)
2019-05-01 21:11:23 +00:00
needs to have access to two Kubernetes APIs:
- [**TokenReview**](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.11/#create-tokenreview-v1-authentication-k8s-io)
2020-04-09 00:09:01 +00:00
-> Kubernetes should be running with `--service-account-lookup`. This is
defaulted to true in Kubernetes 1.7, but any versions prior should ensure
the Kubernetes API server is started with this setting.
2019-05-01 21:11:23 +00:00
- [**ServiceAccount**](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.11/#read-serviceaccount-v1-core)
(`get`)
The following is an example
[RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
configuration snippet to grant the necessary permissions to a service account
named `consul-auth-method-example`:
```yaml
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: review-tokens
namespace: default
subjects:
2020-04-06 20:27:35 +00:00
- kind: ServiceAccount
name: consul-auth-method-example
namespace: default
2019-05-01 21:11:23 +00:00
roleRef:
kind: ClusterRole
name: system:auth-delegator
apiGroup: rbac.authorization.k8s.io
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: service-account-getter
namespace: default
rules:
2020-04-06 20:27:35 +00:00
- apiGroups: ['']
resources: ['serviceaccounts']
verbs: ['get']
2019-05-01 21:11:23 +00:00
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: get-service-accounts
namespace: default
subjects:
2020-04-06 20:27:35 +00:00
- kind: ServiceAccount
name: consul-auth-method-example
namespace: default
2019-05-01 21:11:23 +00:00
roleRef:
kind: ClusterRole
name: service-account-getter
apiGroup: rbac.authorization.k8s.io
```
## Kubernetes Authentication Details
Initially the
2022-01-10 23:36:16 +00:00
[`ServiceAccountJWT`](/docs/security/acl/auth-methods/kubernetes#serviceaccountjwt)
2019-05-01 21:11:23 +00:00
given to the Consul leader uses the TokenReview API to validate the provided
JWT. The trusted attributes of `serviceaccount.namespace`,
`serviceaccount.name`, and `serviceaccount.uid` are populated directly from the
Service Account metadata.
The Consul leader makes an additional query, this time to the ServiceAccount
API to check for the existence of an annotation of
`consul.hashicorp.com/service-name` on the ServiceAccount object. If one is
found its value will override the trusted attribute of `serviceaccount.name`
for the purposes of evaluating any binding rules.
2020-05-13 19:14:03 +00:00
## Trusted Identity Attributes
The authentication step returns the following trusted identity attributes for
use in binding rule selectors and bind name interpolation.
| Attributes | Supported Selector Operations | Can be Interpolated |
| -------------------------- | -------------------------------------------------- | ------------------- |
| `serviceaccount.namespace` | Equal, Not Equal, In, Not In, Matches, Not Matches | yes |
| `serviceaccount.name` | Equal, Not Equal, In, Not In, Matches, Not Matches | yes |
| `serviceaccount.uid` | Equal, Not Equal, In, Not In, Matches, Not Matches | yes |