OCI GoldenGate Security RBAC IAM Policy Generator

Implement RBAC for OCI GG with fine-grained IAM policies using the Segregation of Duties (SoD) matrix.

When it comes to the question of security, the only acceptable answer is paranoia. For peace of mind, only allow specific required permissions to your cloud users. Trust no one, but if you must, trust minimally.

Like layers of Onion, OCI and OCI GoldenGate offer security options at multiple layers to secure your deployments and data.

OCI GG — Securing by layers

In this article we will discuss the first layer of security i.e., IAM Policy Controls. Subsequent posts in this series will look at other layers such as console security, NW access, etc. I will add layers to this diagram as we progress along the way.

Before securing OCI GG deployments there should be a well-planned SoD matrix for users and groups. All OCI resource permissions are covered by 4 verbs (listed in order of least to most ability) INSPECT, READ, USE and MANAGE.

More often than not group policies allow MANAGE permissions on entire resource-family, which provides lot more permissions than really required. One of the guidelines listed in the documentation for securing OCI GG states that permissions for GOLDENGATE_DEPLOYMENT_DELETE and GOLDENGATE_CONNECTION_DELETE must be restricted.

MANAGE permission on goldengate-family or goldengate-deployment resource gives ability to delete the deployment. This is not a good idea even if you have one administrator performing all the tasks.

Using OCI IAM policies, role based access control (RBAC) can be implement by restricting access scope at individual operation level in policy statement instead of providing aggregate permissions.

I will discuss how to implement RBAC for OCI GG users using a hypothetical scenario. A excel workbook is used to automate IAM policies generation based on user inputs.

Why do we need RBAC for OCI GG apart from preventing accidental deletion?

OCI GG supports several RDBMS and Big data source/targets. In a complex setup it’s unlikely one single team or person manages all sources and targets. DBA and GoldenGate responsibilities may belong to different teams. Each organization has a different setup and hence the need for RBAC.

Consider a team setup with 4 different personas.

GoldenGate Cloud Personas

• DevOPS group is in charge of rolling out all OCI services across the tenancy.
• GoldenGate Administrators group in charge of creating new GoldenGate deployments, database connection and upgrades, etc.
• GoldenGate Operators group in charge of day to day operation such as stopping and starting deployments, updating deployments and connections, etc.
• GoldenGate Monitor group in charge of monitoring the status of deployments and backups, etc.

Each of these groups require varying level of permissions on goldengate-family resources.

goldengate-family is aggregate resource type consisting of 4 different types of resources namely

• goldengate-deployments
• goldengate-deployment-backups
• goldengate-connections
• goldengate-connections-assignments

Manually configuring IAM policy per operation is tedious, error-prone and cumbersome.

To simplify this, I have created a semi-automated Excel workbook. Two policy statements are generated per Group. One whitelist policy to explicitly allow operations and another blacklist policy to explicitly disallow specific operations. You should use either one of them. Whether to adopt a whitelist or blacklist approach is matter of personal preference.

If explicitly allowing specific operations then permissions need to be revised when new operations/API’s are released. Conversely, if we choose to disallow specific operations/API’s, all newly released operations will be automatically allowed. I prefer to take the approach of explicitly allowing operations since it’s more restrictive.

How to use the OCI GG IAM policy generator.

Currently policy generator requires to configure three set of values:

1. User and Group names. Enter values in blue cells as required.

Provide User and Group Names

2. Compartment name for which policy statement is generated and Bucket name for manual backup location. These values are used to further scope the IAM policy. Enter values in blue cell.

Enter Compartment and Bucket Name

3. Select X/Y to allow/disallow each operation.

Y to Allow and X to disallow specific operation

Three Policy statements are automatically generated in the policy worksheet.

1. OCI GG IAM whitelist policy
2. OCI GG IAM blacklist policy
3. Minimum required policy

This can be edited as required before executing with OCI policy editor. Sample policy statements:

Auto generate IAM Policy

Sample policy output — The first policy statement is an example of whitelisting allowed operations and second policy achieves the same by blacklisting disallowed operations.

# Example of IAM policy to allow specific operations 

ALLOW GROUP DevOPSGrp TO MANAGE goldengate-family in COMPARTMENT TestComp  
where any { 
request.operation='ListDeployments', request.operation='CreateDeployment', 
request.operation='GetDeployment', request.operation='StartDeployment', 
request.operation='ChangeDeploymentCompartment', 
request.operation='GetWorkRequest', request.operation='ListWorkRequests', 
request.operation='ListWorkRequestErrors', 
request.operation='ListWorkRequestLogs', request.operation='ListConnections', 
request.operation='CreateConnection', request.operation='GetConnection', 
request.operation='ChangeConnectionCompartment', 
request.operation='ListConnectionAssignments', 
request.operation='CreateConnectionAssignment', 
request.operation='GetConnectionAssignment'
}

# Example of Previous IAM policy to disallow specific operations

ALLOW GROUP DevOPSGrp TO MANAGE goldengate-family in COMPARTMENT TestComp   
where ALL { 
request.operation!='UpdateDeployment', request.operation!='DeleteDeployment', 
request.operation!='StopDeployment', request.operation!='RestoreDeployment', 
request.operation!='UpgradeDeployment', 
request.operation!='GetDeploymentUpgrade', 
request.operation!='ListDeploymentUpgrades', 
request.operation!='UpdateConnection', 
request.operation!='DeleteConnection', 
request.operation!='DeleteConnectionAssignment'
}

#Minimum required policies
 ALLOW GROUP DevOPSGrp,GGAdminGrp,GGOperGrp,GGMonGrp to manage objects 
 in compartment  TestCompartment where target.bucket.name='TestBucket' 
 ALLOW GROUP DevOPSGrp,GGAdminGrp,GGOperGrp,GGMonGrp to use tag-namespaces in 
 compartment TestCompartment
 ALLOW GROUP DevOPSGrp,GGAdminGrp,GGOperGrp,GGMonGrp to use 
 virtual-network-family in compartment TestCompartment
 ALLOW GROUP DevOPSGrp,GGAdminGrp,GGOperGrp,GGMonGrp to read database-family 
 in compartment TestCompartment
 ALLOW GROUP DevOPSGrp,GGAdminGrp,GGOperGrp,GGMonGrp to read 
 autonomous-database-family in compartment TestCompartment

Thank you for reading so far. Please share your feedback, comments on this approach. What do you think about this? Get the conversation going.

Note 1— All policy statements were tested against local non-federated users/groups.

Note 2— Scripts/examples provided here are for education purpose and are not a replacement for official OCI documentation. When in doubt consult the documentation. This is not an official product or tool. I highly recommend testing all the policies in lower environment before using it in production setup.

To access the latest policy generator excel, you can star or watch my public OGG repo.

GitHub - GitJig/PracticalOGG: Collection of Oracle GoldenGate script examples and samples