Source | Yufu Technology
In traditional R&D, the "security" we often pay attention to includes code security, machine (operating environment) security, and network operation and maintenance security. With the advent of the cloud-native era, if it is still divided according to the original dimensions Obviously, it’s easy to ignore many new challenges introduced by the cloud native environment. We need to analyze the "cloud native security" step by step based on the best practice of network security-the principle of defense in depth , and understand the defense methods at different levels to establish Own cloud-native security concept, truly build a cloud-native system with kernel security.
Note: "Defense in depth" refers to the use of multiple network security technologies at multiple levels in a computer system to reduce the overall possibility of attackers using key business resources or information leaking outside the system. In the messaging and collaboration environment, the defense-in-depth system can ensure that malicious attacks are blocked at multiple checkpoints within the infrastructure, reducing the possibility of threats entering the internal network.
Taking the Yufu IDaaS system as an example, we divide a cloud-native system security model into 4 levels, from the outside to the inside: cloud/data center/network layer, cluster layer, container layer, code layer, as shown in the figure below :
For each layer of the security model here, it is unidirectionally dependent on the outer layer. In other words, if the security of the outer cloud, cluster, and container is done well, the security of the code layer can benefit, and conversely, we cannot compensate for the security vulnerabilities in the outer layer by improving the security of the code layer. problem.
Based on the above-mentioned principle, our defense in depth strategy is to "defense from the outside".
Cloud/data center/network layer security
This layer can also be referred to as infrastructure security . From any perspective, public or private cloud or enterprise data center and corresponding network security are the most fundamental security foundation of the K8s cluster. If this layer has security vulnerabilities or is too fragile , The entire system cannot guarantee the safety of components on this basis.
In addition to defending against traditional attacks, such as ARP masquerading, DDOS, and various types of network layer attacks, we should take the following protective measures against the Kubernetes cluster:
1. It is not allowed to open all access to the Kubernetes management platform (Control Plane) on the Internet, and only open some trusted IPs to access the Kubernetes management API.
2. All nodes only expose specified ports, including the internal ports of the management platform and connections from NodePort and LoadBalancer types of Kubernetes services, and should not be directly exposed to the Internet.
3. Grant minimal permission control to the management platform and nodes through the cloud provider or the network layer security group of the computer room (such as AWS Security Group) :
4. Strictly control access to etcd (the basic storage of Kubernetes) (only allow access from the cluster management platform). All connections should be forced to use TLS, and all information should be encrypted at the persistence layer (Encryption at rest).
Cluster layer
There are two main subjects to pay attention to to protect the Kubernetes cluster:
Clusters and components
Service or application running
Protect Kubernetes cluster components and services or applications
For the protection of these two subjects, our protection can be divided into four major blocks: access control for management APIs, access control for Kubelet, access control for runtime workloads or user functions, and protection against security vulnerabilities for cluster components. As shown below.
1. Management API access control
a. Mandatory TLS to protect the transport layer
b. Mandatory API authentication
c. Mandatory API authorization mechanism (RBAC)
2. Kubelet access control
a. Enable authentication in the production environment
b. Identity authorization (RBAC)
c. Mandatory TLS to protect the transport layer
3. Runtime (runtime) workload or user function access control
a. Restrict the use of privileged containers
b. Reasonably limit resource load
c. Prevent loading unnecessary kernel modules
d. Restrict Pod unauthorized access to other nodes
e. Access control of basic data credentials
4. Security vulnerability protection of cluster components
a. Prohibit unauthorized access to etcd
b. Enable audit logging
c. Rotate infrastructure credentials regularly
d. Regular upgrades to fix vulnerabilities
Container layer
At this level, since it is not strongly related to Kubernetes features, we can provide some general security measures and suggestions:
Code layer
The program code layer is the most vulnerable but also one of the most controllable parts. Although the person generally responsible for this piece of security is not necessarily an operation and maintenance development (DevOps), but may be a dedicated security engineer (Sec Eng), there are some basic common concepts and suggestions that can be learned from each other.
In general, the four-layer architecture of the cloud native era: cloud/data center/network layer, cluster layer, container layer, and code layer is more detailed and vulnerable to attacks than traditional architectures . By practicing every layer of security best practices from the outside to the inside, our defense in depth can be considered successful. Every team that wants to benefit from cloud-native technology in the long term needs to have a consensus on this.
Author introduction :
Weijia Chen, graduated from the University of California, Irvine, worked at Facebook and Splunk, and is currently the CTO of Yufu Technology, responsible for the design and implementation of Yufu IDaaS technology architecture, leading the R&D team to realize independent product research and development from 0 to 1, and build stateless support , Lightweight container packaging, operation and maintenance automation and other microservice architectures.
Reference materials:
[1]https://baike.baidu.com/item/%E7%BA%B5%E6%B7%B1%E9%98%B2%E5%BE%A1/8282191?fr=aladdin
[2]https://kubernetes.io/docs/concepts/security/overview/
[3]https://www.stackrox.com/post/2020/09/protecting-against-kubernetes-threats-chapter-8-lateral-movement/
More reading recommendations