Kubernetes comes with many challenges, and one of them is security. Managed Kubernetes solutions like Azure Kubernetes Service (AKS) take many tasks off your plate, but what about AKS security? Teams can gain confidence here by implementing practices that have become industry standards and go-to methods for the Kubernetes community. Here are the 10 AKS security practices you need to secure your clusters.
What is AKS security?
Azure Kubernetes Service (AKS) is a cloud-based service for deploying, managing and securing containerized applications on Kubernetes. AKS takes care of control plane maintenance and health monitoring, leaving you to manage and maintain worker nodes.
Like any other managed Kubernetes service, AKS still requires you to come up with a security plan for your deployment. You're responsible for configuring secure configurations, building security into the architecture, setting up secure network communications within your cluster, and maintaining other aspects of the system, such as upgrade management.
To protect a cluster running on AKS, users can leverage the built-in security features in AKS and add some Kubernetes-specific security best practices to the mix. We cover the most important ones below. Additionally, it would help if you considered secure configurations recommended by the industry itself (for example, CIS benchmarks).
Basics of security for Azure Kubernetes Service (AKS)
Pod and cluster security
Azure provides a number of predefined security policies that improve the security posture of your AKS clusters and pods.
One of the key best practices is based on limiting access to container operations and preventing root/privilege escalations. Luckily, an Azure Policy add-on for AKS allows you to install a managed instance of OPA Gatekeeper, an open-source Kubernetes admission controller.
What exactly is Gatekeeper? It works by checking every request that creates or updates a resource. Also, it supports RBAC integration with Azure Active Directory (AD) or other identity providers. This brings fine-grained access, which is very similar to how you control access to other Microsoft Azure resources. It additionally opens the door to logging and auditing on all of the API server operations.
Azure also provides tools for orchestrating cluster and component upgrades to the latest version of Kubernetes. This helps you maintain compliance and security, as well as get access to the latest Kubernetes features. Both Kubernetes masters and agents are included in this upgrade orchestration as Azure upgrades each AKS node.
Network security
AKS provides security policies you can use to secure clusters and pods. Some of these policies include:
- Ingress controllers - use ingress controllers to say who can access internal IP addresses, making internal IPs accessible only from your internal network.
- Filtering network traffic - only allow network traffic from authorized networks based on IP address or namespace.
- Web application firewall (WAF) - using the Azure WAF solution together with an egress firewall allows you to manage predefined routes in and out of an environment.
- Network security groups - implement finer-grained control by applying security groups to AKS resources, allowing specific ports and protocols based on source/destination. By default, AKS creates a subnet-level security group for your cluster. Security groups change automatically when you add services such as load balancers, port mappings, and ingress routing.
Master security
AKS manages, maintains, and provides the Kubernetes master components as part of its service. AKS clusters include a single-tenant Kubernetes master, where you can find features such as the API Server and Kubernetes Scheduler.
In AKS, the API server has a public IP address with a domain name. If you need to restrict API access, you can limit access to specific IP ranges or create private clusters inside an Azure Virtual Network (VNet). All in all, you end up managing access via RBAC and Kubernetes RBAC privileges.
10 proven AKS security practices
1. Think twice about running containers in privileged mode
Does your deployment have containers running in privileged (root) mode? This lets the container get access to important host resources and - as a result - brings about some security problems.
Don't run containers in privileged mode. Alternatively, you can turn the podSecurityPolicy on and then set the privileged parameter to false. This is how you make sure that no container can run processes that require root privileges on the host.
2. Avoid sharing the host's IPC or network namespace
Do your pods share the host's IPC or network namespace? Sharing namespaces for pod and host interprocess communication can be tricky. It poses a security issue because it may open access to this shared information.
That's why it's an industry best practice to keep pods from accessing host namespaces because it lets network access to the host network from the pod. As a result, you're dealing with a broken network isolation.
What can you do about it? Set the hostNetwork parameter to false in PodSecurityPolicy, and you'll sleep much better at night, confident that your cluster is secure.
3. Make sure to isolate Kubernetes nodes
Another best practice is not exposing your Kubernetes nodes to public networks directly. Instead, locate your nodes on a separate network so they don't have any direct connection to the general company network.
Isolate Kubernetes control and data traffic isolated, so they don't flow through the same pipe. Open access to the data plane means open access to the control plane, which is bad news for AKS security. Make sure to configure nodes with the help of an ingress controller and set it to only give access to connections from the master node via a specified port in the network access control list (ACL).
4. Use Kubernetes Role-Based Access Control (RBAC)
Use RBAC to define who has access to the Kubernetes API and based on what permissions. In Kubernetes 1.6 and higher, RBAC is usually enabled by default. Since Kubernetes brings together authorization controllers, you can disable the Attribute Based Access Control (ABAC) when you use RBAC.
To tighten your cluster security further, pick namespace-specific permissions over cluster-wide permissions. Even when you're debugging your application, you should refrain from granting cluster administrator privileges. If you do, you risk compromising your container security.
5. Avoid using the root file system for container security
Are your containers running without a read-only root file system? Expect security issues to arise soon.
Do yourself a favor and use a read-only file system. This helps to avoid all kinds of malicious binaries, be it writing to a system or facing a system takeover. Double-check that your containers use only the read-only file system and set the readOnlyRootFilesystem to true in Pod securityContext definition.
6. Boost authentication and authorization
Another best practice is integrating Kubernetes with a third-party authentication provider to get an extra layer of security, like multi-factor authentication.
For secure control plane access, avoid managing users at the level of the API server but use the Azure Active Directory and Azure RBAC. Choose OpenID Connect (OIDC) together with an SSO provider that you've got, if you can't get CSP IAM.1
7. Disable NET_RAW
If your containers don't drop the NET_RAW capability, you might let in various networking exploits from inside the cluster. To boost your AKS security, take advantage of Policy Enforcement solutions such as Open Policy Agents, Kyverno, or Kubernetes Pod Security admission controller.
Additionally, you can set drop for ALL or NET_RAW capabilities in the pod's securityContext definition. This is how you ensure that the NET_RAW capability is disabled.2,3
8. Double check unsafe /proc mount
Containers with unsafe /proc mount (procMount=Unmasked) let others bypass the default masking behavior of the container runtime. If you set your Kubernetes container with Unmasked /proc mount type, you might expose the host information to that container.
Why is that a bad idea? You're looking at problems like data leaks or container escapes. Set procMount=Default to ensure your container doesn't expose any parts of /proc.
9. Don't keep secrets in an environment variable
It's a good practice to have your secret outside an environment variable. The reason for that is that other parts of your system can access environment variables. Use secrets as files or leverage secretKeyRef to minimize threats. You can also leverage Azure Key Vault service to store and access your secrets securely.4
10. Develop a rolling update strategy
To keep your AKS security tight, build a rolling update strategy. Rolling updates allow deployment updates to minimize application downtime by updating pod instances with new ones incrementally.
Another good practice is to run a vulnerability scan at runtime to prevent supply chain attacks. That way, you can see what really got to your cluster - even if you carried out a scan of your deployment artifacts in the CI/CD stage.
If you’re using third-party tools, you might install them via vendor-provided scripts - as a result, bypassing security tools built into your CI/CD. Agent-based security solutions give you more accurate and deeper insights than "agentless" ones.
Achieve AKS security with expert help
As the Kubernetes ecosystem grows, so do its security concerns. To stay on top of emerging threats, engineers must learn how to prioritize security issues and track them effectively.
With CAST AI's Kubernetes Security feature, you can scan your cluster against industry best practices, Kubernetes recommendations, and container security system benchmarks to identify vulnerabilities and set yourself up for success right from the start.
Scan your Kubernetes cluster against a curated list of configuration and security best practices, and find out how to secure it optimally.
Check your Kubernetes cluster against configuration and security best practices
Connect your cluster and see your costs in 5 min, no credit card required.
References
- [1] - Kubernetes documentation
- [2]- Kubernetes documentation
- [3] - Kubernetes documentation
- [4] - Microsoft
Top comments (0)