BigQuery en GCP paso a paso: alta, IAM y credenciales JSON

Activar BigQuery en GCP parece un trámite menor hasta que el uso deja de ser individual. El primer analista que no puede consultar por permisos, el primer entorno local que falla al autenticarse o la primera clave JSON compartida por mensajería convierten una puesta en marcha aparentemente simple en un problema de seguridad, trazabilidad y tiempo de plataforma. En ese momento, el coste real ya no está en BigQuery. Está en la fricción operativa que has dejado entrar alrededor del servicio.

Esta guía de BigQuery en GCP paso a paso cubre justo eso: cómo activarlo, cómo crear el primer dataset, cómo configurar IAM para el equipo de datos y cómo generar credenciales seguras, incluidas las credenciales JSON cuando no queda otra opción. El objetivo no es solo que una consulta responda. El objetivo es que la configuración aguante auditoría, rotación de personal, automatización y revisiones de seguridad sin obligarte a rehacer IAM una semana después.

BigQuery en GCP se decide en el proyecto, la facturación y la región antes del primer dataset

El error más común es abrir la consola, crear un dataset y asumir que BigQuery ya quedó listo. En la práctica, lo que más condiciona coste, cumplimiento y capacidad de cambio se decide antes. Si esa base queda ambigua, todo lo demás se resolverá a golpe de excepción.

Hay cuatro decisiones que conviene cerrar en este orden:

1. Elige un proyecto con frontera clara y responsable definido.
   Si BigQuery va a alojar datos de negocio, evita montarlo en un proyecto genérico donde conviven pruebas, demostraciones y servicios de otras áreas. Lo razonable es usar un proyecto con responsable claro, etiquetas coherentes y una frontera de acceso fácil de gobernar. Si tu equipo todavía es pequeño, quizá no necesites un proyecto por dominio, pero sí deberías separar al menos producción del resto.

2. Asocia facturación desde el principio si habrá uso real.
   BigQuery Sandbox sirve para exploración muy inicial o pruebas individuales. En cuanto hay equipo, automatización o dependencia de otros sistemas, posponer la facturación suele crear una segunda migración administrativa cuando ya existen datasets, consultas y procesos que no conviene tocar.

3. Habilita solo las API que vayas a usar, pero hazlo antes del primer caso serio.
   Como mínimo, activa la API de BigQuery, ya sea desde la consola o con gcloud services enable bigquery.googleapis.com. Si el equipo va a usar bibliotecas cliente, conectores o lecturas intensivas basadas en la API de almacenamiento, valora también bigquerystorage.googleapis.com. No se trata de activar todo por inercia, sino de no descubrir dependencias evidentes en mitad de una entrega.

4. Fija la ubicación antes de crear nada.
   La ubicación del dataset afecta a residencia del dato, latencia, cumplimiento y compatibilidad entre cargas. Además, no es una decisión que luego cambies sin coste. Si hoy creas el primer dataset en US por costumbre y mañana necesitas EU, te tocará copiar datos, revisar procesos y corregir referencias. Tampoco podrás combinar sin más tablas alojadas en ubicaciones distintas dentro de la misma consulta. Lo que parece un detalle cosmético suele acabar siendo una restricción arquitectónica.

El primer dataset fija acceso, retención y trazabilidad mucho antes de que existan las tablas

En BigQuery, el primer dataset, es decir, el primer conjunto de datos, acaba siendo mucho más que un contenedor lógico. Suele convertirse en la frontera de permisos, en el lugar donde defines la caducidad predeterminada de tablas y en la unidad que después aparece en auditorías, revisiones de acceso y análisis de coste. Por eso merece cinco minutos de atención antes de pulsar guardar.

No hace falta diseñar toda la taxonomía de la plataforma el primer día. Sí hace falta evitar nombres débiles, ausencia total de caducidad y ubicaciones mezcladas sin criterio. Con dos tablas no parece grave. Con varias cargas, consumidores y revisiones de acceso, ya lo es.

Si prevés separar datos de origen, capas transformadas y consumo analítico, define una convención de nombres que pueda crecer contigo. La prioridad no es la elegancia. La prioridad es que dentro de tres meses siga siendo evidente qué contiene cada dataset, quién lo usa y qué nivel de control exige.

Configurar IAM en BigQuery evita el bloqueo más caro del equipo

BigQuery rara vez falla porque el equipo no sabe escribir SELECT. Suele fallar porque el modelo de permisos se resolvió con prisa. El patrón es conocido: alguien ve el dataset pero no puede ejecutar consultas; otra persona puede lanzar trabajos, pero no leer las tablas correctas; una tercera acaba con permisos de administración total porque era la salida rápida. Ese atajo reduce fricción durante unas horas y encarece la gobernanza durante meses.

En la práctica conviene separar tres planos: la capacidad de ejecutar consultas y trabajos en el proyecto, el acceso a los datos dentro de cada dataset y los permisos adicionales que exigen algunos patrones, como lecturas mediante BigQuery Storage API o la suplantación de una cuenta de servicio.

La distinción importa. roles/bigquery.jobUser no sustituye al acceso al dato, y roles/bigquery.dataViewer no permite ejecutar trabajos por sí solo. Cuando el equipo no separa ambos planos, la salida fácil suele ser sobredimensionar permisos.

También conviene evitar dos atajos frecuentes. El primero es dar roles/bigquery.user de forma general sin revisar si de verdad quieres que el equipo cree datasets. El segundo es conceder roles/bigquery.admin al área completa. Ambos alivian un bloqueo puntual y empeoran el control desde el día uno.

Si el acceso cambia con frecuencia, no lo gestiones persona por persona. Usa grupos de Google Workspace o Cloud Identity. Incluso en equipos pequeños compensa rápido si esperas incorporaciones, salidas o revisiones de acceso. Un patrón razonable es este:

1. Crea un grupo, por ejemplo data-team@tuempresa.com.
2. Añade al grupo solo a quienes necesitan acceso efectivo.
3. Concede al grupo roles/bigquery.jobUser en el proyecto.
4. Asigna en cada dataset el rol de lectura o edición que corresponda al mismo grupo.
5. Añade roles/bigquery.readSessionUser solo cuando una herramienta o biblioteca lo necesite de verdad.

Cuando alguien entra o sale del equipo, el cambio se hace en un único punto. Eso acelera la operación diaria y reduce la probabilidad de que queden permisos huérfanos repartidos entre IAM del proyecto y permisos de dataset.

Para personas, la credencial correcta es su identidad corporativa

Cuando alguien pide “credenciales para BigQuery”, casi siempre está mezclando dos problemas distintos: cómo se autentican las personas y cómo se autentican los procesos. Si quien va a trabajar es un analista o un ingeniero desde su portátil, la respuesta por defecto no debería ser una cuenta de servicio compartida ni una clave JSON que circule por chat.

Para herramientas locales que respetan las credenciales predeterminadas de la aplicación, conocidas como Application Default Credentials o ADC, lo más limpio suele ser autenticar al usuario con su identidad corporativa:

gcloud auth application-default login

No conviene confundir este comando con gcloud auth login. Ese otro flujo autentica la CLI de Google Cloud, pero no siempre resuelve las credenciales que consumen las bibliotecas cliente. Si el equipo trabaja con Python, dbt u otras herramientas que usan los SDK de Google Cloud, gcloud auth application-default login suele ser el punto correcto de partida.

Con este modelo, cada persona opera con su propia identidad. BigQuery aplica IAM normal, los registros de auditoría conservan quién hizo qué y no hace falta repartir secretos estáticos por portátiles o carpetas compartidas. Operativamente, eso simplifica altas y bajas, análisis de incidentes y cumplimiento.

Hay organizaciones que, por política interna, prefieren que el acceso local no use directamente la cuenta del usuario sobre el dato. En ese caso, la alternativa razonable no es volver a una clave JSON permanente, sino usar suplantación de identidad de una cuenta de servicio. Para eso, la persona o el grupo necesitan roles/iam.serviceAccountTokenCreator sobre la cuenta de servicio objetivo.

gcloud auth application-default login \
  --impersonate-service-account=bq-data-runner@PROJECT_ID.iam.gserviceaccount.com

Con ese enfoque, la persona sigue autenticándose con su identidad corporativa, pero obtiene credenciales temporales para actuar como una cuenta de servicio concreta. Mantienes trazabilidad, reduces la exposición de secretos y evitas que una excepción local se convierta en el modelo de acceso por defecto.

Las cuentas de servicio deben pertenecer a procesos concretos, no al equipo entero

Cuando hay cargas programadas, orquestadores, aplicaciones o integraciones sin intervención humana, sí tiene sentido crear cuentas de servicio. Lo importante es que cada una represente un proceso concreto y no se convierta en la identidad genérica de todo el equipo.

Ese matiz cambia mucho la operación diaria. Si una sola cuenta de servicio sirve para procesos de carga, conectores externos, usos locales y automatizaciones varias, la auditoría se vuelve opaca, la revocación es dolorosa y cualquier ampliación de permisos afecta a demasiados consumidores a la vez.

Un criterio operativo sano suele ser este:

1. Una cuenta de servicio por proceso o integración relevante.
   Por ejemplo, bq-data-runner para una carga concreta o un proceso de transformación definido. Si mañana incorporas otra integración con requisitos distintos, crea otra identidad. No intentes que una sola sirva para todo.

2. Permisos mínimos y acotados.
   Lo habitual es conceder roles/bigquery.jobUser en el proyecto y roles/bigquery.dataViewer o roles/bigquery.dataEditor solo en los datasets que ese proceso necesita. Si el proceso usa BigQuery Storage API, añade roles/bigquery.readSessionUser únicamente en ese caso.

3. Identidad adjunta al entorno de ejecución siempre que sea posible.
   Si el proceso corre en Cloud Run, GKE, Compute Engine, Composer o servicios similares, adjunta la cuenta de servicio al entorno y evita descargar claves. Cuando la identidad viaja con el servicio, la operación es más segura y la rotación deja de ser un problema cotidiano.

4. Si el proceso vive fuera de GCP, revisa antes la federación de identidades de cargas de trabajo.
   Antes de generar una clave, comprueba si la integración puede usar Workload Identity Federation. Para muchas cargas externas, esa opción reduce la dependencia de secretos persistentes y mejora el control operativo.

La regla práctica es simple: para personas, identidad corporativa; para procesos, cuentas de servicio específicas. En cuanto mezclas ambos modelos, reaparece la fricción.

Cómo generar credenciales JSON para BigQuery sin convertirlas en deuda permanente

Hay casos en los que no queda más remedio. Algunas herramientas heredadas, ciertos conectores externos o entornos muy restringidos siguen exigiendo una clave JSON de cuenta de servicio. Si buscas cómo generar credenciales JSON para BigQuery, el punto importante no es solo el comando o el botón de descarga. Lo importante es que la excepción quede acotada, entendida y reversible.

Cómo generar el .json desde la consola de GCP

Si lo vas a hacer desde la interfaz de Google Cloud, el recorrido habitual es este:

1. Ve a IAM y administración > Cuentas de servicio.
2. Crea una cuenta nueva o entra en la cuenta de servicio que ya vayas a usar, por ejemplo bq-data-runner.
3. Abre la pestaña Claves.
4. Pulsa Agregar clave > Crear clave nueva.
5. Selecciona JSON y confirma la creación.
6. Descarga el archivo y muévelo de inmediato a un lugar seguro.

Ese archivo solo se descarga en el momento de creación. Si se pierde, la respuesta correcta no es intentar recuperar "la misma clave", sino crear una nueva y revocar la anterior.

Cómo generarlo por CLI

Si de verdad necesitas un archivo .json, este es el flujo mínimo razonable:

1. Crea una cuenta de servicio dedicada a ese uso.
   Si la cuenta ya existe, reutiliza esa identidad concreta. Si no existe, puedes crearla y generar la clave así:

gcloud iam service-accounts create bq-data-runner \
  --display-name="BigQuery Data Runner"

gcloud iam service-accounts keys create ./bq-data-runner.json \
  --iam-account=bq-data-runner@PROJECT_ID.iam.gserviceaccount.com

1. Asigna solo los permisos que necesita.
   En la mayoría de los casos, eso significa roles/bigquery.jobUser en el proyecto y roles/bigquery.dataViewer o roles/bigquery.dataEditor en el dataset correspondiente. Si una integración concreta necesita algo más, deja por escrito por qué.

2. Guarda la clave en un gestor de secretos o en un almacén seguro.
   Si termina en un chat, en una carpeta compartida o en un repositorio, el problema ya no es BigQuery. Es exposición de credenciales.

3. Configura la ruta de la clave para las bibliotecas cliente.
   Las bibliotecas de Google Cloud leerán ese archivo a través de ADC:

export GOOGLE_APPLICATION_CREDENTIALS="$PWD/bq-data-runner.json"

1. Si vas a usar la herramienta bq, activa explícitamente la cuenta de servicio en el SDK de Google Cloud.
   Para la línea de comandos, este paso suele ser más fiable que depender solo de la variable de entorno:

gcloud auth activate-service-account \
  --key-file="$PWD/bq-data-runner.json"

1. Valida el acceso con una consulta mínima antes de darlo por resuelto.
   Con bq:

bq query --use_legacy_sql=false 'SELECT 1 AS ok'

Y con Python:

from google.cloud import bigquery

client = bigquery.Client()
query_job = client.query("SELECT 1 AS ok")
print(list(query_job.result()))

Lo importante no es que el .json funcione. Lo importante es que siga siendo una excepción controlada. Si el equipo entero depende de una sola clave para trabajar, no has resuelto la autenticación. Solo has desplazado el problema a un secreto estático más difícil de gobernar.

En cuanto exista una clave, impón disciplina operativa:

• Define una frecuencia de rotación y cúmplela.
• Revoca la clave cuando la integración deje de usarse.
• No reutilices la misma clave entre personas o herramientas distintas.
• Supervisa quién la usa y desde dónde.
• No la subas nunca al repositorio, ni siquiera si es privado.

Además, deja documentado junto a esa clave qué integración la usa, dónde está almacenada y quién es responsable de rotarla o retirarla. Sin ese contexto, el secreto sobrevive más que el caso de uso y acaba convirtiéndose en deuda permanente.

Antes de abrir acceso al equipo, estas comprobaciones deberían quedar resueltas

Antes de dar por terminada la puesta en marcha, conviene hacer una revisión corta. Si varias filas fallan, lo que has resuelto es un acceso puntual, no un entorno gobernable.

Esta validación parece administrativa, pero en realidad es operativa. Si no la haces al principio, la acabarás haciendo después de un incidente, de una auditoría o de una semana perdida resolviendo permisos rotos.

Las dudas de la primera semana suelen concentrarse aquí

¿Me basta con BigQuery Sandbox?

Para una prueba individual y breve, puede bastar. Para trabajo real en equipo, casi nunca. En cuanto necesitas compartir conjuntos de datos, automatizar cargas, controlar costes o integrar varias herramientas, conviene operar ya con un proyecto normal y facturación asociada. Retrasar esa decisión suele ahorrar muy poco y complicar bastante.

¿Tengo que generar una clave JSON para que un analista trabaje en local?

No, salvo que la herramienta lo imponga. Para uso local, intenta primero las credenciales predeterminadas de la aplicación con identidad corporativa y, si necesitas encapsular permisos, suplantación de una cuenta de servicio. La clave JSON debería reservarse para productos que no admiten un modelo mejor. Si todo acceso local empieza generando un secreto, el problema está en el diseño de identidad, no en BigQuery.

¿Conviene separar desarrollo, preproducción y producción en proyectos distintos?

Si ya separas entornos en GCP, mantén esa disciplina. BigQuery comparte las mismas razones: permisos más claros, costes atribuibles, menor riesgo de contaminar producción y operaciones menos confusas. Si tu uso aún es pequeño, al menos separa producción del resto. Mezclarlo todo en un único proyecto suele parecer más ágil hasta que aparece un borrado accidental, una auditoría o una revisión de costes.

¿Tiene sentido dar roles/bigquery.admin a todo el equipo para evitar bloqueos?

Como medida excepcional para desbloquear una incidencia, quizá te saque de un atasco. Como modelo permanente, casi nunca compensa. Lo razonable es reservar la administración completa a un grupo pequeño y separar permisos de ejecución, lectura y edición para el resto. Si necesitas una vía de emergencia, que sea explícita, temporal y revisable.

¿Cuándo hace falta roles/bigquery.readSessionUser?

No siempre. Suele ser necesario cuando la herramienta o la biblioteca cliente usa BigQuery Storage API para leer datos. Algunos conectores y ciertos flujos con DataFrame lo requieren; otros no. Añádelo cuando el patrón de acceso lo justifique, no como reflejo automático.

¿Puedo compartir una única cuenta de servicio entre todo el equipo?

Puedes hacerlo, pero no deberías usar ese modelo para personas. Pierdes trazabilidad, mezclas responsabilidades y normalizas el uso de secretos estáticos donde no hacen falta. Incluso entre procesos automáticos conviene separar identidades por integración o por carga relevante. La cuenta compartida de hoy suele convertirse en el cuello de botella de mañana.

Cuando haya dudas sobre permisos y autenticación, estas son las referencias canónicas

• BigQuery quickstart using the Google Cloud console
• Introduction to BigQuery access control
• BigQuery IAM roles and permissions
• Authenticate to BigQuery
• Create and delete service account keys
• Best practices for using service account keys

La activación de BigQuery condiciona el resto de la plataforma de datos

La forma en que resuelves proyecto, permisos y credenciales en BigQuery acaba afectando al gobierno del dato, al coste operativo y a la velocidad con la que el equipo puede automatizar nuevas cargas o productos analíticos. Si estás revisando esa decisión dentro de una conversación más amplia de plataforma, estos artículos conectan con el mismo problema:

• Plataforma de datos para analytics: confianza operativa y velocidad de decisión
• AWS vs GCP vs Azure para IA/ML en 2026: cómo decidir sin deuda operativa
• MLOps en producción: del prototipo a un sistema gobernable
• Airflow 3 en producción: cómo migrar sin romper tus pipelines
• Consultoría de ingeniería de datos: plataformas y pipelines