Kubernetes Deployment 的安全最佳实践

今天的文章由来自 Aqua Security 的 Amir Jerbl 和 Micheal Chemy 撰写，在不同用户案例中搜集到的数据基础上，描述了 Kubernetes Deployment 的安全最佳实践。

Kubernetes 提供了很多配置来提升应用程序的安全性。但是配置这些需要深入了解 Kubernetes 的初始知识以及一些安全的需求。我们在这里要强调的最佳实践跟容器的生命周期相匹配：创建，运送以及运行，以及为 Kubernetes 特别定制。在谷歌 GCE 上，我们的用 Kubernetes 来部署我们的 SaaS 服务 。

对于部署安全的 Kubernetes 应用程序，我们推荐以下：

确认镜像是没有缺陷

运行没有缺陷的容器会使你的环境面临轻易妥协的威胁。很多攻击都可以简单地通过确认软件组件没有缺陷来减轻。

实施连续安全缺陷扫描

容器可能包含过时的已知缺陷的程序包（ CVEs ）。而且每天都有缺点被暴露出来，所以这并不是一个“一次性”进程。作为一个连续评估镜像不间断的程序，这个程序对于确保所需安全状态非常重要。

你的环境需要定期申请安全更新

一旦运行中的容器被发现有缺陷，你需要做的就是更新资源镜像，重新部署容器。尝试避免直接更新到运行的容器，因为这样可能会破坏镜像跟容器之间的关系。有了 Kubernetes 的滚动升级功能，升级容器变得十分容易——这个功能可以通过升级镜像到最新版本来慢慢更新运行的应用程序。

确保你的环境中只使用授权的镜像

如果没有程序来确认只有镜像依附在组织机构的策略上，那么组织机构就容易受到有缺陷或者是恶意的容器的攻击。

从未知的资源里下载运行镜像是十分危险的。这就相当于在生产环境的服务器上运行一个未知软件提供商的产品一样。所以，不要那么做。

使用私有库来存储规定镜像——确保你只 push 规定的镜像到这些库。这已经把运行的领域缩小了，减少了可进入管道的数量。

创建集成安全评估（比如漏洞扫描）的 CI 管道，使之成为创建进程的一部分。

CI 管道要确保代码被审查过才能够用来创建镜像。镜像创建好了，就要扫描有没有安全缺陷，如果没有的话，那么镜像就会被 push 到一个私有库，在这个私有库，部署到产品就完成了。安全评估要是失败的话，管道也会相应失败，这样就避免了安全质量不好的镜像被 push 到镜像仓库。在 Kubernetes 中还有很多需要为镜像授权插件做的工作（期望在 Kubernetes1.4 中能够完成），这就避免了运送未授权的镜像。

限制直接访问 Kubernetes 节点

需要限制 SSH 访问 Kubernetes 节点，减少未授权访问主机资源的风险。同时要求用户使用“ kubectl exec ”，它可以直接访问容器环境，而不需要访问主机。

可以使用 Kubernetes 授权插件来远程控制用户访问资源。这也就意味着要为特定的 namespace ，容器和操作来定义细粒度访问控制规则。

在资源间创建管理的边界

限制用户权限的范围能够控制错误或者恶意活动的发生。 Kubernetes 的 namespace 允许把创建的资源分割成逻辑的 group 。在一个 namespace 中创建的资源在其它的 namespace 中不可见。默认设置下，每个由 Kubernetes 集群用户创建的资源都运行在一个默认 namespace 中，名为 default 。你可以创建额外的 namespace ，并在该 namespace 中创建资源，然后使用这些资源。你也可以使用 Kubernetes 授权插件来创建策略，来隔离访问不同用户间的 namespace 资源。

比如：以下就是策略允许“ alice ”从 namespace “ fronto ”阅读 pods 。

定义资源配额

运行资源未装订的容器，你的系统可能面临陷入 DoS 或者“ noisy neighbor ”场景的风险。为了避免，或者说是将这些风险最小化，你需要定义资源配额。默认设置下，所有在 Kubernetes 集群中的资源都是用 unbounded 的 CPU 和内存要求／限制来创建的。为了限制 Pod 允许使用的 cpu 和 memory 资源，你可以创建资源配额策略，并把这个策略应用到 Kubernetes 的 namespace 上。

以下是 namespace 资源配额定义的一个例子，它限制 namespace 中 pod 的数量不能超过 4 个，限制他们的 CPU 请求在 1 到 2 个之间，内存请求在 1GB 到 2GB 之间。

compute-resource.yaml:

分配 resource 配额到 namespace ：

实施网络分割

在同一个 Kubernetes 集群上运行不同的程序会有风险，就是应用程序可能会受到损坏，然后攻击相邻的程序。容器只能够跟确认的容器进行交流，所以网络分割显得很重要。

Kubernetes 部署面临的一个挑战就是，在 pod ， service 和容器间创建分割。这个挑战的原因就是容器网络身份（ IPs ）的动态特性，当然，容器既可以在同一个节点中交流，也可以在不同节点间交流。

谷歌云平台的用户能够从自动防火墙规则中受益，避免跨集群交流。可以使用网络防火墙或者 SDN 解决方法在内部部署相似的实施。 Kubernetes 的 Network SIG （兴趣组）在这方面的做了一些工作，很大程度上提升了 pod 之间的交流的策略。新的网络策略 API 应该在 pods 周围处理创建防火墙规则，限制容器化的网络访问。

以下的例子就是，为“ backend ” pods 控制网络的网络策略，只允许本地网络访问“ frontend ” pods ：

为你的 pods 和容器申请安全环境

当设计你的容器和 pods 的时候，需要确认给你的 pods ，容器和数据卷配置了 SecurityGroup 。 SecurityGroup 可以在 yaml 文件中定义。它控制分配到 pod/container/volume 的安全参数。一些重要的参数如下图所示：

下图是 pod 定义的一个例子：

如果允许有提升权限（--privilege ）的容器，你应该考虑使用“ DenyEscalatingExec ”这个 Admission Controller 。这个 Controller 拒绝在 Pod 上运行 exec 和 attach 命令，并且在提升 Pod 的权限时，只允许该 Pod 在宿主机上访问。包括那些以特权模式运行的 Pod ，能够访问主机 IPC namespace 的 Pod ，以及能够访问主机 PID namespace 的 Pod 。

日志记录

Kubernetes 提供基于集群的日志，支持把日志推送到一个中心化的 log hub 。创建完集群的时候，使用 Fluentd 代理来收集每个容器的标准输出，标准错误输出。当集群创建成功以后，每个容器产生的日志（标准输出和标准错误输出）就可以被每个节点上的 Fluent Agent 采集，然后推送到 GoogleStackDriver Logging 或者 Elasticsearch ，然后用户可以用 Kibana 来看这些日志。

结论

Kubernetes 提供很多选择来创建安全部署。但是并不存在一个对策解决所有问题这样的好事，所以需要对这些选项有一定的熟悉，同样，也要理解他们是如何提高你的程序的安全性的。我们推荐实施本文中强调的最佳实践，并且使用 Kubernetes 中灵活的配置功能将安全加工到连续的整合管道，将整个进程用无缝安全进行自动化。

原文链接： http://blog.kubernetes.io/2016/08/security-best-practices-kubernetes-deployment.html?utm_campaign=kb&utm_content=36720023&utm_medium=social&utm_source=twitter

转载请联系我们 － 3-