Permisos en Google Cloud: identidad, rol y recurso con una práctica local

Una aplicación recibe un error de permisos. Tu usuario puede abrir el proyecto, pero el programa sigue fallando. Antes de añadir otro rol, conviene responder a tres preguntas: ¿quién hace la petición, qué quiere hacer y sobre qué recurso?

En esta primera entrega de permisos vamos a leer políticas pequeñas, cambiar la identidad que estamos mirando y comparar dos archivos. Así veremos por qué una concesión a una persona no aparece automáticamente para la cuenta de servicio que ejecuta su aplicación.

La práctica está probada en un lector local de JSON. No ejecuta el motor de autorización de Google Cloud ni prueba una petición real contra sus servicios. Los datos son ficticios; las capturas muestran la herramienta funcionando con esos archivos. La parte que utiliza Google Cloud se ofrece como guía documental de lectura, identificada al final.

Portada conceptual generada con IA. No es una captura de Google Cloud ni acredita un cambio de permisos.

Qué necesitas y qué vas a obtener

Un navegador, un editor de texto si quieres revisar el JSON y el ejemplo descargable. El recorrido principal funciona abriendo un HTML: no necesitas cuenta de Google, tarjeta, gcloud, Node, npm ni un servidor.

El material propio tiene licencia MIT. No incorpora claves o datos de un proyecto real y funciona sin conexión. La lectura de estos archivos no consume cuotas cloud. Si más adelante utilizas un proyecto real, sus servicios mantienen sus requisitos y costes; revisa la información oficial de precios de IAM y la de los servicios implicados antes de ampliar la práctica. Aquí no los creamos.

Al terminar podrás localizar un rol, reconocer si está escrito en el proyecto o en el servicio y detectar cuándo falta información para concluir algo. Eso es distinto de asegurar que una petición real está permitida.

1. Separar identidad, rol, permiso y recurso

En IAM, la identidad —también llamada principal— puede ser una persona o una carga de trabajo. Un rol agrupa permisos y se vincula a una identidad sobre un recurso. El permiso describe una operación; el rol es la colección que se asigna. Conceptos de IAM.

En nuestro ejemplo aparecen estos nombres ficticios:

Elemento	Qué representa
user:ana@example.com	La persona que consulta la configuración.
cliente-runtime@proyecto-demo.iam.gserviceaccount.com	Una cuenta de servicio para una aplicación cliente.
saludos-runtime@proyecto-demo.iam.gserviceaccount.com	Otra cuenta, que ejecutaría el servicio de destino.
roles/run.viewer	Un rol para consultar recursos de Cloud Run.
roles/run.invoker	Un rol que incluye invocar servicios de Cloud Run.
Servicio saludos	El recurso de destino de la práctica.

Ver la configuración y llamar a un endpoint son operaciones distintas. Los roles del ejemplo tampoco son una lista completa de requisitos de despliegue. Roles oficiales de Cloud Run.

2. Extraer el ZIP y abrir el lector

Extrae la carpeta lector-politicas-iam. Dentro encontrarás:

lector-politicas-iam/
  index.html
  estilo.css
  lector.js
  interfaz.js
  politicas/
    01-antes.json
    02-despues.json
    03-rol-amplio.json
  comprobar.cjs
  package.json
  LEEME.md
  LICENSE

Abre index.html con el navegador. La página explica su alcance antes de mostrar resultados.

Aplicación didáctica propia, ejecutada localmente y sin conexión. No imita la consola de Google Cloud.

Conserva juntos HTML, CSS y JavaScript. Si extraes solo index.html, faltarán los archivos que hacen funcionar el lector.

3. Cargar una política de la práctica

Pulsa Seleccionar archivo y elige politicas/01-antes.json. No introduzcas políticas privadas: no las necesitamos para este recorrido.

Cada entrada de policies contiene un recurso y su política allow. Dentro de bindings, un rol se relaciona con una lista de miembros. Por ejemplo:

{
  "role": "roles/run.viewer",
  "members": ["user:ana@example.com"]
}

El archivo del descargable reúne dos políticas para poder compararlas: una del proyecto y otra del servicio. Ese contenedor didáctico no es una política única lista para aplicar con set-iam-policy. La estructura real de las políticas se explica en la documentación de políticas allow.

El lector solo admite la cadena proyecto → servicio Cloud Run de estos ejemplos. No resuelve organizaciones, carpetas o recursos de otro proyecto.

4. Encontrar un rol que procede del proyecto

En Selecciona una identidad, elige user:ana@example.com.

El rol aparece en la política del proyecto ficticio. El lector muestra su procedencia, además de su nombre.

La herencia importa: las concesiones de una política de un ancestro pueden aplicarse a sus recursos descendientes. Por eso mirar únicamente la política adjunta al servicio deja fuera una parte de la información. La ausencia de un rol en el hijo no elimina una concesión escrita en el proyecto. Herencia de las políticas IAM.

En la práctica hemos probado también ese caso: al vaciar las vinculaciones del servicio en una copia de los datos, la concesión del proyecto sigue apareciendo. No es una prueba de revocación en Google Cloud: es una comprobación de la lectura de estos dos archivos.

5. Mirar a la cuenta que ejecutaría el cliente

Ahora selecciona:

serviceAccount:cliente-runtime@proyecto-demo.iam.gserviceaccount.com

La concesión a Ana no se ha convertido en una concesión a la cuenta cliente.

Una cuenta de servicio puede actuar como identidad de una aplicación. No es la misma identidad que el usuario que abre la consola o despliega. Qué es una cuenta de servicio.

El lector dice «no hay coincidencias explícitas en estos archivos». No dice «acceso denegado por Google Cloud». No conoce todas las políticas, grupos, condiciones y restricciones que intervendrían en una petición real.

6. Comparar con una copia que añade una vinculación concreta

Sin cambiar la identidad seleccionada, carga politicas/02-despues.json.

Cambio de resultado calculado a partir del segundo JSON. No se ha concedido un rol en Google Cloud.

La diferencia del segundo archivo es esta vinculación, añadida a la política del servicio de destino:

{
  "role": "roles/run.invoker",
  "members": [
    "serviceAccount:cliente-runtime@proyecto-demo.iam.gserviceaccount.com"
  ]
}

Fíjate en el recurso: en la práctica la escribimos en el servicio, no en todo el proyecto. Elegir el ámbito forma parte de la decisión; no es suficiente elegir un nombre de rol.

Esta copia ayuda a ver qué cambiaría en el documento. No demuestra por sí sola que una llamada real funcione: aún habría que comprobar identidad efectiva, autenticación, configuración del servicio y las demás políticas aplicables. No hemos creado un servicio ni ejecutado esa llamada.

7. Distinguir las dos cuentas de servicio

Selecciona ahora serviceAccount:saludos-runtime@proyecto-demo.iam.gserviceaccount.com. Verás que no hereda la vinculación que hemos escrito para cliente-runtime.

En un escenario real, una aplicación cliente puede ejecutarse con una cuenta y el servicio de destino con otra. Dar un rol a la cuenta equivocada no cambia qué identidad utiliza la petición.

Cloud Run distingue además entre la identidad que despliega y la identidad de ejecución del servicio. Poder asociar una cuenta de servicio a una revisión requiere permisos específicos sobre esa cuenta, además de los demás necesarios para desplegar. Esa asociación no otorga automáticamente a la cuenta de ejecución acceso a otros recursos. Identidad de servicio en Cloud Run.

No descargamos claves ni modificamos identidades en esta entrega.

8. Reconocer una condición que no hemos evaluado

Con 02-despues.json cargado, elige user:bea@example.com.

La expresión de fecha se muestra como texto, sin fingir que el lector ejecuta CEL o toma una decisión de IAM.

El ejemplo contiene una condición temporal. Aunque reconozcas su fecha, no uses esta herramienta como validador de condiciones: no ejecuta el lenguaje CEL ni recibe el contexto de una petición. Las políticas que contienen condiciones necesitan representar esa información correctamente; los archivos de la práctica usan version: 3. IAM Conditions.

Esta es una diferencia importante entre encontrar un miembro en un documento y evaluar si una concesión condicional se aplica.

9. No adivinar la pertenencia a un grupo

Los archivos incluyen una vinculación a group:equipo@example.com. El lector la señala como sin resolver.

No dispone de un directorio de miembros, así que no supone que Ana, Bea o la cuenta cliente pertenezcan a ese grupo. Si seleccionas user:otra@example.com, la presencia del grupo no se convierte en una coincidencia personal.

En una revisión real hay que investigar esas membresías y el resto de las políticas aplicables. También pueden intervenir políticas deny y límites de acceso de principales —principal access boundaries—. Este lector no los evalúa. Políticas deny y límites de acceso de principales.

10. Detectar un rol demasiado amplio sin concederlo

Carga politicas/03-rol-amplio.json y selecciona Ana.

Archivo deliberado para aprender a reconocer una concesión amplia. No se ha asignado Owner a nadie.

El objetivo de esta copia es que te fijes en el rol y en dónde está escrito. Para una tarea concreta, investiga un rol predefinido y un ámbito adecuados, en lugar de utilizar Owner o Editor como respuesta automática a cualquier fallo.

Cambiar permisos sin identificar la operación puede ocultar la causa y ampliar el acceso de otra identidad. Tampoco debes retirar una concesión de un proyecto compartido solo porque te parezca amplia: primero hay que conocer qué cargas de trabajo dependen de ella.

11. Comprobar que un archivo inválido no conserva un resultado anterior

Crea una copia de prueba con un JSON incompleto —por ejemplo, solo {— y cárgala. No edites el original si quieres conservarlo.

Al fallar la lectura, se borra el resultado anterior. No se mantiene una tarjeta que pueda confundirse con el contenido del archivo nuevo.

La herramienta también rechaza un recurso de otro proyecto, políticas duplicadas y condiciones que no tengan el formato admitido. Ese rechazo solo indica que el archivo queda fuera de esta práctica, no que sea una política inválida para todos los usos de Google Cloud.

12. Repetir las comprobaciones del ejemplo

El recorrido de navegador no necesita instalar nada. Si ya tienes Node y quieres ejecutar las pruebas incluidas, abre una terminal en la carpeta extraída:

node --test comprobar.cjs

Se han ejecutado con Node 24.19.0. No hay dependencias que instalar con npm. Comprueban ocho casos: separación de identidades, cambio limitado a la copia del servicio, herencia, condición sin evaluar, grupos sin resolver y rechazo de varias entradas fuera del alcance.

También se ha probado el descargable desde una extracción nueva, con el lector abierto sin conexión. Las pruebas son del código del lector; no son pruebas de la autorización de Google Cloud IAM.

13. Leer políticas reales cuando tengas un entorno autorizado

Lo siguiente está contrastado documentalmente y no se ha ejecutado sobre un proyecto cloud durante la preparación. No necesitas hacerlo para completar el ejemplo local.

Si ya tienes un proyecto y acceso autorizado, puedes consultar por separado la política del proyecto y la del servicio:

gcloud projects get-iam-policy MI_PROYECTO --format=json

gcloud run services get-iam-policy MI_SERVICIO --project MI_PROYECTO --region MI_REGION --format=json

Sustituye los nombres por los tuyos y confirma el destino. Son comandos de lectura; pueden fallar si tu identidad no tiene permiso para consultar esas políticas. No lo arregles concediéndote un rol amplio por tu cuenta. Referencia del proyecto y del servicio Cloud Run.

La política devuelta para un servicio no sustituye revisar los ancestros que correspondan. Tampoco metas esa salida privada en el ejemplo didáctico esperando un análisis completo: su formato y su alcance son deliberadamente limitados.

Antes de cambiar algo en un entorno real, registra identidad, permiso concreto, recurso, origen de la concesión y operación que falla. Conserva el estado anterior y acuerda cómo revertir únicamente el cambio autorizado.

14. Comprobar el acceso efectivo con la herramienta adecuada

Para investigar una petición concreta en Google Cloud, la documentación de Policy Troubleshooter explica cómo analizar una identidad, un recurso y un permiso. Su resultado depende de la información y los permisos disponibles para quien consulta; los estados desconocidos o la información incompleta no se deben convertir en una conclusión segura. Diagnóstico oficial de permisos.

Esta parte no incluye capturas de una cuenta cloud ni un resultado remoto inventado. Cuando tengamos un entorno de prueba autorizado podremos añadir una petición observada, su diagnóstico y una modificación reversible. Hasta entonces, lo probado aquí es la lectura local de los archivos.

IAM y Firebase Security Rules no son la misma cosa

La entrega anterior utilizaba el emulador de Firebase Hosting, sin base de datos. IAM gestiona acceso a recursos de Google Cloud; las Security Rules de Firebase tienen otro papel en el acceso de los clientes a los datos de los productos que las utilizan. No se arregla un problema de uno copiando sin más una configuración del otro. Security Rules y autenticación de Firebase.

El tutorial de Cloud Run y PORT trata otro tipo de fallo: dónde escucha el proceso. Cambiar un rol no corrige un servidor que está en el puerto equivocado.

Qué se ha probado y qué queda fuera

El ejemplo incluye tres archivos ficticios, un lector sin dependencias, ocho pruebas y siete capturas reales. Se ha comprobado con Chrome 153 en una sesión aislada, sin peticiones HTTP/HTTPS del lector, y con una ventana de 390 píxeles. No se ha probado un móvil físico ni un lector de pantalla.

No se han creado usuarios o cuentas de servicio, leído credenciales, concedido/revocado roles, ejecutado Policy Troubleshooter ni realizado llamadas contra un recurso cloud. Tampoco se resuelven grupos, condiciones, catálogo completo de permisos, deny o límites de acceso. Esos límites están presentes en el artículo y en la herramienta.

Descarga el lector y las políticas de práctica. Fuentes oficiales revisadas el 20 de octubre de 2026. El resultado que buscamos en esta primera entrega es poder explicar de dónde sale una concesión y saber cuándo todavía no tenemos datos para afirmar que una operación está autorizada.