使用内置 Linux 安全功能保护对 Azure Kubernetes 服务（AKS）工作负荷资源的容器访问

用户命名空间的先决条件

• 现有的 AKS 群集。 如果没有群集，请使用 Azure CLI、 Azure PowerShell 或 Azure 门户创建群集。
• 控制平面和工作节点的最低 Kubernetes 版本 1.33。 如果不使用 Kubernetes 版本 1.33 或更高版本，则需要 升级 Kubernetes 版本。
• 运行 Azure Linux 3.0 或 Ubuntu 24.04 的工作器节点，以确保满足启用用户命名空间的最低 堆栈要求 。 如果需要升级作系统（OS）版本，请参阅 升级 OS 版本。

用户命名空间的限制

• 用户命名空间功能适用于 Linux 内核，Windows 节点池不支持此功能。
• 查看 Kubernetes 文档，了解用户命名空间 是否有任何其他限制。

用户命名空间概述

默认情况下，Linux Pod 使用多个命名空间运行：用于隔离网络标识的网络命名空间和用于隔离进程的 PID 命名空间。 用户命名空间（user_namespace）将容器中的用户与主机上的用户隔离开来。 它还会限制功能的范围和 Pod 与系统的其余部分的交互。

容器内的 UID 和 GID 映射到主机上的未特权用户，因此与主机其余部分的所有交互都发生在那些不受特权的 UID 和 GID 中。 例如，容器（UID 0）内的根可以映射到主机上的用户 65536。 Kubernetes 会创建映射，以确保它不会与系统上使用用户命名空间（user namespaces）的其他 Pod 发生重叠。

Kubernetes 实现具有一些关键优势。 若要了解详细信息，请参阅 Kubernetes 用户命名空间文档。

启用用户命名空间

1. 创建名为 mypod.yaml 的文件，并将其复制到以下清单中。 若要使用用户命名空间，YAML 需要具有字段 hostUsers: false。

   apiVersion: v1
   kind: Pod
   metadata:
     name: userns
   spec:
     hostUsers: false
     containers:
     - name: shell
       command: ["sleep", "infinity"]
       image: debian
   

2. 使用 kubectl apply 命令部署应用程序，并指定 YAML 清单的名称。

   kubectl apply -f mypod.yaml
   

3. 使用 kubectl get pods 命令查看已部署的 Pod 的状态。

   kubectl get pods
   

4. 使用 kubectl exec 命令将 Exec 执行到 Pod 中。

   kubectl exec -ti userns -- bash
   

5. 在 pod 内，使用以下命令检查 /proc/self/uid_map：

   cat /proc/self/uid_map
   

   输出在最后一列中应有 65536 。 例如：

   0  833617920      65536
   

   此输出表明容器（UID 0）中的根用户映射到主机上的用户 65536。

用户命名空间缓解的常见漏洞和暴露（CVE）

下表概述了使用user_namespaces部分或完全缓解的一些常见漏洞和风险：

请记住，此列表并不详尽。 若要了解详细信息，请参阅 Kubernetes v1.33：默认启用的用户命名空间。

AppArmor 先决条件

• 现有的 AKS 群集。 如果没有群集，请使用 Azure CLI、 Azure PowerShell 或 Azure 门户创建群集。

AppArmor 概述

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

使用 AppArmor 保护 Pod

可以在 Pod 或容器级别指定 AppArmor 配置文件。 容器 AppArmor 配置文件优先于 Pod AppArmor 配置文件。 如果未指定这两个条件，容器将无约束地运行。 有关 AppArmor 配置文件的详细信息，请参阅 通过 AppArmor 保护 Pod 的 Kubernetes 文档。

配置自定义 AppArmor 配置文件

以下示例创建一个自定义配置文件，该配置文件阻止从容器内部向文件写入。

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

2. 创建名为 deny-write.profile 的文件并粘贴以下内容：

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

3. 将 AppArmor 配置文件加载到节点上。

   # This example assumes that node names match host names, and are reachable via SSH.
   NODES=($( kubectl get node -o jsonpath='{.items[*].status.addresses[?(.type == "Hostname")].address}' ))
   
   for NODE in ${NODES[*]}; do ssh $NODE 'sudo apparmor_parser -q <<EOF
   #include <tunables/global>
   
   profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
     #include <abstractions/base>
   
     file,
   
     # Deny all file writes.
     deny /** w,
   }
   EOF'
   done
   

使用自定义 AppArmor 配置文件部署 Pod

1. 使用拒绝写入配置部署 “Hello AppArmor” Pod。

   apiVersion: v1
   kind: Pod
   metadata:
     name: hello-apparmor
   spec:
     securityContext:
       appArmorProfile:
         type: Localhost
         localhostProfile: k8s-apparmor-example-deny-write
     containers:
     - name: hello
       image: busybox:1.28
       command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
   

2. 使用 kubectl apply 命令应用 Pod 配置。

   kubectl apply -f hello-apparmor.yaml
   

3. 在 Pod 中执行并验证容器是否使用 AppArmor 配置文件运行。

   kubectl exec hello-apparmor -- cat /proc/1/attr/current
   

   输出应显示正在使用的 AppArmor 配置文件。 例如：

   k8s-apparmor-example-deny-write (enforce)
   

Seccomp 先决条件

• 现有的 AKS 群集。 如果没有群集，请使用 Azure CLI、 Azure PowerShell 或 Azure 门户创建群集。
• 需要 注册 KubeletDefaultSeccompProfilePreview 功能标志 才能在节点池上使用默认 seccomp 配置文件。

注册 KubeletDefaultSeccompProfilePreview 功能标志

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

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

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

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

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

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

   az provider register --namespace Microsoft.ContainerService
   

Seccomp 限制

• AKS 仅支持默认 seccomp 配置文件（RuntimeDefault 和 Unconfined）。 不支持自定义 seccomp 配置文件。
• SeccompDefault 不是 Windows 节点池支持的参数。

默认 seccomp 配置文件概述（预览版）

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

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

使用 seccomp 限制容器系统调用

1. 按照步骤通过在 kubelet 配置中指定来应用 seccomp 配置文件。"seccompDefault": "RuntimeDefault"
2. 连接到主机。
3. 验证配置是否已应用于节点。

使用 seccomp 解决工作负荷故障

启用SeccompDefault后，节点上计划的所有工作负荷都将使用容器运行时的默认 seccomp 配置文件，这可能会导致工作负荷因被阻止的系统调用而失败。 如果发生负载失败，您可能会看到如下错误：

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

如果遇到这些错误，建议将 seccomp 配置文件更改为 Unconfined。 Unconfined 对 syscalls 没有限制，允许执行所有系统调用。

自定义 seccomp 配置文件概述

使用自定义 seccomp 配置文件，您可以更细致地控制容器中的受限系统调用。 可以通过以下方式创建自己的 seccomp 配置文件：

• 使用筛选器指定要允许或拒绝的动作。
• 在 pod YAML 清单内批注以与 seccomp 筛选器相关联。

配置自定义 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 状态。

   kubectl get pods
   

   在输出中，您应该会看到 Pod 报告错误。 seccomp 筛选器阻止 chmod 命令运行，如示例输出所示：

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