Security concepts in AKS on Azure Stack HCI
Security in AKS on Azure Stack HCI involves securing the infrastructure and the applications running on the Kubernetes cluster. This topic covers the security hardening measures and the built-in security features used to secure the infrastructure and the applications on Kubernetes clusters.
AKS on Azure Stack HCI applies various security measures to secure its infrastructure. The following diagram highlights these measures:
The table below describes the security hardening aspects of AKS on Azure Stack HCI that are shown in the previous diagram. For conceptual background information on AKS on Azure Stack HCI infrastructure, see clusters and workloads.
|1||Because the AKS host has access to all of the workload (target) clusters, this cluster could be a single point of compromise. However, access to the AKS host is carefully controlled as the management cluster's purpose is limited to provisioning workload clusters and collecting aggregated cluster metrics.|
|2||To reduce deployment cost and complexity, workload clusters share the underlying Windows Server. However, depending on the security needs, admins can choose to deploy a workload cluster on a dedicated Windows Server. When workload clusters share the underlying Windows Server, each cluster is deployed as a virtual machine, which ensures strong isolation guarantees between the workload clusters.|
|3||Customer workloads are deployed as containers and share the same virtual machine. The containers are process-isolated from one another, which is a weaker form of isolation compared to strong isolation guarantees offered by virtual machines.|
|4||Containers communicate with each other over an overlay network. Admins can configure Calico policies to define networking isolation rules between containers. Calico supports both Windows and Linux containers and is an open-source product that is supported as-is.|
|5||Communication between built-in Kubernetes components of AKS on Azure Stack HCI, including communication between the API server and the container host, is encrypted via certificates. AKS on Azure Stack HCI offers an out-of-the-box certificate provisioning, renewal, and revocation for built-in certificates.|
|6||Communication with the API server from Windows client machines is secured using AD credentials for users.|
|7||For every release, Microsoft provides the VHDs for AKS on Azure Stack HCI VMs and applies the appropriate security patches when needed.|
The table below describes the different application security options available in AKS on Azure Stack HCI.
You have the option to use open source application hardening options available in the open source ecosystem if you choose.
|Build security||The goal for securing builds is to prevent vulnerabilities from being introduced in the application code or in the container images when the images are generated. Integration with Azure GitOps of Arc enabled Kubernetes helps with analysis and observation, which allows developers the opportunity to fix security issues. For more information, see Deploy configurations using GitOps on an Azure Arc enabled Kubernetes cluster.|
|Container registry security||The goal for container registry security is to ensure vulnerabilities are not introduced when uploading container images into the registry, while the image is stored in the registry, and during image downloads from the registry. AKS on Azure Stack HCI recommends using Azure Container Registry (ACR). ACR comes with vulnerability scanning and other security features. For more information, see the Azure Container Registry documentation.|
|AD identities for Windows workloads using gMSA for containers||Windows container workloads can inherit the identity of the container host and use that for authentication. With new enhancements, container host doesn’t need to be domain joined. For more information, see gMSA integration for Windows workloads.|
Security built-in features
The security built-in features that are currently available in AKS on Azure Stack HCI are listed in the table below.
|Protect access to API server.||Active Directory single sign-in support for PowerShell and Windows Admin Center clients. This feature is currently enabled only for workload clusters.|
|Ensure all communication between built-in Kubernetes components of the control plane is secure. This includes making sure that communication between the API server and workload cluster is also secure.||Zero touch built-in certificate solution to provision, renew, and revoke certificates. To learn more, see Secure communication with certificates.|
|Rotate encryption keys of the Kubernetes secret store (etcd) using the Key Management Server (KMS) plug-in.||Plug-in for integrating and orchestrating key rotation with specified KMS provider. To learn more, see Encrypt etcd secrets.|
|Real-time threat monitoring for containers that supports workloads for both Windows and Linux containers.||Integration with Azure Defender for Arc enabled Kubernetes, which is offered as a public preview feature until the GA release of Kubernetes threat detection for Azure Arc enabled Kubernetes. For more information, see Defend Azure Arc enabled Kubernetes clusters.|
|AD identity for Windows workloads.||Use gMSA integration for Windows workloads to configure AD identity.|
|Support for Calico policies to secure traffic between pods||To use Calico policies, see Secure traffic between pods using network policies.|
In this topic, you learned about the concepts for securing AKS on Azure Stack HCI and about securing applications on Kubernetes clusters.