Menu
OAuth2-proxy authentication setup, configuration, and troubleshooting for the K3s cluster.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | oauth |
| description | OAuth2-proxy authentication setup, configuration, and troubleshooting for the K3s cluster. |
*.gkcluster.org) → oauth2-proxy gateway → backend servicesexternal-auth-n-z was parked)kubernetes-services/values.yamlkubernetes-services/additions/ingress/ supports oauth2_proxy annotation modeNon-browser MCP clients (claude.ai's connector, Claude Code
--transport http) cannot authenticate through this cluster's
standard pattern. Two reasons:
The established pattern for MCP servers in this cluster (open-brain-mcp historically; thoth going forward) is:
brain.gkcluster.org, thoth.gkcluster.org)
needs a Cloudflare Access bypass policy so the in-pod OAuth
flow isn't shadowed by Google SSO. See /cloudflare skill./mcp must include
WWW-Authenticate: Bearer resource_metadata="<host>/.well-known/oauth-protected-resource"
— without this header, MCP clients silently fail to discover the
auth server and just give up.client_ids
in-memory; clients re-register transparently on pod restart.gilesknap/open-brain-mcp/oauth.py
(provider-agnostic). When standing up the next MCP service, port
the structure rather than reinventing.chrome://settings/resetsealedsecrets.bitnami.com/managed: "true" annotation on targetserver.additional.audiences does
nothing for Dex. Override the argo-cd client in dex.config with
trustedPeers instead. See additions/argocd/README.md.oidc.config disables Dex — having oidc.config in argocd-cm causes
IsDexDisabled()=true. Use dex.config only.secretKeyRef
are read at startup. After rotating with just seal-argocd-dex <subcommand>,
restart affected pods.argocd-dex-secret SealedSecret
template must include app.kubernetes.io/part-of: argocd label. Without
it, ArgoCD's $secret:key resolution in dex.config silently fails,
passing literal key names as OAuth client IDs (→ GitHub 404).dex.config uses $argocd-dex-secret:key for each static client.
Missing keys silently resolve to empty, causing "Failed to get token
from provider" on login. The rebuild path (scripts/seal-from-json)
seals all clients (grafana, open-webui, argocd-monitor) along with
the matching service-side secrets in one pass.cookie-domain=.gkcluster.org, so its _oauth2_proxy cookie reaches all
subdomains. Any service with its own oauth2-proxy sidecar (e.g.
argocd-monitor) must use --cookie-name=<unique> to avoid validating
the shared proxy's cookie with its own secret (→ infinite login loop).email_domains must be [] — the Helm chart defaults
to email_domains = ["*"], which allows any GitHub user through and
silently overrides authenticatedEmailsFile. The fix is
config.configFile with email_domains = []. This bug was found and
fixed in PR #279 — do not remove the configFile override.cookie-secret size — must be exactly 16, 24, or 32
bytes for the AES cipher. base64.b64encode(token_bytes(32)) produces
44 chars and crashes oauth2-proxy. Use secrets.token_hex(16) (32 hex
chars = 32 bytes). This bug has regressed before — do not change the
generation in scripts/seal-argocd-dex. See /sealed-secrets skill.argo-cd static client — ArgoCD auto-generates an
argo-cd DEX client (without trustedPeers). Our dex.config also
declares one (with trustedPeers: [argocd-monitor]). DEX v2.45+ stores
the first and drops the duplicate, so trustedPeers never takes
effect. Fixed in PR #297 by adding oidc.config with
allowedAudiences: [argo-cd, argocd-monitor], which lets
argocd-monitor authenticate as itself. The duplicate argo-cd client
in dex.config is harmless but redundant — kept for clarity.envFrom or secretKeyRef cache values at startup. After
--tags cluster or just seal-argocd-dex, run just restart-dex and
kubectl rollout restart sts grafana-prometheus -n monitoring.
Without this, Dex reports "invalid client_secret" even though the
Secret objects match. See /sealed-secrets for the full namespace list.auth-url uses the internal service (oauth2-proxy.oauth2-proxy.svc).
Using the external domain resolves via Cloudflare to IPv6, which is
unreachable from the cluster, causing intermittent 500s on all
oauth2-protected ingresses./api/dex 301s to /api/dex/ which returns
404. OIDC clients that don't follow redirects (e.g. Open WebUI's authlib)
need the full discovery URL: .well-known/openid-configuration.[users].allow_sign_up — the per-provider
allow_sign_up under [auth.generic_oauth] is not sufficient alone.
Also set [auth].disable_signup_form: true to block manual signup.kubernetes-services/values.yaml — oauth2-proxy toggle and configkubernetes-services/additions/ingress/ — reusable ingress with auth modeskubernetes-services/templates/ — ArgoCD Application CRDsAnsible playbook structure, tags, topology rules, branch switching, and operational foot-guns for the K3s cluster.
ArgoCD operations on the K3s cluster — branch repointing via ansible, OCI Helm chart wiring foot-guns (oci:// prefix breaks chart-name resolution), and the InvalidSpecError cache bounce.
Architecture decisions and historical reversals for this repo's bwrap-based Claude sandbox. Covers real claude off PATH, container-scoped PATs, Ubuntu-24.04 CI bwrap workarounds, dogfood ≈ guest, the `just promote` three-layer model (no JSONC editing), and two walked-back paths (Python orchestration; embedding in python-copier-template). Surface before edits to `.devcontainer/claude-sandbox/{claude-shadow,install.sh,promote.sh}`, `install`, `tests/`, `.github/workflows/ci.yml`, or `.claude/commands/verify-sandbox.md`; or before any suggestion to re-introduce Python tooling, embed in python-copier-template, persist gh/glab PATs across containers, or auto-edit JSONC devcontainer.json.
Cloudflare Tunnel and Access configuration for exposing K3s services externally.
RKLLama (RK3588 NPU LLM server) operations — pod CLI quirks, model layout, hardware pinning, and the silent-failure modes of `rkllama_client pull`.
Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants integration tests, or asks for test-first development.