Puedes otorgar acceso a los recursos de Google Cloud mediante las políticas de permisos, también conocidas como políticas de Identity and Access Management (IAM), que se adjuntan a los recursos. Puedes adjuntar solo una política de permiso a cada recurso. La política de permisos controla el acceso al recurso, así como a todos los elementos subordinados de ese recurso que heredan la política.
En esta página, se muestran las políticas de permisos en formato JSON. También puedes usar Google Cloud CLI para recuperar políticas de permisos en formato YAML.
Estructura de políticas
Una política de permisos es un conjunto de vinculaciones de roles y metadatos. Una vinculación de rol especifica qué acceso se debe otorgar a un recurso. Asocia, o vincula a una o más principales con un solo rol de IAM y cualquier condición específica del contexto que cambie cómo y cuándo se otorga el rol. Los metadatos incluyen información adicional sobre la política de permisos, como ETag y versión para facilitar la administración de políticas.
Cada vinculación de función puede incluir los siguientes campos:
- Una o más principales, también conocidas como miembros o identidades. Existen varios tipos de principales, incluidos usuarios individuales, grupos de usuarios y cuentas de servicio. Para obtener una lista completa de los tipos de principales compatibles, consulta Identificadores de principal.
- Un rol, que es una colección de permisos con nombre que proporciona la capacidad de realizar acciones en los recursos de Google Cloud.
Una condición es una expresión lógica opcional que restringe aún más la vinculación de función según los atributos de la solicitud, como su origen, el recurso de destino. Por lo general, las condiciones se usan para controlar si se otorga el acceso en función del contexto de una solicitud.
Si una vinculación de función también contiene una condición, se la denomina una vinculación de función condicional.
Algunos servicios de Google Cloud no aceptan condiciones en las políticas de permisos. Para obtener una lista de los servicios y tipos de recursos que aceptan condiciones, consulta Tipos de recursos que aceptan vinculaciones de roles condicionales.
Los cambios en el acceso de una principal tienen coherencia eventual. Esto significa que los cambios de acceso tardan un tiempo en propagarse a través del sistema. Para saber cuánto tiempo tardan, en promedio, en propagarse los cambios de acceso, consulta Propagación de cambios de acceso.
Límites de todas las principales
Cada política de permisos puede contener hasta 1,500 principales.
Para los fines de este límite, IAM cuenta todas las apariciones de cada principal en las vinculaciones de roles de la política de permiso, así como los principales que la política de permisos exime a los registros de auditoría de acceso a los datos. No anula el duplicado de las principales que aparecen en más de una vinculación de roles. Por ejemplo, si una política de permisos solo contiene vinculaciones de roles para el user:my-user@example.com principal, y este principal aparece en 50 vinculaciones de roles, puedes agregar otras 1,450 principales a las vinculaciones de roles en la política de permisos.
Además, para los fines de este límite, cada aparición de un dominio o Grupo de Google se cuenta como un único principal, sin importar la cantidad de miembros individuales del dominio o grupo.
Si usas las Condiciones de IAM o si otorgas roles a muchas principales con identificadores más largos de lo normal, IAM podría permitir menos principales en la política de permisos.
Límites de grupos y dominios
Hasta 250 de las principales en una política de permisos pueden ser Grupos de Google, dominios de Cloud Identity o cuentas de Google Workspace.
Para los fines de este límite, los dominios de Cloud Identity, las cuentas de Google Workspace y los Grupos de Google se cuentan de la siguiente manera:
- Para los Grupos de Google, cada grupo único se cuenta solo una vez, sin importar cuántas veces aparezca en la política de permisos. Esto es diferente de la forma en que se cuentan los grupos para el límite de la cantidad total de principales en una política de permisos. Para ese límite, cada aparición de un grupo se considera en el límite.
- Para los dominios de Cloud Identity o las cuentas de Google Workspace, IAM cuenta todas las apariciones de cada dominio o cuenta en las vinculaciones de roles de la política de permisos. No anula el duplicado de los dominios o las cuentas que aparecen en más de una vinculación de roles.
Por ejemplo, si tu política de permisos contiene solo un grupo, group:my-group@example.com y el grupo aparece en la política de permisos 10 veces, puedes agregar 249 dominios, cuentas de Google Workspace o grupos únicos de Cloud Identity más antes de alcanzar el límite.
Como alternativa, si tu política de permisos contiene solo un dominio, domain:example.com, y el dominio aparece en la política de permisos 10 veces, puedes agregar otros 240 dominios de Cloud Identity, cuentas de Google Workspace o grupos únicos antes de alcanzar el límite.
Metadatos de políticas
Los metadatos de una política de permisos incluyen los siguientes campos:
- Un campo
etag, que se usa para el control de simultaneidad, y garantiza que las políticas de permisos se actualicen de forma coherente. Para obtener más información, consulta cómo usar ETags en una política en esta página. - Un campo
version, que especifica la versión de esquema para una política de permisos determinada. Para obtener más información, consulta Versiones de políticas en esta página.
Para organizaciones, carpetas, proyectos y cuentas de facturación, la política de permisos también puede contener un campo auditConfig que especifica los tipos de actividad que generan registros de auditoría para cada servicio. Si quieres obtener información sobre cómo configurar esta parte de una política de permisos, consulta Configura registros de auditoría de acceso a los datos.
Usa ETags en una política
Cuando varios sistemas intentan escribir en la misma política de permisos al mismo tiempo, existe el riesgo de que esos sistemas reemplacen sus cambios entre sí. Este riesgo existe porque las políticas de permisos se actualizan a través del patrón de lectura, modificación y escritura, que implica varias operaciones:
- Leer la política de permisos existente
- Modificar la política de permisos
- Escribir toda la política de permisos
Si el sistema A lee una política de permisos y el sistema B escribe de inmediato una versión actualizada de esa política de permisos, el sistema A no tendrá conocimiento de los cambios del sistema B. Cuando el sistema A escriba sus propios cambios en la política de permisos, podrían perderse los cambios del sistema B.
Para evitar este problema, Identity and Access Management (IAM) admite el control de simultaneidad mediante el uso de un campo etag en la política de permisos. Cada política de permisos contiene un campo etag, y el valor de este campo cambia cada vez que se actualiza una política de permisos. Si una política de permisos contiene un campo etag, pero no tiene vinculaciones de roles, la política de permisos no otorga roles de IAM.
El campo etag contiene un valor, como BwUjMhCsNvY=. Cuando actualices la política de permisos, asegúrate de incluir el campo etag en la política de permisos actualizada.
Si se modificó la política de permisos desde que la recuperaste, el valor etag no coincidirá y la actualización fallará. Para la API de REST, recibirás el código de estado HTTP 409 Conflict y el cuerpo de la respuesta será similar al siguiente:
{
"error": {
"code": 409,
"message": "There were concurrent policy changes. Please retry the whole read-modify-write with exponential backoff.",
"status": "ABORTED"
}
}
Si recibes este error, vuelve a intentar toda la serie de operaciones: lee la política de permisos de nuevo, modifícala según sea necesario y escribe la política de permisos actualizada. Debes realizar reintentos de forma automática, con retirada exponencial, en cualquier herramienta que uses para administrar las políticas de permisos.
Ejemplo: Política simple
Considera la siguiente política de permisos que vincula a una principal con un rol:
{
"bindings": [
{
"members": [
"user:jie@example.com"
],
"role": "roles/owner"
}
],
"etag": "BwUjMhCsNvY=",
"version": 1
}
En el ejemplo anterior, a Jie se le otorga el rol básico de propietario sin ninguna condición. Este rol le otorga a Jie acceso casi ilimitado.
Ejemplo: Política con múltiples vinculaciones de función
Considera la siguiente política de permisos que contiene más de una vinculación de rol. Cada vinculación otorga una función diferente:
{
"bindings": [
{
"members": [
"user:jie@example.com"
],
"role": "roles/resourcemanager.organizationAdmin"
},
{
"members": [
"user:raha@example.com",
"user:jie@example.com"
],
"role": "roles/resourcemanager.projectCreator"
}
],
"etag": "BwUjMhCsNvY=",
"version": 1
}
En el ejemplo anterior, a Jie se le otorga el rol predefinido de administrador de la organización (roles/resourcemanager.organizationAdmin) en la primera vinculación de roles. Esta función contiene permisos para organizaciones, carpetas y operaciones de proyectos limitadas. En la segunda vinculación de roles, a Jie y Raha se les otorga la capacidad de crear proyectos a través del rol de creador de proyectos (roles/resourcemanager.projectCreator). En conjunto, estas vinculaciones de roles otorgan acceso detallado a Jie y Raha, y Jie posee más acceso que Raha.
Ejemplo: Política con vinculación de función condicional
Considera la siguiente política de permisos, que vincula a las principales con un rol predefinido y usa una expresión de condición para restringir la vinculación de rol:
{
"bindings": [
{
"members": [
"group:prod-dev@example.com",
"serviceAccount:prod-dev-example@appspot.gserviceaccount.com"
],
"role": "roles/appengine.deployer",
"condition": {
"title": "Expires_July_1_2022",
"description": "Expires on July 1, 2022",
"expression":
"request.time < timestamp('2022-07-01T00:00:00.000Z')"
}
}
],
"etag": "BwWKmjvelug=",
"version": 3
}En este ejemplo, el campo version se establece en 3, debido a que la política de permisos contiene una expresión de condición. La vinculación de rol de la política de permisos es condicional; otorga el rol al grupo prod-dev y a la cuenta de servicio prod-dev-example@appspot.gserviceaccount.com, pero solo hasta el 1 de julio de 2022.
Para obtener detalles sobre las funciones que admite cada versión de la política de permisos, consulta la sección Versiones de políticas de esta página.
Ejemplo: Política con vinculaciones de funciones condicionales y no condicionales
Considera la siguiente política de permisos, que contiene vinculaciones de roles condicionales y no condicionales para el mismo rol:
{
"bindings": [
{
"members": [
"serviceAccount:prod-dev-example@appspot.gserviceaccount.com"
],
"role": "roles/appengine.deployer"
},
{
"members": [
"group:prod-dev@example.com",
"serviceAccount:prod-dev-example@appspot.gserviceaccount.com"
],
"role": "roles/appengine.deployer",
"condition": {
"title": "Expires_July_1_2022",
"description": "Expires on July 1, 2022",
"expression":
"request.time < timestamp('2022-07-01T00:00:00.000Z')"
}
}
],
"etag": "BwWKmjvelug=",
"version": 3
}En este ejemplo, la cuenta de servicio serviceAccount:prod-dev-example@appspot.gserviceaccount.com se incluye en dos vinculaciones de roles para el mismo rol. La primera vinculación de roles no tiene una condición. La segunda vinculación de función tiene una condición que solo otorga
la función hasta el 1 de julio de 2022.
En efecto, esta política de permisos siempre otorga el rol a la cuenta de servicio. En IAM, las vinculaciones de funciones condicionales no anulan las vinculaciones de funciones sin condiciones. Si un principal está vinculado a una función y la vinculación de función no tiene una condición, la principal siempre tiene esa función. Agregar la principal a una vinculación de función condicional para el mismo rol no tiene efecto.
Por el contrario, el grupo prod-dev solo se incluye en la vinculación de función
condicional. Por lo tanto, tiene el rol solo antes del 1 de julio de 2022.
Ejemplo: Política que vincula una función a un principal borrado
Considera la siguiente política de permisos. Esta política de permisos vincula un rol a una cuenta de servicio, serviceAccount:my-service-account@my-project.iam.gserviceaccount.com, que se borró. Como resultado, el identificador de la cuenta de servicio ahora tiene un prefijo deleted::
{
"bindings": [
{
"members": [
"deleted:serviceAccount:my-service-account@my-project.iam.gserviceaccount.com?uid=123456789012345678901"
],
"role": "roles/owner"
}
],
"etag": "BwUjMhCsNvY=",
"version": 1
}
Si creas una cuenta de servicio nueva con el mismo nombre, las vinculaciones de roles de la política de permisos para la cuenta de servicio borrada no se aplican a la cuenta de servicio nueva. Este comportamiento se aplica a todos los tipos de principales eliminados.
Este comportamiento evita que los principales nuevos hereden roles que se otorgaron a principales borrados. Si deseas otorgar roles al principal nuevo, agrégalo a las vinculaciones de roles de la política de permisos, como se muestra en Políticas con principales borradas en esta página.
Todos los principales borrados tienen el prefijo deleted:. Algunos tipos de principales borrados, como las cuentas de servicio, también tienen el sufijo ?uid=numeric-id, en el que numeric-id es el ID numérico único del principal borrado.
En este ejemplo, en lugar de serviceAccount:serviceAccount:my-service-account@my-project.iam.gserviceaccount.com, la política de permisos muestra el identificador deleted:serviceAccount:my-service-account@my-project.iam.gserviceaccount.com?uid=123456789012345678901.
Políticas predeterminadas
Todos los recursos que aceptan políticas de permisos se crean con políticas de permisos predeterminadas. Las políticas de permisos predeterminadas de la mayoría de los recursos están vacías.
Sin embargo, las políticas de permisos predeterminadas de algunos recursos contienen automáticamente ciertas vinculaciones de roles. Por ejemplo, cuando creas un proyecto nuevo, la política de permisos para el proyecto tiene automáticamente una vinculación de rol que te otorga el rol Owner (roles/owner) en el proyecto.
El sistema crea estas vinculaciones de función, por lo que el usuario no necesita los permisos getIamPolicy ni setIamPolicy en el recurso para que se creen las vinculaciones de función.
Para saber si se crea un recurso con una política de permisos, consulta la documentación del recurso.
La herencia de políticas y la jerarquía de recursos
Los recursos deGoogle Cloud están organizados de forma jerárquica, en la que el nodo de organización es el nodo raíz en la jerarquía, luego, de manera opcional, las carpetas y, luego, los proyectos. La mayoría de los demás recursos se crean y administran en un proyecto. Cada recurso tiene solo un elemento superior, excepto la organización. La organización, como el nodo raíz en la jerarquía, no tiene un superior. Consulta Jerarquía de recursos para obtener más información.
Es importante tener en cuenta la jerarquía de recursos cuando configuras la política de permisos. A la hora de establecer una política de permisos en un nivel superior en la jerarquía, por ejemplo, a nivel de organización, carpeta o proyecto, el permiso de acceso otorgado incluye el nivel de recursos al que está vinculada esta política de permisos y todos los recursos bajo ese nivel. Por ejemplo, una política de permisos establecida a nivel de la organización se aplica a la organización y a todos los recursos de la organización. Del mismo modo, una política de permisos establecida a nivel de proyecto se aplica al proyecto y a todos los recursos del proyecto.
Herencia de políticas es el término que describe cómo se aplican las políticas de permisos a los recursos por debajo de su nivel en la jerarquía de recursos. Política vigente es el término que describe cómo se heredan todas las políticas de permisos superiores en la jerarquía de recursos para un recurso. Es la unión de los siguientes elementos:
- La política de permisos establecida en el recurso
- Las políticas de permisos establecidas en todos los niveles de recursos principales del recurso en la jerarquía
Cada vinculación de rol nueva (heredada de recursos superiores) que afecta la política de permisos vigente del recurso se evalúa de forma independiente. Se concede una solicitud de acceso específica al recurso si alguna de las vinculaciones de función de nivel superior otorga acceso a la solicitud.
Si se ingresa una nueva vinculación de rol en cualquier nivel de la política de permisos heredada de un recurso, el alcance de la concesión de acceso aumenta.
Ejemplo: Herencia de políticas
Para comprender la herencia de políticas de permisos, considera una situación en la que otorgas a un usuario, Raha, dos roles de IAM diferentes en dos niveles diferentes en la jerarquía de recursos.
Para otorgar a Raha un rol a nivel de la organización, establece la siguiente política de permisos en tu organización:
{
"bindings": [
{
"members": [
"user:raha@example.com"
],
"role": "roles/storage.objectViewer"
}
],
"etag": "BwUjMhCsNvY=",
"version": 1
}
Esta política de permisos otorga a Raha el rol Storage Object Viewer (roles/storage.objectViewer), que contiene los permisos get y list para proyectos y objetos de Cloud Storage. Debido a que configuras la política de permisos en tu organización, Raha puede usar estos permisos para todos los proyectos y todos los objetos de Cloud Storage de tu organización.
Para otorgar a Raha un rol a nivel de proyecto, establece la siguiente política de permisos en el proyecto myproject-123:
{
"bindings": [
{
"members": [
"user:raha@example.com"
],
"role": "roles/storage.objectCreator"
}
],
"etag": "BwUjMhCsNvY=",
"version": 1
}
Esta política de permisos otorga a Raha el rol Storage Object Creator (roles/storage.objectCreator), que le permite crear objetos de Cloud Storage. Debido a que configuras la política de permisos en myproject-123, Raha puede crear objetos de Cloud Storage solo en myproject-123.
Ahora que hay dos vinculaciones de roles que otorgan a Raha acceso a los objetos de Cloud Storage de destino en myproject-123, se aplican las siguientes políticas de permisos:
- Una política de permisos a nivel de organización permite enumerar y obtener todos los objetos de Cloud Storage de esta organización.
- Una política de permisos a nivel de proyecto, para el proyecto
myproject-123, otorga la capacidad de crear objetos dentro de ese proyecto.
En la siguiente tabla, se resume la política vigente de Raha:
| Permisos del rol de Visualizador de objetos de Storage en la organización | Permisos del rol de creador de objetos de almacenamiento en "myproject-123" | Permisos efectivos de Raha en "myproject-123" |
|---|---|---|
| resourcemanager.projects.get resourcemanager.projects.list storage.objects.get storage.objects.list |
resourcemanager.projects.get resourcemanager.projects.list storage.objects.create |
resourcemanager.projects.get resourcemanager.projects.list storage.objects.get storage.objects.list storage.objects.create |
Versiones de políticas
Con el tiempo, IAM podría agregar nuevas funciones que sumen o cambien campos de forma significativa en el esquema de políticas de permisos. Para evitar que se rompan las integraciones existentes que dependen de la coherencia en la estructura de políticas de permisos, estos cambios se ingresan en las nuevas versiones del esquema de políticas de permisos.
Si te integras en IAM por primera vez, te recomendamos usar la versión más reciente del esquema de políticas de permisos disponible en ese momento. En la siguiente sección, se analizan las diferentes versiones disponibles y cómo usar cada una. También se describe cómo especificar una versión de política y se analizan algunos casos de solución de problemas.
Cada política de permisos existente especifica un campo version como parte de los metadatos de la política de permisos. Considera la parte destacada del siguiente ejemplo:
{ "bindings": [ { "members": [ "user:jie@example.com" ], "role": "roles/owner" } ], "etag": "BwUjMhCsNvY=", "version": 1 }
Este campo especifica la versión del esquema de sintaxis de la política de permisos. Cada versión de la política de permisos contiene un esquema de sintaxis específico que pueden usar las vinculaciones de roles. La versión más reciente puede contener vinculaciones de roles con el esquema de sintaxis más reciente que no es compatible con versiones anteriores. Este campo no está diseñado para usarse con otros fines que no sean controlar el esquema de sintaxis de la política de permisos.
Versiones válidas de políticas
Las políticas de permisos pueden usar las siguientes versiones de políticas de permisos:
| Versión | Descripción |
|---|---|
1 |
Es la primera versión del esquema de sintaxis de IAM para las políticas. Admite la vinculación de una función con una o más principales. No admite las vinculaciones de funciones condicionales. |
2 |
Está reservada para uso interno. |
3 |
Presenta el campo condition en la vinculación de roles, que restringe la vinculación de roles mediante reglas basadas en los atributos y en el contexto. Para obtener más información, consulta la Descripción general de las Condiciones de IAM.
|
Especifica una versión de política cuando obtienes una política
Para la API de REST y las bibliotecas cliente, cuando obtengas una política de permisos, te recomendamos que especifiques una versión de la política de permisos en la solicitud. Cuando una solicitud especifica una versión de la política de permisos, IAM supone que el emisor conoce sus características y puede manejarlas de forma adecuada.
Si en la solicitud no se especifica una versión de la política de permisos, IAM supone que el emisor quiere una política de permisos de versión 1.
Cuando obtienes una política de permisos, IAM verifica la versión de la política de permisos en la solicitud o la versión predeterminada si la solicitud no especificó una. IAM también verifica la política de permisos en busca de campos que no son compatibles con una política de permisos de versión 1. Usa esta información para decidir qué tipo de respuesta debe enviar:
- Si la política de permisos no contiene ninguna condición, IAM siempre mostrará una política de permisos de versión
1, sin importar el número de versión en la solicitud. - Si la política de permisos contiene condiciones y el emisor solicitó una política de permisos de versión
3, IAM muestra una política de permisos de versión3que incluye las condiciones. Para ver un ejemplo, consulta la Situación 1 que se describe en esta página. Si la política de permisos contiene condiciones y el emisor solicitó una política de permisos de versión
1o no especificó una versión, IAM muestra una política de permisos de versión1.En el caso de las vinculaciones de funciones que incluyen una condición, IAM agrega la string
_withcond_al nombre de la función, seguida de un valor de hash; por ejemplo,roles/iam.serviceAccountAdmin_withcond_2b17cc25d2cd9e2c54d8. La condición en sí no está presente. Para ver un ejemplo, consulta la situación 2 que se describe en esta página.
Situación 1: Versión de la política que es totalmente compatible con las Condiciones de IAM
Supongamos que llamas al siguiente método de la API de REST para obtener la política de permisos de un proyecto:
POST https://cloudresourcemanager.googleapis.com/v1/projects/project-id:getIamPolicy
El cuerpo de la solicitud contiene el siguiente texto:
{
"options": {
"requestedPolicyVersion": 3
}
}
La respuesta contiene la política de permisos del proyecto. Si la política de permisos contiene al menos una vinculación de rol condicional, su campo version se establece en 3:
{
"bindings": [
{
"members": [
"user:tal@example.com"
],
"role": "roles/iam.securityReviewer",
"condition": {
"title": "Expires_July_1_2022",
"description": "Expires on July 1, 2022",
"expression": "request.time < timestamp('2022-07-01T00:00:00.000Z')"
}
}
],
"etag": "BwWKmjvelug=",
"version": 3
}Si la política de permisos no contiene vinculaciones de roles condicionales, su campo version se establece en 1, a pesar de que en la solicitud se haya especificado la versión 3:
{
"bindings": [
{
"members": [
"user:tal@example.com"
],
"role": "roles/iam.securityReviewer",
}
],
"etag": "BwWKmjvelug=",
"version": 1
}Situación 2: Versión de la política que tiene compatibilidad limitada con las Condiciones de IAM
Supongamos que llamas al siguiente método de la API de REST para obtener la política de permisos de un proyecto:
POST https://cloudresourcemanager.googleapis.com/v1/projects/project-id:getIamPolicy
El cuerpo de la solicitud está vacío. No se especifica un número de versión. Como resultado, IAM usa la versión predeterminada de la política de permisos, 1.
La política de permisos contiene una vinculación de rol condicional. Debido a que la versión de la política de permisos es 1, la condición no aparece en la respuesta. Para indicar que la vinculación de rol usa una condición, IAM agrega la string _withcond_ al nombre del rol, seguida de un valor de hash:
{
"bindings": [
{
"members": [
"user:tal@example.com"
],
"role": "roles/iam.securityReviewer_withcond_58e135cabb940ad9346c"
}
],
"etag": "BwWKmjvelug=",
"version": 1
}Especifica una versión de la política cuando configuras una política
Cuando configures una política de permisos, te recomendamos que especifiques una versión de la política de permisos en la solicitud. Cuando una solicitud especifica una versión de la política de permisos, IAM supone que el emisor conoce sus características y puede manejarlas de forma adecuada.
Si la solicitud no especifica una versión de la política de permisos, IAM solo aceptará los campos que pueden aparecer en una política de permisos de versión 1. Como práctica recomendada, no cambies las vinculaciones de roles condicionales en una política de permisos de versión 1. Debido a que la política de permisos no muestra la condición de cada vinculación de rol, no sabrás en qué momento o en qué ubicación se otorga la vinculación de rol.
En su lugar, obtén la representación de la versión 3 de la política de permisos, que muestra la condición de cada vinculación de rol, y usa esa representación para actualizar las vinculaciones de roles.
Situación: Versiones de políticas en solicitudes y respuestas
Supongamos que usas la API de REST para obtener una política de permisos y especificas la versión 3 en la solicitud. La respuesta contendrá la siguiente política de permisos, que usa la versión 3:
{
"bindings": [
{
"members": [
"user:raha@example.com"
],
"role": "roles/storage.admin",
"condition": {
"title": "Weekday_access",
"description": "Monday thru Friday access only in America/Chicago",
"expression": "request.time.getDayOfWeek('America/Chicago') >= 1 && request.time.getDayOfWeek('America/Chicago') <= 5"
}
}
],
"etag": "BwUjMhCsNvY=",
"version": 3
}Decides que Raha debe tener el rol de administrador de almacenamiento (roles/storage.admin) durante toda la semana, no solo durante los días de semana. Quitas la condición de la vinculación de rol y envías una solicitud a la API de REST para configurar la política de permisos. Una vez más, debes especificar la versión 3 en la solicitud:
{
"bindings": [
{
"members": [
"user:raha@example.com"
],
"role": "roles/storage.admin"
}
],
"etag": "BwUjMhCsNvY=",
"version": 3
}
La respuesta contiene la política de permisos actualizada:
{
"bindings": [
{
"members": [
"user:raha@example.com"
],
"role": "roles/storage.admin"
}
],
"etag": "BwWd8I+ZUAQ=",
"version": 1
}La política de permisos en la respuesta usa la versión 1, aunque en la solicitud se haya especificado la versión 3, debido a que la política de permisos solo usa campos que sean compatibles con una política de permisos de versión 1.
Políticas con principales borradas
Si una vinculación de rol de una política de permisos incluye un principal borrada y agregas una vinculación de rol para una principal nueva con el mismo nombre, la vinculación de rol siempre se aplica a la principal nueva.
Por ejemplo, considera esta política de permisos, que incluye una vinculación de rol para una cuenta de servicio borrada, my-service-account@project-id.iam.gserviceaccount.com. Como resultado, el identificador de cada cuenta de servicio tiene un prefijo deleted::
{
"bindings": [
{
"members": [
"deleted:serviceAccount:my-service-account@project-id.iam.gserviceaccount.com?uid=123456789012345678901"
],
"role": "roles/owner"
}
],
"etag": "BwUjMhCsNvY=",
"version": 1
}
Supongamos que creas una cuenta de servicio nueva que también se llama my-service-account@project-id.iam.gserviceaccount.com y deseas otorgarle el rol de creador de proyectos (roles/resourcemanager.projectCreator). Para otorgar el rol a la cuenta de servicio nueva, actualiza la política de permisos como se muestra en este ejemplo:
{ "bindings": [ { "members": [ "deleted:serviceAccount:my-service-account@project-id.iam.gserviceaccount.com?uid=123456789012345678901" ], "role": "roles/owner" }, { "members": [ "serviceAccount:my-service-account@project-id.iam.gserviceaccount.com" ], "role": "roles/resourcemanager.projectCreator" } ], "etag": "BwUjMhCsNvY=", "version": 1 }
Para facilitar la auditoría de tus políticas de permisos de IAM, también puedes quitar al usuario borrado de la vinculación al rol Owner:
{ "bindings": [ { "members": [ "deleted:serviceAccount:my-service-account@project-id.iam.gserviceaccount.com?uid=123456789012345678901" ], "role": "roles/owner" }, { "members": [ "user:donald@example.com" ], "role": "roles/resourcemanager.projectCreator" } ], "etag": "BwUjMhCsNvY=", "version": 1 }
Prácticas recomendadas para políticas
Las siguientes prácticas recomendadas se aplican a organizaciones con muchos usuarios de Google Cloud:
Cuando administres varios principales con las mismas configuraciones de acceso, usa grupos. Coloca cada principal individual en el grupo y otorga los roles previstos al grupo, en lugar de otorgarlos a los principales de las cuentas de usuario individuales.
Roles otorgados a nivel de la organización: Considera de forma cuidadosa qué principales tienen roles a nivel de la organización. Para la mayoría de las organizaciones, solo algunos equipos específicos (como los equipos de seguridad y de red) deben tener acceso en este nivel de la jerarquía de recursos.
Roles otorgados en los niveles de carpeta: Refleja la estructura de operaciones de tu organización mediante niveles de carpetas. Cada carpeta se puede configurar con diferentes conjuntos de concesiones de acceso que estén alineados con las necesidades empresariales y operativas. Por ejemplo, una carpeta superior puede reflejar un departamento, una de sus carpetas secundarias puede reflejar el acceso a recursos y las operaciones de un grupo, y otra carpeta secundaria puede reflejar un equipo pequeño. Ambas carpetas pueden contener proyectos para las necesidades operativas de su equipo. Usar las carpetas de esta manera puede garantizar una separación de acceso adecuada, mientras se respetan las políticas de permisos heredadas de las carpetas superiores y la organización. Esta práctica requiere menos mantenimiento de las políticas de permisos cuando se crean y administran recursos de Google Cloud .
Roles otorgados a nivel del proyecto: Otorga vinculaciones de roles a nivel del proyecto cuando sea necesario para seguir el principio de privilegio mínimo. Por ejemplo, si una principal necesita acceso a 3 de los 10 proyectos en una carpeta, debes otorgar acceso a cada uno de los 3 proyectos de forma individual; por el contrario, si otorgaste una función en la carpeta, el principal obtendrá acceso que no necesita a otros 7 proyectos.
Como alternativa, puedes usar las condiciones de IAM para otorgar funciones a nivel de organización o de carpeta, pero solo para un subconjunto de carpetas o proyectos.
Otorga acceso solo a las principales dentro de tu dominio: Para mejorar la seguridad de tu organización, no otorgues roles a principales fuera de tu dominio. Para aplicar esta práctica recomendada, puedes aplicar la restricción de la política de la organización
iam.allowedPolicyMemberDomains.
¿Qué sigue?
- Aprende cómo solucionar problemas de políticas de permisos que contienen la string
withconden nombres de roles. - Descubre cómo administrar las vinculaciones de roles en una política de permisos.
- Obtén una descripción general de las Condiciones de IAM, que usan políticas de permisos de versión
3. - Explora las Herramientas de inteligencia de políticas, que te ayudan a comprender y administrar las políticas de permisos para mejorar de forma proactiva la configuración de seguridad.
- Usa la API de Cloud Asset para buscar políticas de permisos.
- Usa la API de Cloud Asset para ver las políticas de permisos efectivas.