Oracle Cloud Infrastructure OCI Gen-2 Cloud Security – Part II (Identity and Access Management)

In my previous blog post Oracle Cloud Infrastructure OCI Gen-2 Cloud Security – Part I , I have discussed the seven pillars of information security upon which Oracle Cloud Infrastructure OCI (Oracle Gen-2 Cloud) is built. The cloud shared security and responsibility model was discussed along with the concepts such as Regions, Availability Domains and Fault Domains. This part discusses the Identity and Access Management for OCI. It provides authentication and authorisation for all the OCI resources and services.

An enterprise can use single tenancy shared by various business units, teams, and individuals while maintaining the necessary security, isolation, and governance, and this post will go into the concepts involved in this.

Identity and Access Management

Identity and Access Management service provides authentication and authorisation for all OCI resources and services. It enables you to control what type of access a group of users have and to which specific resources or services. When a customer joins OCI, a tenancy is created. Tenancy is a virtual construct that contains all of the OCI resources that belong to a customer. A resource is a cloud object that you create and use in OCI, eg. Compute instances, Block Storage volumes Virtual Cloud Networks. Each resource has a unique, Oracle-Assigned identifier called Oracle Cloud ID (OCID).

The administrator of tenancy can create users and groups and assign them to least-privilege access to resources that are partitioned into compartments. The Compartment is a heterogeneous collection of resources for the purposes of security isolation and access control. For example, a customer can create a compartment called HR-Compartment to host a specific set of cloud network, compute instances and storage volumes necessary to host its HR applications. IAM service resources are global. Customers can have single tenancy across multiple regions.

Compartments are a fundamental component of OCI for organising and isolating cloud resources. Customers use them to clearly separate resources for the purposes of isolation thereby separating them for one project or business units.

Unlike most OCI services are regionally scoped but IAM services resources are global. Customers can have single tenancy across multiple regions. Following are the key IAM primitives:

• Resource: A cloud object that a company’s employees create and use when interacting with OCI services, for example, compute instances, block storage volumes, virtual cloud networks (VCNs), subnets, and route tables. Each resource is assigned with a unique, Oracle assigned identifier called Oracle Cloud ID (OCID)
• Policy: A set of authorization rules that define access to resources within a tenancy.
• Compartment: A heterogeneous collection of resources for the purposes of security isolation and access control.
• Tenancy: The root compartment that contains all of an organization’s resources. Within a tenancy, administrators can create one or more compartments, create more users and groups, and assign policies that grant groups the ability to use resources within a compartment.
• User: A human being or system that needs access to manage their resources. Users must be added to groups in order to access resources. Users have one or more credentials that must be used to authenticate to Oracle Cloud Infrastructure services. Federated users are also supported.
• Group: A collection of users who share a similar set of access privileges. Administrators can grant access policies that authorize a group to consume or manage resources within a tenancy. All users in a group inherit the same set of privileges.
• Identity Provider: A trusted relationship with a federated identity provider. Federated users who attempt to authenticate to the Oracle Cloud Infrastructure console are redirected to the configured identity provider. After successfully authenticating, federated users can manage Oracle Cloud Infrastructure resources in the console just like a native IAM user. Currently, Oracle Cloud Infrastructure supports the SAML-2 compliant Oracle Identity Cloud Service (IDCS) and Microsoft Active Directory Federation Service (ADFS) as identity providers. Federated groups are mapped to native IAM groups to define the policies apply to a federated user.

The following figure 1 provides an example of Tenancy, Compartments and Policies:

All customer calls to access OCI resources are first authenticated by the IAM service (or federated identity provider) and then authorised based on IAM policies. A customer can create a policy that gives a set of users and groups, permissions to access the infrastructure resources such as network, compute, storage, etc within a compartment in the tenancy. These policies are flexible and are written in a human-readable form that is easy to understand and audit.

Principals

• A Principal is an IAM entity that is allowed to interact with OCI resources
• Principals can be an IAM User or Instance Principals
• IAM Users:
  • Users are persistent identities setup through IAM service to represent individual people or applications
  • when customers sign-up for OCI account, the first IAM user is the Default Administrator. It then setup other users and groups
  • Users have no permissions until placed in one or more group and group should have atleast one policy with permission to tenancy or a compartment (Security principle of least privilege)
• Group is a collection of users who all need the same type of access to a particular set of resources. A same user can be in multiple groups
• Instance Principals
  • Instance Principals let instances (and applications) to make API calls against other OCI services removing the need to configure user credentials or a config file
  • Authentication is at instance level. Customers don’t do any credential management
  • Services that support Instance Principals are – Compute, Block Volume, Networking, Load Balancing, Object Storage
  • Authorisation is done via dynamic groups. Dynamic group allow you to group OCI instances as principal actors, similar to user groups. Policy is set at Dynamic Group level. Membership in the group is determined by a set of criteria called matching rules. Resources that match the rule criteria are members of the dynamic group.

This is depicted in the figure 2 below:

Authentication

IAM service authenticates a Principal by –

• Username, Password
  • Use the password to sign in to web console
  • Administrator will provide you OTP (One Time Password) when setting-up your account
  • at your first log in, you are prompted to reset the password
• API Signing Key
  • Required when using the OCI API in conjunction with SDK/CLI
  • Key is an RSA key-pair in the PEM format (min 2048 bits)
  • In the instances, you can copy and paste the PEM public key
  • User creates the public key pair and uploads the public key in the Console
• Auth-Tokens
  • Oracle-generated token strings to authenticate with 3rd party APIs that do not support OCI signature-based authentication (eg. ADW)

Following depicts the steps that are needed to be taken in order to granting an access to the OCI resource or service:

Step 1: Create a Dynamic Group called “FrontEnd” that matches a set of instances. For example, the statement in italics [ All {instance.compartment.id = ‘<compartment_ocid>’, instance.id != ‘<instance1_to_exclude_ocid>’, instance.id != ‘<instance2_to_exclude_ocid>‘} ]

Step 2: Create a Policy with Permissions for instances. For example, Create a policy called “DynamicGroupPolicy” with policy statements in italics [ allow dynamic-group FrontEnd to manage buckets in tenancy ] and [ allow dynamic-group FrontEnd to manage objects in tenancy ]

Step 3: Customer deploys code to an instance. OCI SDK/CLI is able to make calls to OCI APIs without customer configured credentials. Following figure 3 depicts the screenshots for the same:

Java and Python SDKs and Terraform also support Instance Principal authorization. One can use curl command to query X.509 certioficates. The following figure 4 presents the screenshot:

How it works

• The internal PKI Service issues X.509 certificates for every compute instance
• These compute instance certificates are signed by our internal CA and contain information about the instance (instance Id, compartment Id, etc)
• If the OCI SDK/CLI can not find locally configured credentials, it will call the Instance Metadata service and use the provided X.509 certificate to call the Identity Auth Service, getting back a token to use in calling OCI APIs
• The Auth Service will verify the certificate was issued by us and issue a token with the key information from the certificate
• Calls made using that token will be authorized against any matching policy (using the new “instances” subject)
• The PKI Agent, running on the SmartNIC, will refresh the certificate periodically and the SDK, running on the instance, will get a new token from the Auth Service as necessary

Authorisation

• Authorization specifies various actions an authenticated Principal can perform
• OCI Authorization – define specific privileges in policies and associating them with principals
• Supports security principle of least privilege; by default, users are not allowed to perform any actions (policies cannot be attached to users, but only groups)
• Policies are comprised of one or more statements which specify what groups can access what resources and at what level of access
• Policies are written in human-readable format:
  • Allow group <group_name> to <verb> <resource-type> in tenancy
  • Allow group <group_name> to <verb> <resource-type> in compartment <compartment_name> [where <conditions>]
• Policy Attachment: Policies can be attached to a compartment or the tenancy. Where you attach it controls who can then modify it or delete it

Policy Syntax

The following figure 5 provides the Policy Syntax:

Verbs and Permissions

• When you write a policy giving a group access to a particular verb and resource-type, you’re actually giving that group access to one or more predefined permissions
• Permissions are the atomic units of authorization that control a user’s ability to perform operations on resources
• As you go from inspect > read > use > manage, the level of access generally increases, and the permissions granted are cumulative
• Each API operation requires the caller to have access to one or more permissions. E.g., to use ListVolumes or GetVolume, you must have access to a single permission: VOLUME_INSPECT

The following figure 6 provides depicts the Verbs and Permissions for the Volume family:

Common Policies

1. Network Admins manage a cloud network
   1. Allow group NetworkAdmins to manage virtual-network-family in tenancy
2. Object writers write to Object Storage
   1. Allow group ObjectWriters to manage objects in compartment ABC where any {request.permission=’OBJECT_CREATE’, request.permission=’OBJECT_INSPECT’}
   2. Allow group ObjectWriters to manage objects in compartment ABC where any {request.operation=‘CreateObject’, request.operation=‘ListObjects’}
3. Block Storage and Object Storage encrypt and decrypt volumes and buckets
   1. Allow service blockstorage, objectstorage-<region_name> to use keys in compartment ABC

Reference Model: Compartments

A compartment is a collection of related resources such as VCN, instances etc that can accessed only by groups that have been given permission by administrator in your organisation. They help you organise and control access to your resources. The following are their design considerations:

• Each resource belongs to a single compartment but resources can be connected/shared across compartments (VCN and its subnets can live in different compartments)
• A compartment can be deleted after creation or renamed
• A compartment can have sub compartments that can be up to six levels deep
• A resource can’t be reassigned to a different compartment after creation (exception: Buckets)
• After creating a compartment, you need to write at least one policy  for it, otherwise it cannot be accessed (except by administrators or users who have permission to the tenancy)
• Sub compartment inherits access permissions from compartments higher up its hierarchy
• When you create a policy, you need to specify which compartment to attach it to

The following figure 7 describes the reference model for Compartments:

Audit Service

• Automatically records calls to OCI services API endpoints as log events
• Log Information shows time of API activity, source and target of the activity, action and response
• All OCI Services support Audit Logs
• Perform diagnostics, track resource usage, monitor compliance, and collect security-related events using Audit Logs
• By default, Audit logs are retained for 90 days. You can configure log retention for up to 365 days

Tagging

OCI Tagging allows you to customise the organisation of your resources, control tag spam and script bulk actions based on Tags. There are two types of Tags – Free Form and Defined.

Free Form Tags

They are the basic kind in which we have key value pairs only. For example, you can tag Environment = Production; Project = Alpha

Defined Tags

They have more features and controls associated. They are contained in Namespaces and have defined schema and they are secured with Policy.

Tag Namespace

A Tag Namespace is a container for tag keys with tag key definitions. Tag key definition specifies its key (environment) and what types of values are allowed (string, number, text, date, enumerations, etc). Tag key definition or a tag namespace cannot be deleted, but retired. Retired tag namespaces and key definitions can no longer be applied to resources. You can reactivate a tag namespace or tag key definition that has been retired to reinstate its usage in your tenancy. This is depicted in figure 8 below:

Conclusion

In this part I have explained the Identity and Access Management in OCI. There is a very advanced and sophisticated IAM services that are available to OCI customers in order to secure their resources and services. In the next part of this series I will attempt to explain securing the networking in OCI.