White Papers


Issue link: https://read.uberflip.com/i/1344955

Contents of this Issue


Page 1 of 5

© 2021 Mirantis Inc. All Rights Reserved. Information is subject to change. | www.mirantis.com • Securing the Kubernetes dashboard: While it's important to have a way to see what's going on in your cluster, the upstream Kubernetes Dashboard does not meet the necessary security standards most organizations require for production use. You will need to either take additional steps to mitigate problems or use a different tool, such as the open source Lens Kubernetes IDE. • Runtime security: Within the cluster, applications run in pods, which themselves run containers. While containerd (with and without Docker) is the most common container runtime, multiple implementations of the Container Runtime Interface (CRI) exist, and most provide opportunities for attackers to use malicious containers to attack your host system if the container runtime isn't properly secured. • East-West traffic: Transport Layer Security (TLS) involves certificates to ensure that a hacker cannot, for example, bypass the Kubernetes API and attack the Kubernetes Scheduler directly in order to compromise your cluster. • Securing Ingress: Finally, while you will, of course, have legitimate traffic entering your cluster, you must ensure that only that legitimate traffic gets past your firewall or other perimeter protection. • CIS Benchmarks: There are well-defined, community- produced best practices for several major components of a container environment, including Kubernetes, Docker, and several flavors of Linux. Given the rapid pace of change with Kubernetes, the benchmarks themselves change quickly, so having a process and tools that run these benchmarks against your environment will help ensure you're implementing industry-accepted security settings. Control access Once you've hardened your cluster, you still need to prevent unauthorized access to it. This is a vast topic unto itself, but some of the basic topics you need to consider include: • Infrastructure as code and immutable clusters: One of the most important ways to keep your cluster in good working order — and to keep it secure — is to make sure that node configuration doesn't drift over time. In that respect, you must treat your inf rastructure as you treat every other part of your process: as code. If changes need to be made, you need to make them at the configuration file level and re-create the nodes rather than tinkering on the nodes themselves. • Admission controllers: Admission controllers are cluster- wide checks and restrictions that control how requests to the cluster are treated. These controllers can enforce policies or prevent actions such as pulling container images f rom unknown registries. • Pod Security Policy: While many threats come f rom outside your cluster, there is always the danger that workloads can intentionally, or even unintentionally, cause problems. Pod Security Policy enables you to control access to features such as the ability to run in a "privileged" context, and to control that access at the cluster level. • Audit logging: Kubernetes not only provides the ability to log every request and action, it also enables you to control, at a granular level, which of those actions you want to log. Think carefully about where you're vulnerable and ensure that you're watching those areas and checking the logs on a regular basis. • Penetration testing: You'll never know how secure your system really is until someone tries to break into it. Fortunately, it doesn't have to be someone who intends to do you harm; penetration testing uses hackers who are on your side to look for vulnerabilities and report them back to you so you can fix them. • Limiting resource usage: One way to prevent, or at least mitigate, a Denial of Service attack is to ensure that no single user or workload can monopolize all of your cluster's resources. You can do that by limiting the amount of resources, such as memory, a container can request. • Content Trust policies: Ultimately your cluster is only as secure as the containers that run on it. Content trust policies enable you to choose whether and when to allow unsigned images to be used on your cluster, or whether to require that all containers be instantiated f rom images that have been signed — and even signed by a particular person or process, such as a security scan. Provide a secure software development process Creating, updating, integrating, and lifecycle-managing containerized workloads for Kubernetes is considerably more flexible, and in some ways, fundamentally easier, than creating and managing conventional applications. Most organizations transitioning to container-based development do so partly in order to gain speed — to deliver better software, faster, by using container technology to package software components

Articles in this issue

Links on this page

view archives of White Papers - Kubernetes_Enterprise_Security_Checklist