Oracle Kubernetes Engine (OKE) Hardening: IAM, Workload Identity, Networking and Node Pools

An OKE cluster inherits two permission systems, OCI IAM and Kubernetes RBAC, and a third, easily forgotten identity: the instance principal of every worker node, which any pod can reach through the metadata endpoint unless you block it. Most OKE compromises do not need a Kubernetes zero-day; they use a public API endpoint, an over-broad binding, a node credential or an unsigned image. This guide covers the OKE-specific controls that close those paths: how IAM and RBAC combine, workload identity in place of instance principals, private VCN-native clusters, network security groups and network policy, node pool isolation, image verification, secrets encryption with OCI Vault and API server audit logging. It is for platform engineers and cloud security teams running OKE in production. Generic Kubernetes hardening is in the Kubernetes Security Guide and tenancy-wide controls in the Oracle Cloud Infrastructure Security Guide; this page goes deeper on OKE itself. Facts are from Oracle's documentation, checked 8 November 2026.

This is an independent guide from NHI Mgmt Group, based on Oracle's public documentation as of November 2026. It is not sponsored or reviewed by Oracle. Product features change, so confirm settings against Oracle's current documentation.

Key takeaways

• Either IAM or RBAC can authorise a request. OKE lets an operation succeed if at least one of OCI IAM or Kubernetes RBAC permits it, so review both layers together, never one in isolation.
• Use workload identity, not node credentials. Workload identity scopes OCI permissions to a cluster, namespace and service account; instance principals give every pod on the node the same access. It needs an enhanced cluster.
• Make the cluster private. Put the Kubernetes API endpoint and all worker nodes in private subnets of a VCN-native cluster, and control traffic with NSGs plus Kubernetes network policy.
• Compartments and node selectors are not security boundaries. Oracle states OKE is not suitable for hard multi-tenancy: separate mutually distrusted workloads into separate clusters, and isolate OCI access with separate node pools.
• Enforce what runs and record what changes. Turn on image verification for signed OCIR images, use a customer-managed Vault key for etcd secrets where policy requires it, and monitor API server events in OCI Audit.

How identity and access work in Oracle Kubernetes Engine

OKE uses OCI IAM for cluster-level operations (creating and deleting clusters, adding and changing node pools) and the Kubernetes RBAC Authorizer for fine-grained, in-cluster control. Oracle documents that the two work together so that a user authorised by at least one of them can complete the Kubernetes operation. The exception is creating a Role or ClusterRole: RBAC checks that you already hold privileges at least equal to the role you are creating, which blocks self-escalation.

RBAC subjects are OCIDs. Bindings name the IAM principal by OCID, for example a ClusterRoleBinding to cluster-admin for --user=ocid1.user.oc1.., or a RoleBinding whose subject is kind: Group with a group OCID. Bind groups, not individuals, so that joiner and leaver changes in IAM flow through. For RBAC design patterns see the Kubernetes RBAC Guide.

Admin roles and privileged access

• cluster-admin: Oracle's guidance is to avoid the built-in cluster-admin ClusterRole, which grants super-user rights across all namespaces. Keep at most a break-glass binding to a small group OCID and alert on its use.
• Indirect privilege: Oracle warns that permission to create Deployments implies permission to create Pods, and deleting a Node reschedules its Pods elsewhere. Review custom roles for these paths, plus escalate, bind, impersonate and write access to Secrets.
• IAM cluster permissions: a statement such as Allow group acme-developer-group to use clusters in compartment dev lets users download a kubeconfig; it does not by itself grant workload rights. Reserve manage on cluster resources for the platform team, because it covers creating and deleting clusters and node pools.
• Administrators group: tenancy administrators already have full OKE access. Use separate administrator accounts, phishing-resistant MFA and the controls in the Oracle Cloud Infrastructure Security Guide.
• Node access: SSH keys for worker nodes are privileged credentials. Prefer no SSH key on managed nodes and use the OCI Bastion service or node cycling to replace a suspect node instead of logging in.

Integrations, API tokens and service accounts

Workload identity

Workload identity lets a pod authenticate to OCI as a workload identified by cluster, namespace and Kubernetes service account. Policies use any-user narrowed by conditions, for example:

Allow any-user to manage objects in compartment finance where all {request.principal.type = 'workload', request.principal.namespace = 'finance', request.principal.service_account = 'financeserviceaccount', request.principal.cluster_id = '<cluster-ocid>'}

• Requirements: an enhanced cluster, a supported OCI SDK (Oracle lists minimum versions for Go, Java, Python, .NET and Ruby) and a pod spec with serviceAccountName and automountServiceAccountToken: true.
• Limits: workload identities cannot be used with dynamic groups, and only through the SDK, not the Console or raw API.
• Cross-compartment mappings: a workload mapping created with oci ce workload-mapping create applies to every workload in the namespace; add a request.principal.service_account condition to keep access per service account.
• Least privilege: always include all four conditions. A policy missing cluster_id trusts any cluster with a matching namespace and service account name.

Instance principals and the metadata endpoint

Oracle notes that all pods on a node can reach the instance principal certificates through the instance metadata endpoint. If a workload genuinely needs instance principals, schedule it on a dedicated node pool whose dynamic group grants only that workload's permissions (Oracle's example separates a log archiver needing Object Storage from a host monitor needing the Compute API). For every other pod, block 169.254.0.0/16: the preferred method is a network policy plugin with a default-deny policy and explicit egress grants; Oracle documents an iptables rule on the node as a fallback. Neither affects host-network pods. This path maps to ATT&CK T1552.005 Cloud Instance Metadata API.

Automation tokens

For CI/CD, Oracle recommends a Kubernetes service account token added to a kubeconfig rather than a personal token. Treat it as a non-human identity: one service account per pipeline and namespace, stored in OCI Vault or the pipeline's secret store, rotated, and never copied into repositories. Keep application credentials out of code and in OCI Vault. See the Kubernetes NHI Security Guide and the OCI Vault guide.

Network and node pool hardening

• Terraform and NSGs: when the cloud controller manager edits security lists for LoadBalancer services, Terraform sees drift and reverts it, which can break services. Oracle recommends NSGs with the oci.oraclecloud.com/security-rule-management-mode annotation.
• Isolation by trust level: Oracle states that compartments are not a security boundary for node pools (any workload can schedule on any node pool), and that node selectors, affinity and taints are conventions. Different trust levels, such as production and development or customer code, need separate clusters.
• Node patching: worker nodes run a hardened Linux image on which the container runtime, kubelet and kube-proxy depend. Update node images regularly and apply the CIS Kubernetes Benchmark to workers; on enhanced clusters, node cycling cordons, drains and replaces nodes during node pool updates and version upgrades.
• Pod security: OKE enables the PodSecurity admission controller by default from Kubernetes 1.23, and PodSecurityPolicy is unsupported from 1.25. Label namespaces with the Restricted profile wherever possible, run as non-root with a read-only root filesystem, and set quotas and limit ranges. See the Kubernetes Admission Control Guide.
• Add-ons: Oracle does not recommend the Kubernetes Dashboard or Tiller in production. If the dashboard is enabled, never expose it through a load balancer or ingress. An exposed, unauthenticated dashboard combined with a pod holding cloud credentials gives an attacker a direct path to your cloud account.

Image integrity and secrets encryption

Image verification policy: on the cluster's Image Verification tab you can require that images from OCI Registry are signed by at least one of up to five RSA master encryption keys in OCI Vault. Once enforcement is on, manifests must reference images by digest, not tag. If the policy is enabled with no keys, any signed or unsigned image can be pulled, so a policy without keys gives no protection. Pods annotated oracle.image-policy.k8s.io/break-glass: "true" bypass the policy: alert on that annotation. The cluster needs IAM statements to use the keys and read repositories, conditioned on its OCID. Images from other registries are not enforced, so pair this with an admission policy that only allows your OCIR repositories. See the Container Image Security Guide.

Secrets at rest: by default Oracle encrypts block volume data, including etcd and Kubernetes Secrets, with an Oracle-managed key. You can instead use a customer-managed master encryption key in OCI Vault with envelope encryption (a new data key per secret, wrapped by the master key). Points to plan:

• The key can only be chosen in the Custom Create workflow and cannot be added to an existing cluster.
• Oracle recommends a policy-only grant, conditioned on request.principal.type = 'cluster' and the key OCID, then narrowed to the cluster OCID after creation.
• Deleting or scheduling deletion of the key makes the cluster's secrets inaccessible; if deletion completes the cluster must be recreated. Protect the key with IAM and Vault deletion alerts.
• Rotating the key creates a new version; existing secrets stay on the old version until re-written (Oracle documents annotating all secrets to force re-encryption).

Encryption at rest does not stop anyone with RBAC read on Secrets. For stronger patterns see the Kubernetes Secrets Security Guide.

Logging and detection

OKE writes cluster operations (for example cluster create and delete) and Kubernetes API server administrative changes (for example creating a service with kubectl) to OCI Audit. In the Console, search Audit with the keyword ClustersAPI for OKE operations and OKE API Server Admin Access for API server operations; programmatic access is through the Audit ListEvents API. Requests made with workload identity are also recorded in OCI Audit. Forward events to your SIEM and keep them in a protected store; see the Kubernetes Audit Log Detection Guide.

Metrics: percentage of clusters with private API endpoints; number of cluster-admin bindings (target: break-glass only); percentage of pods calling OCI through workload identity rather than instance principals; percentage of namespaces enforcing the Restricted Pod Security profile; percentage of running images pulled by digest from verified OCIR repositories; median age of worker node images.

Hardening baseline

A phased rollout for an existing OKE estate. Test each phase on a non-production cluster first and keep the previous configuration (Terraform state, policy versions) so you can roll back.

1. Inventory: list clusters, type (basic or enhanced), Kubernetes version, endpoint visibility, node pools and their dynamic groups, and every RBAC binding to OCIDs.
2. Close the control plane: move to VCN-native clusters with a private API endpoint. Access from operators goes through a bastion or VPN.
3. Fix identity: remove standing cluster-admin bindings, bind groups not users, upgrade basic clusters that need it to enhanced (only VCN-native basic clusters can be upgraded, and enhanced cannot be downgraded) and move pods from instance principals to workload identity one namespace at a time.
4. Segment: install a network policy plugin, apply default-deny per namespace in audit-friendly steps (start with egress to metadata), and tighten NSGs.
5. Enforce workloads: set PodSecurity labels to warn, then enforce Restricted; switch manifests to digests, then enable image verification with keys.
6. Protect secrets: for new clusters requiring it, use a customer-managed Vault key; for all clusters, review who can read Secrets.
7. Monitor and benchmark: wire OCI Audit and flow logs to the SIEM, and assess against the CIS Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) Benchmark on a schedule.

Common misconfigurations

• Public API endpoint kept "for convenience": the cluster is reachable from the internet and depends entirely on token hygiene.
• Instance principals with broad dynamic groups: one compromised pod inherits every permission the node has. Move to workload identity and block metadata.
• Workload identity policies without cluster_id: any cluster with the same namespace and service account name gains access.
• Image verification enabled with no keys: the policy looks on but allows everything; tag-based manifests also fail once enforcement starts, which tempts teams to use the break-glass annotation permanently.
• Trusting compartments and taints for isolation: Oracle explicitly says neither is a security boundary.
• Kubernetes Dashboard exposed through a load balancer: keep it internal, behind authentication, or remove it.

Practitioner checklist

• Every cluster is VCN-native with a private Kubernetes API endpoint and private worker subnets.
• RBAC bindings use group OCIDs; cluster-admin is break-glass only and alerted.
• Pods use workload identity with all four principal conditions; instance principals are isolated by node pool.
• Pod access to 169.254.0.0/16 is blocked by default-deny network policy.
• NSGs, not security lists, carry cluster rules, with the security-rule-management annotation for load balancers.
• Namespaces enforce the Restricted Pod Security profile; quotas and limit ranges are set.
• Image verification is enabled with at least one Vault key; manifests use digests; break-glass annotations alert.
• Vault keys for etcd encryption are protected from deletion and rotated with a documented re-encryption step.
• OCI Audit events (ClustersAPI and OKE API Server Admin Access) and VCN Flow Logs reach the SIEM.
• Worker node images are patched on a schedule and assessed against the CIS OKE Benchmark.

Standards and references

• Oracle: Securing Kubernetes Engine (OKE)
• Oracle: OKE Security Best Practices
• Oracle: About Access Control and Kubernetes Engine (OKE)
• Oracle: Granting Workloads Access to OCI Resources (Workload Identity)
• Oracle: Enforcing the Use of Signed Images from Registry
• Oracle: Encrypting Kubernetes Secrets at Rest in Etcd
• Oracle: Viewing Kubernetes API Server Audit Logs
• MITRE ATT&CK: Cloud Instance Metadata API

Related NHI Mgmt Group resources: Kubernetes Security Guide · Oracle Cloud Infrastructure Security Guide · Kubernetes NHI Security Guide · OCI Vault