seyifalode-cmd/k8s-container-security-pipeline

# Kubernetes 容器安全管道 **项目 1/2 — 动手实操 DevSecOps 作品集** Oluwaseyi Michael Falode | 网络安全与云安全工程师 | 加拿大多伦多 | 2026年5月 一个完整的三层 Kubernetes 容器安全管道，在本地 Minikube 集群上从零搭建完成。每一条命令均在真实终端中实时执行。每一张截图均于实际会话期间捕获。无任何模拟内容。 ## 项目概览 | | | |---|---| | **工具** | Trivy · OPA Gatekeeper · Falco · Helm · Minikube · kubectl | | **平台** | macOS — Docker Desktop v29.1.3 — Minikube v1.38.1 — Kubernetes v1.35.1 | | **语言** | YAML（配置） · Rego（OPA 策略语言） | | **框架** | CIS Kubernetes Benchmark · NIST SP 800-190 容器安全指南 | | **MITRE ATT&CK** | T1610 部署容器 · T1543 创建进程 · T1057 进程发现 | | **完成日期** | 2026年5月16日，星期六 | ## 本项目解决的问题 容器是现代应用程序基础设施的支柱。问题在于安全性往往被事后考虑——团队快速部署容器，稍后（如果有的话）才检查安全问题。 这导致容器生命周期的不同阶段产生了三个危险的差距： 此管道使用三个专门构建的开源工具——每个工具对应一层风险——同时解决所有三个差距。 ## 管道架构 ``` IMAGE IN REGISTRY (Docker Hub / ECR) | TRIVY (Layer 1 — Before Deployment) Scans image for CVEs, secrets, misconfigs Blocks: CRITICAL and HIGH severity CVEs | | image passes scan | kubectl apply / helm install v OPA GATEKEEPER (Layer 2 — At Deployment) Intercepts every deployment. Blocks: root containers, bad configs Blocks policy violations. | | passes all policies | CONTAINER RUNNING IN POD ON NODE v FALCO (Layer 3 — During Runtime) Watches every syscall. Detects: shell spawns, file reads, exfil Alerts in under 3 seconds. ``` ## 仓库结构 ``` k8s-container-security-pipeline/ ├── gatekeeper/ │ ├── constraint-template.yaml # Rego policy defining the no-root rule │ ├── constraint.yaml # Activates the policy across namespaces │ ├── bad-pod.yaml # Test pod with runAsUser: 0 (blocked) │ └── good-pod.yaml # Test pod with runAsUser: 1000 (allowed) ├── screenshots/ │ └── (18 screenshots from the live session) ├── docs/ │ └── Project1_K8s_Security_Pipeline_FINAL.pdf └── README.md ``` ## 构建成果 — 完整结果 | 可交付成果 | 结果 | |---|---| | Kubernetes 集群 | Minikube v1.38.1 — 单节点，Kubernetes v1.35.1 — 完全可运行 | | OPA Gatekeeper | v3.17.1 已部署 — 验证性 webhook 处于活动状态 — 创建了 20+ 资源 | | 禁止 root 策略 | ConstraintTemplate + Constraint 已应用 — 在 default 命名空间强制执行 | | 坏 Pod 测试 | runAsUser: 0 在准入层被拒绝 — Pod 从未创建或调度 | | 好 Pod 测试 | nginx-unprivileged + runAsUser: 1000 — 状态 Running 1/1，重启 0 次 | | Trivy 扫描 — nginx | 发现 233 个漏洞：严重: 3，高危: 22，中等: 86 | | Trivy 扫描 — unprivileged | 发现 232 个漏洞：严重: 3，高危: 21 — 相同的 Debian 基础系统 | | Falco 部署 | Helm 安装 — 状态: deployed — falco Pod Running 2/2 — eBPF 处于活动状态 | | Falco 实时告警 | 在 <3 秒内检测到 Shell 启动 — 记录了完整的取证元数据 | ## 分步详解 ### 步骤 1 — 环境检查与工具安装 在编写任何配置之前，验证了所有必需的工具。 ``` docker --version # check Docker version kubectl version --client # check kubectl version which trivy # check if Trivy is installed which minikube # check if Minikube is installed ``` **结果：** Docker v29.1.3 ✓ kubectl v1.34.1 ✓ trivy: 未找到 ✗ minikube: 未找到 ✗ 通过 Homebrew 安装了缺失的工具： ``` brew install minikube # installs Minikube brew install trivy # installs Trivy ``` **结果：** Minikube v1.38.1 ✓ Trivy v0.70.0 ✓ ### 步骤 2 — Kubernetes 集群部署 使用 Minikube 在 Docker Desktop 内部启动了一个单节点 Kubernetes 集群。 ``` minikube start --driver=docker ``` Minikube 下载了 Kubernetes v1.35.1，创建了一个 Docker 容器作为集群节点（2 个 CPU，4600MB 内存），安装了所有 Kubernetes 内部组件，并自动配置了 kubectl。 ``` kubectl get nodes # list all nodes in the cluster kubectl get pods --all-namespaces # list all running system pods ``` **结果：** minikube 节点 STATUS=Ready，VERSION=v1.35.1。kube-system 命名空间中所有 7 个系统 Pod 处于 Running 状态，重启次数为 0。 ### 步骤 3 — OPA Gatekeeper — 准入控制 将 OPA Gatekeeper v3.17.1 作为验证性准入 webhook 安装。从此刻起，Kubernetes 在创建任何资源之前必须向 Gatekeeper 请求批准。 ``` kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/v3.17.1/deploy/gatekeeper.yaml ``` **结果：** 创建了 20+ 资源，包括 validatingwebhookconfiguration。所有 4 个 gatekeeper-system Pod 处于 Running 状态。 创建了项目文件夹结构： ``` mkdir ~/devsecops-project && cd ~/devsecops-project mkdir gatekeeper # subfolder for all policy files ``` ### 步骤 4 — 编写禁止 Root 安全策略 #### ConstraintTemplate（`gatekeeper/constraint-template.yaml`） 用 Rego 定义规则逻辑。检查传入部署请求中的每个容器——如果 `runAsUser` 设置为 `0`（root），则视为违规。 ``` apiVersion: templates.gatekeeper.sh/v1 kind: ConstraintTemplate metadata: name: k8snorootcontainers spec: crd: spec: names: kind: K8sNoRootContainers targets: - target: admission.k8s.gatekeeper.sh rego: | package k8snorootcontainers violation[{"msg": msg}] { c := input.review.object.spec.containers[_] c.securityContext.runAsUser == 0 msg := sprintf("BLOCKED: Container '%v' runs as root (UID 0)", [c.name]) } ``` #### Constraint（`gatekeeper/constraint.yaml`） 在集群中所有 Pod 上激活 ConstraintTemplate，排除系统命名空间。 ``` apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sNoRootContainers metadata: name: deny-root-containers spec: match: kinds: - apiGroups: [""] kinds: ["Pod"] excludedNamespaces: - kube-system - gatekeeper-system ``` 应用了这两个文件： ``` kubectl apply -f ~/devsecops-project/gatekeeper/constraint-template.yaml kubectl apply -f ~/devsecops-project/gatekeeper/constraint.yaml ``` **结果：** constrainttemplate k8snorootcontainers 已创建 ✓ constraint deny-root-containers 已创建 ✓ 策略现已生效。 ### 步骤 5 — 测试策略强制执行 #### 测试 A — 坏 Pod（`gatekeeper/bad-pod.yaml`） ``` apiVersion: v1 kind: Pod metadata: name: bad-pod namespace: default spec: containers: - name: bad-container image: nginx securityContext: runAsUser: 0 # ROOT USER — should be blocked ``` **结果：** 准入 webhook "validation.gatekeeper.sh" 拒绝了请求。错误：BLOCKED: 容器 bad-container 以 root 身份运行（UID 0）。Pod 从未创建。 #### 测试 B — 好 Pod（`gatekeeper/good-pod.yaml`） ``` apiVersion: v1 kind: Pod metadata: name: good-pod namespace: default spec: containers: - name: good-container image: nginxinc/nginx-unprivileged # security-conscious image securityContext: runAsUser: 1000 ``` **结果：** STATUS=Running，READY=1/1，RESTARTS=0。策略通过，容器运行健康。 | Pod | 配置 | 结果 | |---|---|---| | bad-pod (nginx) | runAsUser: 0 (root) | BLOCKED | | good-pod v1 (nginx) | runAsUser: 1000 — 错误的镜像 | CrashLoopBackOff | | good-pod v2 (nginx-unprivileged) | runAsUser: 1000 — 正确的镜像 | Running | ### 步骤 6 — Trivy 镜像漏洞扫描 在部署前扫描容器镜像的已知 CVE（管道第 1 层）。 ``` trivy image nginx trivy image nginxinc/nginx-unprivileged 2>/dev/null | grep 'Total:' ``` | 镜像 | 严重 | 高危 | 中等 | 总计 | |---|---|---|---|---| | nginx（标准） | 3 | 22 | 86 | 233 | | nginxinc/nginx-unprivileged | 3 | 21 | 86 | 232 | 两个镜像的漏洞数量几乎相同，因为它们都基于 Debian Linux 构建。漏洞来自底层操作系统软件包，而非 nginx 本身。真正加固的镜像会使用 Alpine Linux 作为基础操作系统。 **重要发现：** nginx 镜像内的 `bash` 软件包存在一个权限提升漏洞 (TEMP-0841856)。任何获得容器内某种级别访问权限的攻击者，都可能利用此漏洞提升权限。 ### 步骤 7 — Falco 运行时威胁检测 安装了 Falco 作为第三个也是最后一层安全防护。Trivy 和 Gatekeeper 在部署前和部署时防止问题，而 Falco 则监控容器运行期间实际发生的情况。 ``` # 添加 Falco chart 仓库到 Helm helm repo add falcosecurity https://falcosecurity.github.io/charts # 更新仓库 helm repo update # 使用 eBPF 驱动安装 Falco helm install falco falcosecurity/falco \ --namespace falco \ --create-namespace \ --set driver.kind=modern_ebpf \ --set tty=true ``` **结果：** 状态：deployed。falco Pod Running 2/2。eBPF 代理在所有节点上启动并监控所有容器。 #### 触发实时告警 在正在运行的容器内打开一个交互式 Shell，模拟后渗透场景： ``` kubectl exec -it good-pod -- /bin/sh $ whoami # ran inside the container — shows user 1000 $ exit # exited the container shell ``` 立即读取 Falco 日志： ``` kubectl logs -n falco -l app.kubernetes.io/name=falco --tail=20 ``` **结果：** Falco 在 3 秒内触发了告警： 该告警包含了安全运营团队调查和响应所需的所有信息：谁触发了它，启动了什么进程，哪个容器，哪个镜像，以及哪个命名空间。在生产环境中，此告警将被转发到 SIEM（Splunk、Elasticsearch），并可能在几秒内触发自动化响应——隔离 Pod 或封锁节点。 ## 如何复现此项目 **前提条件：** Docker Desktop，Homebrew（macOS） ``` # 1. 安装工具 brew install minikube trivy # 2. 启动集群 minikube start --driver=docker # 3. 验证集群 kubectl get nodes kubectl get pods --all-namespaces # 4. 安装 OPA Gatekeeper kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/v3.17.1/deploy/gatekeeper.yaml # 5. 应用 no-root 策略 kubectl apply -f gatekeeper/constraint-template.yaml kubectl apply -f gatekeeper/constraint.yaml # 6. 测试执行 kubectl apply -f gatekeeper/bad-pod.yaml # should be BLOCKED kubectl apply -f gatekeeper/good-pod.yaml # should be allowed # 7. 使用 Trivy 扫描镜像 trivy image nginx trivy image nginxinc/nginx-unprivileged # 8. 安装 Falco helm repo add falcosecurity https://falcosecurity.github.io/charts helm repo update helm install falco falcosecurity/falco \ --namespace falco \ --create-namespace \ --set driver.kind=modern_ebpf \ --set tty=true # 9. 触发并观察 Falco 告警 kubectl exec -it good-pod -- /bin/sh kubectl logs -n falco -l app.kubernetes.io/name=falco --tail=20 ``` ## 参考的安全框架 - **CIS Kubernetes Benchmark** — Kubernetes 集群的行业标准加固指南 - **NIST SP 800-190** — 应用容器安全指南 - **MITRE ATT&CK** — T1610（部署容器），T1543（创建进程），T1057（进程发现） *Oluwaseyi Michael Falode · 网络安全与云安全工程师 · 加拿大多伦多 · 2026年5月*

标签：Anthropic, APT组织, Chrome Headless, CIS基准, Claude, CVE检测, DevSecOps, Falco, Groq API, Helm, kubectl, Kubernetes安全, Minikube, NIST框架, OPA Gatekeeper, Pandas, Rego, Web截图, YAML, 上游代理, 安全合规, 安全库, 容器安全, 敏感词过滤, 活动识别, 知识图谱, 结构化提示词, 网络代理, 运行时威胁检测, 镜像扫描