k8s/agent-access: a namespace-limited service account and kubeconfig for a coding agent

Read-only by default, optional deploy role; no Secrets, exec, port-forward or RBAC. Tokens from kubectl create token, time-limited. Not applied. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QLJfZQZeAKAwSqViTmLzki
2026-10-19 09:49:20 +02:00
parent f0f4f57fee
commit 461f9d5578
8 changed files with 246 additions and 0 deletions
@@ -0,0 +1,59 @@
+# Agent access to the mg4 namespace
+
+A kubeconfig for a coding agent that reaches **only the `mg4` namespace**, with a token that
+expires on its own. You create and apply everything here yourself; the agent never does.
+
+| File | What |
+|---|---|
+| `serviceaccount.yaml` | the `mg4-agent` service account in `mg4`, never mounted into a pod |
+| `role-read.yaml` | read-only: workloads, pods and their logs, services, ConfigMaps, PVCs, events, network policies, IngressRoutes |
+| `role-deploy.yaml` | **optional**: apply this repository's manifests and restart workloads |
+| `make-kubeconfig.sh` | writes the kubeconfig with a time-limited token |
+
+Neither role allows **Secrets** (any verb), `pods/exec`, `pods/attach`, `pods/portforward`, RBAC
+objects, the Namespace itself, or anything in another namespace or at cluster scope. The deploy
+role also cannot delete PersistentVolumeClaims, so InfluxDB's data volume stays safe.
+
+## 1. Create the service account and its role
+
+With your own kubeconfig, after `k8s/` itself is applied (the namespace must exist):
+
+```sh
+kubectl apply -k k8s/agent-access/
+```
+
+That is read-only. To let the agent also apply changes, uncomment `role-deploy.yaml` in
+`kustomization.yaml` first. Be aware of what that means: whoever may change a Deployment may run
+any image in the namespace, and such a pod could mount mg4's Secrets and print them. Read-only is
+the limit that holds even against a misbehaving agent; the deploy role is a convenience.
+
+## 2. Check what it may do
+
+```sh
+kubectl auth can-i --list -n mg4 --as=system:serviceaccount:mg4:mg4-agent
+kubectl auth can-i get secrets -n mg4 --as=system:serviceaccount:mg4:mg4-agent       # no
+kubectl auth can-i create pods/exec -n mg4 --as=system:serviceaccount:mg4:mg4-agent  # no
+kubectl auth can-i list pods -n kube-system --as=system:serviceaccount:mg4:mg4-agent # no
+```
+
+## 3. Make the kubeconfig
+
+```sh
+k8s/agent-access/make-kubeconfig.sh 24h
+```
+
+It takes the API server address and CA from your current context, asks the cluster for a token
+for `mg4-agent` (`kubectl create token`, valid for the duration you give; the API server may cap
+it), and writes `~/.config/nilsmg4/kubeconfig-mg4-agent` with mode 600. The token is never
+printed. The file is outside the repository, so it cannot be committed.
+
+Then tell the agent it may use it, e.g. *"you may use ~/.config/nilsmg4/kubeconfig-mg4-agent"*.
+It runs `kubectl` with `KUBECONFIG` pointing at that file, so your own kubeconfig is never used.
+
+## Ending access
+
+- **Wait:** the token expires after its duration. Run the script again for a new one.
+- **Now:** `kubectl delete serviceaccount mg4-agent -n mg4` invalidates every token made for
+  it at once. Remove the rest with `kubectl delete -k k8s/agent-access/`.
+- **Less:** take `role-deploy.yaml` out of the kustomization and
+  `kubectl delete rolebinding,role mg4-agent-deploy -n mg4`.