.
.
.
.

The Default Domain is the first identity domain automatically created when you create a tenancy in Oracle Cloud Infrastructure (OCI). It acts as a container to store and manage users, groups, and their roles, and allows for federation, user provisioning, and secure application integration via SSO or protocols such as SAML and OAuth.

Key features:

• It is created in the tenancy's root compartment.
• It can be used for users, groups, and applications in the root compartment.
• It cannot be disabled or deleted.
• It cannot be hidden from the Sign In page.
• It is automatically replicated to all regions where the tenancy is enrolled.

Additional Identity Domains in OCI, going beyond the Default Domain.

Although every tenancy already has a Default Domain, it may be necessary to create multiple Identity Domains to achieve:

• Administrative and identity isolation — separating teams, departments, or environments, such as production and development.
• Differentiated security and compliance — each domain can have its own access, security, and compliance policies.
• More organized management — domains function as "folders" to organize users, groups, and applications.
• Granular administration — each domain can have its own administrators, responsible for users, applications, and policies.

When creating a new Identity Domain, OCI automatically creates:

• An administrator group;
• A domain administrator user.

This administrator can manage domain users, groups, and applications, assign administrative roles, configure MFA, password policies, and auto-enrollment profiles.

Key points taught:

• The region selected in the console at the time of creation becomes the home region of the domain.
• Unlike the Default Domain, additional domains are not automatically replicated to all regions of the tenancy.
• If domain users need to access OCI resources in other regions, replication must be enabled manually.

In IAM, a group is a collection of users who share common roles, permissions, and access policies. Instead of granting permissions individually to each user, you grant permissions to the group, which simplifies administration and facilitates auditing and security.

• Groups help to:
  • Simplify resource access management;
  • Organize users by role, team, or department;
  • Facilitate auditing and compliance by showing which groups have access to which resources.
• Após criar um identity domain, o domain admin pode criar grupos alinhados à estrutura da organização, como:
  • Engineering, Marketing, Finance, etc.;
  • Adicionar usuários a esses grupos conforme seus papéis;
  • Definir permissões por meio de políticas.
• In each domain, there are two default groups created by IAM:
  • Domain Administrators
    • The domain admin is added to this group;
    • It cannot be deleted;
    • It must contain at least one user;
    • Any user added to it will have full control over the identity domain.
  • All Domain Users
    • Automatically assigned to every new user;
    • Does not appear in the Groups tab;
    • Cannot be deleted;
    • If this group is associated with an application, all users in the domain will be able to access it.

User management in OCI IAM involves controlling the entire lifecycle of an identity, from creation to deletion, as well as defining permissions, groups, and administrative roles.

• User Lifecycle
  • Non-existent: profile not yet created.
  • Activated: user created and with active access to resources and applications according to permissions.
  • Deactivated: user cannot log in or use resources; can be reactivated.
  • Deleted: when the user leaves the company; groups, applications, and privileges are revoked.
• Who can manage/create users?
  • Tenancy admin: manages all tenancy resources.
  • Domain admin: manages users, groups, and domain capabilities.
  • Administrator with a delegated role: e.g., user manager admin.
  • User with permission via policy: e.g., allow group to manage users in tenancy.
• User Onboarding Methods
  • OCI Console or API.
  • CSV import for large volumes.
  • Self-registration for consumer users.
  • Integration with external sources via:
    • App Catalog (Oracle HCM, Oracle Unified Directory, Oracle Internet Directory);
    • SCIM APIs;
    • Active Directory Bridge and Provisioning Bridge (on-premises);
    • Just-In-Time provisioning via federation.

The use of Administrator Roles in OCI IAM, what permissions each role grants, and how they allow domain admins to delegate responsibilities within an identity domain.

Administrator Roles are predefined roles in OCI IAM that allow you to delegate administrative tasks to other users in an identity domain without having to create complex policies. They are domain-specific and grant granular permissions to manage users, groups, applications, security, auditing, and domain settings.

Key points taught:

• The domain admin is the superuser of the domain and can manage users, groups, applications, system settings, security, auditing, and notifications.
• To share these responsibilities, the domain admin can assign predefined administrative roles to other users.
• These roles already come with broad and specific permissions, without requiring the writing of complex policies.

Administrative roles presented:

• Identity Domain Administrator — superuser of the domain; can delegate roles to others.
• Security Administrator — manages security settings, password policies, login, MFA, and identity providers.
• Application Administrator — creates, updates, and manages applications; grants or revokes access for users and groups.
• User Administrator — manages users, groups, and memberships in the domain.
• User Manager — limited permissions; can manage all users or only specific groups, including activation, deactivation, password reset, etc.
• User Support / Help Desk Administrator — manages user accounts, unlocking, password reset, authentication factors, and code bypass.
• Audit Administrator — generates and runs audit reports and monitors identity domain activities.

In OCI, authorization is the mechanism that grants granular permissions for users to access resources and services. This is done through policies, which implement Role-Based Access Control (RBAC). Policies define who can do what, within what scope, and optionally, under what conditions.

• Policy Syntax
  • Subject: who receives the permission (group, dynamic group, OCID, any-user, etc.).
  • Action: what action the subject can perform (verb + resource type).
  • Placement/Location: where the permission applies (tenancy or compartment).
  • Condition: optional, for additional granularity.
• Important Principles
  • By default, everything is denied.
  • There is no "deny" policy; policies always start by allowing something.
  • The principle of least privilege applies: grant only the minimum necessary.
• Subject Clause
  • You can use groups: group /.
  • You can use dynamic groups: dynamic-group /.
  • You can use OCIDs.
  • You can use any-user.
  • Multiple groups can be chained in a single policy.
  • If the domain is not prefixed, the default domain is assumed; prefixing is always recommended.
• Action Clause
  • Available verbs, in ascending order of access:
    • inspect: observe/monitor.
    • read: basic read access.
    • use: use/modify existing resources.
    • manage: full control over the resource.
  • Resource Types:
    • all-resources: all OCI resources.
    • Aggregate resource type: family of resources (e.g., virtual network family, database family).
    • Individual resource type: specific resource (e.g., VCN, subnet, DB nodes).
  • Identity does not have an aggregate resource type; individual resources must be used.
• Placement/Location
  • Could it be:
    • in tenancy
    • in compartment
    • in compartment id

The video teaches the concept of compartments in OCI, which are logical containers used to organize, isolate, and manage cloud resources within a tenancy. They function like folders: they help separate resources by project, environment, team, region, or any other criteria, and are also fundamental for implementing access control through policies.

• A tenancy is also called a root compartment, where all resources can reside.
• From it, you can create subcompartments, such as:
  • Network compartment for VCNs and Load Balancers;
  • Storage compartment for Block Storage and File Storage;
  • Compartments by project, such as production and development.
• Creating dedicated compartments is a good practice for isolating and organizing resources.

Compartment Characteristics:

• Each resource belongs to a single compartment—it cannot be in two at the same time.
• Access is controlled by policies—for example, allowing a group to manage block storage only in Compartment A.
• Resources in different compartments can interact—for example, a VM in one compartment and a VCN in another.
• Resources can be moved between compartments.
• Compartments are global—the same compartment exists in all subscribed regions of the tenancy.
• Compartments can be nested—up to 6 levels deep, allowing for complex hierarchical structures.
• Policies can be attached to compartments, defining who can access, modify, or delete resources.

Compartment Quotas in OCI are limits used to control resource consumption within compartments. Additionally, it shows how to use quota policies to define, reset, or block resource usage, and how to complement this control with budgets to limit spending.

Key points taught:

• Purpose of quotas: to control the amount of resources each compartment can consume, preventing excessive use of expensive or critical resources.
• Quota policies: policies written to define consumption limits per service, resource family, or compartment.
• Basic syntax of a quota policy:
  • Use the set keyword to define a limit.
  • Then define the service family / resource family (e.g., vcn, compute-core, object-storage).
  • Next, the quota name (e.g., vcn-count, reserved-public-ip-count).
  • Then the numerical value of the limit.
  • And finally, the application location: in tenancy or in compartment .

Example taught:

set vcn quota vcn-count to 4 in compartment production

This limits the creation of 4 VCNs in the production compartment.