Securing AKS Network Connections

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 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 lax security and do pretty much whatever they want in your cluster.

In this chapter, we will explore Kubernetes secrets in more depth. You will learn about different secrets backends and how to use them. You'll get a brief introduction to service mesh concepts, and you'll be able to follow along with a practical example.

The following topics will be covered briefly in this chapter:

• SSH secrets management
• The Istio service mesh at your service

...

Technical requirements

You will require a modern browser, such as Chrome, Firefox, or Edge, for this chapter.

Setting up secrets management

All production applications require some secret information to function. Kubernetes has a pluggable secrets backend to manage these secrets. Kubernetes also provides multiple ways of using the secrets in your deployment. The ability to manage secrets and properly use the secrets backend will make your services resistant to attacks.

We have used secrets in all our deployments in previous chapters. Mostly, we passed the secrets as a string in some kind of variable, or Helm took care of creating the secrets for us. In Kubernetes, secrets are a resource just like pods and replica sets. There are no cluster-wide secrets, which can cause a number of long debugging sessions. Secrets have to be (re)created in all the namespaces where you want to use them. In this section, we'll learn how to create, decode, and use our own secrets.

...

The Istio service mesh at your service

We have found a number of ways to secure our pods, but our network connections are still open. Any pod in the cluster can talk to any other pod in the same cluster. As a site reliability engineer, you will want to enforce both ingress and egress rules. As a developer, you don't want to be bothered by it as you won't have information on where your application will be deployed, as well as what is allowed and what is not. If only there was a way that we could run the applications as is, while still specifying network policies.

Enter service mesh—this is defined as the layer that controls service-to-service communication. Just as with microservices, service mesh implementation is not a free lunch. If you don't have hundreds of microservices running, you probably don't need a service mesh. If you decide that you really...

Summary

In this chapter, we learned how to secure secrets in Kubernetes. We went into detail in creating, decoding, and using secrets. We installed and injected Istio, achieving the goal of being able to set system-wide policies without needing developer intervention or oversight. Since hackers like to pick on easy systems, the skills that we have learned in this chapter will help to make your setup less likely to be targeted. In the next chapter, you will learn how to deploy serverless functions on AKS.