防止进程逃离容器边界并获得权限

作为使用Kubernetes的开发或者运维人员，您需要重点关注如何防止在容器中运行的进程逃离容器的隔离边界并获得对宿主机的访问权限。这样做主要有两个原因：

• 首先，容器内运行的进程默认在 [Linux] root 用户的上下文中运行。尽管 root 在容器中的操作部分受到Docker分配给容器的 Linux capabilities 的限制，但这些默认权限可能允许攻击者提权或者访问到宿主机的敏感信息，包括 Secrets 和 ConfigMap 等敏感资源。下面是分配给Docker容器的默认 capabilities 列表。更多信息，请参见 capabilities(7) — Linux manual page 。

  cap_chown, cap_dac_override, cap_fowner, cap_fsetid, cap_kill, cap_setgid, cap_setuid, cap_setpcap, cap_net_bind_service, cap_net_raw, cap_sys_chroot, cap_mknod, cap_audit_write, cap_setfcap .

  应尽可能避免使用以特权身份（ privileged ）运行Pod，因为其拥有与宿主机上root关联的所有Linux capabilities 。

• 其次，所有Kubernetes工作节点都使用一种称为节点授权者的授权模式。节点授权者授权所有源自Kubelet的API请求，并允许节点执行以下操作：

  读操作：

  • Services

  • Endpoints

  • Nodes

  • Pods

  • 与绑定到Kubelet节点的Pod相关的Secrets、Configmaps、PV和PVC

  写操作：

  • 节点和节点状态（启用 NodeRestriction 准入插件以限制Kubelet修改自己的节点）

  • Pods和Pod状态（启用 NodeRestriction 准入插件以限制Kubelet修改绑定到自身的Pod）

  • Events

  Auth相关操作：

  • 对用于TLS引导的 CertificateSigningRequest (CSR) API的读/写访问权限

  • 能够为委托的身份认证/授权检查创建 TokenReview 和 SubjectAccessReview

ACK集群默认使用节点限制准入控制器。该控制器仅允许节点修改绑定到节点的一组有限节点属性和Pod对象，但是设法访问主机的攻击者仍然能够从Kubernetes API搜集环境中的敏感信息。更多信息，请参见 节点限制准入控制器 。

Pod安全配置建议

• 限制容器以特权模式运行

  如前所述，以特权身份运行的容器继承了分配给主机上root的所有Linux capabilities。大多数场景下，容器并不是必须拥有这些权限才能保证业务运行。您可以通过创建Pod安全策略来拒绝容器配置为以特权模式运行的Pod。您可以将Pod安全策略视为Pod在创建之前必须满足的一组安全约束。ACK提供了基于OPA和gatekeeper的 容器安全策略 能力，可以验证在集群上创建和更新Pod的请求，该请求基于用户配置的安全规则。如果创建或更新Pod的请求不符合定义的规则，系统将拒绝该请求并返回错误。同样，您可以通过部署 ACKPSPPrivilegedContainer 策略限制，在集群指定范围的命名空间中部署privileged特权容器。

• 限制应用程序进程以root身份运行

  默认情况下，容器都以root身份运行。如果攻击者能够利用应用程序中的漏洞并获得正在运行的容器的shell访问权限，这可能会出现安全问题。您可以通过多种方式缓解此类风险。一种方式是，通过从容器镜像中删除shell。另一种方式是，将USER指令添加到您的Dockerfile或以非root用户身份在Pod中运行容器。Kubernetes podSpec在 spec.securityContext 下包含 runAsUser 和 runAsGroup 两个字段，允许您指定运行应用程序的用户和组。您可以通过创建 ACKPSPAllowedUsers 策略来限制。

• 禁止以Docker in Docker的方式运行容器或者在容器中挂载Docker.sock

  使用嵌套容器或者挂载Docker.sock的方式可以方便地在Docker容器中构建/运行容器镜像，但您将节点的控制权交给了在容器中运行的进程。关于在Kubernetes上构建容器镜像，请参见 使用企业版实例构建镜像 、 Kaniko 、 img 。

• 限制使用HostPath，如果需要使用HostPath，限制只可以挂载指定前缀的目录并将卷配置为只读

  使用 HostPath 可以直接将宿主机的目录挂载到容器中。很少有业务场景的Pod用到此功能特性。但如果确实有业务需要，您需要了解其中的风险。默认情况下，以root身份运行的Pod将拥有对 HostPath 暴露的文件系统的写访问权限。这可能允许攻击者修改 Kubelet 设置，创建指向未直接通过 HostPath 暴露的目录或文件的符号链接，例如 /etc/shadow 、安装Ssh密钥、读取挂载到主机的密钥以及进行恶意操作。为了降低使用 HostPath 的风险，请将 spec.containers.volumeMounts 配置为只读，例如：

  volumeMounts:
  - name: hostPath-volume
      readOnly: true
      mountPath: /host-path

  同样，您可以通过部署 ACKPSPHostFilesystem 策略实例，限制在集群指定命名空间范围内部署的Pod允许挂载的主机Host目录范围。

• 为每个容器设置请求和资源限制，避免资源争夺或DoS攻击

  没有请求或资源限制的Pod理论上可以消耗掉主机上的所有可用资源。当有Pod被调度到此节点上时，该节点可能会遭遇CPU或内存不足的情况，这可能导致 Kubelet 崩溃或从节点驱逐Pod。虽然无法完全避免这种情况的发生，但设置请求和资源限制将有助于最大程度地减少资源争夺，并降低应用程序编写不当导致资源消耗过多所带来的风险。

  PodSpec允许您限制CPU和内存的使用。您可以通过在命名空间上设置Resource Quota或创建Limit Range来强制对请求和资源进行限制。资源配额允许您指定分配给命名空间的资源总量，例如CPU和RAM。当应用于命名空间时，会强制您为部署到该命名空间中的所有容器指定请求和资源的限制。相比之下，限制范围可让您更精细地控制资源分配。通过限制范围，您可以为命名空间内的每个Pod或每个容器的CPU和内存资源设置最小值/最大值。如果没有提供，您还可以设置默认请求/限制值。更多信息，请参见 Managing Resources for Containers 。

  同样，您可以通过部署 ACKContainerLimits 策略实例，要求在集群指定命名空间范围内部署的应用Pod必须配置的资源限制。

• 禁止使用特权提升配置

  特权提升允许进程更改其运行所在的安全上下文。例如 sudo ，带有 SUID 或 SGID 位的二进制文件也是如此。特权升级基本上是用户以另一个用户或组的权限执行文件的一种方式。您可以将 allowPriviledgedEscalation 设置为 false 的 pod 安全策略或通过在 podSpec 中设置 securityContext.allowPrivilegedEscalation 来阻止容器进行特权提升。

  同样，您可以通过部署 ACKPSPAllowPrivilegeEscalationContainer 策略实例，强制要求在集群指定命名空间范围内部署的Pod配置 allowPrivilegeEscalation 参数。

• 禁用Service Account令牌自动挂载

  对于不需要访问Kubernetes API的Pod，您可以在 PodSpec 上禁止自动挂载 ServiceAccount 令牌，或禁用所有使用特定 ServiceAccount 的Pod。

  apiVersion: v1
  kind: Pod
  metadata:
    name: pod-no-automount
  spec:
    automountServiceAccountToken: false

  禁用 ServiceAccount 自动挂载不会阻止Pod对Kubernetes API的网络访问。为阻止Pod对Kubernetes API进行网络访问，您需要修改ACK集群 Endpoint 访问并使用网络策略Network Policy来阻止Pod对Kubernetes API进行网络访问。具体操作，请参见 在ACK集群使用网络策略 。

  apiVersion: v1
  kind: ServiceAccount
  metadata:
    name: sa-no-automount
  automountServiceAccountToken: false

  同样，您可以通过部署 ACKBlockAutomountToken 策略实例，要求在应用Pod中设置 automountServiceAccountToken: false 字段，以防止自动挂载Service Account。

• 禁用服务发现

  对于不需要查找或调用集群服务的Pod，您可以减少提供给Pod的信息量。您可以将Pod的DNS策略设置为不使用CoreDNS，并且不将命名空间中的Service暴露为Pod中的环境变量。更多信息，请参见 Environment variables 。

  Pod的DNS策略的默认值是 ClusterFirst ，使用集群内DNS，而非默认值 Default 使用底层节点的DNS解析。更多信息，请参见 Kubernetes docs on Pod DNS policy 。

  禁用服务链接和更改Pod的DNS策略不会阻止Pod对集群内DNS服务进行网络访问。攻击者仍然可以通过访问集群内DNS服务来枚举集群中的服务（例如： dig SRV *.*.svc.cluster.local @$CLUSTER_DNS_IP ）。关于阻止集群内服务发现，请参见 在ACK集群使用网络策略 。

  apiVersion: v1
  kind: Pod
  metadata:
    name: pod-no-service-info
  spec:
      dnsPolicy: Default # “默认值”不是真正的默认值。
      enableServiceLinks: false

• 配置镜像为只读文件系统

  将您的镜像配置为只读文件系统可防止攻击者覆盖您的应用程序使用的文件系统上的文件。如果您的应用程序必须写入文件系统，请考虑写入临时目录或挂载附加卷。您可以通过如下设置Pod的 SecurityContext 来强制执行此操作：

  ...
  securityContext:
    readOnlyRootFilesystem: true
  ...

  同样，您可以通过部署 ACKPSPReadOnlyRootFilesystem 策略实例，限制在集群指定命名空间范围内部署的Pod只能使用只读的根文件系统。