编排安全
容器技术的成熟推动着微服务的发展和落地，越来越多的企业开始采用微服务架构来组建自己的应用，其中， 容器编排工具管理着承载各类服务的容器集群。可以说，在各类采用微服务架构的项目中，容器编排工具支撑了 其核心业务。接下来以社区热度最高的编排工具 Kubernetes 为例，说明目前编排工具需要做的安全防护措施。
Kubernetes 安全防护
无论是 Kubernetes 社区还是第三方 安全机构均针对 Kubernetes 中组件和资源的安全进行了相应改善和安全 加固，以下为主要改进措施：1. 计算资源安全 Kubernetes 社区提供 PodSecurityPolicy[61]，在 Kubernetes 中 PodSecurityPolicy 是一个集群级别的资源，用 于控制 Pod 规范以及管理 Pod 安全，PodSecurityPolicy 对象定义了一组必须运行的条件以及相关字段的默认值， 集群管理员 通过 PodSecurityPolicy 可以控制以下内容。
| 控制方面 | 字段名 | ||
|---|---|---|---|
| 特权模式运行 | privileged | ||
| 使用 root 命名空间 | hostPID hostIPC | ||
| 使用主机网络和端口 | hostNetwork hostPorts | ||
| 使用卷类型 | Volumes | ||
| 使用主机文件系统 | all | ||
| owedHostPaths | FlexVolume 驱动程序白名单 | allowedFlexVolumes | |
| 分配拥有 Pods 卷的 FSGroup | fsGroup | ||
| 要求 root 文件系统为只读 | readOnlyRootFilesystem | ||
| 容器的用户和组 ID | runAsUser supplementalGroups | ||
| 限制 root 特权升级 | allowPrivilegeEsca | ||
| lationdefault AllowPrivilegeEscalation | Linux功能 | defaultAddCapabilities requiredDropCapabilities allowedCapabilities | |
| 容器的 SELinux | SELinux | ||
| 容器使用的 AppArmor 配置文件 | annotations | ||
| 容器使用的 Seccomp 配置文件 | annotations | ||
| 容器使用的 Sysctl 配置文件 | annotations |
- 集群安全 （1）控制 Kubernetes API 的访问 Kubernetes 的 API Server 针对所有 API流量使用了安全传输协议（TLS）以确保服务间访问的安全性，另外 又提供了访问认证、访问授权、Admission Control 等访问控制机制。 （2）控制对 Kubelet 的访问 Kubelet 的 HTTPS 端点公开了 API，这些 API授予了节点上容器强大的控制权，默认情况下 Kubelet 允许对 此 API进行未经认证的访问。生产环境集群中建议开启 Kubelet 身份验证和授权。 （3）控制集群运行时工作负载和用户的能力
- 限制集群中的资源使用 资源配额（Resource Quota）限制了授予命名空间的资源数量，通常是用于限制命名空间可以分配的 CPU、 内存或持久性磁盘的数量，或是通过控制命名空间中 Pod、Service、Volume 的数量来限制资源使用。
- 控制 root 权限运行容器 Pod 在 yaml 文件中的定义包含一个安全的上下文（security context），用于描述此 Pod 请求访问某个节点 上的特定用户（如 root）、获得特权或访问主机所在网络以及 Pod 在主机节点上不受约束的运行其它控件。而 Kubernetes 的 Pod 安全策略（PodSecurityPolicy）可以限制用户或服务账户（Service Count）提供安全上下文设置， 比如 Pod 的安全策略可以限制卷的挂载等。
- 限制网络访问 首先 Kubernetes 中基于命名空间的网络策略（Network Policy）允许用户限制集群中其它命名空间的哪些 Pod 可以访问它们命名空间内的 Pod 和端口，另外通过配额和限制范围的方法也可以控制用户是否可以请求节点 端口和负载均衡服务，最后基于插件式的控制网络规则方法可以增加额外的保护措施，比如节点防火墙、物理分 离集群节点等。
- 控制 Pod 访问 默认情况下，对在节点上访问 Pod 没做任何限制，但 Kubernetes 为用户提供了一组丰富的策略用于控制 Pod 运行节点的位置，这些策略典型的有 NodeSelector，Affinity 和 Anti-affinity等。 （4）保护集群中各组件
- 限制对 Etcd 的访问 对于 API来说，拥有 Etcd 服务器后端的写权限相当于获得了整个集群的 root 权限。在 API Server 访问 Etcd 服务器时，管理员应该使用广受信任的凭证，比如通过 TLS客户端证书的相互认证。通常建议将 Etcd 服务器隔 离到只有 API Server 可以访问的防火墙后面。
- 启用审计日志 Kubernetes 启用审计日志来记录 API发生破坏时进行后续的分析操作。
- 限制对 Alpha 或 Beta 的访问 Kubernetes 的 α 和 β 特性还处在积极开发阶段，所以可能会有限制或是 Bug，从而导致安全漏洞，所以在 使用时可以禁用那些不需要的特性。
- 实时关注安全更新和漏洞报告 加入 Kubernetes-announce 组 [62]，能够获得有关安全公告的邮件，有关如何报告漏洞相关信息，可以参考安 全报告页面 [63]。
- 对 Etcd 数据进行加密 一般情况下，Etcd 数据库包含了通过 Kubernetes API 可以访问到的所有信息，并且可以给予攻击者对集群 状态的可见性。所以要使用经过良好审查的备份和加密解决方案来进行数据加密，并且考虑在可能的情况下使用 全磁盘加密。 Kubernetes 1.7 包含了静态敏感信息加密（encryption at rest），它是一个 α 特性，会加密 Etcd 里面的 Secret 资源，以防止某一方通过查看这些 Secret 内容获取 Etcd 备份。虽然目前只是测试阶段，但是在关键时可 以提供额外防御层级。
- 开启集成前审查第三方 许多集成至 Kubernetes 的第三方插件都可以改变集群的安全配置，所以在启用第三方插件时，应当检查扩 展请求的权限，Kubernetes 中的 Pod 安全策略（PodSecurityPolicy）可以提高其安全性。
- 频繁回收基础证书 Kubernetes 中一个 Secret 或凭据的寿命越短，攻击者就越难使用该凭据，所以在证书上设置短生命周期并 实现自动回收证书是安全防护的一个好办法。因此使用身份验证机制时，应该设置发布令牌的可用时间，尽量缩 短寿命。 4.7.1.3 小结 在使用编排工具时注意以下几个风险项。 （1）编排工具中认证和授权机制是否合规 可为编排工具的各个访问接口提供独立的权限控制策略。比如 Kubernetes 的访问接口 API Server，由于 Kubernetes 各组件通信全部由 API驱动，控制用户访问集群以及允许用户执行哪些操作是第一道防线。类似的还 有 Docker CLI。 （2）编排工具对用户输入的合法性校验是否完善 可为编排工具自定义一个过滤用户输入内容的正则列表，以确保将非法的用户内容阻挡在外。 （3）编排工具对运行时的异常处理是否全面 运行时的异常处理流程是确保工具稳定运行的必要工作，目前 Kubernetes 集群内部各组件都有其各自的日 志可供查看，组件运行时异常可直接查看日志。当集群中部署的应用在集群中运行异常时，首先要查看是否是集 群的问题导致，若不是则排查是否是应用本身的问题。 （4）编排工具所依赖的运行环境是否安全
外部运行环境的安全是编排工具安全的前提，可以使用针对主机系统的安全防护工具来对编排的外部运行环 境进行安全加固。另外需要加固容器宿主机以缓解主机安全配置错误。更新容器引擎至最新版本避免旧版本存在 漏洞对主机造成危害。最后还有一些权限及审计的问题同样需受到重视。
