Permisos obligatorios para obtener acceso a recursos de IAM
Los recursos son objetos dentro de un servicio. Los recursos de IAM incluyen grupos, usuarios, roles y políticas. Si inicia sesión con las credenciales de Usuario raíz de la cuenta de AWS, no tiene restricciones para administrar credenciales de IAM o recursos de IAM. Sin embargo, los usuarios de IAM deben conceder permisos explícitamente para administrar credenciales o recursos de IAM. Puede hacerlo, adjuntando una política basada en identidades al usuario.
nota
En la documentación de AWS, cuando nos referimos a una política de IAM sin mencionar ninguna de las categorías específicas, nos referimos a una política administrada por el cliente basada en identidades. Para obtener información acerca de categorías de políticas, consulte Políticas y permisos en AWS Identity and Access Management.
Permisos para administrar identidades de IAM
Los permisos obligatorios para administrar grupos, usuarios, roles y credenciales de IAM normalmente corresponden a las acciones de la API para la tarea. Por ejemplo, con el fin de crear usuarios IAM, debe tener el permiso iam:CreateUser
que tiene el comando de API correspondiente: CreateUser
. Para permitir que un usuario de IAM cree otros usuarios de IAM, puede conectar una política de IAM como la siguiente a dicho usuario:
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "iam:CreateUser", "Resource": "*" } }
En una política, el valor del elemento Resource
depende de la acción y de los recursos a los que la acción puede afectar. En el ejemplo anterior, la política permite a un usuario crear cualquier usuario (*
es un comodín que coincide con todas las cadenas). En cambio, una política que permite a los usuarios cambiar únicamente sus propias claves de acceso (acciones de API CreateAccessKey
y UpdateAccessKey
) normalmente tiene un elemento Resource
. En este caso, el ARN incluye una variable (${aws:username}
) que se resuelve en el nombre del usuario actual, como en el siguiente ejemplo:
{ "Version": "2012-10-17", "Statement": [ { "Sid": "ListUsersForConsole", "Effect": "Allow", "Action": "iam:ListUsers", "Resource": "arn:aws:iam::*:*" }, { "Sid": "ViewAndUpdateAccessKeys", "Effect": "Allow", "Action": [ "iam:UpdateAccessKey", "iam:CreateAccessKey", "iam:ListAccessKeys" ], "Resource": "arn:aws:iam::*:user/${aws:username}" } ] }
En el ejemplo anterior, ${aws:username}
es una variable que se resuelve en el nombre de usuario del usuario actual. Para obtener más información sobre las variables de las políticas, consulte Elementos de la política de IAM: variables y etiquetas.
El uso de un comodín (*
) en el nombre de acción a menudo facilita la concesión de permisos para todas las acciones relacionadas con una tarea específica. Por ejemplo, para permitir que los usuarios realicen cualquier acción de IAM, puede utilizar iam:*
para la acción. Para permitir que los usuarios realicen cualquier acción relacionada solo con claves de acceso, puede utilizar iam:*AccessKey*
en el elemento Action
de la instrucción de una política. Esto da al usuario permiso para realizar las acciones CreateAccessKey
, DeleteAccessKey
, GetAccessKeyLastUsed
, ListAccessKeys
y UpdateAccessKey
. (Si una acción se añade a IAM en el futuro con "AccessKey" en el nombre, si usa iam:*AccessKey*
para el elemento Action
también dará al usuario permiso para esa nueva acción). En el ejemplo siguiente se muestra una política que permite a los usuarios llevar a cabo todas las acciones que pertenecen a sus propias claves de acceso (se sustituye
por su ID de cuenta de Cuenta de AWS): account-id
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "iam:*AccessKey*", "Resource": "arn:aws:iam::
account-id
:user/${aws:username}" } }
Algunas tareas, como, por ejemplo, eliminar un grupo, implican varias acciones: primero eliminar los usuarios del grupo, después separar o eliminar las políticas del grupo y, por último, eliminar el grupo. Si quiere que un usuario pueda eliminar un grupo, debe estar seguro de dar al usuario permisos para llevar a cabo todas las acciones relacionadas.
Permisos para trabajar en la AWS Management Console.
En los ejemplos anteriores se muestran políticas que permiten a un usuario realizar las acciones con la AWS CLI
A medida que los usuarios trabajan con la consola, esta genera solicitudes para IAM para enumerar grupos, usuarios, roles y políticas, y para obtener las políticas asociadas a un grupo, usuario o rol. La consola también envía solicitudes para obtener información de cuenta de Cuenta de AWS e información sobre la entidad principal. La entidad principal es el usuario que realiza solicitudes en la consola.
En general, para realizar una acción, debe tener únicamente la acción coincidente incluida en una política. Para crear un usuario, necesita permiso para llamar a la acción CreateUser
. A menudo, cuando utiliza la consola para realizar una acción, debe disponer de permisos para mostrar, enumerar, obtener o consultar recursos en la consola. Esto es necesario para que pueda navegar a través de la consola para realizar la acción especificada. Por ejemplo, si el usuario Jorge desea utilizar la consola para cambiar sus propias claves de acceso, va a la consola de IAM y elige Users. Esta acción hace que la consola genere una solicitud ListUsers
. Si Jorge no tiene permiso para la acción iam:ListUsers
, se deniega el acceso a la consola cuando esta intenta enumerar los usuarios. Como resultado, Jorge no puede ir a su propio nombre ni a sus propias claves de acceso, aunque tenga permisos para las acciones CreateAccessKey
y UpdateAccessKey
.
Si quiere conceder a los usuarios permisos para administrar grupos, usuarios, roles, políticas y credenciales con la AWS Management Console, debe incluir permisos para las acciones que realiza la consola. Para ver algunos ejemplos de políticas que puede utilizar para conceder a un usuario estos permisos, consulte Ejemplos de políticas para administrar recursos de IAM.
Conceder permisos en las cuentas de AWS
Puede conceder directamente a los usuarios de IAM de su propia cuenta acceso a los recursos. Si hay usuarios de otra cuenta que necesitan obtener acceso a sus recursos, puede crear un rol de IAM, que es una entidad que contiene permisos, pero que no está asociada a un usuario concreto. Los usuarios de otras cuentas pueden utilizar el rol y obtener acceso a recursos en función de los permisos que haya asignado al rol. Para obtener más información, consulte Acceso para un usuario de IAM en otra Cuenta de AWS propia.
nota
Algunos servicios de admiten políticas basadas en recursos como se describe en Políticas basadas en identidad y políticas basadas en recursos (como Amazon S3, Amazon SNS y Amazon SQS). Para esos servicios, una alternativa al uso de roles es adjuntar una política al recurso (bucket, tema o cola) que desea compartir. La política basada en recursos puede especificar la cuenta de AWS que tenga permisos para obtener acceso al recurso.
Permisos para que un servicio obtenga acceso a otro.
Muchos servicios de AWS obtienen acceso a otros servicios de AWS. Por ejemplo, varios servicios de AWS, como Amazon EMR, Elastic Load Balancing y Amazon EC2 Auto Scaling administran instancias de Amazon EC2. Otros servicios de AWS utilizan buckets de Amazon S3, temas de Amazon SNS, colas de Amazon SQS, etc.
El escenario de administración de permisos en estos casos varía según el servicio. He aquí algunos ejemplos de cómo se gestionan los permisos para diferentes servicios:
-
En Amazon EC2 Auto Scaling, los usuarios deben tener permiso para utilizar Auto Scaling, pero no necesitan que se les concedan de forma explícita permiso para administrar instancias Amazon EC2.
-
En AWS Data Pipeline, un rol de IAM determina qué puede hacer una canalización; los usuarios necesitan permiso para asumir el rol. (Para más detalles, consulte Concesión de permisos a pipelines con IAM en la Guía del desarrollador de AWS Data Pipeline).
Para obtener información detallada sobre cómo configurar permisos de forma adecuada, de forma que un servicio de AWS sea capaz de realizar las tareas que usted se propone, consulte la documentación del servicio al que llama. Para obtener información sobre cómo crear un rol para un servicio, consulte Crear un rol para delegar permisos a un servicio de AWS.
Configuración de un servicio con un rol de IAM para que trabaje en su nombre
Cuando quiere configurar un servicio de AWS para que trabaje en su nombre, normalmente proporciona el ARN de un rol de IAM que define qué puede hacer el servicio. AWS realiza una comprobación para asegurarse de que tiene permisos para transferir un rol a un servicio. Para obtener más información, consulte Conceder permisos a un usuario para transferir un rol a un servicio de AWS.
Acciones obligatorias
Las acciones son las cosas que puede hacer en un recurso, como visualizar, crear, editar y eliminar dicho recurso. Las acciones se definen por medio de cada servicio de AWS.
Para permitir a alguien realizar una acción, debe incluir las acciones necesarias en una política que se aplica a la identidad que realiza la llamada o al recurso afectado. En general, para proporcionar el permiso obligatorio para realizar una acción, deberá incluir dicha acción en la política. Por ejemplo, para crear un usuario, tiene que añadir la acción CreateUser a su política.
En algunos casos, una acción podría requerir que incluya acciones relacionadas en su política. Por ejemplo, para proporcionar permiso para que alguien cree un directorio en AWS Directory Service utilizando la operación ds:CreateDirectory
, deberá incluir las siguientes acciones en su política:
-
ds:CreateDirectory
-
ec2:DescribeSubnets
-
ec2:DescribeVpcs
-
ec2:CreateSecurityGroup
-
ec2:CreateNetworkInterface
-
ec2:DescribeNetworkInterfaces
-
ec2:AuthorizeSecurityGroupIngress
-
ec2:AuthorizeSecurityGroupEgress
Al crear o editar una política con el editor visual, recibe advertencias y avisos que le ayudarán a elegir todas las acciones necesarias para su política.
Para obtener más información acerca de los permisos necesarios para crear un directorio en AWS Directory Service, consulte Ejemplo 2: Permitir a un usuario crear un directorio.