There are many components that make up a Secure by default Azure Kubernetes Service Deployment. This blog post is meant to demystify this conversation.
Authentication and Authorization
Starting at the top with Authentication and Authorization there are a few things to think about. The default is to deploy a cluster with local authentication enabled, meaning you are logging onto the cluster as a local admin/user with a certificate. This is not a secure configuration and if you want to continue to use local authentication then you limit access to the cluster configuration file.
A more secure alternative would be to AAD enable the AKS cluster through Managed AAD. This allows users to logon to the cluster with AAD accounts/groups and allows administrators to leverage things like Conditional Access or Just in Time access for those users. The key to understand with this deployment is that by default local authentication is still enabled. So even though you have configured AAD users can bypass the RBAC configuration deployed for the user by specifying --admin in there az aks get-credentials call. In order to close this backdoor we have a new feature to disable local accounts with that AAD enablement.
Once you have Authentication answered, now you have some choices for Authorization. If you are deploying a local authentication cluster than K8s RBAC is your only option. If you have AAD enabled your AKS deployment then you have Azure RBAC or K8s RBAC that can be leveraged to provide a more secure and robust authorization story.
In order to have a secure deployment it is recommended to deploy an AAD enabled cluster with local accounts disabled. This will force users to use the AAD configuration specified by the administrators without a backdoor, and secures elevation of privilege possibilities by removing the local accounts and there certificates.
Identity
Currently, an Azure Kubernetes Service (AKS) cluster (specifically, the Kubernetes cloud provider) requires an identity to create additional resources like load balancers and managed disks in Azure. This identity can be either a managed identity or a service principal. If you use a service principal, you must either provide one or AKS creates one on your behalf. If you use managed identity, this will be created for you by AKS automatically. Clusters using service principals eventually reach a state in which the service principal must be renewed to keep the cluster working. Managing service principals adds complexity, which is why it's easier to use managed identities instead. The same permission requirements apply for both service principals and managed identities.
Managed identities are essentially a wrapper around service principals, and make their management simpler. Credential rotation for MI happens automatically every 46 days according to Azure Active Directory default. AKS uses both system-assigned and user-assigned managed identity types.
It is recommended to leverage Managed Identity, which is the default deployment, with Azure Kubernetes Service to simplify and secure the administration of Identity in support of the cluster. If you currently have a Service Principal based AKS cluster you can upgrade that cluster to Managed Identity without having to redeploy a new cluster.
Network Security
Next you want to think about your network security which for most customers is solved by deploying a Private AKS cluster. This will put the API server and AKS worker node communication on the customer virtual network. From there customers need to think about how to make the API service accessible. This can be accomplished by Private DNS, or Public DNS.
Secondly, you want to think about the securing the pod traffic with network policies.
Lastly regarding networking restrict egress traffic through a firewall.
Azure Policy
There are many AKS Built-in policies to help you secure your AKS deployment. These policies cover feature enforcement, CIS standards, and security vulnerabilities, as well as Custom policies to extend your policy in any way your organization sees fit.
Azure Defender for Kubernetes
To round out the secure by default configuration enabling Azure Defender for Kubernetes gives customers Host level and Cluster level threat protection.
Azure Defender for container registries will help you secure images posted to Azure Container Registry with continuous scanning and reporting. In the same ASC SKU that enables ACR scanning there is also CI/CD scanning that can be enabled providing a Secure Pipeline capability natively.
Conclusion
The combination of Authentication and Authorization, Networking, Policy, and Azure Defender for Kubernetes gives customers a secure by default configuration to utilize natively in Azure.
So from a cli perspective it would look something like below:
"az aks create -g myResourceGroup -n myManagedCluster --enable-aad --aad-admin-group-object-ids <id> [--aad-tenant-id <id>] --disable-local-accounts --enable-private-cluster --enable-managed-identity --assign-identity <ResourceId> --private-dns-zone <private-dns-zone-mode> --disable-public-fqdn enable-addons --addons azure-policy"
The above is an example but obviously if using Terraform or ARM you will want to grab the same configurations. Azure Defender for Kubernetes can be attached via Azure Security Center.
Posted at https://sl.advdat.com/3oVpDFf
