Skip to content

RedThunder.Blog
Demystifying cloud technologies…

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:

 Figure 1: 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:

 Figure 2: Users, Groups, Resources, Compartments and Tenancy

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:
Figure 3: Screenshot of OCI API calls
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:
 Figure 4: X.509 Certificate using curl command

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:

 Figure 5: 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:
 Figure 6: Verbs and Permissions

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:

 Figure 7: OCI Compartments Reference Model

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:

Figure 8: Tag Namespace

 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.

Share this:

 Share

AuthorRaminder BhraraPosted onDecember 31,

2018CategoriesUncategorizedTagsGen-2, IAM, Identity and Access
Management, OCI, Oracle Cloud Infrastructure

4 thoughts on “Oracle Cloud Infrastructure OCI Gen-2

Cloud Security – Part II (Identity and
Access Management)”

1. Pingback: Oracle Cloud Infrastructure OCI Gen-2 Cloud Security – Part III

(Networking) – RedThunder.Blog
2. Pingback: Oracle Cloud Infrastructure OCI Gen-2 Cloud Security – Part IV
(Key Management) – RedThunder.Blog
3. Pingback: Oracle Cloud Infrastructure OCI Gen-2 Cloud Security – Part V
(Edge Security Services) – RedThunder.Blog

4. Amal K Msays:

June 27, 2020 at 12:06 am

This should be made the official documentation of OCI IAM.

Concise, Precise, to-the-point explanation.
Can’t thank you enough for writing this!

Like

Reply

Leave a Reply
Post navigation
PREVIOUSPrevious post:Oracle Cloud Infrastructure OCI Gen-2 Cloud Security
– Part I
NEXTNext post:Oracle Cloud Infrastructure OCI Gen-2 Cloud Security – Part
III (Networking)
Search for:SEARCH
RECENT POSTS
 #BuildWithAI Announces Winners
 #BuildWithAI – A Hackathon Experience
 Kiron – A #VisFSG Project
 Configure to completion a site-to-site VPN tunnel on OCI using the
VPN Wizard
 Triggering an OIC integration via OCI Events – the Oracle
Functions Approach

RECENT COMMENTS

#BuildWithAI Announc… on #BuildWithAI – A Hackath…

#BuildWithAI Announc… on #BuildWithAI – A Hackath…

Object Storage with… on Object Storage with Oracle Int…

Object Storage with… on Object Storage with Oracle Int…

Jason Lowe on #BuildWithAI – A Hackath…

ARCHIVES
 August 2020
 June 2020
 May 2020
 April 2020
 March 2020
 January 2020
 November 2019
 October 2019
 September 2019
 August 2019
 July 2019
 June 2019
 May 2019
 April 2019
 March 2019
 February 2019
 January 2019
 December 2018
 November 2018
 October 2018
 September 2018
 August 2018
 July 2018
 May 2018
 April 2018
 March 2018
 February 2018
 January 2018
 December 2017
 November 2017
 October 2017
 September 2017
 August 2017
 July 2017
 June 2017
 May 2017
 April 2017
 March 2017
 February 2017
 January 2017
 December 2016
 November 2016
 March 2016

CATEGORIES
 ADWC
 Analytics
 APIs
 App Dev
 Application Builder Cloud Service
 Application Container Cloud Service
 Architecture
 Autonomous
 Bitnami
 Blockchain
 Business
 chatbots
 Cloud Native
 Community
 Containers
 Content & Experience Cloud Service
 Data Science
 Database Cloud Service
 Delivery
 Design
 Developer Cloud Service
 DevOps
 Docker
 Docker Hub
 Docker-Compose
 Documents Cloud Service
 Eloqua
 ERP Cloud
 Functions
 GitHub
 Governance
 HCM Cloud
 How To
 IaaS
 IDCS
 Insight
 Integration Analytics
 Integration Cloud Service
 IOT
 Java Cloud Service
 Javascript
 JET
 Kubernetes
 Linux
 Machine Learning
 Marketing and Workshops
 Messaging Cloud Service
 MFT
 Microservices
 Mobile Cloud Service
 Mobility
 MongoDB
 NodeJS
 OCI
 OMC
 Oracle API Platform
 Oracle Cloud Infrastructure
 Oracle Container Cloud Service
 Oracle Container Registry
 Oracle Database
 Oracle Identity Cloud Service
 Oracle Instant Client
 Oracle Integration Cloud
 Oracle Public Cloud
 Oracle SQL Developer
 PaaS
 PeopleSoft
 Process
 Process Cloud Service
 Provisioning
 Ravello
 Real Time Integration Business Insight
 RPA
 SCM Cloud
 Security
 Service Cloud
 SOA Cloud Service
 SOA Suite
 StackEngine
 Storage Cloud Service
 Testing
 Transformation
 Uncategorized
 Vagrant
 VisualBuilder
 Weblogic
 WebLogic Server
 Workshops

Search for:SEARCH
RECENT POSTS
 #BuildWithAI Announces WinnersAugust 18, 2020
 #BuildWithAI – A Hackathon ExperienceAugust 11, 2020
 Kiron – A #VisFSG ProjectJune 19, 2020
 Configure to completion a site-to-site VPN tunnel on OCI using the
VPN WizardMay 26, 2020
 Triggering an OIC integration via OCI Events – the Oracle
Functions ApproachMay 14, 2020
 ARCHIVES

Archives                                                                                       
CATEGORIES
Categories                                                                                                                                       

CONTRIBUTORS

  Alessia Sacchi

  Anton Koren

  Solutions ANZ

  Sergio J. Castro

  CallanHP

  chrisadianto

  David Reid

  deepaksekar2101

  francoucci
  John Graves

  HuntersView

  jeetendrabhardwaj

  Jason Grogan

  Jason Lowe

  Tam Nguyen

  Labanish

  lmukadam

  manishkugupta

  Mounash

  Jin Park

  Raminder Bhrara
  Manish Kumar Gupta

  Rakesh Singh

  Carlos Rodriguez Iturria

  Serene Tan

  Stan Tanev

  Sunny Chua

  Tom Walker

  Vladimir Dmitriev

  vijaykumaryenne

BLOGROLL
 Jason Lowe

RedThunder.blog and contributors. All Rights Reserved. The views expressed in this
blog are our own and do not necessarily reflect the views of Oracle Corporation. All
content is provided on an ‘as is’ basis, without warranties or conditions of any kind,
either express or implied, including, without limitation, any warranties or conditions
of title, non-infringement, merchantability, or fitness for a particular purpose. You
are solely responsible for determining the appropriateness of using or redistributing
and assume any risks.
FOLLOW BLOG VIA EMAIL
Enter your email address to follow this blog and receive notifications of new posts by
email.

Join 206 other followers

FOLLOW
RedThunder.Blog