时间戳

首页 > 解决方案 > 尝试执行从初始化容器复制的文件时，Kubernetes 卷 emptyDir 权限被拒绝

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

问题描述

我遇到了 emptydir 的问题：

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

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 是否可以/仍然以某种方式影响它。

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

标签： kubernetes

解决方案

经过几天的谷歌搜索和故障排除，我已经解决了这个问题 - 问题是：/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]

# 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

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

推荐阅读