Introduction
In this blog post, we will explore the security considerations on whether or not to use a private or public K8s API server when setting up Azure Kubernetes Service (AKS).
There is an accompanying GitHub repository with examples at https://github.com/fredrkl/private-aks-demo, and MS provides a full guide at https://learn.microsoft.com/en-us/azure/aks/private-clusters?tabs=azure-portal.
The main difference between Private and Public AKS API server
When setting up an Azure Kubernetes Service (AKS) cluster, the main difference between having the Kubernetes API server public and private lies in the accessibility of the management plane of the cluster: the control plane.
With a public API server, the cluster control plane is accessible over the internet, making it easier for developers to change their applications. However, this increases the exposure to potential security risks if not properly secured.
A private API server restricts access to the cluster within a virtual network, providing an additional layer of security.
It is important to stress that with a managed offering like AKS, the control plane is 100% managed by Microsoft, thus reducing the operational load and exposure to related security issues.
Application accessibility
Even though the control plane goes down, the applications will still run in the data plane. The security risk we are discussing here concerns the unauthorized configuration change in the applications and their overall systems from the control plane. One such change could be to scale an application to zero, effectively taking down applications.
Control and Data plane communication
The communication between the control and data plane in Kubernetes is secured through a secure TLS channel known as the kubelet API. All communication between the control plane components themselves and worker nodes is encrypted using TLS. The kubelet API also uses mutual authentication, and both the worker nodes and the control plane can verify each other's identity.
In a public AKS cluster, the communication is done over the internet, whereas in a private AKS cluster, the communication is done through a private endpoint, keeping the traffic off the internet. AKS has a new feature in preview: public AKS cluster with VNet integration. This is the same as a public AKS setup, except the communication between the control and data plane is internal. The VNet integration feature has the ability to make the API server private, resulting in a “simplified private AKS setup.”
AKS Control plane security features
The Azure Kubernetes Service (AKS) API server provides several security features beyond API server accessibility. These include:
- Azure Active Directory (Azure AD) Integration: AKS supports Azure AD integration, allowing you to authenticate and authorize users, groups, and applications using Azure AD credentials.
- Role-Based Access Control (RBAC): AKS uses RBAC to control access to cluster resources. You can define fine-grained access policies to grant or restrict permissions to specific users or groups.
- Azure Policy: AKS integrates with Azure Policy, which enables you to define and enforce policies to ensure compliance and security standards within the cluster.
- Network Security: AKS supports network security groups (NSGs) and virtual network service endpoints to control inbound and outbound traffic to the cluster, enhancing network security.
More security is not necessarily better security
More components in a security chain do not necessarily guarantee better security. In fact, having more components can increase the risk of misconfigurations and vulnerabilities. Each additional component introduces complexity, increasing the chances of human error or oversight. It is crucial to ensure that each component is properly configured and maintained to prevent any potential security gaps. Although a private cluster setup reduces the control plane exposure, it does complicate the setup with jump host, bastion service, and private DNS.
The main argument for private cluster
The main argument for using a private Azure Kubernetes Service (AKS) cluster, considering all the factors mentioned above, is to ensure that any security vulnerabilities or misconfigurations are inaccessible to the public. Imagine a newly found bug in the latest K8s API Server.
Conclusion
In conclusion, the decision to use a private or public Azure Kubernetes Service (AKS) cluster largely depends on your organization's specific needs and security posture. Both private and public clusters provide robust security features, but each has its own considerations. A public AKS cluster can provide easy accessibility, but it may also expose the cluster to potential security risks if not properly secured. On the other hand, a private AKS cluster can offer an increased level of security by limiting access to a virtual network, but it may also introduce more complexity and potential for misconfigurations. Therefore, it's essential to thoroughly evaluate the pros and cons of each setup and consider the implications of your choice on your overall security strategy.