Permisos de AssumeRole, AssumeRoleWithSAML y AssumeRoleWithWebIdentity

La política de permisos del rol que se asume determina los permisos de las credenciales de seguridad temporales devueltas por AssumeRole, AssumeRoleWithSAML y AssumeRoleWithWebIdentity. Defina estos permisos al crear o actualizar el rol.

De forma opcional, puede pasar políticas de sesión administradas o insertadas como parámetros de las operaciones de API AssumeRole, AssumeRoleWithSAML o AssumeRoleWithWebIdentity. Las políticas de sesión limitan los permisos para la sesión de credenciales temporales de la función. Los permisos de la sesión resultantes son la intersección de las políticas basadas en identidades de la función y las políticas de la sesión. Puede utilizar las credenciales temporales del rol en llamadas posteriores a la API de AWS para tener acceso a los recursos de la cuenta propietaria del rol. No puede utilizar las políticas de sesión para conceder más permisos que los permitidos por la política basada en identidades de la función que se asume. Para obtener más información sobre cómo determina AWS los permisos efectivos de un rol, consulte Lógica de evaluación de políticas.

AWS no evalúa las políticas asociadas a las credenciales con las que se hizo la llamada original a AssumeRole para tomar la decisión de autorización "permitir" o "denegar". El usuario abandona temporalmente sus permisos originales en favor de los permisos asignados al rol asumido. En el caso de las operaciones de API AssumeRoleWithSAML y AssumeRoleWithWebIdentity, no existen políticas que evaluar, porque el intermediario de la API no es una identidad de AWS.

Ejemplo: asignación de permisos utilizando AssumeRole

Puede utilizar la operación de API AssumeRole con diferentes tipos de políticas. A continuación se ofrecen algunos ejemplos.

Política de permisos del rol

En este ejemplo, se llama a la operación de API AssumeRole sin especificar la política de sesión en el parámetro opcional Policy. Los permisos asignados a las credenciales temporales vienen determinados por la política de permisos del rol que se asume. En el ejemplo siguiente, la política de permisos concede el permiso de rol para enumerar todos los objetos contenidos en un bucket de S3 denominado productionapp. También permite al rol obtener, agregar y eliminar objetos en ese bucket.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::productionapp"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::productionapp/*"
    }
  ]
}

Política de sesión pasada como parámetro

Imagine que desea permitir a un usuario asumir el mismo rol que en el ejemplo anterior. Sin embargo, en este caso desea que la sesión del rol solo tenga permiso para obtener y colocar objetos en el bucket de S3 productionapp. No desea permitirle eliminar objetos. Una forma de conseguirlo es crear un nuevo rol y especificar los permisos deseados en su política de permisos. Otra forma de conseguirlo consiste en llamar a la API AssumeRole e incluir políticas de sesión en el parámetro opcional Policy como parte de la llamada a la operación de API. Los permisos de la sesión resultantes son la intersección de las políticas basadas en identidades del rol y las políticas de la sesión. Las políticas de sesión no se pueden utilizar para conceder más permisos que los permitidos por la política basada en identidades del rol que se asume. Para obtener más información sobre los permisos de sesión de un rol, consulte Políticas de sesión.

Después de recuperar las credenciales temporales de la nueva sesión, puede pasarlas al usuario que desea que tenga esos permisos.

Por ejemplo, imagine que las siguientes políticas se transfieren como parámetro de la llamada a la API. La persona que ha iniciado la sesión solo tiene permisos para ejecutar las acciones siguientes:

Con la política de sesión siguiente, el permiso s3:DeleteObject se descarta y en la sesión no se concede el permiso s3:DeleteObject. La política establece los permisos máximos para la sesión del rol, anulando todas las políticas de permisos que tuviera el rol.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::productionapp"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::productionapp/*"
    }
  ]
}

Política basada en recursos

Algunos recursos de AWS admiten políticas basadas en recursos y dichas políticas proporcionan otro mecanismo para definir los permisos que afectan directamente a las credenciales de seguridad temporales. Solo unos pocos recursos, como buckets de Amazon S3, temas de Amazon SNS y colas de Amazon SQS admiten políticas basadas en recursos. El siguiente ejemplo amplía los ejemplos anteriores y utiliza un bucket de S3 denominado productionapp. La política siguiente se asocia al bucket.

Al adjuntar la siguiente política basada en recursos al bucket productionapp, se deniega a todos los usuarios el permiso para eliminar objetos del bucket. (Consulte el elemento Principal en la política). Esto incluye todos los usuarios con el rol asumido, aunque la política de permisos de rol conceda el permiso DeleteObject. Una instrucción Deny explícita siempre prevalece sobre una instrucción Allow.

{
  "Version": "2012-10-17",
  "Statement": {
    "Principal": {"AWS": "*"},
    "Effect": "Deny",
    "Action": "s3:DeleteObject",
    "Resource": "arn:aws:s3:::productionapp/*"
  }
}

Para obtener más información sobre el modo en que AWS combina y evalúa varios tipos de políticas, consulte Lógica de evaluación de políticas.