A customer planning guide for reviewing IAM policies, validating node pool workflows, and aligning to a more consistent authorization path.
OCI Kubernetes Engine (OKE) is strengthening the authorization path used for node pool operations. By August 7, 2026, node pool workflows are expected to authorize through the node pool resource principal rather than rely on a service principal fallback. This update is intended to make the authorization model for node pool operations more explicit and more consistent with OCI security best practices. OCI security guidance emphasizes least-privilege access, secure configuration, and monitoring of activity across cloud resources. Customers should review IAM policies tied to affected node pool workflows, validate the updated configuration in a non-production environment, and roll changes into production.
What is Changing
OKE node pool workflows perform operations such as create, scale, upgrade, and update on your behalf. Going forward, customers should plan for those workflows to authorize through the node pool resource principal. For customers that use custom images, customer-managed encryption keys, or shared resources across compartments or tenancies, this is the right time to review how those node pool operations are authorized and confirm that required permissions are in place through the intended policy path.
What is Not Changing
- This transition primarily affects node pool operations, not steady-state running workloads.
- Authentication remains OCI IAM-based.
- This is a tightening of the authorization path and customer policy control model, not a change to the way customers authenticate to OCI.
Who Should Review Configuration Now
Customers should prioritize review and action if they use any of the following:
- Custom images for worker nodes, including shared or cross-tenancy image references
- Customer-managed keys for worker node boot volume encryption
- Shared images or keys across compartments or tenancies
- Operational runbooks that depend on scaling, upgrading, or updating node pools
Scenarios to Review
Custom Images and Cross-Tenancy Image Access
If your node pools rely on custom images, especially images referenced across compartment or tenancy boundaries, review whether the node pool resource principal has the access it needs to consume those images under the updated authorization path.
Customer-Managed Keys for Boot Volume Encryption
If worker node boot volumes use customer-managed KMS keys, review both IAM and key access configuration. The goal is to confirm that the intended node pool workflow can use the required key path without depending on broader fallback behavior.
Shared Resources Across Compartments or Tenancies
If your architecture centralizes images or keys in separate compartments or tenancies, validate that your policy scoping still lines up with how the node pool workflow is authorized.
Recommended Migration Plan
Here’s the step–by-step guide to ensure node pool workflows are authorized through the node pool resource principal. Our instructions will cover
- Scoping where change is needed
- Preparing to execute the change
- Example Policy Pattern for Shared Images Across Tenancies
- Validation after change
1. Scoping where change is needed
Start by identifying whether your environment uses cross-tenancy images, customer-managed keys, or other shared resources that need explicit policy review under the node pool resource principal model.
- Cross-Tenancy Images. If your node pools rely on images that are hosted in another tenancy, review whether the node pool resource principal has the access it needs to inspect and read those images under the updated authorization path.
- Customer-Managed Keys for Boot Volume Encryption. If worker node boot volumes use customer-managed KMS keys, review both IAM and key access configuration. Confirm that the node pool workflow can use the required key path through the intended configuration.
- Shared Resources Across Compartments or Tenancies. If your architecture centralizes images or keys in separate compartments or tenancies, validate that your policy scoping still lines up with how the node pool workflow is authorized.
2. Preparing to execute the change
Once you identify the affected node pools, work through the policy and validation steps below to update the authorization path in a controlled way.
1. Identify managed node pools that create nodes from images outside the node pool tenancy.
2. For each affected node pool, confirm which tenancy hosts the image and whether the image is shared across compartments or tenancies.
3. Add or verify the paired cross-tenancy IAM policies required for the image-hosting tenancy and the node pool tenancy.
4. Review any related KMS or shared-resource policies that the node pool workflow depends on.
5. Test the updated configuration in a non-production environment.
6. Validate with a create-node-pool or scale-up action so the workflow provisions new worker nodes through the updated authorization path.
7. Roll the policy changes into production before August 7, 2026.
3. Example Policy Pattern for Shared Images Across Tenancies
The following examples are sanitized versions of the internal policy patterns. Replace the tenancy aliases and OCIDs with values from your environment.
In the node pool tenancy
“`text
define tenancy image-tenancy as ocid1.tenancy.oc1..<image-tenancy-ocid>
endorse any-user to {INSTANCE_IMAGE_INSPECT, INSTANCE_IMAGE_READ} in tenancy image-tenancy where request.principal.type = ‘nodepool’
“`
In the image-hosting tenancy
“`text
define tenancy nodepool-tenancy as ocid1.tenancy.oc1..<nodepool-tenancy-ocid>
admit any-user of tenancy nodepool-tenancy to {INSTANCE_IMAGE_INSPECT, INSTANCE_IMAGE_READ} where request.principal.type = ‘nodepool’
“`
If the image and the node pool are already in the same tenancy, this specific cross-tenancy image policy pattern might not be required.
4. Validation Approach
After the policy changes are in place, validate with a routine node pool action that creates new worker nodes. A create-node-pool or scale-up operation is a practical test because it exercises the image-access path directly.
If the operation fails, recheck the policy placement, tenancy aliases, and the resource-principal condition before promoting the change more broadly.
Additional Resources
Oracle Cloud Infrastructure policy reference
Oracle Cloud Infrastructure cross-tenancy access policies
Oracle Kubernetes Engine custom images documentation
Oracle Cloud Infrastructure Security Overview