容器与镜像安全

• Pod Security Standards 三级定义
• 准入控制（Pod Security Admission / 策略引擎）落地
• 存量集群的迁移路径

Pod Security Standards（PSS）定义了三级安全标准：privileged（宽松，允许特权容器等）、baseline（基线，限制危险特性如 hostPID、特权容器、hostNetwork 等）、restricted（严格，强制非 root、只读根文件系统、禁用 capabilities 提升等）。落地方式：通过 Pod Security Admission（k8s 1.23+ 内置）或策略引擎（Kyverno/Gatekeeper）在准入控制阶段对 Pod 做校验，按 namespace 设置 enforcement 级别（enforce/audit/warn），使不符合级别的 Pod 被拒绝、记录或告警。存量集群迁移：先对存量 Pod 做评估（audit/warn 模式收集违规），分析哪些 namespace 的负载需要升级到更严格级别，通过灰度推进（先 warn 观察、再 enforce），对确实需要特权的基础设施负载（如 DaemonSet、node 组件）单独放行或使用 privileged 级别，逐步把命名空间收敛到 baseline/restricted，避免一次性 enforce 导致存量业务崩溃。

PSS 的价值在于用一个"官方标准"把 Pod 安全要求分级，让团队按"privileged → baseline → restricted"逐级收紧。落地的关键是"先审计后强制"：存量集群不能直接 enforce 最严级别，要先用 warn/audit 模式评估影响，再分 namespace 灰度迁移，防止误伤存量负载。

• SELinux 与 AppArmor 的 MAC 机制
• 容器运行时中的 MAC 配置
• 与 capabilities 机制的互补关系

SELinux 与 AppArmor 都是 Linux 的强制访问控制（MAC）机制，通过为容器进程定义访问策略（文件、进程、网络、capability）来限制容器行为，即使容器内 root 也只能在被允许的范围内操作。SELinux 使用标签（label）与策略（policy）控制（如 svirt_sandbox 类型），容器运行时（如 CRI-O、containerd 的 selinux 选项）为容器设置安全上下文；AppArmor 通过 profile 限制容器进程的访问（如运行时的 apparmor profile）。配置时需在运行时启用 MAC 并加载对应 profile/policy，确保容器被正确的安全上下文包裹。与 capabilities 机制互补：capabilities 是"特权分解"——把 root 的超级权限拆成细粒度能力（如 CAP_NET_ADMIN），容器默认只持有最小能力集；而 MAC 是"对已给定能力的操作做强制约束"——即使容器持有某 capability，SELinux/AppArmor 也限制其能否真正访问某个文件/资源。两者一个管"能做什么类型操作"，一个管"具体能碰哪些资源"，共同构成纵深防御。

三个机制互补：capabilities 管"能力类型"，SELinux/AppArmor 管"资源访问"（MAC）。容器内 root 不等于主机 root，因为 capabilities 限制了特权、MAC 限制了资源访问。配置时需同时启用运行时选项与对应 profile，才能真正发挥 MAC 的隔离效果。

• SLSA 各级别在镜像构建中的要求
• 镜像构建与发布流程的落地要点
• 签名与 provenance 的落实

SLSA 在容器镜像构建与发布流程中的落地要点按级别递进：L1 要求"构建脚本文档化"，即镜像构建过程可复现、可记录——需要把 Dockerfile 与构建过程版本化、记录完整构建参数；L2 要求"受托管构建 + 生成签名 provenance"——镜像必须在受控的托管 CI（如 GitHub Actions、Buildkite、GitLab CI）上构建，并生成带签名的 provenance（描述构建输入、输出、命令），同时镜像本身用 cosign 等签名；L3 要求"构建者与源仓库隔离"——构建者身份与源代码仓库分离，防止源仓库被篡改后影响构建，构建环境与源码的信任边界分离，并保证 provenance 可验证。发布流程上，落地要点包括：在 CI 中生成镜像签名与 SBOM 并随镜像发布（作为 OCI 注解）、固定镜像 digest 与不可变 tag、在部署准入时验签（cosign verify / ImagePolicyWebhook），使"构建可信、签名可验、来源可溯"成为镜像发布的标准动作。

SLSA 在镜像构建中的核心是"可复现构建（L1）→ 托管+签名 provenance（L2）→ 构建者与源隔离（L3）"，落地时把签名、SBOM、不可变 tag 与准入验签固化到 CI/CD 流程，让镜像从"构建"到"部署"全程可验证。绝大多数团队至少应做到 L2。

• User Namespace 的隔离机制
• rootless 容器的安全价值
• 性能与兼容性代价

User Namespace 将容器内的 UID/GID 映射到宿主机的非特权 UID/GID，使容器内 root 在宿主机上只是普通用户，从而让容器内提权到 root 也无法获得宿主机权限，这是 rootless 容器（rootless container）的安全基础。其安全价值在于：容器内 root 与宿主机 root 解耦，即使容器被攻破并获得 root，也无法在宿主机上执行特权操作（如访问宿主机文件、加载模块），显著缩小提权与逃逸风险。代价方面：性能——User Namespace 涉及 ID 映射与系统调用开销，某些场景（如大量文件操作、网络命名空间）有轻微性能损失；兼容性——并非所有镜像/应用都兼容 rootless 运行（如依赖固定 UID、需要特权能力、挂载操作受限的应用），需要调整配置；同时 rootless 场景下对某些能力（如绑定低端口、部分 mount 操作）受限，需要额外配置（如 slirp4netns、userfaultfd 等）。

User Namespace 的核心理念是"把容器 root 变成宿主非特权用户"，从机制上消除"容器 root = 宿主机 root"的提权路径。安全价值大，但代价是性能损失与兼容性限制，落地时需评估镜像与应用的兼容性，并对 rootless 支持不足的负载做折中。

• VEX 的概念与作用
• 与镜像漏洞扫描的结合方式
• 降低告警噪声的机制

VEX（Vulnerability Exploitability eXchange）是一种用于声明"漏洞是否可利用/是否受影响"的标准化元数据（常见格式如 CSAF 的 VEX 文档），它告诉消费者某漏洞在特定产品/版本上是否受影响、是否可利用、是否已修复。VEX 与镜像漏洞扫描结合，可以显著降低告警噪声：扫描工具（如 grype、Trivy）识别出大量 CVE 时，很多漏洞实际上"不可利用"（如某库中的漏洞代码未被调用、已修复但版本未更新、或仅在特定条件下可利用）。通过加载 VEX 信息，扫描器可以对这些漏洞进行"受影响的判定"过滤——对于 VEX 声明"不受影响"或"不可利用"的漏洞，扫描器将其标记为已缓解/降级，从而只告警真正有实际风险的漏洞。这避免了"扫描出大量 CVE 但实则无风险"的告警洪泛，提升告警的准确率与可操作性。VEX 的来源包括供应商声明、自身的安全团队分析，以及自动化规则生成。

漏洞扫描的问题在于"它报的是'版本中存在漏洞'，而非'实际可利用'"。VEX 的价值正是把"存在性"校正为"可利用性"，通过受影响的判定把大量不可利用的告警过滤掉，实现降噪。结合 VEX 的理解，扫描结果从"版本比对"上升为"风险研判"。

• 最小化基础镜像的理念
• 缩小攻击面的机制
• 迁移代价与注意事项

Wolfi、distroless 等最小化基础镜像通过"只保留运行时所需的最小内容"来缩小攻击面：它们不包含 shell、包管理器、编译工具等非必要组件，只含应用运行所需的库与依赖。其安全价值在于：攻击面小——没有 shell/工具可被利用做反弹、提权或横向移动；漏洞面小——组件越少，潜在 CVE 越少；供应链更可控——镜像内容确定、可复现。迁移的代价与注意事项包括：调试困难——没有 shell 难以进容器排查，需依赖日志、健康检查与临时调试工具；改造成本——应用需为非 root、只读根文件系统优化，某些依赖系统工具的应用无法直接运行；构建方式改变——需用多阶段构建把运行产物复制进最小镜像，或使用 Wolfi 的 apko/melange 构建；监控与排障工具需外部化（如通过 sidecar、eBPF 工具）。迁移时应先评估应用对系统工具与 shell 的依赖，再逐步迁移。

最小镜像的理念是"攻击面 = 镜像内容"，删掉 shell 与工具就删掉了攻击者可利用的入口。代价是调试与排障不便，需把排查能力移到外部。迁移前先评估应用依赖，再用多阶段构建/专用工具生成最小镜像，是安全与可维护性的平衡。

• eBPF 运行时检测工具的能力
• 各工具的能力边界与差异
• 选型考量

基于 eBPF 的运行时检测工具通过内核 eBPF 钩子观测系统调用、文件、网络、进程生命周期等事件，实现容器/主机运行时行为检测，无需修改应用或重启。能力边界：Falco——偏规则驱动的告警，基于 syscall 与内核事件匹配规则，能力边界在"检测并告警"，规则丰富、生态成熟，但主要是告警而非阻断；Tracee——偏取证与行为分析，能识别恶意行为并输出详细证据，支持运行时检测与取证；Tetragon——偏策略执行与网络、进程级安全，支持 enforce（阻断）能力，能基于 Cilium 网络策略做内核级防护；Sysdig——综合平台，含运行时检测、漂移检测、取证与合规，能力最全。选型考量：看需求是"告警"还是"阻断"（Falco 告警、Tetragon 可阻断）、需要网络策略联动（选 Tetragon）、需要取证能力（选 Tracee/Sysdig）、以及团队运维能力与生态集成（SIEM、告警）。eBPF 工具的共性边界是"观测内核可见行为"，无法覆盖纯应用层/业务逻辑的安全问题，需与其他防护配合。

eBPF 工具把"容器运行时行为"变成可观测、可检测、可执行的对象，但各有侧重：Falco 告警、Tracee 取证、Tetragon 网络/阻断、Sysdig 综合。选型依据是"告警 or 阻断""网络策略 or 取证""生态集成"，且 eBPF 只能观测内核可见行为，需叠加应用层防护。

• Falco 规则自定义机制
• 误报抑制与规则调优
• 告警分级与 SIEM 集成

Falco 运行时检测的规则调优与告警运营包括：规则自定义——Falco 规则（rules）由条件（condition，基于 syscall/事件字段）、宏与列表组成，可自定义规则匹配特定行为（如容器内执行 shell、异常文件访问），通过 falcoctl 或规则文件管理。误报抑制——规则过严会导致误报，需通过增加上下文条件（如按 namespace、进程、镜像白名单）、配置例外（exceptions）、调整阈值来抑制误报，并基于告警反馈持续调优规则。告警分级——按严重度（如提权、恶意进程、信息泄露）与影响面将告警分级（Critical/High/Medium/Low），对应不同响应时限。与 SIEM 集成——Falco 输出可对接 SIEM（如 Splunk、ELK、THREAT 平台），通过插件或 syslog/webhook 转发告警，在 SIEM 中统一关联、检索与告警处置，形成"检测→告警→SIEM→分析→响应"闭环。

Falco 运营的核心是"规则质量"与"告警闭环"：规则要自定义到贴合业务、抑制误报（否则告警淹没），告警要分级（有优先级），并接入 SIEM 统一治理。规则调优依赖告警反馈，误报数据是调优的输入，形成持续改进闭环。

• ImagePolicyWebhook 的准入机制
• 镜像来源与签名强制校验
• 落地与 fail-closed 策略

ImagePolicyWebhook 是一种 Kubernetes 准入控制器，在 Pod 创建时调用外部 webhook 服务，对镜像的"来源与签名"进行校验，只有通过校验的镜像才被允许创建。其工作方式：集群配置 ImagePolicyWebhook 为 admission 插件，Pod 中引用的镜像会发送给 webhook 服务，webhook 服务根据策略（如只允许来自受信任 registry 的镜像、校验镜像签名、校验镜像 digest）评估并返回 allow/deny，同时可结合 cosign 验证镜像签名（如通过 cosign 校验镜像是否由可信私钥签名）。实施强制校验时，应配置 fail-closed 策略——当 webhook 不可用或校验失败时拒绝创建（而非放行），防止攻破准入后放行恶意镜像；同时需配置 webhook 的 CACert、service 与 rules，并设置合理的重试与超时。基线结合：可用 ImagePolicyWebhook 强制镜像来源白名单 + 签名验签，配合镜像 digest 固定，阻止未授权或被篡改的镜像进入集群。

ImagePolicyWebhook 把"镜像能否运行"从"能拉取"提升为"来源受信 + 签名有效"。核心是 fail-closed（校验失败即拒绝）与"来源白名单 + 签名验签"的组合，确保只有受信任、未篡改的镜像能创建 Pod。这是容器准入中强制的镜像信任边界。

• NetworkPolicy 默认拒绝策略
• 按 namespace/label 分段
• DNS 规则与跨命名空间通信

K8s NetworkPolicy 微隔离落地的核心是"默认拒绝 + 按需放行"。默认拒绝策略：先为命名空间设置默认拒绝所有入站/出站的 NetworkPolicy，只允许显式声明的流量，从根本上减少横向移动面。按 namespace/label 分段：用 podSelector/namespaceSelector 按标签或命名空间将工作负载分组，只允许同一信任域内的 Pod 相互通信，实现微隔离。DNS 规则：允许访问 kube-dns/coredns（-> dns 规则）以支持服务发现，同时精确控制出站。跨命名空间通信：对需要跨命名空间的服务，用 namespaceSelector 明确放行指定的源/目标命名空间（如允许前端 ns 访问后端 ns 的特定端口），避免全开。落地时需注意：NetworkPolicy 依赖 CNI 支持（如 Calico、Cilium）且默认不拦截，需先建立策略再逐步收紧；要覆盖 Ingress 与 Egress 双向，并配合调试（如用 networking 工具验证）。微隔离的价值在于把"网络可达"约束为"策略允许"，显著缩小横向攻击面。

微隔离的本质是"默认拒绝 + 最小放行"：默认拒绝所有流量，再按 namespace/label 分段精确放行，配合 DNS 与跨命名空间规则形成可管理的最小网络拓扑。落地关键是先建默认拒绝策略、再逐步收紧，避免全开导致的横向移动。

• enforce 与 audit 模式的区别
• 策略引擎的工程实践
• 容器安全策略的落地

Kyverno 与 Gatekeeper 都是 Kubernetes 的准入策略引擎，用于在容器安全策略中实施"策略即代码"。两者都有 enforce 与 audit 模式：enforce 模式在准入时强制拒绝不符合策略的资源（如禁止特权容器、禁止 hostPath、强制非 root）；audit 模式只记录不符合策略的资源而不拒绝，用于评估现有负载的合规情况。工程实践：先以 audit 模式部署策略，收集存量资源的不合规情况，评估影响面后再逐步切换到 enforce；对策略按严重度分级（如安全基线、合规、最佳实践），用 label/annotation 提供例外与豁免；策略应版本化、可测试（通过 CI 测试策略），并接入审计日志与告警。Kyverno 用 YAML 声明策略（更易上手），Gatekeeper 用 OPA Rego（更灵活）。落地时 enforce 与 audit 结合：先用 audit 摸清现状，再 enforce 把关新资源，配合例外管理，实现容器安全策略的持续合规。

enforce 与 audit 是"强制"与"审计"两种策略模式：enforce 拒绝违规，audit 记录违规。工程实践的核心是"先 audit 后 enforce"——先摸清存量不合规面，再逐步收紧，避免误伤；同时用版本化、可测试、可豁免的策略管理，让安全策略成为可维护的工程资产。

• 容器逃逸的常见路径
• capabilities 滥用与特权容器风险
• seccomp/AppArmor 防护

容器逃逸指攻击者突破容器隔离，获得宿主机权限。常见路径：namespace 逃逸——容器内进程通过未隔离的 namespace 或错误挂载访问宿主机资源（如挂载宿主机 / 目录、访问宿主机进程）；capabilities 滥用——容器持有过多 capabilities（尤其 CAP_SYS_ADMIN 等）可执行宿主机特权操作（如挂载、mount 篡改）；特权容器（privileged）——获得完整 capabilities 且关闭大部分隔离，几乎等于宿主机 root，是最危险路径。检测防护：seccomp 限制系统调用（禁用逃逸常用的 syscall），AppArmor/SELinux 限制资源访问（MAC），配合最小 capabilities（从默认集裁剪）、禁用特权容器、只读根文件系统、User Namespace 隔离，以及运行时检测（Falco/EDR）监测逃逸行为。防护的核心是"最小权限 + 多层隔离 + 运行时监控"：即使一个隔离被突破，其他层仍能拦截。

容器逃逸的根因是"隔离被破坏或权限过大"，常见路径是 namespace 逃逸、capabilities 滥用与特权容器。防护通过 seccomp/AppArmor、最小 capabilities、禁特权容器、User Namespace 与运行时检测层层设防，形成纵深——单个隔离失效不代表整个宿主机失守。

• 镜像扫描接入 CI 卡点
• 扫描阈值设计
• 例外豁免流程与复审

镜像扫描接入 CI 卡点：在 CI 流水线构建镜像后执行漏洞扫描（如 grype/Trivy），根据扫描结果决定是否放行——设置阈值（如 Critical/High 漏洞数量），超过阈值即阻断构建（fail-on），使带高危漏洞的镜像无法进入部署。例外豁免管理：对"业务必须但无法立即修复"的漏洞，需走例外审批流程——由负责人申请、说明风险与缓解措施，安全团队审批后豁免；豁免应设置期限（如 30 天），到期后自动复审或重新扫描，若仍未修复则再次触发卡点或升级处理。同时可采用 VEX 对"不可利用"漏洞降噪，避免误豁免。设计要点：阈值要合理（避免一票否决导致阻塞，也避免阈值过低放行高危）；豁免要有审批、有期限、有复审，防止"豁免永久化"；卡点与豁免都要有审计记录，可追溯。

"CI 卡点 + 例外豁免"是镜像扫描落地的两个关键：卡点把高危漏洞挡在部署前，豁免为"必须但暂时无法修复"提供平衡。核心是豁免必须"有期限、有审批、有复审"，否则豁免会变成永久放行漏洞的漏洞，削弱卡点的意义。

• 多阶段构建与最小镜像
• 非 root、只读根文件系统、不可变标签
• 缓存投毒风险与防护

最小镜像与构建安全的落地要点：多阶段构建——用构建阶段把编译工具与依赖隔离，只将运行产物复制到最终镜像，使镜像最小化；非 root 用户——镜像内以非 root 用户运行应用（RUN useradd、USER 指令），降低提权影响；只读根文件系统——将根文件系统设为只读（securityContext readOnlyRootFilesystem: true），只暴露必要可写目录，防止被篡改；不可变标签——用 digest 或不可变 tag 固定镜像版本，避免 tag 被覆盖指向被篡改或新版本。缓存投毒风险与防护：镜像构建缓存（如 BuildKit 的 layer cache）可能被投毒——攻击者注入伪造的缓存层导致后续构建命中被篡改的产物。防护措施：共享缓存配合认证与权限控制（只允许受信任构建者写入）、按项目/信任域隔离缓存、对关键基础层做校验/签名、对高安全构建禁用远程缓存或使用不可信缓存只读策略、以及构建产物最终签名校验。

最小镜像与构建安全是"镜像内容最小化 + 运行权限最小化 + 版本不可变"的组合：多阶段构建让镜像最小，非 root 与只读根防提权，不可变标签防覆盖。缓存投毒是构建环节的供应链风险，靠缓存隔离、权限控制与签名校验防范。

• runtimeClassName 与 gVisor/Kata 的安全价值
• seccomp/AppArmor 加固
• 运维与性能代价评估

容器运行时安全加固通过更强的隔离与更严的权限限制提升安全性。runtimeClassName（gVisor/Kata）提供了更强的隔离层：gVisor 用用户态内核拦截系统调用，Kata Containers 用轻量 VM 提供硬件级隔离，二者都能显著降低容器逃逸风险，但代价是性能下降（gVisor 系统调用开销大，Kata VM 启动与内存开销大）与兼容性（部分应用/系统调用不兼容）。seccomp/AppArmor 加固：通过 seccomp profile 限制容器系统调用（白名单），AppArmor profile 限制资源访问，进一步缩小攻击面。运维与性能代价评估：运行时加固需评估性能开销（CPU/内存/延迟，尤其对 I/O 密集、系统调用密集的应用）、兼容性（应用是否依赖被禁 syscall 或被隔离的运行时）、运维复杂度（多运行时管理、profile 维护、故障排查更难）。落地时应对高安全要求的命名空间/工作负载启用 gVisor/Kata，对普通负载用 seccomp/AppArmor 加固，按风险与性能权衡选择。

运行时加固是"更安全隔离 vs 性能/兼容"的权衡：gVisor/Kata 提供更强的隔离但性能成本高，seccomp/AppArmor 成本低但要维护 profile。评估时按负载的关键程度与性能敏感度选择，做到"高风险负载更隔离，普通负载最小化加固"。

• 容器资源滥用与 DoS 的成因
• limit、cgroup 资源限制
• PID 限制与防护

容器资源滥用与 DoS 指容器内进程无限消耗宿主机资源（fork 炸弹导致进程数爆炸、内存/CPU 无限占用）从而拖垮宿主机或同节点其他容器。防护手段：资源 limit——通过 Kubernetes 的 resources.limits（CPU、内存）与 resources.requests 设定容器资源上限，配合 cgroup 在宿主机层面强制限制，防止无限消耗；PID 限制——通过 pids_cgroup（K8s 的 pod.spec.pidLimit 或容器运行时 PID 限制）限制容器内进程总数，阻断 fork 炸弹导致进程数爆炸；同时设置 CPU 配额、内存限制（超限 OOM kill）、磁盘 IO 限制等。落地时：设置合理的 requests/limits（过小会限制业务，过大会失去防护）、对 PID 设置上限、监控资源使用及时发现滥用、配合运行时检测识别异常行为。cgroup 是底层机制，K8s 的 limits 通过 cgroup v2 实现，是防资源 DoS 的基础。

容器资源 DoS 的防护核心是"给资源上锁"：cgroup 强制 CPU/内存/IO 上限，PID 限制阻断进程爆炸，limits 在 K8s 层声明。没有限制的容器是"无界"的，一个异常容器能拖垮整个节点，因此资源限制是容器安全与稳定性的基础。

• 镜像扫描的能力边界
• 运行时投毒的类型
• 运行时监控的补充

镜像扫描（静态扫描）检测的是镜像"内容"中的已知漏洞与恶意特征，但无法覆盖"运行时行为"——即镜像在运行时才显现的恶意行为。这类"运行时投毒"包括：混淆脚本（利用编码/拼接规避静态特征检测的恶意脚本）、动态下载（镜像运行时从外部下载恶意负载，如下载并执行恶意二进制、反向 shell）、环境操作（运行时读取敏感信息、提权、横向移动）。这些行为在镜像扫描时看不到，只有在运行时才发生。运行时监控的补充：通过 Falco、Tracee、Tetragon 等 eBPF 工具或 EDR 监控容器的运行时行为——检测异常进程执行、动态下载后执行、可疑网络外连、敏感文件访问、提权尝试等，识别并阻断"运行时才暴露的恶意行为"。配合镜像扫描（防已知）+ 运行时监控（防未知/动态）形成互补，覆盖"静态内容"与"动态行为"两个维度。

镜像扫描解决"镜像里有什么已知问题"，运行时监控解决"镜像运行起来做什么"。由于恶意行为可以动态下载、混淆，静态扫描存在盲区，必须靠运行时监控补位——检测"运行时的行为"而非"镜像的内容"，两者结合才是完整的容器安全。

• imagePullSecrets 的机制
• 凭据权限管理与轮换
• 多租户隔离

imagePullSecrets 用于在 Kubernetes 中为拉取私有镜像仓库提供凭据，本质是 Secret 中保存的 registry 认证信息（dockerconfigjson）。权限管理：凭据应遵循最小权限——为不同 registry 或不同命名空间/团队使用独立的凭据，避免共享一个高权限凭据；imagePullSecrets 可配置在服务账户（ServiceAccount）上，让命名空间内的 Pod 自动继承，便于统一管理。轮换：registry 凭据会过期或泄露，需支持轮换——通过更新 Secret 的 dockerconfigjson 实现，轮换时效仿金丝雀（先更新部分，再全量），并确保轮换不影响运行中 Pod（新 Pod 用新凭据，旧 Pod 保持）。多租户隔离：不同租户/团队应使用各自的 imagePullSecrets 与 registry 凭据，在命名空间或服务账户层面隔离，避免一个租户的凭据泄露影响其他租户；可配合 registry 的权限模型（只读/写受限）与镜像仓库权限控制，实现凭据与镜像的租户隔离。

imagePullSecrets 的治理核心是"最小权限 + 可轮换 + 租户隔离"：凭据要按需、按租户独立，避免共享高权限；支持轮换应对泄露；在命名空间/服务账户层隔离防止越权拉取。把凭据与身份、租户绑定，才能安全地管理镜像拉取。

• imageCredentialProvider 的机制
• 配置要点
• 缓存与失效回退

kubelet 的 imageCredentialProvider（镜像凭据提供插件）允许 kubelet 通过外部插件（如云厂商的 credential provider）动态获取镜像拉取凭据，而不是把凭据硬编码在节点或 imagePullSecrets 中。多用于云环境免密钥拉取。配置：通过 kubelet 的 --image-credential-provider-config 指定配置文件，配置声明了插件可处理的 registry 前缀与插件可执行文件路径；插件按需被调用，返回对应 registry 的凭据。缓存与失效回退：kubelet 会缓存插件返回的凭据（避免每次拉取都调用插件），缓存有有效期（TTL,由插件的 cache 配置决定）；当凭据失效或插件返回错误时，kubelet 应回退到 imagePullSecrets 或默认凭据，或按配置处理——若插件不可用且无回退凭据，拉取会失败，需保证插件可用性。落地时需配置插件可执行文件、权限与缓存 TTL，并考虑插件故障时的降级策略（fail-open 到 imagePullSecrets 或 fail-closed）。

imageCredentialProvider 把"拉取凭据"从静态配置改为"动态获取"，提升安全性与云环境适配性。关键在缓存（减少插件调用）与失效回退（插件故障/凭据失效时的处理），需明确降级策略并保证插件可用性。

• 云厂商 credential provider 的机制
• 对接 kubelet 的配置
• 免密钥拉取与安全价值

云厂商镜像凭据提供插件（如 Aliyun credential provider、AWS ecr-credential-provider、GCP）让 kubelet 通过调用云厂商的凭证服务动态获取镜像仓库凭据，实现"免密钥拉取"——即不在节点或 imagePullSecrets 中硬编码长期密钥。其机制：kubelet 通过 imageCredentialProvider 配置调用插件可执行文件，插件向云厂商的凭证接口（如 Aliyun ACR 的临时凭证、AWS ECR 的 get-login-token）换取短期凭据，返回给 kubelet 用于拉取镜像。对接配置：在 kubelet 的 credential provider 配置文件中声明该 registry 前缀与插件路径，安装插件到节点、授予适当地执行权限，并配置缓存 TTL。安全价值：凭据是短期的、动态获取的，不长期驻留节点，降低密钥泄露风险；配合云厂商的 IAM/权限模型（如按实例角色授权），实现最小权限与免密钥。落地时需确保插件可用（节点可访问云凭证服务）、缓存有效，并处理插件故障时的拉取回退。

云厂商 credential provider 的价值是"凭据动态化、短期化、不落盘"：用云厂商的临时凭证替代长期密钥，配合 IAM 角色实现最小权限与免密钥拉取。对接 kubelet 的关键是配置插件与 registry 前缀、保证插件可用并管理缓存，让安全性与云原生适配兼得。