使用 AppArmor 限制容器对资源的访问

本页展示了如何在节点上加载 AppArmor 配置文件，并在 Pod 中强制执行这些配置文件。要深入了解 Kubernetes 如何使用 AppArmor 约束 Pod，请参阅 Pod 和容器的 Linux 内核安全约束。

目标

• 查看如何在节点上加载配置文件的示例
• 学习如何在 Pod 上强制执行配置文件
• 学习如何检查配置文件是否已加载
• 查看违反配置文件时会发生什么
• 查看无法加载配置文件时会发生什么

开始之前

AppArmor 是一个可选的内核模块和 Kubernetes 功能，因此请在继续之前验证您的节点是否支持它。

1. AppArmor 内核模块已启用 -- 为了让 Linux 内核强制执行 AppArmor 配置文件，必须安装并启用 AppArmor 内核模块。许多发行版（如 Ubuntu 和 SUSE）默认启用该模块，还有许多其他发行版提供可选支持。要检查该模块是否已启用，请查看 /sys/module/apparmor/parameters/enabled 文件。

   cat /sys/module/apparmor/parameters/enabled
   Y
   

   在接纳明确配置了 AppArmor 的 Pod 之前，kubelet 会验证宿主机上是否已启用 AppArmor。

2. 容器运行时支持 AppArmor -- 所有 Kubernetes 支持的常见容器运行时都应支持 AppArmor，包括 containerd 和 CRI-O。请参考相应的运行时文档，并验证集群是否满足使用 AppArmor 的要求。

3. 配置文件已加载 -- AppArmor 是通过指定每个容器应使用的 AppArmor 配置文件来应用于 Pod 的。如果指定的任何配置文件未在内核中加载，kubelet 将拒绝该 Pod。您可以通过检查 /sys/kernel/security/apparmor/profiles 文件来查看节点上加载了哪些配置文件。例如：

   ssh gke-test-default-pool-239f5d02-gyn2 "sudo cat /sys/kernel/security/apparmor/profiles | sort"
   

   apparmor-test-deny-write (enforce)
   apparmor-test-audit-write (enforce)
   docker-default (enforce)
   k8s-nginx (enforce)
   

   有关在节点上加载配置文件的更多详细信息，请参阅 使用配置文件设置节点。

保护 Pod 安全

可以在 Pod 级别或容器级别指定 AppArmor 配置文件。容器 AppArmor 配置文件优先于 Pod 配置文件。

securityContext:
  appArmorProfile:
    type: <profile_type>

其中 <profile_type> 是以下之一：

• RuntimeDefault：使用运行时的默认配置文件
• Localhost：使用加载在宿主机上的配置文件（见下文）
• Unconfined：在没有 AppArmor 的情况下运行

请参阅 指定 AppArmor 约束 以获取有关 AppArmor 配置文件 API 的全部详细信息。

为了验证配置文件是否已应用，您可以通过检查容器根进程的 proc 属性，确认其是否正在使用正确的配置文件运行：

kubectl exec <pod_name> -- cat /proc/1/attr/current

输出看起来应该如下所示：

cri-containerd.apparmor.d (enforce)

示例

本示例假设您已经设置了一个支持 AppArmor 的集群。

首先，将您要使用的配置文件加载到节点上。此配置文件会阻止所有文件写入操作：

#include <tunables/global>

profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
  #include <abstractions/base>

  file,

  # Deny all file writes.
  deny /** w,
}

配置文件需要加载到所有节点上，因为您不知道 Pod 将被调度到哪里。在此示例中，您可以使用 SSH 安装配置文件，但 使用配置文件设置节点 中讨论了其他方法。

# 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

接下来，使用 deny-write 配置文件运行一个简单的 "Hello AppArmor" Pod：

pods/security/hello-apparmor.yaml

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" ]

kubectl create -f hello-apparmor.yaml

您可以通过检查 /proc/1/attr/current 来验证容器是否确实在使用该配置文件运行：

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

输出应为

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

最后，您可以查看通过写入文件违反配置文件时会发生什么：

kubectl exec hello-apparmor -- touch /tmp/test

touch: /tmp/test: Permission denied
error: error executing remote command: command terminated with non-zero exit code: Error executing in Docker Container: 1

总结一下，查看如果您尝试指定未加载的配置文件会发生什么：

kubectl create -f /dev/stdin <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: hello-apparmor-2
spec:
  securityContext:
    appArmorProfile:
      type: Localhost
      localhostProfile: k8s-apparmor-example-allow-write
  containers:
  - name: hello
    image: busybox:1.28
    command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
EOF

pod/hello-apparmor-2 created

尽管 Pod 创建成功，但进一步检查会发现它停留在 pending 状态：

kubectl describe pod hello-apparmor-2

Name:          hello-apparmor-2
Namespace:     default
Node:          gke-test-default-pool-239f5d02-x1kf/10.128.0.27
Start Time:    Tue, 30 Aug 2016 17:58:56 -0700
Labels:        <none>
Annotations:   container.apparmor.security.beta.kubernetes.io/hello=localhost/k8s-apparmor-example-allow-write
Status:        Pending
... 
Events:
  Type     Reason     Age              From               Message
  ----     ------     ----             ----               -------
  Normal   Scheduled  10s              default-scheduler  Successfully assigned default/hello-apparmor to gke-test-default-pool-239f5d02-x1kf
  Normal   Pulled     8s               kubelet            Successfully pulled image "busybox:1.28" in 370.157088ms (370.172701ms including waiting)
  Normal   Pulling    7s (x2 over 9s)  kubelet            Pulling image "busybox:1.28"
  Warning  Failed     7s (x2 over 8s)  kubelet            Error: failed to get container spec opts: failed to generate apparmor spec opts: apparmor profile not found k8s-apparmor-example-allow-write
  Normal   Pulled     7s               kubelet            Successfully pulled image "busybox:1.28" in 90.980331ms (91.005869ms including waiting)

事件提供带有原因的错误消息，具体措辞取决于运行时。

  Warning  Failed     7s (x2 over 8s)  kubelet            Error: failed to get container spec opts: failed to generate apparmor spec opts: apparmor profile not found 

管理

使用配置文件设置节点

Kubernetes 1.36 未提供将 AppArmor 配置文件加载到节点上的任何内置机制。配置文件可以通过自定义基础设施或工具（如 Kubernetes 安全配置文件操作员 (Security Profiles Operator)）进行加载。

调度程序不了解哪些配置文件加载在哪些节点上，因此必须将完整的配置文件集加载到每个节点上。另一种方法是为节点上的每个配置文件（或配置文件类）添加一个节点标签，并使用 节点选择器 (node selector) 来确保 Pod 在具有所需配置文件的节点上运行。

编写配置文件

正确指定 AppArmor 配置文件可能是一件棘手的事情。幸运的是，有一些工具可以提供帮助。

• aa-genprof 和 aa-logprof 通过监控应用程序的活动和日志并准入其采取的行动来生成配置文件规则。AppArmor 文档 提供了进一步的说明。
• bane 是一个用于 Docker 的 AppArmor 配置文件生成器，它使用简化的配置文件语言。

要调试 AppArmor 的问题，您可以检查系统日志以查看具体被拒绝的内容。AppArmor 会将详细消息记录到 dmesg，错误通常可以在系统日志中或通过 journalctl 找到。有关更多信息，请参阅 AppArmor 故障。

指定 AppArmor 约束

安全上下文中的 AppArmor 配置文件

您可以在容器的 securityContext 或 Pod 的 securityContext 上指定 appArmorProfile。如果配置文件是在 Pod 级别设置的，它将被用作 Pod 中所有容器（包括 init 容器、sidecar 容器和临时容器）的默认配置文件。如果同时设置了 Pod 和容器的 AppArmor 配置文件，将使用容器的配置文件。

AppArmor 配置文件有两个字段：

type （必需） - 指示将应用哪种 AppArmor 配置文件。有效选项为：

Localhost

预加载在节点上的配置文件（通过 localhostProfile 指定）。

RuntimeDefault

容器运行时的默认配置文件。

Unconfined

不进行 AppArmor 强制执行。

localhostProfile - 加载在节点上的应使用的配置文件的名称。该配置文件必须预先配置在节点上才能生效。当且仅当 type 为 Localhost 时，必须提供此选项。

接下来

其他资源

• AppArmor 配置文件语言快速指南
• AppArmor 核心策略参考