Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Securing your platform is foundational to improving the overall security of your Kubernetes environment. This article focuses on configuring your Kubernetes cluster, its underlying operating system, and hardware infrastructure to operate more securely. By leveraging built-in capabilities and following best practices, you can help ensure that your platform is more resilient against threats and provides a stronger base for your workloads and operations.
Stay up to date with the latest security patches
We recommend upgrading your cluster and node OS with the latest security patches as they're published. In turn, this means it's important to keep your cluster up to date with a supported version of Kubernetes, for which patches are released. Similarly, it's also important to keep your nodes up to date with a supported version of their OS.
If you connect your own cluster via Arc-enabled Kubernetes, then keep it up to date following your vendor's guidance, and configure automatic upgrades for the Arc-enabled Kubernetes agents that maintain the cluster's connection to Azure.
You may also deploy extensions to your cluster: other sections of this security book recommend many of these extensions for the security benefits they can help bring. If so, configure automatic upgrades for these extensions too.
References
- NSA Kubernetes Hardening Guidance - "Upgrading and application security patches"
- Kubernetes Security - OWASP Cheat Sheet Series - "Securing Kubernetes Hosts"
Protect the communication between Kubernetes control plane components
If you're running AKS enabled by Azure Arc on Azure Local, then Transport Layer Security (TLS) is used to help protect all cross-node communication between control plane components, such as the API server and etcd. TLS certificates are regularly rotated.
If you connect your own cluster via Arc-enabled Kubernetes, then determine if traffic between your nodes is similarly protected. Evaluate if there are any steps you need to take to enable this protection (for example, creating and updating certificates) by following your vendor's guidance.
References
- NIST Application Container Security Guide - Section 4.3.5
- NSA Kubernetes Hardening Guidance - "Encryption"
- Kubernetes Security - OWASP Cheat Sheet Series - "Restricting access to etcd"
Protect direct access to your nodes
In general, we don't recommend direct access your cluster's nodes. It's best to administer your cluster via the API server, and Role-Based Access Control (RBAC) can help you control which users can perform which operations. See our further guidance on this topic.
Therefore, SSH access to your worker nodes should be disabled by default. However, if this access does prove to be required, and you're running AKS enabled by Azure Arc on Azure Local, then it's important to manage it carefully. Safely store the SSH keys when you create the cluster and restrict SSH access to only expected network addresses . Beyond this limited exception, there should be no other way to reach the control plane nodes and the Kubernetes infrastructure components that run on them such as kube-scheduler, etcd, kubelet.
Finally, because edge clusters often reside in nonsecure locations, consider what physical protections are appropriate (locked access, tamper evident measures, etc.).
References
Next steps
- Learn how to secure your workloads
- Return to the top of this security book