Synchronizacja użytkownika bazy danych

Użytkownicy baz danych tworzy użytkownika tenax jednorazowo. W większości konfiguracji to wystarczy. Ta strona jest dla konfiguracji GitOps, w których użytkownik musi stale odpowiadać swojemu Secret, bez ręcznego uruchamiania czegokolwiek:

• hasło w Secret jest rotowane;
• baza danych zostaje odbudowana lub przywrócona ze starszego zrzutu i użytkownika już nie ma;
• ktoś zmienia użytkownika ręcznie (odbiera uprawnienie, zmienia hasło);
• baza danych powstaje po manifestach opisujących jej użytkownika (nowy klaster).

Jednorazowy Job nie obsługuje żadnego z tych przypadków: uruchamia się raz, a Kubernetes nie uruchomi ponownie zakończonego Joba, gdy Secret się zmieni. CronJob, który ponownie stosuje ten sam idempotentny SQL, już tak: w ciągu jednego okresu użytkownik znów odpowiada Secret.

Jak to działa

Jeden CronJob na bazę danych, w namespace bazy danych. Każde uruchomienie:

1. czeka, aż baza danych odpowie (w granicach deadline'u Joba);
2. loguje się jako administrator, korzystając z Secret, którego używa sama baza danych;
3. tworzy użytkownika tenax, jeśli go brakuje, i ustawia jego hasło oraz uprawnienia na podstawie Secret Tenax.

Każda instrukcja jest idempotentna, więc uruchomienie, które zastanie wszystko na miejscu, niczego nie zmienia. Hasła trafiają do kontenera jako zmienne środowiskowe z Secretów; nigdy nie pojawiają się w wierszu poleceń ani w logu.

PostgreSQL

Zastąp cztery wartości oznaczone # ←: namespace, Service bazy danych, bazę danych oraz Secret i klucz zawierający hasło administratora.

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 wymaga w obrazie psql 15 lub nowszego; serwer może mieć dowolną obsługiwaną wersję. Ustaw max_slot_wal_keep_size w konfiguracji serwera (na przykład -c max_slot_wal_keep_size=2GB), nie tutaj: to ustawienie serwera, a nie część użytkownika.

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"

Hasło trafia do SQL bez dodatkowego cytowania poza literałem tekstowym, więc wygeneruj je w formacie hex (openssl rand -hex 24).

Uruchom teraz

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

Co 30 minut w zupełności wystarczy: sam Tenax ponawia odrzucone logowanie i zgłasza je w celu, więc rotacja zostanie uwzględniona najpóźniej po jednym okresie. Reguła w pg_hba.conf i ustawienia binlogu pozostają konfiguracją serwera (Użytkownicy baz danych, krok 3); ten CronJob ich nie dotyka.