OIDC/Kubernetes docs: Improve instructions for setting bound_audiences (#16080)

This commit is contained in:
Tom Proctor 2022-06-22 09:27:19 +01:00 committed by GitHub
parent 03d75a7b60
commit caf00b9f3c
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23

View file

@ -306,7 +306,7 @@ service account tokens using JWT/OIDC auth.
-> **Note:** The JWT auth engine does **not** use Kubernetes' `TokenReview` API -> **Note:** The JWT auth engine does **not** use Kubernetes' `TokenReview` API
during authentication, and instead uses public key cryptography to verify the during authentication, and instead uses public key cryptography to verify the
contents of JWTs. This means tokens that have been revoked by Kubernetes will contents of JWTs. This means tokens that have been revoked by Kubernetes will
still be considered valid by Vault until their expiry time. To mitigate this still be considered valid by Vault until their expiry time. To mitigate this
risk, use short TTLs for service account tokens or use risk, use short TTLs for service account tokens or use
[Kubernetes auth](/docs/auth/kubernetes) which _does_ use the `TokenReview` API. [Kubernetes auth](/docs/auth/kubernetes) which _does_ use the `TokenReview` API.
@ -392,10 +392,7 @@ Configuration steps:
1. Fetch the service account signing public key from your cluster's JWKS URI. 1. Fetch the service account signing public key from your cluster's JWKS URI.
```bash ```bash
# 1. Find the issuer URL of the cluster. # Query the jwks_uri specified in /.well-known/openid-configuration
ISSUER="$(kubectl get --raw /.well-known/openid-configuration | jq -r '.issuer')"
# 2. Query the jwks_uri specified in /.well-known/openid-configuration
kubectl get --raw "$(kubectl get --raw /.well-known/openid-configuration | jq -r '.jwks_uri' | sed -r 's/.*\.[^/]+(.*)/\1/')" kubectl get --raw "$(kubectl get --raw /.well-known/openid-configuration | jq -r '.jwks_uri' | sed -r 's/.*\.[^/]+(.*)/\1/')"
``` ```
@ -420,16 +417,36 @@ Configuration steps:
### Creating a role and logging in ### Creating a role and logging in
Once your JWT auth mount is configured, you're ready to configure a role and Once your JWT auth mount is configured, you're ready to configure a role and
log in. log in. The following assumes you use the projected service account token
available in all pods by default. See [Specifying TTL and audience](#specifying-ttl-and-audience)
below if you'd like to control the audience or TTL.
1. Choose any value from the array of default audiences. In these examples,
there is only one audience in the `aud` array,
`https://kubernetes.default.svc.cluster.local`.
To find the default audiences, either create a fresh token (requires
`kubectl` v1.24.0+):
```shell-session
$ kubectl create token default | cut -f2 -d. | base64 --decode
{"aud":["https://kubernetes.default.svc.cluster.local"], ... "sub":"system:serviceaccount:default:default"}
```
Or read a token from a running pod's filesystem:
```shell-session
$ kubectl exec my-pod -- cat /var/run/secrets/kubernetes.io/serviceaccount/token | cut -f2 -d. | base64 --decode
{"aud":["https://kubernetes.default.svc.cluster.local"], ... "sub":"system:serviceaccount:default:default"}
```
1. Create a role for JWT auth that the `default` service account from the 1. Create a role for JWT auth that the `default` service account from the
`default` namespace can use. The audience of tokens defaults to the same as `default` namespace can use.
the issuer, but it is configurable.
```bash ```bash
vault write auth/jwt/role/my-role \ vault write auth/jwt/role/my-role \
role_type="jwt" \ role_type="jwt" \
bound_audiences="${ISSUER}" \ bound_audiences="<AUDIENCE-FROM-PREVIOUS-STEP>" \
user_claim="sub" \ user_claim="sub" \
bound_subject="system:serviceaccount:default:default" \ bound_subject="system:serviceaccount:default:default" \
policies="default" \ policies="default" \
@ -469,9 +486,9 @@ metadata:
name: nginx name: nginx
spec: spec:
# automountServiceAccountToken is redundant in this example because the # automountServiceAccountToken is redundant in this example because the
# mountPath overlapping with the default path below will already stop the # mountPath used overlaps with the default path. The overlap stops the default
# default admission injected token from being created. Use this option if you # admission injected token from being created. You can use this option to
# choose a different mount path. # ensure only a single token is mounted if you choose a different mount path.
automountServiceAccountToken: false automountServiceAccountToken: false
containers: containers:
- name: nginx - name: nginx
@ -487,7 +504,9 @@ spec:
- serviceAccountToken: - serviceAccountToken:
path: token path: token
expirationSeconds: 600 # 10 minutes is the minimum TTL expirationSeconds: 600 # 10 minutes is the minimum TTL
audience: vault audience: vault # Must match your JWT role's `bound_audiences`
# The remaining sources are included to mimic the rest of the default
# admission injected volume.
- configMap: - configMap:
name: kube-root-ca.crt name: kube-root-ca.crt
items: items: