Note:

Set up an initial administrator model for your Oracle Cloud tenancy

Introduction

Cloud security requires a shared responsibility model. Oracle as the cloud provider, owns the responsibility for providing secure infrastructure and platform services. And you, as the tenancy owner, are responsible for managing and controlling access to the resources that you create in the tenancy. When you first create an Oracle Cloud Infrastructure (OCI) tenancy, there is a single user account that is a member of the tenancy Administrators group, which grants full access to the entire tenancy and all resources within.

As you begin to add other administrators, assign permissions, create resources, and populate data, it is important to think about your security model early in the process so you don’t have to figure out how to clean up problems down the road.

The security model described in this tutorial represents a general design and should be adapted to align with your organization’s specific security policies and tenancy management approaches. The Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) policy model is incredibly flexible and can be easily adapted or modified to accommodate different designs.

Objectives

Prerequisites

Task 1: Configure the Initial Tenancy Settings

To simplify the creation of a baseline model for tenancy access, and to create high-level roles for working with tenancy level resources within OCI, initial entitlements can be scripted using the OCI CLI and run from Cloud Shell.

A template script which creates groups and policy statements for the following core set of access capabilities, as well as providing a level of baseline access for all OCI administrators is provided below.

The intent of these policies is to create an initial set of entitlements which are applicable to most customers. More detail about these specific access capabilities and potential additional policies are described in the following sections.

These groups should be used in concert with the roles that already exist within OCI IAM identity domains; including Security Administrators who configure the authentication mechanisms for the environment; as well as User Administrators for managing on-boarding and assignment of users. User Administrators may not be required in deployments for which users are managed in an external identity management solution.

If you are not familiar with the OCI IAM policy syntax, review the OCI IAM documentation to understand the structure of the policy statements.

Baseline Access Script

Note: This script is applicable only to OCI environments with IAM Domains. Some older tenancies may not have IAM Domains in their environment. To confirm whether your environment has IAM Domains, follow the instructions here.

#!/bin/bash

#Update the below with details for the environment
tenancy_ocid=ocid1.tenancy.oc1..aaaaaaaa....

#Group names
tenancy_manager_group=TenancyManagers
pol_admin_group=PolicyAdmins
sec_admin_group=SecurityAdmin
sec_analyst_group=SecurityAnalysts

#All_Users_Policy
oci iam policy create -c $tenancy_ocid --name "All_Users_Policy" \
--description "General purpose permissions intended for all users of the tenancy." \
--statements "[\"allow any-user to inspect tag-defaults in tenancy where all{ request.domain.name = 'default', request.principal.type = 'user' }\", \
              \"allow any-user to inspect limits in tenancy where all{ request.domain.name = 'default', request.principal.type = 'user' }\", \
              \"allow any-user to inspect tenancies in tenancy where all{ request.domain.name = 'default', request.principal.type = 'user' }\", \
              \"allow any-user to inspect compartments in tenancy where all{ request.domain.name = 'default', request.principal.type = 'user' }\", \
              \"allow any-user to read policies in tenancy where all{ request.domain.name = 'default', request.principal.type = 'user' }\", \
              \"allow any-user to read objectstorage-namespaces in tenancy where all{ request.domain.name = 'default', request.principal.type = 'user' }\", \
              \"allow any-user to read announcements in tenancy where all{ request.domain.name = 'default', request.principal.type = 'user' }\", \
              \"allow any-user to use cloud-shell in tenancy where all{ request.domain.name = 'default', request.principal.type = 'user' }\"]"

#Tenancy Managers
oci iam group create --name $tenancy_manager_group \
--description "Group for Tenancy Managers for OCI, who can manage tenancy-level constructs, such as budgets and regions."

oci iam policy create -c $tenancy_ocid --name "Tenancy_Managers_Policy" \
  --description "Policy statements which define the 'Tenancy Manager' role, which allows for managing tenancy-level configuration and objects." \
  --statements "[\"define tenancy usage-report as ocid1.tenancy.oc1..aaaaaaaaned4fkpkisbwjlr56u7cj63lf3wffbilvqknstgtvzub7vhqkggq\", \
                \"allow group ${tenancy_manager_group} to read usage-report in tenancy\", \
                \"allow group ${tenancy_manager_group} to read resource-availability in tenancy\", \
                \"allow group ${tenancy_manager_group} to manage quotas in tenancy\", \
                \"allow group ${tenancy_manager_group} to manage tenancies in tenancy\", \
                \"allow group ${tenancy_manager_group} to manage objectstorage-namespaces in tenancy\", \
                \"allow group ${tenancy_manager_group} to manage buckets in tenancy where request.operation = 'UpdateNamespaceMetadata'\", \
                \"allow group ${tenancy_manager_group} to manage usage-budgets in tenancy\", \
                \"allow group ${tenancy_manager_group} to manage organizations-family in tenancy\", \
                \"allow group ${tenancy_manager_group} to {AUDIT_CONFIGURATION} in tenancy\", \
                \"endorse group ${tenancy_manager_group} to read objects in tenancy usage-report\"]"

#Policy Admins
oci iam group create --name $pol_admin_group \
--description "Group for Policy Administrators for OCI, who create and maintain IAM Policies and supporting resources."

oci iam policy create -c $tenancy_ocid --name "Policy_Admins_Policy" \
--description "Policy statements which define the 'Policy Admin' role, who create and maintain IAM Policies and supporting resources." \
--statements "[\"allow group ${pol_admin_group} to inspect groups in tenancy\", \
              \"allow group ${pol_admin_group} to read users in tenancy\", \
              \"allow group ${pol_admin_group} to manage groups in tenancy where target.group.name != 'Administrators'\", \
              \"allow group ${pol_admin_group} to manage compartments in tenancy\", \
              \"allow group ${pol_admin_group} to manage dynamic-groups in tenancy\", \
              \"allow group ${pol_admin_group} to manage domains in tenancy where request.permission != 'DOMAIN_RESOURCES_ADMINISTER'\", \
              \"allow group ${pol_admin_group} to manage network-sources in tenancy\", \
              \"allow group ${pol_admin_group} to manage policies in tenancy\", \
              \"allow group ${pol_admin_group} to manage tag-namespaces in tenancy\", \
              \"allow group ${pol_admin_group} to manage iamworkrequests in tenancy\"]"

#Security Admin
oci iam group create --name $sec_admin_group \
--description "Group for Security Admins for OCI, who can manage Cloud Guard and Data Safe"

oci iam policy create -c $tenancy_ocid --name "Security_Admins_Policy" \
  --description "Policy statements which define the 'Security Admin' role, which allows for managing Cloud Guard and Data Safe." \
  --statements "[\"allow group ${sec_admin_group} to inspect groups in tenancy\", \
                \"allow group ${sec_admin_group} to read repos in tenancy\", \
                \"allow group ${sec_admin_group} to manage cloud-guard-family in tenancy\", \
                \"allow group ${sec_admin_group} to manage data-safe in tenancy\"]"

#Security Analyst
oci iam group create --name $sec_analyst_group \
--description "Group for Security Analysts for OCI, which provides read access to resources in the tenancy, and the ability to use Cloud Guard"

oci iam policy create -c $tenancy_ocid --name "Security_Analysts_Policy" \
  --description "Policy statements which define the 'Security Analyst' role, which allows for read access to the tenancy, and the ability to work with Cloud Guard." \
  --statements "[\"allow group ${sec_analyst_group} to read all-resources in tenancy\", \
                \"allow group ${sec_analyst_group} to read audit-events in tenancy\", \
                \"allow group ${sec_analyst_group} to read cloud-guard-family in tenancy\", \
                \"allow group ${sec_analyst_group} to use cloud-guard-config in tenancy\", \
                \"allow group ${sec_analyst_group} to manage cloud-guard-detectors in tenancy\", \
                \"allow group ${sec_analyst_group} to manage cloud-guard-problems in tenancy\", \
                \"allow group ${sec_analyst_group} to manage cloud-guard-detector-recipes in tenancy\", \
                \"allow group ${sec_analyst_group} to manage cloud-guard-managed-lists in tenancy\", \
                \"allow group ${sec_analyst_group} to manage cloud-guard-user-preferences in tenancy\"]"

Task 2: Update the script

  1. Copy the script into a text editor to make any required adjustments before executing it in your environment.

  2. Update the tenancy_ocid variable to the correct value for your tenancy. The tenancy OCID can be obtained from the Tenancy Details page, available at https://cloud.oracle.com/tenancy, or by clicking the tenancy name in the OCI Console Dashboard.

    Image of the tenancy overview screen, with the OCID item highlighted

  3. Update the Group names if required. The Group names may need to align with a naming scheme, especially if there is an intention to populate them from an external identity management system.

  4. Review and update the policy statements to align with your organization’s requirements. Considerations for modifications to these policy statements, as well as additional policy statements are outlined in the following sections.

Understand the Permission Model

At a high level, the entitlement design implemented by this script divides tenancy management responsibilities into narrower roles which better reflect the different types of administrators that may exist in your environment. It is also intended to prevent users who are operating at the tenancy level from creating infrastructure resources outside of dedicated OCI Compartments.

Ensuring resources are created in compartments improves tenancy governance, as budgets and resource quotas can be configured at the compartment level. It also simplifies the policy model for managing those resources, since compartments can be directly referenced in those policies.

This script is intended to be conservative, only granting a minimal set of permissions to each group. Depending upon how your organization intends to use OCI, additional permissions may be required. The following sections discuss the entitlements created by the script in more detail and include examples of potential changes.

Baseline Access via ‘all-users’ policies

In OCI, users have no access unless a policy has been configured to provide that access. To facilitate user productivity, as well as provide users with meaningful information about the tenancy, the script creates a set of baseline access for all users. These policies authorize the use of cloud shell, as well as the ability to read announcements and check subscribed regions.

The recommended policies are also designed to aid users in making informed requests when they require additional access or resources, by allowing them to view objects which may limit their ability to interact with the tenancy, including service limits and policies.

In general, it is recommended to use the Default OCI IAM identity domain for OCI resource management, and to disallow access to the OCI console for users who authenticate via any other identity domains. As such, the supplied script limits access to users who authenticate via the Default domain. Your security design may support use of multiple identity domains for managing OCI access. For example, you might have a production domain for production administrators, and a non-production domain for non-production administrators. In that case, the condition in the baseline access policies could be modified to capture each domain, as follows:

... where all{ request.domain.name in ('<prod_domain_name>, '<non-prod_domain_name>'), request.principal.type = 'user' }

Depending upon your tenancy design, you may wish to add the following policy.

allow any-user to use tag-namespaces in tenancy where all{ request.domain.name = 'default', request.principal.type = 'user' }

This policy permits all users to apply, update, or remove defined tags for resources that they can modify. This may be desirable if owners of resources should be able to modify tags for their own tracking purposes, or for access management purposes. It may not be desirable if your design makes use of tag defaulting for cost tracking or other purposes.

Tenancy Managers

Tenancy Manager entitlements are intended for users with a governance responsibility for the tenancy, including managing costs and budgeting, as well as the regions to which the tenancy subscribes.

The policies created by the script for the tenancy managers may require minor adjustments to provide access to usage reports. The script uses the default tenancy identifier for cost analysis, however some tenancies, depending upon their status, may use an alternative tenancy identifier. If a tenancy manager is unable to access usage reports, the policy should be updated to use the values shown in the usage reports section of the OCI Console. i.e.

Image of an unauthorized Usage Reports page, showing the required tenancy id.

Policy Admins

Perhaps the most important capability to facilitate moving away from using the Administrators group is the assignment of Policy Admin entitlements. These entitlements are used by administrators responsible for configuring access entitlements within the tenancy. In the model created by the supplied script, Policy Admins are responsible for defining entitlements but not assigning users to those groups. User management entitlements are granted through the assignment of the User Administrators role within the IAM Domain. In some deployments a single administrator may be assigned both responsibilities, depending upon your organization’s security design.

Note: The Policy Admin entitlement has very narrow scope, but as it can be used to create policies which grant any level of access within the environment, including escalating their own level of access, it should be considered a highly privileged entitlement.

Security Admins

The Security Admin role is for users who are responsible for configuring security services in the environment, such as Cloud Guard and Data Safe.

You may also wish to add the following statements to enable Security Admins to configure tenancy-level alerting:

allow group SecurityAdmins to manage cloudevents-rules in tenancy where target.compartment.id = '<tenancy_ocid>'
allow group SecurityAdmins to use metrics in tenancy

These allow Security Admins to configure alerting on events that occur at the tenancy level, including sign in or Cloud Guard problem creation. These events will require an action such as a notification to be associated with them to be meaningful, however the action does not need to be in the root (tenancy) compartment. The services responsible for handling these events can instead be in a sub-compartment used for other security purposes. For example, a policy such as the following could be added to authorize the configuration of notifications for security purposes:

allow group SecurityAdmins to manage ons-family in compartment security_resources

Security Analysts

The Security Analyst role is for users who are responsible for reviewing actions and events within the OCI Tenancy. To investigate and validate issues associated with Cloud Guard problems, a Security Analyst requires read access to the entire tenancy.

Task 3: Run the Script using Cloud Shell

After making any required modifications to the script, you can execute it using Cloud Shell within the OCI Console.

Note: Cloud Shell is not required, but provides a simple mechanism for executing scripts as it is pre-configured with OCI CLI, and uses the authentication context of the logged in user.

  1. Open Cloud Shell from the Developer Tools icon in the OCI Console header.

    Image of the Developer Tools dropdown, with the 'Cloud Shell' menu item highlighted

    Cloud Shell may take some time to initialize, especially if this is the first time it has been accessed.

  2. Copy the updated script into your Cloud Shell environment, e.g. using vi:

    $vi policy_scaffold.sh

    Within vi, press i to enter [INSERT] mode, then paste the content of the script into the file, before pressing esc, then :wq to save and exit.

  3. Make the script executable, and run it to create initial entitlements.

    $chmod +x policy_scaffold.sh
$./policy_scaffold.sh

  4. Monitor the output to ensure each of the Group and Policy objects are created correctly. Issues can be resolved manually, or by tweaking then re-executing individual OCI CLI commands from within the script.

Task 4: Assign users and secure the Administrators group

Once the script has been executed, users can be assigned to the created groups, granting them the associated entitlements.

After assigning a few administrative roles, it is a good practice to restrict use of the OCI Administrators group to emergency access scenarios. OCI requires at least one user account to be assigned to the Administrators group so that you can recover access to the tenancy in the event of identity outage or misconfiguration. Otherwise, it would be possible to create a situation in which no user can assign access, and all your administrators could become locked out of your environment.

For more information and detailed recommendations, refer to Managing Emergency Access Accounts in Oracle Cloud Infrastructure.

Next Steps

After building out an initial set of tenancy administration roles, these can be used as a base to facilitate the creation of roles for individual projects, or to expand the capabilities of these core administrators.

The model used here has two primary goals. First, it allows administrators of the OCI environment to be removed from the Administrators group and into roles that are more closely tailored to their specific responsibilities. Secondarily, it prevents users with tenancy level access from being able to create infrastructure resources in the root compartment. When creating additional policies, it is recommended to maintain this design principle and to only create policies that target compartments under the root. In addition to security benefits, this also allows for simplified cost-tracking and project governance.

To learn more, review the Oracle Cloud Infrastructure Security Guide.

Acknowledgments

More Learning Resources

Explore other labs on docs.oracle.com/learn or access more free learning content on the Oracle Learning YouTube channel. Additionally, visit education.oracle.com/learning-explorer to become an Oracle Learning Explorer.

For product documentation, visit Oracle Help Center.