Kubernetes v1.4
betaApparmor 是一个 Linux 内核安全模块,它补充了标准的基于 Linux 用户和组的安全模块将程序限制为有限资源集的权限。AppArmor 可以配置为任何应用程序减少潜在的攻击面,并且提供更加深入的防御。AppArmor 是通过配置文件进行配置的,这些配置文件被调整为报名单,列出了特定程序或者容器所需要的访问权限,如 Linux 功能、网络访问、文件权限等。每个配置文件都可以在*强制*模式(阻止访问不允许的资源)或*投诉*模式(仅报告冲突)下运行。
务必:
Kubernetes 版本至少是 v1.4 – AppArmor 在 Kubernetes v1.4 版本中才添加了对 AppArmor 的支持。早于 v1.4 版本的 Kubernetes 组件不知道新的 AppArmor 注释,并且将会 默认忽略 提供的任何 AppArmor 设置。为了确保您的 Pods 能够得到预期的保护,必须验证节点的 Kubelet 版本:
kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {@.status.nodeInfo.kubeletVersion}\n{end}'
gke-test-default-pool-239f5d02-gyn2: v1.4.0
gke-test-default-pool-239f5d02-x1kf: v1.4.0
gke-test-default-pool-239f5d02-xwux: v1.4.0
AppArmor 内核模块已启用 – 要使 Linux 内核强制执行 AppArmor 配置文件,必须安装并且启动 AppArmor 内核模块。默认情况下,有几个发行版支持该模块,如 Ubuntu 和 SUSE,还有许多发行版提供可选支持。要检查模块是否已启用,请检查
/sys/module/apparmor/parameters/enabled
文件:
cat /sys/module/apparmor/parameters/enabled
Y
如果 Kubelet 包含 AppArmor 支持(>=v1.4),如果内核模块未启用,它将拒绝运行带有 AppArmor 选项的 Pod。
注意: Ubuntu 携带了许多没有合并到上游 Linux 内核中的 AppArmor 补丁,包括添加附加钩子和特性的补丁。Kubernetes 只在上游版本中测试过,不承诺支持其他特性。
Docker 作为容器运行环境 – 目前,支持 Kubernetes 运行的容器中只有 Docker 也支持 AppArmor。随着更多的运行时添加 AppArmor 的支持,可选项将会增多。您可以使用以下命令验证节点是否正在运行 Docker:
kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {@.status.nodeInfo.containerRuntimeVersion}\n{end}'
gke-test-default-pool-239f5d02-gyn2: docker://1.11.2
gke-test-default-pool-239f5d02-x1kf: docker://1.11.2
gke-test-default-pool-239f5d02-xwux: docker://1.11.2
如果 Kubelet 包含 AppArmor 支持(>=v1.4),如果运行环境不是 Docker,它将拒绝运行带有 AppArmor 选项的 Pod。
配置文件已加载 – 通过指定每个容器都应使用 AppArmor 配置文件,AppArmor 应用于 Pod。如果指定的任何配置文件尚未加载到内核, Kubelet (>=v1.4) 将拒绝 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)
有关在节点上加载配置文件的详细信息,请参见使用配置文件设置节点。
只要 Kubelet 版本包含 AppArmor 支持(>=v1.4),如果不满足任何先决条件,Kubelet 将拒绝带有 AppArmor 选项的 Pod。您还可以通过检查节点就绪状况消息来验证节点上的 AppArmor 支持(尽管这可能会在以后的版本中删除):
kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {.status.conditions[?(@.reason=="KubeletReady")].message}\n{end}'
gke-test-default-pool-239f5d02-gyn2: kubelet is posting ready status. AppArmor enabled
gke-test-default-pool-239f5d02-x1kf: kubelet is posting ready status. AppArmor enabled
gke-test-default-pool-239f5d02-xwux: kubelet is posting ready status. AppArmor enabled
注意:AppArmor 目前处于测试阶段,因此选项被指定为注释。一旦 AppArmor 被授予支持通用,注释将替换为首要的字段(更多详情参见升级到 GA 的途径)。
AppArmor 配置文件被指定为 *per-container*。要指定要用其运行 Pod 容器的 AppArmor 配置文件,请向 Pod 的元数据添加注释:
container.apparmor.security.beta.kubernetes.io/<container_name>: <profile_ref>
<container_name>
的名称是容器的简称,用以描述简介,并且简称为 <profile_ref>
。<profile_ref>
可以作为其中之一:
runtime/default
应用运行时的默认配置localhost/<profile_name>
应用在名为 <profile_name>
的主机上加载的配置文件unconfined
表示不加载配置文件有关注释和配置文件名称格式的详细信息,请参阅API 参考。
Kubernetes AppArmor 强制首先通过检查所有先决条件都已满足,然后将配置文件选择转发到容器运行时进行强制。如果未满足先决条件, Pod 将被拒绝,并且不会运行。
要验证是否应用了配置文件,可以查找容器创建事件中列出的 AppArmor 安全选项:
kubectl get events | grep Created
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,直接验证容器的根进程是否以正确的配置文件运行:
kubectl exec <pod_name> cat /proc/1/attr/current
k8s-apparmor-example-deny-write (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 来安装概要文件,但是在使用配置文件设置节点中讨论了其他方法。
NODES=(
# The SSH-accessible domain names of your nodes
gke-test-default-pool-239f5d02-gyn2.us-central1-a.my-k8s
gke-test-default-pool-239f5d02-x1kf.us-central1-a.my-k8s
gke-test-default-pool-239f5d02-xwux.us-central1-a.my-k8s)
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
接下来,我们将运行一个带有拒绝写入配置文件的简单 “Hello AppArmor” pod:
pods/security/hello-apparmor.yaml
|
---|
|
kubectl create -f ./hello-apparmor.yaml
如果我们查看 pod 事件,我们可以看到 pod 容器是用 AppArmor 配置文件 “k8s-apparmor-example-deny-write” 所创建的:
kubectl get events | grep hello-apparmor
14s 14s 1 hello-apparmor Pod Normal Scheduled {default-scheduler } Successfully assigned hello-apparmor to gke-test-default-pool-239f5d02-gyn2
14s 14s 1 hello-apparmor Pod spec.containers{hello} Normal Pulling {kubelet gke-test-default-pool-239f5d02-gyn2} pulling image "busybox"
13s 13s 1 hello-apparmor Pod spec.containers{hello} Normal Pulled {kubelet gke-test-default-pool-239f5d02-gyn2} Successfully pulled image "busybox"
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]
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 来验证容器是否实际使用该配置文件运行:
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
annotations:
container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-allow-write
spec:
containers:
- name: hello
image: busybox
command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
EOF
pod/hello-apparmor-2 created
kubectl describe pod hello-apparmor-2
Name: hello-apparmor-2
Namespace: default
Node: gke-test-default-pool-239f5d02-x1kf/
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
Reason: AppArmor
Message: Pod Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" is not loaded
IP:
Controllers: <none>
Containers:
hello:
Container ID:
Image: busybox
Image ID:
Port:
Command:
sh
-c
echo 'Hello AppArmor!' && sleep 1h
State: Waiting
Reason: Blocked
Ready: False
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-dnz7v (ro)
Conditions:
Type Status
Initialized True
Ready False
PodScheduled True
Volumes:
default-token-dnz7v:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-dnz7v
Optional: false
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: <none>
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
23s 23s 1 {default-scheduler } Normal Scheduled Successfully assigned hello-apparmor-2 to e2e-test-stclair-node-pool-t1f5
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 在具有所需配置文件的节点上运行。
如果启用了 PodSecurityPolicy 扩展,则可以应用群集范围的 AppArmor 限制。要启用 PodSecurityPolicy,必须在“apiserver”上设置以下标志:
--enable-admission-plugins=PodSecurityPolicy[,others...]
AppArmor 选项可以指定为 PodSecurityPolicy 上的注释:
apparmor.security.beta.kubernetes.io/defaultProfileName: <profile_ref>
apparmor.security.beta.kubernetes.io/allowedProfileNames: <profile_ref>[,others...]
默认配置文件名选项指定默认情况下在未指定任何配置文件时应用于容器的配置文件。节点允许配置文件名选项指定允许 Pod 容器运行时的配置文件列表。配置文件的指定格式与容器上的相同。完整规范见API 参考。
如果您不希望 AppArmor 在集群上可用,可以通过命令行标志禁用它:
--feature-gates=AppArmor=false
禁用时,任何包含 AppArmor 配置文件的 Pod 都将因 “Forbidden” 错误而导致验证失败。注意,默认情况下,docker 总是在非特权 pods 上启用 “docker-default” 配置文件(如果 AppArmor 内核模块已启用),并且即使功能门已禁用,也将继续启用该配置文件。当 AppArmor 应用于通用(GA)时,禁用 Apparmor 的选项将被删除。
不需要对 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 运行应用程序以生成配置文件,但是没有什么可以阻止在运行 Pod 的 Kubernetes 节点上运行工具。
想要调试 AppArmor 的问题,您可以检查系统日志,查看具体拒绝了什么。AppArmor 将详细消息记录到 dmesg
,错误通常可以在系统日志中或通过 journalctl
找到。更多详细信息见AppArmor 失败。
指定容器将使用的配置文件:
container.apparmor.security.beta.kubernetes.io/<container_name>
中的 <container_name>
匹配 Pod 中的容器名称。
可以为 Pod 中的每个容器指定单独的配置文件。runtime/default
: 指默认运行时配置文件。Docker default
配置文件,特权容器的配置文件为未定义(无配置文件)。localhost/<profile_name>
: 指按名称加载到节点(localhost)上的配置文件。unconfined
: 这有效地禁用了容器上的 AppArmor 。任何其他配置文件引用格式无效。
指定在未提供容器时应用于容器的默认配置文件:
apparmor.security.beta.kubernetes.io/defaultProfileName
上面描述的指定配置文件, Pod 容器列表的配置文件引用允许指定:
apparmor.security.beta.kubernetes.io/allowedProfileNames
其他资源
此页是否对您有帮助?
感谢反馈。如果您有一个关于如何使用 Kubernetes 的特定的、需要答案的问题,可以访问 Stack Overflow. 在 GitHub 仓库上登记新的问题 报告问题 或者 提出改进建议.