Ejemplos de políticas

Utilice los siguientes ejemplos para obtener más información sobre las políticas de IAM en Data Integration.

La sintaxis general de una sentencia de política es:

allow <subject> to <verb> <resource-type> in <location> where <condition>

Para obtener una descripción de cada variable, consulte Sintaxis de políticas.

Nota

Después de agregar componentes de IAM (por ejemplo, grupos dinámicos y sentencias de política), no intente realizar las tareas asociadas inmediatamente. Las nuevas políticas de IAM requieren entre cinco y 10 minutos para que se apliquen.

Para exportar e importar objetos, consulte Activar Exportación e Importación de Espacio de Trabajo y Objetos en Espacio de Trabajo.

Revise también las políticas de Oracle Cloud Infrastructure (OCI) Data Integration del blog para identificar las políticas que necesita.

Ejemplos de políticas para permitir el acceso a Data Integration y usar espacios de trabajo

Para utilizar espacios de trabajo de Data Integration, debe crear políticas.

Activación del uso de red privada en espacios de trabajo

Para utilizar conexiones de red privadas a los orígenes de datos, debe otorgar permiso a Data Integration para gestionar las redes virtuales que ha configurado para la integración.

Sin la siguiente política, la integración de datos falla.

allow service dataintegration to use virtual-network-family in compartment <compartment-name>

Para otorgar permiso a un grupo para gestionar los recursos de red en un compartimento:

allow group <group-name> to manage virtual-network-family in compartment <compartment-name>

Para usuarios que no sean administradores:

allow group <group-name> to use virtual-network-family in compartment <compartment-name>
allow group <group-name> to inspect instance-family in compartment <compartment-name>

Activación del acceso a la lista de usuarios y compartimentos

Para otorgar permiso a Data Integration para mostrar usuarios y compartimentos, puede utilizar inspect.

allow service dataintegration to inspect users in tenancy
allow group <group-name> to inspect compartments in compartment <target-compartment-name>
Activación de acceso para ver espacios de trabajo

Para permitir que un grupo vea la lista de todos los espacios de trabajo de Data Integration, puede utilizar inspect.

Para ver los espacios de trabajo en un compartimento específico:

allow group <group-name> to inspect dis-workspaces in compartment <compartment-name>
Activación de acceso para obtener detalles del espacio de trabajo

Para permitir que un grupo vea la lista de todos los espacios de trabajo de Data Integration, puede utilizar inspect.

El verbo read para dis-workspaces incluye los mismos permisos y operaciones de API que inspect, además del permiso, DIS_WORKSPACE_READ y las operaciones de API que cubre.

Para permitir que un grupo muestre y obtenga detalles de dis-workspaces en un compartimento específico, puede utilizar el verbo read:

allow group <group-name> to read dis-workspaces in compartment <compartment-name>

Para permitir que un grupo muestre y obtenga detalles de dis-workspaces y los objetos que contiene en el arrendamiento, puede utilizar:

allow group <group-name> to read dis-workspaces in tenancy
Activación de acceso para actualizar espacios de trabajo

Para permitir que un grupo actualice los espacios de trabajo y los objetos que contienen, puede utilizar el verbo use.

El verbo use para dis-workspaces incluye los mismos permisos y operaciones de API que read e inspect, además del permiso DIS_WORKSPACE_UPDATE, y las operaciones de API que cubre.

Para permitir que un grupo actualice dis-workspaces en un compartimento específico, puede utilizar:

allow group <group-name> to use dis-workspaces in compartment <compartment-name>

Para permitir que un grupo actualice dis-workspaces y los objetos que contiene en el arrendamiento, puede utilizar:

allow group <group-name> to use dis-workspaces in tenancy

Para permitir que un grupo actualice un espacio de trabajo específico y ningún otro espacio de trabajo:

allow group <group-name> to use dis-workspaces in compartment <compartment-name> where target.workspace.id = '<workspace-ocid>'

Para permitir que un grupo actualice un juego de espacios de trabajo especificados:

allow group <group-name> to use dis-workspaces in compartment <compartment-name> where ANY (target.workspace.id = '<workspace-1-ocid>', target.workspace.id = '<workspace-2-ocid>')
Nota

Puede copiar el OCID del espacio de trabajo desde la consola.
Activación de acceso para gestionar espacios de trabajo

Para permitir que un grupo gestione espacios de trabajo y los objetos que contienen, puede utilizar el verbo manage.

El verbo manage para dis-workspaces incluye los mismos permisos y operaciones de API que inspect, read y use además de los permisos DIS_WORKSPACE_CREATE y DIS_WORKSPACE_DELETE, y las operaciones de API que cubre.

Para permitir que un grupo gestione dis-workspaces en un compartimento específico, puede utilizar:

allow group <group-name> to manage dis-workspaces in compartment <compartment-name>

Para permitir que un grupo gestione dis-workspaces y los objetos que contiene en el arrendamiento, puede utilizar:

allow group <group-name> to manage dis-workspaces in tenancy

Para permitir que un grupo gestione un espacio de trabajo específico y ningún otro espacio de trabajo:

allow group <group-name> to manage dis-workspaces in compartment <compartment-name> where target.workspace.id = '<workspace-ocid>'

Para permitir que un grupo gestione un juego de espacios de trabajo especificados:

allow group <group-name> to manage dis-workspaces in compartment <compartment-name> where ANY (target.workspace.id = '<workspace-1-ocid>', target.workspace.id = '<workspace-2-ocid>')
Nota

Puede copiar el OCID del espacio de trabajo desde la consola.
Permitir Exportación e Importación de Objetos en Espacios de Trabajo

Data Integration necesita políticas específicas para utilizar la exportación y la importación. Consulte Configuración y políticas necesarias en el tema Exportación e importación de objetos.

Data Integration también necesita acceder a los recursos de Object Storage para su exportación e importación. Consulte Ejemplos de políticas para activar el acceso a OCI Object Storage.

Ejemplos de políticas para configurar el acceso entre arrendamientos para la copia de proyectos y la copia de aplicaciones

Para crear una aplicación o un proyecto en un arrendamiento (destino) copiando recursos de una aplicación o proyecto existente que esté en un arrendamiento diferente (origen), se deben configurar determinadas políticas en los arrendamientos de origen y destino.

Debe tener lo siguiente para escribir sentencias de política entre arrendamientos:

  • El OCID y el nombre del arrendamiento de destino
  • El OCID y el nombre del arrendamiento de origen
  • OCID de grupo de usuarios de un grupo cuyos usuarios tienen permisos de lectura y escritura en los espacios de trabajo de origen y destino

En el arrendamiento de destino:

El arrendamiento de destino es donde se va a crear la nueva aplicación o copia del proyecto.

  1. Crear un grupo de usuarios y agregar usuarios al grupo.

  2. Definir una política con las siguientes sentencias:

    define tenancy <source-tenancy-name> as <source-tenancy-OCID>
    endorse group <group-name> to manage dis-family in tenancy <source-tenancy-name>
    endorse group <group-name> to manage dis-workspaces in tenancy <source-tenancy-name>
    endorse group <group-name> to read compartments in tenancy <source-tenancy-name>
    endorse any-user to read compartments in tenancy <source-tenancy-name> where ALL {request.principal.type = 'disworkspace'}
    endorse any-user to manage dis-workspaces in tenancy <source-tenancy-name> where ALL {request.principal.type = 'disworkspace'}

En el arrendamiento de origen:

El arrendamiento de origen tiene el espacio de trabajo con la aplicación o proyecto existente que se va a copiar.

  1. Definir una política con las siguientes sentencias:

    define tenancy <target-tenancy-name> as <target-tenancy-OCID>
    define group <group-name> as <group-OCID>
  2. Para el acceso genérico a todos los espacios de trabajo:

    admit group <group-name> of tenancy <target-tenancy-name> to read compartments in tenancy
    admit group <group-name> of tenancy <target-tenancy-name> to manage dis-workspaces in tenancy
    admit any-user of tenancy <target-tenancy-name> to read compartments in tenancy  where ALL {request.principal.type = 'disworkspace'}
    admit any-user of tenancy <target-tenancy-name> to manage dis-workspaces in tenancy where ALL {request.principal.type = 'disworkspace'}

En lugar de acceso genérico, puede proporcionar un permiso más detallado basado en el OCID del espacio de trabajo de origen o la clave de la aplicación de origen:

admit group <group-name> of tenancy <target-tenancy-name> to manage dis-workspaces in tenancy where source.workspace.id  = '<source-tenancy-workspace-OCID>'
admit group <group-name> of tenancy <target-tenancy-name> to manage dis-workspaces in tenancy where source.application.key = '<source-existing-application-key>'
Permisos de política y ejemplos de API

A continuación se incluyen algunos ejemplos del uso de permisos en una condición:

allow group <group-name> to use dis-workspace in compartment <compartment-name> where request.permission = 'DIS_WORKSPACE_READ'
allow group <group-name> to use dis-workspace in compartment <compartment-name> where request.permission = 'DIS_WORKSPACE_UPDATE'

A continuación se incluyen algunos ejemplos para utilizar operaciones de API en una condición:

allow group <group-name> to use dis-workspace in compartment <compartment-name> where request.operation = 'GetWorkspace'
allow group <group-name> to use dis-workspace in compartment <compartment-name> where request.operation = 'UpdateWorkspace'
Nota

Un permiso puede tener más de una API relacionada con él. Si utiliza un permiso y no una API específica en una política, consulte Permisos necesarios para cada operación de API para asegurarse de que la política cubre las API que desea utilizar.
Ejemplos de políticas con sentencias condicionales
Nota

Puede copiar el OCID del espacio de trabajo desde la consola.

Se utilizan variables al agregar condiciones a una política. Consulte Variables generales para todas las solicitudes.

Las políticas con sentencias condicionales tienen una cláusula where. Por ejemplo, para permitir que un grupo actualice un espacio de trabajo específico y ningún otro espacio de trabajo:

allow group <group-name> to use dis-workspace in compartment <compartment-name> where target.workspace.id = '<workspace-ocid>'

Para permitir que solo el grupo que crea un espacio de trabajo lo utilice:

allow group <group-name> to use dis-workspaces in compartment <compartment-name> where target.workspace.createdBy = request.user.id

Para permitir que un grupo gestione todos los recursos de Data Integration, excepto para suprimir espacios de trabajo:

allow group <group-name> to manage dis-family in compartment <compartment-name> where request.permission != 'DIS_WORKSPACE_DELETE'

Las sentencias de política que utilizan una clave en una cláusula where permiten a los usuarios de un grupo utilizar espacios de trabajo de un compartimento en el que la solicitud tenga esa clave específica. Por ejemplo, puede permitir que un grupo opere solo en una aplicación específica.

Para restringir que un grupo solo ejecute tareas en una aplicación específica:

allow group <group-name> to use dis-workspaces in compartment <compartment-name> where any {target.application.key='<application-key>'}

Para permitir que un grupo cree objetos (como tareas y flujos de datos) solo en una carpeta:

allow group <group-name> to use dis-workspaces in compartment <compartment-name> where any {target.folder.key='<folder-key>'}

Para permitir que un grupo actualice o suprima un objeto específico, como un flujo de datos:

allow group <group-name> to use dis-workspaces in compartment <compartment-name> where any {target.object.key='<object-key>'}
Ejemplos de políticas para permitir el acceso a OCI Object Storage

Data Integration necesita permisos específicos para Oracle Cloud Infrastructure Object Storage para acceder a los metadatos y leer y escribir datos.

Para crear un activo de datos de Object Storage y examinar sus esquemas, debe pertenecer a un grupo de usuarios que tenga permiso para leer Object Storage. Consulte Ejemplos de políticas en nombre de.

Para probar una conexión a Object Storage, asegúrese de que el espacio de trabajo o el compartimento de Data Integration tenga, como mínimo, acceso READ a objectstorage-namespaces. Consulte Ejemplos de políticas de entidad de recurso.

Para crear y ejecutar un flujo de datos utilizando Object Storage como origen o destino, el espacio de trabajo o compartimento debe tener todas las políticas mencionadas en Ejemplos de política de entidad de recurso.

Nota

El contenido de la cláusula WHERE es opcional, pero es necesario para limitar los recursos que acceden a Oracle Cloud Infrastructure Object Storage. Puede utilizarlo para ajustar el acceso en función de necesidades específicas. Para aplicar una sentencia de política a:
  • Todos los espacios de trabajo, utilice WHERE ALL {request.principal.type='disworkspace'}
  • Un espacio de trabajo específico, utilice WHERE ALL {request.principal.id='<workspace-OCID>'}

    Puede copiar el OCID del espacio de trabajo desde la consola.

  • Todos los espacios de trabajo de un compartimento específico, utilice WHERE ALL {request.resource.compartment.id = '<compartment-OCID>'}

Para obtener detalles completos sobre la escritura de políticas para controlar el acceso a Object Storage, consulte Detalles de Object Storage.

Política de entidad de recurso

Estas políticas permiten que un espacio de trabajo de Data Integration o su compartimento validen las conexiones a Oracle Cloud Infrastructure Object Storage y lean y escriban datos.

Las políticas necesarias dependen de si el activo de datos de Object Storage y el espacio de trabajo de Data Integration están en el mismo arrendamiento o en distintos arrendamientos.

Dentro del mismo arrendamiento

Si el espacio de trabajo de Data Integration y el origen de datos de Object Storage están en el mismo arrendamiento, debe crear las siguientes políticas:

allow any-user to read buckets in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-ocid>', request.operation = 'GetBucket'}
allow any-user to manage objects in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-ocid>'}

Dentro de diferentes arrendamientos

Si el espacio de trabajo de Data Integration y el origen de datos de Object Storage están en diferentes arrendamientos, debe crear las siguientes políticas:

En el arrendamiento del espacio de trabajo:


Endorse any-user to read buckets in tenancy <tenancy-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-OCID>', request.operation = 'GetBucket'}

Endorse any-user to manage objects in tenancy <tenancy-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-OCID>'}

Endorse any-user to manage buckets in tenancy <tenancy-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-OCID>', request.permission = 'PAR_MANAGE'}

Endorse any-user to inspect compartments in tenancy <tenancy-name> where ALL {request.principal.type = 'disworkspace'}

En el arrendamiento de Object Storage:

Admit any-user of tenancy <tenancy-name> to read buckets in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-OCID>', request.operation = 'GetBucket'}

Admit any-user of tenancy <tenancy-name> to manage objects in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-OCID>'}

Admit any-user of tenancy <tenancy-name> to manage buckets in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-OCID>', request.permission = 'PAR_MANAGE'}

Admit any-user of tenancy <tenancy-name> to inspect compartments in tenancy
Ejemplos de políticas en nombre de

Estas políticas permiten al usuario conectado mostrar y examinar compartimentos, cubos de Object Storage y objetos según los permisos ya asignados al usuario.

Las políticas necesarias dependen de si el activo de datos de Object Storage y el espacio de trabajo de Data Integration están en el mismo arrendamiento o en distintos arrendamientos.

Dentro del mismo arrendamiento

Si el espacio de trabajo de Data Integration y el activo de datos de Object Storage pertenecen al mismo arrendamiento, el usuario (o el grupo al que pertenece el usuario) debe tener acceso a Object Storage:

allow group <group-name> to use object-family in compartment <compartment-name>

Dentro de diferentes arrendamientos

Si el espacio de trabajo de Data Integration y el activo de datos de Object Storage están en diferentes arrendamientos, debe crear las siguientes políticas:

En el arrendamiento del espacio de trabajo:

Define tenancy <any-name1> as <object-storage-tenancy-OCID>
Endorse group <group-name> to inspect compartments in tenancy <any-name1>
Endorse group <group-name> to use object-family in tenancy <any-name1>

En el arrendamiento de Object Storage:

Define tenancy <any-name2> as <workspace-tenancy-OCID>
Define group <workspace-tenancy-group-name> as <workspace-tenancy-group-OCID>
Admit group <group-name> of tenancy <any-name2> to inspect compartments in tenancy
Admit group <group-name> of tenancy <any-name2> to use object-family in compartment <compartment-name>
Ejemplos de políticas para utilizar instancias de Autonomous Database como destinos

Cuando se utilizan las bases de datos de Autonomous Data Warehouse o de Autonomous Transaction Processing como base de datos de destino en Data Integration, OCI Object Storage se utiliza para almacenar datos temporales y completar operaciones. Además de las políticas de Object Storage necesarias, también debe crear la siguiente política para permitir la autenticación previa de dichas solicitudes:

allow any-user to manage buckets in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-ocid>', request.permission = 'PAR_MANAGE'}
Ejemplos de políticas para la publicación en el servicio OCI Data Flow

Antes de publicar tareas de OCI Data Integration en el servicio OCI Data Flow con puntos finales privados, asegúrese de tener las siguientes políticas.

allow any-user to manage dataflow-application in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-ocid>'}
allow any-user to manage dataflow-run in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-ocid>'}
allow group <group-name> to read dataflow-application in compartment <compartment-name>
allow group <group-name> to manage dataflow-run in compartment <compartment-name>
allow any-user to read dataflow-private-endpoint in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-ocid>'}
allow any-user to read secret-bundles in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-ocid>'}

Para los usuarios no administradores, estas políticas son necesarias:

allow group <group-name> to inspect dataflow-private-endpoint in compartment <compartment-name>
allow group <group-name> to read secret-bundles in compartment <compartment-name>
Ejemplos de políticas para acceder al punto final de REST del servicio IA de OCI

Para autenticar la ejecución de una tarea de REST mediante la entidad de recurso de aplicación, agregue lo siguiente para obtener la entidad de recurso de OCI.

allow any-user to use ai-service-language-family in tenancy where ALL {request.principal.type = 'disapplication', request.principal.id = '<disapplication-ocid>'}