Oracle Cloud Infrastructure (OCI) Container Engine for Kubernetes (OKE) reduces the operational burden of setting up and managing enterprise-grade Kubernetes clusters. We recognize that Kubernetes and its ecosystem is complex, so we built OKE with the following design principles in mind:
Secure by default: OKE hardens Kubernetes clusters following Enterprise Security best practices.
Simplified Kubernetes operations: Oracle manages your cluster resources and automates recurrent Kubernetes administration and scaling tasks.
High performance: Containerized applications run on high-performance Compute resources through OCI's non-blocking network.
Today, we’re excited to announce the general availability of fully private Kubernetes clusters for Oracle Container Engine for Kubernetes (OKE). You can now create fully private OKE clusters that don’t use or expose any public IPs.
Organizations require robust access control to their Kubernetes Clusters to meet their security and compliance needs. This requires fully integrating Kubernetes clusters with your virtual cloud network (VCN). In OKE, your cluster worker nodes and load balancers are already part of the VCN, you can now add the Kubernetes API endpoint to the VCN too.
Kubernetes administrators configure the Kubernetes API endpoint of a cluster as part of a private or public subnet. Regular VCN routing and firewall rules control the access to the Kubernetes API endpoint and make it accessible from a corporate network only, through a bastion host, or by specific SaaS services. Let's explore these three use cases.
First, to access the Kubernetes API endpoint from authorized subnets in a corporate network, specify a private subnet for your endpoint. In this case, you would typically peer your VCN to your corporate network using OCI FastConnect, which provides an easy way to create a dedicated, private connection between your data center and Oracle Cloud Infrastructure.
Second, if you don't peer your corporate network, you can use a bastion host, which provides access to resources on a private network. To access your API endpoint through a bastion host, configure the endpoint to a private subnet in your VCN and a bastion server on a public subnet. Kubernetes users can set up an SSH tunnel through a bastion to interact with their Kubernetes API endpoint.
Finally, you might also want to configure the Kubernetes API endpoint on a public subnet of a VCN. For example, this configuration can be useful when your continuous integration-continuous delivery (CI/CD) pipeline runs on a third-party SaaS CI/CD service. In this case, restrict the access to your Kubernetes API endpoint to the SaaS service network IPs.
To learn more or get hands-on, use the following resources: