AppArmor

    Apparmor 是一个 Linux 内核安全模块，它补充了标准的基于 Linux 用户和组的安全模块将程序限制为有限资源集的权限。AppArmor 可以配置为任何应用程序减少潜在的攻击面，并且提供更加深入的防御。AppArmor 是通过配置文件进行配置的，这些配置文件被调整为报名单，列出了特定程序或者容器所需要的访问权限，如 Linux 功能、网络访问、文件权限等。每个配置文件都可以在强制模式(阻止访问不允许的资源)或投诉模式(仅报告冲突)下运行。

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

    准备开始

    务必：

    1. Kubernetes 版本至少是 v1.4 — AppArmor 在 Kubernetes v1.4 版本中才添加了对 AppArmor 的支持。早于 v1.4 版本的 Kubernetes 组件不知道新的 AppArmor 注释，并且将会 默认忽略 提供的任何 AppArmor 设置。为了确保您的 Pods 能够得到预期的保护，必须验证节点的 Kubelet 版本：
    1. gke-test-default-pool-239f5d02-gyn2: v1.4.0
    2. gke-test-default-pool-239f5d02-x1kf: v1.4.0
    3. gke-test-default-pool-239f5d02-xwux: v1.4.0
    1. AppArmor 内核模块已启用 — 要使 Linux 内核强制执行 AppArmor 配置文件，必须安装并且启动 AppArmor 内核模块。默认情况下，有几个发行版支持该模块，如 Ubuntu 和 SUSE，还有许多发行版提供可选支持。要检查模块是否已启用，请检查 /sys/module/apparmor/parameters/enabled 文件：
    1.  cat /sys/module/apparmor/parameters/enabled
    2.  Y

    如果 Kubelet 包含 AppArmor 支持(>=v1.4)，如果内核模块未启用，它将拒绝运行带有 AppArmor 选项的 Pod。

    1. Docker 作为容器运行环境 — 目前，支持 Kubernetes 运行的容器中只有 Docker 也支持 AppArmor。随着更多的运行时添加 AppArmor 的支持，可选项将会增多。您可以使用以下命令验证节点是否正在运行 Docker:

      1. kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {@.status.nodeInfo.containerRuntimeVersion}\n{end}'
      1. gke-test-default-pool-239f5d02-gyn2: docker://1.11.2
      2. gke-test-default-pool-239f5d02-x1kf: docker://1.11.2
      3. gke-test-default-pool-239f5d02-xwux: docker://1.11.2

      如果 Kubelet 包含 AppArmor 支持(>=v1.4)，如果运行环境不是 Docker，它将拒绝运行带有 AppArmor 选项的 Pod。

    2. 配置文件已加载 — 通过指定每个容器都应使用 AppArmor 配置文件，AppArmor 应用于 Pod。如果指定的任何配置文件尚未加载到内核， Kubelet (>=v1.4) 将拒绝 Pod。通过检查 /sys/kernel/security/apparmor/profiles 文件，可以查看节点加载了哪些配置文件。例如:

      1. ssh gke-test-default-pool-239f5d02-gyn2 "sudo cat /sys/kernel/security/apparmor/profiles | sort"
      1. apparmor-test-deny-write (enforce)
      2. apparmor-test-audit-write (enforce)
      3. docker-default (enforce)
      4. k8s-nginx (enforce)

      有关在节点上加载配置文件的详细信息，请参见。

    只要 Kubelet 版本包含 AppArmor 支持(>=v1.4)，如果不满足任何先决条件，Kubelet 将拒绝带有 AppArmor 选项的 Pod。您还可以通过检查节点就绪状况消息来验证节点上的 AppArmor 支持(尽管这可能会在以后的版本中删除)：

    1. kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {.status.conditions[?(@.reason=="KubeletReady")].message}\n{end}'
    1. gke-test-default-pool-239f5d02-gyn2: kubelet is posting ready status. AppArmor enabled
    2. gke-test-default-pool-239f5d02-x1kf: kubelet is posting ready status. AppArmor enabled
    3. gke-test-default-pool-239f5d02-xwux: kubelet is posting ready status. AppArmor enabled

    说明：

    AppArmor 目前处于测试阶段，因此选项被指定为注释。一旦 AppArmor 被授予支持通用，注释将替换为首要的字段(更多详情参见升级到 GA 的途径)。

    AppArmor 配置文件被指定为 per-container。要指定要用其运行 Pod 容器的 AppArmor 配置文件，请向 Pod 的元数据添加注释：

    1. container.apparmor.security.beta.kubernetes.io/<container_name>: <profile_ref>

    <container_name> 的名称是容器的简称，用以描述简介，并且简称为 <profile_ref> 。<profile_ref> 可以作为其中之一：

    • runtime/default 应用运行时的默认配置
    • localhost/<profile_name> 应用在名为 <profile_name> 的主机上加载的配置文件
    • unconfined 表示不加载配置文件

    有关注释和配置文件名称格式的详细信息，请参阅。

    要验证是否应用了配置文件，可以查找容器创建事件中列出的 AppArmor 安全选项：

    1. 22s        22s         1         hello-apparmor     Pod       spec.containers{hello}   Normal    Created     {kubelet e2e-test-stclair-node-pool-31nt}   Created container with docker id 269a53b202d3; Security:[seccomp=unconfined apparmor=k8s-apparmor-example-deny-write]

    您还可以通过检查容器的 proc attr，直接验证容器的根进程是否以正确的配置文件运行：

    1. kubectl exec <pod_name> cat /proc/1/attr/current
    1. k8s-apparmor-example-deny-write (enforce)

    举例

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

    首先，我们需要将要使用的配置文件加载到节点上。我们将使用的配置文件仅拒绝所有文件写入：

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

    由于我们不知道 Pod 将被安排在那里，我们需要在所有节点上加载配置文件。在本例中，我们将只使用 SSH 来安装概要文件，但是在中讨论了其他方法。

    1. NODES=(
    2.     # The SSH-accessible domain names of your nodes
    3.     gke-test-default-pool-239f5d02-gyn2.us-central1-a.my-k8s
    4.     gke-test-default-pool-239f5d02-xwux.us-central1-a.my-k8s)
    5. for NODE in ${NODES[*]}; do ssh $NODE 'sudo apparmor_parser -q <<EOF
    6. #include <tunables/global>
    8. profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
    9.   #include <abstractions/base>
    11.   file,
    13.   # Deny all file writes.
    15. }
    16. EOF'
    17. done

    接下来，我们将运行一个带有拒绝写入配置文件的简单 “Hello AppArmor” pod：

    pods/security/hello-apparmor.yaml 

    1. apiVersion: v1
    2. kind: Pod
    3. metadata:
    4.   name: hello-apparmor
    5.   annotations:
    6.     # Tell Kubernetes to apply the AppArmor profile "k8s-apparmor-example-deny-write".
    7.     # Note that this is ignored if the Kubernetes node is not running version 1.4 or greater.
    8.     container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-deny-write
    9. spec:
    10.   containers:
    11.   - name: hello
    12.     image: busybox
    13.     command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
    1. kubectl create -f ./hello-apparmor.yaml

    如果我们查看 pod 事件，我们可以看到 pod 容器是用 AppArmor 配置文件 “k8s-apparmor-example-deny-write” 所创建的：

    1. kubectl get events | grep hello-apparmor
    1. 14s        14s         1         hello-apparmor   Pod                                Normal    Scheduled   {default-scheduler }                           Successfully assigned hello-apparmor to gke-test-default-pool-239f5d02-gyn2
    2. 14s        14s         1         hello-apparmor   Pod       spec.containers{hello}   Normal    Pulling     {kubelet gke-test-default-pool-239f5d02-gyn2}   pulling image "busybox"
    3. 13s        13s         1         hello-apparmor   Pod       spec.containers{hello}   Normal    Pulled      {kubelet gke-test-default-pool-239f5d02-gyn2}   Successfully pulled image "busybox"
    4. 13s        13s         1         hello-apparmor   Pod       spec.containers{hello}   Normal    Created     {kubelet gke-test-default-pool-239f5d02-gyn2}   Created container with docker id 06b6cd1c0989; Security:[seccomp=unconfined apparmor=k8s-apparmor-example-deny-write]
    5. 13s        13s         1         hello-apparmor   Pod       spec.containers{hello}   Normal    Started     {kubelet gke-test-default-pool-239f5d02-gyn2}   Started container with docker id 06b6cd1c0989

    我们可以通过检查该配置文件的 proc attr 来验证容器是否实际使用该配置文件运行：

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

    最后，我们可以看到如果试图通过写入文件来违反配置文件，会发生什么情况：

    1. kubectl exec hello-apparmor touch /tmp/test
    1. touch: /tmp/test: Permission denied
    2. error: error executing remote command: command terminated with non-zero exit code: Error executing in Docker Container: 1

    最后，让我们看看如果我们试图指定一个尚未加载的配置文件会发生什么：

    1. kubectl create -f /dev/stdin <<EOF
    1. apiVersion: v1
    2. kind: Pod
    3. metadata:
    4.   name: hello-apparmor-2
    5.   annotations:
    6.     container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-allow-write
    7. spec:
    8.   containers:
    9.   - name: hello
    10.     image: busybox
    11.     command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
    12. EOF
    13. pod/hello-apparmor-2 created
    1. kubectl describe pod hello-apparmor-2
    1. Name:          hello-apparmor-2
    2. Namespace:     default
    3. Node:          gke-test-default-pool-239f5d02-x1kf/
    4. Start Time:    Tue, 30 Aug 2016 17:58:56 -0700
    5. Labels:        <none>
    6. Annotations:   container.apparmor.security.beta.kubernetes.io/hello=localhost/k8s-apparmor-example-allow-write
    7. Status:        Pending
    8. Message:       Pod Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" is not loaded
    10. Controllers:   <none>
    11. Containers:
    12.   hello:
    13.     Container ID:
    14.     Image:     busybox
    15.     Image ID:
    16.     Port:
    17.     Command:
    18.       sh
    19.       -c
    20.       echo 'Hello AppArmor!' && sleep 1h
    21.     State:              Waiting
    22.       Reason:           Blocked
    23.     Ready:              False
    24.     Restart Count:      0
    25.     Environment:        <none>
    26.     Mounts:
    27.       /var/run/secrets/kubernetes.io/serviceaccount from default-token-dnz7v (ro)
    28. Conditions:
    29.   Type          Status
    30.   Initialized   True
    31.   Ready         False
    32.   PodScheduled  True
    33. Volumes:
    34.   default-token-dnz7v:
    35.     Type:    Secret (a volume populated by a Secret)
    36.     SecretName:    default-token-dnz7v
    37.     Optional:   false
    38. QoS Class:      BestEffort
    39. Node-Selectors: <none>
    40. Tolerations:    <none>
    41. Events:
    42.   FirstSeen    LastSeen    Count    From                        SubobjectPath    Type        Reason        Message
    43.   ---------    --------    -----    ----                        -------------    --------    ------        -------
    44.   23s          23s         1        {default-scheduler }                         Normal      Scheduled     Successfully assigned hello-apparmor-2 to e2e-test-stclair-node-pool-t1f5
    45.   23s          23s         1        {kubelet e2e-test-stclair-node-pool-t1f5}             Warning        AppArmor    Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" is not loaded

    注意 pod 呈现失败状态，并且显示一条有用的错误信息：Pod Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" 未加载。还用相同的消息记录了一个事件。

    Kubernetes 目前不提供任何本地机制来将 AppArmor 配置文件加载到节点上。有很多方法可以设置配置文件，例如：

    • 通过在每个节点上运行 Pod 的确保加载了正确的配置文件。可以找到一个示例实现这里。
    • 在节点初始化时，使用节点初始化脚本(例如 Salt 、Ansible 等)或镜像。
    • 通过将配置文件复制到每个节点并通过 SSH 加载它们，如。

    调度程序不知道哪些配置文件加载到哪个节点上，因此必须将全套配置文件加载到每个节点上。另一种方法是为节点上的每个配置文件(或配置文件类)添加节点标签，并使用[节点选择器](/zh/docs/concepts/configuration/assign pod node/)确保 Pod 在具有所需配置文件的节点上运行。

    使用 PodSecurityPolicy 限制配置文件

    1. --enable-admission-plugins=PodSecurityPolicy[,others...]

    AppArmor 选项可以指定为 PodSecurityPolicy 上的注释：

    1. apparmor.security.beta.kubernetes.io/defaultProfileName: <profile_ref>
    2. apparmor.security.beta.kubernetes.io/allowedProfileNames: <profile_ref>[,others...]

    默认配置文件名选项指定默认情况下在未指定任何配置文件时应用于容器的配置文件。节点允许配置文件名选项指定允许 Pod 容器运行时的配置文件列表。配置文件的指定格式与容器上的相同。完整规范见。

    如果您不希望 AppArmor 在集群上可用，可以通过命令行标志禁用它：

    禁用时，任何包含 AppArmor 配置文件的 Pod 都将因 “Forbidden” 错误而导致验证失败。注意，默认情况下，docker 总是在非特权 pods 上启用 “docker-default” 配置文件(如果 AppArmor 内核模块已启用)，并且即使功能门已禁用，也将继续启用该配置文件。当 AppArmor 应用于通用(GA)时，禁用 Apparmor 的选项将被删除。

    使用 AppArmor 升级到 Kubernetes v1.4

    不需要对 AppArmor 执行任何操作即可将集群升级到 v1.4。但是，如果任何现有的 pods 有一个 AppArmor 注释，它们将不会通过验证(或 PodSecurityPolicy 认证)。如果节点上加载了许可配置文件，恶意用户可以预先应用许可配置文件，将 pod 权限提升到 docker-default 权限之上。如果存在这个问题，建议清除包含 apparmor.security.beta.kubernetes.io 注释的任何 pods 的集群。

    当 Apparmor 准备升级到通用(GA)时，当前指定的选项通过注释将转换为字段。通过转换支持所有升级和降级路径是非常微妙的，并将在转换发生时详细解释。我们将承诺在至少两个版本中同时支持字段和注释，并在之后的至少两个版本中显式拒绝注释。

    编写配置文件

    获得正确指定的 AppArmor 配置文件可能是一件棘手的事情。幸运的是，有一些工具可以帮助您做到这一点：

    • aa-genprof and aa-logprof 通过监视应用程序的活动和日志并承认它所采取的操作来生成配置文件规则。更多说明由AppArmor 文档提供。
    • 是一个用于 Docker的 AppArmor 档案生成器，它使用简化的档案语言。

    建议在开发工作站上通过 Docker 运行应用程序以生成配置文件，但是没有什么可以阻止在运行 Pod 的 Kubernetes 节点上运行工具。

    想要调试 AppArmor 的问题，您可以检查系统日志，查看具体拒绝了什么。AppArmor 将详细消息记录到 dmesg ，错误通常可以在系统日志中或通过 journalctl 找到。更多详细信息见AppArmor 失败。

    Pod 注释

    指定容器将使用的配置文件：

    • key: container.apparmor.security.beta.kubernetes.io/<container_name> 中的 <container_name> 匹配 Pod 中的容器名称。 可以为 Pod 中的每个容器指定单独的配置文件。
    • value: 配置文件参考，如下所述
    • runtime/default: 指默认运行时配置文件。
      • 等同于不指定配置文件(没有 PodSecurityPolicy 默认值)，除非它仍然需要启用 AppArmor。
      • 对于 Docker，这将解析为非特权容器的Docker default配置文件，特权容器的配置文件为未定义(无配置文件)。
    • localhost/<profile_name>: 指按名称加载到节点(localhost)上的配置文件。
      • 可能的配置文件名在 。
    • unconfined: 这有效地禁用了容器上的 AppArmor 。

    任何其他配置文件引用格式无效。

    PodSecurityPolicy 注解

    指定在未提供容器时应用于容器的默认配置文件：

    • key: apparmor.security.beta.kubernetes.io/defaultProfileName
    • value: 如上述文件参考所述

    上面描述的指定配置文件， Pod 容器列表的配置文件引用允许指定：

    • key:
    • value: 配置文件引用的逗号分隔列表(如上所述)
      • 尽管转义逗号是配置文件名中的合法字符，但此处不能显式允许。

    接下来

    其他资源