Uso de etiquetas para gestionar el acceso
En este tema se describe cómo se pueden utilizar etiquetas en la política para definir el ámbito de acceso según las etiquetas aplicadas al solicitante o al destino de una llamada de autorización.
Acerca del control de acceso basado en etiquetas
Utilizando las condiciones y un juego de variables de etiqueta, puede escribir una política para definir el ámbito de acceso en función de las etiquetas que se han aplicado a un recurso. El acceso se puede controlar según una etiqueta que existe en el recurso de solicitud (grupo, grupo dinámico o compartimento) o en el destino de la solicitud (recurso o compartimento). El control de acceso basado en etiquetas proporciona flexibilidad adicional a las políticas ya que le permite definir políticas de acceso con etiquetas que abarcan compartimentos, grupos y recursos.
Si la organización decide crear políticas que utilicen etiquetas para gestionar el acceso, asegúrese de que dispone de los controles adecuados para gestionar quién puede aplicar etiquetas. Además, una vez activas las políticas, tenga en cuenta que la aplicación de etiquetas a un grupo, un usuario o un recurso puede otorgar acceso a los recursos.
Antes de crear una política que especifique una etiqueta en un destino o en un solicitante, asegúrese de que tiene en cuenta lo siguiente:
- todos los solicitantes potenciales (usuarios, grupos, grupos dinámicos) que llevan la etiqueta
- todos los recursos que llevan la etiqueta
Antes de aplicar una etiqueta a un recurso, asegúrese de que tiene en cuenta todas las políticas activas que incluyen la etiqueta y que podrían determinar quién tiene acceso al recurso.
Gestión del acceso mediante etiquetas aplicadas al recurso de solicitud
Puede controlar el acceso en función del valor de la etiqueta que se aplica a:
- un grupo (de usuarios) que solicita acceso
- un grupo dinámico (de instancias) que solicita acceso
- un compartimento en el que reside un recurso de un grupo dinámico
Mediante el uso de etiquetas en las sentencias de política para definir el ámbito de acceso, puede definir el acceso para varios grupos mediante una sola sentencia de política. También puede otorgar acceso y revocar el acceso de los grupos aplicando o eliminando etiquetas sin cambiar las políticas originales.
En la siguiente tabla se muestra la sintaxis básica de cada variable. Tenga en cuenta que la sintaxis es la misma para el grupo y para el grupo dinámico, pero cada una se presenta en una fila diferente. Consulte más ejemplos de uso en Operadores soportados.
| Etiqueta aplicada al solicitante | Sintaxis de variable | Descripción |
|---|---|---|
|
grupo |
request.principal.group.tag.{tagNamespace}.{tagKeyDefinition}= '<value>'
Política de ejemplo para un grupo de usuarios:
Cualquier usuario que pertenezca a un grupo que se haya etiquetado con Operations.Project='Prod' puede gestionar instancias en el compartimento HR. |
Las etiquetas aplicadas a los grupos a los que pertenece el usuario se evalúan para buscar una coincidencia. |
|
grupo dinámico |
request.principal.group.tag.{tagNamespace}.{tagKeyDefinition}= '<value>'
Política de ejemplo para un grupo dinámico:
Las instancias que son miembros del grupo dinámico InstancesA y que también son miembros de un grupo dinámico etiquetado con Operations.Project='Prod' pueden gestionar instancias en el compartimento HR. |
Las etiquetas aplicadas a los grupos dinámicos a los que pertenece la instancia se evalúan para buscar una coincidencia. |
|
compartimento |
request.principal.compartment.tag.{tagNamespace}.{tagKeyDefinition}= '<value>'
Política de ejemplo:
Las instancias que son miembros del grupo dinámico InstancesA y que también residen en un compartimento etiquetado con Operations.Project='Prod' pueden gestionar instancias en el arrendamiento. |
Se evalúan las etiquetas aplicadas al compartimento al que pertenece el recurso de solicitud. |
Los usuarios residen en el compartimento raíz de su arrendamiento, por lo que las etiquetas se deben aplicar al compartimento raíz para que las sentencias de política funcionen.
Gestión de acceso mediante etiquetas aplicadas al recurso de destino
Puede controlar el acceso en función del valor de la etiqueta que se aplica a:
- un recurso
- un compartimento en el que reside el recurso de destino
En la siguiente tabla se muestra la sintaxis básica de estas variables. Consulte más ejemplos de uso en Operadores soportados.
| Etiqueta aplicada al destino | Sintaxis de variable | Descripción |
|---|---|---|
|
recurso |
target.resource.tag.{tagNamespace}.{tagKeyDefinition}='<value>'
Política de ejemplo:
|
Se evalúa la etiqueta aplicada al recurso de destino de la solicitud. Existen limitaciones para los permisos que se pueden otorgar en este tipo de política. Consulte las siguientes secciones de este tema para obtener más información. |
|
compartimento |
target.resource.compartment.tag.{tagNamespace}.{tagKeyDefinition}='<value>'
Política de ejemplo:
|
Se evalúa la etiqueta aplicada al compartimento de destino de la solicitud. Consulte Jerarquías de compartimentos para obtener más información sobre cómo se otorga el acceso en compartimentos anidados. |
Los permisos para mostrar un recurso se deben otorgar por separado
Las políticas que delimitan el ámbito de acceso según la etiqueta aplicada al recurso de destino no pueden permitir los permisos que le permiten devolver una lista de recursos. Por lo tanto, los permisos para permitir que se muestre un recurso se deben otorgar mediante una sentencia de política adicional. Esto significa que si ha definido una política como la siguiente:
allow group GroupA to manage all-resources in compartment Operations where target.resource.tag.Operations.Project= 'Prod'
GroupA no podrá mostrar ninguno de los recursos que, por otro lado, se le permite gestionar. Los miembros de GroupA no podrían utilizar la consola para interactuar con estos recursos, y los usuarios necesitarían conocer el OCID del recurso que intentan gestionar, lo que hace que el uso del SDK y la CLI sea también complicado.
Para permitir que GroupA muestre esos recursos, debe agregar otra sentencia de política como la siguiente:
allow group GroupA to inspect all-resources in compartment Operations
Este enfoque mejora la política basada en etiquetas porque permite a los usuarios utilizar la consola de forma más sencilla (permitiéndoles ver el recurso que desean gestionar), pero sigue limitando los permisos solo a la inspección. Los miembros de GroupA no pueden realizar ninguna acción en esos recursos a menos que estén etiquetados correctamente. Tenga en cuenta que, al utilizar el control de acceso basado en etiquetas, la flexibilidad agregada requiere esta posible ampliación adicional del acceso.
Otro enfoque que puede utilizar para evitar esta limitación es etiquetar los compartimentos que contengan los recursos a los que desea otorgar acceso. Un ejemplo de política sería similar al siguiente:
allow group GroupA to manage all-resources in tenancy where target.resource.compartment.tag.Operations.Project= 'Prod'Esta política permite a los miembros de GroupA gestionar todos los recursos del arrendamiento que están en compartimientos etiquetados con la etiqueta Operations.Project='Prod'.
Las políticas que requieren una etiqueta en el recurso de destino no pueden otorgar permisos de creación
Al escribir una política para definir el ámbito de acceso según el valor de una etiqueta en el recurso, tenga en cuenta que la política no puede otorgar permisos de creación. Una solicitud para crear una instancia provocaría un fallo porque el recurso de destino aún no se ha creado y, por lo tanto, no tiene la etiqueta adecuada para que se pueda evaluar. Por lo tanto, una política como la siguiente:
allow group GroupA to manage instances in compartment Operations where target.resource.tag.Operations.Project='Prod'
permite a los miembros de GroupA utilizar y suprimir instancias etiquetadas con Operations.Project='Prod', pero no pueden crear instancias.
Operadores soportados
La política que utiliza estas variables de etiqueta, puede incluir los siguientes operadores y tipos de coincidencia:
| Operador | Tipo | Ejemplo | Descripción |
|---|---|---|---|
| = | Cadena | request.principal.group.tag.MyTagNamespace.MyTag='sample'
|
Se evalúa como true si cualquiera de los grupos a los que pertenece el solicitante está etiquetado con el valor coincidente "sample" para MyTagNamespace.MyTag. (El valor no es sensible a mayúsculas/minúsculas). |
| Patrón | request.principal.group.tag.MyTagNamespace.MyTag=/*sample/
|
Se evalúa como true si cualquiera de los valores de MyTagNamespace.MyTag termina en "sample". (Coincidencia de patrón simple no sensible a mayúsculas/minúsculas). | |
| Variable de política | request.principal.group.tag.mytagnamespace.mytag = target.resource.tag.mytagnamespace.mytag |
Se evalúa como true cuando el recurso especificado mytagnamespace.mytag tiene un valor que coincide con el destino especificado mytagnamespace.tag. | |
| != | Cadena | request.principal.group.tag.MyTagNamespace.MyTag !='sample'
|
Se evalúa como true si ninguno de los valores de cadena de la variable de política es igual a "sample". (Comparación de cadenas no sensibles a mayúsculas/minúsculas simples). |
| Patrón | request.principal.group.tag.MyTagNamespace.MyTag !=/*sample/
|
Se evalúa como true si ninguno de los valores de MyTagNamespace.MyTag termina en "sample". (Coincidencia de patrón simple no sensible a mayúsculas/minúsculas). | |
| Variable de política | request.principal.group.tag.mytagnamespace.mytag != target.resource.tag.mytagnamespace.mytag |
Se evalúa como true si ninguna de las partes es un subjuego de la otra. |
In / Not In
| Operador | Tipo | Ejemplo | Descripción |
|---|---|---|---|
| in | Cadena | request.principal.group.tag.MyTagNamespace.MyTag in ('sample', 'sample1')
|
La cláusula se evalúa como true si cualquiera de los valores de MyTagNamespace.MyTag para cualquier grupo del principal de solicitud actual es igual a "sample" o a "sample1". |
| Patrón | request.principal.group.tag.MyTagNamespace.MyTag in (/*sample/, /sample1*/)
|
La cláusula se evalúa como true si cualquiera de los valores de MyTagNamespace.MyTag para cualquier grupo del principal de solicitud actual termina en "sample" o empieza por "sample1". | |
| Variable de política | request.principal.group.tag.MyTagNamespace.MyTag in (target.resource.tag.mytagnamespace.mytag, 'sample') |
La cláusula se evalúa como true si se cumple alguna de las siguientes condiciones: 1 request.principal.group.tag.MyTagNamespace.MyTag o target.resource.tag.mytagnamespace.mytag es un subjuego del otro. 2. Cualquier valor de cadena de request.principal.group.tag.MyTagNamespace.MyTag es igual a "sample". |
|
| not in | Cadena | request.principal.group.tag.MyTagNamespace.MyTag not in ('sample', 'sample1')
|
La cláusula se evalúa como true si ninguno de los valores de MyTagNamespace.MyTag para cualquier grupo del principal de solicitud actual es igual a "sample" o "sample1". |
| Patrón | request.principal.group.tag.MyTagNamespace.MyTag not in (/*sample/, /sample1*/)
|
La cláusula se evalúa como true si ninguno de los valores de MyTagNamespace.MyTag para cualquier grupo del principal de solicitud actual termina en "sample" o empieza por "sample1". | |
| Variable de política | request.principal.group.tag.MyTagNamespace.MyTag not in (target.resource.tag.mytagnamespace.mytag, 'sample')
|
La cláusula se evalúa como verdadera si se cumplen todas las condiciones siguientes: 1. Ni la etiqueta request.principal.group.tag.MyTagNamespace.MyTag ni target.resource.tag.mytagnamespace.my es un subjuego de la otra. 2. Ninguno de los valores de cadena de request.principal.group.tag.MyTagNamespace.MyTag es igual a "sample". |
Soporte de comodines
Puede utilizar el carácter * para que coincida con todas las ocurrencias de {tagNamespace}. {tagKeyDefinition} con independencia del valor. En la política, puede colocar * entre comillas simples '*' o entre barras invertidas /*/. Por ejemplo,
allow group GroupA to use all-resources in compartment HR where target.resource.tag.HR.Project= '*'
En este ejemplo, GroupA puede utilizar todos los recursos del compartimento HR que estén etiquetados con el espacio de nombre de etiqueta y la clave de etiqueta: HR.Project con cualquier valor.
Limitaciones de caracteres en espacios de nombre de etiqueta y definiciones de clave de etiqueta utilizados en variables de política
Los espacios de nombre de etiqueta y las definiciones de clave de etiqueta soportan un juego de caracteres más amplio que el permitido en las variables de política. Por lo tanto, para utilizar espacios de nombre de etiqueta y definiciones de clave de etiqueta en variables, asegúrese de que solo se incluyen los caracteres también soportados por las variables de política. Los caracteres soportados son:
a-z, A-Z, 0-9, _, @,-,:
Si los espacios de nombre de etiqueta o las claves de etiqueta tienen caracteres distintos de estos, no podrá utilizarlos en las variables de política. No se puede cambiar el nombre de los espacios de nombre de etiqueta ni de las claves de etiqueta, por lo que tendrá que crear nuevos espacios de nombre de etiqueta y definiciones de clave de etiqueta.
Consideraciones sobre las mayúsculas/minúsculas
Al trabajar con etiquetas en las políticas, tenga en cuenta que los valores de etiqueta no distinguen entre mayúsculas/minúsculas. Por ejemplo:
request.principal.group.tag.MyTagNamespace.MyTag='sample'
es igual que
request.principal.group.tag.MyTagNamespace.MyTag='Sample'
Jerarquías de compartimentos
Al escribir una condición para permitir el acceso según la etiqueta aplicada a un compartimento de destino, recuerde que esta política también permite el acceso a todos los compartimentos anidados dentro del compartimento etiquetado. Todos los subcompartimentos del compartimento etiquetado son recursos del compartimento etiquetado y, por lo tanto, la política otorga acceso.
Por ejemplo, en este escenario:
La política:
allow group GroupA to use all-resources in tenancy where target.resource.compartment.Operations.Project='ProjectA'permite a GroupA utilizar todos los recursos de CompartmentA, CompartmentA1 y CompartmentA1.1, aunque la etiqueta se aplique sólo a CompartmentA.
Servicios admitidos
Todos los servicios de Oracle Cloud Infrastructure admiten las variables de política request.principal.compartment, request.principal.group y target.resource.compartment.tag.
No todos los servicios admiten la variable de política target.resource.tag. En la siguiente tabla se muestran los servicios admitidos. Si el servicio no figura en la tabla, quiere decir que no se admite en este momento.
Algunos servicios tienen limitaciones. Consulte el enlace adecuado en la tabla.
| Servicios soportados | Más información |
|---|---|
| API Gateway | Consulte Limitaciones del servicio API Gateway. |
| Big Data Service | Consulte Limitaciones del servicio Big Data. |
| Blockchain Platform | Completamente soportado, sin limitaciones. |
| Block Volume | Consulte Limitaciones del servicio Block Volume. |
| Certificados | Completamente soportado, sin limitaciones. |
| Compute | Consulte Limitaciones del servicio Compute. |
| Gestión de recursos informáticos | Consulte Limitaciones de Compute Management. |
| Content Management | Consulte Limitaciones de Content Management. |
| Data Catalog | Consulte Limitaciones del servicio Data Catalog. |
| Data Flow | Completamente soportado, sin limitaciones. |
| Data Science | Consulte Limitaciones del servicio Data Science. |
| Database | Consulte Limitaciones del servicio Database. |
| Digital Assistant | Consulte Limitaciones de Digital Assistant. |
| DNS | Consulte Limitaciones de DNS público. |
| Email Delivery | Completamente soportado, sin limitaciones. |
| FastConnect | Completamente soportado, sin limitaciones. |
| Funciones | Completamente soportado, sin limitaciones. |
| Health Checks | Completamente soportado, sin limitaciones. |
| IAM | Los recursos soportados son: users, groups, policies, dynamic-groups, network-sources y identity-providers |
| equilibrador de carga | Consulte Limitaciones del servicio Load Balancing. |
| HeatWave | Completamente soportado, sin limitaciones. |
| Red | Consulte Limitaciones del servicio Networking. |
| NoSQL Database Cloud | Consulte Limitaciones del servicio Networking. |
| Notifications | Completamente soportado, sin limitaciones. |
| Object Storage | Consulte Limitaciones del servicio Object Storage. |
| Servicio de cuotas | Completamente soportado, sin limitaciones. |
| Espacio de nombres de Tagging | Consulte Limitaciones del espacio de nombres de Tagging. |
| Vault | Cifrado no soportado. |
| WAF | Consulte Limitaciones de WAF. |
Limitaciones y políticas adicionales necesarias para casos Target.Resource.Tag específicos
Para algunos servicios, no están soportados todos los permisos o tipos de recursos. Si un permiso no está soportado, significa que incluso si el recurso está etiquetado y el permiso está incluido en el verbo que otorga acceso, dicho permiso no está permitido y falla la autorización para la operación gestionada por el permiso. Por ejemplo, el recurso volume-backups del servicio de volumen en bloque no soporta el control de acceso basado en etiquetas para el permiso VOLUME_BACKUP_COPY. Por lo tanto, esta política:
allow group TestGroup to manage volume-backups in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'no permite a los miembros del grupo TestGroup realizar la operación CopyVolumeBackup. Para otorgar este permiso a TestGroup, debe agregar otra sentencia de política que lo cubra.
Además, algunos casos operativos requieren autorización para acceder a varios recursos. Al definir el ámbito de acceso a las etiquetas que se aplican al recurso de destino, debe incluir una política independiente para cada recurso implicado en la operación. Además, debido a las limitaciones para mostrar los recursos y otros permisos específicos del servicio, se necesitan políticas adicionales (sin el ámbito definido por etiqueta).
Limitaciones del servicio API Gateway
Además de la política de control de acceso basada en etiquetas esperada para los recursos de API Gateway, necesitará una política que conceda permisos de gestión para api-workrequests.
A continuación, se muestra un ejemplo de política con los permisos adicionales:
allow group TestGroup to manage api-workrequests in compartment Compartment1Limitaciones del servicio Big Data
Además de la política de control de acceso basada en etiquetas esperada para los recursos de Big Data Service, necesitará una política que conceda permisos de gestión para cluster-work-requests.
A continuación, se muestra un ejemplo de política con los permisos adicionales:
allow group TestGroup to manage cluster-work-requests in compartment Compartment1Limitaciones del servicio de volumen en bloque
| Servicio | Tipo de recurso con limitaciones | Permisos no soportados con la variable de política target.resource.tag |
|---|---|---|
| Block Volume | backup-policy-assignments
|
BACKUP_POLICY_ASSIGNMENT_DELETE |
volume-backups
|
VOLUME_BACKUP_COPY |
Casos que requieren una política adicional:
Asociación de un volumen en bloque a una instancia informática:
Para asociar un volumen en bloque a una instancia informática, además de la política de control de acceso basado en etiquetas, para permitir el verbo use en volúmenes e instancias, necesitará permisos adicionales.
Por ejemplo:
allow group TestGroup to use volumes in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'
allow group TestGroup to use instances in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'Estas dos políticas permiten a los miembros de TestGroup utilizar volúmenes e instancias en Compartment1 cuando los recursos tienen la etiqueta adecuada. Para permitir que los miembros asocien un volumen en bloque a una instancia, también necesitará políticas que permitan los permisos que se muestran en las siguientes sentencias:
allow group TestGroup to read instances in compartment Compartment1
allow group TestGroup to manage volume-attachments in compartment Compartment1 where any {request.permission='VOLUME_ATTACHMENT_CREATE', request.permission='VOLUME_ATTACHMENT_DELETE'}Limitaciones del servicio Compute
| Servicio | Tipo de recurso | Permisos no soportados con la variable de política target.resource.tag |
|---|---|---|
| Compute | instance-console-connection
|
INSTANCE_CONSOLE_CONNECTION_DELETE |
instances
|
INSTANCE_POWER_ACTIONS |
Casos que requieren una política adicional:
Asocie la instancia informática a la subred:
Para gestionar la asociación de subred de una instancia informática, además de la política de control de acceso basada en etiquetas esperada para instances y subnets que se muestra a continuación:
allow group TestGroup to use subnets in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'
allow group TestGroup to manage instances in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'Necesitará permisos adicionales para vnics:
allow group TestGroup to use vnics in compartment Compartment1 where ANY{request.permission='VNIC_ATTACH', request.permission='VNIC_CREATE'}Suprima una VNIC de una instancia informática:
Para suprimir una VNIC de una instancia informática, además de la política de control de acceso basada en etiquetas esperada para instances y subnets que se muestra a continuación:
allow group TestGroup to manage instances in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'
allow group TestGroup to use subnets in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'Necesitará una política que le otorgue permisos sobre vnics:
allow group TestGroup to use vnics in compartment Compartment1 where ANY {request.permission='VNIC_DELETE', request.permission='VNIC_DETACH'}Limitaciones de Compute Management
| Servicio | Tipo de recurso | Permisos no soportados con la variable de política target.resource.tag | Notas |
|---|---|---|---|
| Gestión de recursos informáticos | instance-pools
|
Todos los permisos | El tipo de recurso instance-pools no está soportado. |
auto-scaling-configurations
|
AUTO_SCALING_CONFIGURATION_UPDATE | . |
Limitaciones de Content Management
Además de la política de control de acceso basada en etiquetas esperada para los recursos de gestión de contenido, necesitará una política que otorgue permisos de gestión para oce-work-requests.
A continuación, se muestra un ejemplo de política con los permisos adicionales:
allow group TestGroup to manage oce-requests in compartment Compartment1Limitaciones del servicio Database
| Servicio | Tipo de recurso | Permisos no soportados con la variable de política target.resource.tag |
|---|---|---|
| Database | all
|
DATABASE_DELETE |
Actualizar etiquetas para infraestructura de ExaData:
No está soportado en este momento mediante políticas de control de acceso basadas en etiquetas.
Casos que requieren una política adicional:
Suprimir un sistema de base de datos:
Para suprimir o actualizar un sistema de base de datos, además de la política de control de acceso basada en etiquetas esperada para db-systems que se muestra a continuación:
allow group TestGroup to manage db-systems in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'Necesitará una política que le otorgue permisos para db-backups, db-homes, vnics, subnets y databases. A continuación, se muestra una política de ejemplo con los permisos adicionales:
allow group TestGroup to manage db-backups in compartment Compartment1 where ANY {request.permission='DB_BACKUP_DELETE', request.permission='DB_BACKUP_INSPECT'}
allow group TestGroup to manage db-homes in compartment Compartment1 where request.permission='DB_HOME_DELETE'
allow group TestGroup to manage vnics in compartment Compartment1 where ANY {request.permission='VNIC_DELETE', request.permission='VNIC_DETACH'}
allow group TestGroup to manage subnets in compartment Compartment1 where request.permission='SUBNET_DETACH'
allow group TestGroup to manage databases in compartment compartment1Mover un sistema de base de datos a otro compartimento:
Para mover un sistema de base de datos a otro compartimento, además de la política de control de acceso basado en etiquetas esperada para db-systems que se muestra a continuación:
allow group TestGroup to manage db-systems in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'Necesitará una política que le otorgue permisos para databases, db-homes y db-backups. A continuación, se muestra un ejemplo de política con los permisos adicionales:
allow group TestGroup to use databases in compartment Compartment1 where request.permission='DATABASE_UPDATE'
allow group TestGroup to manage db-backups in compartment Compartment1 where request.permission='DB_BACKUP_INSPECT'
allow group TestGroup to manage db-homes in compartment Compartment1 where request.permission='DB_HOME_UPDATE'Supresión de base de datos para el sistema de base de datos Exadata:
Para suprimir un recurso de base de datos para un sistema de base de datos Exadata, necesitará la política de control de acceso basada en etiquetas esperada para db-systems y databases que se muestra a continuación:
allow group TestGroup to manage db-systems in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'
allow group TestGroup to manage databases in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'También necesitará permisos para db-homes y db-backups. A continuación, se muestra un ejemplo de política con los permisos adicionales:
allow group TestGroup to manage db-homes in compartment Compartment1 where request.permision='DB_HOME_UPDATE'
allow group TestGroup to manage db-backups in compartment Compartment1 where ANY {request.permission='DB_BACKUP_DELETE', request.permission='DB_BACKUP_INSPECT'}Suprimir base de datos:
La supresión de una base de datos para un sistema de base de datos de máquina virtual o con hardware dedicado no está soportada utilizando políticas basadas en etiquetas en el recurso de destino.
Creación de copia de seguridad de base de datos:
Para crear una copia de seguridad de la base de datos, necesitará la política de control de acceso basado en etiquetas esperada para databases:
allow group TestGroup to manage databases in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'También necesitará permisos para db-backups. A continuación, se muestra un ejemplo de política con los permisos adicionales:
allow group TestGroup to manage db-backups in compartment Compartment1 where request.permission='DB_BACKUP_CREATE'Restauración de base de datos:
Para restaurar una copia de seguridad de la base de datos, necesitará la política de control de acceso basado en etiquetas esperada para databases:
allow group TestGroup to manage databases in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'También necesitará permisos para backups, como el que se muestra a continuación:
allow group TestGroup to manage db-backups in compartment Compartment1 where ANY {request.permission='DB_BACKUP_INSPECT', request.permission='DB_BACKUP_CONTENT_READ'}Crear asociación de Data Guard:
La creación de una asociación de Data Guard no está soportada utilizando políticas basadas en etiquetas en el recurso de destino.
Limitaciones del servicio Data Catalog
Además de la política de control de acceso basada en etiquetas esperada para los recursos de Data Catalog, necesitará las siguientes políticas adicionales para data-catalog-family:
allow group resource_managers to read data-catalog-family in tenancy where request.operation = 'GetWorkRequest'
allow group resource_managers to read data-catalog-family in tenancy where request.operation = 'ListWorkRequestErrors'
allow group resource_managers to read data-catalog-family in tenancy where request.operation = 'listworkrequestlogs'Limitaciones del servicio Data Science
Además de la política de control de acceso basada en etiquetas esperada para los recursos de Data Science, necesitará una política que conceda permisos de gestión para data-science-work-requests.
A continuación, se muestra un ejemplo de política con los permisos adicionales:
allow group TestGroup to manage data-science-work-requests in compartment Compartment1Limitaciones de Digital Assistant
| Servicio | Tipo de recurso | Permisos no soportados con la variable de política target.resource.tag |
|---|---|---|
| Digital Assistant | oda-design
|
Todos los permisos |
oda-insights
|
Todos los permisos |
Además de la política de control de acceso basada en etiquetas esperada para los recursos de Oracle Digital Assistant, necesitará las siguientes políticas adicionales para oda-instances:
allow group TestGroup to inspect oda-instances in compartment Compartment1
allow group TestGroup to read oda-instances in compartment Compartment1 request.operation = 'GetWorkRequest'
allow group TestGroup to read oda-instances in compartment Compartment1 request.operation = 'ListWorkRequestErrors'
allow group TestGroup to read oda-instances in compartment Compartment1 request.operation = 'listworkrequestlogs'Limitaciones del servicio de equilibrio de carga
Casos que requieren una política adicional:
Actualizar equilibrador de carga:
Para realizar cualquier actualización en los equilibradores de carga, además de la política de control de acceso basado en etiquetas esperada para load-balancers:
allow group TestGroup to manage load-balancers in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'Necesitará una política que permita la operación de API GetWorkRequest. A continuación, se muestra un ejemplo de política con el permiso adicional:
allow group TestGroup to read load-balancers in compartment Compartment1 where request.operation = 'GetWorkRequest'
network-security-groupSuprimir equilibrador de carga:
Para suprimir un equilibrador de carga, además de la política de control de acceso basada en etiquetas esperada para load-balancers, subnets y network-security-group:
allow group TestGroup to manage load-balancers in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'
allow group TestGroup to use subnets in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'
allow group TestGroup to use network-security-group in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'Necesitará estos permisos adicionales para vnics:
allow group TestGroup to use vnics in compartment Compartment1 where ANY {request.permission = 'VNIC_DETACH', request.permission = 'VNIC_DELETE', request.permission='VNIC_DISASSOCIATE_NETWORK_SECURITY_GROUP'}Limitaciones del servicio Networking
| Servicio | Tipo de recurso | Permisos no soportados con la variable de política target.resource.tag | Notas |
|---|---|---|---|
| Red | private-ips
|
PRIVATE_IP_UPDATE PRIVATE_IP_DELETE VNIC_UNASSIGN SUBNET_DETACH |
|
route-tables
|
UPDATE (INTERNET_GATEWAY_DETACH) | La eliminación de una regla de ruta no está soportada. | |
vnics
|
VNIC_UPDATE VNIC_DELETE |
Asociación de gateway de servicio o gateway de NAT a una tabla de rutas:
La asociación de un gateway de servicio o un gateway de NAT a una tabla de rutas mediante políticas basadas en etiquetas no está soportada en el recurso de destino.
Casos que requieren una política adicional:
Asociar DRG a VCN:
Para asociar DRG a VCN, además de la siguiente política de control de acceso basada en etiquetas esperada para virtual-network-family y vcns:
allow group TestGroup to use virtual-network-family in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'
Necesitará una política que le otorgue permisos manage para drgs. A continuación, se muestra un ejemplo de política con los permisos adicionales:
allow group TestGroup to manage drgs in compartment Compartment1
Limitaciones del servicio NoSQL Database Cloud
Los recursos soportados son: nosql-tables, nosql-rows y nosql-indexes.
Además de la política de control de acceso basada en etiquetas esperada para los recursos de NoSQL Database Cloud, necesitará estas políticas adicionales:
allow group TestGroup to read nosql-tables in compartment Compartment1 where request.operation='ListWorkRequests'allow group TestGroup to read nosql-tables in compartment Compartment1 where request.operation='ListWorkRequestErrors'allow group TestGroup to read nosql-tables in compartment Compartment1 where request.operation='ListWorkRequestLogs'Tenga en cuenta que las políticas anteriores son necesarias para navegar por los recursos de NoSQL Database Cloud en la consola.
Limitaciones del servicio de almacenamiento de objetos
| Servicio | Tipo de recurso | Permisos no soportados con la variable de política target.resource.tag | Notas |
|---|---|---|---|
| Object Storage | objects
|
Todos los permisos relacionados con el acceso a objects |
Los objetos no se pueden etiquetar. |
El acceso a los objetos se puede gestionar mediante las etiquetas del cubo al que pertenecen los objetos. Utilice la variable de política
target.bucket.tag. Consulte Permitir a los usuarios escribir objetos en cubos de Object Storage.Limitaciones de DNS público
Además de la política de control de acceso basada en etiquetas esperada para los recursos de dns, necesitará una política que le permita realizar manage en permisos para dns-records. A continuación, se muestra un ejemplo de política con los permisos adicionales:
allow group TestGroup to manage dns-records in compartment Compartment1Limitaciones del espacio de nombres de Tagging
La política que otorga a un usuario acceso a un espacio de nombres de etiqueta basándose en una etiqueta del espacio de nombres no permite al usuario crear ni suprimir definiciones de clave de etiqueta en ese espacio de nombres de etiqueta.
Por ejemplo, la política:
allow group TestGroup to manage tag-namespaces in compartment Compartment1 where target.resource.tag.TagNS.TagKey='test'no permite a los usuarios de TestGroup crear ni suprimir definiciones de clave de etiqueta en los espacios de nombres de etiquetas etiquetados con TagNS.TagKey='test'.
Limitaciones de WAF
Además de la política de control de acceso basada en etiquetas esperada para los recursos de WAF, necesitará una política que le conceda permisos de gestión para waas-work-request. A continuación, se muestra un ejemplo de política con los permisos adicionales:
allow group TestGroup to manage waas-work-request in compartment Compartment1Ejemplos ilustrados
Ejemplo de uso de etiquetas aplicadas a un grupo
En el ejemplo siguiente, se muestra cómo puede utilizar etiquetas aplicadas a grupos de usuarios para gestionar el acceso a los recursos de un compartimento.
Supongamos que tiene tres compartimentos: ProjectA, ProjectB y ProjectC
Para cada compartimento, hay un grupo de administradores configurado: A-Admins, B-Admins y C-Admins.
Cada grupo de administradores tiene acceso completo a su compartimento mediante las siguientes políticas:
allow group A-Admins to manage all-resources in compartment ProjectAallow group B-Admins to manage all-resources in compartment ProjectBallow group C-Admins to manage all-resources in compartment ProjectC
Su organización ha configurado el siguiente espacio de nombre y clave de etiqueta para etiquetar cada grupo por su rol:
- EmployeeGroup.Role
Algunos valores de esta etiqueta son 'Admin', 'Developer', 'Test-Engineer'.
Todos sus grupos de administradores están etiquetados con EmployeeGroup.Role='Admin'
A continuación, desea configurar un compartimento Test para que lo compartan los miembros de los tres proyectos. Desea otorgar acceso de administrador a los tres grupos de administradores existentes. Para ello, puede escribir una política como la siguiente:
allow any-user to manage all-resources in compartment Test where request.principal.group.tag.EmployeeGroup.Role='Admin'
Con esta política, todos los grupos de administradores existentes con la etiqueta tendrán acceso al compartimento Test. Además, cualquier grupo nuevo o existente que etiquete con EmployeeGroup.Role='Admin' en el futuro tendrá acceso al compartimento Test sin tener que actualizar las sentencias de política.
Ejemplo de uso de etiquetas aplicadas a un recurso de destino
En este ejemplo, cada uno de los compartimentos de proyecto de la organización contiene dos compartimentos secundarios: Test y Prod. Desea proporcionar a los ingenieros de prueba acceso a los compartimentos de prueba en los tres proyectos. Para ello, debe crear una etiqueta:
ResourceGroup.Role='Test'
y aplicarla a los compartimentos Test de cada uno de los compartimentos del proyecto.
A continuación, puede utilizar una política como la siguiente:
allow group Testers to use all-resources in tenancy where target.resource.compartment.tag.ResourceGroup.Role='Test'
para permitir que los comprobadores del grupo accedan a los recursos de los tres compartimentos de prueba.