长期以来，Kubernetes 社区一直依赖 container.apparmor.security.beta.kubernetes.io/<container-name> 这一 Pod 注解机制来配置 AppArmor 策略。这种注解不仅破坏了 ...

在持续集成（CI）流水线和容器交付链路中，基础镜像通常预装了 curl 命令行工具，许多构建脚本、发布工具和内部运维 CLI 也会直接调用或链接 libcurl。根据官方安全公告，CVE-2026-92392 揭示了一个存在于 libcurl 中的高危释放后使...

容器与宿主机共享 Linux 内核。如果工作负载未配置 Seccomp，且节点 kubelet 没有启用默认配置，容器可能以 Unconfined 方式运行，缺少 Seccomp 系统调用过滤。将默认配置收敛到 RuntimeDefault，可以减少不必要的内...

镜像治理在 Kubernetes 集群里经常被当成两件事：一件是“把镜像做小”，另一件是“把标签换成摘要”。但在实际攻防视角下，它们消除的是两类完全不同的风险，而且只有串起来才能被验证。典型场景是：集群里跑着几十个 Deployment，镜像引用写成 app:...

很多团队在 Pod 安全上下文里写了 runAsNonRoot: true，就认为容器逃逸的风险已经被兜住了。这个判断只对了一半：runAsNonRoot 约束的是容器内进程的 UID 不为 0，它并不改变内核视角下这个 UID 与宿主机 UID 的对应关系。...

Kubernetes 控制平面的安全防线中，准入控制器（Admission Controller）扮演着请求“守门员”的角色：它在请求通过认证和鉴权之后、对象被持久化之前拦截 API 请求，既可以修改请求内容，也可以直接拒绝。当攻击者突破应用层权限后，往往会把...

镜像从构建流水线进入集群，中间会经过镜像仓库、拉取凭据、准入控制、kubelet 缓存等多个环节；只要有一个环节允许未经授权的摘要进入,前面的签名工作就难以发挥作用。常见风险位置包括：使用可变 tag 覆盖已发布镜像、仓库写入权限过宽、准入控制器只覆盖部分命名...

在托管 Kubernetes 集群里，很多工作负载仍以镜像默认用户启动，容器内进程 UID 0 与宿主机内核之间只隔命名空间和 Linux Capabilities。应用一旦被利用，攻击者就可能写入容器可写层、投放工具、尝试挂载或借助多余能力扩大影响。secu...

临时容器（ephemeral container）是 Kubernetes 在排障场景下提供的一把“万能钥匙”，它允许你在一个已经运行、甚至已经崩溃的 Pod 里临时注入一个调试容器，共享进程命名空间、挂载卷和网络栈。对于无法用 kubectl exec 进入...

在自建 Kubernetes 集群里，API server 与 etcd 之间的链路承载着全部对象状态、准入结果和控制器协调数据。很多加固清单把注意力放在 Secret 的静态加密上，但另一个更直接的问题往往被忽略：谁能够到达 etcd 的 2379 和 23...