Use o Secret Manager para processar segredos no AlloyDB for PostgreSQL

Esta página descreve como usar o AlloyDB for PostgreSQL com o Secret Manager para armazenar informações de acesso confidenciais.

O processamento seguro das suas informações confidenciais é uma parte essencial da criação de um fluxo de trabalho de desenvolvimento seguro. Para o AlloyDB, recomendamos que armazene as suas informações confidenciais como segredos que cria no Secret Manager. Os segredos incluem chaves de API, palavras-passe, informações confidenciais e credenciais que pode usar para aceder a um sistema confidencial.

Vista geral

O Secret Manager oferece conveniência e melhora a segurança. Também pode aplicar o controlo de versões aos seus segredos e partilhá-los com a sua equipa. Para saber mais sobre como partilhar segredos com a sua equipa, consulte o artigo Controlo de acesso com a IAM.

Nomes de utilizador e palavras-passe

A utilização do Secret Manager para armazenar os nomes de utilizador e as palavras-passe das suas contas de utilizador do AlloyDB como segredos é uma forma segura e fiável de gerir as suas informações confidenciais.

Primeiro, crie um utilizador no AlloyDB. Para tal, tem de fornecer um nome de utilizador e uma palavra-passe. Para mais informações sobre como criar um utilizador no AlloyDB, consulte o artigo Gerir utilizadores do PostgreSQL com autenticação integrada.

Depois de criar o utilizador, crie um segredo no Secret Manager para armazenar o nome de utilizador e a palavra-passe, o que evita a perda das suas informações confidenciais. Para mais informações sobre como criar e aceder a segredos no Secret Manager, consulte o artigo Crie um segredo.

Cenários de réplica entre regiões

Se um cluster principal do AlloyDB falhar, pode promover um cluster secundário. Depois de o cluster secundário se tornar o cluster principal, tem de atualizar o nome de ligação da instância para refletir esta promoção. Se o nome da instância estiver armazenado num segredo, tem de atualizar o segredo com o nome do novo cluster principal. Para mais informações, consulte o artigo Edite um segredo.

Uma forma de usar o Secret Manager para failovers é armazenar o nome do cluster principal num segredo e, em seguida, envolver a invocação do AlloyDB Auth Proxy num script que sondar o Secret Manager.

Para detetar quando o valor do nome da ligação da instância é atualizado, use o proxy Auth do AlloyDB e, em seguida, reinicie-o com o novo valor, da seguinte forma:

#!/bin/bash

SECRET_ID="my-secret-id" # TODO(developer): replace this value
REFRESH_INTERVAL=5
PORT=5432                # TODO(developer): change this port as needed

# Get the latest version of the secret and start the proxy
INSTANCE=$(gcloud secrets versions access "latest" --secret="$SECRET_ID")
alloydb-auth-proxy $INSTANCE --port=$PORT &
PID=$!

# Every 5s, get the latest version of the secret. If it's changed, restart the
# proxy with the new value.
while true; do
    sleep $REFRESH_INTERVAL
    NEW=$(gcloud secrets versions access "latest" --secret="$SECRET_ID")
    if [ "$INSTANCE" != "$NEW" ]; then
        INSTANCE=$NEW
        kill $PID
        wait $PID
        alloydb-auth-proxy $INSTANCE --port=$PORT &
        PID=$!
    fi
done

Para mais informações sobre como criar e aceder a um segredo que contenha o nome de ligação da instância da réplica principal, consulte o artigo Crie e aceda a um segredo através do Secret Manager. Para mais informações sobre a utilização do proxy Auth do AlloyDB, consulte o artigo Ligue-se através do proxy Auth do AlloyDB.

O que se segue?