OKE Security Best Practices

Securing an OKE cluster is not one control, it is several layers, and a gap in any one of them undermines the rest. A cluster with perfect network policy but an open API endpoint is not secure. A cluster with strict IAM but unscanned images is not secure. The teams that get this right think in layers, putting controls at each point where an attacker would need to get through, so that defeating one does not defeat the cluster. This article lays out those layers and what belongs in each.

It is part of our OKE and containers series and complements the cluster design in OKE cluster architecture.

The layers of cluster security

OKE security spans the cloud control layer, the cluster access layer, the workload layer and the supply chain. Each addresses a different question. Who can manage the cluster in OCI? Who can do what inside Kubernetes? Which pods can talk to which? And can you trust the images you run? Treating these as one undifferentiated problem leads to gaps. Treating them as distinct layers, each with its own controls, leads to defence in depth.

Cloud control: IAM and compartments

At the OCI level, who can create, modify and delete the cluster and its resources is governed by IAM policies. The principle is least privilege: grant each person and service only the permissions they need, scoped to the compartment that holds the cluster. Putting the cluster in its own compartment makes this easier, because you can write policies against the compartment rather than the whole tenancy. This is the outermost layer and the one most often left too broad.

Cluster access: RBAC and the API endpoint

Inside Kubernetes, role based access control governs what authenticated users and service accounts can do. The goal again is least privilege: a developer who needs to deploy to one namespace should not have cluster wide admin. Equally important is where the API endpoint lives. A private endpoint, reachable only through a bastion or VPN, removes the cluster's control plane from the public internet entirely, which is the single most valuable access control you can apply. An open endpoint is an invitation.

Workload layer: network policy, pod security and secrets

Within the cluster, three controls matter. Network policy restricts which pods can communicate, so a compromised pod cannot freely reach the rest of the cluster, as covered in OKE networking explained. Pod security standards constrain what pods can do, preventing them from running as root or with dangerous privileges unless explicitly allowed. And secrets management keeps sensitive values such as credentials out of plain configuration, ideally backed by the OCI vault rather than stored in the clear. Together these contain the blast radius if a single workload is compromised.

Workload identity: credentials without secrets

Pods often need to call OCI services, and the wrong way to enable that is to embed long lived credentials in the pod. Workload identity, available on enhanced clusters, lets a pod assume OCI permissions based on its identity in the cluster, with no static credentials to leak or rotate. This is a meaningful security improvement over baked in keys, and it is a reason to run enhanced clusters for anything that touches other OCI services.

Supply chain: trusting your images

You cannot secure a cluster while running images you do not trust. Image scanning in the container registry checks images for known vulnerabilities before they run, and you should treat a failed scan as a blocker, not a warning. Beyond scanning, signing images and pulling only from trusted registries prevents tampered or unknown images from reaching the cluster. The supply chain is an increasingly common attack path, and an unscanned image is a hole no amount of network policy will cover.

Node security

The worker nodes themselves are part of the attack surface. They need to run hardened, current images and to be patched on a schedule, because a node with a known unpatched vulnerability is a foothold. Virtual nodes remove this concern by removing the nodes you manage, which is a security argument in their favour for suitable workloads, covered in OKE virtual nodes explained. For managed node pools, node patching belongs in your operational routine, tied to the upgrade discipline in OKE upgrade strategy.

A security checklist

Auditing and detection

Prevention is most of security, but not all of it. You also need to see what is happening. Kubernetes audit logging and OCI logging together give you a record of who did what, and integrating cluster telemetry into your monitoring lets you alarm on suspicious activity, covered in monitoring OKE with OCI tools. The combination of strong prevention and good detection is what lets you both reduce the chance of compromise and notice it quickly if it happens.

Bringing it together

OKE security is layered by nature, and the strength of the whole is the strength of the weakest layer. IAM and a private endpoint keep the wrong people out, RBAC and network policy limit what anyone inside can do, image scanning and workload identity secure what runs, and node hardening or virtual nodes close the infrastructure gap. Put all the layers in place and the cluster is genuinely defensible. Leave one out and the rest do less than you think. Continue with OKE networking explained and OKE upgrade strategy.

The OCI security and compliance practice reviews and hardens OKE clusters to this layered model on a project or managed basis.