Securing Pods in Azure Kubernetes Service

Many Organisations neglect necessary security measures while designing their IT infrastructure and end up with a chaotic approach to incident management and mitigation. Security mostly works with the 20:80 rule, where 20% of the time spent on implementing security will make the environment 80% secure.

We hear a lot about Kubernetes cluster level security, node-level security but not about pod level security. In this article, I will try to cover the ways to secure the pods in AKS(Azure Kubernetes Service).

1. Pod security with Azure Policy

Azure policy integration enables the control to deny and audit pod requests to an AKS cluster that violates policy. It offers two built-in initiatives, baseline and restrictive which have different levels of controls to secure pods.

To secure AKS pods through Azure Policy, Azure Policy Add-on for AKS has to be installed on an AKS cluster. It runs 3 Gatekeeper components to run: 1 audit pod and 2 webhook pod replicas. Gatekeeper is a validating admission controller which is built on the open-source Open Policy Agent. It’s audit functionality allows administrators to see what resources are currently violating any given policy.

Built-in policy for Baseline initiative:

a) Disallow running of privileged containers

b) Disallow shared usage of host namespaces

c) Restrict all usage of host networking and ports

d) Restrict any usage of the host filesystem

e) Restrict Linux capabilities to the default set

Built-in policy for Restricted initiative: (Baseline initiate policies + below policies)

a) Restrict usage of defined volume types

b) Privilege escalation to root

c) Restrict the user and group IDs of the container

d) Restrict allocating an FSGroup that owns the pod’s volumes

e) Requires seccomp profile

Both these policy initiatives can be applied quickly using the set policy definitions, only the scope, parameters and effect have to be selected and everything else will be taken care of automatically.

Follow these links for policy definitions and implementations in Azure portal.

Baseline Initiative: https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicySetDefinitions%2Fa8640138-9b0a-4a28-b8cb-1666c838647d

Restircted Initiaitve: https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicySetDefinitions%2F42b8ef37-b724-4e24-bbc8-7a7708edfe00

Note: If you are using Azure preview feature of using security policies for pod then you have to first disable them before enabling the Azure policies. Both of them can’t be applied to AKS together. However, Microsoft is deprecating the security policy for AKS soon.

2. Using Azure Active Directory Pod identity

It’s not at all recommended to use fixed credentials within pods or container images. To overcome this issue, use pod identities to automatically request access using a central Azure AD identity solution.

The Azure Active Directory (AAD) pod identity is a service that gives users the required authorisation to access other Azure cloud resources and services by assigning identities to individual pods.

For e.g. If you integrate key management system(KMS) with Kubernetes using pod identity then secrets, certificates, and keys in a key management system become a volume accessible to pods. The volume is mounted into the pod, and its data is available directly in the container file system for your application.

AAD Pod Identity has two components: the Managed Identity Controller (MIC) and the Node Managed Identity (NMI).

The Managed Identity Controller (MIC) is a Kubernetes custom resource that watches for changes to pods, AzureIdentity and AzureIdentityBindings through the Kubernetes API server and whenever it detects a relevant change, the MIC adds or deletes AzureAssignedIdentity as needed.

The Node Managed Identity(NMI) server identifies the pod based on the remote address of the request and then queries Kubernetes (through MIC) for a matching Azure identity. NMI then makes an Azure Active Directory Authentication Library (ADAL) request to get the token for the client ID and returns it as a response. If the request had client ID as part of the query, it is validated against the admin-configured client ID.

Process of using Managed Identity by Pod:

1. Cluster operator first creates a service account that can be used to map identities when pods request access to services.
2. The NMI server and MIC are deployed to relay any pod requests for access tokens to Azure AD.
3. A developer deploys a pod with a managed identity that requests an access token through the NMI server.
4. The token is returned to the pod and used to access Azure SQL Database.

3. Network Policies for securing traffic between pods

By default, all pods in an AKS cluster can send and receive traffic without limitations. To improve pod level security, network policies can be defined to control the communication between the pods.

Using Network Policies, you define an ordered set of rules to send and receive traffic and apply them to a collection of pods that match one or more label selectors.

Azure provides two ways to implement network policy and only one can be chosen during AKS cluster creation.

• Azure’s own implementation, called Azure Network Policies.
• Calico Network Policies, an open-source network and network security solution

Some most recommended network policies for secuiting Pod communication are:

Deny all traffic to pod.

Allow traffic based on pod labels.

Allow traffic based on namespace.

To use Azure Network Policy, you must use the Azure CNI plug-in and define your own virtual network and subnets. However, Calico Network Policy can be used with either this same Azure CNI plug-in or with the Kubenet CNI plug-in.

The process to apply network policy for Pods:

• Creates a virtual network and subnet.
• Creates an Azure Active Directory (Azure AD) service principal for use with the AKS cluster.
• Assigns Contributor permissions for the AKS cluster service principal on the virtual network.
• Creates an AKS cluster in the defined virtual network and enables network policy.
• The Azure Network policy option is used. To use Calico as the network policy option instead, use the network-policy calico parameter. Note: Calico could be used with either network-plugin azure or network-plugin kubenet.

Conclusion

Remember that the above are just the pod level securities and to make your AKS cluster completely secure, you MUST implement cluster level, node level as well as identity level securities along with robust monitoring and logging.