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

Cada proyecto, carpeta y organización puede tener hasta 5 políticas de denegación adjuntas. 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.

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 cualquier 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 cualquier recurso dentro de el 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.

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 y de servicio. Los conjuntos de principales incluyen Grupos de Google, dominios de Cloud Identity y todos los usuarios de Internet.
  • 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 y de servicio. Los conjuntos de principales incluyen Grupos de Google y dominios de Cloud Identity.

  • deniedPermissions: Son los permisos que las principales especificadas no pueden usar o denegar. Estos permisos usan el formato de permiso v2beta 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

  • 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 funciones personalizadas de tu organización a un solo equipo central. A fin de hacerlo, crea una regla de denegación que deniegue los permisos necesarios para la administración de funciones personalizadas 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 funciones personalizadas, 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 agregar el grupo como una principal excepcional en 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.

A fin de 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?