Article 08 – Resource Principals & Workload Identity: Authorization for OKE, Functions, and Automation

1. Introduction to Resource-Level Authentication

While Instance Principals authorize compute virtual machines, modern cloud architectures rely heavily on serverless workloads (OCI Functions), cloud automation (Cloud Shell), and containerized microservices operating inside Container Engine for Kubernetes (OKE).

For these non-VM workloads, OCI provides Resource Principals and OKE Workload Identity.

These features extend credential-less security down to individual code executions and Kubernetes Pods, ensuring that microservices only access the specific cloud resources required for their function.

2. Resource Principals Mechanics

A Resource Principal allows an OCI service resource (such as an OCI Function or API Gateway) to authenticate directly against OCI APIs without using host-level credentials.

Token Exchange Flow:

1. When an OCI Function executes, the runtime environment sets environment variables pointing to a local Resource Principal Token (RPT) file (OCI_RESOURCE_PRINCIPAL_RPT_PATH).
2. The OCI SDK reads the RPT token and exchanges it with the OCI Security Token Service (STS) for a short-lived, signed session token.
3. The function uses this session token to execute authorized API actions (such as writing to a database or invoking another service).

3. OKE Workload Identity Architecture

In Container Engine for Kubernetes (OKE), multiple application pods run on shared worker nodes. Using Instance Principals at the worker node level would grant every pod on that node the same permissions.

OKE Workload Identity solves this by mapping Kubernetes Service Accounts directly to OCI IAM policies:

Kubernetes Pod ➔ K8s Service Account ➔ OCI Workload Identity ➔ IAM Policy

• Pod-Level Isolation: Each pod receives its own temporary service token mounted inside the container filesystem.
• Granular Least Privilege: Pod A (Frontend) can read public assets, while Pod B (Backend) can write to sensitive databases on the same physical worker node.

4. Binding Policies to Resource Principals and OKE Workload Identity

OCI Functions Policy Pattern

Allow service FaaS to use buckets in compartment Production-Data where target.compartment.id = 'ocid1.compartment.oc1..prod'

OKE Workload Identity Policy Pattern

Allow dynamic-group OKE-Pod-DynamicGroup to manage objects in compartment Production-Data

5. OCI Web Console (GUI) Step-by-Step Walkthrough

Configuring Resource Principals and OKE Workload Identity is managed directly in the OCI Web Console GUI.

Step 1: Configuring Dynamic Groups for OKE Workload Identity

1. Log in to the Oracle Cloud Console (https://cloud.oracle.com).
2. Open Navigation Menu (≡) ➔ Identity & Security ➔ Domains ➔ Select Domain (e.g., Default).
3. Click Dynamic Groups ➔ Create Dynamic Group.
4. Enter:
5. Name: OKE-Backend-Pod-Group
6. Matching Rule:
   text
All {resource.type = 'fnfunc', resource.compartment.id = 'ocid1.compartment.oc1..prod'}
7. Click Create.

Step 2: Granting Policy Access to the Resource Principal Group

1. Open Identity & Security ➔ Policies.
2. Select Production-Data compartment.
3. Click Create Policy.
4. Enter statement:
   text
Allow dynamic-group OKE-Backend-Pod-Group to read buckets in compartment Production-Data
5. Click Create.

6. Common Architectural Misconceptions & Pitfalls

Misconception 1: “Resource Principals Are Identical to Instance Principals”

• Reality: Instance Principals authenticate the underlying Virtual Machine host. Resource Principals authenticate short-lived serverless runtime environments (OCI Functions, Cloud Shell execution environments) independently of host VMs.

Misconception 2: “All Pods on an OKE Worker Node Share the Same OCI Permissions”

• Reality: With OKE Workload Identity, pods acquire unique token identities based on their assigned Kubernetes Service Account. Permissions are isolated per Pod, not per worker node.

7. OCI Resource Principals vs. Google Cloud (GCP) Workload Identity

For cloud architects familiar with Google Cloud, the following table compares container/serverless workload authentication: