From 19f59a26389a0e5947b0b1085729c58cdc773ae2 Mon Sep 17 00:00:00 2001
From: Tom Proctor <tomhjp@users.noreply.github.com>
Date: Mon, 31 Jan 2022 22:33:17 +0000
Subject: [PATCH] backport of commit a11b0685e290fc869525fd6c3a1dab3559fdb88a

---
 website/content/docs/auth/kubernetes.mdx | 22 ++++++++++++++++------
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/website/content/docs/auth/kubernetes.mdx b/website/content/docs/auth/kubernetes.mdx
index 6ba8312b4056..6cb1f4857821 100644
--- a/website/content/docs/auth/kubernetes.mdx
+++ b/website/content/docs/auth/kubernetes.mdx
@@ -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