Last updated
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
Modelo de recursos de IBM Cloud (de la documentación):
Forma recomendada de dividir proyectos:
Los usuarios tienen un correo electrónico asignado. Pueden acceder a la consola de IBM y también generar claves API para usar sus permisos programáticamente. Los permisos pueden ser otorgados directamente al usuario con una política de acceso o a través de un grupo de acceso.
Estos son como los Roles de AWS o cuentas de servicio de GCP. Es posible asignarlos a instancias de VM y acceder a sus credenciales a través de metadatos, o incluso permitir a Proveedores de Identidad usarlos para autenticar usuarios de plataformas externas. Los permisos pueden ser otorgados directamente al perfil de confianza con una política de acceso o a través de un grupo de acceso.
Esta es otra opción para permitir que las aplicaciones interactúen con IBM Cloud y realicen acciones. En este caso, en lugar de asignarlo a una VM o Proveedor de Identidad, se puede usar una clave API para interactuar con IBM de manera programática. Los permisos pueden ser otorgados directamente al ID de servicio con una política de acceso o a través de un grupo de acceso.
Se pueden configurar Proveedores de Identidad externos para acceder a los recursos de IBM Cloud desde plataformas externas accediendo a perfiles de confianza.
En el mismo grupo de acceso pueden estar presentes varios usuarios, perfiles de confianza e IDs de servicio. Cada principal en el grupo de acceso heredará los permisos del grupo de acceso. Los permisos pueden ser otorgados directamente al perfil de confianza con una política de acceso. Un grupo de acceso no puede ser miembro de otro grupo de acceso.
Un rol es un conjunto de permisos granulares. Un rol está dedicado a un servicio, lo que significa que solo contendrá permisos de ese servicio. Cada servicio de IAM ya tendrá algunos roles posibles para elegir y otorgar acceso a un principal a ese servicio: Visualizador, Operador, Editor, Administrador (aunque podría haber más).
Los permisos de rol se otorgan a través de políticas de acceso a los principales, por lo que si necesitas otorgar, por ejemplo, una combinación de permisos de un servicio de Visualizador y Administrador, en lugar de otorgar esos 2 (y sobreprivilegiar a un principal), puedes crear un nuevo rol para el servicio y otorgar a ese nuevo rol los permisos granulares que necesitas.
Las políticas de acceso permiten adjuntar 1 o más roles de 1 servicio a 1 principal. Al crear la política, necesitas elegir:
El servicio donde se otorgarán los permisos
Recursos afectados
Acceso al servicio y plataforma que se otorgará
Estos indican los permisos que se otorgarán al principal para realizar acciones. Si se crea algún rol personalizado en el servicio, también podrás elegirlo aquí.
Condiciones (si las hay) para otorgar los permisos
Para otorgar acceso a varios servicios a un usuario, puedes generar varias políticas de acceso
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
