Microsoft Azure Kubernetes Service (AKS) is a fully managed Kubernetes cloud container orchestration that simplifies the deployment, management, and scaling of containerized applications in Azure. As you move your workloads to AKS, security becomes increasingly critical to ensure compliance and maintain the integrity of running applications.
This article covers key technologies and best practices related to access, network, data, and logging management for AKS security.
Best practices for AKS Security
A brief rundown of the best practices covered in this article are
Best practice | Description |
---|---|
Access management in AKS security | Authentication and authorization services for AKS access management |
Network management in AKS security | Network security components designed to secure AKS clusters |
Data protection for AKS security | Protect data and applications on AKS clusters |
Monitoring and logging | Stay compliant with industry standards and requirements |
Overview of AKS architecture
AKS provides a managed Kubernetes service that reduces the complexity of deploying and managing Kubernetes clusters. The Azure platform manages the control plane, while the customer is responsible for the nodes.
Overview of the AKS service showing the Azure-managed vs. customer-managed components (Source).
From a security perspective, you are responsible for access management of the AKS service, container security from build to running in AKS, and network security of nodes.
Access management in AKS security
The authentication and authorization process in AKS deployments restricts unauthorized access to your AKS service. Below are some authentication and authorization mechanisms you can use to ensure that only authorized users interact with the applications and systems running inside an AKS cluster.
Azure Active Directory
Azure Active Directory (AAD) provides a centralized authentication mechanism for access control management. It leverages existing identities for authentication and allows integration with other Azure services. To use AAD authentication with an AKS deployment, you must:
- Create an Azure AD application (App Registration)
- Assign appropriate permissions to access AKS.
The Azure AD application is a service principal between AAD and AKS and handles all access requests. We recommend using a separate Azure AD application for each cluster for a multiple AKS cluster group.
For more information, see Azure AD integration with AKS.
Role-based access control
Role-based access control (RBAC) allows you to define fine-grained access policies based on roles and distribute access flexibly across systems. You can use pre-defined roles like developers, admin, DBA, and readers to provide access based on user requirements without giving unnecessary permissions.
AKS security provides the following built-in roles:
- Azure Kubernetes Service RBAC Reader
- Azure Kubernetes Service RBAC Writer
- Azure Kubernetes Service RBAC Admin
- Azure Kubernetes Service RBAC Cluster Admin
We recommend following the principle of least privilege – when assigning roles to users, only grant those permissions they need to perform tasks. Also, always grant permission to groups and not individual users.
Kubernetes role bindings
Kubernetes uses service accounts (objects) to run applications and services with different access levels to the AKS cluster. Role binding in AKS and Kubernetes allows administrators to create roles with specific permissions and assign the role to a service account.
The process is similar to RBAC but offers more granular permissions to revoke easily. For example, a service account can have read permissions while another can have write permission to the same resource. We recommend separating service accounts for different applications or services.
Network management in AKS security
Network security protects sensitive data in AKS from unauthorized access during transit. The following components need attention to secure any AKS deployment in a cluster or non-cluster configuration.
Network modes
In AKS, there are two virtual networking models to consider:
- Kubenet networking
- Azure Container Networking Interface (CNI) networking
For most production deployments, Microsoft recommends using the Azure CNI network. Microsoft only recommends Kubenet for the following:
- Small development or testing workloads
- Low-traffic volume websites
- Lifting and shifting of workloads into containers
Use Azure CNI for integration with existing virtual networks or on-premise networks. Azure CNI allows the separation of control and management of resources. For example, the virtual network resource is in a separate resource group, enabling different teams to manage and secure those resources.
Azure Virtual Network
VNet in Microsoft Azure gives you the option to leverage multiple network security features like:
- Packet inspections
- Network access control lists (ACLs)
- User-defined routes
- Virtual network gateways (VPN)
VNet integration isolates the AKS cluster from other virtual networks in Azure and gives you greater control over cluster inbound and outbound traffic.
Network policies
By default, all pods in an AKS cluster can send and receive traffic without restrictions, and the Kubernetes API server uses a public IP address and a fully qualified domain name (FQDN).
You should define rules to control the flow of network traffic. For example, you can limit access to the API server endpoint using authorized IP ranges. If applicable to your workloads, create a fully private cluster to limit API server access to your virtual network.
Network policies are the security rules that define how services and pods inside the cluster communicate with external resources and services. Kubernetes also has native network policies that extend cluster capabilities and enforce security at the network level. They give you granular control over network traffic in and out of pods. You can apply the policies to:
- IP Addresses
- Namespaces
- Ports
You can configure the policies using Azure native tools or third-party resources like Paladin Cloud Azure Policy based on best practices.
Best Practices for Azure Network Policies
The following items can help build good foundations around security, reliability, and performance of network policies.
Network Security Groups (NSG) – NSGs are virtual firewalls allowing us to filter inbound and outbound traffic based on IPs, Network ports, and protocols.
Azure Virtual Network (VNet) – Use VNets to separate applications and services and prevent unauthorized access. We can also use VNets to segment the network based on security and functionality.
DDoS Protection – Safeguard applications and services from Distributed Denial of Service (DDoS) attacks.
TLS protocol
Another AKS security best practice is to use Transport Layer Security (TLS) protocol for network communication cryptography. Services and applications enforce TLS to protect sensitive information and prevent man-in-the-middle attacks.
AKS allows administrators to use TLS-based mutual authentication and encryption between clients and servers. You can use mechanisms like TLS certificates and keys to configure application and service endpoints in AKS. Kubernetes secrets can store the certificates and keys for the AKS clusters.
Data protection for AKS security
AKS contains container images, configurations, and confidential application data you must secure.
Configuration data
To decouple pod configurations from the application source code, AKS ConfigMaps store configuration data that pods use to run within the cluster. The ConfigMaps are made of YAML or JSON files and use key-value pairs to provide application configurations. For instance, the map may contain a database URL and API key needed to connect to it. You can protect sensitive information within the ConfigMaps using Azure Key Vault.
Azure Key Vault offers security keys and secrets management services that can seamlessly integrate with Azure AKS. The service allows AKS to programmatically access the following:
- Passwords
- Secrets
- API Keys
- Certificates
- Sensitive information.
By using Key Vault, AKS can store and access secrets securely from the applications and services running within the cluster without actually storing them locally on the cluster.
We recommend regularly rotating secrets and keys and taking regular backups for disaster recovery.
Container images
Azure Container Registry(ACR) is an Azure service allowing you to store and manage the container images you deploy to AKS. ACR provides a private storage location protected by security policies and authentication mechanisms like:
- RBAC
- Image replication
- Vulnerability scanning
Organizations can sign their container images with digital signatures for additional security. We recommend using minimal image layers and updating all images with the latest security patching. Conduct static analysis of image builds to discover vulnerabilities before they are deployed. For information on how Microsoft manages security vulnerabilities, see Vulnerability management for Azure Kubernetes Service. Base image updates are applied automatically to address security fixes. AKS Linux node images are updated weekly, and Windows node images are updated monthly.
Additionally, you can integrate vulnerability scanning tools into AKS and give the cluster permission to review ACR images before deployment. You can also incorporate runtime security tools to check the container runtime layer for unusual behavior.
Paladin Cloud serves as an enterprise security efficacy platform with a prioritization engine that integrates with third-party vulnerability scanning solutions, such as Qualys, Tenable and Aqua, to correlate findings with misconfigurations in multi and hybrid cloud environments.
Monitoring and logging
Monitoring and logging provide visibility into your existing AKS security measures and are essential for compliance and auditing. Azure provides services like Azure Monitor and Azure Log Analytics to connect and analyze AKS logs for visibility into the backplane and containers.
Organizations must establish robust alerting mechanisms based on the logs to detect potential security incidents. Azure Monitor has limited capabilities to report performance and security incidents. Paladin Cloud monitors multiple AKS deployments to identify security risks to ensure governance and compliance with CIS regulatory benchmarks.
Paladin Cloud UI has a centralized monitoring view.
Conclusion
Organizations can increase their overall cloud security posture and compliance level by securing their AKS deployments. Authentication, network management, and protection of configuration files and container images are essential for AKS security. Monitoring and logging are also crucial to ensure AKS meets regulatory compliance requirements post-deployment. You also require ongoing processes to validate, update and maintain AKS security measures over time.