Add cross reference do decision page

docs/modules/ROOT/pages/explanations/decisions/admin-kubeconfig.adoc

@@ -39,7 +39,7 @@ However, group `system:cluster-admins` is allowed, and functionally equivalent o
 Note that we can't revoke certificates issued through CSRs or through a self-managed CA certificate.
 However, if we use a self-managed CA certificate, we can invalidate any existing certificates by rotating the CA and issuing a new certificate from the new CA.
 
-==== Use service account tokens with cluster-admin privileges
+==== Use service account tokens with cluster-admin privileges [[TokenRequest API]]
 
 The second approach is that we setup a Kubernetes service account which is granted `cluster-admin` privileges through a `ClusterRoleBinding` and issue service account tokens for that service account.
 
@@ -71,7 +71,7 @@ This allows us to issue relatively short-lived credentials (on the order of days
 Optionally, we can also extend Steward to render a full kubeconfig file based on the managed credentials and store that file in Vault in addition to the raw credentials.
 If we store a full kubeconfig file in Vault, we can document a single `vault` CLI command which fetches the emergency kubeconfig for a cluster.
 
-==== Create a new custom controller which manages the credentials on the cluster and writes them to an external secrets store
+==== Create a new custom controller which manages the credentials on the cluster and writes them to an external secrets store [[custom controller]]
 
 Instead of extending Steward, we could also create a new controller which manages admin credentials and writes them to an external secrets store.
 This would provide some level of separation of concerns, since managing admin credentials isn't necessarily part of the Project Syn bootstrap process.
@@ -84,7 +84,7 @@ Another approach is to manage and renew the admin credentials by hand.
 
 == Decision
 
-Use service account tokens generated through the TokenRequest API and implement a custom controller to manage the service account, cluster role binding and tokens.
+Use service account tokens generated through the <<TokenRequest API>> and implement a <<custom controller>> to manage the service account, cluster role binding and tokens.
 
 == Rationale