Generosidad bajo condiciones: Fortalecer el acceso a Google Cloud

En Google Cloud, Identity and Access Management (IAM) te ayuda a mantener el control de acceso sobre tus recursos y operaciones en la nube. Si bien incluye otras funciones, este es su propósito principal. Si alguna vez has tratado de endurecer la seguridad de tu aplicación, sabes la importancia del Principio del Mínimo Privilegio (PoLP) – otorgar los permisos mínimos absolutos a tus usuarios y cargas de trabajo para que puedan realizar sus tareas. Puedes lograr esto mediante el uso de roles predefinidos y roles personalizados, y al configurar una combinación de políticas de permitir y denegar IAM a nivel de proyecto, carpeta o organización. El uso de una combinación de políticas de permitir y denegar a lo largo de la jerarquía de recursos es una forma efectiva de controlar el acceso. Este enfoque te permite hacer cumplir el PoLP en muchos escenarios diferentes. El control flexible existente puede ser insuficiente cuando los recursos en el proyecto se comparten entre múltiples cargas de trabajo o son utilizados por más de un equipo. En muchos escenarios así, es posible vincular políticas de IAM a un recurso específico en el proyecto. Por ejemplo, considera la diferencia entre otorgar el rol Artifact Registry Editor (roles/artifactregistry.editor) en un proyecto frente a otorgarlo en un repositorio específico en el proyecto. En el primer caso, el acceso se otorga a cualquier repositorio en el proyecto. En el segundo caso, los usuarios tendrán acceso al editor solo a un repositorio específico. Sin embargo, vincular políticas de IAM a un nivel de recurso o servicio no siempre es posible. Es aquí cuando es hora de usar las condiciones de IAM. Veamos dos ejemplos distintos que demuestran el poder de las condiciones para endurecer la gestión del acceso: uno para roles administrativos tradicionales, y otro para integraciones modernas de IA. Caso de uso 1: Restringir el poder de los administradores. Este caso demuestra cómo restringir las operaciones específicas que están autorizadas para realizar los roles de IAM amplios. Puedes definir fácilmente los privilegios administrativos para administrar recursos específicos en un proyecto otorgando un rol de creador de recursos a nivel de proyecto y un rol de editor en un recurso seleccionado. Es mucho más desafiante restringir los roles de IAM de administración que están diseñados para otorgar acceso a operaciones en lugar de recursos específicos. Un ejemplo representativo es el rol de administrador de IAM (roles/iam.admin). Los usuarios que tienen este rol pueden otorgarse cualquier otro rol o crear uno nuevo. Esto excede significativamente las necesidades prácticas. El primer paso es reducir el acceso utilizando el rol de administrador de IAM (roles/resourcemanager.projectIamAdmin) que proporciona privilegios administrativos solo a nivel de proyecto. Sin embargo, es posible restringir aún más los privilegios otorgados. Por ejemplo, supongamos que otorgas el rol de administrador de IAM a tu cuenta de servicio que crea recursos y despliega cargas de trabajo. Solo las cargas de trabajo necesitan acceso a las API BigQuery y Agent Platform (anteriormente Vertex APIs) y permiso para escribir registros y trazas. Para este caso, puedes usar el siguiente comando gcloud CLI o su alternativa en Terraform: code_block )])]> El valor del parámetro de condición se define utilizando la sintaxis del Common Expression Language (CEL). Primero, personaliza un delimitador de campo para que sea un colon en lugar de una coma, y luego describe los campos de título y expresión de la condición. El campo de expresión utiliza funciones para atributos de API para identificar qué roles se están otorgando, lo que permite otorgar solo los roles en la lista delimitada por comas. La misma operación en Terraform se verá de manera muy similar. Usando variables de entrada en lugar de variables de entorno, se verá así: code_block )])]> Caso de uso 2: Control sobre el acceso al servidor MCP. Este caso se trata de endurecer el acceso a servicios específicos detrás de un conjunto de permisos. Google expone el acceso a un subconjunto de recursos y servicios en la nube a través de servidores MCP que expone extremos de Protocolo de Contexto de Modelo (MCP). El acceso a estos servidores se otorga utilizando el rol predefinido de Usuario de Herramientas de MCP (roles/mcp.toolUser). Este rol otorga acceso a TODOS los servidores de MCP disponibles (para un proyecto donde está configurada una política de IAM). Usar condiciones ayuda a restringir el acceso a un servidor MCP específico. code_block )])]> Ten en cuenta que el valor comparado con el atributo de servicio del recurso no es el extremo del servidor MCP (que es bigquery.googleapis.com/mcp) sino el extremo del servicio. Se puede restringir aún más el alcance del acceso al nivel de herramientas MCP específicas. Para esto, nuevamente necesitarás usar los atributos de la API. La siguiente expresión limita el acceso a la cuenta de servicio al nivel de solo dos herramientas de BigQuery MCP. code_block )])]> Ten en cuenta que si condiciones el vínculo de la política de IAM al nivel de la herramienta MCP, no es necesario validar el atributo de servicio. Para experimentar con el acceso al servidor MCP, puedes usar el codelab Getting Started with Google MCP Servers y modificar los comandos gcloud add-iam-policy-binding. Y Más Además de hacer cumplir un control preciso al usar roles predefinidos, las condiciones de IAM te permiten crear la gestión del acceso en función del momento de la solicitud. Por ejemplo, la siguiente expresión permite el acceso solo durante la hora del día en días laborables: code_block = 9 &&\\r\nrequest.time.getHours(‘Europe/Berlin’) <= 17 &&\\r\nrequest.time.getDayOfWeek(‘Europe/Berlin’) >= 1 &&\\r\nrequest.time.getDayOfWeek(‘Europe/Berlin’) <= 5), (’language’, ‘’), (‘caption’, )])]> La expresión limita el acceso desde las 9 de la mañana hasta las 5 de la tarde según la zona horaria de Europa/Berlín de lunes a viernes (los días de la semana tienen un rango de 0 a 6, comenzando con domingo). Las condiciones de IAM permiten controlar la identidad del actor utilizando atributos del principal. Sin embargo, esto puede fácilmente convertirse en un anti-patrón. La práctica recomendada es controlar la identidad de los actores que están autorizados a usar la política a través de la lista de los principales de la política de IAM, en lugar de usar las condiciones. Conclusión y más recursos Si bien las condiciones de IAM te dan un control preciso sobre las políticas de permitir, puedes llevar tu estrategia de defensa en profundidad aún más lejos con las políticas de denegar. Con las políticas de denegar, puedes otorgar acceso utilizando los roles de IAM predefinidos y eliminar los permisos excesivos de un rol para hacer cumplir el PoLP. Para obtener más información sobre las políticas de denegar, consulta los siguientes recursos: Identifica los permisos que admiten las políticas de denegar. Obtén el formato de los identificadores de los principales en las políticas de denegar. Averigua cómo solucionar problemas de acceso con las políticas de denegar. Aprende a controlar el acceso a los principales. Lee el artículo del blog sobre Construir defensa en profundidad. Puedes usar Google Skills para obtener experiencia práctica con las políticas de IAM.