Cómo funcionan las políticas

Supongamos que el administrador crea un grupo denominado HelpDesk cuyo trabajo es gestionar usuarios y sus credenciales. Esta es una política que permite hacerlo:

Allow group HelpDesk to manage users in tenancy

Tenga en cuenta que, debido a que los usuarios residen en el arrendamiento (el compartimento raíz), la política simplemente indica la palabra tenancy, sin la palabra compartment delante de ella.

A continuación, supongamos que tiene un compartimento denominado Project-A y un grupo denominado A-Admins cuyo trabajo es gestionar todos los recursos de Oracle Cloud Infrastructure del compartimento. A continuación, se muestra una política de ejemplo que permite esto:

Allow group A-Admins to manage all-resources in compartment Project-A

Tenga en cuenta que la política inmediatamente anterior incluye la capacidad de escribir políticas para ese compartimento, lo que significa que A-Admins puede controlar el acceso a los recursos del compartimento. Para obtener más información, consulte Anexo de políticas.

Si desea limitar el acceso de A-Admins a iniciar y gestionar instancias informáticas y volúmenes de almacenamiento de bloques (tanto los volúmenes como sus copias de seguridad) en el compartimento Project-A, pero la red en sí reside en el compartimento Networks, entonces la política podría ser:

Allow group A-Admins to manage instance-family in compartment Project-A

Allow group A-Admins to manage volume-family in compartment Project-A

Allow group A-Admins to use virtual-network-family in compartment Networks

La tercera sentencia con el tipo de recurso virtual-network-family activa el proceso de inicio de la instancia, porque la red en la nube está implicada. Específicamente, el proceso de inicio crea una nueva VNIC y la asocia a la subred donde reside la instancia.

Para obtener más ejemplos, consulte Políticas comunes.

Normalmente, en la política se especifica un grupo o compartimento por su nombre. Sin embargo, en su lugar puede utilizar el OCID. Asegúrese de agregar "id" antes del OCID. Por ejemplo:

Allow group

 id ocid1.group.oc1..aaaaaaaaqjihfhvxmumrl3isyrjw3n6c4rzwskaawuc7i5xwe6s7qmnsbc6a

 to manage instance-family in compartment Project-A

Puede especificar varios grupos separados por comas:

Allow group A-Admins, B-Admins to manage instance-family in compartment Projects-A-and-B

Oracle define los posibles verbos que puede utilizar en sus políticas. Este es un resumen de los verbos, de menor a mayor grado de acceso:

El verbo proporciona un determinado tipo de acceso general (por ejemplo, inspect permite mostrar y obtener recursos). Al unirse a ese tipo de acceso con un determinado tipo de recurso en una política (por ejemplo, Allow group XYZ to inspect compartments in the tenancy), le otorga a dicho grupo acceso a un juego específico de permisos y operaciones de API (por ejemplo, ListCompartments, GetCompartment). Para obtener más ejemplos, consulte Detalles de combinaciones de verbo + tipo de recurso. Cada servicio detalla la lista de operaciones de API cubiertas para cada combinación de verbo y tipo de recurso.

algunas excepciones o matices especiales para ciertos tipos de recursos.

Usuarios: el acceso a manage users y a manage groups permite realizar cualquier acción con usuarios y grupos, incluidas la creación y la supresión de usuarios y grupos, así como la agregación/eliminación de usuarios de los grupos. Para agregar/eliminar usuarios de los grupos sin acceso a la creación y la supresión de usuarios y grupos, solo se necesita use users y use groups. Consulte Políticas comunes.

Políticas: la capacidad para actualizar una política solo está disponible con manage policies, no use policies, porque la actualización de una política es similar a la creación de una nueva política (puede sobrescribir las sentencias de política existentes). Además, inspect policies le permite obtener el contenido completo de las políticas.

Objetos de Object Storage: inspect objects permite mostrar todos los objetos de un cubo y realizar una operación HEAD para un objeto determinado. En comparación, read objects permite descargar el objeto en sí.

Recursos del equilibrador de carga: tenga en cuenta que inspect load-balancers permite obtener toda la información sobre los equilibradores de carga y los componentes relacionados (juegos de backend, etc.).

Recursos de red:

Oracle también define los tipos de recursos que puede utilizar en sus políticas. En primer lugar, hay tipos individuales. Cada tipo individual representa un tipo específico de recurso. Por ejemplo, el tipo de recurso vcns se emplea específicamente para redes virtuales en la nube (VCN).

Para facilitar la escritura de políticas, hay tipos family que incluyen varios tipos de recursos individuales que se suelen gestionar juntos. Por ejemplo, el tipo virtual-network-family reúne una serie de tipos relacionados con la gestión de VCN (p. ej., vcns, subnets, route-tables, security-lists, etc.). Si necesita escribir una política más granular que solo proporcione acceso a un tipo de recurso individual, puede hacerlo. Pero también puede escribir fácilmente una política para ofrecer acceso a un rango más amplio de recursos.

En otro ejemplo: un volumen en bloque tiene volumes, volume-attachments y volume-backups. Si solo necesita conceder acceso a la realización de copias de seguridad de volúmenes, puede especificar el tipo de recurso volume-backups en la política. Sin embargo, si necesita dar acceso amplio a todos los recursos del volumen en bloque, puede especificar el tipo de familia denominado volume-family. Para obtener una lista completa de los tipos de recursos family, consulte Tipos de recursos.

Tenga en cuenta que hay otras maneras de hacer que las políticas sean más granulares, como la capacidad de especificar las condiciones en las que se concede el acceso. Para obtener más información, consulte Funciones avanzadas de políticas.

Algunas operaciones de API requieren acceso a varios tipos de recursos. Por ejemplo, LaunchInstance requiere la capacidad de crear instancias y trabajar con una red en la nube. La operación CreateVolumeBackup requiere acceso tanto al volumen como a la copia de seguridad del volumen. Esto significa que dispondrá de sentencias específicas para otorgar acceso a cada tipo de recurso (para ver un ejemplo, consulte Permitir a los administradores de copia de seguridad de volúmenes gestionar solo copias de seguridad). Estas sentencias individuales no tienen por qué estar en la misma política. Además, un usuario puede obtener el acceso necesario al estar en diferentes grupos. Por ejemplo, George podría estar en un grupo que proporciona el nivel de acceso necesario al tipo de recurso volumes y en otro grupo que concede el acceso necesario al tipo de recurso volume-backups. La suma de las sentencias individuales, independientemente de su ubicación en el juego general de políticas, proporciona a George acceso a CreateVolumeBackup.

Una función básica de las políticas es el concepto de herencia: los compartimentos heredan todas las políticas de su compartimento principal. El ejemplo más sencillo es el grupo Administradores, que se incluye automáticamente con su arrendamiento (consulte Política y grupo Administradores). Existe una política incorporada que permite al grupo Administradores realizar cualquier acción en el arrendamiento:

Allow group Administrators to manage all-resources in tenancy

Debido a la herencia de políticas, el grupo Administradores también puede realizar cualquier acción en cualquiera de los compartimentos del arrendamiento.

Para ilustrar mejor esto, piense en un arrendamiento con tres niveles de compartimentos: CompartmentA, CompartmentB y ComparmentC, que se muestran a continuación:

Las políticas que se aplican a los recursos de CompartmentA también se aplican a los recursos de CompartmentB y CompartmentC. Por lo tanto, esta política:

Allow group NewtworkAdmins to manage virtual-network-family in compartment CompartmentA

permite al grupo NetworkAdmins gestionar las VCN en CompartmentA, CompartmentB y CompartmentC.

Otra función básica de las políticas es el concepto de asociación. Cuando crea una política, debe asociarla a un compartimento (o al arrendamiento, que es el compartimento raíz). El lugar al que la asocie determinará quién puede modificarla o suprimirla. Si la asocia al arrendamiento (es decir, si la política está en el compartimento raíz), cualquier usuario con acceso para gestionar políticas en el arrendamiento podrá cambiarla o suprimirla. Normalmente, se trata del grupo Administradores o cualquier grupo similar que se crea y al que se proporciona acceso amplio. Un usuario que solo tenga acceso a un compartimento secundario no puede modificar ni suprimir esa política.

En cambio, si asocia la política a un compartimento secundario, cualquiera que tenga acceso para gestionar políticas en ese compartimento podrá cambiarla o suprimirla. En la práctica, esto significa que es fácil otorgar a los administradores de compartimento (es decir, un grupo con permiso manage all-resources en el compartimento) acceso para gestionar sus propias políticas de compartimento, sin asignarles un acceso más amplio para gestionar las políticas que residan en el arrendamiento. Para ver un ejemplo que utilice este tipo de diseño de administrador de compartimento, consulte Escenario de ejemplo. (Recuerde que, debido a la herencia de políticas, los usuarios con acceso para gestionar políticas en el arrendamiento tienen automáticamente la capacidad de gestionar políticas en compartimentos dentro del arrendamiento).

El proceso de asociación de la política es fácil (mediante la asociación a un compartimento o al arrendamiento): si está utilizando la consola, cuando agregue la política a IAM, simplemente asegúrese de que está en el compartimento deseado en el momento en que crea la política. Si utiliza la API, especifique el OCID del compartimento deseado (ya sea el arrendamiento u otro compartimento) como parte de la solicitud para crear la política.

Cuando asocia una política a un compartimento, debe estar en ese compartimento y debe indicar directamente en la sentencia a qué compartimento se aplica. Si no se encuentra en el compartimento, recibirá un error si intenta asociar la política a otro compartimento diferente. Tenga en cuenta que la asociación se produce durante la creación de la política, lo que significa que una política se puede asociar solo a un compartimento. Para aprender a asociar una política a un compartimento, consulte Para crear una política.

Como se describe en la sección anterior, una sentencia de política debe especificar el compartimento para el que se otorga acceso (o el arrendamiento). Dónde se crea la política determina quién puede actualizar la política. Si asocia la política al compartimento o a su principal, puede especificar sin más el nombre del compartimento. Si asocia la política más arriba en la jerarquía, debe especificar la ruta de acceso. El formato de la ruta de acceso es cada nombre de compartimento (o OCID) de la ruta de acceso, separado por dos puntos:

<compartment_level_1>:<compartment_level_2>: . . . <compartment_level_n>

Por ejemplo, suponga que tiene una jerarquía de compartimento de tres niveles, como se muestra aquí:

Desea crear una política para permitir a NetworkAdmins gestionar las VCN en CompartmentC. Si desea asociar esta política a CompartmentC o a su principal, CompartmentB, escriba esta sentencia de política:

Allow group NewtworkAdmins to manage virtual-network-family in compartment CompartmentC

Sin embargo, si desea asociar esta política a CompartmentA (para que solo los administradores de CompartmentA puedan modificarla), escriba esta sentencia de política que especifica la ruta de acceso:

Allow group NewtworkAdmins to manage virtual-network-family in compartment CompartmentB:CompartmentC

Para asociar esta política al arrendamiento, escriba esta sentencia de política que especifica la ruta de acceso de CompartmentA a CompartmentC:

Allow group NewtworkAdmins to manage virtual-network-family in compartment CompartmentA:CompartmentB:CompartmentC

Es posible que la definición de un verbo o tipo de recurso pueda cambiar en el futuro. Por ejemplo, supongamos que el recurso virtual-network-family cambia para incluir un nuevo tipo de recurso que se ha agregado a Networking. Por defecto, sus políticas se actualizan automáticamente ante cualquier cambio en la definición del servicio, por lo que cualquier política suya que acceda a virtual-network-family incluirá automáticamente el acceso al recurso recién agregado.

La visión general de políticas de IAM incluye detalles de los tipos de recursos específicos para cada servicio, y qué combinación de verbo + tipo de recurso proporciona acceso a qué operaciones de API.