使用内置 Linux 安全功能保护容器对资源的访问

本文介绍如何保护容器对 Azure Kubernetes 服务 (AKS) 工作负载资源的访问。

概述

与应该向用户或组授予所需最少权限的方式一样，也应将容器限制为只能访问它们所需的操作和进程。 为了尽量减少攻击风险，避免配置需要提升的权限或 root 访问权限的应用程序和容器。

可以使用内置的 Kubernetes Pod 安全上下文来定义更多权限，例如要作为哪个用户或组运行、要公开的 Linux 功能，或在 Pod 清单中设置 allowPrivilegeEscalation: false。 有关更多最佳做法，请参阅保护 Pod 对资源的访问。

若要更精确地控制容器操作，可以使用内置 Linux 安全功能，例如 AppArmor 和 seccomp。

1. 在节点级别定义 Linux 安全功能。
2. 通过 pod 清单实现功能。

内置的 Linux 安全功能仅在 Linux 节点和 Pod 上提供。

App Armor

若要限制容器操作，可以使用 AppArmor Linux 内核安全模块。 AppArmor 作为基础 AKS 节点 OS 的一部分提供，默认情况下处于启用状态。 可以创建 AppArmor 配置文件来限制读取、写入或执行等操作或者装载文件系统等系统功能。 默认 AppArmor 配置文件限制对各种 /proc 和 /sys 位置的访问，并提供一种在逻辑上将容器与基础节点隔离的方法。 AppArmor 适用于 Linux 上运行的任何应用程序，而不仅仅是 Kubernetes Pod。

为了通过实际操作了解 AppArmor，以下示例将创建一个阻止写入文件的配置文件。

1. 通过 SSH 连接到 AKS 节点。

2. 创建一个名为 deny-write.profile 的文件。

3. 复制并粘贴以下内容：

   #include <tunables/global>
   profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
     #include <abstractions/base>
   
     file,
     # Deny all file writes.
     deny /** w,
   }
   

使用 apparmor_parser 命令添加 AppArmor 配置文件。

1. 将配置文件添加到 AppArmor。

2. 指定在上一步中创建的配置文件的名称：

   sudo apparmor_parser deny-write.profile
   

   如果已正确分析配置文件并将其应用于 AppArmor，则不会显示任何输出，并且你将回到命令提示符。

3. 在本地计算机上，创建一个名为 aks-apparmor.yaml 的 Pod 清单。 此清单：

   • 为 container.apparmor.security.beta.kubernetes 定义一个注释。
   • 引用在前面的步骤中创建的 deny-write 配置文件。

   apiVersion: v1
   kind: Pod
   metadata:
     name: hello-apparmor
     annotations:
       container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-deny-write
   spec:
     containers:
     - name: hello
       image: mcr.azk8s.cn/dotnet/runtime-deps:6.0
       command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
   

4. 部署 Pod 后，运行以下命令并验证 hello-apparmor Pod 是否显示“正在运行”状态：

   kubectl get pods
   
   NAME             READY   STATUS    RESTARTS   AGE
   aks-ssh          1/1     Running   0          4m2s
   hello-apparmor   0/1     Running   0          50s
   

有关 AppArmor 的详细信息，请参阅 Kubernetes 中的 AppArmor 配置文件。

安全计算 (seccomp)

AppArmor 适用于任何 Linux 应用程序，seccomp（安全计算）则在进程级别运行。 Seccomp 也是一个 Linux 内核安全模块，并由 AKS 节点所用的 containerd 运行时提供本机支持。 借助 seccomp，你可以限制容器的系统调用。 Seccomp 建立了一个额外的保护层来防范恶意参与者利用的常见系统调用漏洞，并使你能够为节点中的所有工作负载指定一个默认的配置文件。

配置默认 seccomp 配置文件（预览）

创建新的 Linux 节点池时，可以使用自定义节点配置来应用默认的 seccomp 配置文件。 AKS 支持两个值：RuntimeDefault 和 Unconfined。 某些工作负载需要的 syscall 限制可能比其他工作负载要少。 这意味着它们在使用“RuntimeDefault”配置文件的运行时期间可能会失败。 若要缓解此类失败，可以指定 Unconfined 配置文件。 如果工作负载需要自定义配置文件，请参阅配置自定义 seccomp 配置文件。

限制

• SeccompDefault 不是 Windows 节点池支持的参数。
• SeccompDefault 从 2024-09-02-preview API 开始可用。

注册 KubeletDefaultSeccompProfilePreview 功能标志

1. 使用 az feature register 命令注册 KubeletDefaultSeccompProfilePreview 功能标志。

   az feature register --namespace "Microsoft.ContainerService" --name "KubeletDefaultSeccompProfilePreview"
   

   状态显示为“已注册”需要几分钟时间。

2. 使用 az feature show 命令验证注册状态。

   az feature show --namespace "Microsoft.ContainerService" --name "KubeletDefaultSeccompProfilePreview"
   

3. 当状态反映为已注册时，使用 az provider register 命令刷新 Microsoft.ContainerService 资源提供程序的注册。

   az provider register --namespace Microsoft.ContainerService
   

使用 seccomp 限制容器的系统调用

1.按照步骤，通过指定 "seccompDefualt": "RuntimeDefault" 在 kubelet 配置中应用 seccomp 配置文件。

RuntimeDefault 使用容器的默认 seccomp 配置文件，限制某些系统调用来提高安全性。 受限制的 syscall 将失败。 有关详细信息，请参阅 containerD 默认 seccomp 配置文件。

2.检查是否已应用配置。

可以通过连接到主机并验证是否已在文件系统上进行了配置更改，确认设置已应用到节点。

3.排查工作负载失败情况。

启用 SeccompDefault 后，默认情况下，容器运行时默认 seccomp 配置文件用于节点上计划的所有工作负载。 这可能会导致工作负载由于 syscall 被阻止而失败。 如果工作负载失败，可能会看到如下错误：

• 启用该功能后，工作负载意外存在，出现“权限被拒绝”错误。
• 通过在默认配置文件中将 SCMP_ACT_ERRNO 替换为 SCMP_ACT_LOG，也可以在 auditd 或 syslog 中看到 Seccomp 错误消息。

如果遇到上述错误，建议将 seccomp 配置文件更改为 Unconfined。 Unconfined 对 syscall 没有限制，允许所有系统调用，这降低了安全性。

配置自定义 seccomp 配置文件

使用自定义 seccomp 配置文件，可以更精细地控制受限制的 syscall。 通过以下方式，遵循授予容器运行所需要的最低权限的最佳做法：

• 定义时采用筛选器，以筛选允许或拒绝的操作。
• 在 pod YAML 清单内批注以与 seccomp 筛选器相关联。

为了通过实际操作了解 seccomp，请创建一个筛选器来阻止更改文件权限。

1. 通过 SSH 连接到 AKS 节点。

2. 创建名为 /var/lib/kubelet/seccomp/prevent-chmod 的 seccomp 筛选器。

3. 复制并粘贴以下内容：

   {
     "defaultAction": "SCMP_ACT_ALLOW",
     "syscalls": [
       {
         "name": "chmod",
         "action": "SCMP_ACT_ERRNO"
       },
       {
         "name": "fchmodat",
         "action": "SCMP_ACT_ERRNO"
       },
       {
         "name": "chmodat",
         "action": "SCMP_ACT_ERRNO"
       }
     ]
   }
   

   在版本 1.19 及更高版本中，需要配置以下各项：

   {
     "defaultAction": "SCMP_ACT_ALLOW",
     "syscalls": [
       {
         "names": ["chmod","fchmodat","chmodat"],
         "action": "SCMP_ACT_ERRNO"
       }
     ]
   }
   

4. 在本地计算机上，创建一个名为 aks-seccomp.yaml 的 Pod 清单并粘贴以下内容。 此清单：

   • 为 seccomp.security.alpha.kubernetes.io 定义一个注释。
   • 引用在上一步中创建的 prevent-chmod 筛选器。

   apiVersion: v1
   kind: Pod
   metadata:
     name: chmod-prevented
     annotations:
       seccomp.security.alpha.kubernetes.io/pod: localhost/prevent-chmod
   spec:
     containers:
     - name: chmod
       image: mcr.azk8s.cn/dotnet/runtime-deps:6.0
       command:
         - "chmod"
       args:
        - "777"
        - /etc/hostname
     restartPolicy: Never
   

   在版本 1.19 及更高版本中，需要配置以下各项：

   apiVersion: v1
   kind: Pod
   metadata:
     name: chmod-prevented
   spec:
     securityContext:
       seccompProfile:
         type: Localhost
         localhostProfile: prevent-chmod
     containers:
     - name: chmod
       image: mcr.azk8s.cn/dotnet/runtime-deps:6.0
       command:
         - "chmod"
       args:
        - "777"
        - /etc/hostname
     restartPolicy: Never
   

5. 使用 kubectl apply 命令部署示例 Pod：

   kubectl apply -f ./aks-seccomp.yaml
   

6. 使用 kubectl get pods 命令查看 Pod 状态。

   • 该 Pod 报告一个错误。
   • seccomp 筛选器阻止 chmod 命令运行，如示例输出所示：

   kubectl get pods
   
   NAME                      READY     STATUS    RESTARTS   AGE
   chmod-prevented           0/1       Error     0          7s
   

seccomp 安全配置文件选项

seccomp 安全配置文件是一组定义的被允许或受到限制的 syscall。 大多数容器运行时都有一个默认的 seccomp 配置文件，该文件如果与 Docker 使用的不相同，则与之相似。 有关可用配置文件的详细信息，请参阅 Docker 或 containerD 默认 seccomp 配置文件。

使用自定义节点配置配置 seccomp 时，AKS 使用 RuntimeDefault 的 containerD 默认 seccomp 配置文件。

默认配置文件阻止的重要 syscall

Docker 和 containerD 都维护有安全 syscall 的允许列表。 此表列出了因不在允许列表上而被有效阻止的重要（但并非全部）syscall。 如果工作负载需要任何被阻止的 syscall，请不要使用 RuntimeDefault seccomp 配置文件。

对 Docker 和 containerD 进行更改时，AKS 会更新其默认配置来进行匹配。 更新此列表可能会导致工作负载失败。 有关发布更新，请参阅 AKS 发行说明。

后续步骤

如需相关的最佳做法，请参阅 AKS 中群集安全性和升级的最佳做法和 AKS 中的 Pod 安全的最佳做法。