From 58700396f9e6d5c0de01b2f4f592f7ab16058bb2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Petazzoni?= <jerome.petazzoni@gmail.com>
Date: Sun, 23 Mar 2025 18:27:31 -0500
Subject: [PATCH] =?UTF-8?q?=F0=9F=90=9E=20Fix=20permissions=20for=20inject?=
 =?UTF-8?q?ed=20kubeconfig=20in=20mk8s=20stage2?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .../terraform/many-kubernetes/stage2.tmpl     | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)

diff --git a/prepare-labs/terraform/many-kubernetes/stage2.tmpl b/prepare-labs/terraform/many-kubernetes/stage2.tmpl
index 843e0c76..c3f1d441 100644
--- a/prepare-labs/terraform/many-kubernetes/stage2.tmpl
+++ b/prepare-labs/terraform/many-kubernetes/stage2.tmpl
@@ -107,6 +107,36 @@ resource "helm_release" "metrics_server_${index}" {
   }
 }
 
+# This section here deserves a little explanation.
+#
+# When we access a cluster with shpod (either through SSH or code-server)
+# there is no kubeconfig file - we simply use "in-cluster" authentication
+# with a ServiceAccount token. This is a bit unusual, and ideally, I would
+# prefer to have a "normal" kubeconfig file in the students' shell.
+#
+# So what we're doing here, is that we're populating a ConfigMap with
+# a kubeconfig file; and in the initialization scripts (e.g. bashrc) we
+# automatically download the kubeconfig file from the ConfigMap and place
+# it in ~/.kube/kubeconfig.
+#
+# But, which kubeconfig file should we use? We could use the "normal"
+# kubeconfig file that was generated by the provider; but in some cases,
+# that kubeconfig file might use a token instead of a certificate for
+# user authentication - and ideally, I would like to have a certificate
+# so that in the section about auth and RBAC, we can dissect that TLS
+# certificate and explain where our permissions come from.
+#
+# So we're creating a TLS key pair; using the CSR API to issue a user
+# certificate belongong to a special group; and grant the cluster-admin
+# role to that group; then we use the kubeconfig file generated by the
+# provider but override the user with that TLS key pair.
+#
+# This is not strictly necessary but it streamlines the lesson on auth.
+#
+# Lastly - in the ConfigMap we actually put both the original kubeconfig,
+# and the one where we injected our new user (just in case we want to
+# use or look at the original for any reason).
+
 resource "kubernetes_config_map" "kubeconfig_${index}" {
   provider = kubernetes.cluster_${index}
   metadata {
@@ -153,6 +183,23 @@ resource "tls_cert_request" "cluster_admin_${index}" {
   }
 }
 
+resource "kubernetes_cluster_role_binding" "shpod_cluster_admin_${index}" {
+  provider = kubernetes.cluster_${index}
+  metadata {
+    name = "shpod-cluster-admin"
+  }
+  role_ref {
+    api_group = "rbac.authorization.k8s.io"
+    kind = "ClusterRole"
+    name = "cluster-admin"
+  }
+  subject {
+    api_group = "rbac.authorization.k8s.io"
+    kind = "Group"
+    name = "shpod-cluster-admins"
+  }
+}
+
 resource "kubernetes_certificate_signing_request_v1" "cluster_admin_${index}" {
   provider = kubernetes.cluster_${index}
   metadata {