Runbook: dołożenie klucza do istniejącego sekretu #22

2026-08-21T10:58:33Z

gitea commented

2026-08-21 10:58:33 +00:00

Po zmergowaniu LOG-34 pody prezentacji nie wstały:

Error: couldn't find key SESSION_SECRET in Secret astrololo/astrololo-auth

Co przeoczyłem

Runbook opisywał wyłącznie instalację od zera — SESSION_SECRET pojawiał się tylko w komendzie create secret. Na działającym wdrożeniu sekret już istnieje, a merge manifestu kluczy do niego nie dokłada; każe ich tylko szukać.

Gorzej: opisana rotacja też by nie zadziałała. Używała JSON Patch z op: replace na /data/SESSION_SECRET, a replace wymaga, żeby ścieżka już istniała — czyli jedyna komenda, po którą ktoś w tej sytuacji sięgnie, również odmawia.

Co teraz

Obie potrzeby obsługuje jedna komenda:

kubectl -n astrololo patch secret astrololo-auth --type=merge \
  -p "{\"stringData\":{\"SESSION_SECRET\":\"$(openssl rand -hex 32)\"}}"

--type=merge ze stringData dokłada albo nadpisuje i nie wymaga wcześniejszego istnienia klucza — w odróżnieniu od JSON Patch. Ta sama komenda służy więc i do dołożenia, i do rotacji.

Dopisane też sprawdzenie kompletu kluczy bez pokazywania wartości oraz to samo ostrzeżenie w runbooku demo, gdzie czeka identyczna pułapka przy astrololo-demo.

🤖 Generated with Claude Code

Po zmergowaniu LOG-34 pody prezentacji nie wstały: ``` Error: couldn't find key SESSION_SECRET in Secret astrololo/astrololo-auth ``` ## Co przeoczyłem Runbook opisywał **wyłącznie instalację od zera** — `SESSION_SECRET` pojawiał się tylko w komendzie `create secret`. Na działającym wdrożeniu sekret już istnieje, a merge manifestu kluczy do niego nie dokłada; każe ich tylko szukać. **Gorzej: opisana rotacja też by nie zadziałała.** Używała JSON Patch z `op: replace` na `/data/SESSION_SECRET`, a `replace` wymaga, żeby ścieżka już istniała — czyli jedyna komenda, po którą ktoś w tej sytuacji sięgnie, również odmawia. ## Co teraz Obie potrzeby obsługuje **jedna** komenda: ```bash kubectl -n astrololo patch secret astrololo-auth --type=merge \ -p "{\"stringData\":{\"SESSION_SECRET\":\"$(openssl rand -hex 32)\"}}" ``` `--type=merge` ze `stringData` **dokłada albo nadpisuje** i nie wymaga wcześniejszego istnienia klucza — w odróżnieniu od JSON Patch. Ta sama komenda służy więc i do dołożenia, i do rotacji. Dopisane też sprawdzenie kompletu kluczy bez pokazywania wartości oraz to samo ostrzeżenie w runbooku demo, gdzie czeka identyczna pułapka przy `astrololo-demo`. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

gitea added 1 commit 2026-08-21 10:58:34 +00:00

docs(sekrety): dołożenie klucza do ISTNIEJĄCEGO sekretu, nie tylko tworzenie 111f11f534

Po zmergowaniu LOG-34 pody prezentacji nie wstały:
  Error: couldn't find key SESSION_SECRET in Secret astrololo/astrololo-auth

Runbook opisywał wyłącznie ścieżkę instalacji OD ZERA — SESSION_SECRET pojawiał
się tylko w komendzie `create secret`. Na działającym wdrożeniu sekret już
istnieje, a merge manifestu kluczy do niego nie dokłada; każe ich tylko szukać.

Gorzej: opisana rotacja też by tam nie zadziałała. Używała JSON Patch z
`op: replace` na /data/SESSION_SECRET, a `replace` wymaga, żeby ścieżka już
istniała — czyli jedyna komenda, po którą sięgnąłby ktoś w tej sytuacji, też
odmawia.

Teraz obie potrzeby obsługuje JEDNA komenda: `--type=merge` ze `stringData`
dokłada albo nadpisuje i nie wymaga wcześniejszego istnienia klucza. Dopisane
sprawdzenie kompletu kluczy bez pokazywania wartości oraz to samo ostrzeżenie
w runbooku demo, gdzie czeka dokładnie ta sama pułapka.

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

gitea merged commit 47544d1769 into master

2026-08-26 09:05:30 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: gitea/deploy#22