infra/stacks/claude-agent-service/main.tf

871 lines
29 KiB
Terraform
Raw Normal View History

[claude-agent-service] Add CLAUDE_CODE_OAUTH_TOKEN env var — 1-year long-lived auth ## Context Earlier today we hit a silent auth failure on the upgrade agent: the short-lived `sk-ant-oat01-*` access token in `.credentials.json` had expired and the CLI's refresh path failed (refresh token either stale or invalidated after the creds sat in Vault for 5 days). The real fix isn't "refresh more often" — it's switching to the long-lived auth mechanism `claude setup-token` provides. Unlike `claude login` (OAuth flow → 6–8h access token + refresh token JSON), `setup-token` mints a single opaque token valid for **1 year** that the CLI consumes via `CLAUDE_CODE_OAUTH_TOKEN` env var. No refresh dance, no JSON file, no rotation for a year. ## This change Adds `CLAUDE_CODE_OAUTH_TOKEN` to the existing `claude-agent-secrets` ExternalSecret, sourced from a new `claude_oauth_token` field at `secret/claude-agent-service`. The container already pulls that secret via `envFrom`, so no other wiring needed. The Claude CLI prefers `CLAUDE_CODE_OAUTH_TOKEN` over the OAuth JSON file when both are present, so this is additive — `.credentials.json` stays mounted as a fallback while we validate the long-lived path. Future cleanup can remove the JSON mount entirely. Verified E2E: synthetic DIUN webhook for `docker.io/library/httpd` → n8n → claude-agent-service /execute → agent job `fea5ff70dcfe` completed in 30s with exit_code=0, agent correctly identified no matching stack and aborted without changes. No API auth errors. ## Spares Harvested two additional long-lived tokens and stored them at `secret/claude-agent-service-spare-{1,2}` for failover if the primary is compromised or revoked. Verified both coexist with the primary (no revocation on mint). ## What is NOT in this change - No removal of `.credentials.json` mount or its Vault source (keep as fallback until we've run for 24h on env-var auth with no issues). - No cron rotator — 1-year TTL means this can be a yearly manual rotation, alerted on from Vault metadata. If we add rotation, we'll source from the spares pool rather than minting new tokens. ## Reproduce locally ``` 1. vault login -method=oidc 2. vault kv get -field=claude_oauth_token secret/claude-agent-service | head -c 25 3. cd stacks/claude-agent-service && ../../scripts/tg apply 4. kubectl -n claude-agent exec deploy/claude-agent-service -- \ printenv CLAUDE_CODE_OAUTH_TOKEN # should be 108 chars 5. Fire synthetic DIUN webhook (see docs/architecture/automated-upgrades.md) ``` Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 12:12:30 +00:00
data "vault_kv_secret_v2" "secrets" {
mount = "secret"
name = "claude-agent-service"
}
data "vault_kv_secret_v2" "viktor_secrets" {
mount = "secret"
name = "viktor"
}
locals {
namespace = "claude-agent"
[forgejo] Phases 3+4+5: cutover, decommission, docs sweep End of forgejo-registry-consolidation. After Phase 0/1 already landed (Forgejo ready, dual-push CI, integrity probe, retention CronJob, images migrated via forgejo-migrate-orphan-images.sh), this commit flips everything off registry.viktorbarzin.me onto Forgejo and removes the legacy infrastructure. Phase 3 — image= flips: * infra/stacks/{payslip-ingest,job-hunter,claude-agent-service, fire-planner,freedify/factory,chrome-service,beads-server}/main.tf — image= now points to forgejo.viktorbarzin.me/viktor/<name>. * infra/stacks/claude-memory/main.tf — also moved off DockerHub (viktorbarzin/claude-memory-mcp:17 → forgejo.viktorbarzin.me/viktor/...). * infra/.woodpecker/{default,drift-detection}.yml — infra-ci pulled from Forgejo. build-ci-image.yml dual-pushes still until next build cycle confirms Forgejo as canonical. * /home/wizard/code/CLAUDE.md — claude-memory-mcp install URL updated. Phase 4 — decommission registry-private: * registry-credentials Secret: dropped registry.viktorbarzin.me / registry.viktorbarzin.me:5050 / 10.0.20.10:5050 auths entries. Forgejo entry is the only one left. * infra/stacks/infra/main.tf cloud-init: dropped containerd hosts.toml entries for registry.viktorbarzin.me + 10.0.20.10:5050. (Existing nodes already had the file removed manually by `setup-forgejo-containerd-mirror.sh` rollout — the cloud-init template only fires on new VM provision.) * infra/modules/docker-registry/docker-compose.yml: registry-private service block removed; nginx 5050 port mapping dropped. Pull- through caches for upstream registries (5000/5010/5020/5030/5040) stay on the VM permanently. * infra/modules/docker-registry/nginx_registry.conf: upstream `private` block + port 5050 server block removed. * infra/stacks/monitoring/modules/monitoring/main.tf: registry_ integrity_probe + registry_probe_credentials resources stripped. forgejo_integrity_probe is the only manifest probe now. Phase 5 — final docs sweep: * infra/docs/runbooks/registry-vm.md — VM scope reduced to pull- through caches; forgejo-registry-breakglass.md cross-ref added. * infra/docs/architecture/ci-cd.md — registry component table + diagram now reflect Forgejo. Pre-migration root-cause sentence preserved as historical context with a pointer to the design doc. * infra/docs/architecture/monitoring.md — Registry Integrity Probe row updated to point at the Forgejo probe. * infra/.claude/CLAUDE.md — Private registry section rewritten end- to-end (auth, retention, integrity, where the bake came from). * prometheus_chart_values.tpl — RegistryManifestIntegrityFailure alert annotation simplified now that only one registry is in scope. Operational follow-up (cannot be done from a TF apply): 1. ssh root@10.0.20.10 — edit /opt/registry/docker-compose.yml to match the new template AND `docker compose up -d --remove-orphans` to actually stop the registry-private container. Memory id=1078 confirms cloud-init won't redeploy on TF apply alone. 2. After 1 week of no incidents, `rm -rf /opt/registry/data/private/` on the VM (~2.6GB freed). 3. Open the dual-push step in build-ci-image.yml and drop registry.viktorbarzin.me:5050 from the `repo:` list — at that point the post-push integrity check at line 33-107 also needs to be repointed at Forgejo or removed (the per-build verify is redundant with the every-15min Forgejo probe). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-07 18:30:02 +00:00
# Phase 3 cutover 2026-05-07 — see infra/docs/plans/2026-05-07-forgejo-registry-consolidation-plan.md.
image = "forgejo.viktorbarzin.me/viktor/claude-agent-service"
image_tag = "latest"
[claude-agent-service] Add CLAUDE_CODE_OAUTH_TOKEN env var — 1-year long-lived auth ## Context Earlier today we hit a silent auth failure on the upgrade agent: the short-lived `sk-ant-oat01-*` access token in `.credentials.json` had expired and the CLI's refresh path failed (refresh token either stale or invalidated after the creds sat in Vault for 5 days). The real fix isn't "refresh more often" — it's switching to the long-lived auth mechanism `claude setup-token` provides. Unlike `claude login` (OAuth flow → 6–8h access token + refresh token JSON), `setup-token` mints a single opaque token valid for **1 year** that the CLI consumes via `CLAUDE_CODE_OAUTH_TOKEN` env var. No refresh dance, no JSON file, no rotation for a year. ## This change Adds `CLAUDE_CODE_OAUTH_TOKEN` to the existing `claude-agent-secrets` ExternalSecret, sourced from a new `claude_oauth_token` field at `secret/claude-agent-service`. The container already pulls that secret via `envFrom`, so no other wiring needed. The Claude CLI prefers `CLAUDE_CODE_OAUTH_TOKEN` over the OAuth JSON file when both are present, so this is additive — `.credentials.json` stays mounted as a fallback while we validate the long-lived path. Future cleanup can remove the JSON mount entirely. Verified E2E: synthetic DIUN webhook for `docker.io/library/httpd` → n8n → claude-agent-service /execute → agent job `fea5ff70dcfe` completed in 30s with exit_code=0, agent correctly identified no matching stack and aborted without changes. No API auth errors. ## Spares Harvested two additional long-lived tokens and stored them at `secret/claude-agent-service-spare-{1,2}` for failover if the primary is compromised or revoked. Verified both coexist with the primary (no revocation on mint). ## What is NOT in this change - No removal of `.credentials.json` mount or its Vault source (keep as fallback until we've run for 24h on env-var auth with no issues). - No cron rotator — 1-year TTL means this can be a yearly manual rotation, alerted on from Vault metadata. If we add rotation, we'll source from the spares pool rather than minting new tokens. ## Reproduce locally ``` 1. vault login -method=oidc 2. vault kv get -field=claude_oauth_token secret/claude-agent-service | head -c 25 3. cd stacks/claude-agent-service && ../../scripts/tg apply 4. kubectl -n claude-agent exec deploy/claude-agent-service -- \ printenv CLAUDE_CODE_OAUTH_TOKEN # should be 108 chars 5. Fire synthetic DIUN webhook (see docs/architecture/automated-upgrades.md) ``` Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 12:12:30 +00:00
labels = {
app = "claude-agent-service"
}
}
# --- Namespace ---
resource "kubernetes_namespace" "claude_agent" {
metadata {
name = local.namespace
labels = {
tier = local.tiers.aux
"resource-governance/custom-limitrange" = "true"
"resource-governance/custom-quota" = "true"
}
}
[infra] Suppress Goldilocks vpa-update-mode label drift on all namespaces [ci skip] ## Context Wave 3B-continued: the Goldilocks VPA dashboard (stacks/vpa) runs a Kyverno ClusterPolicy `goldilocks-vpa-auto-mode` that mutates every namespace with `metadata.labels["goldilocks.fairwinds.com/vpa-update-mode"] = "off"`. This is intentional — Terraform owns container resource limits, and Goldilocks should only provide recommendations, never auto-update. The label is how Goldilocks decides per-namespace whether to run its VPA in `off` mode. Effect on Terraform: every `kubernetes_namespace` resource shows the label as pending-removal (`-> null`) on every `scripts/tg plan`. Dawarich survey 2026-04-18 confirmed the drift. Cluster-side count: 88 namespaces carry the label (`kubectl get ns -o json | jq ... | wc -l`). Every TF-managed namespace is affected. This commit brings the intentional admission drift under the same `# KYVERNO_LIFECYCLE_V1` discoverability marker introduced in c9d221d5 for the ndots dns_config pattern. The marker now stands generically for any Kyverno admission-webhook drift suppression; the inline comment records which specific policy stamps which specific field so future grep audits show why each suppression exists. ## This change 107 `.tf` files touched — every stack's `resource "kubernetes_namespace"` resource gets: ```hcl lifecycle { # KYVERNO_LIFECYCLE_V1: goldilocks-vpa-auto-mode ClusterPolicy stamps this label on every namespace ignore_changes = [metadata[0].labels["goldilocks.fairwinds.com/vpa-update-mode"]] } ``` Injection was done with a brace-depth-tracking Python pass (`/tmp/add_goldilocks_ignore.py`): match `^resource "kubernetes_namespace" ` → track `{` / `}` until the outermost closing brace → insert the lifecycle block before the closing brace. The script is idempotent (skips any file that already mentions `goldilocks.fairwinds.com/vpa-update-mode`) so re-running is safe. Vault stack picked up 2 namespaces in the same file (k8s-users produces one, plus a second explicit ns) — confirmed via file diff (+8 lines). ## What is NOT in this change - `stacks/trading-bot/main.tf` — entire file is `/* … */` commented out (paused 2026-04-06 per user decision). Reverted after the script ran. - `stacks/_template/main.tf.example` — per-stack skeleton, intentionally minimal. User keeps it that way. Not touched by the script (file has no real `resource "kubernetes_namespace"` — only a placeholder comment). - `.terraform/` copies (e.g. `stacks/metallb/.terraform/modules/...`) — gitignored, won't commit; the live path was edited. - `terraform fmt` cleanup of adjacent pre-existing alignment issues in authentik, freedify, hermes-agent, nvidia, vault, meshcentral. Reverted to keep the commit scoped to the Goldilocks sweep. Those files will need a separate fmt-only commit or will be cleaned up on next real apply to that stack. ## Verification Dawarich (one of the hundred-plus touched stacks) showed the pattern before and after: ``` $ cd stacks/dawarich && ../../scripts/tg plan Before: Plan: 0 to add, 2 to change, 0 to destroy. # kubernetes_namespace.dawarich will be updated in-place (goldilocks.fairwinds.com/vpa-update-mode -> null) # module.tls_secret.kubernetes_secret.tls_secret will be updated in-place (Kyverno generate.* labels — fixed in 8d94688d) After: No changes. Your infrastructure matches the configuration. ``` Injection count check: ``` $ rg -c 'KYVERNO_LIFECYCLE_V1: goldilocks-vpa-auto-mode' stacks/ | awk -F: '{s+=$2} END {print s}' 108 ``` ## Reproduce locally 1. `git pull` 2. Pick any stack: `cd stacks/<name> && ../../scripts/tg plan` 3. Expect: no drift on the namespace's goldilocks.fairwinds.com/vpa-update-mode label. Closes: code-dwx Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 21:15:27 +00:00
lifecycle {
# KYVERNO_LIFECYCLE_V1: goldilocks-vpa-auto-mode ClusterPolicy stamps this label on every namespace
ignore_changes = [metadata[0].labels["goldilocks.fairwinds.com/vpa-update-mode"]]
}
[claude-agent-service] Add CLAUDE_CODE_OAUTH_TOKEN env var — 1-year long-lived auth ## Context Earlier today we hit a silent auth failure on the upgrade agent: the short-lived `sk-ant-oat01-*` access token in `.credentials.json` had expired and the CLI's refresh path failed (refresh token either stale or invalidated after the creds sat in Vault for 5 days). The real fix isn't "refresh more often" — it's switching to the long-lived auth mechanism `claude setup-token` provides. Unlike `claude login` (OAuth flow → 6–8h access token + refresh token JSON), `setup-token` mints a single opaque token valid for **1 year** that the CLI consumes via `CLAUDE_CODE_OAUTH_TOKEN` env var. No refresh dance, no JSON file, no rotation for a year. ## This change Adds `CLAUDE_CODE_OAUTH_TOKEN` to the existing `claude-agent-secrets` ExternalSecret, sourced from a new `claude_oauth_token` field at `secret/claude-agent-service`. The container already pulls that secret via `envFrom`, so no other wiring needed. The Claude CLI prefers `CLAUDE_CODE_OAUTH_TOKEN` over the OAuth JSON file when both are present, so this is additive — `.credentials.json` stays mounted as a fallback while we validate the long-lived path. Future cleanup can remove the JSON mount entirely. Verified E2E: synthetic DIUN webhook for `docker.io/library/httpd` → n8n → claude-agent-service /execute → agent job `fea5ff70dcfe` completed in 30s with exit_code=0, agent correctly identified no matching stack and aborted without changes. No API auth errors. ## Spares Harvested two additional long-lived tokens and stored them at `secret/claude-agent-service-spare-{1,2}` for failover if the primary is compromised or revoked. Verified both coexist with the primary (no revocation on mint). ## What is NOT in this change - No removal of `.credentials.json` mount or its Vault source (keep as fallback until we've run for 24h on env-var auth with no issues). - No cron rotator — 1-year TTL means this can be a yearly manual rotation, alerted on from Vault metadata. If we add rotation, we'll source from the spares pool rather than minting new tokens. ## Reproduce locally ``` 1. vault login -method=oidc 2. vault kv get -field=claude_oauth_token secret/claude-agent-service | head -c 25 3. cd stacks/claude-agent-service && ../../scripts/tg apply 4. kubectl -n claude-agent exec deploy/claude-agent-service -- \ printenv CLAUDE_CODE_OAUTH_TOKEN # should be 108 chars 5. Fire synthetic DIUN webhook (see docs/architecture/automated-upgrades.md) ``` Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 12:12:30 +00:00
}
# --- Secrets ---
resource "kubernetes_manifest" "external_secret" {
manifest = {
apiVersion = "external-secrets.io/v1beta1"
kind = "ExternalSecret"
metadata = {
name = "claude-agent-secrets"
namespace = local.namespace
}
spec = {
refreshInterval = "15m"
secretStoreRef = {
name = "vault-kv"
kind = "ClusterSecretStore"
}
target = {
name = "claude-agent-secrets"
}
data = [
{
secretKey = "GITHUB_TOKEN"
remoteRef = {
key = "viktor"
property = "github_pat"
}
},
claude-agent: grant shared pod executor powers (Forgejo PR, terragrunt apply, kubectl write, MCP) Elevates the shared claude-agent-service pod (SA claude-agent, ns claude-agent) so the nextcloud-todos-exec agent can run autonomously. Viktor explicitly chose to elevate the SHARED service knowing every agent on the pod inherits these creds — each grant is security-sensitive and flagged inline for review. Vault (stacks/vault/main.tf): - terraform-state k8s-auth role: add `claude-agent` to bound_service_account_names (was only `default` — the pod's own SA token could not log in, so scripts/tg apply died fetching the PG backend password). `default` kept. - terraform-state policy broadened from `database/static-creds/pg-terraform-state` read only to read on database/static-creds/*, database/creds/*, secret/data/* and secret/metadata/* — what stacks read at plan/apply time. FLAG: grants the shared pod broad Vault READ (effectively all app secrets + rotating DB creds); not denied: secret/data/vault. claude-agent-service stack (stacks/claude-agent-service/main.tf): - ExternalSecret: add FORGEJO_TOKEN (secret/ci/global -> forgejo_push_token, viktor-scoped admin PAT) and HA_MCP_URL (secret/openclaw -> ha_sofia_mcp_url). - git-init: add url.insteadOf rewrite to authenticate git pushes to forgejo.viktorbarzin.me with $FORGEJO_TOKEN (PRs opened via Forgejo API). - New claude-agent-exec ClusterRole+Binding: cluster-wide get/list/watch/create/update/patch/delete on core (incl. secrets), apps, batch, networking.k8s.io, rbac roles/rolebindings. Additive to the existing read-only claude-agent role; does NOT bind cluster-admin. FLAG: very broad — close to cluster-admin in blast radius. - Vault login: VAULT_ADDR + VAULT_K8S_ROLE env + vault-token-refresher sidecar (k8s-auth login role=terraform-state every 30m -> shared emptyDir); main container symlinks ~/.vault-token so scripts/tg auto-auths. - MCP: project-scoped .mcp.json at infra repo root wires `ha` (HTTP, ${HA_MCP_URL}) and `paperless` (in-cluster Service, no token in-cluster). Not applied, not pushed — code only, for human review of the privilege grants. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-04 08:04:10 +00:00
{
# Forgejo push token for opening PRs on forgejo.viktorbarzin.me
# (exec agent uses the Forgejo API via curl + $FORGEJO_TOKEN, and
# git push over HTTPS via the url.insteadOf rewrite in git-init).
# SECURITY: this is the viktor-scoped admin PAT (write:package +
# repo) shared by Woodpecker — see secret/ci/global/forgejo_push_token.
# The shared claude-agent pod (all agents on it) can now push to
# and open PRs against any repo this token can reach.
secretKey = "FORGEJO_TOKEN"
remoteRef = {
key = "ci/global"
property = "forgejo_push_token"
}
},
[claude-agent-service] Add CLAUDE_CODE_OAUTH_TOKEN env var — 1-year long-lived auth ## Context Earlier today we hit a silent auth failure on the upgrade agent: the short-lived `sk-ant-oat01-*` access token in `.credentials.json` had expired and the CLI's refresh path failed (refresh token either stale or invalidated after the creds sat in Vault for 5 days). The real fix isn't "refresh more often" — it's switching to the long-lived auth mechanism `claude setup-token` provides. Unlike `claude login` (OAuth flow → 6–8h access token + refresh token JSON), `setup-token` mints a single opaque token valid for **1 year** that the CLI consumes via `CLAUDE_CODE_OAUTH_TOKEN` env var. No refresh dance, no JSON file, no rotation for a year. ## This change Adds `CLAUDE_CODE_OAUTH_TOKEN` to the existing `claude-agent-secrets` ExternalSecret, sourced from a new `claude_oauth_token` field at `secret/claude-agent-service`. The container already pulls that secret via `envFrom`, so no other wiring needed. The Claude CLI prefers `CLAUDE_CODE_OAUTH_TOKEN` over the OAuth JSON file when both are present, so this is additive — `.credentials.json` stays mounted as a fallback while we validate the long-lived path. Future cleanup can remove the JSON mount entirely. Verified E2E: synthetic DIUN webhook for `docker.io/library/httpd` → n8n → claude-agent-service /execute → agent job `fea5ff70dcfe` completed in 30s with exit_code=0, agent correctly identified no matching stack and aborted without changes. No API auth errors. ## Spares Harvested two additional long-lived tokens and stored them at `secret/claude-agent-service-spare-{1,2}` for failover if the primary is compromised or revoked. Verified both coexist with the primary (no revocation on mint). ## What is NOT in this change - No removal of `.credentials.json` mount or its Vault source (keep as fallback until we've run for 24h on env-var auth with no issues). - No cron rotator — 1-year TTL means this can be a yearly manual rotation, alerted on from Vault metadata. If we add rotation, we'll source from the spares pool rather than minting new tokens. ## Reproduce locally ``` 1. vault login -method=oidc 2. vault kv get -field=claude_oauth_token secret/claude-agent-service | head -c 25 3. cd stacks/claude-agent-service && ../../scripts/tg apply 4. kubectl -n claude-agent exec deploy/claude-agent-service -- \ printenv CLAUDE_CODE_OAUTH_TOKEN # should be 108 chars 5. Fire synthetic DIUN webhook (see docs/architecture/automated-upgrades.md) ``` Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 12:12:30 +00:00
{
secretKey = "API_BEARER_TOKEN"
remoteRef = {
key = "claude-agent-service"
property = "api_bearer_token"
}
},
{
# Long-lived OAuth token (1-year) from `claude setup-token`.
# Preferred over the short-lived .credentials.json — CLI picks this up and
# skips the refresh flow entirely. Rotate yearly; alert 30d before expiry.
secretKey = "CLAUDE_CODE_OAUTH_TOKEN"
remoteRef = {
key = "claude-agent-service"
property = "claude_oauth_token"
}
},
[claude-agent-service] Add WOODPECKER_API_TOKEN + SLACK_WEBHOOK_URL env vars ## Context Companion fix to 2026-04-19's service-upgrade spec refactor. The agent pod has no Vault CLI auth (no VAULT_TOKEN, port 8200 refused), so every `vault kv get` in the spec returned empty: - `WOODPECKER_TOKEN=""` → 401 on /api/repos/1/pipelines → agent can't find its pipeline → 15m poll timeout → rollback loop → >30m cap. - `SLACK_WEBHOOK=""` → webhook POST to empty URL → no Slack messages for 3+ days (the surface symptom that kicked off bd code-3o3). ## This change Extends the `claude-agent-secrets` ExternalSecret with two more keys, making them available to the agent via `envFrom`: - `WOODPECKER_API_TOKEN` ← `secret/ci/global.woodpecker_api_token` (already used by the vault-woodpecker-sync CronJob, same key) - `SLACK_WEBHOOK_URL` ← `secret/viktor.alertmanager_slack_api_url` (shared webhook also consumed by Alertmanager) Pairs with commit a5963169 which refactored service-upgrade.md to read these env vars directly instead of shelling out to `vault kv get`. ## What is NOT in this change - REGISTRY_USER / REGISTRY_PASSWORD — not needed on the agent side. The separate `.woodpecker/build-cli.yml` fix (bd code-3o3 fix C) will add those to `secret/ci/global` for the vault-woodpecker-sync CronJob to publish as Woodpecker secrets, not here. ## Test Plan ### Automated `terraform plan` reported `Plan: 0 to add, 2 to change, 0 to destroy` (ExternalSecret + a cosmetic `tier` label drop on the Deployment). Applied cleanly. ### Manual Verification ``` $ kubectl -n claude-agent get externalsecret claude-agent-secrets \ -o jsonpath='{.status.conditions[?(@.type=="Ready")].message}' secret synced $ kubectl -n claude-agent exec deploy/claude-agent-service -- sh -c \ 'echo "WP=${WOODPECKER_API_TOKEN:0:20}... SLACK=${SLACK_WEBHOOK_URL:0:40}..."' WP=eyJhbGciOiJIUzI1NiIs... SLACK=https://hooks.slack.com/services/T02SV75... $ kubectl -n claude-agent rollout status deploy/claude-agent-service deployment "claude-agent-service" successfully rolled out ``` Next step: fire one synthetic DIUN webhook to confirm the agent reaches Slack + lands a commit + exits cleanly, completing code-3o3. Refs: bd code-3o3 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-19 13:23:12 +00:00
{
# Consumed by service-upgrade agent to poll ci.viktorbarzin.me
# per-workflow status. Pod has no Vault CLI auth, so the old
# `vault kv get` path is dead — see bd code-3o3.
secretKey = "WOODPECKER_API_TOKEN"
remoteRef = {
key = "ci/global"
property = "woodpecker_api_token"
}
},
{
# Consumed by service-upgrade agent for Start/Success/Failure
# notifications. Same shared webhook as alertmanager.
secretKey = "SLACK_WEBHOOK_URL"
remoteRef = {
key = "viktor"
property = "alertmanager_slack_api_url"
}
},
claude-agent: grant shared pod executor powers (Forgejo PR, terragrunt apply, kubectl write, MCP) Elevates the shared claude-agent-service pod (SA claude-agent, ns claude-agent) so the nextcloud-todos-exec agent can run autonomously. Viktor explicitly chose to elevate the SHARED service knowing every agent on the pod inherits these creds — each grant is security-sensitive and flagged inline for review. Vault (stacks/vault/main.tf): - terraform-state k8s-auth role: add `claude-agent` to bound_service_account_names (was only `default` — the pod's own SA token could not log in, so scripts/tg apply died fetching the PG backend password). `default` kept. - terraform-state policy broadened from `database/static-creds/pg-terraform-state` read only to read on database/static-creds/*, database/creds/*, secret/data/* and secret/metadata/* — what stacks read at plan/apply time. FLAG: grants the shared pod broad Vault READ (effectively all app secrets + rotating DB creds); not denied: secret/data/vault. claude-agent-service stack (stacks/claude-agent-service/main.tf): - ExternalSecret: add FORGEJO_TOKEN (secret/ci/global -> forgejo_push_token, viktor-scoped admin PAT) and HA_MCP_URL (secret/openclaw -> ha_sofia_mcp_url). - git-init: add url.insteadOf rewrite to authenticate git pushes to forgejo.viktorbarzin.me with $FORGEJO_TOKEN (PRs opened via Forgejo API). - New claude-agent-exec ClusterRole+Binding: cluster-wide get/list/watch/create/update/patch/delete on core (incl. secrets), apps, batch, networking.k8s.io, rbac roles/rolebindings. Additive to the existing read-only claude-agent role; does NOT bind cluster-admin. FLAG: very broad — close to cluster-admin in blast radius. - Vault login: VAULT_ADDR + VAULT_K8S_ROLE env + vault-token-refresher sidecar (k8s-auth login role=terraform-state every 30m -> shared emptyDir); main container symlinks ~/.vault-token so scripts/tg auto-auths. - MCP: project-scoped .mcp.json at infra repo root wires `ha` (HTTP, ${HA_MCP_URL}) and `paperless` (in-cluster Service, no token in-cluster). Not applied, not pushed — code only, for human review of the privilege grants. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-04 08:04:10 +00:00
{
# Home Assistant MCP endpoint (community ha-mcp add-on on ha-sofia).
# The URL embeds a secret path-token, so it ships as a secret, not a
# literal. Referenced as ${HA_MCP_URL} by the project-scoped .mcp.json
# in the infra repo root. Same Vault key OpenClaw uses
# (secret/openclaw -> ha_sofia_mcp_url).
secretKey = "HA_MCP_URL"
remoteRef = {
key = "openclaw"
property = "ha_sofia_mcp_url"
}
},
[claude-agent-service] Add CLAUDE_CODE_OAUTH_TOKEN env var — 1-year long-lived auth ## Context Earlier today we hit a silent auth failure on the upgrade agent: the short-lived `sk-ant-oat01-*` access token in `.credentials.json` had expired and the CLI's refresh path failed (refresh token either stale or invalidated after the creds sat in Vault for 5 days). The real fix isn't "refresh more often" — it's switching to the long-lived auth mechanism `claude setup-token` provides. Unlike `claude login` (OAuth flow → 6–8h access token + refresh token JSON), `setup-token` mints a single opaque token valid for **1 year** that the CLI consumes via `CLAUDE_CODE_OAUTH_TOKEN` env var. No refresh dance, no JSON file, no rotation for a year. ## This change Adds `CLAUDE_CODE_OAUTH_TOKEN` to the existing `claude-agent-secrets` ExternalSecret, sourced from a new `claude_oauth_token` field at `secret/claude-agent-service`. The container already pulls that secret via `envFrom`, so no other wiring needed. The Claude CLI prefers `CLAUDE_CODE_OAUTH_TOKEN` over the OAuth JSON file when both are present, so this is additive — `.credentials.json` stays mounted as a fallback while we validate the long-lived path. Future cleanup can remove the JSON mount entirely. Verified E2E: synthetic DIUN webhook for `docker.io/library/httpd` → n8n → claude-agent-service /execute → agent job `fea5ff70dcfe` completed in 30s with exit_code=0, agent correctly identified no matching stack and aborted without changes. No API auth errors. ## Spares Harvested two additional long-lived tokens and stored them at `secret/claude-agent-service-spare-{1,2}` for failover if the primary is compromised or revoked. Verified both coexist with the primary (no revocation on mint). ## What is NOT in this change - No removal of `.credentials.json` mount or its Vault source (keep as fallback until we've run for 24h on env-var auth with no issues). - No cron rotator — 1-year TTL means this can be a yearly manual rotation, alerted on from Vault metadata. If we add rotation, we'll source from the spares pool rather than minting new tokens. ## Reproduce locally ``` 1. vault login -method=oidc 2. vault kv get -field=claude_oauth_token secret/claude-agent-service | head -c 25 3. cd stacks/claude-agent-service && ../../scripts/tg apply 4. kubectl -n claude-agent exec deploy/claude-agent-service -- \ printenv CLAUDE_CODE_OAUTH_TOKEN # should be 108 chars 5. Fire synthetic DIUN webhook (see docs/architecture/automated-upgrades.md) ``` Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 12:12:30 +00:00
]
}
}
depends_on = [kubernetes_namespace.claude_agent]
}
# SOPS age key for terraform state decryption
resource "kubernetes_secret" "sops_age_key" {
metadata {
name = "sops-age-key"
namespace = kubernetes_namespace.claude_agent.metadata[0].name
}
data = {
"keys.txt" = data.vault_kv_secret_v2.viktor_secrets.data["sops_age_key_devvm"]
}
type = "Opaque"
}
# Claude OAuth credentials (for claude -p)
resource "kubernetes_secret" "claude_credentials" {
metadata {
name = "claude-credentials"
namespace = kubernetes_namespace.claude_agent.metadata[0].name
}
data = {
".credentials.json" = data.vault_kv_secret_v2.secrets.data["claude_credentials_json"]
}
type = "Opaque"
}
# git-crypt key for repo decryption
resource "kubernetes_config_map" "git_crypt_key" {
metadata {
name = "git-crypt-key"
namespace = kubernetes_namespace.claude_agent.metadata[0].name
}
binary_data = {
"key" = filebase64("${path.root}/../../.git/git-crypt/keys/default")
}
}
# --- RBAC ---
resource "kubernetes_service_account" "claude_agent" {
metadata {
name = "claude-agent"
namespace = kubernetes_namespace.claude_agent.metadata[0].name
}
}
resource "kubernetes_cluster_role" "claude_agent" {
metadata {
name = "claude-agent"
}
rule {
verbs = ["get", "list", "watch"]
api_groups = ["", "apps", "batch"]
resources = ["pods", "pods/log", "nodes", "events", "deployments", "services", "namespaces", "jobs", "cronjobs", "configmaps", "replicasets", "statefulsets", "daemonsets"]
}
rule {
verbs = ["patch", "update"]
api_groups = ["apps"]
resources = ["deployments"]
}
rule {
verbs = ["create"]
api_groups = [""]
resources = ["pods/exec"]
}
}
resource "kubernetes_cluster_role_binding" "claude_agent" {
metadata {
name = "claude-agent"
}
subject {
kind = "ServiceAccount"
name = kubernetes_service_account.claude_agent.metadata[0].name
namespace = kubernetes_namespace.claude_agent.metadata[0].name
}
role_ref {
api_group = "rbac.authorization.k8s.io"
kind = "ClusterRole"
name = kubernetes_cluster_role.claude_agent.metadata[0].name
}
}
claude-agent: grant shared pod executor powers (Forgejo PR, terragrunt apply, kubectl write, MCP) Elevates the shared claude-agent-service pod (SA claude-agent, ns claude-agent) so the nextcloud-todos-exec agent can run autonomously. Viktor explicitly chose to elevate the SHARED service knowing every agent on the pod inherits these creds — each grant is security-sensitive and flagged inline for review. Vault (stacks/vault/main.tf): - terraform-state k8s-auth role: add `claude-agent` to bound_service_account_names (was only `default` — the pod's own SA token could not log in, so scripts/tg apply died fetching the PG backend password). `default` kept. - terraform-state policy broadened from `database/static-creds/pg-terraform-state` read only to read on database/static-creds/*, database/creds/*, secret/data/* and secret/metadata/* — what stacks read at plan/apply time. FLAG: grants the shared pod broad Vault READ (effectively all app secrets + rotating DB creds); not denied: secret/data/vault. claude-agent-service stack (stacks/claude-agent-service/main.tf): - ExternalSecret: add FORGEJO_TOKEN (secret/ci/global -> forgejo_push_token, viktor-scoped admin PAT) and HA_MCP_URL (secret/openclaw -> ha_sofia_mcp_url). - git-init: add url.insteadOf rewrite to authenticate git pushes to forgejo.viktorbarzin.me with $FORGEJO_TOKEN (PRs opened via Forgejo API). - New claude-agent-exec ClusterRole+Binding: cluster-wide get/list/watch/create/update/patch/delete on core (incl. secrets), apps, batch, networking.k8s.io, rbac roles/rolebindings. Additive to the existing read-only claude-agent role; does NOT bind cluster-admin. FLAG: very broad — close to cluster-admin in blast radius. - Vault login: VAULT_ADDR + VAULT_K8S_ROLE env + vault-token-refresher sidecar (k8s-auth login role=terraform-state every 30m -> shared emptyDir); main container symlinks ~/.vault-token so scripts/tg auto-auths. - MCP: project-scoped .mcp.json at infra repo root wires `ha` (HTTP, ${HA_MCP_URL}) and `paperless` (in-cluster Service, no token in-cluster). Not applied, not pushed — code only, for human review of the privilege grants. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-04 08:04:10 +00:00
# -----------------------------------------------------------------------------
# claude-agent-exec — broad cluster WRITE for the executor agent
# -----------------------------------------------------------------------------
# Added 2026-06-04 for the nextcloud-todos-exec executor elevation. The
# existing `claude-agent` ClusterRole above stays as-is (read + patch
# deployments + pods/exec) — this is purely ADDITIVE.
#
# SECURITY — VERY BROAD, FLAG FOR REVIEW:
# - This grants the SHARED claude-agent pod cluster-wide
# get/list/watch/create/update/patch/delete across the common API groups
# below. EVERY agent that runs on this pod inherits it.
# - It explicitly includes core `secrets` (read+write, cluster-wide) and
# rbac roles/rolebindings (create/update/delete) — i.e. the agent can
# read any Secret in any namespace and grant itself further RBAC. That is
# close to cluster-admin in blast radius, minus a few group wildcards.
# - It intentionally does NOT bind the built-in `cluster-admin` ClusterRole,
# so it lacks: arbitrary CRDs/apiextensions, clusterroles/clusterrolebindings
# bind/escalate beyond what's listed, raw `*` on `*`. Viktor can widen to
# `cluster-admin` by swapping the role_ref below if he decides the scoped
# list is too restrictive.
# Terraform-managed cluster resources must still be changed via `scripts/tg
# apply` (CLAUDE.md Terraform-only rule) — this RBAC is for ad-hoc kubectl
# writes the exec agent needs, not a license to drift Terraform state.
resource "kubernetes_cluster_role" "claude_agent_exec" {
metadata {
name = "claude-agent-exec"
}
rule {
verbs = ["get", "list", "watch", "create", "update", "patch", "delete"]
api_groups = [""]
resources = ["pods", "pods/log", "pods/exec", "services", "configmaps", "secrets", "persistentvolumeclaims", "serviceaccounts", "namespaces", "events", "endpoints"]
}
rule {
verbs = ["get", "list", "watch", "create", "update", "patch", "delete"]
api_groups = ["apps"]
resources = ["deployments", "statefulsets", "daemonsets", "replicasets"]
}
rule {
verbs = ["get", "list", "watch", "create", "update", "patch", "delete"]
api_groups = ["batch"]
resources = ["jobs", "cronjobs"]
}
rule {
verbs = ["get", "list", "watch", "create", "update", "patch", "delete"]
api_groups = ["networking.k8s.io"]
resources = ["ingresses", "networkpolicies"]
}
rule {
verbs = ["get", "list", "watch", "create", "update", "patch", "delete"]
api_groups = ["rbac.authorization.k8s.io"]
resources = ["roles", "rolebindings"]
}
}
resource "kubernetes_cluster_role_binding" "claude_agent_exec" {
metadata {
name = "claude-agent-exec"
}
subject {
kind = "ServiceAccount"
name = kubernetes_service_account.claude_agent.metadata[0].name
namespace = kubernetes_namespace.claude_agent.metadata[0].name
}
role_ref {
api_group = "rbac.authorization.k8s.io"
kind = "ClusterRole"
name = kubernetes_cluster_role.claude_agent_exec.metadata[0].name
}
}
[claude-agent-service] Add CLAUDE_CODE_OAUTH_TOKEN env var — 1-year long-lived auth ## Context Earlier today we hit a silent auth failure on the upgrade agent: the short-lived `sk-ant-oat01-*` access token in `.credentials.json` had expired and the CLI's refresh path failed (refresh token either stale or invalidated after the creds sat in Vault for 5 days). The real fix isn't "refresh more often" — it's switching to the long-lived auth mechanism `claude setup-token` provides. Unlike `claude login` (OAuth flow → 6–8h access token + refresh token JSON), `setup-token` mints a single opaque token valid for **1 year** that the CLI consumes via `CLAUDE_CODE_OAUTH_TOKEN` env var. No refresh dance, no JSON file, no rotation for a year. ## This change Adds `CLAUDE_CODE_OAUTH_TOKEN` to the existing `claude-agent-secrets` ExternalSecret, sourced from a new `claude_oauth_token` field at `secret/claude-agent-service`. The container already pulls that secret via `envFrom`, so no other wiring needed. The Claude CLI prefers `CLAUDE_CODE_OAUTH_TOKEN` over the OAuth JSON file when both are present, so this is additive — `.credentials.json` stays mounted as a fallback while we validate the long-lived path. Future cleanup can remove the JSON mount entirely. Verified E2E: synthetic DIUN webhook for `docker.io/library/httpd` → n8n → claude-agent-service /execute → agent job `fea5ff70dcfe` completed in 30s with exit_code=0, agent correctly identified no matching stack and aborted without changes. No API auth errors. ## Spares Harvested two additional long-lived tokens and stored them at `secret/claude-agent-service-spare-{1,2}` for failover if the primary is compromised or revoked. Verified both coexist with the primary (no revocation on mint). ## What is NOT in this change - No removal of `.credentials.json` mount or its Vault source (keep as fallback until we've run for 24h on env-var auth with no issues). - No cron rotator — 1-year TTL means this can be a yearly manual rotation, alerted on from Vault metadata. If we add rotation, we'll source from the spares pool rather than minting new tokens. ## Reproduce locally ``` 1. vault login -method=oidc 2. vault kv get -field=claude_oauth_token secret/claude-agent-service | head -c 25 3. cd stacks/claude-agent-service && ../../scripts/tg apply 4. kubectl -n claude-agent exec deploy/claude-agent-service -- \ printenv CLAUDE_CODE_OAUTH_TOKEN # should be 108 chars 5. Fire synthetic DIUN webhook (see docs/architecture/automated-upgrades.md) ``` Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 12:12:30 +00:00
# --- Storage ---
#
# The `workspace` volume in the deployment is intentionally emptyDir — agent
# jobs do fresh git clones each run, so a per-pod scratch dir on node disk
# is faster and isolated. The 10Gi `claude-agent-workspace-encrypted` PVC
# that previously sat next to this comment was created but never wired
# into the deployment (sat idle from 2026-04-15 to 2026-05-11).
#
# For cases where the agent DOES need to persist state across pod restarts
# (caches, ad-hoc outputs, anything that should survive a pod reschedule),
# `module.persistent` below provides a 5Gi NFS-backed RWX volume mounted
# at /persistent for state that should survive a pod reschedule. Since the
# service now runs jobs concurrently (bounded semaphore, no single-flight
# lock), agents sharing /persistent must use per-job paths to avoid races —
# per-job *workspaces* are isolated (own clone under /workspace/jobs/<id>),
# but /persistent is shared.
module "persistent" {
source = "../../modules/kubernetes/nfs_volume"
name = "claude-agent-persistent"
namespace = kubernetes_namespace.claude_agent.metadata[0].name
nfs_server = "192.168.1.127"
nfs_path = "/srv/nfs/claude-agent-persistent"
storage = "5Gi"
[claude-agent-service] Add CLAUDE_CODE_OAUTH_TOKEN env var — 1-year long-lived auth ## Context Earlier today we hit a silent auth failure on the upgrade agent: the short-lived `sk-ant-oat01-*` access token in `.credentials.json` had expired and the CLI's refresh path failed (refresh token either stale or invalidated after the creds sat in Vault for 5 days). The real fix isn't "refresh more often" — it's switching to the long-lived auth mechanism `claude setup-token` provides. Unlike `claude login` (OAuth flow → 6–8h access token + refresh token JSON), `setup-token` mints a single opaque token valid for **1 year** that the CLI consumes via `CLAUDE_CODE_OAUTH_TOKEN` env var. No refresh dance, no JSON file, no rotation for a year. ## This change Adds `CLAUDE_CODE_OAUTH_TOKEN` to the existing `claude-agent-secrets` ExternalSecret, sourced from a new `claude_oauth_token` field at `secret/claude-agent-service`. The container already pulls that secret via `envFrom`, so no other wiring needed. The Claude CLI prefers `CLAUDE_CODE_OAUTH_TOKEN` over the OAuth JSON file when both are present, so this is additive — `.credentials.json` stays mounted as a fallback while we validate the long-lived path. Future cleanup can remove the JSON mount entirely. Verified E2E: synthetic DIUN webhook for `docker.io/library/httpd` → n8n → claude-agent-service /execute → agent job `fea5ff70dcfe` completed in 30s with exit_code=0, agent correctly identified no matching stack and aborted without changes. No API auth errors. ## Spares Harvested two additional long-lived tokens and stored them at `secret/claude-agent-service-spare-{1,2}` for failover if the primary is compromised or revoked. Verified both coexist with the primary (no revocation on mint). ## What is NOT in this change - No removal of `.credentials.json` mount or its Vault source (keep as fallback until we've run for 24h on env-var auth with no issues). - No cron rotator — 1-year TTL means this can be a yearly manual rotation, alerted on from Vault metadata. If we add rotation, we'll source from the spares pool rather than minting new tokens. ## Reproduce locally ``` 1. vault login -method=oidc 2. vault kv get -field=claude_oauth_token secret/claude-agent-service | head -c 25 3. cd stacks/claude-agent-service && ../../scripts/tg apply 4. kubectl -n claude-agent exec deploy/claude-agent-service -- \ printenv CLAUDE_CODE_OAUTH_TOKEN # should be 108 chars 5. Fire synthetic DIUN webhook (see docs/architecture/automated-upgrades.md) ``` Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 12:12:30 +00:00
}
# --- Deployment ---
resource "kubernetes_deployment" "claude_agent" {
metadata {
name = "claude-agent-service"
namespace = kubernetes_namespace.claude_agent.metadata[0].name
labels = local.labels
}
spec {
replicas = 1
strategy {
type = "Recreate"
}
selector {
match_labels = local.labels
}
template {
metadata {
labels = local.labels
}
spec {
service_account_name = kubernetes_service_account.claude_agent.metadata[0].name
image_pull_secrets {
name = "registry-credentials"
}
security_context {
run_as_user = 1000
run_as_group = 1000
fs_group = 1000
}
# Fix workspace ownership. Kubelet creates the Dockerfile WORKDIR
# (/workspace/infra) inside the emptyDir as root:gid=fsGroup with
# the setgid bit — uid 1000 can't write into it without explicit
# chown + chmod. Pre-create so the path is guaranteed, then chown
# recursively and chmod the infra subdir for safety.
[claude-agent-service] Add CLAUDE_CODE_OAUTH_TOKEN env var — 1-year long-lived auth ## Context Earlier today we hit a silent auth failure on the upgrade agent: the short-lived `sk-ant-oat01-*` access token in `.credentials.json` had expired and the CLI's refresh path failed (refresh token either stale or invalidated after the creds sat in Vault for 5 days). The real fix isn't "refresh more often" — it's switching to the long-lived auth mechanism `claude setup-token` provides. Unlike `claude login` (OAuth flow → 6–8h access token + refresh token JSON), `setup-token` mints a single opaque token valid for **1 year** that the CLI consumes via `CLAUDE_CODE_OAUTH_TOKEN` env var. No refresh dance, no JSON file, no rotation for a year. ## This change Adds `CLAUDE_CODE_OAUTH_TOKEN` to the existing `claude-agent-secrets` ExternalSecret, sourced from a new `claude_oauth_token` field at `secret/claude-agent-service`. The container already pulls that secret via `envFrom`, so no other wiring needed. The Claude CLI prefers `CLAUDE_CODE_OAUTH_TOKEN` over the OAuth JSON file when both are present, so this is additive — `.credentials.json` stays mounted as a fallback while we validate the long-lived path. Future cleanup can remove the JSON mount entirely. Verified E2E: synthetic DIUN webhook for `docker.io/library/httpd` → n8n → claude-agent-service /execute → agent job `fea5ff70dcfe` completed in 30s with exit_code=0, agent correctly identified no matching stack and aborted without changes. No API auth errors. ## Spares Harvested two additional long-lived tokens and stored them at `secret/claude-agent-service-spare-{1,2}` for failover if the primary is compromised or revoked. Verified both coexist with the primary (no revocation on mint). ## What is NOT in this change - No removal of `.credentials.json` mount or its Vault source (keep as fallback until we've run for 24h on env-var auth with no issues). - No cron rotator — 1-year TTL means this can be a yearly manual rotation, alerted on from Vault metadata. If we add rotation, we'll source from the spares pool rather than minting new tokens. ## Reproduce locally ``` 1. vault login -method=oidc 2. vault kv get -field=claude_oauth_token secret/claude-agent-service | head -c 25 3. cd stacks/claude-agent-service && ../../scripts/tg apply 4. kubectl -n claude-agent exec deploy/claude-agent-service -- \ printenv CLAUDE_CODE_OAUTH_TOKEN # should be 108 chars 5. Fire synthetic DIUN webhook (see docs/architecture/automated-upgrades.md) ``` Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 12:12:30 +00:00
init_container {
name = "fix-perms"
image = "busybox:1.37"
command = ["sh", "-c", "mkdir -p /workspace/infra /persistent && chown -R 1000:1000 /workspace /persistent && chmod 0775 /workspace/infra /persistent"]
[claude-agent-service] Add CLAUDE_CODE_OAUTH_TOKEN env var — 1-year long-lived auth ## Context Earlier today we hit a silent auth failure on the upgrade agent: the short-lived `sk-ant-oat01-*` access token in `.credentials.json` had expired and the CLI's refresh path failed (refresh token either stale or invalidated after the creds sat in Vault for 5 days). The real fix isn't "refresh more often" — it's switching to the long-lived auth mechanism `claude setup-token` provides. Unlike `claude login` (OAuth flow → 6–8h access token + refresh token JSON), `setup-token` mints a single opaque token valid for **1 year** that the CLI consumes via `CLAUDE_CODE_OAUTH_TOKEN` env var. No refresh dance, no JSON file, no rotation for a year. ## This change Adds `CLAUDE_CODE_OAUTH_TOKEN` to the existing `claude-agent-secrets` ExternalSecret, sourced from a new `claude_oauth_token` field at `secret/claude-agent-service`. The container already pulls that secret via `envFrom`, so no other wiring needed. The Claude CLI prefers `CLAUDE_CODE_OAUTH_TOKEN` over the OAuth JSON file when both are present, so this is additive — `.credentials.json` stays mounted as a fallback while we validate the long-lived path. Future cleanup can remove the JSON mount entirely. Verified E2E: synthetic DIUN webhook for `docker.io/library/httpd` → n8n → claude-agent-service /execute → agent job `fea5ff70dcfe` completed in 30s with exit_code=0, agent correctly identified no matching stack and aborted without changes. No API auth errors. ## Spares Harvested two additional long-lived tokens and stored them at `secret/claude-agent-service-spare-{1,2}` for failover if the primary is compromised or revoked. Verified both coexist with the primary (no revocation on mint). ## What is NOT in this change - No removal of `.credentials.json` mount or its Vault source (keep as fallback until we've run for 24h on env-var auth with no issues). - No cron rotator — 1-year TTL means this can be a yearly manual rotation, alerted on from Vault metadata. If we add rotation, we'll source from the spares pool rather than minting new tokens. ## Reproduce locally ``` 1. vault login -method=oidc 2. vault kv get -field=claude_oauth_token secret/claude-agent-service | head -c 25 3. cd stacks/claude-agent-service && ../../scripts/tg apply 4. kubectl -n claude-agent exec deploy/claude-agent-service -- \ printenv CLAUDE_CODE_OAUTH_TOKEN # should be 108 chars 5. Fire synthetic DIUN webhook (see docs/architecture/automated-upgrades.md) ``` Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 12:12:30 +00:00
security_context {
run_as_user = 0
}
volume_mount {
name = "workspace"
mount_path = "/workspace"
}
volume_mount {
name = "persistent"
mount_path = "/persistent"
}
[claude-agent-service] Add CLAUDE_CODE_OAUTH_TOKEN env var — 1-year long-lived auth ## Context Earlier today we hit a silent auth failure on the upgrade agent: the short-lived `sk-ant-oat01-*` access token in `.credentials.json` had expired and the CLI's refresh path failed (refresh token either stale or invalidated after the creds sat in Vault for 5 days). The real fix isn't "refresh more often" — it's switching to the long-lived auth mechanism `claude setup-token` provides. Unlike `claude login` (OAuth flow → 6–8h access token + refresh token JSON), `setup-token` mints a single opaque token valid for **1 year** that the CLI consumes via `CLAUDE_CODE_OAUTH_TOKEN` env var. No refresh dance, no JSON file, no rotation for a year. ## This change Adds `CLAUDE_CODE_OAUTH_TOKEN` to the existing `claude-agent-secrets` ExternalSecret, sourced from a new `claude_oauth_token` field at `secret/claude-agent-service`. The container already pulls that secret via `envFrom`, so no other wiring needed. The Claude CLI prefers `CLAUDE_CODE_OAUTH_TOKEN` over the OAuth JSON file when both are present, so this is additive — `.credentials.json` stays mounted as a fallback while we validate the long-lived path. Future cleanup can remove the JSON mount entirely. Verified E2E: synthetic DIUN webhook for `docker.io/library/httpd` → n8n → claude-agent-service /execute → agent job `fea5ff70dcfe` completed in 30s with exit_code=0, agent correctly identified no matching stack and aborted without changes. No API auth errors. ## Spares Harvested two additional long-lived tokens and stored them at `secret/claude-agent-service-spare-{1,2}` for failover if the primary is compromised or revoked. Verified both coexist with the primary (no revocation on mint). ## What is NOT in this change - No removal of `.credentials.json` mount or its Vault source (keep as fallback until we've run for 24h on env-var auth with no issues). - No cron rotator — 1-year TTL means this can be a yearly manual rotation, alerted on from Vault metadata. If we add rotation, we'll source from the spares pool rather than minting new tokens. ## Reproduce locally ``` 1. vault login -method=oidc 2. vault kv get -field=claude_oauth_token secret/claude-agent-service | head -c 25 3. cd stacks/claude-agent-service && ../../scripts/tg apply 4. kubectl -n claude-agent exec deploy/claude-agent-service -- \ printenv CLAUDE_CODE_OAUTH_TOKEN # should be 108 chars 5. Fire synthetic DIUN webhook (see docs/architecture/automated-upgrades.md) ``` Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 12:12:30 +00:00
resources {
requests = {
memory = "32Mi"
}
limits = {
memory = "64Mi"
}
}
}
# Copy Claude credentials to writable volume (CLI needs to refresh OAuth tokens)
init_container {
name = "copy-claude-creds"
image = "busybox:1.37"
command = ["sh", "-c", "cp /secrets/claude/.credentials.json /home/agent/.claude/.credentials.json && chown 1000:1000 /home/agent/.claude/.credentials.json"]
security_context {
run_as_user = 0
}
volume_mount {
name = "claude-credentials-secret"
mount_path = "/secrets/claude"
}
volume_mount {
name = "claude-home"
mount_path = "/home/agent/.claude"
}
resources {
requests = {
memory = "32Mi"
}
limits = {
memory = "64Mi"
}
}
}
# Init: clone repo + unlock git-crypt on first run
init_container {
name = "git-init"
image = "${local.image}:${local.image_tag}"
command = ["sh", "-c", <<-EOF
set -e
# Configure git with HTTPS + PAT
git config --global user.name "Claude Agent Service"
git config --global user.email "claude-agent@viktorbarzin.me"
git config --global --add safe.directory /workspace/infra
git config --global url."https://$${GITHUB_TOKEN}@github.com/".insteadOf "git@github.com:"
git config --global url."https://$${GITHUB_TOKEN}@github.com/".insteadOf "https://github.com/"
claude-agent: grant shared pod executor powers (Forgejo PR, terragrunt apply, kubectl write, MCP) Elevates the shared claude-agent-service pod (SA claude-agent, ns claude-agent) so the nextcloud-todos-exec agent can run autonomously. Viktor explicitly chose to elevate the SHARED service knowing every agent on the pod inherits these creds — each grant is security-sensitive and flagged inline for review. Vault (stacks/vault/main.tf): - terraform-state k8s-auth role: add `claude-agent` to bound_service_account_names (was only `default` — the pod's own SA token could not log in, so scripts/tg apply died fetching the PG backend password). `default` kept. - terraform-state policy broadened from `database/static-creds/pg-terraform-state` read only to read on database/static-creds/*, database/creds/*, secret/data/* and secret/metadata/* — what stacks read at plan/apply time. FLAG: grants the shared pod broad Vault READ (effectively all app secrets + rotating DB creds); not denied: secret/data/vault. claude-agent-service stack (stacks/claude-agent-service/main.tf): - ExternalSecret: add FORGEJO_TOKEN (secret/ci/global -> forgejo_push_token, viktor-scoped admin PAT) and HA_MCP_URL (secret/openclaw -> ha_sofia_mcp_url). - git-init: add url.insteadOf rewrite to authenticate git pushes to forgejo.viktorbarzin.me with $FORGEJO_TOKEN (PRs opened via Forgejo API). - New claude-agent-exec ClusterRole+Binding: cluster-wide get/list/watch/create/update/patch/delete on core (incl. secrets), apps, batch, networking.k8s.io, rbac roles/rolebindings. Additive to the existing read-only claude-agent role; does NOT bind cluster-admin. FLAG: very broad — close to cluster-admin in blast radius. - Vault login: VAULT_ADDR + VAULT_K8S_ROLE env + vault-token-refresher sidecar (k8s-auth login role=terraform-state every 30m -> shared emptyDir); main container symlinks ~/.vault-token so scripts/tg auto-auths. - MCP: project-scoped .mcp.json at infra repo root wires `ha` (HTTP, ${HA_MCP_URL}) and `paperless` (in-cluster Service, no token in-cluster). Not applied, not pushed — code only, for human review of the privilege grants. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-04 08:04:10 +00:00
# Authenticate git pushes/clones to Forgejo so the exec agent can
# branch + push to open PRs on forgejo.viktorbarzin.me. The PR
# itself is created via the Forgejo API (curl + $FORGEJO_TOKEN);
# this rewrite only handles the git transport.
if [ -n "$${FORGEJO_TOKEN}" ]; then
git config --global url."https://$${FORGEJO_TOKEN}@forgejo.viktorbarzin.me/".insteadOf "https://forgejo.viktorbarzin.me/"
fi
[claude-agent-service] Add CLAUDE_CODE_OAUTH_TOKEN env var — 1-year long-lived auth ## Context Earlier today we hit a silent auth failure on the upgrade agent: the short-lived `sk-ant-oat01-*` access token in `.credentials.json` had expired and the CLI's refresh path failed (refresh token either stale or invalidated after the creds sat in Vault for 5 days). The real fix isn't "refresh more often" — it's switching to the long-lived auth mechanism `claude setup-token` provides. Unlike `claude login` (OAuth flow → 6–8h access token + refresh token JSON), `setup-token` mints a single opaque token valid for **1 year** that the CLI consumes via `CLAUDE_CODE_OAUTH_TOKEN` env var. No refresh dance, no JSON file, no rotation for a year. ## This change Adds `CLAUDE_CODE_OAUTH_TOKEN` to the existing `claude-agent-secrets` ExternalSecret, sourced from a new `claude_oauth_token` field at `secret/claude-agent-service`. The container already pulls that secret via `envFrom`, so no other wiring needed. The Claude CLI prefers `CLAUDE_CODE_OAUTH_TOKEN` over the OAuth JSON file when both are present, so this is additive — `.credentials.json` stays mounted as a fallback while we validate the long-lived path. Future cleanup can remove the JSON mount entirely. Verified E2E: synthetic DIUN webhook for `docker.io/library/httpd` → n8n → claude-agent-service /execute → agent job `fea5ff70dcfe` completed in 30s with exit_code=0, agent correctly identified no matching stack and aborted without changes. No API auth errors. ## Spares Harvested two additional long-lived tokens and stored them at `secret/claude-agent-service-spare-{1,2}` for failover if the primary is compromised or revoked. Verified both coexist with the primary (no revocation on mint). ## What is NOT in this change - No removal of `.credentials.json` mount or its Vault source (keep as fallback until we've run for 24h on env-var auth with no issues). - No cron rotator — 1-year TTL means this can be a yearly manual rotation, alerted on from Vault metadata. If we add rotation, we'll source from the spares pool rather than minting new tokens. ## Reproduce locally ``` 1. vault login -method=oidc 2. vault kv get -field=claude_oauth_token secret/claude-agent-service | head -c 25 3. cd stacks/claude-agent-service && ../../scripts/tg apply 4. kubectl -n claude-agent exec deploy/claude-agent-service -- \ printenv CLAUDE_CODE_OAUTH_TOKEN # should be 108 chars 5. Fire synthetic DIUN webhook (see docs/architecture/automated-upgrades.md) ``` Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 12:12:30 +00:00
# Clone or update repo
if [ ! -d /workspace/infra/.git ]; then
git clone https://$${GITHUB_TOKEN}@github.com/ViktorBarzin/infra.git /workspace/infra
else
cd /workspace/infra
git fetch origin
git reset --hard origin/master
fi
# Unlock git-crypt
cd /workspace/infra
git-crypt unlock /secrets/git-crypt/key || true
EOF
]
env_from {
secret_ref {
name = "claude-agent-secrets"
}
}
volume_mount {
name = "workspace"
mount_path = "/workspace"
}
volume_mount {
name = "git-crypt-key"
mount_path = "/secrets/git-crypt"
}
resources {
requests = {
cpu = "100m"
memory = "256Mi"
}
limits = {
memory = "512Mi"
}
}
}
[infra/claude-agent-service] Seed beads metadata + scratch dir at runtime ## Context Review of the BeadBoard Dispatch wiring found that the claude-agent-service Dockerfile's `COPY beads/metadata.json /workspace/.beads/metadata.json` and `COPY agents/beads-task-runner.md /home/agent/.claude/agents/...` both land on paths that are volume-mounted at runtime: - `/workspace` → `claude-agent-workspace-encrypted` PVC (main.tf:394-398) - `/home/agent/.claude` → `claude-home` emptyDir (main.tf:424-427) Kubernetes mounts hide image-layer content at those paths, so the COPYs are dead. The companion commit in `claude-agent-service` restages both files to `/usr/share/agent-seed/` (an image-layer path that is never mounted). Additionally, the beads-task-runner agent rails expect `/workspace/scratch/<job_id>/` to exist, but nothing was creating it. ## Layout before / after ``` Before (dead COPYs): image layer runtime (mounted volumes hide the files) ----------- ----------------------------------- /workspace/ <- hidden by PVC mount .beads/ metadata.json <- UNREACHABLE /home/agent/.claude/ <- hidden by emptyDir mount agents/ beads-task-runner.md <- UNREACHABLE After (init container seeds volumes at pod start): image layer runtime ----------- ------------------------------------ /usr/share/agent-seed/ beads-metadata.json --+ beads-task-runner.md --+-> copied by seed-beads-agent init container into the mounted volumes on every pod start: /workspace/.beads/metadata.json /workspace/scratch/ /home/agent/.claude/agents/beads-task-runner.md ``` ## What ### New init container: `seed-beads-agent` - Positioned AFTER `git-init`, BEFORE the main container. - Uses the same service image (`${local.image}:${local.image_tag}`) — the seed files are baked in at `/usr/share/agent-seed/`. - Runs as default uid 1000 (the PVCs are already chowned by `fix-perms`). - Shell body: mkdir -p /workspace/.beads /workspace/scratch /home/agent/.claude/agents cp /usr/share/agent-seed/beads-metadata.json /workspace/.beads/metadata.json cp /usr/share/agent-seed/beads-task-runner.md /home/agent/.claude/agents/beads-task-runner.md - Mounts: `workspace` at `/workspace`, `claude-home` at `/home/agent/.claude`. - Resources: 32Mi requests / 64Mi limits (matches `fix-perms`/`copy-claude-creds`). ### Formatting - `terraform fmt -recursive` also normalised whitespace in the token-expiry locals block and the CronJob container definition. No semantic change. ## What is NOT in this change - No image tag bump. The Dockerfile refactor that produces the `/usr/share/agent-seed/` path lands in the claude-agent-service repo and will roll in on the next CI build. Until that build ships and the tag is bumped in this file, the new init container will `cp` from a path that doesn't exist yet — so do NOT apply this commit until the corresponding image tag bump is ready. The commit is declarative prep. - No changes to storage class, RBAC, Service, or any other init. - The main container mounts remain unchanged — only the init containers prepare volume contents. ## Test Plan ### Automated ``` $ terraform fmt -check -recursive stacks/claude-agent-service/ (no output — clean) $ terraform -chdir=stacks/claude-agent-service/ init -backend=false Terraform has been successfully initialized! $ terraform -chdir=stacks/claude-agent-service/ validate Warning: Deprecated Resource (pre-existing; use kubernetes_namespace_v1) Success! The configuration is valid, but there were some validation warnings as shown above. ``` ### Manual Verification (after image bump + apply) 1. Bump `local.image_tag` in main.tf to the SHA of a build that has `/usr/share/agent-seed/*` (verify with `docker inspect $IMAGE | jq ...` or `kubectl run tmp --image ... -- ls /usr/share/agent-seed`). 2. `scripts/tg apply stacks/claude-agent-service` 3. `kubectl -n claude-agent get pods -w` — all init containers complete. 4. `kubectl -n claude-agent exec deploy/claude-agent-service -c claude-agent-service -- ls -la /workspace/.beads/metadata.json /home/agent/.claude/agents/beads-task-runner.md /workspace/scratch` Expected: all three paths exist; first two are regular files with the expected content, `scratch` is a directory. 5. `kubectl -n claude-agent exec deploy/claude-agent-service -c claude-agent-service -- jq -r .dolt_server_host /workspace/.beads/metadata.json` Expected: `dolt.beads-server.svc.cluster.local`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 14:23:19 +00:00
# Seed beads metadata + beads-task-runner agent into runtime volumes.
# The Dockerfile stages these files at /usr/share/agent-seed/ (image
# layer, never mounted). Both /workspace (PVC) and /home/agent/.claude
# (emptyDir) are volume mounts that hide any image-layer content, so
# the files have to be copied in at pod start. Also creates the
# scratch directory the beads-task-runner rails expect.
init_container {
name = "seed-beads-agent"
image = "${local.image}:${local.image_tag}"
command = ["sh", "-c", <<-EOT
set -e
mkdir -p /workspace/.beads /workspace/scratch /home/agent/.claude/agents
cp /usr/share/agent-seed/beads-metadata.json /workspace/.beads/metadata.json
cp /usr/share/agent-seed/beads-task-runner.md /home/agent/.claude/agents/beads-task-runner.md
cp /usr/share/agent-seed/recruiter-triage.md /home/agent/.claude/agents/recruiter-triage.md
cp /usr/share/agent-seed/nextcloud-todos-planner.md /home/agent/.claude/agents/nextcloud-todos-planner.md
cp /usr/share/agent-seed/nextcloud-todos-exec.md /home/agent/.claude/agents/nextcloud-todos-exec.md
[infra/claude-agent-service] Seed beads metadata + scratch dir at runtime ## Context Review of the BeadBoard Dispatch wiring found that the claude-agent-service Dockerfile's `COPY beads/metadata.json /workspace/.beads/metadata.json` and `COPY agents/beads-task-runner.md /home/agent/.claude/agents/...` both land on paths that are volume-mounted at runtime: - `/workspace` → `claude-agent-workspace-encrypted` PVC (main.tf:394-398) - `/home/agent/.claude` → `claude-home` emptyDir (main.tf:424-427) Kubernetes mounts hide image-layer content at those paths, so the COPYs are dead. The companion commit in `claude-agent-service` restages both files to `/usr/share/agent-seed/` (an image-layer path that is never mounted). Additionally, the beads-task-runner agent rails expect `/workspace/scratch/<job_id>/` to exist, but nothing was creating it. ## Layout before / after ``` Before (dead COPYs): image layer runtime (mounted volumes hide the files) ----------- ----------------------------------- /workspace/ <- hidden by PVC mount .beads/ metadata.json <- UNREACHABLE /home/agent/.claude/ <- hidden by emptyDir mount agents/ beads-task-runner.md <- UNREACHABLE After (init container seeds volumes at pod start): image layer runtime ----------- ------------------------------------ /usr/share/agent-seed/ beads-metadata.json --+ beads-task-runner.md --+-> copied by seed-beads-agent init container into the mounted volumes on every pod start: /workspace/.beads/metadata.json /workspace/scratch/ /home/agent/.claude/agents/beads-task-runner.md ``` ## What ### New init container: `seed-beads-agent` - Positioned AFTER `git-init`, BEFORE the main container. - Uses the same service image (`${local.image}:${local.image_tag}`) — the seed files are baked in at `/usr/share/agent-seed/`. - Runs as default uid 1000 (the PVCs are already chowned by `fix-perms`). - Shell body: mkdir -p /workspace/.beads /workspace/scratch /home/agent/.claude/agents cp /usr/share/agent-seed/beads-metadata.json /workspace/.beads/metadata.json cp /usr/share/agent-seed/beads-task-runner.md /home/agent/.claude/agents/beads-task-runner.md - Mounts: `workspace` at `/workspace`, `claude-home` at `/home/agent/.claude`. - Resources: 32Mi requests / 64Mi limits (matches `fix-perms`/`copy-claude-creds`). ### Formatting - `terraform fmt -recursive` also normalised whitespace in the token-expiry locals block and the CronJob container definition. No semantic change. ## What is NOT in this change - No image tag bump. The Dockerfile refactor that produces the `/usr/share/agent-seed/` path lands in the claude-agent-service repo and will roll in on the next CI build. Until that build ships and the tag is bumped in this file, the new init container will `cp` from a path that doesn't exist yet — so do NOT apply this commit until the corresponding image tag bump is ready. The commit is declarative prep. - No changes to storage class, RBAC, Service, or any other init. - The main container mounts remain unchanged — only the init containers prepare volume contents. ## Test Plan ### Automated ``` $ terraform fmt -check -recursive stacks/claude-agent-service/ (no output — clean) $ terraform -chdir=stacks/claude-agent-service/ init -backend=false Terraform has been successfully initialized! $ terraform -chdir=stacks/claude-agent-service/ validate Warning: Deprecated Resource (pre-existing; use kubernetes_namespace_v1) Success! The configuration is valid, but there were some validation warnings as shown above. ``` ### Manual Verification (after image bump + apply) 1. Bump `local.image_tag` in main.tf to the SHA of a build that has `/usr/share/agent-seed/*` (verify with `docker inspect $IMAGE | jq ...` or `kubectl run tmp --image ... -- ls /usr/share/agent-seed`). 2. `scripts/tg apply stacks/claude-agent-service` 3. `kubectl -n claude-agent get pods -w` — all init containers complete. 4. `kubectl -n claude-agent exec deploy/claude-agent-service -c claude-agent-service -- ls -la /workspace/.beads/metadata.json /home/agent/.claude/agents/beads-task-runner.md /workspace/scratch` Expected: all three paths exist; first two are regular files with the expected content, `scratch` is a directory. 5. `kubectl -n claude-agent exec deploy/claude-agent-service -c claude-agent-service -- jq -r .dolt_server_host /workspace/.beads/metadata.json` Expected: `dolt.beads-server.svc.cluster.local`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 14:23:19 +00:00
EOT
]
volume_mount {
name = "workspace"
mount_path = "/workspace"
}
volume_mount {
name = "claude-home"
mount_path = "/home/agent/.claude"
}
resources {
requests = {
memory = "32Mi"
}
limits = {
memory = "64Mi"
}
}
}
[claude-agent-service] Add CLAUDE_CODE_OAUTH_TOKEN env var — 1-year long-lived auth ## Context Earlier today we hit a silent auth failure on the upgrade agent: the short-lived `sk-ant-oat01-*` access token in `.credentials.json` had expired and the CLI's refresh path failed (refresh token either stale or invalidated after the creds sat in Vault for 5 days). The real fix isn't "refresh more often" — it's switching to the long-lived auth mechanism `claude setup-token` provides. Unlike `claude login` (OAuth flow → 6–8h access token + refresh token JSON), `setup-token` mints a single opaque token valid for **1 year** that the CLI consumes via `CLAUDE_CODE_OAUTH_TOKEN` env var. No refresh dance, no JSON file, no rotation for a year. ## This change Adds `CLAUDE_CODE_OAUTH_TOKEN` to the existing `claude-agent-secrets` ExternalSecret, sourced from a new `claude_oauth_token` field at `secret/claude-agent-service`. The container already pulls that secret via `envFrom`, so no other wiring needed. The Claude CLI prefers `CLAUDE_CODE_OAUTH_TOKEN` over the OAuth JSON file when both are present, so this is additive — `.credentials.json` stays mounted as a fallback while we validate the long-lived path. Future cleanup can remove the JSON mount entirely. Verified E2E: synthetic DIUN webhook for `docker.io/library/httpd` → n8n → claude-agent-service /execute → agent job `fea5ff70dcfe` completed in 30s with exit_code=0, agent correctly identified no matching stack and aborted without changes. No API auth errors. ## Spares Harvested two additional long-lived tokens and stored them at `secret/claude-agent-service-spare-{1,2}` for failover if the primary is compromised or revoked. Verified both coexist with the primary (no revocation on mint). ## What is NOT in this change - No removal of `.credentials.json` mount or its Vault source (keep as fallback until we've run for 24h on env-var auth with no issues). - No cron rotator — 1-year TTL means this can be a yearly manual rotation, alerted on from Vault metadata. If we add rotation, we'll source from the spares pool rather than minting new tokens. ## Reproduce locally ``` 1. vault login -method=oidc 2. vault kv get -field=claude_oauth_token secret/claude-agent-service | head -c 25 3. cd stacks/claude-agent-service && ../../scripts/tg apply 4. kubectl -n claude-agent exec deploy/claude-agent-service -- \ printenv CLAUDE_CODE_OAUTH_TOKEN # should be 108 chars 5. Fire synthetic DIUN webhook (see docs/architecture/automated-upgrades.md) ``` Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 12:12:30 +00:00
container {
name = "claude-agent-service"
image = "${local.image}:${local.image_tag}"
claude-agent: grant shared pod executor powers (Forgejo PR, terragrunt apply, kubectl write, MCP) Elevates the shared claude-agent-service pod (SA claude-agent, ns claude-agent) so the nextcloud-todos-exec agent can run autonomously. Viktor explicitly chose to elevate the SHARED service knowing every agent on the pod inherits these creds — each grant is security-sensitive and flagged inline for review. Vault (stacks/vault/main.tf): - terraform-state k8s-auth role: add `claude-agent` to bound_service_account_names (was only `default` — the pod's own SA token could not log in, so scripts/tg apply died fetching the PG backend password). `default` kept. - terraform-state policy broadened from `database/static-creds/pg-terraform-state` read only to read on database/static-creds/*, database/creds/*, secret/data/* and secret/metadata/* — what stacks read at plan/apply time. FLAG: grants the shared pod broad Vault READ (effectively all app secrets + rotating DB creds); not denied: secret/data/vault. claude-agent-service stack (stacks/claude-agent-service/main.tf): - ExternalSecret: add FORGEJO_TOKEN (secret/ci/global -> forgejo_push_token, viktor-scoped admin PAT) and HA_MCP_URL (secret/openclaw -> ha_sofia_mcp_url). - git-init: add url.insteadOf rewrite to authenticate git pushes to forgejo.viktorbarzin.me with $FORGEJO_TOKEN (PRs opened via Forgejo API). - New claude-agent-exec ClusterRole+Binding: cluster-wide get/list/watch/create/update/patch/delete on core (incl. secrets), apps, batch, networking.k8s.io, rbac roles/rolebindings. Additive to the existing read-only claude-agent role; does NOT bind cluster-admin. FLAG: very broad — close to cluster-admin in blast radius. - Vault login: VAULT_ADDR + VAULT_K8S_ROLE env + vault-token-refresher sidecar (k8s-auth login role=terraform-state every 30m -> shared emptyDir); main container symlinks ~/.vault-token so scripts/tg auto-auths. - MCP: project-scoped .mcp.json at infra repo root wires `ha` (HTTP, ${HA_MCP_URL}) and `paperless` (in-cluster Service, no token in-cluster). Not applied, not pushed — code only, for human review of the privilege grants. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-04 08:04:10 +00:00
# Wrap the image CMD so a Vault token is in place before any agent
# runs `scripts/tg apply`. The `vault-token-refresher` sidecar
# k8s-auth-logs-in (role=terraform-state) and writes the token to the
# shared `vault-token` emptyDir at /vault/token; we symlink
# $HOME/.vault-token → that file so `vault` / `scripts/tg` (which fall
# through to ~/.vault-token when $VAULT_TOKEN is unset) pick it up.
# NOTE: this duplicates the image's CMD (uvicorn line below) — if the
# Dockerfile CMD changes, update this too. FLAG for review.
command = ["/bin/sh", "-c", <<-EOF
ln -sfn /vault/token "$HOME/.vault-token"
exec python3 -m uvicorn app.main:app --host 0.0.0.0 --port 8080 --app-dir /srv
EOF
]
[claude-agent-service] Add CLAUDE_CODE_OAUTH_TOKEN env var — 1-year long-lived auth ## Context Earlier today we hit a silent auth failure on the upgrade agent: the short-lived `sk-ant-oat01-*` access token in `.credentials.json` had expired and the CLI's refresh path failed (refresh token either stale or invalidated after the creds sat in Vault for 5 days). The real fix isn't "refresh more often" — it's switching to the long-lived auth mechanism `claude setup-token` provides. Unlike `claude login` (OAuth flow → 6–8h access token + refresh token JSON), `setup-token` mints a single opaque token valid for **1 year** that the CLI consumes via `CLAUDE_CODE_OAUTH_TOKEN` env var. No refresh dance, no JSON file, no rotation for a year. ## This change Adds `CLAUDE_CODE_OAUTH_TOKEN` to the existing `claude-agent-secrets` ExternalSecret, sourced from a new `claude_oauth_token` field at `secret/claude-agent-service`. The container already pulls that secret via `envFrom`, so no other wiring needed. The Claude CLI prefers `CLAUDE_CODE_OAUTH_TOKEN` over the OAuth JSON file when both are present, so this is additive — `.credentials.json` stays mounted as a fallback while we validate the long-lived path. Future cleanup can remove the JSON mount entirely. Verified E2E: synthetic DIUN webhook for `docker.io/library/httpd` → n8n → claude-agent-service /execute → agent job `fea5ff70dcfe` completed in 30s with exit_code=0, agent correctly identified no matching stack and aborted without changes. No API auth errors. ## Spares Harvested two additional long-lived tokens and stored them at `secret/claude-agent-service-spare-{1,2}` for failover if the primary is compromised or revoked. Verified both coexist with the primary (no revocation on mint). ## What is NOT in this change - No removal of `.credentials.json` mount or its Vault source (keep as fallback until we've run for 24h on env-var auth with no issues). - No cron rotator — 1-year TTL means this can be a yearly manual rotation, alerted on from Vault metadata. If we add rotation, we'll source from the spares pool rather than minting new tokens. ## Reproduce locally ``` 1. vault login -method=oidc 2. vault kv get -field=claude_oauth_token secret/claude-agent-service | head -c 25 3. cd stacks/claude-agent-service && ../../scripts/tg apply 4. kubectl -n claude-agent exec deploy/claude-agent-service -- \ printenv CLAUDE_CODE_OAUTH_TOKEN # should be 108 chars 5. Fire synthetic DIUN webhook (see docs/architecture/automated-upgrades.md) ``` Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 12:12:30 +00:00
port {
container_port = 8080
}
env_from {
secret_ref {
name = "claude-agent-secrets"
}
}
env {
name = "WORKSPACE_DIR"
value = "/workspace/infra"
}
# Soft-unbounded concurrency: this caps simultaneous agent runs;
# excess calls queue FIFO rather than 409/503. Each run peaks ~0.5-1.5Gi
# (claude + terraform), so this and the memory limit are sized together.
env {
name = "MAX_CONCURRENCY"
value = "10"
}
claude-agent: grant shared pod executor powers (Forgejo PR, terragrunt apply, kubectl write, MCP) Elevates the shared claude-agent-service pod (SA claude-agent, ns claude-agent) so the nextcloud-todos-exec agent can run autonomously. Viktor explicitly chose to elevate the SHARED service knowing every agent on the pod inherits these creds — each grant is security-sensitive and flagged inline for review. Vault (stacks/vault/main.tf): - terraform-state k8s-auth role: add `claude-agent` to bound_service_account_names (was only `default` — the pod's own SA token could not log in, so scripts/tg apply died fetching the PG backend password). `default` kept. - terraform-state policy broadened from `database/static-creds/pg-terraform-state` read only to read on database/static-creds/*, database/creds/*, secret/data/* and secret/metadata/* — what stacks read at plan/apply time. FLAG: grants the shared pod broad Vault READ (effectively all app secrets + rotating DB creds); not denied: secret/data/vault. claude-agent-service stack (stacks/claude-agent-service/main.tf): - ExternalSecret: add FORGEJO_TOKEN (secret/ci/global -> forgejo_push_token, viktor-scoped admin PAT) and HA_MCP_URL (secret/openclaw -> ha_sofia_mcp_url). - git-init: add url.insteadOf rewrite to authenticate git pushes to forgejo.viktorbarzin.me with $FORGEJO_TOKEN (PRs opened via Forgejo API). - New claude-agent-exec ClusterRole+Binding: cluster-wide get/list/watch/create/update/patch/delete on core (incl. secrets), apps, batch, networking.k8s.io, rbac roles/rolebindings. Additive to the existing read-only claude-agent role; does NOT bind cluster-admin. FLAG: very broad — close to cluster-admin in blast radius. - Vault login: VAULT_ADDR + VAULT_K8S_ROLE env + vault-token-refresher sidecar (k8s-auth login role=terraform-state every 30m -> shared emptyDir); main container symlinks ~/.vault-token so scripts/tg auto-auths. - MCP: project-scoped .mcp.json at infra repo root wires `ha` (HTTP, ${HA_MCP_URL}) and `paperless` (in-cluster Service, no token in-cluster). Not applied, not pushed — code only, for human review of the privilege grants. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-04 08:04:10 +00:00
# Vault — so `scripts/tg apply` can fetch the Tier-1 PG backend
# password + the broadened app-secret reads. The CLI + scripts/tg
# fall through to $HOME/.vault-token (symlinked above) when
# $VAULT_TOKEN is unset; VAULT_K8S_ROLE tells the refresher which
# role to log in as.
env {
name = "VAULT_ADDR"
value = "http://vault-active.vault.svc.cluster.local:8200"
}
env {
name = "VAULT_K8S_ROLE"
value = "terraform-state"
}
# NOTE on MCP: the HA MCP URL (secret — its path segment is the auth
# token) arrives as env `HA_MCP_URL` via the claude-agent-secrets
# ExternalSecret (env_from above), sourced from Vault
# secret/openclaw -> ha_sofia_mcp_url. The project-scoped .mcp.json
# in the infra repo root references it as ${HA_MCP_URL}. Paperless
# MCP needs no token in-cluster (bearer is enforced only at the
# Traefik ingress), so its in-cluster Service URL is a plain literal
# in .mcp.json.
[claude-agent-service] Add CLAUDE_CODE_OAUTH_TOKEN env var — 1-year long-lived auth ## Context Earlier today we hit a silent auth failure on the upgrade agent: the short-lived `sk-ant-oat01-*` access token in `.credentials.json` had expired and the CLI's refresh path failed (refresh token either stale or invalidated after the creds sat in Vault for 5 days). The real fix isn't "refresh more often" — it's switching to the long-lived auth mechanism `claude setup-token` provides. Unlike `claude login` (OAuth flow → 6–8h access token + refresh token JSON), `setup-token` mints a single opaque token valid for **1 year** that the CLI consumes via `CLAUDE_CODE_OAUTH_TOKEN` env var. No refresh dance, no JSON file, no rotation for a year. ## This change Adds `CLAUDE_CODE_OAUTH_TOKEN` to the existing `claude-agent-secrets` ExternalSecret, sourced from a new `claude_oauth_token` field at `secret/claude-agent-service`. The container already pulls that secret via `envFrom`, so no other wiring needed. The Claude CLI prefers `CLAUDE_CODE_OAUTH_TOKEN` over the OAuth JSON file when both are present, so this is additive — `.credentials.json` stays mounted as a fallback while we validate the long-lived path. Future cleanup can remove the JSON mount entirely. Verified E2E: synthetic DIUN webhook for `docker.io/library/httpd` → n8n → claude-agent-service /execute → agent job `fea5ff70dcfe` completed in 30s with exit_code=0, agent correctly identified no matching stack and aborted without changes. No API auth errors. ## Spares Harvested two additional long-lived tokens and stored them at `secret/claude-agent-service-spare-{1,2}` for failover if the primary is compromised or revoked. Verified both coexist with the primary (no revocation on mint). ## What is NOT in this change - No removal of `.credentials.json` mount or its Vault source (keep as fallback until we've run for 24h on env-var auth with no issues). - No cron rotator — 1-year TTL means this can be a yearly manual rotation, alerted on from Vault metadata. If we add rotation, we'll source from the spares pool rather than minting new tokens. ## Reproduce locally ``` 1. vault login -method=oidc 2. vault kv get -field=claude_oauth_token secret/claude-agent-service | head -c 25 3. cd stacks/claude-agent-service && ../../scripts/tg apply 4. kubectl -n claude-agent exec deploy/claude-agent-service -- \ printenv CLAUDE_CODE_OAUTH_TOKEN # should be 108 chars 5. Fire synthetic DIUN webhook (see docs/architecture/automated-upgrades.md) ``` Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 12:12:30 +00:00
liveness_probe {
http_get {
path = "/health"
port = 8080
}
initial_delay_seconds = 10
period_seconds = 30
}
readiness_probe {
http_get {
path = "/health"
port = 8080
}
initial_delay_seconds = 5
period_seconds = 10
}
volume_mount {
name = "workspace"
mount_path = "/workspace"
}
volume_mount {
name = "persistent"
mount_path = "/persistent"
}
[claude-agent-service] Add CLAUDE_CODE_OAUTH_TOKEN env var — 1-year long-lived auth ## Context Earlier today we hit a silent auth failure on the upgrade agent: the short-lived `sk-ant-oat01-*` access token in `.credentials.json` had expired and the CLI's refresh path failed (refresh token either stale or invalidated after the creds sat in Vault for 5 days). The real fix isn't "refresh more often" — it's switching to the long-lived auth mechanism `claude setup-token` provides. Unlike `claude login` (OAuth flow → 6–8h access token + refresh token JSON), `setup-token` mints a single opaque token valid for **1 year** that the CLI consumes via `CLAUDE_CODE_OAUTH_TOKEN` env var. No refresh dance, no JSON file, no rotation for a year. ## This change Adds `CLAUDE_CODE_OAUTH_TOKEN` to the existing `claude-agent-secrets` ExternalSecret, sourced from a new `claude_oauth_token` field at `secret/claude-agent-service`. The container already pulls that secret via `envFrom`, so no other wiring needed. The Claude CLI prefers `CLAUDE_CODE_OAUTH_TOKEN` over the OAuth JSON file when both are present, so this is additive — `.credentials.json` stays mounted as a fallback while we validate the long-lived path. Future cleanup can remove the JSON mount entirely. Verified E2E: synthetic DIUN webhook for `docker.io/library/httpd` → n8n → claude-agent-service /execute → agent job `fea5ff70dcfe` completed in 30s with exit_code=0, agent correctly identified no matching stack and aborted without changes. No API auth errors. ## Spares Harvested two additional long-lived tokens and stored them at `secret/claude-agent-service-spare-{1,2}` for failover if the primary is compromised or revoked. Verified both coexist with the primary (no revocation on mint). ## What is NOT in this change - No removal of `.credentials.json` mount or its Vault source (keep as fallback until we've run for 24h on env-var auth with no issues). - No cron rotator — 1-year TTL means this can be a yearly manual rotation, alerted on from Vault metadata. If we add rotation, we'll source from the spares pool rather than minting new tokens. ## Reproduce locally ``` 1. vault login -method=oidc 2. vault kv get -field=claude_oauth_token secret/claude-agent-service | head -c 25 3. cd stacks/claude-agent-service && ../../scripts/tg apply 4. kubectl -n claude-agent exec deploy/claude-agent-service -- \ printenv CLAUDE_CODE_OAUTH_TOKEN # should be 108 chars 5. Fire synthetic DIUN webhook (see docs/architecture/automated-upgrades.md) ``` Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 12:12:30 +00:00
volume_mount {
name = "sops-age-key"
mount_path = "/home/agent/.config/sops/age"
}
volume_mount {
name = "claude-home"
mount_path = "/home/agent/.claude"
}
# git-crypt key — each job re-unlocks its own clone, so the runtime
# container (not just the git-init init container) needs the key.
volume_mount {
name = "git-crypt-key"
mount_path = "/secrets/git-crypt"
}
claude-agent: grant shared pod executor powers (Forgejo PR, terragrunt apply, kubectl write, MCP) Elevates the shared claude-agent-service pod (SA claude-agent, ns claude-agent) so the nextcloud-todos-exec agent can run autonomously. Viktor explicitly chose to elevate the SHARED service knowing every agent on the pod inherits these creds — each grant is security-sensitive and flagged inline for review. Vault (stacks/vault/main.tf): - terraform-state k8s-auth role: add `claude-agent` to bound_service_account_names (was only `default` — the pod's own SA token could not log in, so scripts/tg apply died fetching the PG backend password). `default` kept. - terraform-state policy broadened from `database/static-creds/pg-terraform-state` read only to read on database/static-creds/*, database/creds/*, secret/data/* and secret/metadata/* — what stacks read at plan/apply time. FLAG: grants the shared pod broad Vault READ (effectively all app secrets + rotating DB creds); not denied: secret/data/vault. claude-agent-service stack (stacks/claude-agent-service/main.tf): - ExternalSecret: add FORGEJO_TOKEN (secret/ci/global -> forgejo_push_token, viktor-scoped admin PAT) and HA_MCP_URL (secret/openclaw -> ha_sofia_mcp_url). - git-init: add url.insteadOf rewrite to authenticate git pushes to forgejo.viktorbarzin.me with $FORGEJO_TOKEN (PRs opened via Forgejo API). - New claude-agent-exec ClusterRole+Binding: cluster-wide get/list/watch/create/update/patch/delete on core (incl. secrets), apps, batch, networking.k8s.io, rbac roles/rolebindings. Additive to the existing read-only claude-agent role; does NOT bind cluster-admin. FLAG: very broad — close to cluster-admin in blast radius. - Vault login: VAULT_ADDR + VAULT_K8S_ROLE env + vault-token-refresher sidecar (k8s-auth login role=terraform-state every 30m -> shared emptyDir); main container symlinks ~/.vault-token so scripts/tg auto-auths. - MCP: project-scoped .mcp.json at infra repo root wires `ha` (HTTP, ${HA_MCP_URL}) and `paperless` (in-cluster Service, no token in-cluster). Not applied, not pushed — code only, for human review of the privilege grants. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-04 08:04:10 +00:00
# Shared Vault token written by the vault-token-refresher sidecar.
# Symlinked to $HOME/.vault-token by the container command above.
volume_mount {
name = "vault-token"
mount_path = "/vault"
}
# Burstable (tier-aux). Sized for ~10 concurrent agent runs at
# ~0.5-1.5Gi each (see MAX_CONCURRENCY). No CPU limit per cluster
# policy (CFS throttling); request only.
[claude-agent-service] Add CLAUDE_CODE_OAUTH_TOKEN env var — 1-year long-lived auth ## Context Earlier today we hit a silent auth failure on the upgrade agent: the short-lived `sk-ant-oat01-*` access token in `.credentials.json` had expired and the CLI's refresh path failed (refresh token either stale or invalidated after the creds sat in Vault for 5 days). The real fix isn't "refresh more often" — it's switching to the long-lived auth mechanism `claude setup-token` provides. Unlike `claude login` (OAuth flow → 6–8h access token + refresh token JSON), `setup-token` mints a single opaque token valid for **1 year** that the CLI consumes via `CLAUDE_CODE_OAUTH_TOKEN` env var. No refresh dance, no JSON file, no rotation for a year. ## This change Adds `CLAUDE_CODE_OAUTH_TOKEN` to the existing `claude-agent-secrets` ExternalSecret, sourced from a new `claude_oauth_token` field at `secret/claude-agent-service`. The container already pulls that secret via `envFrom`, so no other wiring needed. The Claude CLI prefers `CLAUDE_CODE_OAUTH_TOKEN` over the OAuth JSON file when both are present, so this is additive — `.credentials.json` stays mounted as a fallback while we validate the long-lived path. Future cleanup can remove the JSON mount entirely. Verified E2E: synthetic DIUN webhook for `docker.io/library/httpd` → n8n → claude-agent-service /execute → agent job `fea5ff70dcfe` completed in 30s with exit_code=0, agent correctly identified no matching stack and aborted without changes. No API auth errors. ## Spares Harvested two additional long-lived tokens and stored them at `secret/claude-agent-service-spare-{1,2}` for failover if the primary is compromised or revoked. Verified both coexist with the primary (no revocation on mint). ## What is NOT in this change - No removal of `.credentials.json` mount or its Vault source (keep as fallback until we've run for 24h on env-var auth with no issues). - No cron rotator — 1-year TTL means this can be a yearly manual rotation, alerted on from Vault metadata. If we add rotation, we'll source from the spares pool rather than minting new tokens. ## Reproduce locally ``` 1. vault login -method=oidc 2. vault kv get -field=claude_oauth_token secret/claude-agent-service | head -c 25 3. cd stacks/claude-agent-service && ../../scripts/tg apply 4. kubectl -n claude-agent exec deploy/claude-agent-service -- \ printenv CLAUDE_CODE_OAUTH_TOKEN # should be 108 chars 5. Fire synthetic DIUN webhook (see docs/architecture/automated-upgrades.md) ``` Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 12:12:30 +00:00
resources {
requests = {
cpu = "1"
memory = "2Gi"
[claude-agent-service] Add CLAUDE_CODE_OAUTH_TOKEN env var — 1-year long-lived auth ## Context Earlier today we hit a silent auth failure on the upgrade agent: the short-lived `sk-ant-oat01-*` access token in `.credentials.json` had expired and the CLI's refresh path failed (refresh token either stale or invalidated after the creds sat in Vault for 5 days). The real fix isn't "refresh more often" — it's switching to the long-lived auth mechanism `claude setup-token` provides. Unlike `claude login` (OAuth flow → 6–8h access token + refresh token JSON), `setup-token` mints a single opaque token valid for **1 year** that the CLI consumes via `CLAUDE_CODE_OAUTH_TOKEN` env var. No refresh dance, no JSON file, no rotation for a year. ## This change Adds `CLAUDE_CODE_OAUTH_TOKEN` to the existing `claude-agent-secrets` ExternalSecret, sourced from a new `claude_oauth_token` field at `secret/claude-agent-service`. The container already pulls that secret via `envFrom`, so no other wiring needed. The Claude CLI prefers `CLAUDE_CODE_OAUTH_TOKEN` over the OAuth JSON file when both are present, so this is additive — `.credentials.json` stays mounted as a fallback while we validate the long-lived path. Future cleanup can remove the JSON mount entirely. Verified E2E: synthetic DIUN webhook for `docker.io/library/httpd` → n8n → claude-agent-service /execute → agent job `fea5ff70dcfe` completed in 30s with exit_code=0, agent correctly identified no matching stack and aborted without changes. No API auth errors. ## Spares Harvested two additional long-lived tokens and stored them at `secret/claude-agent-service-spare-{1,2}` for failover if the primary is compromised or revoked. Verified both coexist with the primary (no revocation on mint). ## What is NOT in this change - No removal of `.credentials.json` mount or its Vault source (keep as fallback until we've run for 24h on env-var auth with no issues). - No cron rotator — 1-year TTL means this can be a yearly manual rotation, alerted on from Vault metadata. If we add rotation, we'll source from the spares pool rather than minting new tokens. ## Reproduce locally ``` 1. vault login -method=oidc 2. vault kv get -field=claude_oauth_token secret/claude-agent-service | head -c 25 3. cd stacks/claude-agent-service && ../../scripts/tg apply 4. kubectl -n claude-agent exec deploy/claude-agent-service -- \ printenv CLAUDE_CODE_OAUTH_TOKEN # should be 108 chars 5. Fire synthetic DIUN webhook (see docs/architecture/automated-upgrades.md) ``` Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 12:12:30 +00:00
}
limits = {
memory = "12Gi"
[claude-agent-service] Add CLAUDE_CODE_OAUTH_TOKEN env var — 1-year long-lived auth ## Context Earlier today we hit a silent auth failure on the upgrade agent: the short-lived `sk-ant-oat01-*` access token in `.credentials.json` had expired and the CLI's refresh path failed (refresh token either stale or invalidated after the creds sat in Vault for 5 days). The real fix isn't "refresh more often" — it's switching to the long-lived auth mechanism `claude setup-token` provides. Unlike `claude login` (OAuth flow → 6–8h access token + refresh token JSON), `setup-token` mints a single opaque token valid for **1 year** that the CLI consumes via `CLAUDE_CODE_OAUTH_TOKEN` env var. No refresh dance, no JSON file, no rotation for a year. ## This change Adds `CLAUDE_CODE_OAUTH_TOKEN` to the existing `claude-agent-secrets` ExternalSecret, sourced from a new `claude_oauth_token` field at `secret/claude-agent-service`. The container already pulls that secret via `envFrom`, so no other wiring needed. The Claude CLI prefers `CLAUDE_CODE_OAUTH_TOKEN` over the OAuth JSON file when both are present, so this is additive — `.credentials.json` stays mounted as a fallback while we validate the long-lived path. Future cleanup can remove the JSON mount entirely. Verified E2E: synthetic DIUN webhook for `docker.io/library/httpd` → n8n → claude-agent-service /execute → agent job `fea5ff70dcfe` completed in 30s with exit_code=0, agent correctly identified no matching stack and aborted without changes. No API auth errors. ## Spares Harvested two additional long-lived tokens and stored them at `secret/claude-agent-service-spare-{1,2}` for failover if the primary is compromised or revoked. Verified both coexist with the primary (no revocation on mint). ## What is NOT in this change - No removal of `.credentials.json` mount or its Vault source (keep as fallback until we've run for 24h on env-var auth with no issues). - No cron rotator — 1-year TTL means this can be a yearly manual rotation, alerted on from Vault metadata. If we add rotation, we'll source from the spares pool rather than minting new tokens. ## Reproduce locally ``` 1. vault login -method=oidc 2. vault kv get -field=claude_oauth_token secret/claude-agent-service | head -c 25 3. cd stacks/claude-agent-service && ../../scripts/tg apply 4. kubectl -n claude-agent exec deploy/claude-agent-service -- \ printenv CLAUDE_CODE_OAUTH_TOKEN # should be 108 chars 5. Fire synthetic DIUN webhook (see docs/architecture/automated-upgrades.md) ``` Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 12:12:30 +00:00
}
}
}
claude-agent: grant shared pod executor powers (Forgejo PR, terragrunt apply, kubectl write, MCP) Elevates the shared claude-agent-service pod (SA claude-agent, ns claude-agent) so the nextcloud-todos-exec agent can run autonomously. Viktor explicitly chose to elevate the SHARED service knowing every agent on the pod inherits these creds — each grant is security-sensitive and flagged inline for review. Vault (stacks/vault/main.tf): - terraform-state k8s-auth role: add `claude-agent` to bound_service_account_names (was only `default` — the pod's own SA token could not log in, so scripts/tg apply died fetching the PG backend password). `default` kept. - terraform-state policy broadened from `database/static-creds/pg-terraform-state` read only to read on database/static-creds/*, database/creds/*, secret/data/* and secret/metadata/* — what stacks read at plan/apply time. FLAG: grants the shared pod broad Vault READ (effectively all app secrets + rotating DB creds); not denied: secret/data/vault. claude-agent-service stack (stacks/claude-agent-service/main.tf): - ExternalSecret: add FORGEJO_TOKEN (secret/ci/global -> forgejo_push_token, viktor-scoped admin PAT) and HA_MCP_URL (secret/openclaw -> ha_sofia_mcp_url). - git-init: add url.insteadOf rewrite to authenticate git pushes to forgejo.viktorbarzin.me with $FORGEJO_TOKEN (PRs opened via Forgejo API). - New claude-agent-exec ClusterRole+Binding: cluster-wide get/list/watch/create/update/patch/delete on core (incl. secrets), apps, batch, networking.k8s.io, rbac roles/rolebindings. Additive to the existing read-only claude-agent role; does NOT bind cluster-admin. FLAG: very broad — close to cluster-admin in blast radius. - Vault login: VAULT_ADDR + VAULT_K8S_ROLE env + vault-token-refresher sidecar (k8s-auth login role=terraform-state every 30m -> shared emptyDir); main container symlinks ~/.vault-token so scripts/tg auto-auths. - MCP: project-scoped .mcp.json at infra repo root wires `ha` (HTTP, ${HA_MCP_URL}) and `paperless` (in-cluster Service, no token in-cluster). Not applied, not pushed — code only, for human review of the privilege grants. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-04 08:04:10 +00:00
# Sidecar: keep a fresh Vault token on disk for `scripts/tg apply`.
# k8s-auth login (role=terraform-state) every 30 min — well inside the
# 6-day token TTL — and write it to the shared `vault-token` emptyDir.
# The main container symlinks $HOME/.vault-token at it. Mirrors the
# estate k8s-auth-login pattern (infra/.woodpecker/default.yml "Vault
# auth" step, woodpecker vault-sync sidecar).
container {
name = "vault-token-refresher"
image = "docker.io/curlimages/curl:8.11.0"
# No `set -e`: a transient Vault blip must NOT kill the refresh loop
# (the stale token keeps working until its 6d TTL). curlimages/curl
# is Alpine/busybox — has `sed`, no `jq`, so parse client_token with
# sed. umask 077 so the token file is 0600.
command = ["/bin/sh", "-c", <<-EOF
umask 077
while true; do
SA_TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
TOKEN=$(curl -s -X POST "$VAULT_ADDR/v1/auth/kubernetes/login" \
-d "{\"role\":\"$VAULT_K8S_ROLE\",\"jwt\":\"$SA_TOKEN\"}" \
| sed -n 's/.*"client_token":"\([^"]*\)".*/\1/p')
if [ -n "$TOKEN" ]; then
printf '%s' "$TOKEN" > /vault/token
echo "$(date -u +%FT%TZ) refreshed vault token (role=$VAULT_K8S_ROLE)"
else
echo "$(date -u +%FT%TZ) ERROR: vault k8s login failed (role=$VAULT_K8S_ROLE)" >&2
fi
sleep 1800
done
EOF
]
env {
name = "VAULT_ADDR"
value = "http://vault-active.vault.svc.cluster.local:8200"
}
env {
name = "VAULT_K8S_ROLE"
value = "terraform-state"
}
volume_mount {
name = "vault-token"
mount_path = "/vault"
}
resources {
requests = { cpu = "5m", memory = "16Mi" }
limits = { memory = "32Mi" }
}
}
[claude-agent-service] Add CLAUDE_CODE_OAUTH_TOKEN env var — 1-year long-lived auth ## Context Earlier today we hit a silent auth failure on the upgrade agent: the short-lived `sk-ant-oat01-*` access token in `.credentials.json` had expired and the CLI's refresh path failed (refresh token either stale or invalidated after the creds sat in Vault for 5 days). The real fix isn't "refresh more often" — it's switching to the long-lived auth mechanism `claude setup-token` provides. Unlike `claude login` (OAuth flow → 6–8h access token + refresh token JSON), `setup-token` mints a single opaque token valid for **1 year** that the CLI consumes via `CLAUDE_CODE_OAUTH_TOKEN` env var. No refresh dance, no JSON file, no rotation for a year. ## This change Adds `CLAUDE_CODE_OAUTH_TOKEN` to the existing `claude-agent-secrets` ExternalSecret, sourced from a new `claude_oauth_token` field at `secret/claude-agent-service`. The container already pulls that secret via `envFrom`, so no other wiring needed. The Claude CLI prefers `CLAUDE_CODE_OAUTH_TOKEN` over the OAuth JSON file when both are present, so this is additive — `.credentials.json` stays mounted as a fallback while we validate the long-lived path. Future cleanup can remove the JSON mount entirely. Verified E2E: synthetic DIUN webhook for `docker.io/library/httpd` → n8n → claude-agent-service /execute → agent job `fea5ff70dcfe` completed in 30s with exit_code=0, agent correctly identified no matching stack and aborted without changes. No API auth errors. ## Spares Harvested two additional long-lived tokens and stored them at `secret/claude-agent-service-spare-{1,2}` for failover if the primary is compromised or revoked. Verified both coexist with the primary (no revocation on mint). ## What is NOT in this change - No removal of `.credentials.json` mount or its Vault source (keep as fallback until we've run for 24h on env-var auth with no issues). - No cron rotator — 1-year TTL means this can be a yearly manual rotation, alerted on from Vault metadata. If we add rotation, we'll source from the spares pool rather than minting new tokens. ## Reproduce locally ``` 1. vault login -method=oidc 2. vault kv get -field=claude_oauth_token secret/claude-agent-service | head -c 25 3. cd stacks/claude-agent-service && ../../scripts/tg apply 4. kubectl -n claude-agent exec deploy/claude-agent-service -- \ printenv CLAUDE_CODE_OAUTH_TOKEN # should be 108 chars 5. Fire synthetic DIUN webhook (see docs/architecture/automated-upgrades.md) ``` Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 12:12:30 +00:00
volume {
name = "workspace"
# Per-pod ephemeral scratch — agent does fresh git clones each
# job, so node-disk emptyDir is faster than a network-backed PVC
# and avoids RWO contention across the 3 replicas.
empty_dir {}
}
volume {
name = "persistent"
[claude-agent-service] Add CLAUDE_CODE_OAUTH_TOKEN env var — 1-year long-lived auth ## Context Earlier today we hit a silent auth failure on the upgrade agent: the short-lived `sk-ant-oat01-*` access token in `.credentials.json` had expired and the CLI's refresh path failed (refresh token either stale or invalidated after the creds sat in Vault for 5 days). The real fix isn't "refresh more often" — it's switching to the long-lived auth mechanism `claude setup-token` provides. Unlike `claude login` (OAuth flow → 6–8h access token + refresh token JSON), `setup-token` mints a single opaque token valid for **1 year** that the CLI consumes via `CLAUDE_CODE_OAUTH_TOKEN` env var. No refresh dance, no JSON file, no rotation for a year. ## This change Adds `CLAUDE_CODE_OAUTH_TOKEN` to the existing `claude-agent-secrets` ExternalSecret, sourced from a new `claude_oauth_token` field at `secret/claude-agent-service`. The container already pulls that secret via `envFrom`, so no other wiring needed. The Claude CLI prefers `CLAUDE_CODE_OAUTH_TOKEN` over the OAuth JSON file when both are present, so this is additive — `.credentials.json` stays mounted as a fallback while we validate the long-lived path. Future cleanup can remove the JSON mount entirely. Verified E2E: synthetic DIUN webhook for `docker.io/library/httpd` → n8n → claude-agent-service /execute → agent job `fea5ff70dcfe` completed in 30s with exit_code=0, agent correctly identified no matching stack and aborted without changes. No API auth errors. ## Spares Harvested two additional long-lived tokens and stored them at `secret/claude-agent-service-spare-{1,2}` for failover if the primary is compromised or revoked. Verified both coexist with the primary (no revocation on mint). ## What is NOT in this change - No removal of `.credentials.json` mount or its Vault source (keep as fallback until we've run for 24h on env-var auth with no issues). - No cron rotator — 1-year TTL means this can be a yearly manual rotation, alerted on from Vault metadata. If we add rotation, we'll source from the spares pool rather than minting new tokens. ## Reproduce locally ``` 1. vault login -method=oidc 2. vault kv get -field=claude_oauth_token secret/claude-agent-service | head -c 25 3. cd stacks/claude-agent-service && ../../scripts/tg apply 4. kubectl -n claude-agent exec deploy/claude-agent-service -- \ printenv CLAUDE_CODE_OAUTH_TOKEN # should be 108 chars 5. Fire synthetic DIUN webhook (see docs/architecture/automated-upgrades.md) ``` Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 12:12:30 +00:00
persistent_volume_claim {
claim_name = module.persistent.claim_name
[claude-agent-service] Add CLAUDE_CODE_OAUTH_TOKEN env var — 1-year long-lived auth ## Context Earlier today we hit a silent auth failure on the upgrade agent: the short-lived `sk-ant-oat01-*` access token in `.credentials.json` had expired and the CLI's refresh path failed (refresh token either stale or invalidated after the creds sat in Vault for 5 days). The real fix isn't "refresh more often" — it's switching to the long-lived auth mechanism `claude setup-token` provides. Unlike `claude login` (OAuth flow → 6–8h access token + refresh token JSON), `setup-token` mints a single opaque token valid for **1 year** that the CLI consumes via `CLAUDE_CODE_OAUTH_TOKEN` env var. No refresh dance, no JSON file, no rotation for a year. ## This change Adds `CLAUDE_CODE_OAUTH_TOKEN` to the existing `claude-agent-secrets` ExternalSecret, sourced from a new `claude_oauth_token` field at `secret/claude-agent-service`. The container already pulls that secret via `envFrom`, so no other wiring needed. The Claude CLI prefers `CLAUDE_CODE_OAUTH_TOKEN` over the OAuth JSON file when both are present, so this is additive — `.credentials.json` stays mounted as a fallback while we validate the long-lived path. Future cleanup can remove the JSON mount entirely. Verified E2E: synthetic DIUN webhook for `docker.io/library/httpd` → n8n → claude-agent-service /execute → agent job `fea5ff70dcfe` completed in 30s with exit_code=0, agent correctly identified no matching stack and aborted without changes. No API auth errors. ## Spares Harvested two additional long-lived tokens and stored them at `secret/claude-agent-service-spare-{1,2}` for failover if the primary is compromised or revoked. Verified both coexist with the primary (no revocation on mint). ## What is NOT in this change - No removal of `.credentials.json` mount or its Vault source (keep as fallback until we've run for 24h on env-var auth with no issues). - No cron rotator — 1-year TTL means this can be a yearly manual rotation, alerted on from Vault metadata. If we add rotation, we'll source from the spares pool rather than minting new tokens. ## Reproduce locally ``` 1. vault login -method=oidc 2. vault kv get -field=claude_oauth_token secret/claude-agent-service | head -c 25 3. cd stacks/claude-agent-service && ../../scripts/tg apply 4. kubectl -n claude-agent exec deploy/claude-agent-service -- \ printenv CLAUDE_CODE_OAUTH_TOKEN # should be 108 chars 5. Fire synthetic DIUN webhook (see docs/architecture/automated-upgrades.md) ``` Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 12:12:30 +00:00
}
}
volume {
name = "sops-age-key"
secret {
secret_name = kubernetes_secret.sops_age_key.metadata[0].name
default_mode = "0600"
}
}
volume {
name = "git-crypt-key"
config_map {
name = kubernetes_config_map.git_crypt_key.metadata[0].name
}
}
volume {
name = "claude-credentials-secret"
secret {
secret_name = kubernetes_secret.claude_credentials.metadata[0].name
default_mode = "0600"
}
}
volume {
name = "claude-home"
empty_dir {}
}
claude-agent: grant shared pod executor powers (Forgejo PR, terragrunt apply, kubectl write, MCP) Elevates the shared claude-agent-service pod (SA claude-agent, ns claude-agent) so the nextcloud-todos-exec agent can run autonomously. Viktor explicitly chose to elevate the SHARED service knowing every agent on the pod inherits these creds — each grant is security-sensitive and flagged inline for review. Vault (stacks/vault/main.tf): - terraform-state k8s-auth role: add `claude-agent` to bound_service_account_names (was only `default` — the pod's own SA token could not log in, so scripts/tg apply died fetching the PG backend password). `default` kept. - terraform-state policy broadened from `database/static-creds/pg-terraform-state` read only to read on database/static-creds/*, database/creds/*, secret/data/* and secret/metadata/* — what stacks read at plan/apply time. FLAG: grants the shared pod broad Vault READ (effectively all app secrets + rotating DB creds); not denied: secret/data/vault. claude-agent-service stack (stacks/claude-agent-service/main.tf): - ExternalSecret: add FORGEJO_TOKEN (secret/ci/global -> forgejo_push_token, viktor-scoped admin PAT) and HA_MCP_URL (secret/openclaw -> ha_sofia_mcp_url). - git-init: add url.insteadOf rewrite to authenticate git pushes to forgejo.viktorbarzin.me with $FORGEJO_TOKEN (PRs opened via Forgejo API). - New claude-agent-exec ClusterRole+Binding: cluster-wide get/list/watch/create/update/patch/delete on core (incl. secrets), apps, batch, networking.k8s.io, rbac roles/rolebindings. Additive to the existing read-only claude-agent role; does NOT bind cluster-admin. FLAG: very broad — close to cluster-admin in blast radius. - Vault login: VAULT_ADDR + VAULT_K8S_ROLE env + vault-token-refresher sidecar (k8s-auth login role=terraform-state every 30m -> shared emptyDir); main container symlinks ~/.vault-token so scripts/tg auto-auths. - MCP: project-scoped .mcp.json at infra repo root wires `ha` (HTTP, ${HA_MCP_URL}) and `paperless` (in-cluster Service, no token in-cluster). Not applied, not pushed — code only, for human review of the privilege grants. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-04 08:04:10 +00:00
# Holds the Vault token the refresher sidecar mints; main container
# symlinks $HOME/.vault-token at /vault/token. emptyDir (memory-backed
# not required) — token is re-minted every 30 min and on pod restart.
volume {
name = "vault-token"
empty_dir {}
}
[claude-agent-service] Add CLAUDE_CODE_OAUTH_TOKEN env var — 1-year long-lived auth ## Context Earlier today we hit a silent auth failure on the upgrade agent: the short-lived `sk-ant-oat01-*` access token in `.credentials.json` had expired and the CLI's refresh path failed (refresh token either stale or invalidated after the creds sat in Vault for 5 days). The real fix isn't "refresh more often" — it's switching to the long-lived auth mechanism `claude setup-token` provides. Unlike `claude login` (OAuth flow → 6–8h access token + refresh token JSON), `setup-token` mints a single opaque token valid for **1 year** that the CLI consumes via `CLAUDE_CODE_OAUTH_TOKEN` env var. No refresh dance, no JSON file, no rotation for a year. ## This change Adds `CLAUDE_CODE_OAUTH_TOKEN` to the existing `claude-agent-secrets` ExternalSecret, sourced from a new `claude_oauth_token` field at `secret/claude-agent-service`. The container already pulls that secret via `envFrom`, so no other wiring needed. The Claude CLI prefers `CLAUDE_CODE_OAUTH_TOKEN` over the OAuth JSON file when both are present, so this is additive — `.credentials.json` stays mounted as a fallback while we validate the long-lived path. Future cleanup can remove the JSON mount entirely. Verified E2E: synthetic DIUN webhook for `docker.io/library/httpd` → n8n → claude-agent-service /execute → agent job `fea5ff70dcfe` completed in 30s with exit_code=0, agent correctly identified no matching stack and aborted without changes. No API auth errors. ## Spares Harvested two additional long-lived tokens and stored them at `secret/claude-agent-service-spare-{1,2}` for failover if the primary is compromised or revoked. Verified both coexist with the primary (no revocation on mint). ## What is NOT in this change - No removal of `.credentials.json` mount or its Vault source (keep as fallback until we've run for 24h on env-var auth with no issues). - No cron rotator — 1-year TTL means this can be a yearly manual rotation, alerted on from Vault metadata. If we add rotation, we'll source from the spares pool rather than minting new tokens. ## Reproduce locally ``` 1. vault login -method=oidc 2. vault kv get -field=claude_oauth_token secret/claude-agent-service | head -c 25 3. cd stacks/claude-agent-service && ../../scripts/tg apply 4. kubectl -n claude-agent exec deploy/claude-agent-service -- \ printenv CLAUDE_CODE_OAUTH_TOKEN # should be 108 chars 5. Fire synthetic DIUN webhook (see docs/architecture/automated-upgrades.md) ``` Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 12:12:30 +00:00
}
}
}
lifecycle {
[infra] Establish KYVERNO_LIFECYCLE_V1 drift-suppression convention [ci skip] ## Context Phase 1 of the state-drift consolidation audit (plan Wave 3) identified that the entire repo leans on a repeated `lifecycle { ignore_changes = [...dns_config] }` snippet to suppress Kyverno's admission-webhook dns_config mutation (the ndots=2 override that prevents NxDomain search-domain flooding). 27 occurrences across 19 stacks. Without this suppression, every pod-owning resource shows perpetual TF plan drift. The original plan proposed a shared `modules/kubernetes/kyverno_lifecycle/` module emitting the ignore-paths list as an output that stacks would consume in their `ignore_changes` blocks. That approach is architecturally impossible: Terraform's `ignore_changes` meta-argument accepts only static attribute paths — it rejects module outputs, locals, variables, and any expression (the HCL spec evaluates `lifecycle` before the regular expression graph). So a DRY module cannot exist. The canonical pattern IS the repeated snippet. What the snippet was missing was a *discoverability tag* so that (a) new resources can be validated for compliance, (b) the existing 27 sites can be grep'd in a single command, and (c) future maintainers understand the convention rather than each reinventing it. ## This change - Introduces `# KYVERNO_LIFECYCLE_V1` as the canonical marker comment. Attached inline on every `spec[0].template[0].spec[0].dns_config` line (or `spec[0].job_template[0].spec[0]...` for CronJobs) across all 27 existing suppression sites. - Documents the convention with rationale and copy-paste snippets in `AGENTS.md` → new "Kyverno Drift Suppression" section. - Expands the existing `.claude/CLAUDE.md` Kyverno ndots note to reference the marker and explain why the module approach is blocked. - Updates `_template/main.tf.example` so every new stack starts compliant. ## What is NOT in this change - The `kubernetes_manifest` Kyverno annotation drift (beads `code-seq`) — that is Phase B with a sibling `# KYVERNO_MANIFEST_V1` marker. - Behavioral changes — every `ignore_changes` list is byte-identical save for the inline comment. - The fallback module the original plan anticipated — skipped because Terraform rejects expressions in `ignore_changes`. - `terraform fmt` cleanup on adjacent unrelated blocks in three files (claude-agent-service, freedify/factory, hermes-agent). Reverted to keep this commit scoped to the convention rollout. ## Before / after Before (cannot distinguish accidental-forgotten from intentional-convention): ```hcl lifecycle { ignore_changes = [spec[0].template[0].spec[0].dns_config] } ``` After (greppable, self-documenting, discoverable by tooling): ```hcl lifecycle { ignore_changes = [spec[0].template[0].spec[0].dns_config] # KYVERNO_LIFECYCLE_V1 } ``` ## Test Plan ### Automated ``` $ rg -c 'KYVERNO_LIFECYCLE_V1' stacks/ --include='*.tf' --include='*.tf.example' \ | awk -F: '{s+=$2} END {print s}' 27 $ git diff --stat | grep -E '\.(tf|tf\.example|md)$' | wc -l 21 # All code-file diffs are 1 insertion + 1 deletion per marker site, # except beads-server (3), ebooks (4), immich (3), uptime-kuma (2). $ git diff --stat stacks/ | tail -1 20 files changed, 45 insertions(+), 28 deletions(-) ``` ### Manual Verification No apply required — HCL comments only. Zero effect on any stack's plan output. Future audits: `rg 'KYVERNO_LIFECYCLE_V1' stacks/ | wc -l` must grow as new pod-owning resources are added. ## Reproduce locally 1. `cd infra && git pull` 2. `rg 'KYVERNO_LIFECYCLE_V1' stacks/` → expect 27 hits in 19 files 3. Grep any new `kubernetes_deployment` for the marker; absence = missing suppression. Closes: code-28m Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 14:15:51 +00:00
ignore_changes = [spec[0].template[0].spec[0].dns_config] # KYVERNO_LIFECYCLE_V1
[claude-agent-service] Add CLAUDE_CODE_OAUTH_TOKEN env var — 1-year long-lived auth ## Context Earlier today we hit a silent auth failure on the upgrade agent: the short-lived `sk-ant-oat01-*` access token in `.credentials.json` had expired and the CLI's refresh path failed (refresh token either stale or invalidated after the creds sat in Vault for 5 days). The real fix isn't "refresh more often" — it's switching to the long-lived auth mechanism `claude setup-token` provides. Unlike `claude login` (OAuth flow → 6–8h access token + refresh token JSON), `setup-token` mints a single opaque token valid for **1 year** that the CLI consumes via `CLAUDE_CODE_OAUTH_TOKEN` env var. No refresh dance, no JSON file, no rotation for a year. ## This change Adds `CLAUDE_CODE_OAUTH_TOKEN` to the existing `claude-agent-secrets` ExternalSecret, sourced from a new `claude_oauth_token` field at `secret/claude-agent-service`. The container already pulls that secret via `envFrom`, so no other wiring needed. The Claude CLI prefers `CLAUDE_CODE_OAUTH_TOKEN` over the OAuth JSON file when both are present, so this is additive — `.credentials.json` stays mounted as a fallback while we validate the long-lived path. Future cleanup can remove the JSON mount entirely. Verified E2E: synthetic DIUN webhook for `docker.io/library/httpd` → n8n → claude-agent-service /execute → agent job `fea5ff70dcfe` completed in 30s with exit_code=0, agent correctly identified no matching stack and aborted without changes. No API auth errors. ## Spares Harvested two additional long-lived tokens and stored them at `secret/claude-agent-service-spare-{1,2}` for failover if the primary is compromised or revoked. Verified both coexist with the primary (no revocation on mint). ## What is NOT in this change - No removal of `.credentials.json` mount or its Vault source (keep as fallback until we've run for 24h on env-var auth with no issues). - No cron rotator — 1-year TTL means this can be a yearly manual rotation, alerted on from Vault metadata. If we add rotation, we'll source from the spares pool rather than minting new tokens. ## Reproduce locally ``` 1. vault login -method=oidc 2. vault kv get -field=claude_oauth_token secret/claude-agent-service | head -c 25 3. cd stacks/claude-agent-service && ../../scripts/tg apply 4. kubectl -n claude-agent exec deploy/claude-agent-service -- \ printenv CLAUDE_CODE_OAUTH_TOKEN # should be 108 chars 5. Fire synthetic DIUN webhook (see docs/architecture/automated-upgrades.md) ``` Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 12:12:30 +00:00
}
}
# --- Service ---
resource "kubernetes_service" "claude_agent" {
metadata {
name = "claude-agent-service"
namespace = kubernetes_namespace.claude_agent.metadata[0].name
labels = local.labels
}
spec {
selector = local.labels
port {
port = 8080
target_port = 8080
}
type = "ClusterIP"
}
}
[monitoring] Add Claude OAuth token expiry monitoring + alerts ## Context The new CLAUDE_CODE_OAUTH_TOKEN mechanism (commit 8a054752) uses long-lived 1-year tokens minted via `claude setup-token`. Tokens don't auto-refresh — at the 1-year mark they expire hard and the upgrade agent stops working. We need to be told 30 days ahead, not find out when DIUN fires and gets 401 again. A cron rotator doesn't make sense here (tokens don't refresh, they just expire) so we alert instead. Two spares at `secret/claude-agent-service-spare-{1,2}` provide failover runway — monitor covers all three. ## This change **CronJob** (`claude-agent` ns, every 6h): reads a ConfigMap containing `<path> → expiry_unix_timestamp` entries, pushes `claude_oauth_token_expiry_timestamp{path="..."}` and `claude_oauth_expiry_monitor_last_push_timestamp` to Pushgateway at `prometheus-prometheus-pushgateway.monitoring:9091`. **ConfigMap** generated from a Terraform local `claude_oauth_token_mint_epochs` — source of truth for mint times. On rotation, update the map + apply. TTL is a shared local (365d). **PrometheusRules** (in prometheus_chart_values.tpl): - `ClaudeOAuthTokenExpiringSoon` — <30d, warning, for 1h - `ClaudeOAuthTokenCritical` — <7d, critical, for 10m - `ClaudeOAuthTokenMonitorStale` — last push >48h, warning - `ClaudeOAuthTokenMonitorNeverRun` — metric absent for 2h, warning Alert labels include `{{ $labels.path }}` so we know which token is expiring (primary / spare-1 / spare-2). ## Verification ``` $ kubectl -n claude-agent create job --from=cronjob/claude-oauth-expiry-monitor manual $ curl pushgateway/metrics | grep claude_oauth_token_expiry claude_oauth_token_expiry_timestamp{...,path="primary"} 1.808064429e+09 claude_oauth_token_expiry_timestamp{...,path="spare-1"} 1.80806428e+09 claude_oauth_token_expiry_timestamp{...,path="spare-2"} 1.808064429e+09 $ query: (claude_oauth_token_expiry_timestamp - time()) / 86400 primary: 365.2 days spare-1: 365.2 days spare-2: 365.2 days ``` ## Rotation playbook (future) 1. `kubectl run -it --rm --image=registry.viktorbarzin.me/claude-agent-service:latest tokmint -- claude setup-token` (or harvest via `harvest3.py` pattern in memory for headless flow) 2. `vault kv patch secret/claude-agent-service claude_oauth_token=<new>` 3. Update `claude_oauth_token_mint_epochs["primary"]` in `stacks/claude-agent-service/main.tf` with new unix timestamp 4. `scripts/tg apply` claude-agent-service + monitoring 5. Alert clears within 6h (next cron tick) + 1h of the `ClaudeOAuthTokenExpiringSoon` "for:" duration Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 12:27:11 +00:00
# =============================================================================
# Token expiry monitor
# Long-lived CLAUDE_CODE_OAUTH_TOKEN values expire 1y after mint. We track
# mint timestamps here — on rotation, update the map below. A CronJob pushes
# the computed expiry_timestamp to Pushgateway, Prometheus alerts 30d out.
# =============================================================================
locals {
claude_oauth_token_mint_epochs = {
# unix seconds (UTC) — when `claude setup-token` finished minting
[infra/claude-agent-service] Seed beads metadata + scratch dir at runtime ## Context Review of the BeadBoard Dispatch wiring found that the claude-agent-service Dockerfile's `COPY beads/metadata.json /workspace/.beads/metadata.json` and `COPY agents/beads-task-runner.md /home/agent/.claude/agents/...` both land on paths that are volume-mounted at runtime: - `/workspace` → `claude-agent-workspace-encrypted` PVC (main.tf:394-398) - `/home/agent/.claude` → `claude-home` emptyDir (main.tf:424-427) Kubernetes mounts hide image-layer content at those paths, so the COPYs are dead. The companion commit in `claude-agent-service` restages both files to `/usr/share/agent-seed/` (an image-layer path that is never mounted). Additionally, the beads-task-runner agent rails expect `/workspace/scratch/<job_id>/` to exist, but nothing was creating it. ## Layout before / after ``` Before (dead COPYs): image layer runtime (mounted volumes hide the files) ----------- ----------------------------------- /workspace/ <- hidden by PVC mount .beads/ metadata.json <- UNREACHABLE /home/agent/.claude/ <- hidden by emptyDir mount agents/ beads-task-runner.md <- UNREACHABLE After (init container seeds volumes at pod start): image layer runtime ----------- ------------------------------------ /usr/share/agent-seed/ beads-metadata.json --+ beads-task-runner.md --+-> copied by seed-beads-agent init container into the mounted volumes on every pod start: /workspace/.beads/metadata.json /workspace/scratch/ /home/agent/.claude/agents/beads-task-runner.md ``` ## What ### New init container: `seed-beads-agent` - Positioned AFTER `git-init`, BEFORE the main container. - Uses the same service image (`${local.image}:${local.image_tag}`) — the seed files are baked in at `/usr/share/agent-seed/`. - Runs as default uid 1000 (the PVCs are already chowned by `fix-perms`). - Shell body: mkdir -p /workspace/.beads /workspace/scratch /home/agent/.claude/agents cp /usr/share/agent-seed/beads-metadata.json /workspace/.beads/metadata.json cp /usr/share/agent-seed/beads-task-runner.md /home/agent/.claude/agents/beads-task-runner.md - Mounts: `workspace` at `/workspace`, `claude-home` at `/home/agent/.claude`. - Resources: 32Mi requests / 64Mi limits (matches `fix-perms`/`copy-claude-creds`). ### Formatting - `terraform fmt -recursive` also normalised whitespace in the token-expiry locals block and the CronJob container definition. No semantic change. ## What is NOT in this change - No image tag bump. The Dockerfile refactor that produces the `/usr/share/agent-seed/` path lands in the claude-agent-service repo and will roll in on the next CI build. Until that build ships and the tag is bumped in this file, the new init container will `cp` from a path that doesn't exist yet — so do NOT apply this commit until the corresponding image tag bump is ready. The commit is declarative prep. - No changes to storage class, RBAC, Service, or any other init. - The main container mounts remain unchanged — only the init containers prepare volume contents. ## Test Plan ### Automated ``` $ terraform fmt -check -recursive stacks/claude-agent-service/ (no output — clean) $ terraform -chdir=stacks/claude-agent-service/ init -backend=false Terraform has been successfully initialized! $ terraform -chdir=stacks/claude-agent-service/ validate Warning: Deprecated Resource (pre-existing; use kubernetes_namespace_v1) Success! The configuration is valid, but there were some validation warnings as shown above. ``` ### Manual Verification (after image bump + apply) 1. Bump `local.image_tag` in main.tf to the SHA of a build that has `/usr/share/agent-seed/*` (verify with `docker inspect $IMAGE | jq ...` or `kubectl run tmp --image ... -- ls /usr/share/agent-seed`). 2. `scripts/tg apply stacks/claude-agent-service` 3. `kubectl -n claude-agent get pods -w` — all init containers complete. 4. `kubectl -n claude-agent exec deploy/claude-agent-service -c claude-agent-service -- ls -la /workspace/.beads/metadata.json /home/agent/.claude/agents/beads-task-runner.md /workspace/scratch` Expected: all three paths exist; first two are regular files with the expected content, `scratch` is a directory. 5. `kubectl -n claude-agent exec deploy/claude-agent-service -c claude-agent-service -- jq -r .dolt_server_host /workspace/.beads/metadata.json` Expected: `dolt.beads-server.svc.cluster.local`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 14:23:19 +00:00
"primary" = 1776528429 # 2026-04-18T12:07:09Z (TOKEN2)
"spare-1" = 1776528280 # 2026-04-18T12:04:40Z (TOKEN1)
"spare-2" = 1776528429 # 2026-04-18T12:07:09Z (TOKEN2 — redundant w/ primary)
[monitoring] Add Claude OAuth token expiry monitoring + alerts ## Context The new CLAUDE_CODE_OAUTH_TOKEN mechanism (commit 8a054752) uses long-lived 1-year tokens minted via `claude setup-token`. Tokens don't auto-refresh — at the 1-year mark they expire hard and the upgrade agent stops working. We need to be told 30 days ahead, not find out when DIUN fires and gets 401 again. A cron rotator doesn't make sense here (tokens don't refresh, they just expire) so we alert instead. Two spares at `secret/claude-agent-service-spare-{1,2}` provide failover runway — monitor covers all three. ## This change **CronJob** (`claude-agent` ns, every 6h): reads a ConfigMap containing `<path> → expiry_unix_timestamp` entries, pushes `claude_oauth_token_expiry_timestamp{path="..."}` and `claude_oauth_expiry_monitor_last_push_timestamp` to Pushgateway at `prometheus-prometheus-pushgateway.monitoring:9091`. **ConfigMap** generated from a Terraform local `claude_oauth_token_mint_epochs` — source of truth for mint times. On rotation, update the map + apply. TTL is a shared local (365d). **PrometheusRules** (in prometheus_chart_values.tpl): - `ClaudeOAuthTokenExpiringSoon` — <30d, warning, for 1h - `ClaudeOAuthTokenCritical` — <7d, critical, for 10m - `ClaudeOAuthTokenMonitorStale` — last push >48h, warning - `ClaudeOAuthTokenMonitorNeverRun` — metric absent for 2h, warning Alert labels include `{{ $labels.path }}` so we know which token is expiring (primary / spare-1 / spare-2). ## Verification ``` $ kubectl -n claude-agent create job --from=cronjob/claude-oauth-expiry-monitor manual $ curl pushgateway/metrics | grep claude_oauth_token_expiry claude_oauth_token_expiry_timestamp{...,path="primary"} 1.808064429e+09 claude_oauth_token_expiry_timestamp{...,path="spare-1"} 1.80806428e+09 claude_oauth_token_expiry_timestamp{...,path="spare-2"} 1.808064429e+09 $ query: (claude_oauth_token_expiry_timestamp - time()) / 86400 primary: 365.2 days spare-1: 365.2 days spare-2: 365.2 days ``` ## Rotation playbook (future) 1. `kubectl run -it --rm --image=registry.viktorbarzin.me/claude-agent-service:latest tokmint -- claude setup-token` (or harvest via `harvest3.py` pattern in memory for headless flow) 2. `vault kv patch secret/claude-agent-service claude_oauth_token=<new>` 3. Update `claude_oauth_token_mint_epochs["primary"]` in `stacks/claude-agent-service/main.tf` with new unix timestamp 4. `scripts/tg apply` claude-agent-service + monitoring 5. Alert clears within 6h (next cron tick) + 1h of the `ClaudeOAuthTokenExpiringSoon` "for:" duration Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 12:27:11 +00:00
}
claude_oauth_token_ttl_seconds = 365 * 24 * 60 * 60
}
resource "kubernetes_config_map" "claude_oauth_expiry" {
metadata {
name = "claude-oauth-expiry"
namespace = kubernetes_namespace.claude_agent.metadata[0].name
}
data = {
for path, mint in local.claude_oauth_token_mint_epochs :
path => tostring(mint + local.claude_oauth_token_ttl_seconds)
}
}
resource "kubernetes_cron_job_v1" "claude_oauth_expiry_monitor" {
metadata {
name = "claude-oauth-expiry-monitor"
namespace = kubernetes_namespace.claude_agent.metadata[0].name
}
spec {
concurrency_policy = "Replace"
failed_jobs_history_limit = 3
successful_jobs_history_limit = 1
schedule = "17 */6 * * *" # every 6h at :17 past
job_template {
metadata {}
spec {
backoff_limit = 1
ttl_seconds_after_finished = 300
template {
metadata {}
spec {
restart_policy = "OnFailure"
container {
[infra/claude-agent-service] Seed beads metadata + scratch dir at runtime ## Context Review of the BeadBoard Dispatch wiring found that the claude-agent-service Dockerfile's `COPY beads/metadata.json /workspace/.beads/metadata.json` and `COPY agents/beads-task-runner.md /home/agent/.claude/agents/...` both land on paths that are volume-mounted at runtime: - `/workspace` → `claude-agent-workspace-encrypted` PVC (main.tf:394-398) - `/home/agent/.claude` → `claude-home` emptyDir (main.tf:424-427) Kubernetes mounts hide image-layer content at those paths, so the COPYs are dead. The companion commit in `claude-agent-service` restages both files to `/usr/share/agent-seed/` (an image-layer path that is never mounted). Additionally, the beads-task-runner agent rails expect `/workspace/scratch/<job_id>/` to exist, but nothing was creating it. ## Layout before / after ``` Before (dead COPYs): image layer runtime (mounted volumes hide the files) ----------- ----------------------------------- /workspace/ <- hidden by PVC mount .beads/ metadata.json <- UNREACHABLE /home/agent/.claude/ <- hidden by emptyDir mount agents/ beads-task-runner.md <- UNREACHABLE After (init container seeds volumes at pod start): image layer runtime ----------- ------------------------------------ /usr/share/agent-seed/ beads-metadata.json --+ beads-task-runner.md --+-> copied by seed-beads-agent init container into the mounted volumes on every pod start: /workspace/.beads/metadata.json /workspace/scratch/ /home/agent/.claude/agents/beads-task-runner.md ``` ## What ### New init container: `seed-beads-agent` - Positioned AFTER `git-init`, BEFORE the main container. - Uses the same service image (`${local.image}:${local.image_tag}`) — the seed files are baked in at `/usr/share/agent-seed/`. - Runs as default uid 1000 (the PVCs are already chowned by `fix-perms`). - Shell body: mkdir -p /workspace/.beads /workspace/scratch /home/agent/.claude/agents cp /usr/share/agent-seed/beads-metadata.json /workspace/.beads/metadata.json cp /usr/share/agent-seed/beads-task-runner.md /home/agent/.claude/agents/beads-task-runner.md - Mounts: `workspace` at `/workspace`, `claude-home` at `/home/agent/.claude`. - Resources: 32Mi requests / 64Mi limits (matches `fix-perms`/`copy-claude-creds`). ### Formatting - `terraform fmt -recursive` also normalised whitespace in the token-expiry locals block and the CronJob container definition. No semantic change. ## What is NOT in this change - No image tag bump. The Dockerfile refactor that produces the `/usr/share/agent-seed/` path lands in the claude-agent-service repo and will roll in on the next CI build. Until that build ships and the tag is bumped in this file, the new init container will `cp` from a path that doesn't exist yet — so do NOT apply this commit until the corresponding image tag bump is ready. The commit is declarative prep. - No changes to storage class, RBAC, Service, or any other init. - The main container mounts remain unchanged — only the init containers prepare volume contents. ## Test Plan ### Automated ``` $ terraform fmt -check -recursive stacks/claude-agent-service/ (no output — clean) $ terraform -chdir=stacks/claude-agent-service/ init -backend=false Terraform has been successfully initialized! $ terraform -chdir=stacks/claude-agent-service/ validate Warning: Deprecated Resource (pre-existing; use kubernetes_namespace_v1) Success! The configuration is valid, but there were some validation warnings as shown above. ``` ### Manual Verification (after image bump + apply) 1. Bump `local.image_tag` in main.tf to the SHA of a build that has `/usr/share/agent-seed/*` (verify with `docker inspect $IMAGE | jq ...` or `kubectl run tmp --image ... -- ls /usr/share/agent-seed`). 2. `scripts/tg apply stacks/claude-agent-service` 3. `kubectl -n claude-agent get pods -w` — all init containers complete. 4. `kubectl -n claude-agent exec deploy/claude-agent-service -c claude-agent-service -- ls -la /workspace/.beads/metadata.json /home/agent/.claude/agents/beads-task-runner.md /workspace/scratch` Expected: all three paths exist; first two are regular files with the expected content, `scratch` is a directory. 5. `kubectl -n claude-agent exec deploy/claude-agent-service -c claude-agent-service -- jq -r .dolt_server_host /workspace/.beads/metadata.json` Expected: `dolt.beads-server.svc.cluster.local`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 14:23:19 +00:00
name = "push-expiry"
image = "docker.io/curlimages/curl:8.11.0"
[monitoring] Add Claude OAuth token expiry monitoring + alerts ## Context The new CLAUDE_CODE_OAUTH_TOKEN mechanism (commit 8a054752) uses long-lived 1-year tokens minted via `claude setup-token`. Tokens don't auto-refresh — at the 1-year mark they expire hard and the upgrade agent stops working. We need to be told 30 days ahead, not find out when DIUN fires and gets 401 again. A cron rotator doesn't make sense here (tokens don't refresh, they just expire) so we alert instead. Two spares at `secret/claude-agent-service-spare-{1,2}` provide failover runway — monitor covers all three. ## This change **CronJob** (`claude-agent` ns, every 6h): reads a ConfigMap containing `<path> → expiry_unix_timestamp` entries, pushes `claude_oauth_token_expiry_timestamp{path="..."}` and `claude_oauth_expiry_monitor_last_push_timestamp` to Pushgateway at `prometheus-prometheus-pushgateway.monitoring:9091`. **ConfigMap** generated from a Terraform local `claude_oauth_token_mint_epochs` — source of truth for mint times. On rotation, update the map + apply. TTL is a shared local (365d). **PrometheusRules** (in prometheus_chart_values.tpl): - `ClaudeOAuthTokenExpiringSoon` — <30d, warning, for 1h - `ClaudeOAuthTokenCritical` — <7d, critical, for 10m - `ClaudeOAuthTokenMonitorStale` — last push >48h, warning - `ClaudeOAuthTokenMonitorNeverRun` — metric absent for 2h, warning Alert labels include `{{ $labels.path }}` so we know which token is expiring (primary / spare-1 / spare-2). ## Verification ``` $ kubectl -n claude-agent create job --from=cronjob/claude-oauth-expiry-monitor manual $ curl pushgateway/metrics | grep claude_oauth_token_expiry claude_oauth_token_expiry_timestamp{...,path="primary"} 1.808064429e+09 claude_oauth_token_expiry_timestamp{...,path="spare-1"} 1.80806428e+09 claude_oauth_token_expiry_timestamp{...,path="spare-2"} 1.808064429e+09 $ query: (claude_oauth_token_expiry_timestamp - time()) / 86400 primary: 365.2 days spare-1: 365.2 days spare-2: 365.2 days ``` ## Rotation playbook (future) 1. `kubectl run -it --rm --image=registry.viktorbarzin.me/claude-agent-service:latest tokmint -- claude setup-token` (or harvest via `harvest3.py` pattern in memory for headless flow) 2. `vault kv patch secret/claude-agent-service claude_oauth_token=<new>` 3. Update `claude_oauth_token_mint_epochs["primary"]` in `stacks/claude-agent-service/main.tf` with new unix timestamp 4. `scripts/tg apply` claude-agent-service + monitoring 5. Alert clears within 6h (next cron tick) + 1h of the `ClaudeOAuthTokenExpiringSoon` "for:" duration Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 12:27:11 +00:00
command = ["/bin/sh", "-c", <<-EOT
set -e
PG='http://prometheus-prometheus-pushgateway.monitoring:9091/metrics/job/claude-oauth-expiry-monitor'
NOW=$(date +%s)
PAYLOAD=''
PAYLOAD="$${PAYLOAD}# HELP claude_oauth_token_expiry_timestamp Unix epoch when the CLAUDE_CODE_OAUTH_TOKEN for this path expires
"
PAYLOAD="$${PAYLOAD}# TYPE claude_oauth_token_expiry_timestamp gauge
"
for path in /mnt/expiry/*; do
name=$(basename "$path")
exp=$(cat "$path")
PAYLOAD="$${PAYLOAD}claude_oauth_token_expiry_timestamp{path=\"$name\"} $exp
"
done
PAYLOAD="$${PAYLOAD}# HELP claude_oauth_expiry_monitor_last_push_timestamp Last time the expiry monitor pushed metrics
"
PAYLOAD="$${PAYLOAD}# TYPE claude_oauth_expiry_monitor_last_push_timestamp gauge
"
PAYLOAD="$${PAYLOAD}claude_oauth_expiry_monitor_last_push_timestamp $NOW
"
echo "$PAYLOAD"
echo "$PAYLOAD" | curl -sS --data-binary @- "$PG"
echo "pushed at $NOW"
EOT
]
volume_mount {
name = "expiry"
mount_path = "/mnt/expiry"
}
resources {
requests = { cpu = "10m", memory = "32Mi" }
limits = { memory = "64Mi" }
}
}
volume {
name = "expiry"
config_map {
name = kubernetes_config_map.claude_oauth_expiry.metadata[0].name
}
}
}
}
}
}
}
[infra] Sweep dns_config ignore_changes across all pod-owning resources [ci skip] ## Context Wave 3A (commit c9d221d5) added the `# KYVERNO_LIFECYCLE_V1` marker to the 27 pre-existing `ignore_changes = [...dns_config]` sites so they could be grepped and audited. It did NOT address pod-owning resources that were simply missing the suppression entirely. Post-Wave-3A sampling (2026-04-18) found that navidrome, f1-stream, frigate, servarr, monitoring, crowdsec, and many other stacks showed perpetual `dns_config` drift every plan because their `kubernetes_deployment` / `kubernetes_stateful_set` / `kubernetes_cron_job_v1` resources had no `lifecycle {}` block at all. Root cause (same as Wave 3A): Kyverno's admission webhook stamps `dns_config { option { name = "ndots"; value = "2" } }` on every pod's `spec.template.spec.dns_config` to prevent NxDomain search-domain flooding (see `k8s-ndots-search-domain-nxdomain-flood` skill). Without `ignore_changes` on every Terraform-managed pod-owner, Terraform repeatedly tries to strip the injected field. ## This change Extends the Wave 3A convention by sweeping EVERY `kubernetes_deployment`, `kubernetes_stateful_set`, `kubernetes_daemon_set`, `kubernetes_cron_job_v1`, `kubernetes_job_v1` (+ their `_v1` variants) in the repo and ensuring each carries the right `ignore_changes` path: - **kubernetes_deployment / stateful_set / daemon_set / job_v1**: `spec[0].template[0].spec[0].dns_config` - **kubernetes_cron_job_v1**: `spec[0].job_template[0].spec[0].template[0].spec[0].dns_config` (extra `job_template[0]` nesting — the CronJob's PodTemplateSpec is one level deeper) Each injection / extension is tagged `# KYVERNO_LIFECYCLE_V1: Kyverno admission webhook mutates dns_config with ndots=2` inline so the suppression is discoverable via `rg 'KYVERNO_LIFECYCLE_V1' stacks/`. Two insertion paths are handled by a Python pass (`/tmp/add_dns_config_ignore.py`): 1. **No existing `lifecycle {}`**: inject a brand-new block just before the resource's closing `}`. 108 new blocks on 93 files. 2. **Existing `lifecycle {}` (usually for `DRIFT_WORKAROUND: CI owns image tag` from Wave 4, commit a62b43d1)**: extend its `ignore_changes` list with the dns_config path. Handles both inline (`= [x]`) and multiline (`= [\n x,\n]`) forms; ensures the last pre-existing list item carries a trailing comma so the extended list is valid HCL. 34 extensions. The script skips anything already mentioning `dns_config` inside an `ignore_changes`, so re-running is a no-op. ## Scale - 142 total lifecycle injections/extensions - 93 `.tf` files touched - 108 brand-new `lifecycle {}` blocks + 34 extensions of existing ones - Every Tier 0 and Tier 1 stack with a pod-owning resource is covered - Together with Wave 3A's 27 pre-existing markers → **169 greppable `KYVERNO_LIFECYCLE_V1` dns_config sites across the repo** ## What is NOT in this change - `stacks/trading-bot/main.tf` — entirely commented-out block (`/* … */`). Python script touched the file, reverted manually. - `_template/main.tf.example` skeleton — kept minimal on purpose; any future stack created from it should either inherit the Wave 3A one-line form or add its own on first `kubernetes_deployment`. - `terraform fmt` fixes to pre-existing alignment issues in meshcentral, nvidia/modules/nvidia, vault — unrelated to this commit. Left for a separate fmt-only pass. - Non-pod resources (`kubernetes_service`, `kubernetes_secret`, `kubernetes_manifest`, etc.) — they don't own pods so they don't get Kyverno dns_config mutation. ## Verification Random sample post-commit: ``` $ cd stacks/navidrome && ../../scripts/tg plan → No changes. $ cd stacks/f1-stream && ../../scripts/tg plan → No changes. $ cd stacks/frigate && ../../scripts/tg plan → No changes. $ rg -c 'KYVERNO_LIFECYCLE_V1' stacks/ --include='*.tf' --include='*.tf.example' \ | awk -F: '{s+=$2} END {print s}' 169 ``` ## Reproduce locally 1. `git pull` 2. `rg 'KYVERNO_LIFECYCLE_V1' stacks/ | wc -l` → 169+ 3. `cd stacks/navidrome && ../../scripts/tg plan` → expect 0 drift on the deployment's dns_config field. Refs: code-seq (Wave 3B dns_config class closed; kubernetes_manifest annotation class handled separately in 8d94688d for tls_secret) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 21:19:48 +00:00
lifecycle {
# KYVERNO_LIFECYCLE_V1: Kyverno admission webhook mutates dns_config with ndots=2
ignore_changes = [spec[0].job_template[0].spec[0].template[0].spec[0].dns_config]
}
[monitoring] Add Claude OAuth token expiry monitoring + alerts ## Context The new CLAUDE_CODE_OAUTH_TOKEN mechanism (commit 8a054752) uses long-lived 1-year tokens minted via `claude setup-token`. Tokens don't auto-refresh — at the 1-year mark they expire hard and the upgrade agent stops working. We need to be told 30 days ahead, not find out when DIUN fires and gets 401 again. A cron rotator doesn't make sense here (tokens don't refresh, they just expire) so we alert instead. Two spares at `secret/claude-agent-service-spare-{1,2}` provide failover runway — monitor covers all three. ## This change **CronJob** (`claude-agent` ns, every 6h): reads a ConfigMap containing `<path> → expiry_unix_timestamp` entries, pushes `claude_oauth_token_expiry_timestamp{path="..."}` and `claude_oauth_expiry_monitor_last_push_timestamp` to Pushgateway at `prometheus-prometheus-pushgateway.monitoring:9091`. **ConfigMap** generated from a Terraform local `claude_oauth_token_mint_epochs` — source of truth for mint times. On rotation, update the map + apply. TTL is a shared local (365d). **PrometheusRules** (in prometheus_chart_values.tpl): - `ClaudeOAuthTokenExpiringSoon` — <30d, warning, for 1h - `ClaudeOAuthTokenCritical` — <7d, critical, for 10m - `ClaudeOAuthTokenMonitorStale` — last push >48h, warning - `ClaudeOAuthTokenMonitorNeverRun` — metric absent for 2h, warning Alert labels include `{{ $labels.path }}` so we know which token is expiring (primary / spare-1 / spare-2). ## Verification ``` $ kubectl -n claude-agent create job --from=cronjob/claude-oauth-expiry-monitor manual $ curl pushgateway/metrics | grep claude_oauth_token_expiry claude_oauth_token_expiry_timestamp{...,path="primary"} 1.808064429e+09 claude_oauth_token_expiry_timestamp{...,path="spare-1"} 1.80806428e+09 claude_oauth_token_expiry_timestamp{...,path="spare-2"} 1.808064429e+09 $ query: (claude_oauth_token_expiry_timestamp - time()) / 86400 primary: 365.2 days spare-1: 365.2 days spare-2: 365.2 days ``` ## Rotation playbook (future) 1. `kubectl run -it --rm --image=registry.viktorbarzin.me/claude-agent-service:latest tokmint -- claude setup-token` (or harvest via `harvest3.py` pattern in memory for headless flow) 2. `vault kv patch secret/claude-agent-service claude_oauth_token=<new>` 3. Update `claude_oauth_token_mint_epochs["primary"]` in `stacks/claude-agent-service/main.tf` with new unix timestamp 4. `scripts/tg apply` claude-agent-service + monitoring 5. Alert clears within 6h (next cron tick) + 1h of the `ClaudeOAuthTokenExpiringSoon` "for:" duration Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 12:27:11 +00:00
}