.
.
.
.
.

Definition: It is the principle by which a compartment automatically inherits any policy from its parent compartment. That is, access permissions flow downstream in the compartment hierarchy.

Example taught:

• There is a default administrator policy in the root compartment that cannot be edited or deleted. The "admin" group (without a domain prefix, indicating it belongs to the default domain) has permission to manage all resources in any compartment of the tenancy.
• If we have a hierarchy: Root → A → B → C, and we write a policy in compartment A giving the Domain1/NetworkAdmin group permission to manage VCNs (Virtual Cloud Networks) in compartment A, this group will also be able to manage VCNs in compartments B and C, as the permission flows down.

Conclusion: Inheritance explains why a policy written at the root (tenancy) can manage resources in any descendant compartment.

Definition: When creating a policy, it must be attached to a specific compartment (or to the tenancy/root). The location where the policy is attached determines who can modify or delete it.

Example taught:

• Policy 1 attached to the root compartment → any user with permission to manage policies in the tenancy can update or delete it.
• Policy 2 attached to the parent compartment → only those who manage policies in that compartment can change it.
• Policy 3 attached to the child compartment → only those who manage policies in that child compartment can change it.
• A user with access only to the child compartment cannot modify or delete policies attached to the root compartment.

Important point: The policy can be attached at any level of the hierarchy, but the full path must be provided when the policy is written at a higher level that does not directly "see" the target compartment.

This section explains how to create conditional policies in Oracle Cloud Infrastructure (OCI) using the where clause to add conditions that make access control more advanced, refined, and granular. The complete content definition follows.

Definition: These are policies that, in addition to the basic structure Allow to in , include a where clause with conditions. These conditions are evaluated as True, False, or Not Applicable.

Why use them?

• They allow for more complex, advanced, and refined access control.
• They restrict broad permissions to specific cases (e.g., region, compartment, resource type, specific permission).

Conditions use variables prefixed by request or target, followed by a period.

Request variable

Refers to attributes about the request itself (who is making the request and what is being requested).

Examples:

• request.user.id → allows access only to a user with a specific OCID.
• request.permission → restricts a broad permission (e.g., manage) to only specific permissions such as OBJECT_INSPECT and OBJECT_CREATE.
• request.region → restricts access to a specific region.

Target variable

Refers to the resource targeted by the request and its attributes.

Examples:

• target.bucket.name → limits access to a specific bucket.
• target.compartment.id → restricts access to a specific compartment.
• target.workload.type → restricts access to specific workload types (e.g., OLTP, Data Warehouse, Autonomous JSON Database).

Single Condition

Uses an equality (=) or inequality (!=) operator. The result is True or False.

Example:

request.region = 'Phoenix'
target.compartment.id != 'ocid1.compartment.oc1..xxxx'

Multiple Conditions

They use two keywords: any and all.

Example with any:

where any { request.region = 'Phoenix', request.region = 'Ashburn' }

How to apply the Least Privilege Principle when writing policies in Oracle Cloud Infrastructure (OCI), going beyond the permissions predefined by verbs (manage, inspect, use, read) and using individual permissions, API operations, conditions, and even time-based variables.

• Definition: Permissions are the atomic units of authorization that control a user's ability to perform operations on resources.
• In OCI, permission management is done through verbs: manage, inspect, use, read.
• These verbs simplify the granting of multiple related permissions, covering a broad set of access rights.
• When writing a policy, we use verb + resource type. OCI, in the background, grants one or more predefined permissions.

Example 1: Restricting manage access to a specific bucket and permission

• Original policy (without least privilege):

Allow group Audit to manage objects in compartment Acme

The verb "manage" grants all permissions, violating even the least privileged.

• Policy rewritten (with less privilege):

Allow group Audit to manage objects in compartment Acme
where target.bucket.name = 'bucket-name'

• Restricts it to a specific bucket.

Allow group Audit to manage objects in compartment Acme
where request.permission = 'OBJECT_CREATE'

Purpose: Group XYZ can list, create, update, write, and move block volumes, but cannot delete them.

Approach 1 — List allowed permissions:

Allow group XYZ to manage volumes in compartment Acme
where request.permission = 'VOLUME_LIST'
   or request.permission = 'VOLUME_CREATE'
   or request.permission = 'VOLUME_UPDATE'
   or request.permission = 'VOLUME_WRITE'
   or request.permission = 'VOLUME_MOVE'

VOLUME_DELETE is not included.

Approach 2 — Use inequality operator:

Allow group XYZ to manage volumes in compartment Acme
where request.permission != 'VOLUME_DELETE'

Purpose: The group can inspect or upload objects in any bucket within a compartment, but is limited to a specific bucket.

Allow group GroupName to manage objects in compartment Acme
where any {
   request.permission = 'OBJECT_CREATE',
   request.permission = 'OBJECT_INSPECT'
}

Objective: A group of contractors can access or use instances only during a specific period.

Allow group Contractors to use instances in compartment Acme
where request.time >= '2024-01-01T00:00:00Z'
  and request.time <= '2024-12-31T23:59:59Z'

It uses time-based variables to restrict access to specific time intervals.

How to use tags in Oracle Cloud Infrastructure (OCI) to simplify and make access control more flexible, allowing you to write policies that cover multiple compartments, groups, and resources without having to create repeated policies for each one.

Definition: It's an OCI feature that allows you to add metadata (key-value pairs) to resources and use them in policies to control access. Instead of writing policies for each compartment, group, or resource individually, you write a single tag-based policy.

How it works:

• You add tags to resources (e.g., Project, CostCenter, ProjectPhase as Production or Development).
• You use tag variables in the policy conditions (where clauses).
• Access is granted or revoked by applying or removing tags, without altering the original policy.

Advantages:

• Avoids creating the same policy repeatedly for each compartment/resource.
• A single policy can cover multiple groups, resources, and compartments.
• Easy to manage: to revoke access, simply change or remove the tag.
• New groups/resources with the correct tag automatically gain access.

Tags are used in conditions with variables prefixed by request or target. Tags always have a namespace + key + value.

Tags in the Requester (request.principal)

Used when the tag is applied to the one making the request (group, dynamic group, or compartment).

Example — Tag in the group:

Allow any-user to manage instances in compartment HR
where request.principal.group.tag.Operations.Project = 'Prod'

Any user belonging to a group with the tag Operations.Project = 'Prod' can manage instances in the HR compartment.

Tags on the Target

Used when the tag is applied to the target resource or the compartment where the target resource resides.

Example — Tag on the target resource:

Allow group GroupA to manage all-resources in compartment HR
where target.resource.tag.Operations.Project = 'Prod'

Example: Test Compartment with Multiple Admin Groups

Scenario:

• Three compartments: Project A, Project B, Project C.
• Each has its own admin group: A-Admin, B-Admin, C-Admin.
• All three admin groups have the tag EmployeeGroup.Role = 'Admin'.
• Each admin has full access to their own compartment via traditional policies.

Problem: Create a new "Test" compartment and grant access to all three admin groups without creating a new group and without manually managing user login/logout.

Solution with Tag-Based Access Control:

Allow any-user to manage all-resources in compartment Test
where request.principal.group.tag.EmployeeGroup.Role = 'Admin'

How to use Network Sources in Oracle Cloud Infrastructure (OCI) to control access to resources based on the source IP addresses of requests. It's a mechanism that adds an extra layer of security, allowing only requests from trusted IPs to access specific resources.

Definition: Network Sources is a mechanism that controls access based on the source IP addresses of requests. It works like a gatekeeper that only allows access to your resources if the request comes from the IP addresses you have specified.

Analog used: It's like a gatekeeper that only allows access if the request comes from authorized IPs.

Step 1: Define the IP Addresses (Create the Network Source)

• Create a list of IP addresses you wish to allow.
• These IPs can come from:
  • Virtual Cloud Network (VCN) — Private IPs from your cloud network.
  • Public IPs — Trusted external addresses.
• Create a Network Source object and add the IPs to it.
• The Network Source can contain:
  • A long list of IPs.
  • Or just a single IP.
  • The choice depends on your needs.

Summary of Step 1: Create a Network Source object containing the list of allowed IPs (VCN and/or public).

Step 2: Write the policy with the Network Source condition

• Write a policy that allows a group of users to perform actions on resources in a compartment or tenancy.
• Add a condition to restrict access to the Network Source created in Step 1.
• Use the keyword request.networkSource.name in the policy, passing the Network Source name as a parameter.

Syntax of politics:

Allow group <nome-do-grupo> to <ação> <recurso> in <compartimento/tenancy>
where request.networkSource.name = '<nome-do-network-source>'

What this policy does:

It allows the user group to manage resources in the tenancy only if the request originates from the IP addresses specified in the Network Source.

Scenario: You want a group of users to only be able to manage resources if they are accessing them from the company network.

Step 1 — Create Network Source:

• Name: OfficeNetwork
• Included IPs: Public IPs of the office and/or CIDR of the company's VCN.

Step 2 — Write the policy:

Allow group Developers to manage all-resources in tenancy
where request.networkSource.name = 'OfficeNetwork'

The concept of Dynamic Groups in Oracle Cloud Infrastructure (OCI) allows you to group resource principals (such as instances, functions, databases) and write policies so that these resources can make API calls to other OCI services. Before getting to Dynamic Groups, the lesson recaps important terms and introduces the three resource principal patterns.

Before understanding Dynamic Groups, it is necessary to know the three resource principal patterns:

Infrastructure Principal (Instance Principal)

Analogy: Birth certificate — proves the existence of a resource in OCI.

Definition: OCI IAM has the ability to make instances authorized actors (principals). That is, instances and applications running on them can call and manage other services (e.g., Object Storage).

Example: Instance Principal — the instance acts as the principal and performs actions on service resources.

Stacked Principal

Analogy: Someone with a birth certificate obtains a passport—the passport represents the ability to interact with other resources.

Definition: You project one principal on top of another. A service controls a resource that specifies the intent of the resource.

Example: A database that calls Object Storage to store backups.

Ephemeral Principal

Analogy: Temporary badge valid for one day — temporary credentials for short-term actions.

Definition: Uses injected identifiers to grant temporary access.

Example: Functions — a function is created and temporary access to other services (e.g., Object Storage) is granted for a limited time.

What are they?

Definition: Dynamic Groups allow you to group resource principals (instances, functions, databases, etc.) as "principal actors," similar to user groups. Then, policies are written for these dynamic groups, allowing the principal actors to make API calls against OCI services.

Examples of use:

• Instance calling Object Storage.
• Database calling Vault Service.
• Functions calling any other OCI service.

Why "Dynamic"?

Because Dynamic Groups are created using matching rules. Members can change dynamically—if you create or delete instances in a compartment, the group membership changes automatically, without manual maintenance.

Example rule: "Instances from a given compartment will be members of this dynamic group."

When creating a Dynamic Group, a matching rule is defined to specify the members. Examples shown:

After creating the Dynamic Group with the matching rule, it is necessary to write a policy to grant access to the main actors. Without a policy, the members of the dynamic group cannot do anything.

Syntax:

Allow dynamic-group <domain>/<group-name> to <ação> <recurso> in <compartimento/tenancy>
where <condições adicionais>

This video tutorial teaches practical ways to simplify and optimize IAM policies in Oracle Cloud Infrastructure (OCI) by removing redundancies and duplicates, grouping policies, and applying appropriate conditions. The goal is to stay within policy boundaries, facilitate management, and simplify security audits.

Analog used: IAM policies are like a lock and key system. Having multiple keys for the same lock complicates access and creates vulnerabilities. Ideally, the right person should have the right key for the right resource.

Reasons to optimize:

• Performance: Many policies can delay API calls and impact application performance.
• OCI Limits: OCI imposes limits on the number of policies and statements. Reaching these limits restricts the scalability of the environment.
• Management: Fewer policies are easier to manage, audit, and update.
• Security: A leaner access control model is more secure and efficient.

Removing Exact Duplicates

• Scenario: Identical policy statements attached to the same compartment, granting the same permissions to the same groups/users/resources.
• Cause: Different teams manage policies in the same scope without proper coordination.
• Solution:
  • Remove duplicate statements.
  • Establish clear policy ownership within the organization.
  • Implement a review process for new policies.

Removing Redundant Policies Due to Inheritance

Scenario: Compartment A has a policy that allows the Network Admins group to manage virtual-network-family. Compartment B (child of A) has a similar policy with the same permissions.

Problem: The second policy is redundant because IAM policies follow the inheritance model—any policy attached to a parent compartment is automatically inherited by all children.

Solution: Remove the policy from compartment B. Always check the permission scope before writing a policy.

Redundancy by Maximum Permission

Scenario 1:

Compartment A: group can manage virtual-network-family.

Compartment B (child): same group can use virtual-network-family.

Problem: The policy in B is redundant because B inherits manage from A — and manage already includes use and all lower levels.

Solution: Remove the redundant policy from B.

Part 2 of the video lesson delves into techniques for refining IAM policies in Oracle Cloud Infrastructure (OCI), making them more efficient and secure. The focus is on merging policy statements, applying the principle of least privilege with explicit permissions, combining permissions for multiple groups, and using patterns in conditions.

To launch a compute instance, several permissions are required. In the example, the VCN has already been created by an admin, and the operator has been added to group X.

1. Attach the instance to a subnet:

Included Permissions:

• SUBNET_READ — view subnet details.

• SUBNET_ATTACH — attach the instance to the subnet.

• SUBNET_DETACH — detach resources from the subnet.

2. Manage instances:

Included permissions:

• INSTANCE_CREATE — create instances.

• INSTANCE_DELETE — delete instances.

• Other instance management permissions.

3. Access the application catalog:

Included permissions:

• View available listings for resources in the compartment.

Problem: The same group receives multiple permissions for different types of resources through separate declarations. Solution: Merge the permissions into a single policy statement, listing the explicit permissions instead of using verbs.

Consolidated Policy (example):

where request.permission = 'SUBNET_READ'
or request.permission = 'SUBNET_ATTACH'

or request.permission = 'SUBNET_DETACH'

Allow group X to manage instances in compartment A
where request.permission = 'INSTANCE_CREATE'

or request.permission = 'INSTANCE_DELETE'

or request.permission = 'INSTANCE_INSPECT'

Allow group X to read catalog listings in compartment A

Benefits:

• Minimizes the number of policy statements.

• Simplifies auditing and governance.

• Assigns only the necessary permissions (principle of least privilege).

Problem: Using verbs (such as manage) grants additional predefined permissions that may not be necessary.

Example: If the goal is only to launch an instance, attach it to a subnet, and assign it to a network security group, using verbs may grant more permissions than necessary.

Solution: Refine the policy by removing unwanted permissions and including only the necessary permissions for the specific use case.

Result:

• More focused and secure policy.

• Minimizes unnecessary access.

• Alignment with the principle of least privilege.

4. Optimization 3: Combining Permissions for Multiple Groups

Problem: Creating separate policies for each group that needs the same permissions.

Solution: Use a single policy statement to cover all groups.

Example: If groups X and Y need access to instances:

Refinement with explicit permissions:

where request.permission = 'INSTANCE_CREATE'
or request.permission = 'INSTANCE_UPDATE'

or request.permission = 'INSTANCE_DELETE'

or request.permission = 'INSTANCE_INSPECT'

• Adds only the necessary permissions in a single statement.

• Follows the principle of least privilege.

• Ensures that only the necessary access is granted.

Definition: Patterns allow you to apply permissions dynamically based on naming conventions.

Example: A pattern like ProjectX* matches all compartments whose names begin with ProjectX.

Application: Combine separate policies for production and development into a single policy using patterns.

Example:

• Reduces redundancy.

• Simplifies policy updates in multi-compartment environments.

This video lesson teaches how to use OCI's IAM (Identity and Access Management) to define granular access control policies at the object level within OCI Object Storage. This level of control is essential for workloads such as data lakes, big data, and IoT applications, where it is necessary to manage secure and flexible access to millions of objects.

Definition: A scalable, high-performance service designed to handle large volumes of data, ensuring fast and reliable access, durability (multiple data copies), and continuous integrity monitoring.

Main Components:

• Bucket: A container that organizes and stores unstructured data (files, images, videos).

• Object: Each item stored within a bucket (image, video, document).

Lesson Focus: Applying access control at the object level within buckets.

Traditionally, policies are defined for:

• Buckets (e.g., manage buckets).
• Objects (e.g., manage objects).
• Single-object family policy.

These policies can be applied at the tenancy level or the compartment level, granting access to all buckets and objects within the defined scope.

Intermediate granularity: Add conditions for a specific bucket (e.g., target.bucket.name = 'BucketA'), allowing only certain actions (e.g., OBJECT_CREATE, OBJECT_INSPECT).

Limitation: When multiple applications or users need different permissions for different objects within the same bucket, it is necessary to go beyond the bucket level.

3. Object-Level Permissions

Definition: Allows you to assign permissions to individual objects or groups of objects within a bucket, using the target.object.name variable.

How ​​it works:

• The target.object.name variable allows you to refine access control down to the object level.

• Allows you to define permissions for specific files or folders.

• Assigns different access levels to users or applications.

• Restricts actions such as reading, writing, deleting, or copying specific objects.

• Supports large workloads (buckets with millions of objects).

IAM Scope Hierarchy:

Tenancy → Compartment → Bucket (via conditions) → Object (via target.object.name)

Objective: To grant full access (read, write, delete) to all objects within the prod folder in the test bucket.

where target.bucket.name = 'test'

and target.object.name = 'prod*'

• target.object.name = 'prod*' restricts access only to objects in the prod folder.

Objective: To provide read-only access to objects in the same folder prod.

where target.bucket.name = 'test'

and target.object.name = 'prod*'

and request.permission = 'OBJECT_INSPECT'

or request.permission = 'OBJECT_READ'

• Allows only viewing and reading of objects.

Objective: To allow users to add new data or read existing data, but not modify or see the complete list of objects in the folder.

Allow group GroupName to manage objects in compartment Acme
where target.bucket.name = 'test'
and target.object.name = 'dev*'
and request.permission = 'OBJECT_CREATE'
or request.permission = 'OBJECT_READ'

• Ideal for scenarios where the user can add or read data, but not modify or list all objects.

Objective: Grant a specific user full access to all PDF files within the bucket test-bucket.

where target.bucket.name = 'test-bucket'

and target.object.name = '*.pdf'

• Uses the pattern *.pdf combined with the unique user OCID.

• Ensures that only the specified user can list, read, write, delete, or copy PDF files.