Docker Compose 的 USER 字段仅控制容器启动 UID/GID，属建议性配置；Kubernetes SecurityContext 是强制运行时防护机制，需通过 kompose 转换+ kustomize 增强实现语义对齐与安全落地。
在 docker-compose.yml 中设置 USER，本身不能直接映射为 Kubernetes 的安全上下文（SecurityContext），因为 Compose 规范不原生支持完整的 Pod 安全策略字段。但通过合理设计和工具链配合，可以实现语义对齐——即让本地开发时的用户隔离行为，在 K8s 生产环境中得到等效、可验证的安全落地。
明确 USER 在 Compose 中的作用与局限
Compose 中的 USER 字段（如 user: "1001:1001" 或 user: "www-data"）仅控制容器进程启动时的 UID/GID，它影响文件访问权限、避免 root 运行，但不触发任何运行时安全策略，也不约束 capabilities、seccomp 或 SELinux。Kubernetes 的 securityContext 则是一套声明式、强制执行的运行时防护机制。
- Compose 的
USER是“建议性”的，镜像内若未显式指定或被 CMD/OVERWRITE 覆盖，可能失效 - K8s 的
runAsUser/runAsGroup是强制性的，由 kubelet 在创建容器前校验并注入 - 二者数值需一致（如都用 1001），否则权限逻辑断裂，比如挂载的 ConfigMap/Secret 文件不可读
用 .env + 构建参数统一 UID/GID 基线
避免硬编码导致环境错位，把用户 ID 提取为可配置项，确保 compose 和镜像构建阶段同步：
- 在
.env中定义：APP_UID=1001、APP_GID=1001 - docker-compose.yml 中引用：
user: "${APP_UID}:${APP_GID}" - Dockerfile 中使用构建参数：
ARG UID=1001 && ARG GID=1001，再创建非 root 用户并设为默认 - 这样生成的镜像天然适配 K8s 的
runAsUser，无需额外 patch 镜像
借助 kompose 转换时自动注入 SecurityContext
Kompose 默认会将 user 字段转换为 Deployment 的 securityContext.runAsUser 和 runAsGroup，但需满足前提：
- 使用
kompose convert -f docker-compose.yml --volumes-host-path确保卷挂载路径兼容 - 若 compose 中用了
user: "www-data"（非数字），kompose 无法解析，必须改用 UID/GID 数值形式 - 转换后手动检查生成的 deployment.yaml，确认
securityContext已出现且值正确 - 补充关键字段：如添加
runAsNonRoot: true、allowPrivilegeEscalation: false，这些需在转换后人工补全或通过 kustomize 注入
生产环境用 Kustomize 补齐缺失的安全控制
Kompose 生成的是基础资源，真正的安全对齐靠后续增强。推荐用 kustomize 管理 K8s 层安全上下文：
- 创建
security/base/securitycontext.yaml，定义通用securityContext模板 - 在
kustomization.yaml中用patchesStrategicMerge将其打到所有 Deployment 上 - 覆盖字段包括：
fsGroup（用于卷权限）、seccompProfile（如 runtime/default）、capabilities.drop（如["ALL"]） - 这样即使 compose 文件没写，K8s 层也始终 enforce 最小权限原则
