尝试执行从初始化容器复制的文件时，Kubernetes 卷 emptyDir 权限被拒绝

Question

我遇到了 emptydir 的问题：

将任何文件从 init 容器复制到 emptydir 会使其在主容器中无法执行 发生在我的 4 个节点中的 3 个上，在单个主节点上没有问题 成功运行它的主节点在某些文件上显示不同的 selinux 标签 集群信息：

• RHEL 7，允许 SELinux，VM 位于内部数据中心
• 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 是否可以/仍然以某种方式影响它。

非常感谢任何方向或建议！

Answer 1

经过几天的谷歌搜索和故障排除，我已经解决了这个问题 - 问题是： /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 - 如果您在强制模式下运行，请通过 ls 的 -Z 选项检查您的 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/

• /var/lib/kubelet/pods 上的 Noexec 或其他挂载选项 - 这是我的问题。假设您的系统在启动时使用 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

我毫不怀疑还有其他通过不可访问性来提高安全性的功能，这些正是我在解决问题时发现的。