Add decision page for managing the admin kubeconfig

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

@@ -0,0 +1,48 @@
+= Admin kubeconfig management
+
+== Problem
+
+We currently store the kubeconfig for the `system:admin` user which is generated by the `openshift-install` program in Passbolt for emergency access to clusters.
+The client certificate generated for that kubeconfig has a lifetime of 10 years.
+Unfortunately, Kubernetes doesn't support revoking client certificates (cf. https://github.com/kubernetes/kubernetes/issues/18982)
+
+We would like to have another form of emergency access to OpenShift 4 clusters.
+The main reason is that having credentials with a lifetime of 10 years which can't be revoked is less than ideal.
+
+=== Goals
+
+* Define a method to manage emergency access credentials for OpenShift 4 clusters
+* The credentials should be relatively short-lived and it must be possible to rotate them
+
+=== Non-Goals
+
+* Replace regular authentication
+
+== Proposals
+
+For both proposals below, we can extend https://syn.tools/steward[Steward] to manage and renew the credentials and store them in Vault.
+
+This allows us to issue relatively short-lived credentials, which limits the attack surface presented by engineers accessing admin credentials in emergency situations.
+
+Optionally, we can also extend Steward to render a full kubeconfig file based on the managed credentials and store that file in Vault instead of just the raw credentials.
+
+=== Issue short-lived certificates with cluster-admin privileges
+
+The first approach is that we issue client certificates with cluster-admin privileges.
+This can be done either through Kubernetes' `CertificateSigningRequest` (CSR) resources, or by manually issuing certificates against a self-signed CA certificate which is installed as a client CA certificate in the cluster.
+
+One point to consider is that Kubernetes doesn't support issuing client certificates for group `system:masters` through CSRs, but group `system:cluster-admins` is allowed, and functionally equivalent on OpenShift 4.
+
+=== Use service account tokens with cluster-admin privileges
+
+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.
+
+We can use the https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#manually-create-an-api-token-for-a-serviceaccount[TokenRequest] to generate service account tokens which expire after a defined amount of time.
+
+== Decision
+
+== Rationale
+
+== References
+
+* https://access.redhat.com/solutions/4845381[Red Hat solution which gives some details on the admin kubeconfig]

docs/modules/ROOT/partials/nav.adoc

@@ -225,3 +225,4 @@
 ** xref:oc4:ROOT:explanations/decisions/shipping-metrics-to-centralized-instance.adoc[]
 ** xref:oc4:ROOT:explanations/decisions/scheduled-mr-merges.adoc[]
 ** xref:oc4:ROOT:explanations/decisions/subscription-tracking.adoc[]
+** xref:oc4:ROOT:explanations/decisions/admin-kubeconfig.adoc[]