bitnami/kubectl容器创建文件报permission denied的原因及解决方法

• 从shell提示符I have no name!可以直接判断，当前容器进程以非root身份运行：bitnami/kubectl镜像默认遵循最小权限安全规范，默认启动用户为UID 1001的非特权用户，且该UID未被写入容器内/etc/passwd条目，才会出现提示符无法解析用户名的特征。
• 容器内置的根文件系统所有默认目录（含根路径/）所有权归属UID 0的root用户，默认权限位为drwxr-xr-x，仅root用户拥有写入权限，UID 1001的普通用户对这类路径无写权限，执行touch/mkdir等写操作时会直接抛出Permission denied报错。
• 如果集群开启了Pod安全准入（PSA）的restricted策略、或配置了OPA/Gatekeeper等安全规则强制容器非root运行，会进一步禁止容器进程提权到root身份，默认进入容器时无法直接获取写入权限。
• 你提到的ConfigMap挂载绕过方案本质是利用了Kubernetes存储卷挂载时的权限适配逻辑，但ConfigMap本身为配置存储设计，不适合作为通用可写目录使用，存在写入不持久、挂载点更新延迟等问题，不属于标准修复方案。

根据使用场景选择对应方案即可：

临时调试场景 #

不需要修改Pod原有配置，执行exec进入容器时显式指定以root用户身份进入：

kubectl exec -it <目标Pod名称> -c test-c --user root -- /bin/bash

进入后即可正常在容器路径下执行创建文件、目录的操作。

业务正常运行场景 #

禁止直接在容器根文件系统写入业务数据，通过Kubernetes原生存储卷挂载可写目录，所有写入操作统一在挂载路径下执行：

# Pod配置片段示例
containers:
- name: test-c
  image: bitnami/kubectl:latest
  volumeMounts:
  - name: writable-workspace
    mountPath: /work # 业务写入操作统一放在该路径
volumes:
- name: writable-workspace
  emptyDir: {} # 可根据持久化需求替换为PVC、hostPath等卷类型

存储卷挂载后的目录会自动适配容器运行用户的权限，不需要额外提权即可正常写入，符合容器安全最佳实践。

特殊强需求场景 #

如果业务逻辑强制要求在容器根文件系统非挂载路径写入，可在Pod安全上下文显式指定以root用户运行（该方案会降低容器安全等级，生产环境不推荐使用）：

containers:
- name: test-c
  image: bitnami/kubectl:latest
  securityContext:
    runAsUser: 0
    runAsNonRoot: false
    allowPrivilegeEscalation: true

内容的提问来源于stack exchange，提问作者anonymous user