amazon web services - Dentro de IAM, ¿puedo restringir un grupo de usuarios para acceder/iniciar/terminar solo ciertas AMI o instancias de EC2?

amazon-web-services amazon-ec2

Question

Lo que dice el título.

Dentro de la cuenta maestra de AWS, tengo varias cuentas personales, es decir, usuarios de AWS Identity and Access Management (IAM) . Me gustaría asignar ciertos usuarios de IAM a grupos y evitar que terminen ciertas instancias de Amazon EC2 , anulen el registro de ciertas imágenes de máquina de Amazon (AMI) , etc.

No me importa si están jugando con sus propias cosas, pero no quiero que toquen mis cosas.

¿Es eso posible?

Answer 1

Actualizar

AWS acaba de anunciar Permisos de nivel de recursos para Amazon EC2 y Amazon RDS para abordar este defecto de larga data del soporte de IAM dentro de EC2 y RDS (en comparación con otros servicios de AWS, consulte mi respuesta original a continuación para obtener detalles / antecedentes):

Hoy estamos haciendo que IAM sea aún más poderoso con la introducción de permisos a nivel de recursos para Amazon EC2 y Amazon RDS . [...]

En el lado de EC2, ahora puede construir y usar políticas de IAM para controlar el acceso a las instancias de EC2, los volúmenes EBS, las imágenes y las direcciones IP elásticas. [...]

Estas son algunas de las cosas que puede hacer:

• Permita que los usuarios actúen en un conjunto limitado de recursos dentro de un entorno EC2 multiusuario más grande.
• Establecer diferentes permisos para los recursos de "desarrollo" y "prueba".
• Controla qué usuarios pueden terminar qué instancias.
• Requerir medidas de seguridad adicionales, como la autenticación MFA, al actuar sobre ciertos recursos.

Esto resuelve una gran cantidad de complicaciones de seguridad y también permite bastantes nuevos casos de uso.

Además, las declaraciones de políticas de EC2 pueden incluir referencias a etiquetas en los recursos de EC2 , lo que permite utilizar el mismo modelo y esquema de etiquetado para los permisos y para los informes de facturación . Finalmente, hay un conjunto expandido de etiquetas de condición [...] que incluye ec2: Región, ec2: Propietario y ec2: Tipo de instancia , consulte las Claves de condición para Amazon EC2 para obtener más detalles.

Solución

Aquí hay una variación del Ejemplo 3: Permitir que los usuarios detengan e inicien solo instancias particulares para el caso de uso en cuestión, lo que les permite iniciar y detener [y terminar] solo las instancias que tienen la etiqueta "department = dev" :

{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"ec2:StopInstances",
"ec2:StartInstances",
"ec2:TeminateInstances"
],
"Resource": "arn:aws:ec2:us-east-1:123456789012:instance/*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/department": "dev"
}
}
}
]
}

Advertencia

El soporte para los permisos a nivel de recursos está restringido al siguiente conjunto de acciones en los recursos indicados, que excluye partes del caso de uso (por ejemplo , anular el registro de AMI ): la confianza en la base de esta característica compleja y de gran alcance es aparentemente lo suficientemente alto como para anunciar que planean agregar soporte para API adicionales durante el resto de 2013 (por lo general, AWS no publica ningún plan de trabajo):

• Instancias - Reiniciar, Iniciar, Detener, Terminar.
• Volúmenes EBS - Adjuntar, Eliminar, Separar.

Respuesta original

Me temo que esto no es posible de la forma en que te gustaría hacerlo (y muchos otros, incluso yo mismo).

Problema

Desea restringir el acceso a los recursos de un servicio en particular en lugar de a sus acciones , mientras que AWS Identity and Access Management (IAM) es compatible con ambos, en principio, no todos los productos / servicios de AWS ofrecen restricciones basadas en recursos; desafortunadamente, Amazon EC2 es uno de estos e incluso se presenta como un ejemplo de esta misma diferencia, consulte Integración con otros productos de AWS :

La siguiente tabla resume si puede otorgar permisos de IAM que controlen el acceso a las acciones, los recursos de un servicio o ambos. Por ejemplo, puede usar IAM para controlar a qué acciones de Amazon EC2 tienen acceso los usuarios, pero no puede usar IAM para controlar el acceso de los usuarios a AMI, volúmenes, instancias, etc. [énfasis mío]

(Parcial) Solución

Dependiendo de las necesidades de las otras cuentas, es posible que aún pueda al menos limitar su capacidad para realizar aquellas acciones consideradas destructivas; puede explorar las acciones disponibles a través del generador de políticas de AWS , por ejemplo:

• ec2:DeregisterImage - efecto obvio, cuando se deniega para un usuario / grupo
• ec2:ModifyInstanceAttribute : esto ayudaría a través de la habilitación de la protección de terminación para una instancia , cuando se deniega para un usuario / grupo:

De forma predeterminada, puede terminar cualquier instancia que inicie. Si desea evitar la terminación accidental de la instancia, puede habilitar la protección de terminación para la instancia.

Es decir, una vez que haya habilitado la protección de terminación, cualquier persona sin permiso para usar ec2:ModifyInstanceAttribute no puede terminar estas instancias en absoluto.

Obviamente, las cuentas restringidas respectivamente ya no podrán facilitar esas llamadas para sus propios recursos.

Además, esto no evitará que ejecuten una elegante instancia de gran tamaño de Cluster Compute Eight o algo así, incurriendo en los costos respectivos a su vez;)

Enfoque alternativo

Dependiendo de su configuración / entorno, es posible que desee consultar la Facturación consolidada , que esencialmente proporciona una manera de reunir una o varias cuentas de AWS bajo otra, que es pagar por los recursos utilizados por las otras.

Si bien esta es principalmente una función contable, también se puede usar para separar áreas de interés, por ejemplo, es bastante común facilitar cuentas de desarrollo y producción separadas para lograr una operación independiente respectivamente, no menos importante con respecto a los derechos de IAM y similares.

La publicación introductoria del blog New AWS Feature: Consolidated Billing ofrece una buena descripción general, y este es el tema relevante de la AWS Consolidated Billing Guide con respecto a su caso de uso aparente:

La cuenta de pago se factura por todos los costos de las cuentas vinculadas. Sin embargo, cada cuenta vinculada es completamente independiente en todos los demás aspectos (inscribirse en los servicios, acceder a recursos, usar el Soporte Premium de AWS, etc.). El propietario de la cuenta de pago no puede acceder a los datos que pertenecen a los propietarios de la cuenta vinculada (por ejemplo, sus archivos en Amazon S3). Cada propietario de cuenta usa sus propias credenciales de AWS para acceder a sus recursos (por ejemplo, su propia clave de acceso secreta de AWS). [énfasis mío]

Obviamente, esta funcionalidad está dirigida a clientes más grandes, pero dependiendo de su situación, podría encontrar una solución para separar sus cuentas y recursos de AWS según sea necesario.