Best Practices from Oracle Development's A‑Team

Governance: The Key Ingredient to Success: Part-3

Kiran Thakkar
Consulting Solutions Architect

Resource Governance

Resource governance encompasses three aspects. Of the three, Identity governance and cost governance are not closely tied to resources and their life cycle. However, they are essential for effective resource governance. On the other hand, access governance is closely tied to resources and directly impacts their security.

Identity Governance

Identity governance is the centralized and policy-based Identities and their entitlements management. It starts with user creation. When the user is created, the user might get default access to some resources and applications known as birth-right entitlements provisioning. Then, depending on the user's organization and user's groups/roles, the user might get access to applications and entitlements.

During the life cycle, the user can request more entitlements. After the approval process, the user gets assigned to those entitlements. In the end, when the user retires or leaves the organization, the Identity is de-provisioned.

If the same user joins back the organization, the user can usually claim the same Identity, as shown in the diagram below however may not have the same entitlements.

Identity on Oracle Cloud

There are two Islands of Identity on the Oracle cloud. OCI IAM service and IDCS (Identity Cloud Service). OCI IAM is the Identity for the control plane on Oracle cloud, and IDCS is the Identity of PaaS and SaaS services. IDCS can gate OCI IAM access to create a unified identity platform. IDCS acts as a glue and login service for all the IaaS, PaaS, and SaaS services, including third-party cloud services.

You can synchronize Identities from HR systems like PSFT or Fusion HCM to IDCS, as mentioned in the Identity Governance diagram. Furthermore, using SCIM 2.0 or provisioning bridge, you can sync Identities from Third-party Identity management systems or LDAP running either on-premises or in the cloud.

Then you go through the profile enrichment process in IDCS. As you enrich user profiles, users are provisioned to various services on Oracle cloud and third-party cloud services referred to as target systems.

When the user account is deactivated or removed from IDCS, IDCS can deactivate or remove Identity from target systems. Similarly, as Identities are removed or deactivated in source systems like HR system or on-premises LDAP, those Identities are deactivated in IDCS.

All the identities and their groups are synchronized between IDCS and OCI IAM. That provides a unified system of Identity Administration for the Oracle Cloud. Other than provisioning and de-provisioning users, IDCS would also act as a single authentication and authorization service for the Oracle Cloud. It can integrate with third-party cloud services using SAML and OIDC. IDCS can also delegate authentication to third-party IDP using SAML or OIDC if that is the preference.

Overall, IDCS provides a single source of truth for Identities on the Oracle Cloud. Along with OCI IAM Audit logs, it can control who has access to what and provides visibility into who accessed what and when on the Oracle Cloud.



Tagging is a powerful construct that you can leverage in the governance model. Tags are metadata (key-value pairs) attached to resources defining their usage, cost, ownership, etc. A resource (an instance of a service on a compartment) can have one or many tags. Tags assigned to the compartment are assigned to all the resources in the compartment. There are two ways to give tags to resources.

Defined tags: Tag administrators managed resource metadata

Free-form tags: Unmanaged metadata applied to resources by users during the life cycle of a resource

Tag Basics

Tag namespace (only applicable to defined tags): Tag namespace is a container for your tags. It consists of a name and zero or more tag key definitions. Tag namespace is unique across the tenancy.

Tag key: The name you use to refer to the tag. Tag keys are unique across the namespace.

Tag value type: It specifies the data type allowed for the value. There are two supported data types: String and a list of strings.

Tag value: It is the value that the user applies to the tags. Some tags have predefined values, and for others, users must choose one value from the list of values.

Defined Tags

Most of the tagging features are implemented using defined tags. For example, to create resource metadata that you use to manage resources or collect data, you use defined tags. There are three types of defined tags based on their usage and how values are assigned.

Tags with predefined values

You can create a list of values and associate that list with a tag key definition. When users then apply the tag to a resource, they must select a value from the list of predefined values. Use lists of predefined values to impose limits on the values that users can apply to tags.

Cost tracking tags

Cost tracking tags are the tags that are used when setting budgets.

Tag defaults

Tag defaults let you specify tags applied automatically to all resources at the time of creation in a specific compartment. This feature allows you to ensure that appropriate tags are applied at resource creation without requiring the user creating the resource to have access to the tag namespaces. Ideally, you use tag variables to create tag defaults. Ex: $(iam.principal.name}, $(iam.principal.type}, ${oci.datetime}

Tags for Access Management

Using conditions and a set of tag variables, you can write a policy to scope access based on the tags applied to a resource. Access can be controlled based on a tag that exists on the requesting resource (group, dynamic group, or compartment) or the target of the request (resource or compartment). First, three sample access policies use requesting resource tags and the last two sample access policies use the target resource tags.

  1. allow any-user to manage instances in compartment HR where request.principal.group.tag.Operations.Project= 'Prod'
  2. allow dynamic-group InstancesA to manage instances in compartment HR where request.principal.group.tag.Operations.Project= 'Prod'
  3. allow dynamic-group InstancesA to manage instances in tenancy where request.principal.compartment.tag.Operations.Project= 'Prod'
  4. allow group GroupA to manage all-resources in compartment HR where target.resource.tag.Operations.Project= 'Prod'
  5. allow group GroupA to manage all-resources in tenancy where target.resource.compartment.tag.Operations.Project= 'Prod'

Access Governance

OCI has adopted a deny-by-default security posture. When a tenancy is provisioned, no user other than the tenancy administrator user can access any resources in OCI. Tenancy administrators can create policies to grant permissions to groups of users on resources in compartments or the tenancy. For the compartment structure proposed in the Compartment section of Part-2 of the series, the following are some sample IAM policies.  

  1. Create policies to allow compartment admin to manage all resources in the respective compartment.
  • Allow group security_admin to manage all resources in compartment Shared_Security:Prod
  • Allow group security_admin to manage all resources in compartment Shared_Security:NonProd
  • Allow group network_admin to manage network-family-resources in compartment Network
  • Allow group database_admin to manage database-family-resources in compartment Database
  • Allow group appdev_admin to manage instance-family-resources in compartment App-Dev
  1. Create policies for compartment admins to use shared resources from other compartments.
  • Allow group appdev_admin to use network-family-resources in compartment Network
  • Allow group appdev_admin to use database-family-resources in compartment Database
  • Allow group database_admin to use network-family-resources in compartment Network
  • Allow group database_admin to use vaults in compartment Shared_Security
  1. Create policies for auditors and other read-only user groups to read all resources in the tenancy.
  • Allow group auditors to read all resources in tenancy
  • Allow helpdesk-users to inspect all resources in tenancy
  • Allow group announcement_readers_group to read announcements in tenancy

Then for every service that you onboard, you start with three high-level roles.

  • Service admin role
  • Service developer role
  • Service viewer role

For each of those roles, create baseline policies to manage, use, read, and inspect permission to service instances. Other than that, you create policies to give use permission on shared resources to the service administrator. For example, for the Analytics service, I will create below mentioned policies.

  1. Service admin role
    • Allow group Analytics-admin to manage analytics-instances in compartment App-Dev
    • Allow group Analytics-admin to manage analytics-instance-work-requests in compartment App-Dev
    • Allow group Analytics-admin to use network-family-resources in compartment Network
    • Allow group Analytics-admin to use autonomous-databases in compartment Database
  2. Service developer role
    • Allow group Analytics-developer to use analytics-instances in compartment App-Dev
    • Allow group Analytics-developer to use analytics-instance-work-requests in compartment App-Dev
  3. Service viewer role
    • Allow group Analytics-viewer to read analytics-instances in compartment App-Dev
    • Allow group Analytics-viewer to read analytics-instance-work-requests in compartment App-Dev

For every new service that you onboard, you bootstrap the process with these or similar policies and extend the policy model as needed to suit your needs.

Cost Governance

When transitioning from a CapEx model, where many costs are fixed at the implementation of a project, to an OpEx model, where costs scale up and down with the usage of the system, you often require cost management tools to understand, control, and communicate these cloud costs within your organization.

Oracle provides tools that we talk about in the following sections to meet these needs.

  • Set and manage cloud budgets
  • Prevent overspending
  • Ensure accurate cost tracking across departments and projects
  • Analyze which departments, services, and projects are contributing to cloud usage over time
  • Get granular usage details for invoice reconciliation
  • Identify areas to optimize costs.

Service Limits

Service limits are resource allowances that are established when you create your tenancy. Each resource has a defined limit and scope. The limits initially set in the tenancy are based upon a combination of resources purchased in the Bill of Materials and values determined as defaults. The scope of service limits is either regional or availability domain-specific allowing for additional flexibility. Service limits are invaluable in managing the maximum number of resources that can be provisioned in a tenancy, region, availability domain, and compartment. These “soft” limits will restrict provisioning resources which will breach the limits defined. Only authorized users can request these service limits to be increased or lowered. Service limits are crucial in limiting the maximum number of service instances of a particular service in a region, availability domain, and compartment.

The Data Science service limits are listed for the Ashburn region in compartment DEV in the example below. These limits can be set to align with approved boundaries and or budgets in accordance with the needs required by those groups.

Budgets and Quotas

A budget can be used to set soft limits on the Oracle Cloud Infrastructure spending by setting cost-tracking tags or by compartments (including the root compartment) to track all spending in that cost-tracking tag or for that compartment and its children. In addition, alerts can be set on budgets to inform management when they might be exceeded. All budgets and spending limits are available from one single place in the Oracle Cloud Infrastructure console.

All budget alerts are evaluated every hour in most regions and every four hours in Ashburn (IAD). To see the last time a budget was evaluated, open the details for a budget. You will see fields that show the current spend, the forecast and the "Spent in period" field, which shows you the period over which the budget was evaluated. When a budget alert fires, the email recipients configured in the budget alert receive an email.

Compartment quotas are policies that allow administrators to allocate resources with a high level of flexibility by giving tenant and compartment administrators better control over how resources are consumed in OCI, creating a powerful toolset to manage spending within the tenancy. Compartment quotas are similar to Service Limits, except service limits are set by Oracle. In contrast, compartment quotas are set by administrators, using policies that allow them to allocate resources with a high level of flexibility.

These budgets and quotas are aggregated within a compartment tree, so child compartments share the total aggregate budget or quota set on the parent. 

Therefore, if compartment "Data Science" has a budget of $2000, child compartments of DEV and TST share that global budget and will be restricted if either of them exceeds that limit. That is a fundamental concept to adhere to when adopting a budget model for particular groups with access to resources frequently for development or testing purposes.

An example of utilizing tagging with budgets can be viewed in the following:

Configure a tag key definition CostManagement.CostCenterID and enable for cost tracking. Setting a key tag value of "Finance" for Finance cost center (CostManagement.CostCenterID = "Finance") to specific resources, and "IT" (CostManagement.CostCenterID = "IT") to others, would allow the following budget scenario:

Create one budget for resources tagged "CostManagement.CostCenterID = Finance" and a second budget for resources tagged "CostManagement.CostCenterID = IT". If costs surpass the pre-defined budget or are forecast to exceed a particular threshold, alerts can be configured to notify recipients via email.

In this example, a budget is created for a compartment, specific to a tag value, where a monthly budget of $500 is created for all resources in a project with a Tag Key value of "IT" in the "Cost-Management/Finance" Tag namespace and Tag Key "CostCenterID." In addition, these budgets can be configured to start on a particular day of the month to align with business requirements. This budget is configured to send alerts to ABC.someone@company.com when the actual spend value reaches 80% of the $500 budget defined. 

The following example sets the quota for VM.Standard2 and BM.Standard2 compute series to 240 OCPUs (cores) in each AD on compartment App-Dev in the US West (Phoenix) region:

set compute-core quota standard2-core-count to 240 in compartment App-Dev where request.region = us-phoenix-1

The next example shows how to make an allow list, setting every quota in a family to zero and then explicitly allocating resources:

zero compute-core quotas in tenancy set compute-core quota standard2-core-count to 240 in tenancy

This example shows how to limit creating dense I/O compute resources to only one region:

zero compute-core quotas /*dense-io*/ in tenancy set compute-core quota /*dense-io*/ to 48 in tenancy where request.region = us-phoenix-1

You can clear quotas by using an unset statement, which removes the quota for a resource - any limits on this resource will now be enforced by the service limits:

zero compute-core quotas in tenancy unset compute-core quota standard2-core-count in tenancy

Cost Analysis

The Cost Analysis tool is essential and informative in understanding how Oracle Cloud Credits are being spent and how consumption compares to your commitment amount. This dashboard is used to view the spending by service or department (compartment or cost-tracking tag) and trend lines to understand how spending patterns are changing and focusing on cost reduction efforts.  Like the budget, a cost analysis can be done for a given tag key.

As seen in the graphic above, specific report types can be chosen to be run for desired periods and factors.  In addition, grouping these reports based on the compartment, tagging, or other group values allows for granular reporting for chargeback or analysis.

Usage and Cost Report

Usage reports enable you to get more insight into your bill or create custom billing applications. The reports contain one record per resource (for example, an instance, DB system, or Object Storage bucket) per hour with metadata and tags.

A cost report is a comma-separated value (CSV) file similar to a usage report and includes cost columns. The report can be used to obtain a breakdown of your invoice line items at resource-level granularity. As a result, you can optimize your Oracle Cloud Infrastructure spending and make more informed cloud spending decisions.

In summary, usage reports indicate the quantity of what is consumed, while cost reports indicate the cost of resource consumption.

When joined with your rate card, usage reports drive scenarios such as:

  • Invoice reconciliation
  • Custom reporting
  • Cross-charging
  • Cost optimization
  • Resource inventory

In addition to enabling new billing scenarios, usage reports provide transparency into how the billing system works. For example, it will indicate how and where rounding occurs within the usage report and how resources that existed for less than an hour are billed.


This is the third blog in a series of four blogs on the governance model. Links to other blogs are

  1. Overview (Part-1 of the blog series)
  2. Resource Organization (Part-2)
  3. Observe and Monitor (Part-4)


Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha