→ Back to Home
Crossplane

OCI Extends Workload Identity to Self-Managed Clusters, Eliminating Static Crossplane Secrets

Oracle Cloud Infrastructure (OCI) has announced Workload Identity support for self-managed Kubernetes clusters, expanding identity federation capabilities that were previously restricted to managed OKE environments. The mechanism enables Kubernetes controllers and workloads to exchange projected service account tokens for short-lived OCI Resource Principal Session Tokens (RPST) via OCI IAM Identity Propagation Trust, directly binding Kubernetes service account identities to fine-grained OCI IAM policies. For platform engineers running Crossplane control planes or self-hosted operators on custom Kubernetes deployments, this release removes a long-standing security trade-off. Previously, managing OCI resources via Crossplane providers on self-managed clusters required either storing long-lived, sensitive API signing keys within Kubernetes Secrets or assigning broad instance principals to entire worker nodes. The latter compromised multi-tenant isolation, granting every pod on a node equal access to cloud infrastructure APIs. This development aligns with the broader cloud-native movement toward zero-trust infrastructure automation and passwordless control planes. As organizations adopt Crossplane and other Kubernetes-native composition frameworks to build internal developer platforms (IDPs), credential hygiene has surfaced as a major compliance hurdle. Major cloud providers have embraced OIDC-based workload identity federation (such as AWS IRSA and GCP Workload Identity), and extending equivalent token-exchange parity to self-managed and hybrid clusters is critical for unified multi-cloud governance. In practice, platform teams can now configure the Crossplane Provider for OCI using projected service account tokens rather than static credentials across on-premises, edge, or bespoke cloud compute instances. When deploying Crossplane Compositions that provision databases, object storage, or network peering, controllers assume precisely scoped OCI IAM roles on the fly. To implement this, operators must establish Identity Propagation Trust for their cluster's token issuer in OCI IAM and update provider runtime configurations to leverage token exchange endpoints.
#crossplane#kubernetes#security#cloud-native#iam#oci
Read original source