云原生安全

一、现象与背景 【问题本质】 基础镜像（如 eclipse-temurin:17-jre）紧急更新后，依赖该镜像的微服务需重新验证安全合规性。但现有CI流程要求「全量Trivy扫描+无CRITICAL方可发布」，导致： - 重复构建耗时（如

一、现象或背景 46字符SA Token读出生产数据库密码 在EKS托管集群（Kubernetes 1.27.4）中，"payment-service"部署在"prod-payment"命名空间，使用默认ServiceAccount。红队通

一、背景与问题 1.1 现状痛点 管理一个 3 master + 5 worker 的 Kubernetes 集群（RBAC 已启用，镜像来自私有 Harbor），当前安全基线存在三大核心问题： 1. 人工巡检低效：依赖运维人员手动检查，耗

背景 管理一个 3 master + 5 worker 的 Kubernetes 集群（RBAC 已启用，镜像来自私有 Harbor），当前安全基线较为粗放，缺乏一套可落地、可重复执行的安全加固检查机制。 现象 1. 依赖人工巡检，效率低且

«作者：温砚舟-809｜3 年安全工程师｜专注安全加固与风险防范 栈：Kubernetes 1.28.4（kubeadm，cgroup v2，内核 5.15.0-91）、containerd 1.7.13、OPA/Kyverno 1.11、

«作者视角：8 年安全加固，习惯用「门锁」的比方讲机制 栈：阿里云 ECS（IMDS 1.0/2.0）、AWS EC2（IMDSv1/v2）、Go 1.21、K8s 1.27（对比参考） 结论先行：应用层挡不住 SSRF 是常态，真正决定「

一、现象：一条 kubectl 命令暴露了 3 个命名空间的数据库密码 去年 9 月，安全团队做一次内部红蓝对抗演练。蓝队（我们）的 "payment-service" 跑在 "prod-payment" 命名空间，部署了 4 个 Pod（