The Kubernetes Control Plane and runtime are inherently complex and often misunderstood.   They defy standardization especially when you consider all the plug-ins and deployment options that are available to implementers.  

Having been in architecture and leadership roles with input regarding the security posture of Kubernetes deployments for various DevOps teams, I’ve seen designs and implementations that are all over the board.   The good news is that there are some standards available to help drive Best Practices driven security posture such as the CIS Kubernetes Benchmarks for cloud provider implementations and stand-alone deployments.    But even with this level of guidance for stand-alone deployments there are many knobs to turn and plenty of areas where configurations may deviate not to mention the level of constant oversight required to ensure consistent security posture.

 

The Kubernetes Attack Surface

A quick look at some of the moving parts of the Kubernetes framework shows the breadth of the attack surface of the platform. 

This includes components such as:
  1. The kube-api server
  2. Kubelets on the nodes
  3. The master node itself
  4. The cluster and it’s respective compute nodes 
  5.  etcd database.  

 

Kubernetes Misconfiguration

It is well reported that many stand-alone Kubernetes deployments both in cloud environments and on-premise have been and continue to be compromised by way of misconfiguration.   

A stand-alone deployment would be a manual installation of the Kubernetes framework on physical or virtual machines managed entirely by the installer/implementer.    By taking on the full responsibility of the managing the platform its security posture is the complete responsibility of the implementer.    

 

Potential areas of misconfiguration when self-managing:
  1. Etcd database protection and encryption.
  2. Kubernetes key management
  3. Container image scanning, signing and verification.
  4. Appropriately configuring Kubernetes Audit capabilities.
  5. Configuring Kubernetes to adhere to the principle of least privilege.
  6. Pod Security Policy configurations
  7. Secure Namespace configuration
  8. HA and DR configurations and administration.

 

With Kubernetes still being relatively new to many shops and with all the deployment options that are available it can introduce significant risk.

 

Figure 2 –

figure2

 

Aside from stand-alone deployments various cloud providers have PaaS oriented Managed Services offerings for Kubernetes deployments.    In OCI there are a few offerings to consider including:

  1. OCI OKE (Oracle Container Engine for Kubernetes)
  2. OCI Container Instances (Oracle Serverless Kubernetes)

 

By outsourcing the administration of the Kubernetes framework the risk associated with deploying, running and managing the Kubernetes platform is now transferred to the cloud provider.   In Oracle’s case that would be by way of OCI OKE and/or OCI Container Instances.  

 

Let’s take a quick look at the two.

 

Figure 3 – Oracle Kubernetes Engine Shared Responsibility Model

k8sharedresponsibility

As you can see in the diagram above, Oracle takes on the management of the Kubernetes control plane in the OKE model.   The customer is only responsible for managing the individual nodes within the cluster.   Oracle also provides a managed and secure container registry which can be used to deploy container images across the managed environment.    The OCI Container Registry supports native vulnerability scanning in OCI. 

 

Figure 4 – OCI Container Instances Shared Responsibility Model 

k8containerservices

 

In the OCI Container Instances deployment model Oracle takes on administration of the Kubernetes Server Nodes as well making deploying containers a completely serverless and “Kubernetes-less” process thus offloading those security and administration responsibilities to the provider.

 

By leveraging Oracle Managed Kubernetes Services you can leverage OCI “Secure By Default” configurations:

 

  1. Private clusters and node pools
  2. Network security at multiple levels –
    1. Security Groups
    2. Security Lists
    3. Network Policy
    4. VCN Native Pod Networking
    5. Persistent data encrypted at-rest and in-transit
    6. Container image vulnerability scanning, signing and verification
    7. CIS Benchmarks and STIG guidelines for cluster hardening
    8. Enable zero trust with OCI Service Mesh.

 

So, as you and your teams consider the use of Kubernetes you should consider managed Kubernetes services.   By doing so your developers and security teams can focus more on business benefits as opposed to the “undifferentiated heavy lifting” and risk associated with managing the Kubernetes platform itself.