Secretos
Todo lo sensible vive en Secret Manager del proyecto correspondiente. Nunca en el código, nunca en una variable de entorno escrita a mano en la consola.
Producción (aprendix-prod)
| Secreto | Quién lo lee |
|---|---|
nexo-app-key | nexo-hub-backend |
microsoft-cliente-secreto | nexo-hub-backend |
github-lectura-token | nexo-hub-backend |
ti-db-password | los dos backends: mismo usuario de MySQL |
ti-app-key | nexo-ti-backend |
ti-aprendix-db-password | nexo-ti-backend |
ti-whatsapp-token, ti-whatsapp-app-secret, ti-whatsapp-verify | nexo-ti-backend |
github-packages-token | Cloud Build, no un servicio |
gcs-service-account-json | Aprendix |
Cada secreto se concede individualmente a la cuenta de servicio que lo necesita. Ninguna cuenta tiene acceso a todos.
Los dos tokens de GitHub, y por qué son dos
github-packages-token | github-lectura-token | |
|---|---|---|
| Lo lee | Cloud Build, al construir | nexo-hub-backend, en caliente |
| Para qué | Instalar @ucic-pe/ui | Leer repos y commits |
| Alcance | repo + write:packages | Solo lectura de contenido |
Podrían ser uno. Son dos a propósito: el de Packages lleva escritura sobre todos los repos de la organización, y usarlo también para una pantalla de consulta multiplicaría por dos los sitios desde donde se puede filtrar.
github-packages-token tiene más alcance del que necesita (repo y
write:packages cuando le bastaría read:packages) y estuvo expuesto. Debe
reemplazarse por un PAT de solo lectura de paquetes.
Quién lee el secreto durante un build
Esta es la que hace perder una tarde. Los builds de Cloud Run corren como la cuenta de cómputo por defecto:
<número-de-proyecto>-compute@developer.gserviceaccount.com
No como la cuenta heredada <número>@cloudbuild.gserviceaccount.com, aunque
el rol roles/cloudbuild.builds.builder siga apareciendo sobre esa última y
todo invite a pensar lo contrario.
Dárselo a la cuenta equivocada no falla al otorgarlo: falla diez minutos
después, dentro del build, con PermissionDenied sobre
secretmanager.versions.access. Lo que manda es con qué identidad corre el build
de verdad, y se lee así:
gcloud builds describe <id> --project <proyecto> --format="value(serviceAccount)"
Cómo comprobar esto
gcloud secrets list --project aprendix-prod
gcloud secrets get-iam-policy <secreto> --project aprendix-prod