Oracle Cloud Infrastructure Documentation

Securing Connector Hub

This topic provides security information and recommendations for the Oracle Cloud Infrastructure Connector Hub service.

Security Responsibilities

To use Connector Hub securely, learn about your security and compliance responsibilities.

In general, Oracle provides security of cloud infrastructure and operations, such as cloud operator access controls and infrastructure security patching. You are responsible for securely configuring your cloud resources. Security in the cloud is a shared responsibility between you and Oracle.

Oracle is responsible for the following security requirements:

  • Physical Security: Oracle is responsible for protecting the global infrastructure that runs all services offered in Oracle Cloud Infrastructure. This infrastructure consists of the hardware, software, networking, and facilities that run Oracle Cloud Infrastructure services.

Your security responsibilities are described on this page, which include the following areas:

  • Access Control: Limit privileges as much as possible. Users should be given only the access necessary to perform their work.

Initial Security Tasks

Use this checklist to identify the tasks you perform to secure Connector Hub in a new Oracle Cloud Infrastructure tenancy.

Task More Information
Use IAM policies to grant access to users and resources IAM Policies

Routine Security Tasks

After getting started with Connector Hub, use this checklist to identify security tasks that we recommend you perform regularly.

Connector Hub does not have any security tasks that you need to perform regularly.

IAM Policies

Use policies to limit access to Connector Hub.

A policy specifies who can access Oracle Cloud Infrastructure resources and how. For more information, see How Policies Work.

Assign a group the least privileges that are required to perform their responsibilities. Each policy has a verb that describes what actions the group is allowed to do. From the least amount of access to the most, the available verbs are: inspect, read, use, and manage.

User Access Policies

Create this policy to allow group ConnectorUsers to create, update, and delete connectors in the ABC compartment.

Allow group ConnectorUsers to manage serviceconnectors in compartment ABC

Create this policy to allow group ConnectorUsers to update connectors only (not allowing the group to create or delete connectors) in the ABC compartment.

Allow group ConnectorUsers to use serviceconnectors in compartment ABC

For more information about Connector Hub policies, see Details for Connector Hub.

Service Access Policies

Note

Ensure that any policy you create complies with your company guidelines.

To move data, your connector must have authorization to access the specified resources in the source , task , and target  services. Some resources are accessible without policies. Default policies providing the required authorization are offered when you use the Console to define a connector. These policies are limited to the context of the connector. You can either accept the default policies or ensure that you have the proper authorizations in custom policies for user and service access.

For example, the following default policy is offered when you create or edit a connector that moves data from Logging to Monitoring.

allow any-user to use metrics in compartment id <target_metric_compartment_OCID>
where all {
    request.principal.type='serviceconnector',
    target.metrics.namespace='<metric_namespace>',
    request.principal.compartment.id='<serviceconnector_compartment_OCID>'
}

For more information, including default policies, see Access to Source, Task, and Target Services.

Cross-Tenancy Connector Access

Use cross-tenancy connector access to share connectors with another organization that has its own tenancy. For example, share connectors with another business unit in your company, a customer of your company, or a company that provides services to your company.

Note

To create a connector that accesses resources in other tenancies, you must use the OCI SDK, CLI, or API. (The policy builder in the Console doesn't provide information from other tenancies, or suggest Endorse, Admit, or Define statements.) For CLI and API instructions, see Creating a Connector.

To access and share resources, the administrators of both tenancies need to create special policy statements that explicitly state the resources that can be accessed and shared. These special statements use the words Define, Endorse, and Admit. For more information about these statements, see Cross-Tenancy Access Policies.

Source Tenancy Policy Statements

Use a policy statement in the source tenancy to:

  • Admit a connector from a destination tenancy to access resources in your (source) tenancy
  • Endorse a connector to access resources in the destination tenancy
  • Endorse a group to access resources in the destination tenancy
Note

The following example policy statements are formatted for readability. Before using copies of these statements, remove new lines, tabs, and spaces.
Admit any connector from the destination tenancy to access a specific kind of resource in your (source) tenancy
Define tenancy DestinationTenancy as <destination_tenancy_OCID>
Admit any-user of tenancy DestinationTenancy to <permissions_for_resource_kind> in compartment id <compartment_OCID_in_source_tenancy>
    where all 
    { 
        request.principal.type='serviceconnector', 
        request.principal.compartment.id=<compartment_OCID_in_destination_tenancy>' 
    }
For examples, see Examples. To find the permissions required for a specific type of resource accessed by a connector, see Default Policies.
Endorse a group in your (source) tenancy to do anything with any connector in any tenancy
Endorse group <group_name> to manage serviceconnectors in any-tenancy
Endorse a group in your (source) tenancy to do anything with any connector in the destination tenancy only
To write a policy that reduces the scope of tenancy access, the source administrator must reference the destination tenancy OCID provided by the destination administrator.
Define tenancy DestinationTenancy as <destination_tenancy_OCID>
Endorse group <group_name> to read serviceconnectors in tenancy DestinationTenancy

Destination Tenancy Policy Statements

Use a policy statement in the destination tenancy to:

  • Endorse a connector to access resources in the source tenancy
  • Admit a connector from the source tenancy to access resources in your (destination) tenancy
  • Admit a group or dynamic group from the source tenancy to access resources in your (destination) tenancy
Note

The following example policy statements are formatted for readability. Before using copies of these statements, remove new lines, tabs, and spaces.
Endorse any connector in your (destination) tenancy to access a specific kind of resource in the source tenancy
Define tenancy SourceTenancy as <source_tenancy_OCID>
Endorse any-user to <permissions_for_resource_kind> in tenancy SourceTenancy
    where all 
    { 
        request.principal.type='serviceconnector' 
    }
For examples, see Examples. To find the permissions required for a specific type of resource accessed by a connector, see Default Policies.
Admit a group from the source tenancy to do anything with any connector in your (destination) tenancy
Define tenancy SourceTenancy as <source_tenancy_OCID>
Define group <group_name> as <group_OCID>
Admit group <group_name> of tenancy SourceTenancy to manage serviceconnectors 
    in tenancy
Admit a group from the source tenancy to read connectors in the SharedConnectors compartment only (in your destination tenancy)
Define tenancy SourceTenancy as <source_tenancy_OCID>
Define group <group_name> as <group_OCID>
Admit group <group_name> of tenancy SourceTenancy to read serviceconnectors 
    in compartment SharedConnectors
Admit a dynamic group from the source tenancy to read connectors in the SharedConnectors compartment only (in your destination tenancy)
Define tenancy SourceTenancy as <source_tenancy_OCID>
Define dynamic-group <dynamic_group_name> as <group_OCID>
Admit dynamic-group <dynamic_group_name> of tenancy SourceTenancy to read serviceconnectors 
    in compartment SharedConnectors
To find the permissions required for a specific type of resource accessed by a dynamic group, see Custom Policies.

Examples

Note

  • Write cross-tenancy policies before creating the connector. You must use the OCI SDK, CLI, or API to create a cross-tenancy connector.
  • The following example policy statements are formatted for readability. Before using copies of these statements, remove new lines, tabs, and spaces.
  • To endorse or admit a connector for access to a source, target, or task resource that isn't covered in these examples, use the resource permissions in the default policies.
Stream Source in Another Tenancy

Write policies for a connector to move data from a stream in a different tenancy to a bucket in the connector's tenancy.


Stream source in another tenancy
Callout Description
1 Stream used as connector source
2 Connector that moves data from the stream to the bucket
3 Bucket used as connector target

Following are the policies for moving this data from the stream in Tenancy A to the bucket in Tenancy B, using the connector in Tenancy B.

Tenancy A
Admit any connector in the specified compartment of Tenancy B to access any stream in the specified compartment of this tenancy.
Define tenancy ConnectorTenancy as <tenancy_b_OCID>
Admit any-user of tenancy ConnectorTenancy to {STREAM_READ, STREAM_CONSUME} in compartment id <compartment_OCID_in_tenancy_a>
    where all 
    { 
        request.principal.type='serviceconnector', 
        request.principal.compartment.id=<compartment_OCID_in_tenancy_b>' 
    }
Tenancy B
Endorse any connector in this tenancy to access any stream in Tenancy A.
Define tenancy StreamTenancy as <tenancy_a_OCID>
Endorse any-user to {STREAM_READ, STREAM_CONSUME} in tenancy StreamTenancy
    where all 
    { 
        request.principal.type='serviceconnector' 
    }
Allow any connector in the specified compartment of this tenancy to move data to the bucket (same tenancy).
Allow any-user to manage objects in compartment id <target_bucket_compartment_OCID> 
    where all {
        request.principal.type='serviceconnector',
        target.bucket.name='<bucket_name>',          
        request.principal.compartment.id='<serviceconnector_compartment_OCID>'
    }
Log Source in Another Tenancy

Write policies for a connector to move data from a log in a different tenancy to a log group in the connector's tenancy.


Log source in another tenancy
Callout Description
1 Log used as connector source
2 Connector that moves data from the log to the log group
3 Log group used as connector target
Tenancy A
Admit any connector in the specified compartment of Tenancy B to access any log in the specified compartment of this tenancy.
Define tenancy ConnectorTenancy as <tenancy_b_OCID>
Admit any-user of tenancy ConnectorTenancy to read log-content in compartment id <compartment_OCID_in_tenancy_a>
    where all 
    { 
        request.principal.type='serviceconnector', 
        request.principal.compartment.id=<compartment_OCID_in_tenancy_b>' 
    }
Tenancy B
Endorse any connector in this tenancy to access any log in Tenancy A.
Define tenancy LogTenancy as <tenancy_a_OCID>
Endorse any-user to read log-content in tenancy LogTenancy
    where all 
    { 
        request.principal.type='serviceconnector' 
    }
Allow any connector in the specified compartment of this tenancy to move data to the log group (same tenancy).
Allow any-user to use loganalytics-log-group in compartment id <target_log_group_compartment_OCID> 
    where all {
        request.principal.type='serviceconnector', 
        target.loganalytics-log-group.id=<log_group_OCID>, 
        request.principal.compartment.id=<serviceconnector_compartment_OCID>
    }
Function Target in Another Tenancy

Write policies for a connector to move data from a log in the connector's tenancy to a function in a different tenancy.


Function target in another tenancy
Callout Description
1 Log used as connector source
2 Connector that moves data from the log to the function
3 Function used as connector target
Tenancy A
Endorse any connector in the specified compartment of this tenancy to access any function in the specified compartment of Tenancy B.
Define tenancy FunctionTenancy as <tenancy_b_OCID>
Endorse any-user to use fn-function in tenancy FunctionTenancy
    where all 
    { 
        request.principal.type='serviceconnector' 
    }
Define tenancy FunctionTenancy as <tenancy_b_OCID>
Endorse any-user to use fn-invocation in tenancy FunctionTenancy
    where all 
    { 
        request.principal.type='serviceconnector' 
    }
Allow any connector in the specified compartment of this tenancy to access any log (same tenancy).
Allow any-user to read log-content in compartment id <source_log_compartment_OCID>

    where all {
        request.principal.type='serviceconnector',         
        request.principal.compartment.id='<serviceconnector_compartment_OCID>'
    }
Tenancy B
Admit any connector in Tenancy A to access any function in this tenancy.
Define tenancy ConnectorTenancy as <tenancy_a_OCID>
Admit any-user to use fn-function in tenancy ConnectorTenancy
    where all 
    { 
        request.principal.type='serviceconnector' 
    }
Define tenancy ConnectorTenancy as <tenancy_a_OCID>
Admit any-user to use fn-invocation in tenancy ConnectorTenancy
    where all 
    { 
        request.principal.type='serviceconnector' 
    }
Source Metric and Target Bucket in Other Tenancies

Write policies for a connector to move data from a metric in a different tenancy (A) to a function in a different tenancy (C).


Source metric and target bucket in other tenancies
Callout Description
1 Metric used as connector source
2 Connector that moves data from the metric to the bucket
3 Bucket used as connector target
Tenancy A
Admit any connector in the specified compartment of Tenancy B to access any metric in the specified compartment of this tenancy.
Define tenancy ConnectorTenancy as <tenancy_b_OCID>
Admit any-user of tenancy ConnectorTenancy to read metrics in compartment id <compartment_OCID_in_tenancy_a>
    where all 
    { 
        request.principal.type='serviceconnector', 
        request.principal.compartment.id=<compartment_OCID_in_tenancy_b>' 
    }
Tenancy B
Endorse any connector in this tenancy to access any metric in Tenancy A.
Define tenancy MetricTenancy as <tenancy_a_OCID>
Endorse any-user to read metrics in tenancy MetricTenancy
    where all 
    { 
        request.principal.type='serviceconnector' 
    }
Endorse any connector in this tenancy to access any bucket in Tenancy C.
Define tenancy BucketTenancy as <tenancy_c_OCID>
Endorse any-user to manage objects in tenancy BucketTenancy
    where all 
    { 
        request.principal.type='serviceconnector' 
    }
Tenancy C
Admit any connector in the specified compartment of Tenancy B to move data to any bucket in the specified compartment of this tenancy.
Define tenancy ConnectorTenancy as <tenancy_b_OCID>
Admit any-user of tenancy ConnectorTenancy to manage objects in compartment id <compartment_OCID_in_tenancy_c>
    where all 
    { 
        request.principal.type='serviceconnector', 
        request.principal.compartment.id=<compartment_OCID_in_tenancy_b>' 
    }