Introducción a las políticas
Para comenzar, primero debe decidir si desea y cómo desea empezar a utilizar políticas y familiarizarse con preguntas comunes sobre políticas.
Si no está familiarizado con las políticas de IAM, este tema le proporcionará orientación sobre cómo continuar.
Si va a realizar una prueba de concepto
Cree un proyecto de prueba de concepto con recursos de infraestructura.
Si solo está probando Oracle Cloud Infrastructure o está realizando un proyecto de prueba de concepto con recursos de infraestructura, puede que solo necesite unos pocos administradores con acceso completo a todo. En ese caso, basta con crear los nuevos usuarios que necesite y agregarlos al grupo Administradores. Los usuarios podrán realizar cualquier acción con cualquier tipo de recurso. Asimismo, puede crear todos sus recursos directamente en el arrendamiento (el compartimento raíz). Todavía no necesita crear compartimentos ni ninguna otra política, excepto la política de administración de arrendatario, que se incluye automáticamente con su arrendamiento y no se puede cambiar.
No olvide agregar sus nuevos usuarios al grupo Administradores. Es fácil olvidarse de hacerlo después de crearlos.
Si ya ha pasado la fase de prueba de concepto
Restringir el acceso a los recursos después de la fase de prueba de concepto.
Si ya ha pasado la fase de prueba de concepto y desea restringir el acceso a sus recursos, primero:
- Asegúrese de que conoce los componentes básicos de IAM y lea el escenario de ejemplo: Escenario de ejemplo
- Piense en cómo organizar sus recursos en compartimentos: Aprender las mejores prácticas para configurar el arrendamiento
- Aprenda los conceptos básicos del funcionamiento de las políticas: Cómo funcionan las políticas
- Vea algunas políticas típicas: Políticas comunes
- Lea la sección siguiente para obtener más información
Más información sobre las políticas
Más información sobre las políticas.
A todos ellos, incluido el propio IAM. Puede encontrar detalles específicos para la escritura de políticas para cada servicio en la Referencia de políticas.
Sí. Todos los usuarios pueden realizar automáticamente las siguientes tareas sin una política explícita:
- Cambiar o restablecer su propia contraseña de consola.
- Gestionar sus propias claves de firma de API y otras credenciales.
Puede colocar todos sus recursos en un solo compartimento y utilizar políticas para controlar el acceso, pero entonces perdería las ventajas de medir el uso y la facturación por compartimento, la administración simple de políticas a nivel de compartimento y la separación clara de recursos entre proyectos o unidades de negocio.
Sí. Sin embargo, algunos aspectos que hay que conocer primero:
- Las empresas suelen tener varios usuarios que necesitan permisos similares, por lo que las políticas están diseñadas para proporcionar acceso a grupos de usuarios, no a usuarios individuales. Un usuario obtiene acceso por el hecho de estar en un grupo.
- Las políticas están diseñadas para permitir el acceso y no hay ninguna "denegación" explícita al escribir una política.
Si necesita otorgar acceso a un usuario determinado, puede agregar una condición a la política que especifique el OCID del usuario en una variable. Esta construcción restringe el acceso otorgado en la política solo al usuario especificado en la condición. Por ejemplo:
allow any-group to read object-family in compartment ObjectStorage where request.user.id ='ocid1.user.oc1..<user_OCID>'Para obtener más información sobre el uso de condiciones y variables en políticas, consulte Condiciones.
Si necesita restringir el acceso de un usuario concreto, puede:
- Eliminar al usuario del grupo de interés concreto
- Suprimir por completo de IAM (primero debe eliminar al usuario de todos los grupos)
Asegúrese primero de que el usuario no está en ningún grupo. Solo entonces podrá suprimir el usuario.
Deberá examinar las sentencias individuales de todas sus políticas para ver las sentencias que se aplican a cada grupo. Actualmente no hay una forma sencilla de obtener esta información.
Debe consultar las sentencias individuales en todas las políticas del arrendamiento para ver si alguna se aplica al compartimento concreto. También debe consultar las políticas del compartimento en sí. Las políticas de los compartimentos hermanos no pueden hacer referencia al compartimento de interés, por lo que no necesita comprobar esas políticas.
Descripción de las políticas
IAM utiliza políticas para restringir el acceso a los recursos.
Por defecto, las políticas existen en el nivel de arrendamiento y se pueden aplicar a los dominios de identidad. También puede crear políticas con un ámbito más pequeño, por ejemplo, limitando el acceso a un recurso específico. Consulte Cómo funcionan las políticas.
Escenario de ejemplo
Ejemplos que muestran cómo funcionan de forma conjunta los distintos componentes de IAM.
El objetivo de este escenario es mostrar cómo trabajan conjuntamente los diferentes componentes de IAM y presentar las funciones básicas de las políticas.
En este escenario, la compañía Acme tiene dos equipos que utilizarán los recursos de Oracle Cloud Infrastructure para la infraestructura: Proyecto A y Proyecto B. En realidad, su compañía puede tener muchos más.
La compañía Acme planea utilizar una sola red virtual en la nube (VCN) para ambos equipos y desea que un administrador de red gestione la VCN.
La compañía Acme también desea que los equipos del Proyecto A y del Proyecto B tengan su propio juego de instancias y volúmenes de almacenamiento de bloques. Los equipos del Proyecto A y del Proyecto B no deberían poder utilizar instancias ajenas a su proyecto. Además, estos dos equipos tampoco deberían poder cambiar ningún aspecto de la configuración de la VCN realizada por el administrador de red. La compañía Acme desea que cada equipo tenga administradores para los recursos de ese equipo. Los administradores del equipo del Proyecto A pueden decidir quién puede utilizar los recursos en la nube del Proyecto A y cómo. Lo mismo se aplica al equipo del Proyecto B.
Introducción de la compañía Acme a Oracle Cloud Infrastructure
La compañía Acme se registra para utilizar Oracle Cloud Infrastructure e indica a Oracle que una empleada llamada Wenpei será el administrador predeterminado. Como respuesta, Oracle:
- Crea un arrendamiento para la compañía Acme (consulte el siguiente diagrama).
- Crea una cuenta de usuario de IAM para Wenpei en el arrendamiento.
- Crea el grupo Administradores en el arrendamiento y coloca a Wenpei en ese grupo.
- Crea una política en el arrendamiento de la compañía Acme que concede al grupo Administradores acceso para gestionar todos los recursos del arrendamiento. A continuación, se muestra dicha política:
Allow group Administrators to manage all-resources in tenancy
El administrador por defecto crea algunos grupos y otro administrador
A continuación, Wenpei crea varios grupos y usuarios (consulte el siguiente diagrama). Ella:
- Crea grupos con los nombres NetworkAdmins, A-Admins y B-Admins (estos dos últimos son para el Proyecto A y el Proyecto B dentro de la compañía)
- Crea un usuario denominado Alex y lo coloca en el grupo Administradores.
- Deja los nuevos grupos vacíos.
Para obtener más información sobre cómo crear grupos, consulte Gestión de grupos. Para obtener más información sobre cómo crear usuarios y colocarlos en grupos, consulte Gestión de usuarios.
El administrador por defecto crea algunos compartimentos y políticas
Wenpei crea los compartimentos para agrupar recursos (consulte el siguiente diagrama). Ella:
- Crea un compartimento denominado Redes para controlar el acceso a la VCN de la compañía Acme, las subredes, la VPN de sitio a sitio y otros componentes de Networking.
- Crea un compartimento denominado Project-A para organizar los recursos en la nube del equipo del Proyecto A y controlar el acceso a ellos.
- Crea un compartimento denominado Project-B para organizar los recursos en la nube del equipo del Proyecto B y controlar el acceso a ellos.
Para obtener más información sobre cómo gestionar compartimentos, consulte Gestión de compartimentos.
A continuación, Wenpei crea una política para proporcionar a los administradores de cada compartimento su nivel de acceso necesario. Wenpei asocia la política al arrendamiento, lo que significa que solo los usuarios con acceso para gestionar políticas en el arrendamiento pueden actualizar o suprimir posteriormente la política. En este escenario, se trata solamente del grupo Administradores. La política incluye varias sentencias que:
- Proporcionan al grupo NetworkAdmins acceso para gestionar redes e instancias (a efectos de probar fácilmente la red) en el compartimento Networks
- Proporcionan a los grupos A-Admins y B-Admins acceso para utilizar las redes del compartimento Networks (para que puedan crear instancias en la red).
- Proporcionan al grupo A-Admins acceso para gestionar todos los recursos del compartimento Project-A.
- Proporcionan al grupo B-Admins acceso para gestionar todos los recursos del compartimento Project-B.
La apariencia de la política es la siguiente (como puede ver, incluye varias sentencias):
Allow group NetworkAdmins to manage virtual-network-family in compartment Networks
Allow group NetworkAdmins to manage instance-family in compartment Networks
Allow group A-Admins,B-Admins to use virtual-network-family in compartment Networks
Allow group A-Admins to manage all-resources in compartment Project-A
Allow group B-Admins to manage all-resources in compartment Project-B
Observe la diferencia en los verbos (manage, use), así como en los recursos (virtual-network-family, instance-family, all-resources). Para obtener más información sobre ellos, consulte verbos y tipos de recursos. Para obtener más información sobre cómo crear políticas, consulte Creación de una política.
A-Admins y B-Admins pueden usar la familia de red virtual en el compartimento Networks. Sin embargo, no pueden crear instancias en ese compartimento. Solo pueden crear instancias en el compartimento Project-A o Project-B. Recuerde que un compartimento es una agrupación lógica, no física, de manera que los recursos que integran o residen en la misma VCN pueden pertenecer a distintos compartimentos.
La compañía Acme desea permitir a los administradores de los compartimentos Project-A y Project-B decidir qué usuarios pueden utilizar los recursos en esos compartimentos. Por lo tanto, Wenpei crea dos grupos más: A-Users y B-Users. A continuación, Wenpei agrega seis sentencias más que conceden a los administradores de compartimento el acceso necesario para agregar y eliminar usuarios de esos grupos:
Allow group A-Admins to use users in tenancy where target.group.name='A-Users'
Allow group A-Admins to use groups in tenancy where target.group.name='A-Users'
Allow group B-Admins to use users in tenancy where target.group.name='B-Users'
Allow group B-Admins to use groups in tenancy where target.group.name='B-Users'
Allow group A-Admins,B-Admins to inspect users in tenancy
Allow group A-Admins,B-Admins to inspect groups in tenancyObserve que esta política no permite a los administradores del proyecto crear nuevos usuarios ni gestionar credenciales para los usuarios. Les permite decidir qué usuarios existentes pueden estar en los grupos A-Users y B-Users. Las dos últimas sentencias son necesarias para que A-Admins y B-Admins puedan mostrar todos los usuarios y grupos, y confirmar qué usuarios están en grupos determinados.
| Elemento | Descripción |
|---|---|
 |
Políticas asociadas al arrendamiento:
|
Un administrador crea nuevos usuarios
En este punto, Alex está en el grupo Administradores y ahora tiene acceso para crear nuevos usuarios. Así pues, aprovisiona a los usuarios Leslie, Jorge y Cheri y los coloca en los grupos NetworkAdmins, A-Admins y B-Admins, respectivamente. Alex también crea otros usuarios que los administradores de Project-A y Project-B colocarán en algún momento en los grupos A-Users y B-Users.
| Elemento | Descripción |
|---|---|
|
Políticas asociadas al arrendamiento:
|
El administrador de red configura la red
Leslie (del grupo NetworkAdmins) tiene acceso para gestionar virtual-network-family e instance-family en el compartimento Networks. Crea una red virtual en la nube (VCN) con una única subred en ese compartimento. También configura un gateway de Internet para la VCN y actualiza la tabla de rutas de la VCN para permitir el tráfico a través de ese gateway. Para probar la conectividad de la VCN con la red local, Leslie inicia una instancia en la subred de VCN. Como parte de la solicitud de inicio, debe especificar en qué compartimento debe residir la instancia. Especifica el compartimento Networks, que es el único al que tiene acceso. A continuación, confirma la conectividad de la red local a la VCN conectándose a la instancia a través de SSH desde la red local.
Leslie finaliza su instancia de prueba e informa a Jorge y a Cheri de que la VCN está activa y lista para utilizarse. Les comunica que sus compartimentos se denominan Project-A y Project-B, respectivamente. Para obtener más información sobre la configuración de una red en la nube, consulte Networking. Para obtener información sobre el inicio de instancias en la red, consulte Compute.
Los administradores de compartimento configuran sus compartimentos
Jorge y Cheri ahora necesitan configurar sus respectivos compartimentos. Cada administrador debe hacer lo siguiente:
- Iniciar instancias en su propio compartimento
- Colocar usuarios en su grupo "usuarios" (por ejemplo, A-Users)
- Decidir el tipo de acceso que proporcionará a estos usuarios y asociar una política a su compartimento.
Jorge y Cheri inician instancias en la subred de la VCN, en los compartimentos de su equipo correspondiente. Crean y asocian volúmenes en bloque a las instancias. Solo los administradores de compartimento pueden iniciar/finalizar instancias o asociar/desasociar volúmenes en bloque en los compartimentos de su respectivo equipo.
La topología de red y el acceso al compartimento son conceptos diferentes
Es importante entender la diferencia entre la topología de red de la VCN y el control de acceso que proporcionan los compartimentos. Las instancias que inició Jorge residen en la VCN desde un punto de vista de topología de red. Pero desde un punto de vista de acceso, se encuentran en el compartimento Project-A, no en el compartimento Networks donde está la VCN. Leslie (el administrador de Networks) no puede finalizar ni reiniciar las instancias de Jorge, ni iniciar otras nuevas en el compartimento Project-A. Sin embargo, Leslie controla la red de las instancias, de modo que controla el tráfico que se enviará a ellas. Si Jorge hubiera especificado el compartimento Networks en lugar del compartimento Project-A al iniciar sus instancias, se le habría denegado su solicitud. La historia es similar para Cheri y el compartimento Project-B.
Asimismo, es importante tener en cuenta que Wenpei y Alex en el grupo Administradores tienen acceso a los recursos dentro de los compartimentos porque tienen acceso para gestionar todos los tipos de recursos del arrendamiento. Los compartimentos heredan cualquier política asociada a su compartimento principal (el arrendamiento), por lo que el acceso de Administradores también se aplica a todos los compartimentos dentro del arrendamiento.
Luego, Jorge coloca varios usuarios, que creó Alex, en el grupo A-Users. Cheri hace lo mismo con B-Users.
A continuación, Jorge escribe una política que proporciona a los usuarios el nivel de acceso que necesitan en el compartimento Project-A.
Allow group A-Users to use instance-family in compartment Project-A
Allow group A-Users to use volume-family in compartment Project-A
Allow group A-Users to inspect virtual-network-family in compartment Networks
Esto les permite utilizar instancias existentes (con volúmenes en bloque asociados) que los administradores de compartimento ya han iniciado en el compartimento, así como pararlas, iniciarlas o reiniciarlas. No permite a A-Users crear/suprimir ni asociar/desasociar ningún volumen. Para proporcionar dicha capacidad, la política deberá incluir manage volume-family.
Jorge asocia esta política al compartimento Project-A. Cualquier usuario con capacidad para gestionar políticas en el compartimento ahora puede modificar o suprimir esta política. Ahora mismo, se trata solo del grupo A-Admins (y el grupo Administradores, que puede realizar cualquier tarea en el arrendamiento).
Cheri crea y asocia su propia política al compartimento de Project-B, de manera similar a la política de Jorge:
Allow group B-Users to use instance-family in compartment Project-B
Allow group B-Users to use volume-family in compartment Project-B
Allow group B-Users to inspect virtual-network-family in compartment Networks
Ahora los usuarios de A-Users y B-Users pueden trabajar con las instancias existentes y los volúmenes asociados en los compartimentos Project-A y Project-B, respectivamente. Este es el aspecto del código:
| Elemento | Descripción |
|---|---|
|
Políticas asociadas al arrendamiento:
|
 |
Política asociada y gestionada por Jorge:
|
 |
Política asociada y gestionada por Cheri:
|
Para obtener más información sobre las funciones básicas y avanzadas de las políticas, consulte Cómo funcionan las políticas. Para ver ejemplos de otras políticas típicas que puede utilizar la organización, consulte Políticas comunes.
Permitir a los administradores de copia de seguridad gestionar solo copias de seguridad.
Tipo de acceso: permite realizar todas las tareas con copias de seguridad de volúmenes, pero no crear ni gestionar volúmenes en sí. Esto es pertinente si desea tener un solo juego de administradores de copias de seguridad de volúmenes que gestione todas las copias en todos los compartimentos. La primera sentencia proporciona el acceso necesario al volumen del que se está realizando la copia de seguridad; la segunda sentencia permite la creación de la copia de seguridad (y la capacidad de suprimir copias de seguridad). La tercera sentencia permite la creación y gestión de políticas de copia de seguridad definidas por el usuario; la cuarta sentencia permite la asignación y eliminación de políticas de copia de seguridad.
Dónde crear la política: en el arrendamiento, para que el acceso se conceda fácilmente a todos los compartimentos mediante la herencia de políticas. Para reducir el ámbito de acceso a los volúmenes y las copias de seguridad de un compartimento concreto, especifique ese compartimento en lugar del arrendamiento.
Allow group VolumeBackupAdmins to use volumes in tenancy
Allow group VolumeBackupAdmins to manage volume-backups in tenancy
Allow group VolumeBackupAdmins to manage backup-policies in tenancy
Allow group VolumeBackupAdmins to manage backup-policy-assignments in tenancySi el grupo va a utilizar la consola, la siguiente política proporciona una mejor experiencia de usuario:
Allow group VolumeBackupAdmins to use volumes in tenancy
Allow group VolumeBackupAdmins to manage volume-backups in tenancy
Allow group VolumeBackupAdmins to inspect volume-attachments in tenancy
Allow group VolumeBackupAdmins to inspect instances in tenancy
Allow group VolumeBackupAdmins to manage backup-policies in tenancy
Allow group VolumeBackupAdmins to manage backup-policy-assignments in tenancyLas dos últimas sentencias no son necesarias para gestionar las copias de seguridad de volúmenes. Sin embargo, permiten que la consola muestre toda la información sobre un volumen determinado y las políticas de copia de seguridad disponibles.
Asociación de políticas
Asociación de políticas
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 Creación de una política.