容器安全基础：编排

如果您刚开始阅读本系列，建议从头开始：
容器安全基础：简介
容器安全基础：流水线

根据Tripwire《2019 年容器安全状况报告》，目前约三分之一（32%）的组织在生产环境中运行着100多个容器。另有13%的组织运行着500多个容器，6%的积极采用者目前管理着1,000多个容器。大规模运行容器的组织很少会不借助编排系统。

容器安全的编排层侧重于负责容器日常运行的环境。根据目前可用的数据，如果您正在使用容器，几乎可以肯定也在使用Kubernetes作为编排系统。

需要注意的是，还有其他编排工具，但其中大多数也在利用源自Kubernetes的组件和概念。因此，我们将重点介绍Kubernetes及其组件的安全性。

Kubernetes环境

Kubernetes由多个动态组件构成。其安全防护更具挑战性，不仅因为涉及的组件众多，还因为这些组件之间存在复杂的交互方式。有些组件通过API通信，有些则通过主机文件系统通信。所有这些组件都可能成为进入编排环境的入口，因此必须妥善应对。

基本Kubernetes环境

需要关注的核心组件概览：

• API Server和Kubelet
• Pod
• Etcd

这意味着不妨先泡杯咖啡，因为读完这部分需要多花些时间。

1. 身份验证并非可选项

敏锐的读者会发现，这听起来很熟悉。您可能听说过“安全规则二”，也称“锁好门”。这是我们会反复强调的常见主题，因为它经常被忽视。必须采用强身份验证。我们注意到，因容器安全实践不当而导致的安全事件数量持续上升。其中一个常见原因是未使用身份验证，这通常发生在公有云部署中。

应要求使用高强度凭据，并经常轮换。通过不安全的控制台访问API服务器可能导致“满盘皆输”，因为攻击者可以借此控制整个编排环境，包括部署Pod、更改配置以及停止或启动容器。在Kubernetes环境中，API服务器是“统管一切的API”，必须防止其落入恶意行为者手中。

如何保护API服务器和Kubelet
请注意，这些建议基于当前的Kubernetes授权模型。请始终查阅所用版本的最新文档。

• 全面启用mTLS
  - 为每项服务（k8s、etcd、应用程序）分别配置专用CA
  - 轮换证书，并注意磁盘上私钥的访问权限
  
• 仅绑定到安全地址
  - 注意API配置“insecure-bind-address”和“insecure-port”
  - 将此设置应用于_所有_服务（SSH、Vault、etcd）
  
• 禁用“匿名身份验证”
  - “匿名身份验证”听起来是个好主意吗？
  - 从1.5版本开始默认禁用，可使用“--anonymous-auth=True”手动启用
  
• 启用授权
  - 不要使用“--authorization-mode=AlwaysAllow”
  - API Server应使用“--authorization-mode=RBAC,Node”
  - Kubelet应使用“--authorization-mode=Webhook”
  - 限制Kubelet，使其只能访问自身节点上的资源。
  

请注意，这些建议基于当前的Kubernetes授权模型。请务必查阅所用版本的最新文档。

• Kubernetes 授权参考
• Kubelet 身份验证和授权参考

2. Pod 与权限

Pod是容器的集合，也是Kubernetes中最小的组件。根据所使用的容器网络接口（CNI）插件，默认情况下，所有Pod可能都能相互访问。某些CNI插件可以使用“网络策略”来限制这种默认行为。需要特别注意这一点，因为Pod可能会被调度到不同的Kubernetes节点上（节点类似于物理服务器）。Pod通常还会挂载Secret，其中可能包含私钥、身份验证令牌及其他敏感信息。因此，它们才被称为“Secret”。

这意味着Pod存在多项安全隐患。在F5，我们开展威胁建模时，始终假设Pod已遭入侵。这是因为应用工作负载部署在Pod中。应用工作负载最有可能面临不受信任的访问，因此也最有可能成为入侵点。基于这一假设，需要回答四个基本问题，以规划如何缓解潜在威胁。

1. 攻击者获得一个Pod的访问权限后，可以查看其他Pod中的哪些内容，或对其他Pod执行哪些操作？
2. 攻击者能否访问集群中的其他服务？
3. 自动挂载了哪些密钥？
4. 已向Pod服务账号授予哪些权限？

这些问题的答案会揭示相关风险：如果攻击者获得对集群内某个Pod的访问权限，便可能利用这些风险。缓解Pod遭入侵的威胁需要采取多层面的方法，包括配置选项、权限控制和系统级限制。请注意，多个Pod可以部署在同一个物理或虚拟节点上，因此会共享操作系统访问权限，通常是Linux操作系统。

如何缓解Pod威胁
Kubernetes包含Pod安全策略资源，用于控制Pod的敏感方面。运维人员可通过该资源定义Pod获准进入系统所必须满足的运行条件，并强制实施Pod安全上下文基线。切勿认为默认设置是安全的。应实施安全基线并验证是否符合预期，以防范Pod威胁。

Pod安全策略的具体选项应涵盖以下方面：

• 避免使用特权容器
  • 检查kube-api和/或kubelet上的“—allow-privileged”设置
  • 在Pod规范中查找“privileged: true”。
  • 使用“--allow-privileged=false”降低安全风险
• Docker的默认容器用户是root
  • 避免以root身份运行任何工作负载
  • Pod安全策略可以使用“runAsUser”、“runAsGroup”和“runAsNonRoot: true”
  • 可在Dockerfile中定义类似选项
• 禁止容器内的权限提升
  • “allowPrivilegeEscalation: false”
• 使用SELinux或AppArmor
  • SELinux将利用多类别安全机制实现容器之间的相互隔离
  • 保持启用，并逐一解决拒绝问题
  • 禁用或更改为宽容模式会严重降低安全性
• 防止符号链接和入口点攻击
  • 攻击者可以覆盖入口点二进制文件或创建恶意符号链接
  • 将“readOnlyRootFilesystem: true”设置为只读根文件系统，以避免此问题
• 避免使用host*配置选项
  • 能够访问主机资源的攻击者更有可能进一步入侵主机和/或相邻容器
  • 避免使用hostPID、hostIPC、hostNetwork、hostPorts等选项
• 只读hostPath挂载
  • 如果必须配置对主机的读写访问，请谨慎部署，切勿将其作为默认做法
  • 对所有allowedHostPaths使用“readOnly”，以避免遭受攻击
• Seccomp配置文件
  • 通过限制允许的系统调用来缩小威胁面
  • Docker默认配置可减少部分威胁面，但这是一个通用配置文件
  • 应用专用配置文件可提供更显著的安全优势

3. Etcd

Etcd用于存储配置和密钥。一旦遭到入侵，攻击者可能会提取敏感数据或注入恶意数据，这两种情况都会带来风险。要缓解etcd面临的威胁，需要控制访问权限。较为有效的方法是强制实施mTLS。Kubernetes将密钥以base64编码形式存储在etcd中。存储敏感密钥时，可考虑使用Alpha功能“encryption provider”，以获得更强的保护选项；也可考虑使用HashiCorp Vault。

阅读本系列的下一篇博客：
容器安全基础：工作负载