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.

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.

Evaluación de política

Cuando una principal intenta acceder a un recurso, IAM evalúa todas las políticas de permiso y denegación relevantes para ver si la principal puede acceder al recurso. Las políticas se evalúan en este orden:

  1. IAM verifica todas las políticas de denegación relevantes para ver si la principal tiene el permiso denegado. Las políticas de denegación relevantes son las políticas de denegación adjuntas al recurso, así como cualquier política de denegación heredada.

    Si alguna de estas políticas de denegación impide que la principal use un permiso requerido, IAM impide que acceda al recurso.

    Si ninguna política de denegación impide que la principal use un permiso obligatorio, IAM continúa con el paso siguiente.

  2. IAM verifica todas las políticas de permisos relevantes para ver si la principal tiene los permisos necesarios. Las políticas de permiso relevantes son las políticas de permiso adjuntas al recurso, así como cualquier política de permiso heredada.

    Si la principal tiene los permisos necesarios, IAM le permitirá acceder al recurso.

    Si la principal no tiene los permisos necesarios, IAM impedirá que acceda al recurso.

En el siguiente diagrama, se muestra este flujo de evaluación de políticas:

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. No puedes usar comodines en ningún otro nombre de permiso.

El identificador para un grupo de permisos reemplaza una o más secciones de un nombre de permiso por un carácter comodín (*). El grupo de permisos incluye todos los permisos que coinciden con este patrón.

Los comodines pueden aparecer en los siguientes lugares:

  • 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.

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 project-admins@example.com 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/project-admins@example.com"
        ],
        "deniedPermissions": [
          "cloudresourcemanager.googleapis.com/projects.delete"
        ],
        "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 APIs 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.

  • 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 (custom-role-admins@example.com):

{
  "deniedPrincipals": [
    "principalSet://goog/public:all"
  ],
  "exceptionPrincipals": [
    "principalSet://goog/group/custom-role-admins@example.com"
  ],
  "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 custom-role-admins@example.com pueden administrar roles personalizados, incluso si otros usuarios tienen los permisos necesarios.

Por ejemplo, imagina que yuri@example.com y tal@example.com tienen el rol Administrador de roles de la organización (roles/iam.organizationRoleAdmin ). Sin embargo, yuri@example.com es miembro de custom-role-admins@example.com, y tal@example.com no lo es. Con esta política de denegación, solo yuri@example.com 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, eng@example.com, 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 eng@example.com:

{
  "deniedPrincipals": [
    "principalSet://goog/group/eng@example.com"
  ],
  "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 eng@example.com en la carpeta Engineering sin permitir que el grupo cree o borre claves de cuenta de servicio en example-prod.

Los miembros de eng@example.com pueden crear y borrar claves de cuentas de servicio en todos los proyectos, excepto example-prod. Por ejemplo, si izumi@example.com es miembro de eng@example.com, 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 eng@example.com pueda crear y borrar claves de cuentas de servicio en example-prod. Este subconjunto está representado por el grupo eng-prod@example.com. Para permitir que los miembros de eng-prod@example.com 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/eng@example.com"
  ],
  "exceptionPrincipals": [
    "principalSet://goog/group/eng-prod@example.com"
  ],
  "deniedPermissions": [
    "iam.googleapis.com/serviceAccountKeys.create",
    "iam.googleapis.com/serviceAccountKeys.delete"
  ]
}

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

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 project-admins@example.com 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 project-admins@example.com 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/project-admins@example.com"
        ],
        "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 project-admins@example.com borren cualquier proyecto etiquetado como prod.

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

¿Qué sigue?