4.7 KiB

Raw Blame History

layout	page_title	sidebar_current	description
docs	Kubernetes Auth Method	docs-acl-auth-methods-kubernetes	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.

-> 1.5.0+: This guide only applies in Consul versions 1.5.0 and newer.

Kubernetes Auth Method

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 and the concepts described in the main auth method documentation.

Config Parameters

The following auth method Config 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 URL to the base of the Kubernetes API server.
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 newline (\n).
ServiceAccountJWT (string: <required>) - A Service Account Token (JWT) used by the Consul leader to validate application JWTs during login.

Sample Config

{
    ...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 ServiceAccountJWT needs to have access to two Kubernetes APIs:

TokenReview

 -> 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.

ServiceAccount (get)

The following is an example RBAC configuration snippet to grant the necessary permissions to a service account named consul-auth-method-example:

---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: review-tokens
  namespace: default
subjects:
- kind: ServiceAccount
  name: consul-auth-method-example
  namespace: default
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:
- apiGroups: [""]
  resources: ["serviceaccounts"]
  verbs: ["get"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: get-service-accounts
  namespace: default
subjects:
- kind: ServiceAccount
  name: consul-auth-method-example
  namespace: default
roleRef:
  kind: ClusterRole
  name: service-account-getter
  apiGroup: rbac.authorization.k8s.io

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	yes
`serviceaccount.name`	Equal, Not Equal	yes
`serviceaccount.uid`	Equal, Not Equal	yes

Kubernetes Authentication Details

Initially the ServiceAccountJWT 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.

4.7 KiB Raw Blame History