Mantenere sincronizzato l'utente di database

Utenti di database crea l'utente tenax una volta sola. Per la maggior parte delle configurazioni basta. Questa pagina è per le configurazioni GitOps in cui l'utente deve continuare a corrispondere al suo Secret senza che nessuno debba eseguire nulla:

• la password del Secret viene ruotata;
• il database viene ricostruito o ripristinato da un dump più vecchio, e l'utente non c'è più;
• qualcuno modifica l'utente a mano (rimuove un grant, cambia la password);
• il database viene creato dopo i manifest che descrivono il suo utente (un cluster nuovo).

Un Job eseguito una volta non gestisce nessuno di questi casi: gira una volta, e Kubernetes non riesegue un Job terminato quando il Secret cambia. Un CronJob che riapplica lo stesso SQL idempotente invece sì: entro un periodo, l'utente torna a corrispondere al Secret.

Come funziona

Un CronJob per database, nel namespace del database. A ogni esecuzione:

1. attende che il database risponda (entro la deadline del Job);
2. accede come amministratore, con il Secret usato dal database stesso;
3. crea l'utente tenax se manca, e ne imposta password e grant a partire dal Secret di Tenax.

Ogni istruzione è idempotente, quindi un'esecuzione che trova già tutto a posto non cambia nulla. Le password arrivano al container come variabili d'ambiente dai Secret; non compaiono mai su una riga di comando né in un log.

PostgreSQL

Sostituisci i quattro valori marcati con # ←: il namespace, il Service del database, il database, e il Secret e la chiave che contengono la password dell'amministratore.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: tenax-user-postgres
  namespace: team-a                                   # ←
spec:
  schedule: "*/30 * * * *"
  concurrencyPolicy: Forbid
  successfulJobsHistoryLimit: 1
  failedJobsHistoryLimit: 3
  jobTemplate:
    spec:
      backoffLimit: 2
      activeDeadlineSeconds: 300
      template:
        spec:
          restartPolicy: OnFailure
          automountServiceAccountToken: false
          securityContext: { runAsNonRoot: true, runAsUser: 999, runAsGroup: 999 }
          containers:
            - name: psql
              image: docker.io/library/postgres:16
              resources: { requests: { cpu: 10m, memory: 32Mi }, limits: { memory: 128Mi } }
              securityContext: { allowPrivilegeEscalation: false, capabilities: { drop: [ALL] } }
              env:
                - { name: PGHOST, value: postgres }                     # ← the database's Service
                - { name: PGDATABASE, value: app }                      # ← any database on the server
                - { name: PGUSER, value: postgres }
                - { name: PGCONNECT_TIMEOUT, value: "10" }
                - name: PGPASSWORD
                  valueFrom: { secretKeyRef: { name: postgres-admin, key: password } }   # ←
                - name: TENAX_PASSWORD
                  valueFrom: { secretKeyRef: { name: tenax-postgres, key: password } }
              command: [sh, -ec]
              args:
                - |
                  until pg_isready -q; do echo "waiting for $PGHOST"; sleep 5; done
                  psql -v ON_ERROR_STOP=1 -X <<'SQL'
                  \getenv tenax_password TENAX_PASSWORD
                  SELECT 'CREATE ROLE tenax LOGIN REPLICATION' WHERE NOT EXISTS (SELECT 1 FROM pg_roles WHERE rolname = 'tenax') \gexec
                  ALTER ROLE tenax WITH LOGIN REPLICATION NOSUPERUSER NOCREATEDB NOCREATEROLE PASSWORD :'tenax_password';
                  GRANT pg_read_all_data, pg_monitor TO tenax;
                  ALTER ROLE tenax SET idle_in_transaction_session_timeout = '10min';
                  SQL
                  echo "tenax user in sync on $PGHOST"

\getenv richiede psql 15 o successivo nell'immagine; il server può essere di qualsiasi versione supportata. Imposta max_slot_wal_keep_size nella configurazione del server (per esempio -c max_slot_wal_keep_size=2GB), non qui: è un'impostazione del server, non fa parte dell'utente.

MySQL

apiVersion: batch/v1
kind: CronJob
metadata:
  name: tenax-user-mysql
  namespace: team-a                                   # ←
spec:
  schedule: "*/30 * * * *"
  concurrencyPolicy: Forbid
  successfulJobsHistoryLimit: 1
  failedJobsHistoryLimit: 3
  jobTemplate:
    spec:
      backoffLimit: 2
      activeDeadlineSeconds: 300
      template:
        spec:
          restartPolicy: OnFailure
          automountServiceAccountToken: false
          securityContext: { runAsNonRoot: true, runAsUser: 999, runAsGroup: 999 }
          containers:
            - name: mysql
              image: docker.io/library/mysql:8.4
              resources: { requests: { cpu: 10m, memory: 64Mi }, limits: { memory: 256Mi } }
              securityContext: { allowPrivilegeEscalation: false, capabilities: { drop: [ALL] } }
              env:
                - { name: MYSQL_HOST, value: mysql }                    # ← the database's Service
                - name: ROOT_PASSWORD
                  valueFrom: { secretKeyRef: { name: mysql-admin, key: root-password } }  # ←
                - name: TENAX_PASSWORD
                  valueFrom: { secretKeyRef: { name: tenax-mysql, key: password } }
              command: [bash, -ec]
              args:
                - |
                  umask 077
                  printf '[client]\nuser=root\npassword=%s\nhost=%s\nconnect-timeout=10\n' "$ROOT_PASSWORD" "$MYSQL_HOST" > /tmp/root.cnf
                  until mysqladmin --defaults-extra-file=/tmp/root.cnf ping --silent; do echo "waiting for $MYSQL_HOST"; sleep 5; done
                  mysql --defaults-extra-file=/tmp/root.cnf <<SQL
                  CREATE USER IF NOT EXISTS 'tenax'@'%' IDENTIFIED BY '${TENAX_PASSWORD}';
                  ALTER USER 'tenax'@'%' IDENTIFIED BY '${TENAX_PASSWORD}';
                  GRANT SELECT, SHOW VIEW, TRIGGER, EVENT, LOCK TABLES, PROCESS, RELOAD, SHOW_ROUTINE,
                        REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'tenax'@'%';
                  SQL
                  rm -f /tmp/root.cnf
                  echo "tenax user in sync on $MYSQL_HOST"

La password entra nell'SQL senza escaping oltre al letterale stringa, quindi generala in esadecimale (openssl rand -hex 24).

Eseguirlo subito

kubectl -n team-a create job --from=cronjob/tenax-user-postgres tenax-user-now
kubectl -n team-a logs -f job/tenax-user-now

Ogni 30 minuti è più che sufficiente: Tenax stesso ritenta un login rifiutato e lo segnala sul target, quindi una rotazione viene recepita al massimo un periodo dopo. La regola in pg_hba.conf e le impostazioni del binlog restano configurazione del server (Utenti di database, passo 3); questo CronJob non le tocca.