add new blog

Signed-off-by: faweizhao26 <faweizhao@kubesphere.io>

content/zh/blogs/k8s-security.md

@@ -0,0 +1,107 @@
+---
+title: 'K8s 安全策略最佳实践'
+tag: 'Kubernetes, KubeSphere'
+keywords: 'Kubernetes, 安全策略, KubeSphere'
+description: '本文主要是给大家分享以下内容：了解 K8s 环境面临的安全风险；了解 K8s 提供的安全机制；改善 K8s 安全状况的最佳实践'
+createTime: '2022-04-07'
+author: '万宏明'
+snapshot: 'https://pek3b.qingstor.com/kubesphere-community/images/K8s-security-cover.png'
+---
+
+随着 K8s 在生产和测试环境中用的越来越多，对安全性的关注也会越来越多，所以本文主要是给大家分享以下内容：
+
+- 了解 K8s 环境面临的安全风险
+- 了解 K8s 提供的安全机制
+- 改善 K8s 安全状况的最佳实践
+
+## 1. K8s 安全风险
+
+![](https://pek3b.qingstor.com/kubesphere-community/images/k8s-security-1.png)
+
+这张图是 CNCF 金融用户小组总结的 K8s 信任边界图，它把在 K8s 环境中的信任边界划分成三大块儿。
+
+- **容器镜像相关部分**，主要涉及到的安全攻击点就是镜像仓库和镜像本身。红色曲线可以被视为独立边界的系统。
+- **K8s 控制平面相关部分**，如果说一个攻击者攻击你的 K8s 集群的话，首先会攻击 K8s 的控制平面，中间涉及到的组件就是 K8s 的 apiserver、scheduler 和 controller-manager，所以说这些组件之间调用链的安全也需要去注意。
+- **节点上运行时的安全**，其中包括 kubelet、kube-proxy 和容器运行时环境也容易被攻击，要避免运行环境被渗透。
+
+我们根据不同的攻击类型划分，首先最容易规避的就是来自外部的攻击。通常情况下，来自外部的攻击会有 2 种类型：
+
+- 一种是系统层面的漏洞，需要及时更新，及时跟进 K8s 社区和安全领域相关的最新消息，可以很好的规避。
+
+- 第二个是应用本身带来的渗透或者是提权的风险，业务部署在 K8s 之上，应用的漏洞可能造成容器越权或者容器逃逸之类的风险。
+
+借助恶意容器进行攻击也比较常见，在使用容器的过程种主要会面临以下风险：
+
+1. 使用了不受信任的镜像仓库或者是使用了被篡改的容器镜像会导致恶意代码被执行。
+2. 容器执行恶意代码存在提权或者逃逸的风险。
+3. 即使容器运行时足够安全，无法提权或逃逸，内部暴露的服务也容易成为被攻击的点，造成数据被恶意访问。
+
+K8s 集群的规模变大，运维人员与终端用户也会变多，安全凭证的泄露，会对整个集群的安全造成威胁。
+
+即使集群保护的非常好，在安全凭证没有泄漏的情况下，来自内部成员的恶意攻击也难以规避，即使是在测试环境也需要一定程度的租户隔离，避免来自内部的攻击、对数据的恶意访问。
+
+## 2. K8s 安全机制
+
+在 K8s 社区，安全问题的关注度是非常高的，在 K8s 的设计中，各组件都有安全相关的特性。在 API 认证层面，控制平面中各个组件之间，需要开启 mTLS 进行组件之间的互认证。
+
+K8s 也支持丰富的认证、访问控制的机制，通常我们会借助 RBAC 对用户的权限进行限制。
+
+K8s 还提供了针对容器能力的限制机制，我们可以通过 Security Context 去限制容器运行时的用户、用户组，对容器特权进行限制。
+
+K8s 中 Pod Security Policy 可以为集群应用安全策略，但是这个特性会在 1.25 之后被后面提到的 pod security admission webhook 替代。这是 K8s 提供的安全策略机制，非常建议大家去深入了解。
+
+我们还可以用到 Resource Quota 结合 request、limit 限制容器的资源用量，尽可能的利用 linux 提供的安全特性，针对网络、cpu、内存等资源进行用量的限制。Limit Range 可以帮助我们为 Pod 设置默认的资源限制。
+
+除此之外，还可以针对 K8s 集群网络进行划分，通过 network policy 来支持网络隔离策略，设置黑名单或者白名单，为 namespace 去分配一独立的 IP 池。
+
+我们可以借助 K8s 节点调度策略、污点管理，node selector 等机制去限制容器能够调度的节点，实现一定程度的物理隔离。
+
+K8s 还有一些和安全相关的内容，一个是审计日志，需要在 kube-apiserver 中进行开启。然后是 Pod Security Admission Webhook，这将是一个新的特性，帮助我们为集群应用安全策略。最后就是和数据安全相关，我们可以借助 KMS 来加密 etcd 中的数据，在容器运行时进行解密。
+
+## 3. K8s 安全最佳实践
+
+K8s 安全最佳实践，大部分都是来自于社区用户和我们实际生产中环境中的经验总结。
+
+![](https://pek3b.qingstor.com/kubesphere-community/images/k8s-security-2.png)
+
+上图是 K8s 社区的对云原生安全的安全总结，在云原生中主要分四个比较重要的层级：代码安全、容器安全，K8s 集群安全和云平台、数据中心的安全。
+
+针对这四个层面的安全问题，有不同的解决策略。
+
+**代码安全**往往可以通过以下方式进行应对，比如说应用之间的通讯，尽量使用 TLS 或 mTLS，保证数据的加密传输。即使集群中大部分都是可信的环境，TLS 带来的性能损耗我认为也是在可以承受的范围之内。
+
+针对代码安全的增强，通常需要我们在在 CI 或 CD 过程中对代码进行扫描，对容器镜像进行扫描，对应用安全进行扫描，即使很多工具会存在误报的情况，但在大规模的项目中这些步骤是必不可少的。
+
+**容器安全方面**，我们建议尽可能的使用可信的基础镜像，除此之外，尽可能去删掉不必要的二进制，避免基础镜像中操作系统漏洞带来的影响。
+
+在容器运行的过程中尽可能的使用非 root 用户，除非是有特定的数据读写要求，可能会有一些问题。
+
+- **集群安全**
+  K8s 集群安全层面的建议，首先我们需要整理集群中所有关键组件的通讯矩阵，要知道哪些组件会用到哪些端口，比如说 K8s 控制平面常用的 10250,6443 端口等。对系统组件所用到的端口进行合理的管控，通过防火墙来提供最基础的保障。
+- **数据安全**
+  在 K8s 集群中我们可以实现或接入已有的 KMS 服务，对 etcd 中的数据进行加密，在 etcd 数据泄漏的情况下也可以保证集群中 secret 数据的安全。
+- **网络安全**
+  在 K8s 中我们可以借助 Network Policy 实现网络隔离，常用的网络插件 calico 和 Cilium 都可以很好的支持。不要开放不必要的端口，不仅是不对外开放端口甚至对于容器内部暴露的端口也要尽可能的去屏蔽。
+- **针对所部署的应用安全**
+  尽可能的为每一个部署到 K8s 的容器配置 Security Context，限制容器内的运行用户和容器特权，禁止其直接读取或读写整个宿主机的网络和文件。再就是 K8s 针对安全策略的的增强，我们可以利用一些安全策略管理工具如 Gatekeeper，为整个集群运用一些安全策略以抵抗风险。
+
+* **可观测性部分**
+  不论是限制节点调度，还是配置网络隔离策略等，这些都是以很被动的方式主动进行防御。在复杂的分布式容器化环境中数据的可见性降低，借助可观测性工具，我们就可以及时的发现集群中异常，比如异常流量、异常的日志、异常的 API 访问等，这些对整个系统安全来说显得尤为重要。借助可观测性工具，无论是监控数据还是异常日志，都可以帮助我们在第一时间去发现问题，我们可以设置合理的告警策略进行防御。
+* **安全策略管理**
+  K8s 集群安全策略，除了在使用过程中规范对使用者的要求，比如限制不可信的镜像仓库、特权容器、hostPath 挂载，也可以借助 Gatekeeper 这类安全策略管理工具进行主动的拦截。
+
+**KubeSphere 中的安全增强：**
+
+KubeSphere 是一个构建在 K8s 之上的容器管理平台，我们针对 K8s 安全问题提供了以下增强：
+
+1、借助可观测性组件增强异常的感知能力。借助日志、监控数据结合告警策略来提高异常感知的能力，增加数据的能见度。
+
+2、支 Network Policy 实现网络隔离，支持 IP 池的管理。
+
+3、支持接入 Kata Containers 等更安全的运行时。
+
+4、KubeSphere 社区中开源的 KubeEye，是一个可以实现集群自动巡检的小工具，可以帮助我们扫描集群中存在的安全风险、不合理的配置等。
+
+5、KubeSphere 提供了 Gatekeeper 的集成，并计划提供可视化的管理界面，实现安全策略的管理。
+
+6、在 DevOps 流水线中我们可以集成代码、镜像等安全扫描工具。