Update k8s auth long-lived token instructions

hashicorp · Jan 31, 2022 · a11b068 · a11b068
1 parent 634e54a
commit a11b068
Showing 1 changed file with 18 additions and 8 deletions.
diff --git a/website/content/docs/auth/kubernetes.mdx b/website/content/docs/auth/kubernetes.mdx
@@ -154,7 +154,7 @@ table summarizes the options, each of which is explained in more detail below.
 
 | Option                               | All tokens are short-lived | Can revoke tokens early | Other considerations |
 | ------------------------------------ | -------------------------- | ----------------------- | -------------------- |
-| Use local token as reviewer JWT      | Yes                        | Yes                     | Requires Vault (1.10+) to be deployed on the Kubernetes cluster |
+| Use local token as reviewer JWT      | Yes                        | Yes                     | Requires Vault (1.9.3+) to be deployed on the Kubernetes cluster |
 | Use client JWT as reviewer JWT       | Yes                        | Yes                     | Operational overhead |
 | Use long-lived token as reviewer JWT | No                         | Yes                     |                      |
 | Use JWT auth instead                 | Yes                        | No                      |                      |
@@ -182,7 +182,7 @@ vault write auth/kubernetes/config \
     kubernetes_host=https://$KUBERNETES_SERVICE_HOST:$KUBERNETES_PORT
 ```
 
-!> **Note:** Requires Vault 1.10+. In earlier versions the service account
+!> **Note:** Requires Vault 1.9.3+. In earlier versions the service account
 token and CA certificate is read once and stored in Vault storage.
 When the service account token expires or is revoked, Vault will no longer be
 able to use the `TokenReview` API and client authentication will fail.
@@ -209,16 +209,26 @@ kubectl create clusterrolebinding vault-client-auth-delegator \
 
 #### Continue using long-lived tokens
 
-The default Kubernetes secret created for a service account is still long lived,
-and can be used as the `token_reviewer_jwt` without needing to refresh it. To
-find the secret, run:
+You can create a long-lived secret using the instructions [here][k8s-create-secret]
+and use that as the `token_reviewer_jwt`. In this example, the `vault` service
+account would need the `system:auth-delegator` ClusterRole:
 
 ```bash
-kubectl get secret "$(kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}')"
+kubectl apply -f - <<EOF
+apiVersion: v1
+kind: Secret
+metadata:
+  name: vault-k8s-auth-secret
+  annotations:
+    kubernetes.io/service-account.name: vault
+type: kubernetes.io/service-account-token
+EOF
 ```
 
-Using this maintains previous workflows but does not fully take advantage of the
-new default short-lived tokens.
+Using this maintains previous workflows but does not benefit from the improved
+security posture of short-lived tokens.
+
+[k8s-create-secret]: https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#manually-create-a-service-account-api-token
 
 #### Use JWT auth