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.
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
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.
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
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>' }
- 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.
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
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' }
- 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
Examples
- 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.
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.
- Tenancy B
- Endorse any connector in this tenancy to access any stream in Tenancy A.
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.
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.
- Tenancy B
- Endorse any connector in this tenancy to access any log in Tenancy A.
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.
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.
- Tenancy B
- Admit any connector in Tenancy A to access any function in this tenancy.
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).
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.
- Tenancy B
- Endorse any connector in this tenancy to access any metric in Tenancy A.
- 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.