49 lines
2.8 KiB
Django/Jinja
49 lines
2.8 KiB
Django/Jinja
# Managed by Ansible (roles/k3s_postgres) — do not edit on the node.
|
|
#
|
|
# Superuser credentials for the shared-postgres Cluster
|
|
# (postgres-cluster.yaml.j2), sourced from the same Vault path
|
|
# (homelab/shared/postgres) the Unraid/Proxmox shared-postgres instances
|
|
# already use — see docs/vault-secrets.md. CNPG requires
|
|
# `type: kubernetes.io/basic-auth` with username/password keys, and
|
|
# `enableSuperuserAccess: true` on the Cluster (set there) for this secret to
|
|
# actually be usable for password login rather than just ignored.
|
|
#
|
|
# The `-vault` suffix is load-bearing, and removing it reintroduces a bug
|
|
# that is very hard to read off the symptoms. CNPG generates its own
|
|
# superuser secret named `<cluster>-superuser` when the Cluster doesn't name
|
|
# one — for a Cluster called `shared-postgres` that is exactly
|
|
# `shared-postgres-superuser`, the name this file used to claim. Writing our
|
|
# own object at the operator's reserved name meant the operator treated it as
|
|
# one it had already authored and reconciled, so a password change in Vault
|
|
# propagated as far as this Secret and stopped there: the role in the
|
|
# database kept whatever was set at bootstrap. Every check short of querying
|
|
# pg_authid agrees the change landed, while `psql` from the LAN keeps
|
|
# returning "password authentication failed for user postgres". Any name
|
|
# outside the `<cluster>-*` pattern the operator owns avoids it.
|
|
#
|
|
# Namespace comes from postgres-cluster.yaml.j2, a separate file in the same
|
|
# manifests directory — see that file's header for why applying this before
|
|
# the Namespace exists isn't a problem.
|
|
#
|
|
# The username is layered the same way every other value in this repo is —
|
|
# Vault on top, common/vars.yml underneath — rather than required from Vault.
|
|
# It isn't a secret (only the password is), and the Vault path is allowed to
|
|
# carry just POSTGRES_SUPERUSER_PASSWORD; setting POSTGRES_SUPERUSER there
|
|
# still wins, which is what docs/vault-secrets.md means by "Vault is
|
|
# authoritative since it's paired with the password".
|
|
apiVersion: v1
|
|
kind: Secret
|
|
metadata:
|
|
name: shared-postgres-superuser-vault
|
|
namespace: {{ k3s_postgres_namespace }}
|
|
type: kubernetes.io/basic-auth
|
|
# to_json, not bare interpolation: it emits a double-quoted YAML scalar with
|
|
# escaping handled, so a password containing `#`, `:`, a leading `*`/`&`, or
|
|
# leading/trailing whitespace survives intact. Unquoted, YAML silently
|
|
# reinterprets those (`#` starts a comment, an all-digit password becomes an
|
|
# int) and the Secret ends up holding something other than what Vault has —
|
|
# which fails authentication while every value still looks right in playbook
|
|
# output. Alphanumeric-only passwords hide the problem rather than fix it.
|
|
stringData:
|
|
username: {{ (pg_vault_secrets.POSTGRES_SUPERUSER | default(pg_config.POSTGRES_SUPERUSER)) | to_json }}
|
|
password: {{ pg_vault_secrets.POSTGRES_SUPERUSER_PASSWORD | to_json }}
|