Kubernetes is being adopted faster, and an important aspect of it is security-which leaves early adopters at a loss. Compared with VMs, many people doubt the security of containers and Kubernetes, and therefore give up. But slowly, people began to believe that containers and Kubernetes are as secure as physical machines and virtual machines.
Security is a multifaceted issue that must be addressed from many different angles. The following checklist covers the main security areas that should be reviewed throughout the stack.
Security must be a "first-class citizen" of any organization's DevOps process, often referred to as DecSecOps. In DevSecOps, security issues are embedded in the DevOps pipeline from day one. DevSecOps practices support the automation of most security issues and provide a series of security checks during the development process.
The security of Kubernetes can be divided into four aspects: infrastructure, Kubernetes, containers, and applications.
Protect the infrastructure
Infrastructure-level security is the most basic and most important task. However, it is often overlooked during the development process. It is important to keep infrastructure security in mind when building an application because it affects how the application needs to be built.
Infrastructure security itself has many aspects:
1. Network. Most Kubernetes deployments are microservices, and all microservices are communicating with each other or with external applications and services. It is important to limit network traffic to the necessary range, and to understand that microservices may be short-lived and can move between nodes in the cluster. In order to develop a secure network, you need to consider all aspects of network design: isolation of control traffic, isolation of storage traffic, network segmentation, quality of service, network policies, firewalls, and ACLs.
2. Storage. For any organization, storage is a critical part of security. Hackers usually look for confidential data stored in application storage. Developers using Kubernetes should consider the following forms of storage-level security implementation: self-encrypting drives, volume encryption, and quality of service.
3. Host and operating system (OS). The next level of infrastructure is the physical or virtual host itself. Operation and maintenance personnel hope to ensure their security through the following methods: strengthening the operating system, enabling kernel security, audit logging, rotating certificates, locking nodes, and CIS consistency.
4. Host-level access management. The weakest point of a Kubernetes cluster is the node itself. Since Kubernetes isolates users from the underlying nodes, it is very important to control access to nodes: strict access, establishment of locks, isolation of Kubernetes nodes, and master nodes.
Securing Kubernetes
The next layer to be protected is the Kubernetes installation itself. In a typical open source Kubernetes installation, many of them need to be manually configured because they are not all turned on by default.
1. Security etcd. etcd is a highly available key-value store, used as Kubernetes' backup storage for all cluster data. It is very important to protect etcd. As mentioned earlier, nodes in etcd should be locked with minimal access rights.
2. Protect access to Kubernetes clust. Kubernetes allows enterprises to use standard identity and access control solutions, but they need to be integrated with the environment and are not provided by default. Access control can be broken down into the following components: authentication, authorization, and permission control.
3. Security strategy. Kubernetes provides some configurable policies that can be defined by the user. These should be consistent with corporate practices, but are not "on" by default: Pod security policies, network policies, and Kubernetes provide quality of service (QoS) guarantees for computing resources (CPU and memory) to avoid noisy neighbors or lack of resources Problem, but it does not provide QoS for I/O (storage and network).
Fourth, workload isolation and multi-tenancy. In a multi-tenant environment, each tenant or group of tenants must have a separate namespace to isolate workloads and data from each other. CNI, CSI, and authentication plugins need to support these separations and boundaries so that they remain consistent throughout the stack.
Protect the container
When developing and running containers, they must be protected. Here are some key elements:
1. Container image security. All running containers are based on an image file that can be downloaded from open repositories such as Docker Hub, or passed from one team to another. It is important to know where your mirror image comes from and what is inside. All these actions should be part of the DevOps process to automate and ensure image security: image vulnerability scanning, image signature, and restricted permissions.
2. The container is running. The container runtime is a program installed in the operating system. Currently, most environments use Docker because Docker provides a CIS benchmark. Seccomp can be used to reduce the attack surface, while newer runtimes (such as CRI-O) have additional built-in security features.
3. Run the container. Many tools (such as Twistlock, Aqua, and Sysdig) also provide continuous monitoring and threat prevention for runtime vulnerabilities by monitoring network and system calls. These tools can also intercept and block unwanted calls or communications, and enforce security policies.
Protect the application
After protecting the underlying infrastructure, Kubernetes and containers, it is still important to protect the application itself.
1. Application access. Including TLS for Kubernetes entry, all content in encrypted transmission.
2. Communication. Including network and port.
3. Application hardening. Many DevOp practices should be built into the CI/CD pipeline to ensure application security and follow best practices. For example: regularly analyze the source code to ensure that it follows best practices and avoid vulnerabilities and threats (there are many tools available, such as Veracode and Synopsys); most developers rely on third-party applications and libraries to build applications and microservices. Regularly scan code dependencies to find new vulnerabilities to ensure that they will not pose a threat to the security of the application; constantly test the application against common attack practices (such as SQL injection, DDoS attacks, etc.) (various dynamic analysis tools are available) help).
to sum up
Security is always the most concerned issue of the organization. But traditionally, security is independent and far from the development process. Developers usually focus on the application, and the security team intervenes at the end of the development cycle. This unhealthy interaction between security and development teams not only makes the developed software vulnerable to attacks, but also causes many last-minute errors and unexpected production delays.
In the new era of containers and Kubernetes, strong automation of security practices is important, and security should be integrated into the development cycle from the beginning. DevSecOps is now the focus, because security has become deeply ingrained in the DevOps process. The challenge is that many of the items in the above list must be manually configured across multiple domains. Missing one of them may put the entire application and the company at risk.
Original link:
https://thenewstack.io/a-security-checklist-for-cloud-native-kubernetes-environments/