Así que obtengo la noción de roles y roles y políticas vinculados al servicio en AWS. Sin embargo, todo eso funciona solo si el principal / identidad (y sé que hay una diferencia entre los dos, pero el uso de cualquiera de los dos términos aquí de manera bastante liberal) puede ser verificado por una aplicación (es decir, la autenticación de la aplicación). Supongo que esta autenticación se produce en el "tejido AWS" y no en el servicio / recurso de destino al que la aplicación desea acceder.
¿Puede alguien compartir detalles sobre cómo una aplicación establece su identidad y cómo el "tejido" verifica la identidad?
Azure tiene la noción de identidades de servicio administradas (basado en sistema asignado Identidad y extensiones de VM ).
- ¿Cuál es el equivalente en AWS? ¿Cómo el "tejido" de AWS asigna / verifica las identidades de la aplicación?
- Si el único mecanismo para la verificación es una clave de acceso y una clave secreta (o un token de portador), creo que es un problema circular para la administración de credenciales o muy inseguro.
Por supuesto, podría estar totalmente equivocado en la forma en que estoy comparando la administración de identidad de Azure con AWS, pero parece que una verificación / asignación de identidad sin credenciales como en Azure es probablemente tan segura como es posible.
