Container Security with AKS in Microsoft Azure

Containers can make software delivery more efficient, scalable, and portable. Nonetheless, their security must be approached differently and requires certain best practices. If your application is built in Microsoft Azure and uses Azure Kubernetes Service (AKS), it is already benefiting from a set of features that will naturally increase the security of your containers. Nonetheless, Azure offers several advanced Kubernetes features that will do nothing to keep your passwords and confidential information safe unless enabled. While the default configurations will help, truly keeping your containers secure requires more advanced practices. Take this quiz to find out how well you’re doing.

Question Title

* 1. Am I planning to connect my on-premise environment to Azure for use with Azure Kubernetes Service (AKS)?

Basic networking can still be used if you don’t need to connect to an existing Azure or on-prem Virtual Network. Nonetheless, advanced networking and firewalls will offer an extra layer of security to containerized applications. This is especially true when there is a need to connect to an existing Azure or on-prem Virtual Network. Azure’s advanced networking automatically puts AKS Clusters into preconfigured VNETs that transmit traffic to NSGs that are created by default. Click here to learn more about how to configure Advanced Networking into your AKS clusters.

Question Title

* 2. How do I authenticate my users and deployment systems to my Kubernetes clusters?

Credentials retrieved by az aks get-credients are admin-level based users that have absolute access to your system. These credentials can destroy deployments and cause havoc if they fall into the wrong hands. In contrast, RBAC restricts access to authorized users, meaning that individual permissions don’t need to be manually assigned to each user. Azure Active Directory (AD) is an identity provider that will secure your Kubernetes API-Server endpoints when you create AKS Clusters. It is already integrated with Azure and is essential for truly securing your containers in Azure.

Question Title

* 3. How do I authenticate my Kubernetes cluster to pull images from Azure Container Registry?

Service Principals in Azure function as Service Accounts instead of interactive users. Granting service principals access to Azure Container Registry (ACR) during configuration will eliminate the need to pull secrets to Kubernetes. The AKS Cluster will already have the appropriate permissions to pull from that registry. Keep Service Principal admin profiles to the minimum required access rights and create different profiles for different Clusters.

If you’re authenticating your Kubernetes clusters with Kubernetes secrets, you’re enabling Admin level passwords on your Docker registry that is used for Kubernetes. Thus, no one can compromise your images stored in an Azure Container Registry. Azure’s Service Principal means you don’t have to worry about manually changing passwords (rotating passwords), which is typically done every 60 to 90 days.

Question Title

* 4. Have I automated Node reboots?

Outdated OSes are more likely to have exploited security flaws, so it’s good keep your OSes up to date by automating the rebooting of your Nodes to apply security patches. This will prevent configuration drift, which will open your application to known vulnerabilities. AKS Nodes automatically download and install OS updates and security fixes, but they don’t reboot automatically. Maintain a regular cadence of rebooting your Nodes to keep your OS secure.

Question Title

* 5. Am I using Namespaces, Limit Ranges, and Quotas?

Namespaces are important for segregating clusters. They can greatly increase security when linked to Limit Ranges and Quotas. As CPU and memory resources that aren’t constrained are prone to consuming much more than needed, Limit Ranges and Quotas can ensure that all Namespaces have access to equal security. To keep your containers secure, start off by assigning Pod request limits to minimize the influence that workloads have over each other.

Question Title

* 6. Do I limit SSH access to Container Hosts?

It’s standard practice to limit SSH access to VMs in traditional environments, and this carries over to containers. Limiting SSH access to Container Hosts will minimize breaches to the kernel they occurred within.

Question Title

* 7. Am I using Container Image Vulnerability Scanning tools?

It’s standard practice to use some type of anti-virus tool or intrusion detection software that scans applications to alert users of vulnerabilities. As containers carry security risks of their own, containerized environments should use Container Image Vulnerability Scanning tools that are aware of these security risks. Microscanner is a free image vulnerability scanner that can be a good start.

Question Title

* 8. How am I exposing the Kubernetes dashboard to users?

If you answered yes, you’re accessing the dashboard via a secure Transport Layer Security (TLS) port-forwarding mechanism, which makes your containers much more secure. This allows you to avoid exposing the endpoints of your Kubernetes dashboard publicly and makes for much more secure access to your Kubernetes User Interface.

Any dashboard being exposed via Ingress controller of Load Balancer without any authentication mechanisms, especially the dashboard that is included out-of-the-box with Azure Kubernetes Service (AKS), would be very easy to exploit. The dashboard could be used to create cryptocurrency miners or delete all your production environments with the click of a button.

Question Title

* 9. We have a few tips to keep your containers more secure in Azure. Where should we send them to?

0 of 9 answered