（https://rancher.com/blog/2019/2019-01-17-101-more-kubernetes-security-best-practices/）
你好，我是正范。
Kubernetes 作为一个分布式集群的管理工具，提供了非常强大的可扩展能力，可以帮助你管理容器，实现业务的高可用性和弹性能力，保障业务的规模。现在也有越来越多的企业正在逐步将核心应用部署到 Kubernetes 集群中。
但是当业务规模扩大，集群的承载能力变大的时候，Kubernetes 平台自身的安全性就不得不考虑起来。
那么 Kubernetes 平台自身身的安全问题如何解决？我们又该采取什么的策略来保证我们业务应用的安全部署？
Kubernetes 的安全性
A Security Checklist for Cloud Native Kubernetes Environments 这篇文章对 Kubernetes 的安全性总结得非常好，将它 Kubernetes 的安全性归纳为了以下四个方面： Infrastructure（基础设施）、Kubernetes 集群自身、Containers（容器）及其运行时和 Applications（业务应用）。
(https://thenewstack.io/a-security-checklist-for-cloud-native-kubernetes-environments/))
我建议你详细阅读一下这篇文档，我们这里只是做一些简短的总结介绍。
Infrastructure，即基础设施层。正所谓“万丈高楼平地起”，基础设施的安全性是最基础的，也是最重要和关键的，却常常被忽略。这里基础设施，主要包括网络、存储、物理机、操作系统，等等。
Kubernetes 其实对用户屏蔽了底层的基础架构，所以我们在初期规划和设计网络的时候，要提前做好规划，比如同时支持基于第 2 层 VLAN 的分段和基于第 3 层 VXLAN 的分段，以隔离不同租户或不同应用程序之间的流量。
如果你的 Kubernetes 集群搭建在云上，社区也给出了云上 Kubernetes 集群的 9 大安全最佳实践供你参考，如果你使用了一些 Cloud Provider 也可以参考这篇文档。
最佳实践
在底下基础设施安全的情况下，我们下一步要增强安全性的就是 Kubernetes 集群自身了。我们主要详细来看看 Kubernetes 集群及业务层安全性的十个最佳实践。
1. 集群版本更新及 CVE 漏洞
首先，也是最重要的，你要时刻关注社区 Kubernetes 的版本更新，以及披露的 CVE 漏洞，及时地把 CVE 的修复方案变更到你的集群中去。
同时你需要保证跟社区的版本不要太脱节，跟社区保持 1 到 2 个大版本的差异。
2. 保护好 Etcd 集群
Etcd 中保存着整个 Kubernetes 集群中最重要的数据，比如 Pod 信息、Secret、Token 等。一旦这些数据遭到攻击，造成的影响面非常巨大。我们必须确保 Etcd 集群的安全。
对于部署 Etcd 集群的各个节点，我们应该被授予最小的访问权限，同时还要尽量避免这些节点被用作其他用途。由于 Etcd 对数据的读写要求很高，这里磁盘最好是 SSD 类型。
Etcd 集群要配置双向 TLS 认证（mTLS），用于 Etcd 各个节点之间的通信。同时 APIServer 对 Etcd 集群的访问最好也要基于 mTLS。通过 Kubeadm 搭建出来的集群，默认已经采取这种配置方式。
3. 限制对 Kubernetes APIServer 的访问
APIServer 是整个 Kubernetes 的大脑，及流量入口，所有的数据都在此进行交互。Kubernetes 的安全机制也都是围绕着保护 APIServer 进行设计的，正如我们第 18 讲介绍的认证（Authentication）、鉴权（Authorization）和准入控制（Admission Control），这三大机制保护了 APIServer 的安全。
显而易见，APIServer 也必须得使用 TLS 进行通信，尽量不要开启不安全的 HTTP 方式，尤其是在云上的环境中，切记一定要关闭，你可以通过--insecure-port=0参数来关闭。
同时要避免使用 AlwaysAllow 这种鉴权模式，这种模式会允许所有请求。一般来说，我建议这么配置鉴权模式，即--authorization-mode=RBAC,Node。RBAC（基于角色的访问控制）会将传入的用户/组与一组绑定到角色的权限进行匹配。这些权限将 HTTP 请求的动作（GET，POST，DELETE）和 Kubernetes 内部各种资源对象，比如 Pod、Service 或者 Node，在命名空间或者集群范围内有机地结合起来，你可以回顾我们第 18 讲的内容，这里不再赘述。
4. 减少集群的端口暴露
当然你还需要尽可能减少集群的端口暴露。如下是 Kubernetes 各组件需要的端口，在使用的时候，可以限制只允许固定节点对这些端口的访问。
5. 限制对 Kubelet 的访问
Kubelet 上运行着我们的业务容器，同时还暴露了 10250 端口，可以用来查询容器，支持容器 exec，获取容器日志等功能。因此在生产级别的集群，我们要启用 Kubelet 身份验证和授权，同时关闭匿名访问--anonymous-auth=false。
6. 开启审计能力
APIServer 支持对所有的请求进行审计（Audit），你可以通过--audit-log-path来指定用来写入审计事件的日志文件路径，默认是不指定的。通过这个开启审计能力，再结合 RBAC，我们可以对整个集群的请求访问进行详细的监控和分析。
这个审计功能提供了与安全相关的，按时间顺序排列的记录集，每一个请求都会有对应的审计事件，记录着：
-
发生了什么？
-
什么时候发生的？
-
谁触发的？
-
活动发生在哪个（些）对象上？
-
在哪观察到的？
-
它从哪触发的？
-
活动的后续处理行为是什么？
通过这些审计事件，集群管理员可以很容易地分析出集群内的安全风险，以采取应对策略。
7. 通过 namespace 进行隔离
通过 namespace 来隔离工作负载和数据，比如区分不用的用户，不同的业务场景，以及一些关键的业务。你可以通过对这些 namespace 内的资源设置一些 RBAC 的规则，来进一步增强安全性。
8. 使用网络策略进行限制
Kubernetes 提供了基于 namespace 的网络策略（Network Policy），可以允许和限制不同 namespace 中的 Pod 互访。
网络策略通过网络插件来实现，所以你要使用这种能力，要选择支持 NetworkPolicy 的网络解决方案，比如 Calico、Cilium、Weave 等。
9. 容器镜像安全
容器的运行依赖容器的镜像，保证镜像安全是最基本的。要避免使用一些未知来源的镜像，同时自己构建镜像的时候，要使用安全的、确知的、官方的基础镜像。
同时，要定期地对镜像进行漏洞扫描，你可以使用 harbor-scanner-aqua、Clair 等工具对你的镜像中心、镜像进行扫描，来查找已知的漏洞。
除此之外，我们还要限制特权容器，避免在容器镜像中使用 root 用户，防止特权升级。
10. 应用程序的安全性
应用程序自身的安全性也很重要。如果你的应用程序要暴露给集群外部，可以使用入口控制器（Ingress Controller），比如 Nginx。
应用容器也要使用 TLS 进行通信，包括跟入口控制器之间的通信。不需要定期扫描源代码及依赖项，查找是否有新漏洞，还要持续测试你的应用程序，查看是否会受到攻击，比如 SQL 注入，DDoS 攻击等。
使用 kube-bench 对 Kubernetes 集群的安全性进行检测
这里我要跟你介绍一个开源工具kube-bench，它能帮助你排查 95% Kubernetes 集群的配置风险。这里我推荐你使用 kube-bench 对你的Kubernetes 集群进行一次全面的安全性检测，并根据反馈采取安全加固措施。
（https://github.com/aquasecurity/kube-bench）
这个工具使用起来也非常方便快捷，你可以参考官方文档进行操作。
写在最后
在云原生时代，拥有强大的安全非常重要，我们不能掉以轻心。在一开始我们就应该尽量把安全性纳入开发周期，将安全风险消灭在萌芽状态。
好的，如果你对本节课有什么想法或者疑问，欢迎你在留言区留言，我们一起讨论。