Oracle Kubernetes Engine is often introduced as a managed Kubernetes service, but its real strength only becomes clear when you operate it in production. OKE tightly integrates with OCI networking, identity, and security services, which gives you a very different operational model compared to other managed Kubernetes platforms.
This article walks through OKE from a production perspective, focusing on security boundaries, networking design, ingress exposure, private access, and mutual TLS. The goal is not to explain Kubernetes basics, but to explain how OKE behaves when you run regulated, enterprise workloads.
Understanding the OKE Networking Model
OKE does not abstract networking away from you. Every cluster is deeply tied to OCI VCN constructs.
Core Components
An OKE cluster consists of:
- A managed Kubernetes control plane
- Worker nodes running in OCI subnets
- OCI networking primitives controlling traffic flow
Key OCI resources involved:
- Virtual Cloud Network
- Subnets for control plane and workers
- Network Security Groups
- Route tables
- OCI Load Balancers
Unlike some platforms, security in OKE is enforced at multiple layers simultaneously.
Worker Node and Pod Networking
OKE uses OCI VCN-native networking. Pods receive IPs from the subnet CIDR through the OCI CNI plugin.
What this means in practice
- Pods are first-class citizens on the VCN
- Pod IPs are routable within the VCN
- Network policies and OCI NSGs both apply
Example subnet design:
VCN: 10.0.0.0/16
Worker Subnet: 10.0.10.0/24
Load Balancer Subnet: 10.0.20.0/24
Private Endpoint Subnet: 10.0.30.0/24
This design allows you to:
- Keep workers private
- Expose only ingress through OCI Load Balancer
- Control east-west traffic using Kubernetes NetworkPolicies and OCI NSGs together
Security Boundaries in OKE
Security in OKE is layered by design.
Layer 1: OCI IAM and Compartments
OKE clusters live inside OCI compartments. IAM policies control:
- Who can create or modify clusters
- Who can access worker nodes
- Who can manage load balancers and subnets
Example IAM policy snippet:
Allow group OKE-Admins to manage cluster-family in compartment OKE-PROD
Allow group OKE-Admins to manage virtual-network-family in compartment OKE-PROD
This separation is critical for regulated environments.
Layer 2: Network Security Groups
Network Security Groups act as virtual firewalls at the VNIC level.
Typical NSG rules:
- Allow node-to-node communication
- Allow ingress from load balancer subnet only
- Block all public inbound traffic
Example inbound NSG rule:
Source: 10.0.20.0/24
Protocol: TCP
Port: 443
This ensures only the OCI Load Balancer can reach your ingress controller.
Layer 3: Kubernetes Network Policies
NetworkPolicies control pod-level traffic.
Example policy allowing traffic only from ingress namespace:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-from-ingress
namespace: app-prod
spec:
podSelector: {}
ingress:
- from:
- namespaceSelector:
matchLabels:
role: ingress
This blocks all lateral movement by default.
Ingress Design in OKE
OKE integrates natively with OCI Load Balancer.
Public vs Private Ingress
You can deploy ingress in two modes:
- Public Load Balancer
- Internal Load Balancer
For production workloads, private ingress is strongly recommended.
Example service annotation for private ingress:
service.beta.kubernetes.io/oci-load-balancer-internal: "true"
service.beta.kubernetes.io/oci-load-balancer-subnet1: ocid1.subnet.oc1..
This ensures the load balancer has no public IP.
Private Access to the Cluster Control Plane
OKE supports private API endpoints.
When enabled:
- The Kubernetes API is accessible only from the VCN
- No public endpoint exists
This is critical for Zero Trust environments.
Operational impact:
- kubectl access requires VPN, Bastion, or OCI Cloud Shell inside the VCN
- CI/CD runners must have private connectivity
This dramatically reduces the attack surface.
Mutual TLS Inside OKE
TLS termination at ingress is not enough for sensitive workloads. Many enterprises require mTLS between services.
Typical mTLS Architecture
- TLS termination at ingress
- Internal mTLS between services
- Certificate management via Vault or cert-manager
Example cert-manager issuer using OCI Vault:
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: oci-vault-issuer
spec:
vault:
server: https://vault.oci.oraclecloud.com
path: pki/sign/oke
Each service receives:
- Its own certificate
- Short-lived credentials
- Automatic rotation
Traffic Flow Example
End-to-end request path:
- Client connects to OCI Load Balancer
- Load Balancer forwards traffic to NGINX Ingress
- Ingress enforces TLS and headers
- Service-to-service traffic uses mTLS
- NetworkPolicy restricts lateral movement
- NSGs enforce VCN-level boundaries
Every hop is authenticated and encrypted.
Observability and Security Visibility
OKE integrates with:
- OCI Logging
- OCI Flow Logs
- Kubernetes audit logs
This allows:
- Tracking ingress traffic
- Detecting unauthorized access attempts
- Correlating pod-level events with network flows
Regards
Osama
Technology Geek 