Security concepts in Azure Kubernetes Service (AKS)
In this tutorial, we will learn about the security concepts for applications and clusters in Azure Kubernetes Service (AKS). This includes master security, node security, compute isolation, cluster upgrades, network security, Azure network security groups, and Kubernetes Secrets.
However, while running application workloads on Azure Kubernetes Service (AKS), the security of your cluster is a critical factor for securing your client data. Security components such as network policies and Secrets are included in Kubernetes. Azure then adds features like network security groups and managed cluster updates to this. These security components work together to keep the AKS cluster up to date on OS security and Kubernetes releases while also safeguarding pod traffic.
Master security
- In AKS, the Kubernetes master components are part of the managed service that Microsoft provides.
- However, each AKS cluster has its own single-tenanted, dedicated Kubernetes master to provide the API Server, Scheduler, etc. Microsoft manages and maintains this master’s security.
- The Kubernetes API server is configured to utilise a public IP address and a fully qualified domain name by default (FQDN).
- Moreover, you can limit access to the API server endpoint using authorized IP ranges. And, can also create a fully private cluster for limiting API server access to your virtual network.
Node security
- AKS nodes refer to the Azure virtual machines that you manage and maintain. However, the Linux nodes run an optimized Ubuntu distribution using the Moby container runtime. And, the Windows Server nodes run an optimized Windows Server 2019 release and also use the Moby container runtime.
- In this, the Azure platform automatically applies OS security patches to Linux nodes on a nightly basis. And, if a Linux OS security update requires a host reboot, then the reboot does not perform automatically. That means, you can manually reboot the Linux nodes, or a common approach is to use Kured, an open-source reboot daemon for Kubernetes.
- However, the term Kured runs as a DaemonSet and is responsible for monitoring every node for the presence of a file indicating that a reboot is necessary.
- Further, for Windows Server nodes, Windows Update does not automatically run and apply the latest updates.
- On a regular schedule around the Windows Update release cycle, you should perform an upgrade on the Windows Server node pool in your AKS cluster. This procedure generates nodes that run the most recent Windows Server image and patches, then deletes the previous nodes.
Compute isolation
- Certain workloads may need a high degree of isolation from other customer workloads due to compliance or regulatory requirements. And, for these workloads, Azure provides isolated virtual machines, which can be useful as the agent nodes in an AKS cluster.
- These virtual machines are unique to a specific hardware type and dedicated to a single customer.
- So, for using these isolated virtual machines with an AKS cluster, select one of the isolated virtual machines sizes listed here as the Node size when creating an AKS cluster or adding a node pool.
Cluster upgrades
For security and compliance, or to use the latest features, Azure offers tools to set up the upgrade of an AKS cluster and components. However, this upgrade includes both the Kubernetes master and agent components. And, you can view a list of available Kubernetes versions for your AKS cluster. For starting the upgrade process, you specify one of these available versions.
Cordon and drain
During the upgrading process, AKS nodes are individually cordoning from the cluster so new pods do not schedule on them. Then, the nodes upgrading and draining are as follow:
- Firstly, a new node deploys into the node pool. This node runs the latest OS image and patches.
- Secondly, one of the existing nodes is identified for an upgrade. However, pods on this node are gracefully terminated and scheduled on the other nodes in the node pool.
- Thirdly, this existing node is deleted from the AKS cluster.
- Lastly, the next node in the cluster is cordoned and drained using the same process until all nodes are successfully replaced as part of the upgrade process.
Network security
- In this, you can deploy your AKS cluster into existing Azure virtual network subnets for connectivity and security with on-premises networks.
- However, these virtual networks may have an Azure Site-to-Site VPN or Express Route connection back to your on-premises network. And, the Kubernetes ingress controllers can be defined with private, internal IP addresses so services are only accessible over this internal network connection.
Azure network security groups
- For filtering the traffic flow in virtual networks, Azure uses network security group rules. These rules define the source and destination IP ranges, ports, and protocols that has access or denied access to resources.
- However, these default rules created to allow TLS traffic to the Kubernetes API server. AKS automatically modifies the network security group for traffic to flow appropriately when you create services with load balancers, port mappings, or ingress routes.
Kubernetes Secrets
- A Kubernetes Secret is responsible for injecting sensitive data into pods like access credentials or keys.
- In this, firstly, you create a Secret using the Kubernetes API and when you define your pod or deployment, a specific Secret can be requested.
- Secrets are only given to nodes with scheduled pods that need it. However, when the last pod on a node that needs a Secret is deleted, then the Secret is deleted from the node’s tmpfs.
- However, the use of Secrets reduces the sensitive information that is in the pod or service YAML manifest. But, you request the Secret stored in Kubernetes API Server as part of your YAML manifest. This approach only gives specific pod access to the Secret. Lastly, Kubernetes secrets stores in etcd, a distributed key-value store.
Reference: Microsoft Documentation