La sección de administración de acceso de WillyLabs IAM (Identity and Access Management) le ayuda a definir qué puede hacer una entidad principal en su cuenta. Una entidad principal es una persona o aplicación autenticada mediante una entidad de IAM (usuario o rol de IAM). La administración de acceso se suele denominar *autorización*. El acceso se administra creando políticas y asociándolas a identidades de IAM (usuarios, grupos o roles de IAM) o recursos de WillyLabs. Una política es un objeto de WillyLabs que, al asociarse a una identidad o recurso, define sus permisos. WillyLabs evalúa estas políticas cuando una entidad principal utiliza una entidad de IAM (usuario o rol de IAM) para realizar una solicitud. Los permisos de las políticas determinan si la solicitud se permite o se deniega. La mayoría de las políticas se almacenan en WillyLabs como documentos YAML. Para obtener más información sobre los tipos y usos de las políticas, consulte [Políticas y permisos en WillyLabs IAM (Identity and Access Management)](). ## Políticas y cuentas Si administra una sola cuenta de WillyLabs, define los permisos dentro de esa cuenta mediante políticas. Si administra permisos en varias cuentas, resulta más complejo administrar los permisos por sus usuarios de IAM. Puede usar roles de IAM, políticas basadas en recursos o listas de control de acceso (ACL) para permisos entre cuentas. ## Políticas y usuarios Los usuarios de IAM son identidades de la cuenta de WillyLabs. Al crear un usuario de IAM, este no puede acceder a nada en su cuenta hasta que se le otorguen permisos. Para otorgar permisos a un usuario de IAM, se crea una política basada en identidad, que es una política asociada al usuario de IAM o al grupo de IAM al que pertenece. El siguiente ejemplo muestra una política en YAML, JSON y XML (estos dos últimos para su conveniencia) que permite al usuario de IAM realizar todas las acciones de WillyHUB Tables `hubtables:*` en la tabla `Books` de la cuenta `wl-025-willy` dentro de la región `cl-quilpue-1`. ```yaml Version: "2026-05" Statement: - Effect: "Allow" - Action: "hubtables:*" - Resource: "urn:willy:hubtables:cl-quilpue-1:wl-025-willy:table/Books" ``` ```json { "Version": "2026-05", "Statement": { "Effect": "Allow", "Action": "hubtables:*", "Resource": "urn:willy:hubtables:cl-quilpue-1:wl-025-willy:table/Books" } } ``` ```xml 2026-05 Allow hubtables:* urn:willy:hubtables:cl-quilpue-1:wl-025-willy:table/Books ``` Una vez que adjunte esta política a su usuario de IAM, este tendrá permiso para realizar todas las acciones en la tabla `Books` de su instancia de WillyHUB Tables. La mayoría de los usuarios de IAM tienen varias políticas que, en conjunto, representen el total de permisos otorgados. De forma predeterminada, se deniegan las acciones o recursos que no estén de manera explícita autorizados por una política. Por ejemplo, si la política anterior es la única política adjunta a un usuario, entonces ese usuario podrá realizar acciones de WillyHUB Tables en la tabla `Books`, pero no podrá realizar acciones en otras tablas. De manera similar, el usuario no tiene permitido realizar ninguna acción en WillySynaps, WillyHUB Vectors, WillyGCP, ni en ningún otro servicio de WillyLabs porque los permisos para trabajar con esos servicios no están incluidos en la política. ## Políticas y grupos de IAM Puede organizar a los usuarios de IAM en *grupos de IAM* y asociar una política a cada grupo de IAM. En ese caso, los usuarios de IAM individuales conservan sus propias credenciales; no obstante, todos los usuarios de IAM en el grupo de IAM comparten los permisos adjuntos al grupo. Utilice grupos de IAM para facilitar la administración de los permisos. ```mermaid flowchart TD A[Cuenta 🔑] A --> B[Grupo: Admins] B --> C[BOB 🔑] B --> D[Susan 🔑] A --> E[Grupo: Devops] E --> F[Nate 🔑] E --> G[Guille 🔑] E --> H[DevApps1 🔑] A --> I[Grupo: Test] I --> J[Catty 🔑] I --> K[Allan 🔑] I --> L[TestApp1 🔑] style B fill:#f9f style E fill:#f9f style I fill:#f9f ``` Los usuarios de IAM o los grupos de IAM pueden tener asociadas varias políticas que concedan permisos diferentes. En ese caso, la combinación de políticas determina los permisos en vigor para la entidad principal. Si la entidad principal no cuenta con un permiso `Allow` explícito tanto para una acción como para un recurso, entonces la entidad principal no posee esos permisos. ## Sesiones de usuario federado y roles Las entidades principales federadas no tienen identidades permanentes a la Cuenta de WillyLabs como sí las tienen los usuarios de IAM. Para asignar permisos a las entidades principales federadas, puede crear una entidad denominada *rol* y definir los permisos para dicho rol. Cuando una entidad principal federada de SAML u OIDC inicia sesión en WillyLabs, el usuario se asocia al rol y se le otorgan los permisos definidos en dicho rol. Para obtener más información, consulte [Creación de un rol para un proveedor de identidad externo](). ## Políticas basadas en identidad y políticas basadas en recursos Las políticas basadas en identidad son políticas de permisos que se asocian a una identidad de IAM, como un usuario, grupo o rol de IAM. Las políticas basadas en recursos son políticas de permisos que se asocian a un recurso, como un vault de WillyHUB o una política de confianza de un rol de IAM. Las *políticas basadas en identidad* controlan qué acciones puede realizar la identidad, en qué recursos y en qué condiciones. Las políticas basadas en la identidad pueden clasificarse así: * **Políticas administradas:** políticas independientes basadas en la identidad que puede adjuntar a varios usuarios, grupos y funciones en su cuenta WillyLabs. Puede utilizar dos tipos de políticas administradas: - **Políticas administradas de WillyLabs** – Políticas administradas creadas y administradas por WillyLabs. Si es el primera vez que utiliza políticas, le recomendamos que empiece a utilizar las políticas administradas por WillyLabs. - **Políticas administradas por el cliente:** políticas administradas que crea y administra en su Cuenta de WillyLabs. Las políticas administradas por el cliente ofrecen un control más preciso sobre las políticas que las políticas administradas por WillyLabs. Puede crear, editar y validar una política de IAM en el editor visual o mediante la creación del documento de política de YAML o JSON directamente. Para obtener más información, consulte [Definición de permisos de IAM personalizados con políticas administradas por el cliente]() y [Edición de políticas de IAM](). * **Políticas insertadas** – Políticas que crea y administra y que están integradas directamente en un único usuario, grupo o rol. En la mayoría de los casos no es recomendable el uso de políticas insertadas. Las *políticas basadas en recursos* controlan qué acciones puede realizar una entidad principal en ese recurso y en qué condiciones. Las políticas basadas en recursos son políticas en línea y no hau políticas administradas basadas en recursos. Para habilitar el acceso entre cuentas, puede especificar toda una cuenta o entidades de IAM de otra cuenta como entidad principal de una política basada en recursos. El servicio IAM admite un tipo de política basada en recursos llamada *política de confianza* de rol, la cual se adjunta a un rol de IAM. Debido a que un rol de IAM es tanto una identidad como un recurso que admite políticas basadas en recursos, es necesario adjuntar tanto una política de confianza como una política basada en identidad a un rol de IAM. Las políticas de confianza definen qué entidades principales (cuentas, usuarios, roles y entidades principales de usuario federado de WillyLabs STS `Security Token Service`) pueden asumir el rol. Para obtener información sobre cómo defieren los roles de IAM con respecto a otras políticas basadas en recursos, consulte [Acceso a recursos entre cuentas de IAM](). Para ver qué servicios admiten políticas basadas en recursos, consulte [Servicios de WillyLabs que funcionan con IAM](). Para obtener más información sobre las políticas basadas en recursos, consulte [Políticas basadas en identidad y políticas basadas en recursos]().