Profile Applicability:
Level 1
Description:
When creating an Azure Kubernetes Service (AKS) cluster, it is a best practice to use private nodes to ensure that the worker nodes in the cluster are not exposed to the public internet. This check ensures that AKS clusters are configured with private nodes, meaning that the nodes will only be accessible within a private network, enhancing the security of the cluster.
Rationale:
Private nodes provide better security by isolating the worker nodes from the public internet. This minimizes the attack surface and ensures that the nodes are not exposed to unauthorized access. Using private nodes also helps with compliance requirements for environments that need to be fully isolated from public networks.
Impact:
Pros:
Enhances security by isolating AKS worker nodes from the public internet.
Reduces the potential attack surface by ensuring that nodes are not publicly accessible.
Better compliance for environments requiring private network isolation.
Cons:
Requires additional network configuration, such as a private VNet.
External access to worker nodes might require a VPN or Azure Bastion for management purposes.
Default Value:
By default, AKS clusters are created with nodes that have access to the public internet. Private nodes need to be explicitly configured during cluster creation.
Pre-requisites:
Ensure that a private VNet is configured for the AKS cluster and that there is proper network setup for private node access (e.g., private subnets).
Remediation
Test Plan:
Using Azure Console:
Navigate to the Azure portal and access your Azure Kubernetes Service (AKS) cluster.
Under Networking, review the Node Pool Configuration to ensure that Private Nodes are enabled.
Ensure that the nodes are created in a private subnet and verify that the nodes are not exposed to the public internet.
Using Azure CLI:
Use the following command to check if private nodes are enabled in your AKS cluster:
az aks show --resource-group <resource-group-name> --name <aks-cluster-name> --query "nodeResourceGroup"
Ensure that the result shows the node pool is configured with private nodes and located in a private subnet.
Implementation Plan:
Using Azure Console:
In the Azure portal, create or modify your AKS cluster.
Under Networking, select Private Cluster to ensure the nodes are private.
Configure the node pool to use a private subnet.
Ensure that public IPs are not assigned to the nodes during cluster creation.
Using Azure CLI:
Create a new AKS cluster with private nodes enabled by running the following command:
az aks create --resource-group <resource-group-name> --name <aks-cluster-name> --enable-private-cluster --no-public-ip
Verify that the node pool is created with private nodes by using the command:
az aks show --resource-group <resource-group-name> --name <aks-cluster-name> --query "nodeResourceGroup"
To enable private nodes on an existing cluster, run:
az aks update --resource-group <resource-group-name> --name <aks-cluster-name> --enable-private-cluster
Backout Plan:
Using Azure Console:
If using private nodes causes issues, revert the configuration in the Azure portal by disabling Private Cluster and enabling public access to nodes.
Using Azure CLI:
Revert the cluster settings to use public nodes by running:
az aks update --resource-group <resource-group-name> --name <aks-cluster-name> --disable-private-cluster