容器的安全上下文由HostConfig.SecurityOpt字段固化，仅创建时生效且不可动态修改；该字段存储--security-opt参数值如no-new-privileges、label=type:xxx_t或apparmor=profile-name，但不反映运行时真实SELinux/AppArmor上下文。
查容器的SecurityOpt和HostConfig.SecurityOpt字段
容器的安全上下文主要由启动时传入的 --security-opt 参数决定，这些参数最终会固化在 HostConfig.SecurityOpt 字段中。直接 inspect 容器即可看到原始配置，但要注意：这个字段只在容器创建时生效，运行后不可动态修改，且若未显式设置，该字段可能为空或为 null。
实操建议：
- 用
docker inspect --format='{{.HostConfig.SecurityOpt}}' my-container查看是否设置了no-new-privileges、label=type:xxx_t或apparmor=profile-name等值 - 如果输出是
[]或<no value></no>，说明容器未启用额外安全策略，默认继承宿主机策略 - 注意区分
SecurityOpt和IpcMode/PidMode：后者虽影响隔离性，但不属于 SELinux/AppArmor/NO_NEW_PRIVS 这类安全上下文范畴
提取SELinux或AppArmor标签（label=… 或 apparmor=…）
当容器启用了 SELinux 或 AppArmor，对应策略名会作为 --security-opt 的值写入 HostConfig.SecurityOpt，但不会自动展开成完整上下文字符串。inspect 本身不解析策略内容，只暴露配置项。
常见错误现象：
- 执行
docker inspect --format='{{.HostConfig.SecurityOpt}}' my-container返回[label=type:spc_t]，但误以为这是“当前进程的 SELinux 上下文”——其实这只是启动时指定的类型，实际运行时上下文还受父进程、策略规则、process_context文件等影响 - 用
grep -i selinux或jq '.[].HostConfig.SecurityOpt'模糊匹配容易漏掉apparmor=类型，建议明确匹配前缀
推荐写法：
docker inspect --format='{{range .HostConfig.SecurityOpt}}{{if or (contains . "label=") (contains . "apparmor=")}}{{.}}{{end}}{{end}}' my-container
确认容器是否启用 no-new-privileges
no-new-privileges=true 是最常用也最容易被忽略的安全选项，它禁止容器内进程通过 setuid/setgid 提权。inspect 不会单独提供布尔标志位，必须从 SecurityOpt 数组里手动判断。
使用场景：
- 排查某容器为何无法运行需要
sudo或ping的命令（常因 cap-drop + no-new-privileges 双重限制） - 审计镜像是否满足 CIS Docker Benchmark 第 5.25 条要求
实操建议：
- 不要依赖
docker inspect my-container | grep no-new-privileges—— 若字段值含空格或换行，grep 可能截断 - 用 Go 模板精准匹配：
docker inspect --format='{{.HostConfig.SecurityOpt | contains "no-new-privileges=true"}}' my-container输出true或false - 注意大小写和等号两侧空格：
no-new-privileges = true（带空格）不会被匹配到，说明构建时参数格式不规范
为什么不能从 inspect 获取实时进程安全上下文
docker inspect 输出的是容器创建时的静态快照，不是运行时状态。它不包含 ps -Z 或 cat /proc/1/attr/current 这类动态信息。即使容器已启动，inspect 也不会告诉你当前 init 进程的真实 SELinux 上下文或 AppArmor profile 是否被策略拒绝。
这意味着：
- 若需验证策略是否实际生效，必须进入容器执行
cat /proc/1/attr/current（SELinux）或aa-status --pid 1（AppArmor） -
HostConfig.SecurityOpt存在label=...并不保证容器能成功加载该 label——比如目标 SELinux 类型未安装、或策略未启用 - 某些安全加固方案（如 rootless Docker、gVisor）会绕过传统
SecurityOpt机制，此时 inspect 显示为空，但实际隔离更强
真正关键的不是“有没有配”，而是“配了之后有没有被内核策略接受并落地”。inspect 只能帮你确认第一关。
