sec(astrololo): pody bez tokenu konta serwisowego (LOG-33)

Wszystkie cztery usługi biegły na koncie `default` z AUTOMATYCZNIE montowanym
tokenem API Kubernetesa. Żadna z nich nie rozmawia z API klastra — sekrety dostają
przez `secretKeyRef`, który wstrzykuje kubelet, nie pod. Token był więc zbędny,
a leżał w każdym kontenerze jako gotowy punkt wyjścia do klastra dla kogoś, kto
przejmie proces (np. przez lukę w zależności).

`automountServiceAccountToken: false` w szablonie poda data/logic/presentation/
render. Zweryfikowane `kubectl kustomize` — pole trafia do `.spec.template.spec`,
nie do specu Deploymentu (tam byłoby ciche i bez efektu).

Zero wpływu na działanie: nic w kodzie nie woła API Kubernetesa.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

astrololo/data.yaml

@@ -9,6 +9,10 @@ spec:
   template:
     metadata: { labels: { app: data } }
     spec:
+      # LOG-33: pody nie rozmawiają z API Kubernetesa, więc token konta
+      # serwisowego jest im niepotrzebny — a zamontowany byłby gotowym
+      # punktem wyjścia do klastra dla kogoś, kto przejmie kontener.
+      automountServiceAccountToken: false
       imagePullSecrets: [{ name: gitea-registry }]
       containers:
         - name: data

astrololo/kustomization.yaml

@@ -10,10 +10,10 @@ resources:
   - ingress.yaml # wejście po https + przekierowanie z http
 images:
   - name: gitea.czernobog.pl/gitea/astrololo-data
-    newTag: b36b3bee
+    newTag: 70c83cfc
   - name: gitea.czernobog.pl/gitea/astrololo-logic
-    newTag: b36b3bee
+    newTag: 70c83cfc
   - name: gitea.czernobog.pl/gitea/astrololo-render
     newTag: latest
   - name: gitea.czernobog.pl/gitea/astrololo-presentation
-    newTag: a9f2a038
+    newTag: 70c83cfc

astrololo/logic.yaml

@@ -9,6 +9,10 @@ spec:
   template:
     metadata: { labels: { app: logic } }
     spec:
+      # LOG-33: pody nie rozmawiają z API Kubernetesa, więc token konta
+      # serwisowego jest im niepotrzebny — a zamontowany byłby gotowym
+      # punktem wyjścia do klastra dla kogoś, kto przejmie kontener.
+      automountServiceAccountToken: false
       imagePullSecrets: [{ name: gitea-registry }]
       containers:
         - name: logic

astrololo/presentation.yaml

@@ -9,6 +9,10 @@ spec:
   template:
     metadata: { labels: { app: presentation } }
     spec:
+      # LOG-33: pody nie rozmawiają z API Kubernetesa, więc token konta
+      # serwisowego jest im niepotrzebny — a zamontowany byłby gotowym
+      # punktem wyjścia do klastra dla kogoś, kto przejmie kontener.
+      automountServiceAccountToken: false
       imagePullSecrets: [{ name: gitea-registry }]
       containers:
         - name: presentation

astrololo/render.yaml

@@ -19,6 +19,10 @@ spec:
   template:
     metadata: { labels: { app: render } }
     spec:
+      # LOG-33: pody nie rozmawiają z API Kubernetesa, więc token konta
+      # serwisowego jest im niepotrzebny — a zamontowany byłby gotowym
+      # punktem wyjścia do klastra dla kogoś, kto przejmie kontener.
+      automountServiceAccountToken: false
       imagePullSecrets: [{ name: gitea-registry }]
       containers:
         - name: render

conjurer/DEPLOY-BOT.md

@@ -23,17 +23,19 @@ bytes). The image-updater's `deploy-bot` alias then bumps this bot's tag.
 So: normal commits update the test bot + librarian; a commit with `[deploy]` in
 its message is the one that also rolls the production bot.
 
-**Bootstrap (first run):** `conjurer-bot-deploy` doesn't exist until the first
+**Already bootstrapped:** the channel was seeded by the first `[deploy]` commit
-`[deploy]` build. Either land one commit with `[deploy]` in the message, or seed
+(the merge of conjurer#20), which promoted `conjurer-bot-deploy:fbd1ec9f` — the
-it once by hand:
+tag pinned in `kustomization.yaml`. From here the image-updater keeps it current
+on each future `[deploy]` commit. Note the librarian is shared and still tracks
+latest, so mind large bot⇄librarian version skews.
+
+If you ever need to seed a tag by hand:
 ```bash
-docker pull  gitea.czernobog.pl/gitea/conjurer-bot:ac16b77f
+docker pull gitea.czernobog.pl/gitea/conjurer-bot:<sha>
-docker tag   gitea.czernobog.pl/gitea/conjurer-bot:ac16b77f \
+docker tag  gitea.czernobog.pl/gitea/conjurer-bot:<sha> \
-             gitea.czernobog.pl/gitea/conjurer-bot-deploy:ac16b77f
+            gitea.czernobog.pl/gitea/conjurer-bot-deploy:<sha>
-docker push  gitea.czernobog.pl/gitea/conjurer-bot-deploy:ac16b77f
+docker push gitea.czernobog.pl/gitea/conjurer-bot-deploy:<sha>
 ```
-(match the tag in `kustomization.yaml`). Note the librarian is shared, so it
-still tracks latest — mind large bot⇄librarian version skews.
 
 ## One-time setup
 

conjurer/kustomization.yaml

@@ -8,11 +8,12 @@ resources:
   - deploy-bot-backup.yaml
 images:
   - name: gitea.czernobog.pl/gitea/conjurer-librarian
-    newTag: f4dea535
+    newTag: ae1bd677
   - name: gitea.czernobog.pl/gitea/conjurer-bot
-    newTag: f4dea535
+    newTag: fbd1ec9f
   # Production bot channel - only bumped when a [deploy]-tagged build appears.
-  # Placeholder tag; the image-updater sets the real one once the first
+  # Bootstrapped to fbd1ec9f: that's the image the first [deploy] build (merge
-  # [deploy] build (merging conjurer#20) creates conjurer-bot-deploy.
+  # of conjurer#20) promoted to conjurer-bot-deploy. From here the image-updater
+  # keeps it current across future [deploy] commits.
   - name: gitea.czernobog.pl/gitea/conjurer-bot-deploy
-    newTag: f4dea535
+    newTag: fbd1ec9f