1
2

example.com.   CAA 0 issue "pki.goog"
example.com.   CAA 0 issue "letsencrypt.org"

1
2
3
4
5

gcloud compute ssl-certificates describe web-cert --global --format='yaml(managed)'
# managed:
#   domainStatus:
#     www.example.com: PROVISIONING | ACTIVE | FAILED_NOT_VISIBLE | FAILED_CAA_FORBIDDEN | FAILED_CAA_CHECKING | FAILED_RATE_LIMITED
#   status: PROVISIONING | ACTIVE

Para que pase a ACTIVE tienen que cumplirse tres cosas a la vez: el A/AAAA del dominio apunta a la IP del balanceador (y a nada más), el certificado está adjunto a un target proxy con su forwarding rule, y ningún CAA de la zona prohíbe a las CAs de Google. Después, hasta 60 minutos.

Por qué

Google emite los certificados gestionados con Google Trust Services (pki.goog) o con Let’s Encrypt, y elige una u otra en cada emisión o renovación. Para validar el dominio hace una comprobación HTTP contra la IP a la que resuelve el nombre, así que hasta que el DNS apunte al balanceador no hay nada que validar. Y como cualquier CA, respeta los registros CAA: si tu zona dice que solo digicert.com puede emitir (política corporativa típica), Google no puede.

Los estados lo cuentan:

El CAA correcto

Sin ningún registro CAA, cualquier CA puede emitir y Google funciona. Si tienes CAA (o tu organización lo exige), añade las dos CAs:

1
2

example.com.   CAA 0 issue "pki.goog"
example.com.   CAA 0 issue "letsencrypt.org"

Poner solo una obliga a Google a usar siempre esa; la documentación lo desaconseja porque una renovación puede salir por la otra. Los CAA se heredan hacia abajo: un CAA en example.com cubre www.example.com si el subdominio no tiene el suyo.

1

dig +short CAA example.com

Certificate Manager: emitir antes de cambiar el DNS

Con los certificados clásicos (compute ssl-certificates) el dominio tiene que apuntar ya al balanceador, lo que en una migración significa unos minutos de HTTPS roto. Certificate Manager resuelve eso con autorización DNS: publicas un CNAME de validación y Google emite el certificado mientras el tráfico sigue en el sitio viejo.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

gcloud certificate-manager dns-authorizations create www-auth --domain=www.example.com
gcloud certificate-manager dns-authorizations describe www-auth --format='yaml(dnsResourceRecord)'
# dnsResourceRecord: name: _acme-challenge.www.example.com. type: CNAME data: xxxx.authorize.certificatemanager.goog.

# publica ese CNAME en tu zona y luego:
gcloud certificate-manager certificates create www-cert \
  --domains=www.example.com --dns-authorizations=www-auth
gcloud certificate-manager maps create web-map
gcloud certificate-manager maps entries create www --map=web-map --certificate=www-cert --hostname=www.example.com
gcloud compute target-https-proxies update web-proxy --certificate-map=web-map

Cuando el certificado esté ACTIVE, cambias el A/AAAA y el corte es cero. Los CAA aplican igual.

Trampas

• Cloudflare u otro proxy delante del balanceador: el A apunta al proxy, no a Google, y la validación falla con FAILED_NOT_VISIBLE. Nube gris durante la emisión, o Certificate Manager con autorización DNS.
• Un certificado gestionado no adjunto a nada no se emite. Crearlo y esperar no hace nada; adjúntalo al target proxy primero.
• Cambiar la lista de dominios crea un certificado nuevo: adjunta el nuevo, espera ACTIVE, y solo entonces quita el viejo del proxy, o tendrás un hueco.
• Wildcards solo con Certificate Manager y autorización DNS; los certificados gestionados clásicos no los admiten.
• DNSSEC mal firmado rompe la lectura de CAA: FAILED_CAA_CHECKING aunque no tengas ningún CAA.

Referencia: Google-managed SSL certificates y Certificate Manager en la documentación de Google Cloud.

En Logs Explorer, cada fase del túnel tiene su consulta:

Cloud VPN corre strongSwan por debajo, así que los mensajes son los de strongSwan: si conoces charon, ya sabes leerlos.

Qué significa cada mensaje

establishing IKE_SA failed, peer not responding. Cloud VPN manda IKE_SA_INIT y nadie contesta. En orden de probabilidad: el peer está en IKEv1 y el túnel en IKEv2 (o al revés), la IP del peer configurada no es la pública real (NAT delante del firewall), UDP 500 y 4500 no llegan al peer, o el peer ni siquiera tiene el túnel activo. La PSK no produce este mensaje: con PSK incorrecta la fase 1 arranca y falla en IKE_AUTH.

IKE_SA … established between y después nada. Fase 1 bien, fase 2 no. Busca CHILD_SA y traffic selectors.

Remote traffic selectors narrowed / Local traffic selectors narrowed. Las redes de fase 2 no coinciden en los dos lados. En HA VPN (y en Classic VPN basada en rutas) Cloud VPN propone 0.0.0.0/0 a ambos lados y espera lo mismo; un peer policy-based con subredes concretas hace que strongSwan estreche los selectores y solo pase tráfico entre lo que casó, o nada. En el peer: fase 2 con 0.0.0.0/0 local y remoto (en pfSense, modo Routed, que crea una interfaz de túnel ipsecN), y las rutas se resuelven por BGP o estáticas.

received DELETE for ESP CHILD_SA en bucle. El peer tumba la fase 2 cada pocos minutos: lifetimes de fase 2 distintos con rekey mal negociado, o DPD agresivo. Iguala lifetimes (Cloud VPN usa 3 horas en fase 2 y 10 en fase 1) y deja que el rekey lo inicie un solo lado.

Sube, pasa tráfico un rato y muere con NAT-T. Un peer detrás de NAT con UDP 4500 y un middlebox que “ayuda” (ALG de IPsec en el router) descarta paquetes ESP encapsulados. Desactiva el ALG o pasa el firewall a IP pública directa.

HA VPN con BGP contra pfSense (FRR)

El túnel sube, bgp se establece, y ninguna ruta entra ni sale. FRR en pfSense arranca con una política que rechaza todo lo que no esté permitido explícitamente:

1. Services → FRR → BGP → Route Maps: crea ALLOW-ALL, Action Permit, Sequence 100, sin criterios.
2. BGP → Neighbors → el peer de Cloud Router: Remote AS el ASN del Cloud Router, y en Peer Filtering asigna ALLOW-ALL como route map in y out.
3. BGP → Network Distribution: lista las redes locales que quieres anunciar (o Default Originate si todo va por el túnel).
4. En GCP, el Cloud Router con --advertisement-mode custom si quieres controlar qué prefijos salen; por defecto anuncia las subredes de la VPC.

Sin el paso 2, vtysh -c "show ip bgp summary" muestra la sesión Established con 0 prefijos en ambas direcciones, que es exactamente el síntoma.

Trampas

• IKEv2 salvo que el peer no pueda: IKEv1 sigue soportado, pero sin IPv6 y con menos cifrados. Classic VPN sigue existiendo (99,9 %), pero parte de su funcionalidad está retirada; lo nuevo va en HA VPN (99,99 %).
• Dos túneles por gateway en HA VPN para el 99.99 %: si solo levantas uno, el estado del gateway queda en aviso aunque funcione.
• MTU: 1460 por defecto en la VPC de GCP; con IPsec encima, deja que TCP haga MSS clamping en el peer (pfSense lo hace en la interfaz ipsecN del túnel) o verás transferencias que se cuelgan tras el handshake.
• Los logs tardan: un minuto o dos entre el evento y Logs Explorer. Refresca antes de cambiar la configuración otra vez.
• PSK con caracteres especiales copiada de un gestor de contraseñas: comprueba en el peer que no se comió nada; el síntoma es IKE_AUTH que falla, no peer not responding.

Ver también

• pfSense: NAT reflection y split DNS — el otro clásico de “el túnel está bien y aun así no llego”.
• Cloud VPN troubleshooting en la documentación de Google Cloud.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

export PROJECT_ID=my-project
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='value(projectNumber)')
export GITHUB_ORG=my-org
export REPO=my-org/my-repo

gcloud iam workload-identity-pools create github \
  --project=$PROJECT_ID --location=global --display-name="GitHub Actions"

gcloud iam workload-identity-pools providers create-oidc github-oidc \
  --project=$PROJECT_ID --location=global --workload-identity-pool=github \
  --display-name="GitHub OIDC" \
  --issuer-uri="https://token.actions.githubusercontent.com" \
  --attribute-mapping="google.subject=assertion.sub,attribute.actor=assertion.actor,attribute.repository=assertion.repository,attribute.repository_owner=assertion.repository_owner" \
  --attribute-condition="assertion.repository_owner == '$GITHUB_ORG'"

gcloud iam service-accounts create github-actions --project=$PROJECT_ID --display-name="GitHub Actions"
gcloud iam service-accounts add-iam-policy-binding github-actions@$PROJECT_ID.iam.gserviceaccount.com \
  --project=$PROJECT_ID --role=roles/iam.workloadIdentityUser \
  --member="principalSet://iam.googleapis.com/projects/$PROJECT_NUMBER/locations/global/workloadIdentityPools/github/attribute.repository/$REPO"

Y en el workflow:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write            # sin esto GitHub no emite el token OIDC
    steps:
      - uses: actions/checkout@v4
      - id: auth
        uses: google-github-actions/auth@v3
        with:
          workload_identity_provider: projects/123456789012/locations/global/workloadIdentityPools/github/providers/github-oidc
          service_account: github-actions@my-project.iam.gserviceaccount.com
      - uses: google-github-actions/setup-gcloud@v3
      - run: gcloud storage ls

Los roles que necesite el pipeline (Artifact Registry, Cloud Run, GKE…) se los das a github-actions@… como a cualquier service account.

Por qué

La alternativa clásica es exportar una llave JSON del service account y guardarla como secreto en GitHub. Esa llave no caduca, cualquiera con acceso al repo o a los logs puede copiarla, y rotarla es un trabajo manual que nadie hace. Con Workload Identity Federation GitHub emite un token OIDC de corta vida para cada job, Google lo verifica contra el issuer de GitHub, comprueba tu attribute condition y entrega credenciales temporales del service account. No hay secreto que guardar ni rotar, y puedes limitar quién entra hasta el nivel de repo o rama.

Las piezas

Para restringir a una rama, mapea el claim y úsalo en la condición y en el binding:

1
2

--attribute-mapping="…,attribute.ref=assertion.ref"
--attribute-condition="assertion.repository_owner == 'my-org' && assertion.ref == 'refs/heads/main'"

Con Terraform

El módulo oficial hace pool, proveedor y bindings en un bloque:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

module "github_actions_sa" {
  source     = "terraform-google-modules/service-accounts/google"
  version    = "~> 4.0"
  project_id = var.project_id
  names      = ["github-actions"]
  project_roles = ["${var.project_id}=>roles/artifactregistry.writer"]
}

module "gh_oidc" {
  source              = "terraform-google-modules/github-actions-runners/google//modules/gh-oidc"
  project_id          = var.project_id
  pool_id             = "github"
  provider_id         = "github-oidc"
  attribute_condition = "assertion.repository_owner == 'my-org'"
  sa_mapping = {
    "github-actions" = {
      sa_name   = "projects/${var.project_id}/serviceAccounts/${module.github_actions_sa.email}"
      attribute = "attribute.repository/my-org/my-repo"
    }
  }
}

output "workload_identity_provider" { value = module.gh_oidc.provider_name }

El output es exactamente el valor que va en workload_identity_provider del workflow.

Sin service account

auth@v3 también admite federación directa: el principalSet recibe roles IAM sin pasar por un service account (workload_identity_provider y project_id, sin service_account). Menos piezas, pero no todos los servicios aceptan principales federados; para Artifact Registry, GCS y la mayoría de APIs sí, y es el camino que Google recomienda para casos nuevos.

Trampas

• id-token: write en permissions del job. Sin él, auth falla con “Unable to get ACTIONS_ID_TOKEN_REQUEST_URL”.
• Número de proyecto, no ID, en la ruta del proveedor y del principalSet: projects/123456789012/….
• Permission 'iam.serviceAccounts.getAccessToken' denied: falta el binding roles/iam.workloadIdentityUser o el attribute.repository no coincide (mayúsculas y nombre exacto del repo).
• La condición debe referirse a claims mapeados: si usas assertion.ref en la condición sin haberlo mapeado a un atributo, el proveedor se crea pero nunca casa.
• Forks y PRs externos: los tokens de un PR desde un fork llevan repository del fork; una condición por repository_owner los deja fuera, que suele ser lo que quieres.
• Rotación: no hay nada que rotar, pero sí que revisar. gcloud iam workload-identity-pools providers describe y los logs de auditoría de STS dicen quién está entrando.

Referencia: google-github-actions/auth y Workload Identity Federation en la documentación de Google Cloud.

MySQL, en el servidor origen:

1
2
3
4

mysqldump --databases app -h db.example -u dumper -p \
  --hex-blob --single-transaction --set-gtid-purged=OFF \
  --default-character-set=utf8mb4 --routines --triggers --events \
  | sed -E 's/DEFINER=`[^`]+`@`[^`]+`//g' | gzip > app.sql.gz

PostgreSQL, en el servidor origen:

1
2

pg_dump app -h db.example -U dumper --format=plain --no-owner --no-acl \
  | sed -E 's/(DROP|CREATE|COMMENT ON) EXTENSION/-- \1 EXTENSION/g' | gzip > app.sql.gz

Y en los dos casos:

1
2
3
4
5
6
7

SA=$(gcloud sql instances describe my-instance --format='value(serviceAccountEmailAddress)')
gcloud storage buckets add-iam-policy-binding gs://my-dumps \
  --member="serviceAccount:$SA" --role=roles/storage.objectAdmin
gcloud storage cp app.sql.gz gs://my-dumps/

gcloud sql import sql my-instance gs://my-dumps/app.sql.gz --database=app                 # MySQL
gcloud sql import sql my-instance gs://my-dumps/app.sql.gz --database=app --user=postgres  # PostgreSQL

gcloud sql import sql acepta SQL plano o .gz: el formato custom de pg_dump va por pg_restore (abajo).

Los errores y de dónde salen

En Cloud SQL nadie tiene SUPER (MySQL) ni es superusuario (PostgreSQL); el administrador es root@% o postgres, miembro de cloudsqlsuperuser. Todo lo que un dump normal da por hecho de un servidor propio se rompe justo ahí:

MySQL: qué hacer con los DEFINER

Primero mira cuántos y cuáles hay en el origen:

1
2
3
4

SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.VIEWS;
SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.TRIGGERS;
SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.ROUTINES;
SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.EVENTS;

Tres salidas, de más a menos fiel al original:

1. Crear los usuarios en la instancia antes de importar, con el mismo user@host: gcloud sql users create app --host=% --instance=my-instance --password=…. Es lo que recomienda la documentación, y mantiene las vistas y procedimientos exactamente como estaban. root@localhost es la excepción: no se puede crear en Cloud SQL, así que un DEFINER con ese valor hay que cambiarlo sí o sí.
2. Quitar el DEFINER con el sed de arriba: los objetos se crean con el usuario que importa como definer. Suficiente cuando los usuarios del origen no van a existir en Cloud SQL.
3. Pasar a SQL SECURITY INVOKER (sed -E 's/SQL SECURITY DEFINER/SQL SECURITY INVOKER/g' además del anterior): la vista o el procedimiento corre con los privilegios de quien lo llama y el definer deja de importar. Cambia el modelo de permisos; revisa que los usuarios de la aplicación puedan leer las tablas de debajo.

El sed es deliberadamente amplio porque DEFINER= aparece también dentro de comentarios condicionales (/*!50013 DEFINER=… SQL SECURITY DEFINER */); borrar solo el DEFINER= deja el resto intacto y válido.

MySQL: los flags, uno por uno

Si el usuario con el que haces el dump no tiene PROCESS, mysqldump 8.0.21+ falla al inicio con “Access denied; you need (at least one of) the PROCESS privilege(s)” al consultar tablespaces: añade --no-tablespaces.

PostgreSQL: plano o custom

--no-owner --no-acl hacen que todo lo importado pertenezca al --user y no haya GRANT a roles fantasma. Si la aplicación se conecta con otro rol, crea el rol antes y usa --user=app, o reasigna después:

1

REASSIGN OWNED BY postgres TO app;   -- conectado como postgres, en la base importada

Las extensiones que necesite la base (pg_trgm, postgis, uuid-ossp…) créalas antes de importar, como postgres, en la base destino: CREATE EXTENSION IF NOT EXISTS pg_trgm;. Solo funcionan las de la lista de extensiones soportadas de Cloud SQL; plpgsql ya está. Con eso, comentar los CREATE EXTENSION del dump no quita nada.

Si prefieres el formato custom (-Fc), el filtro de extensiones va en la lista de contenidos de pg_restore, tal como lo documenta Google, y restauras a través del Cloud SQL Auth Proxy:

1
2
3

pg_dump app -h db.example -U dumper --format=custom --no-owner --no-acl > app.dmp
pg_restore --list app.dmp | sed -E 's/(.*EXTENSION )/; \1/g' > app.toc
pg_restore --use-list=app.toc --no-owner --no-acl -j 4 -h 127.0.0.1 -U postgres -d app app.dmp

-j 4 restaura en paralelo, cosa que la importación desde el bucket no hace.

Trampas

• El rol del bucket va a la service account de la instancia, no a la tuya: la documentación pide storage.objectAdmin (para importar bastan storage.objects.get y list, es decir, objectViewer). Sin él, “The service account does not have the required permissions for the bucket” aunque tú puedas leer el objeto.
• Una operación a la vez por instancia: si hay un backup o export en marcha, la importación falla con “operation already in progress”. gcloud sql operations list --instance=my-instance lo muestra.
• Dumps grandes: la importación es en serie y tarda; lanza con --async y vigila con gcloud sql operations wait OPERATION_ID --timeout=unlimited, o el gcloud se te muere por el camino.
• Versión de pg_dump: usa la misma versión mayor que el destino o inferior. pg_dump 17 escribe SET transaction_timeout = 0;, que un PostgreSQL 16 rechaza con “unrecognized configuration parameter” y aborta la importación.
• utf8mb4 en la instancia: --default-character-set=utf8mb4 en el dump no arregla una instancia creada con latin1; comprueba character_set_server en los flags de la instancia antes de importar.
• El sed de DEFINER también toca datos: si alguna fila contiene literalmente DEFINER=`x`@`y` (raro, pero un CMS que guarda SQL puede), sáltala con un patrón anclado a CREATE, o revisa el diff del dump.

Ver también

• PostgreSQL: cheat sheet de administración — roles, pg_dump, REASSIGN OWNED y compañía.
• Import and export using SQL dump files (MySQL), DEFINER clause y pg_dump / pg_restore (PostgreSQL) en la documentación de Cloud SQL.