Pod安全上下文与Linux Capabilities浅析

目录

前言

一、Pod安全上下文介绍

二、使用方法与应用场景

2.1 以普通用户运行容器

2.2 限制特权容器的使用

2.3 设置文件系统只读

三、Linux Capabilities

概念

使用方式

使用示例

四、总结

前言

        在云原生时代，Kubernetes 已经成为容器编排的事实标准，提供了强大的功能以支持各种规模和复杂度的应用部署。然而，随着 Kubernetes 在企业中的广泛应用，安全性问题也日益凸显。为了确保集群安全，我们必须对运行在 Kubernetes 中的容器和 Pod 进行严格的安全管控。Pod 安全上下文（Security Context）是 Kubernetes 提供的关键特性之一，它允许在 Pod 和容器级别设置安全相关的参数，以实现对容器的细粒度安全控制。

        本文将探讨 Pod 安全上下文的核心概念、应用场景、操作方法及其在实际环境中的应用。从以非 Root 用户运行容器的好处、限制容器的特权模式的必要性、设置只读文件系统的优点，以及如何利用 Linux Capabilities 进行更细粒度的权限控制等方面进行探讨。通过合理配置这些安全机制，我们可以显著提高 Kubernetes 集群的安全性，降低潜在的安全威胁。

一、Pod安全上下文介绍

        在Kubernetes中，Pod安全上下文（Security Context）是一种提供安全机制的重要特性，它允许用户在Pod和容器级别设置特权和访问控制。通过合理配置安全上下文，我们可以增强应用程序的安全性，降低容器逃逸和提权等安全风险。

安全上下文主要从以下几个维度对Pod和容器进行限制：

1. 以普通用户而非Root用户运行
2. 限制容器的特权模式
3. 设置文件系统的只读访问
4. 添加或移除Linux Capabilities

        其中一些安全机制可以在Pod级别进行设置，作用于Pod内的所有容器；而有些则可以在容器级别进行更细粒度的控制。通常，容器级别的安全设置可以覆盖Pod级别的设置。

二、使用方法与应用场景

2.1 以普通用户运行容器

默认情况下，容器中的应用程序都是以Root用户运行的。然而容器内的Root用户与宿主机的Root用户权限相当，拥有对Linux内核的大部分系统调用权限，存在一定的安全隐患。因此，我们应该尽量避免使用Root用户运行容器进程，转而使用普通用户以最小权限原则运行。

设置普通用户可以通过以下两种方式实现：

1、在Dockerfile中使用USER指令指定运行用户

  Dockerfile

FROM ubuntu:20.04
RUN useradd -m appuser
USER appuser    #设置运行用户为appuser
CMD ["sleep", "infinity"]

2、在Pod的spec.securityContext或containers[].securityContext字段中设置runAsUser，指定容器的默认用户UID，在spec下层级设置（pod级别），在containers下层级设置（container级别）。需要注意的是，普通用户的UID默认从1000开始分配，而Root用户的UID为0

在pod级别设置

apiVersion: v1
kind: Pod
metadata:
  name: security-context-user-example
spec:
  securityContext:
    runAsUser: 1000
  containers:
  - name: app
    image: ubuntu:20.04
    command: ["sleep", "infinity"]

在容器级别设置

apiVersion: v1
kind: Pod
metadata:
  name: container-user-example  
spec:
  containers:
  - name: app
    image: ubuntu:20.04
    command: ["sleep", "infinity"]
    securityContext:
      runAsUser: 1000

2.2 限制特权容器的使用

某些容器化应用可能需要访问宿主机设备、修改内核参数等敏感操作，这时候可能会启用特权模式（privileged mode）。然而，开启特权模式就意味着容器几乎拥有了访问Linux内核的所有能力，极大地增加了安全风险。

为了在授予容器必要权限的同时最小化安全风险，我们可以使用Linux Capabilities机制，更细粒度地控制容器对宿主机内核的访问能力，避免直接使用privileged模式。

打开特权模式Yaml（如果不设置，默认为关闭）

apiVersion: v1
kind: Pod
metadata:
  name: privileged-pod-example
spec:
  containers:
  - name: privileged-container
    image: ubuntu:20.04
    command: ["sleep", "infinity"]
    securityContext:
      privileged: true

使用Capabilities机制，只给容器分配必需的内核能力，而不是直接使用特权模式

        在容器的securityContext中，首先使用capabilities.drop字段删除了容器的所有Capabilities。这一步相当于从容器中收回了所有的特权，使其权限降到最低。

        接下来，使用capabilities.add字段，只为容器添加了NET_RAW这一种Capability。NET_RAW允许容器使用原始套接字（RAW Sockets），这是执行ping命令所必需的能力。

        有了NET_RAW，就可以在容器内执行ping命令了：

apiVersion: v1
kind: Pod
metadata:
  name: cap-net-raw-example
spec:
  containers:
  - name: ping-container
    image: alpine:3.14
    command: ["sleep", "infinity"]
    securityContext:
      capabilities:
        drop:
        - ALL
        add: ["NET_RAW"]

2.3 设置文件系统只读

        在某些场景下，容器只需要读取持久化数据，而不需要对其进行修改。这时我们可以在容器的安全上下文中设置readOnlyRootFilesystem参数为true，将容器的根文件系统挂载为只读模式。这样即使容器中存在恶意程序，它也无法创建或修改容器内的文件，一定程度上保障了宿主机的安全。

        在容器的securityContext中设置了readOnlyRootFilesystem: true，这会将容器的根文件系统挂载为只读模式。在只读模式下，容器内的进程无法对根文件系统进行任何写操作，包括创建、修改和删除文件。

apiVersion: v1
kind: Pod
metadata:
  name: readonly-pod-example
spec:
  containers:
  - name: readonly-container
    image: nginx:1.21
    securityContext:
      readOnlyRootFilesystem: true
    volumeMounts:
    - name: temp-volume
      mountPath: /tmp
    - name: logs-volume
      mountPath: /var/log/nginx
  volumes:
  - name: temp-volume
    emptyDir: {}
  - name: logs-volume
    emptyDir: {}

        设置只读文件系统是提高容器安全性的一种有效手段，特别适用于无状态的应用程序。合理使用这一特性，结合必要的读写卷，可以在不影响功能的前提下，最小化容器的攻击面，提供更强的安全保证。

三、Linux Capabilities

概念

        Linux Capabilities是在Linux内核2.2版本中引入的一种权限控制机制，用于实现比传统超级用户更细粒度的权限划分。在传统的Unix权限模型中，进程或者要完全拥有Root权限，或者完全没有特权。而Capabilities将Root权限划分成了不同的能力，例如修改文件所有者、挂载文件系统、设置系统时间等，进程可以只拥有其中一部分能力，减少潜在的安全风险。

        目前Linux内核定义了40多种不同的Capability，可以通过man 7 capabilities命令查看完整列表。下面列举一些常见的Capabilities：

• CAP_CHOWN: 允许改变文件所有者
• CAP_DAC_OVERRIDE: 忽略文件的DAC访问限制
• CAP_KILL: 允许对不属于自己的进程发送信号
• CAP_NET_ADMIN: 允许执行网络管理任务
• CAP_SYS_TIME: 允许修改系统时间

overview of Linux capabilities：capabilities(7) - Linux manual page

使用方式

在Kubernetes中，我们可以通过Pod或Container的securityContext.capabilities字段来添加或删除容器的Capabilities。

使用示例

示例1：为容器添加SYS_TIME能力

        在这个例子中，通过capabilities.add字段为容器添加了SYS_TIME能力，使其可以修改系统时间，同时移除了其他非必要的特权。

apiVersion: v1
kind: Pod
metadata:
  name: cap-add-example
spec:
  containers:
  - name: example
    image: centos:7
    command: ["/bin/sleep", "999999"]
    securityContext:
      capabilities:
        add: ["SYS_TIME"]

示例2：删除容器的所有Capabilities

        这个例子使用capabilities.drop字段移除了容器的所有Capabilities，将其权限降至最低，这种做法适用于对安全要求很高，应用程序也不需要任何特权的场景。

apiVersion: v1
kind: Pod
metadata:
  name: cap-drop-example
spec:
  containers:
  - name: example
    image: centos:7 
    command: ["/bin/sleep", "999999"]
    securityContext:
      capabilities:
        drop:
        - ALL

示例3：设置容器默认的Capabilities

        在这个例子中，在Pod级别的securityContext中删除了所有默认的Capabilities，然后只添加了容器必需的NET_BIND_SERVICE能力（允许绑定到低于1024的端口）。这个配置会作用于Pod内的所有容器。

apiVersion: v1
kind: Pod
metadata:
  name: cap-default-example
spec:
  containers:
  - name: example
    image: centos:7
    command: ["/bin/sleep", "999999"]
  securityContext:
    capabilities:
      drop:
      - ALL
      add: ["NET_BIND_SERVICE"]

四、总结

        Pod安全上下文是Kubernetes提供的一种细粒度的安全机制，管理员和开发者应该合理利用这一特性，在提供必要权限的同时遵循最小权限原则。通过以普通用户运行容器、限制特权模式、设置文件系统只读等方法，再辅以Linux Capabilities进行精细化控制，多管齐下，可以全面提升Kubernetes集群内的容器安全性，使其更加适应生产环境的需求。