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.

Atención

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:

allow any-user to manage instances in compartment HR where request.principal.group.tag.Operations.Project= 'Prod'

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:

allow dynamic-group InstancesA to manage instances in compartment HR where request.principal.group.tag.Operations.Project= 'Prod'

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:

allow dynamic-group InstancesA to manage instances in tenancy where request.principal.compartment.tag.Operations.Project= 'Prod'

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.

Nota

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:

allow group GroupA to manage all-resources in compartment HR where target.resource.tag.Operations.Project= 'Prod'

 

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:

allow group GroupA to manage all-resources in tenancy where target.resource.compartment.tag.Operations.Project= 'Prod'

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.my 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:

Compartimentos anidados CompartmentA, CompartmentA1, CompartmentA1.1

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.
Servicio de migración clásico Completamente soportado, sin limitaciones.
Big Data Service Consulte Limitaciones del servicio Big Data.
Blockchain Platform Completamente soportado, sin limitaciones.
Volumen en bloque Consulte Limitaciones del servicio Block Volume.
Recursos informáticos Consulte Limitaciones del servicio Compute.
Gestión de recursos informáticos Consulte Limitaciones de Compute Management.
Gestión de contenido 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.
Base de datos Consulte Limitaciones del servicio Database.
Digital Assistant Consulte Limitaciones de Digital Assistant.
DNS Consulte Limitaciones de DNS público.
Entrega de correo electrónico Completamente soportado, sin limitaciones.
FastConnect Completamente soportado, sin limitaciones.
Functions 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.
MySQL Database Completamente soportado, sin limitaciones.
Redes Consulte Limitaciones del servicio Networking.
NoSQL Database Cloud Consulte Limitaciones del servicio Networking.
Notifications Completamente soportado, sin limitaciones.
Almacenamiento de objetos 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.
Almacén de claves 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 Compartment1

Limitaciones del servicio Big Data

Además de la política de control de acceso esperada basada en etiquetas para los recursos de Big Data Service, necesitará una política que otorgue 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 Compartment1

Limitaciones del servicio de volumen en bloque

Servicio Tipo de recurso con limitaciones Permisos no soportados con la variable de política target.resource.tag
Volumen en bloque 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
Compute Management 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 Content Management, necesitará una política que permita gestionar permisos 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 Compartment1

Limitaciones del servicio Database

Servicio Tipo de recurso Permisos no soportados con la variable de política target.resource.tag
Base de datos 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:

Supresión de 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 compartment1

Mover 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'}

Supresión de 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 Compartment1

Limitaciones 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:

Actualización de 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-group

Supresión de 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
Networking 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.
Nota

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 Compartment1

Limitaciones 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 Compartment1

Ejemplos 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

Compartimentos ProjectA, ProjectB, 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 ProjectA
  • allow group B-Admins to manage all-resources in compartment ProjectB
  • allow group C-Admins to manage all-resources in compartment ProjectC

Compartimentos ProjectA, ProjectB, ProjectC con políticas y grupos de administradores asociados

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'

Grupos de administradores con la etiqueta EmployeeGroup.Role='Admin' aplicada

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'

Compartimento Test con política basada en etiquetas

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.

Tres proyectos, cada uno con un compartimento de prueba etiquetado con ResourceGroup.Role='Test'

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.