如何解决尝试执行从初始化容器复制的文件时,Kubernetes 卷 emptyDir 权限被拒绝
我在使用 emptydir 时遇到问题:
将任何文件从 init 容器复制到 emptydir 使其在主容器中无法执行 发生在我的 4 个节点中的 3 个节点上,单个主节点上没有问题 成功运行它的主节点在某些文件上显示不同的 selinux 标签 集群信息:
- RHEL 7、SELinux 许可、虚拟机位于内部数据中心
- kubernetes 1.20,由 kubeadm 部署
- 4 节点集群(1 个是主节点)
Ex Pod Spec(在 3 个节点上失败,在单个主节点上成功):
apiVersion: v1
kind: Pod
Metadata:
name: emptydir-test
namespace: default
spec:
initContainers:
- command:
- "bash"
- -c
- "cp $(which ls) /empty-dir/empty-dir-ls ; cp $(which ls) /mem-dir/mem-ls"
image: ubuntu
imagePullPolicy: IfNotPresent
name: init
volumeMounts:
- mountPath: /empty-dir
name: empty-dir
- mountPath: /mem-dir
name: mem-dir
containers:
- securityContext:
privileged: true
command:
- "bash"
- -c
- "id ; ls -alhZ /mem-dir; /mem-dir/mem-ls -alhZ /root ; ls -alhZ /empty-dir ; /empty-dir/empty-dir-ls -alhZ /root"
image: ubuntu
imagePullPolicy: IfNotPresent
name: emptydir-test
volumeMounts:
- mountPath: /empty-dir
name: empty-dir
- mountPath: /mem-dir
name: mem-dir
volumes:
- emptyDir:
medium: Memory
name: mem-dir
- emptyDir: {}
name: empty-dir
显示失败的日志:
uid=0(root) gid=0(root) groups=0(root)
total 140K
drwxrwxrwt. 2 root root system_u:object_r:tmpfs_t:s0 60 Apr 8 00:32 .
drwxr-xr-x. 1 root root system_u:object_r:unlabeled_t:s0 49 Apr 8 00:32 ..
-rwxr-xr-x. 1 root root system_u:object_r:container_file_t:s0 139K Apr 8 00:32 mem-ls
total 8.0K
drwx------. 2 root root system_u:object_r:unlabeled_t:s0 37 Apr 1 01:26 .
drwxr-xr-x. 1 root root system_u:object_r:unlabeled_t:s0 49 Apr 8 00:32 ..
-rw-r--r--. 1 root root system_u:object_r:unlabeled_t:s0 3.1K Dec 5 2019 .bashrc
-rw-r--r--. 1 root root system_u:object_r:unlabeled_t:s0 161 Dec 5 2019 .profile
total 140K
drwxrwxrwx. 2 root root system_u:object_r:container_file_t:s0 25 Apr 8 00:32 .
drwxr-xr-x. 1 root root system_u:object_r:unlabeled_t:s0 49 Apr 8 00:32 ..
-rwxr-xr-x. 1 root root system_u:object_r:container_file_t:s0 139K Apr 8 00:32 empty-dir-ls
bash: /empty-dir/empty-dir-ls: Permission denied
显示成功的日志:
uid=0(root) gid=0(root) groups=0(root)
total 140K
drwxrwxrwt. 2 root root system_u:object_r:tmpfs_t:s0 60 Apr 8 00:34 .
drwxr-xr-x. 1 root root system_u:object_r:container_share_t:s0 49 Apr 8 00:34 ..
-rwxr-xr-x. 1 root root system_u:object_r:container_file_t:s0 139K Apr 8 00:34 mem-ls
total 8.0K
drwx------. 2 root root system_u:object_r:container_share_t:s0 37 Apr 1 01:26 .
drwxr-xr-x. 1 root root system_u:object_r:container_share_t:s0 49 Apr 8 00:34 ..
-rw-r--r--. 1 root root system_u:object_r:container_share_t:s0 3.1K Dec 5 2019 .bashrc
-rw-r--r--. 1 root root system_u:object_r:container_share_t:s0 161 Dec 5 2019 .profile
total 140K
drwxrwxrwx. 2 root root system_u:object_r:container_file_t:s0 25 Apr 8 00:34 .
drwxr-xr-x. 1 root root system_u:object_r:container_share_t:s0 49 Apr 8 00:34 ..
-rwxr-xr-x. 1 root root system_u:object_r:container_file_t:s0 139K Apr 8 00:34 empty-dir-ls
total 8.0K
drwx------. 2 root root system_u:object_r:container_share_t:s0 37 Apr 1 01:26 .
drwxr-xr-x. 1 root root system_u:object_r:container_share_t:s0 49 Apr 8 00:34 ..
-rw-r--r--. 1 root root system_u:object_r:container_share_t:s0 3.1K Dec 5 2019 .bashrc
-rw-r--r--. 1 root root system_u:object_r:container_share_t:s0 161 Dec 5 2019 .profile
我注意到失败的 (system_u:object_r:unlabeled_t:s0) 和成功的 (system_u:object_r:container_share_t:s0) 容器日志之间根目录的 selinux 标签不同。但是已经确认所有节点都处于许可模式,所以不确定 selinux 是否可以/仍然以某种方式影响它。
非常感谢任何方向或建议!
解决方法
经过几天的谷歌搜索和故障排除后,我解决了这个问题 - 问题是: /var 在 fstab 中使用 noexec 挂载。
我的单个主节点在其他节点之前配置。在此期间,公司政策必须在 /var 上采用默认的 noexec 挂载选项以提高安全性。您可以从 fstab 中的 /var 条目中删除 noexec(经 IT 批准),或者为 /var/lib/kubelet 创建一个新的挂载并在没有 noexec 的情况下挂载它。无论哪种方式,您都需要重新启动。
对于遇到此问题的任何人,我还发现了其他几个潜在原因:
- ACL - 如果您在任何地方使用 ACL,请确保您没有 /var/lib/kubelet 的条目:
getfacl -e /var/lib/kubelet/pods
- SELinux - 如果您在强制模式下运行,请通过 -Z 选项和 ls 检查您的 selinux 标签。这些标签看起来不错,不确定是否有一系列可接受的标签,但可能值得检查。
ls -alhZ /var/lib/kubelet/pods/
drwxr-xr-x. root root system_u:object_r:container_file_t:s0 .
drwxr-xr-x. root root system_u:object_r:container_file_t:s0 ..
drwxr-x---. root root system_u:object_r:container_file_t:s0 [poduid]
drwxr-x---. root root system_u:object_r:container_file_t:s0 [poduid]
-
Pod 安全策略:如果您仍然拥有这些,它们无论如何都会被弃用。
https://kubernetes.io/docs/concepts/policy/pod-security-policy/ -
Pod 安全上下文:确保这些配置正确
https://kubernetes.io/docs/tasks/configure-pod-container/security-context/ -
Noexec 或 /var/lib/kubelet/pods 上的其他挂载选项 - 这是我的问题。假设您的系统在启动时使用 fstab 挂载,请从包含 /var/lib/kubelet/pods 的挂载点删除 noexec。或者,在 /var/lib/kubelet/pods 创建一个新的挂载点,并从其 fstab 条目中省略 noexec。
# edit emptydir-test.yaml to specify node as needed,then
kubectl apply -f emptydir-test.yaml
kubectl get po -o wide # confirm it runs/fails on node
# ssh to node
ls -alhZ /var/lib/kubelet/pods/$(kubectl get po emptydir-test -o jsonpath='{.metadata.uid}')/volumes/kubernetes.io~empty-dir/empty-dir
# drwxrwxrwx. root root system_u:object_r:container_file_t:s0 .
# drwxr-xr-x. root root system_u:object_r:container_file_t:s0 ..
# -rwxr-xr-x. root root system_u:object_r:container_file_t:s0 empty-dir-ls
sudo /var/lib/kubelet/pods/$(kubectl get po emptydir-test -o jsonpath='{.metadata.uid}')/volumes/kubernetes.io~empty-dir/empty-dir/empty-dir-ls -alh /
# output should either be the result of ls -alh on / or a permission denied error
# if it's a permission denied error,you may have a noexec mount options issue
# check current mounts for noexec option:
sudo findmnt -l | grep "/var" | grep noexec
# look for /var/lib or a mount along /var/lib/kubelet/pods with noexec option
# check fstab:
grep "/var" /etc/fstab
# /dev/mapper/vg01-lv_var /var xfs nodev,noexec,nosuid 1 2
# either remove noexec from the mount options or create a new mount point for /var/lib/kubelet and omit noexec
# then reboot to take effect and run the emptydir-test pod on affected nodes
我毫不怀疑还有其他功能通过无法访问来提高安全性,这些正是我在解决问题时发现的。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。