OCI - Identity and Access Management (IAM)

Identity and Access Management (IAM) is a system that allows for fine-grained access control to users in a system. It involves authentication (verifying the identity of a person or device) and authorization (granting permissions to perform certain actions). In the Oracle Cloud Infrastructure (OCI), IAM concepts include users, groups, identity domains, principals, dynamic groups, and compartments. Identity domains are used to logically separate users, while compartments are used to logically isolate resources. Groups are collections of users with similar requirements and policies are used to grant access to resources for these groups. In OCI, authentication can be done through username and password, API signing keys, or auth tokens. Authorization is done through IAM policies, which have four key aspects: subjects, actions, placement, and conditions. These policies are written in a human-readable syntax and default to denying all actions. IAM also includes features such as multi-factor authentication, federation, and single sign-on. In OCI, there are four types of identity domains available: free, Oracle apps premium, premium, and external user. The free identity domain is included by default and allows for the management of access to all OCI resources. The Oracle apps premium identity domain is for managing identities for Oracle SaaS, PaaS, GBU applications, and on-premise applications. The premium identity domain allows for the management of identities for Oracle apps and non-Oracle apps, as well as on-premise environments. The external user identity domain is for managing identities for consumer and non-employee use cases. Users can create additional identity domains or change their domain type, but there are restrictions on these actions.

OCI Identity and Access Management.

Identity and Access Management (IAM) is a way to give fine-grained access control to users in a system.
IAM involves two main concepts: authentication (AuthN) and authorization (AuthZ).
Authentication is the process of verifying the identity of a person or device, while authorization is the process of granting permissions to perform certain actions.
In the Oracle Cloud Infrastructure (OCI), IAM concepts include: users, groups, identity domains, principals, dynamic groups, and compartments.
Identity domains are used to logically separate users, while compartments are used to logically isolate resources.
Groups are collections of users with similar requirements, and policies are used to grant access to resources for these groups.
Authentication in OCI can be done through methods such as username and password, while authorization is done through policies written in a human-readable syntax.
IAM also includes features such as multi-factor authentication, federation, and single sign-on.

identity domains

Identity domains in Oracle Cloud Infrastructure (OCI) are containers for managing users, roles, and other configurations and security settings.
Identity domains allow users to separate and manage different groups of users, such as those in development and production environments, or employees and non-employees.
There are four types of identity domains available in OCI: free (default), Oracle apps premium, premium, and external user.
The free identity domain is included by default when an OCI account is provisioned and allows users to manage access to all OCI resources.
The Oracle apps premium identity domain is for managing identities for Oracle SaaS, PaaS, GBU applications, and on-premise applications such as JD Edwards, PeopleSoft, Oracle Linux, and Oracle database.
The premium identity domain allows users to manage identities for Oracle apps and non-Oracle apps, as well as on-premise environments.
The external user identity domain is for managing identities for consumer and non-employee use cases, such as contractors or large consumer applications.
Users can create additional identity domains or change their domain type, but there are restrictions on these actions.

OCI IAM authentication AuthN

In Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM), a principal is an entity that can interact with OCI resources and can be a user or a service.
Groups in OCI IAM are collections of users who need the same type of access to resources.
OCI IAM authentication (AuthN) can be done through three mechanisms: username and password, API signing keys (RSA key pairs), and auth tokens.
API signing keys are used for authenticating API calls made by applications, while auth tokens are used to authenticate third-party APIs that do not support OCI signature-based authentication.
In OCI, users can be created and managed through the IAM service, and authentication can be done through the console, CLI, or API.
Multi-factor authentication (MFA) can be enabled for added security.
Federation allows users to use single sign-on (SSO) to access multiple applications, while single sign-on allows users to log in to multiple applications with one set of credentials.

AuthZ. AuthZ stands for authorization

AuthZ stands for authorization, which involves granting granular permissions to end users
Authorization in OCI is done through Identity and Access Management (IAM) policies
IAM policies have four key aspects: subjects, actions, placement, and conditions
Policies are written in the syntax “allow subjects to do actions in a location, with optional conditions” and default to denying all actions
Subjects can be defined as a membership in an identity group, a specific service, any user, or a combination of groups
Dynamic groups can be created for services to call other services, and policies can be written to grant permissions to these groups
Actions can be any specific OCI service actions, and multiple actions can be listed in a single policy
Placement specifies the resources that the actions can be performed on, and conditions allow for additional limitations on when the actions can be performed.
Authorization in OCI involves granting permissions to users through IAM policies
A user can be added to a group, but a policy must be written to grant permissions to the group
The Policy Builder tool can be used to create policies, or they can be written manually using the syntax “allow group [identity domain].[group] to [perform actions] in [compartment]”
Policies can be edited or deleted as needed
It is important to test that the correct permissions have been granted to the user or group before relying on them to perform certain actions.

Common IM policies

Common IM policies for a setup with a virtual cloud network, compute instances, and block volumes include permissions for network admins to manage virtual networks, compute admins to manage instances and use volumes and virtual networks, and policies for users to launch instances and attach block volumes
Policies can be written to grant permissions at the tenancy or compartment level and can specify specific actions that are allowed
It is important to consider which groups or users should have access to certain resources and to write policies accordingly to ensure proper access and security.

OCI Compartments

Compartments in OCI are logical constructs that are used to group related resources and control access to them
Each resource belongs to a single compartment, and access to a compartment is controlled through the use of users, groups, and policies
Compartments can contain resources from multiple regions and can interact with resources in other compartments
Resources can be moved between compartments and compartments can be deleted, though doing so will also delete any resources contained within them
It is important to carefully plan and organize compartments to effectively manage resources and access to them.

Compartment quotas and budget

Compartment quotas allow administrators to control resource consumption within individual compartments using policies
There are three types of quota policies: set, unset, and zero
Quota policies can be used to limit or remove access to certain cloud resources within a compartment
Service limits are set by Oracle and apply to the entire tenancy, while compartment quotas can be set on a more granular level within individual compartments
Compartment budgets can be used to set limits on the amount of money spent in a compartment
Alerts can be configured to notify administrators when budget limits are reached or exceeded

Policy inheritance and attachment

Compartments inherit policies from their parent compartment.
The “manage all resources in tenancy” policy cannot be disabled or deleted and must be present for new accounts.
Policy inheritance allows administrators to manage resources in any compartment in the tenancy.
Attachment determines who can modify or delete a policy.
A policy attached to the root compartment can be modified by anyone with access to manage policies in the tenancy, while a policy attached to a child compartment can only be modified by someone with access to manage policies in that child compartment.
Policies can be written at any level of the compartment hierarchy and will apply to all compartments downstream from the location of the policy.

Conditional policy

Conditional policies enable advanced and fine grain access control by evaluating conditions that are written using variables and conditions
Variables are prefixed with either “request” or “target” and represent attributes about the request or target resource
Single conditions can be written using “equal to” or “not equal to” and return true or false
Multiple conditions use the keywords “any” and “all” to represent logical OR and AND, respectively
Values in conditions can be strings, patterns, or other data types
Conditional policies can be used to limit access to resources based on specific attributes, such as the user or resource being targeted

Network sources

Network sources allow for controlling access based on originating IP addresses
Define a set of IP addresses in a network sources object and use a policy to specify what a group of users can do based on those IP addresses
The policy uses the reserved keyword request.networkSource.name
in a condition to scope the policy to the specified IP addresses

Tag-based access control.

Tag-based access control allows policies to span multiple compartments, groups, and resources
Access can be controlled based on tags applied to the requesting resource (group, dynamic group, compartment) or the target resource (resource or compartment)
Tag-based access control uses conditions and tag variables to define access

Dynamic groups

Dynamic groups are used to group resource principals in OCI (Oracle Cloud Infrastructure)
There are three types of resource principals: infrastructure principals, stacked principals, and ephemeral principals
Infrastructure principals are authorized actors (e.g. instances) that can perform actions on service resources
Stacked principals are principals running on top of infrastructure (e.g. a database calling the object storage service for backups)
Ephemeral principals are temporary credentials for a specific purpose (e.g. Oracle functions calling the object storage service)
Dynamic groups allow the grouping of resource principals and the creation of policies for these groups
Dynamic groups can be used to manage access and permissions for resources in OCI
Dynamic groups are used in OCI (Oracle Cloud Infrastructure) to group resource principals and create policies for them
To use a dynamic group, an instance must be created within a compartment and added to the dynamic group
A policy can then be written for the dynamic group to grant permissions to the instance, allowing it to access certain OCI services
The dynamic group and policy creation process is demonstrated using the OCI console and command line interface (CLI)

#

OCI - Identity and Access Management (IAM)#