Loose lips sink ships is a phrase that describes how easy it can be to jeopardize the security of a Kubernetes-managed cluster (Kubernetes, by the way, is Greek for helmsman, as in the helmsman of a ship). If your cluster is left open with the wrong ports or services exposed, or plain text is used for secrets in application definitions, bad actors can take advantage of this negligent security and do pretty much whatever they want in your cluster.
There are multiple items to consider when securing an Azure Kubernetes Service (AKS) cluster and workloads running on top of it. In this section, you will learn about four ways to secure your cluster and applications. You will learn about role-based access control in Kubernetes and how this can be integrated with Azure Active Directory (Azure AD). After that, you'll learn how to allow your pods to get access to Azure resources such as Blob Storage or Key Vault using an Azure AD pod identity. Subsequently, you'll learn about Kubernetes secrets and how to safely integrate them with Key Vault. Finally, you'll learn about network security and how to isolate your Kubernetes cluster.
In this chapter, you will be routinely deleting clusters and creating new clusters with new functionalities enabled. The reason you will delete existing clusters is to save costs and optimize the free trial, if you are using it.
This section contains the following chapters:
- Chapter 8, Role-based access control in AKS
- Chapter 9, Azure Active Directory pod-managed identities in AKS
- Chapter 10, Storing secrets in AKS
- Chapter 11, Network security in AKS
You will start this section with Chapter 8, Role-based access control in AKS, in which you will configure role-based access control in Kubernetes and integrate this with Azure AD.