Políticas de denegación

Las políticas de denegación de Identity and Access Management (IAM) te permiten configurar protecciones de acceso a los recursos de Google Cloud. Con ellas, puedes definir reglas de denegación que evitan que determinadas principales usen ciertos permisos, sin importar las roles que se les otorguen.

En esta página, se proporciona una descripción general de las políticas y las reglas de denegación. Para obtener información sobre cómo crear y actualizar políticas de denegación, consulta Acceso de denegación a los recursos.

Cómo funcionan las políticas de denegación

Las políticas de denegación están compuestas por reglas de denegación. Cada regla de denegación especifica lo siguiente:

• Un conjunto de principales que tienen permisos denegados
• Los permisos que los principales pueden negar o no pueden usar
• La condición que debe ser verdadera para que se rechace el permiso (opcional)

Cuando a una principal se le niega un permiso, no puede hacer nada que requiera ese permiso, sin importar las funciones de IAM que se le hayan otorgado. Esto se debe a que IAM siempre verifica las políticas de denegación relevantes antes de verificar las políticas de permiso relevantes. Para obtener más detalles, consulta Evaluación de políticas.

Para especificar dónde deseas que se aplique una política de denegación, debes adjuntarla a un proyecto, una organización o una carpeta. Cuando se adjunta una política de denegación a uno de estos recursos, las principales de la política no pueden usar los permisos especificados para acceder al recurso ni a ninguno de los subordinados del recurso. Para obtener más información sobre dónde puedes adjuntar una política de denegación, consulta Punto de conexión en esta página.

Puedes adjuntar varias políticas de denegación a un solo recurso. Esto te permite crear políticas de denegación separadas para diferentes tipos de reglas de denegación. Por ejemplo, puedes colocar reglas de denegación relacionadas con el cumplimiento en una política y, luego, usar otra para otras reglas. Cada política de denegación se evalúa de forma independiente de las demás políticas de denegación.

Cada recurso puede tener hasta 500 políticas de denegación. En conjunto, estas políticas de denegación pueden contener un total de 500 reglas de denegación.

Nota: 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.

Punto de conexión

Cada política de denegación se adjunta a una organización, carpeta o proyecto. Cuando se adjuntan a uno de estos recursos, todos los recursos de nivel inferior de ese proyecto, carpeta u organización heredan las políticas de denegación. Para trabajar con políticas de denegación, necesitas un identificador del recurso al que se adjunta la política de denegación, que se denomina punto de conexión. Este identificador usa uno de los siguientes formatos:

Formato de punto de conexión
Organización	cloudresourcemanager.googleapis.com/organizations/ORG_ID Reemplaza ORG_ID por el ID numérico de la organización. Para la API de REST, codifica todo el valor en URL. Ejemplo de la CLI de gcloud: cloudresourcemanager.googleapis.com/organizations/123456789012 Ejemplo de la API de REST: cloudresourcemanager.googleapis.com%2Forganizations%2F123456789012
Carpeta	cloudresourcemanager.googleapis.com/folders/FOLDER_ID Reemplaza FOLDER_ID por el ID de la carpeta numérica. Para la API de REST, codifica todo el valor en URL. Ejemplo de la CLI de gcloud: cloudresourcemanager.googleapis.com/folders/987654321098 Ejemplo de la API de REST: cloudresourcemanager.googleapis.com%2Ffolders%2F987654321098
Proyecto	cloudresourcemanager.googleapis.com/projects/PROJECT_ID Reemplaza PROJECT_ID por el ID del proyecto alfanumérico o numérico. Para la API de REST, codifica todo el valor en URL. Ejemplo de la CLI de gcloud: cloudresourcemanager.googleapis.com/projects/my-project Ejemplo de la API de REST: cloudresourcemanager.googleapis.com%2Fprojects%2Fmy-project

Herencia de políticas de denegación

Las políticas de denegación, al igual que las políticas de permiso, se heredan a través de la jerarquía de recursos. Cuando adjuntas una política de denegación a un proyecto, una organización o una carpeta, la política también se aplicará a todos los recursos dentro de ese proyecto, organización o carpeta.

Por ejemplo, si una política de denegación para una organización indica que una principal no puede usar un permiso específico, la principal no puede usar ese permiso en ningún recurso dentro de la organización. Esta regla se aplica incluso si las carpetas y proyectos dentro de esa organización tienen políticas de denegación más permisivas.

Del mismo modo, si una política de denegación para un proyecto indica que una principal no puede usar un permiso específico, la principal no puede usar ese permiso en ningún recurso dentro del proyecto. Esta regla se aplica incluso si la organización y las carpetas superiores tienen políticas de denegación más permisivas.

Condiciones de denegación

Las condiciones de denegación especifican las condiciones que se deben cumplir para que se aplique una regla de denegación. Si la condición se evalúa como true o no se puede evaluar, se aplica la regla de denegación, y las principales no pueden usar los permisos especificados. Si la condición se evalúa como false, la regla de denegación no se aplica, y las principales pueden usar los permisos especificados si los tienen.

Las condiciones de denegación tienen la misma estructura que las condiciones de IAM. Sin embargo, las condiciones de denegación solo reconocen las funciones de etiqueta de recurso.

Para obtener información sobre cómo escribir condiciones, consulta Descripción general de las condiciones de IAM.

Grupos de permisos

Algunos servicios te permiten denegar grupos de permisos. Los grupos de permisos son conjuntos de permisos que coinciden con un patrón especificado. Puedes usar un grupo de permisos para denegar conjuntos de permisos relacionados, por ejemplo, puedes denegar todos los permisos de un solo servicio o recurso.

Los grupos de permisos compatibles se enumeran en Permisos compatibles con las políticas de denegación. Los identificadores de los grupos de permisos compatibles reemplazan una o más secciones de un nombre de permiso por un carácter comodín (*). Los permisos que incluye cada grupo dependen de la posición del comodín:

• SERVICE_FQDN/RESOURCE.*: Rechaza todos los permisos para el recurso especificado.
• SERVICE_FQDN/*.*: Rechaza todos los permisos para el servicio especificado.
• SERVICE_FQDN/*.VERB: Rechaza todos los permisos para un servicio que termina en el verbo especificado.

Los grupos de permisos incluyen todos los permisos actuales y futuros que coinciden con el patrón especificado. Por ejemplo, imagina que usas el grupo de permisos example.googleapis.com/exampleResource.* a fin de denegar a un usuario todos los permisos para el tipo de recurso exampleResource. Si example.googleapis.com agrega un permiso nuevo para el tipo de recurso exampleResource, como example.googleapis.com/exampleResource.newPermission, se le denegará automáticamente el permiso nuevo.

Solo puedes usar comodines en los grupos de permisos admitidos. No se admite el uso de comodines en otros nombres de permisos.

Estructura de una política de denegación

Una política de denegación es una colección de metadatos y reglas de denegación. Una regla de denegación asocia un conjunto de principales con un conjunto de permisos denegados a las principales o que no pueden usar. Cada regla también puede especificar una condición que determine cuándo se denegará el permiso.

Por ejemplo, la siguiente política de denegación impide que todas las principales borren proyectos, a menos que la principal sea miembro de [e-mail] o el proyecto que se borra tenga una etiqueta con el valor test.

{
  "name": "policies/cloudresourcemanager.googleapis.com%2Fprojects%2F253519172624/denypolicies/limit-project-deletion",
  "uid": "06ccd2eb-d2a5-5dd1-a746-eaf4c6g3f816",
  "kind": "DenyPolicy",
  "displayName": "Only project admins can delete projects.",
  "etag": "MTc1MTkzMjY0MjUyMTExODMxMDQ=",
  "createTime": "2021-09-07T23:15:35.258319Z",
  "updateTime": "2021-09-07T23:15:35.258319Z",
  "rules": [
    {
      "denyRule": {
        "deniedPrincipals": [
          "principalSet://goog/public:all"
        ],
        "exceptionPrincipals": [
          "principalSet://goog/group/[e-mail]"
        ],
        "deniedPermissions": [
          "cloudresourcemanager.googleapis.com/projects.delete",
          "cloudresourcemanager.googleapis.com/folders.*"
        ],
        "exceptionPermissions": [
          "cloudresourcemanager.googleapis.com/folders.list",
          "cloudresourcemanager.googelapis.com/folders.get"
        ],
        "denialCondition": {
          "title":  "Only for non-test projects",
          "expression": "!resource.matchTag('12345678/env', 'test')"
        }
      }
    }
  ]
}

En las siguientes secciones, se describen los campos en los metadatos de una política de denegación y las reglas de denegación.

Metadatos

Las políticas de denegación contienen los siguientes metadatos:

• name: Es el nombre de la política de denegación. Este nombre tiene el formato policies/ATTACHMENT_POINT/denypolicies/POLICY_ID, en el que ATTACHMENT_POINT es el proyecto, la carpeta o la organización a la que se adjunta la política de denegación y POLICY_ID es el ID alfanumérico de la política de denegación.
• uid: Es un ID único que Google asigna a la política de denegación.
• kind: Es el tipo de política. El kind de una política de denegación siempre es DenyPolicy.
• displayName: Opcional Es un nombre legible para la política de denegación.
• etag: Es un identificador para una versión de la política. Para evitar actualizaciones en conflicto, el valor etag debe coincidir con el valor almacenado en IAM. Si los valores etag no coinciden, la solicitud falla.
• createTime: Es el momento en que se creó la política de rechazo.
• updateTime: Es la última vez que se actualizó la política de rechazo.

Reglas de denegación

Cada regla de denegación puede tener los siguientes campos:

• deniedPrincipals: Son las principales a las que se les deniegan esos permisos. Puedes enumerar las principales individuales y los conjuntos de principales. Los tipos de principales individuales incluyen cuentas de usuario, cuentas de servicio e identidades individuales en un grupo de Workforce o Workload Identity. Los conjuntos de principales incluyen Grupos de Google, dominios de Cloud Identity, conjuntos de identidades del personal o de carga de trabajo, y todos los usuarios de Internet.

  Para obtener una lista de identificadores y tipos de principales válidos, consulta Identificadores de API principales de IAM v2.

• exceptionPrincipals: Opcional Son las principales que se excluyen de la regla de denegación. A estas principales no se les deniegan los permisos especificados incluso si aparecen en deniedPrincipals o forman parte de un grupo enumerado en deniedPrincipals.

  Puedes enumerar las principales individuales y los conjuntos de principales. Los tipos de principales individuales incluyen cuentas de usuario, identidades de servicio y cuentas individuales en un grupo de Workforce o Workload Identity. Los conjuntos de principales incluyen Grupos de Google, dominios de Cloud Identity, conjuntos de identidades del personal o de carga de trabajo, y todos los usuarios de Internet.

  Para obtener una lista de identificadores y tipos de principales válidos, consulta Identificadores de API principales de IAM v2.

• deniedPermissions: Son los permisos que las principales especificadas no pueden usar o denegar. Estos permisos usan el formato de permiso v2 de IAM, que usa nombres de dominio completamente calificados (FQDN) para identificar el servicio. El formato es SERVICE_FQDN/RESOURCE.ACTION. Las API de Google usan el dominio *.googleapis.com. Por ejemplo: iam.googleapis.com/roles.delete.

  Solo se pueden denegar algunos permisos. Para obtener una lista completa de los permisos que se pueden denegar, consulta Permisos compatibles con las políticas de denegación.

  En algunos casos, también puedes usar grupos de permisos para denegar conjuntos de permisos. Para obtener más información, consulta Grupos de permisos.

• exceptionPermissions: Opcional Una lista de permisos que pueden usar los principales especificados, incluso si esos permisos se incluyen en deniedPermissions. Por ejemplo, puedes usar este campo para hacer excepciones para permisos específicos en un grupo de permisos.

• denialConditions: Opcional Es una expresión lógica que afecta cuándo se aplica la regla de denegación. Si la condición se evalúa como true o no se puede evaluar, se deniega el permiso. Si la condición se evalúa como false, se otorga el permiso. Para obtener más información, consulta Condiciones de denegación en esta página.

Casos de uso habituales

Las siguientes son situaciones comunes en las que tal vez quieras usar políticas de denegación y ejemplos de las reglas de denegación que podrías crear en cada situación. Para obtener información sobre cómo crear y actualizar políticas de denegación, consulta Acceso de denegación a los recursos.

Centraliza los privilegios administrativos

Puedes usar políticas de denegación para restringir ciertos tipos de actividades administrativas a un conjunto específico de principales.

Por ejemplo, imagina que quieres limitar la administración de roles personalizados de tu organización a un solo equipo central. Para hacerlo, crea una regla de denegación que deniegue los permisos necesarios para la administración de roles personalizados a todos los usuarios, excepto a los del grupo administrativo ([e-mail]):

{
  "deniedPrincipals": [
    "principalSet://goog/public:all"
  ],
  "exceptionPrincipals": [
    "principalSet://goog/group/[e-mail]"
  ],
  "deniedPermissions": [
    "iam.googleapis.com/roles.create",
    "iam.googleapis.com/roles.delete",
    "iam.googleapis.com/roles.update",
  ]
}

Luego, adjunta la política de denegación a tu organización.

Ahora, solo los miembros del grupo [e-mail] pueden administrar roles personalizados, incluso si otros usuarios tienen los permisos necesarios.

Por ejemplo, imagina que [e-mail] y [e-mail] tienen el rol Administrador de roles de la organización (roles/iam.organizationRoleAdmin ). Sin embargo, [e-mail] es miembro de [e-mail], y [e-mail] no lo es. Con esta política de denegación, solo [e-mail] puede crear, borrar y actualizar funciones.

Crea excepciones para las concesiones de acceso

Puedes usar las políticas de denegación para denegar permisos heredados. Esta función te brinda la opción de otorgar una función en un nivel alto en la jerarquía de recursos y, luego, denegar los permisos de la función en recursos individuales de nivel inferior si es necesario.

Por ejemplo, imagina que tienes una carpeta, Engineering, que contiene varios proyectos. Deseas otorgar a un grupo, [e-mail], los permisos de la función de administrador de claves de cuenta de servicio (roles/iam.serviceAccountKeyAdmin) en casi todos los proyectos de la carpeta. Sin embargo, no quieres que el grupo obtenga la capacidad de crear y borrar claves de cuentas de servicio de un proyecto específico de la carpeta, example-prod.

En lugar de otorgar la función de administrador de claves de cuenta de servicio en cada proyecto individual, debes crear la siguiente regla de denegación, que rechaza los permisos de creación y eliminación en la función de administrador de claves de cuenta de servicio a las principales en [e-mail]:

{
  "deniedPrincipals": [
    "principalSet://goog/group/[e-mail]"
  ],
  "deniedPermissions": [
    "iam.googleapis.com/serviceAccountKeys.create",
    "iam.googleapis.com/serviceAccountKeys.delete"
  ]
}

Luego, agrega esta regla de denegación a una política de denegación y adjunta la política al proyecto example-prod.

Después de vincular la política de denegación al proyecto, puedes otorgar la función de administrador de claves de cuenta de servicio a [e-mail] en la carpeta Engineering sin permitir que el grupo cree o borre claves de cuenta de servicio en example-prod.

Los miembros de [e-mail] pueden crear y borrar claves de cuentas de servicio en todos los proyectos, excepto example-prod. Por ejemplo, si [e-mail] es miembro de [e-mail], puede crear y borrar claves para cuentas de servicio en example-dev y example-test, pero no en example-prod.

Sin embargo, imagina que deseas que un subconjunto de [e-mail] pueda crear y borrar claves de cuentas de servicio en example-prod. Este subconjunto está representado por el grupo [e-mail]. Para permitir que los miembros de [e-mail] creen y borren claves de cuentas de servicio en example-prod, puedes hacer que el grupo esté exento de la regla de denegación:

{
  "deniedPrincipals": [
    "principalSet://goog/group/[e-mail]"
  ],
  "exceptionPrincipals": [
    "principalSet://goog/group/[e-mail]"
  ],
  "deniedPermissions": [
    "iam.googleapis.com/serviceAccountKeys.create",
    "iam.googleapis.com/serviceAccountKeys.delete"
  ]
}

Con esta política de denegación revisada, los miembros de [e-mail] pueden crear y borrar claves de cuentas de servicio en todos los proyectos, incluido example-prod. Por ejemplo, si [e-mail] es miembro de [e-mail], puede crear y borrar claves en example-dev, example-test y example-prod, incluso si también es miembro de [e-mail].

Bloquea el acceso según las etiquetas

Una etiqueta es un par clave-valor que se puede adjuntar a una organización, una carpeta o un proyecto. Puedes usar las políticas de denegación para denegar permisos en función de las etiquetas sin agregar una condición de IAM a cada función otorgada.

Por ejemplo, imagina que etiquetas todos tus proyectos como dev, test o prod. Deseas que solo los miembros de [e-mail] puedan borrar proyectos etiquetados como prod.

Para resolver este problema, crea una regla de denegación que rechace el permiso cloudresourcemanager.googleapis.com/projects.delete a todos, excepto [e-mail] para los recursos que tienen la etiqueta prod:

{
  "displayName": "Only project admins can delete production projects.",
  "rules": [
    {
      "denyRule": {
        "deniedPrincipals": [
          "principalSet://goog/public:all"
        ],
        "exceptionPrincipals": [
          "principalSet://goog/group/[e-mail]"
        ],
        "deniedPermissions": [
          "cloudresourcemanager.googleapis.com/projects.delete"
        ],
        "denialCondition": {
          "title":  "Only for prod projects",
          "expression": "resource.matchTag('12345678/env', 'prod')"
        }
      }
    }
  ]
}

Luego, debes agregar esta regla de denegación a una política de denegación y adjuntarla a tu organización.

Debido a esta regla de rechazo, puedes limitar el acceso de las principales sin agregar una condición a sus concesiones de funciones. En su lugar, puedes otorgar a los principales roles que contengan el permiso cloudresourcemanager.googleapis.com/projects.delete y confiar en la regla de denegación para evitar que los principales fuera de [e-mail] borren cualquier proyecto etiquetado como prod.

Por ejemplo, considera dos usuarios: [e-mail] y [e-mail]. Ambos tienen la función de Eliminador de proyectos (roles/resourcemanager.projectDeleter). Además, [e-mail] es miembro de [e-mail]. Con esta política de denegación, [e-mail] solo puede borrar proyectos que tengan la etiqueta dev o test. [e-mail] puede borrar todos los proyectos, independientemente de sus etiquetas.

¿Qué sigue?

• Obtén más información para crear, actualizar y borrar políticas de denegación.
• Descubre cómo solucionar problemas de acceso con políticas de denegación.
• Revisa los permisos que se pueden rechazar.
• Consulta los tipos de principales que puedes incluir en las políticas de denegación.