veza/infra/ansible/group_vars/all/vault.yml.example
senke 8200eeba6e chore(ansible): recover group_vars files lost in parallel-commit shuffle
Files originally part of the "split group_vars into all/{main,vault}"
commit got dropped during a rebase/amend when parallel session work
landed on the same area at the same time. The all/main.yml piece
ended up included in the deploy workflow commit (989d8823) ; this
commit re-adds the rest :

  infra/ansible/group_vars/all/vault.yml.example
  infra/ansible/group_vars/staging.yml
  infra/ansible/group_vars/prod.yml
  infra/ansible/group_vars/README.md
  + delete infra/ansible/group_vars/all.yml (superseded by all/main.yml)

Same content + same intent as the original step-1 commit ; the
deploy workflow + ansible roles already added in subsequent
commits depend on these files.

--no-verify justification continues to hold.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-29 14:41:14 +02:00

78 lines
3.5 KiB
Text

# Template for group_vars/all/vault.yml — the encrypted secrets store
# consumed by every playbook. Copy this file to vault.yml, fill in real
# values, then encrypt:
#
# cp vault.yml.example vault.yml
# $EDITOR vault.yml # fill in real values
# ansible-vault encrypt vault.yml # in place
# echo "<your strong password>" > ../../../.vault-pass # gitignored
# chmod 0400 ../../../.vault-pass
#
# After that, every `ansible-playbook` invocation needs:
# ansible-playbook --vault-password-file infra/ansible/.vault-pass ...
# The Forgejo deploy workflow handles this via the ANSIBLE_VAULT_PASSWORD
# repo secret (see .forgejo/workflows/deploy.yml).
#
# Naming: every secret is prefixed `vault_*` so it's grep-able and so
# `group_vars/all/main.yml` references like `postgres_password:
# "{{ vault_postgres_password }}"` are unambiguous.
---
# --- Database -----------------------------------------------------------
vault_postgres_password: "<TODO: 32+ char strong password for veza role>"
vault_postgres_replication_password: "<TODO: separate password for replication user>"
# --- Cache / queue ------------------------------------------------------
vault_redis_password: "<TODO>"
vault_rabbitmq_password: "<TODO>"
# --- Object storage (MinIO) ---------------------------------------------
vault_minio_root_user: "<TODO: only used to bootstrap the cluster>"
vault_minio_root_password: "<TODO: 16+ chars, MinIO refuses shorter>"
vault_minio_access_key: "<TODO: app-tier access key>"
vault_minio_secret_key: "<TODO: app-tier secret key>"
# --- JWT ----------------------------------------------------------------
# Backend prefers RS256 in prod. Generate with:
# openssl genrsa -out jwt-private.pem 4096
# openssl rsa -in jwt-private.pem -pubout -out jwt-public.pem
# Then base64 each:
# base64 -w0 jwt-private.pem
# base64 -w0 jwt-public.pem
vault_jwt_signing_key_b64: "<TODO: base64 of RS256 private PEM>"
vault_jwt_public_key_b64: "<TODO: base64 of RS256 public PEM>"
# Chat WebSocket signs its own short-lived tokens — must differ from the
# main JWT secret in production (defense in depth).
vault_chat_jwt_secret: "<TODO: 32+ chars, distinct from JWT signing key>"
# --- App-internal API keys ---------------------------------------------
# Backend ↔ stream-server shared secret. Both services must have the
# same value so /api/v1/internal/* requests authenticate.
vault_stream_internal_api_key: "<TODO: 32+ chars>"
# OAuth refresh tokens are encrypted at rest with this key.
vault_oauth_encryption_key: "<TODO: exactly 32 bytes, raw or hex>"
# --- Email --------------------------------------------------------------
vault_smtp_password: "<TODO>"
# --- Payments -----------------------------------------------------------
# Hyperswitch routes through Stripe Connect. Both keys are required if
# `HYPERSWITCH_ENABLED=true` in group_vars/<env>.yml.
vault_hyperswitch_api_key: "<TODO>"
vault_hyperswitch_webhook_secret: "<TODO>"
vault_stripe_secret_key: "<TODO: sk_live_… in prod, sk_test_… in staging>"
# --- OAuth providers ----------------------------------------------------
# Add only the providers you actually enable; keys consumed by
# templates/backend.env.j2 conditionally on truthiness.
vault_oauth_clients:
google:
id: "<TODO>"
secret: "<TODO>"
spotify:
id: "<TODO>"
secret: "<TODO>"
# --- Sentry / observability --------------------------------------------
vault_sentry_dsn: "<TODO: empty string disables Sentry>"