Let's look at some other common recommendations for hardening your cluster in production. These use cases cover both intentional, malicious actions against your cluster, as well as accidental misuse. Let's take a look at what we can do to secure things.

First off, you want to ensure that access to the Kubernetes API is controlled. Given that all actions in Kubernetes are API-driven, we should secure this interface first. We can control access to this API with several settings:

• Encode all traffic: In order to keep communication secure, you should make sure that Transport Level Security (TLS) is set up for API communication in the cluster. Most of the installation methods we've reviewed in this book create the necessary component certificates, but it's always on the cluster operators to identify all in-use local ports that may not use the more secure settings.
• Authenticate your access: Just as with any large scale computer system, you want to ensure that the identity of a user is established. For small clusters, you can use certs or tokens, while larger production clusters should use OpenID or LDAP.
• Control your access: After you've established the identity of the role accessing your API, you always want to ensure that you pass your authenticated access request through an authorization filter with Kubernetes' built-in role-based-access-control (RBAC), which helps operators limit control and access by roles and users. There are two authorizer plugins, node and RBAC, that can be used, along with the NodeRestriction admission plugin. A key point to keep in mind is that role granularity should increase as cluster size increases, and even more so from non-production environments toward production environments.

By default, authentication to use the kubelet is turned off. You can enable authorization/authentication on the kubelet by turning on certificate rotation.

We can also modify the usage of Kubernetes at runtime:

• Long-time operators of Kubernetes in production will recognize this as a reference point to our previous discussions on limits and policies. As discussed previously, resource quotas limit the number of resources provided within a namespace, while limits ranges between restrict minimum and maximum sizes.
• You can determine the privileges of your pods by defining a security context. Here, you can specify things like a particular Linux user, group, volume mount access, allowing privilege escalation, and more.
• You can also restrict access to logical partitions of your cluster by using network policies. You can ensure that certain namespaces are off limits to users, or determine whether or not they're able to set up services with specific load balancer configuration or open ports on host nodes.

While the preceding patterns are useful for operations inside of Kubernetes, there are also several actions that you should take when securing your cluster from an external perspective:

• First off, enable and monitor your logs! While this seems like a no-brainer, we see a lot of problems cropping up from people that aren't watching their logs, or who haven't created alerts based off these logs. Another hint: don't store logs inside of your cluster! If your cluster is breached, then those logs will be an invaluable source of information for malicious agents.
• Make double sure that you restrict access to your etcd cluster. This can come in the form of setting up security groups or firewalls and ensuring that your etcd cluster nodes have the appropriate identity and access management from an infrastructure perspective. From a cluster perspective, make sure that you're always using TLS certificates for authentication and strong credentials. In no case should any components inside your cluster have read/write access to the full etcd key/value space.
• Make sure to vet alpha/beta components and review third-party integrations. Make sure that you know what you're using when you enable it, and what it does when you turn it on! Emerging features or third-party tools may create attack surfaces or threat models where you're not aware of what dependencies they have. Beware of any tools that need to do work inside the kube-system, as it's a particularly powerful portion of the cluster.
• Encrypt your secrets at rest in etcd. This is good advice for any computerized system, and Kubernetes is no different here. The same goes for your backups to ensure that an attacker can't gain access to your cluster via inspection of those resources.

For your production cluster, you should also be doing things such as scanning your container images, running static analysis of your YAML files, running containers as non-root users where possible, and running an intrusion detection system (IDS). Once you have all of this in place, you can begin to explore the functional capabilities of the service meshes out in the wild.