「知识图谱生成工具」一键将文件夹内容变身为交互式知识图谱的免安装桌面工具文末附免费下载链接-CSDN博客AI工程师面试高频考点题目及答案汇总 下载链接目录开篇安全左移从源头开始安全架构全景图TrivyCI阶段的漏洞猎手ClairRed Hat的安全老将OPA策略即代码的守门员Falco运行时的安全摄像头内核级安全隔离Seccomp/AppArmor/SELinux完整CI/CD安全流水线实战文末三件套开篇安全左移从源头开始你是否遇到过镜像漏洞被黑客利用、运行时异常行为没发现、安全策略靠人工检查的被动局面云原生安全需要左移——在构建时就发现问题。本文将给出生产级安全扫描方案。效率技巧安全左移Shift Left Security的核心思想是问题发现得越早修复成本越低。根据IBM的研究生产环境发现的安全问题修复成本是开发阶段的100倍想象一下你辛辛苦苦搭建的Kubernetes集群就像一座精心设计的城堡。但如果你的砖块容器镜像本身就藏着定时炸弹再厚的城墙也没用。这就是为什么我们需要一套从构建到运行的全方位安全方案。安全架构全景图在深入各个工具之前让我们先看看整体架构┌─────────────────────────────────────────────────────────────────────────────┐ │ 云原生安全防线全景图 │ ├─────────────────────────────────────────────────────────────────────────────┤ │ │ │ 【构建阶段】 【镜像仓库】 【部署阶段】 【运行阶段】 │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ 代码提交 │─────▶│ 镜像扫描 │──────▶│ 策略检查 │─────▶│ 实时监控 │ │ │ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ │ │ │ │ │ ▼ ▼ ▼ ▼ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Trivy │ │ Notary │ │ OPA │ │ Falco │ │ │ │ 漏洞扫描 │ │ 镜像签名 │ │ 准入控制 │ │ 异常检测 │ │ │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │ │ │ │ │ │ │ │ ▼ ▼ ▼ ▼ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Clair │ │ Cosign │ │ Kyverno │ │ Seccomp │ │ │ │ 漏洞分析 │ │ 密钥签名 │ │ 策略引擎 │ │ AppArmor │ │ │ └──────────┘ └──────────┘ └──────────┘ │ SELinux │ │ │ └──────────┘ │ │ │ │ ═══════════════════════════════════════════════════════════════════════ │ │ │ │ 【安全数据流】 │ │ │ │ Developer ──git push──▶ CI Pipeline ──scan──▶ Registry ──sign──▶ K8s │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ ┌────────┐ ┌────────┐ ┌────────┐ │ │ │ 阻断 │ │ 验证 │ │ 监控 │ │ │ └────────┘ └────────┘ └────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────────────┘⚠️避坑警告很多团队只关注运行时的安全防护却忽视了构建阶段的安全扫描。这就像在漏水的船上拼命往外舀水——治标不治本。TrivyCI阶段的漏洞猎手为什么选TrivyTrivy是Aqua Security开源的容器镜像漏洞扫描工具它就像一位不知疲倦的漏洞猎手能在几秒钟内找出镜像里的安全隐患。核心优势极速扫描 5秒/镜像实测比Clair快10倍以上开箱即用无需数据库初始化自动更新漏洞库全面覆盖支持OS包、语言依赖、配置文件扫描完全免费Apache 2.0协议商用无忧效率技巧Trivy的扫描速度之所以快是因为它采用了轻量级的漏洞数据库并且支持本地缓存。第一次扫描后后续扫描会更快快速上手# 安装Trivy以Linux为例 curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin # 扫描单个镜像 trivy image nginx:latest # 只显示高危和严重漏洞 trivy image --severity HIGH,CRITICAL nginx:latest # 输出JSON格式适合CI集成 trivy image --format json --output report.json nginx:latest # 扫描本地Dockerfile trivy config ./Dockerfile # 扫描文件系统 trivy filesystem /path/to/projectGitHub Actions集成# .github/workflows/security-scan.yml name: Security Scan on: push: branches: [ main, develop ] pull_request: branches: [ main ] jobs: trivy-scan: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkoutv4 - name: Build Docker image run: docker build -t myapp:${{ github.sha }} . - name: Run Trivy vulnerability scanner uses: aquasecurity/trivy-actionmaster with: image-ref: myapp:${{ github.sha }} format: sarif output: trivy-results.sarif severity: CRITICAL,HIGH exit-code: 1 # 发现高危漏洞时阻断构建 - name: Upload scan results uses: github/codeql-action/upload-sarifv2 if: always() with: sarif_file: trivy-results.sarif⚠️避坑警告默认情况下Trivy会扫描所有漏洞包括低危的。建议在CI中设置--severity HIGH,CRITICAL否则会被海量低危漏洞淹没。实战扫描结果分析$ trivy image --severity HIGH,CRITICAL python:3.9-slim python:3.9-slim (debian 11.7) Total: 45 (HIGH: 32, CRITICAL: 13) ┌──────────────────┬────────────────┬──────────┬─────────────────────┬─────────────────────┬─────────────────────────────────────────────┐ │ Library │ Vulnerability │ Severity │ Installed Version │ Fixed Version │ Title │ ├──────────────────┼────────────────┼──────────┼─────────────────────┼─────────────────────┼─────────────────────────────────────────────┤ │ libssl1.1 │ CVE-2023-0286 │ CRITICAL │ 1.1.1n-0deb11u4 │ 1.1.1n-0deb11u5 │ openssl: X.400 address type confusion in │ │ │ │ │ │ │ X.509 GeneralName │ ├──────────────────┼────────────────┼──────────┼─────────────────────┼─────────────────────┼─────────────────────────────────────────────┤ │ zlib1g │ CVE-2022-37434 │ CRITICAL │ 1:1.2.11.dfsg-2... │ 1:1.2.11.dfsg-2... │ zlib: heap-based buffer over-read │ └──────────────────┴────────────────┴──────────┴─────────────────────┴─────────────────────┴─────────────────────────────────────────────┘看到这一堆CVE编号是不是有点头大别担心重点关注Fixed Version列——只要升级到指定版本漏洞就消失了。ClairRed Hat的安全老将Clair vs Trivy如果说Trivy是小鲜肉那Clair就是老江湖。作为CoreOS后被Red Hat收购开发的项目Clair已经在生产环境摸爬滚打多年。特性ClairTrivy扫描速度较慢需拉取数据库 5秒/镜像数据库管理需自建/维护自动更新Notary集成✅ 原生支持❌ 需额外配置镜像签名验证✅ 内置❌ 第三方工具企业支持Red Hat背书Aqua Security效率技巧如果你的团队已经在使用Red Hat生态OpenShift、Quay等Clair是更自然的选择因为它与这些工具深度集成。Clair架构解析┌─────────────────────────────────────────────────────────────────┐ │ Clair 架构图 │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ Indexer │───▶│ Matcher │───▶│ Notifier │ │ │ │ (索引服务) │ │ (匹配服务) │ │ (通知服务) │ │ │ └──────┬───────┘ └──────┬───────┘ └──────────────┘ │ │ │ │ │ │ ▼ ▼ │ │ ┌──────────────┐ ┌──────────────┐ │ │ │ Layer Blob │ │ Vuln DB │ │ │ │ (镜像层) │ │ (漏洞库) │ │ │ └──────────────┘ └──────────────┘ │ │ │ │ 工作流程 │ │ 1. Indexer分析镜像层提取包信息 │ │ 2. Matcher将包信息与漏洞库匹配 │ │ 3. Notifier发送漏洞报告 │ │ │ └─────────────────────────────────────────────────────────────────┘部署ClairDocker Compose方式# docker-compose.yml version: 3.8 services: clair-db: image: postgres:15-alpine environment: POSTGRES_PASSWORD: clairpassword POSTGRES_DB: clair volumes: - clair-db-data:/var/lib/postgresql/data clair: image: quay.io/projectquay/clair:4.7.0 depends_on: - clair-db environment: CLAIR_CONF: | indexer: connstring: hostclair-db port5432 userpostgres passwordclairpassword dbnameclair sslmodedisable matcher: connstring: hostclair-db port5432 userpostgres passwordclairpassword dbnameclair sslmodedisable notifiers: connstring: hostclair-db port5432 userpostgres passwordclairpassword dbnameclair sslmodedisable command: [-conf, /etc/clair/config.yaml] ports: - 6060:6060 volumes: clair-db-data:Notary签名验证Clair的一大特色是原生支持Docker Content TrustNotary签名验证# 启用Docker Content Trust export DOCKER_CONTENT_TRUST1 # 拉取签名镜像 docker pull myregistry.com/myapp:v1.0 # 使用clairctl扫描并验证签名 clairctl report --host http://localhost:6060 myregistry.com/myapp:v1.0⚠️避坑警告Clair的数据库初始化时间较长首次启动可能需要几分钟。建议在生产环境使用预先填充数据的数据库镜像。OPA策略即代码的守门员什么是OPAOpen Policy AgentOPA是CNCF毕业项目它把安全策略从人治变成法治。想象一下以前靠人工审核的部署请求现在用代码自动判断——这就是策略即代码Policy as Code的魅力。OPA能做什么 Kubernetes准入控制Admission Control API网关授权 微服务间访问控制️ Terraform计划审查效率技巧OPA使用声明式语言Rego编写策略学习曲线有点陡但一旦掌握你会发现它比传统RBAC灵活得多。OPA在Kubernetes中的位置┌─────────────────────────────────────────────────────────────────┐ │ Kubernetes OPA 架构 │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ User ──kubectl apply──▶ API Server ──Webhook──▶ OPA/Gatekeeper │ │ │ │ │ ▼ │ │ ┌─────────────┴─┐ │ │ 策略评估引擎 │ │ │ │ │ │ rego策略文件 │ │ │ - 禁止特权容器 │ │ │ - 强制资源限制 │ │ │ - 要求标签 │ │ └───────┬───────┘ │ │ │ ▼ │ ┌───────────────┐ │ │ Allow / Deny │ │ └───────────────┘ │ │ │ 工作流程 │ │ 1. 用户提交资源定义Pod/Deployment等 │ │ 2. API Server调用OPA Webhook │ │ 3. OPA评估策略返回允许/拒绝 │ │ 4. 只有符合策略的资源才能创建 │ │ │ └─────────────────────────────────────────────────────────────────┘实战禁止特权容器# policy/restrict-privileged.rego package kubernetes.admission import rego.v1 # 默认拒绝 default allow : false # 允许非特权容器 allow if { input.request.kind.kind Pod not is_privileged } # 检测特权容器 is_privileged if { container : input.request.object.spec.containers[_] container.securityContext.privileged true } # 拒绝信息 deny contains msg if { is_privileged msg : 特权容器被禁止请移除securityContext.privileged }Gatekeeper安装与使用Gatekeeper是OPA的Kubernetes集成项目提供了更友好的CRD方式管理策略# 安装Gatekeeper kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yaml # 等待部署完成 kubectl wait --forconditionReady pod -l control-planecontroller-manager -n gatekeeper-system --timeout120s # 创建约束模板ConstraintTemplate cat EOF | kubectl apply -f - apiVersion: templates.gatekeeper.sh/v1 kind: ConstraintTemplate metadata: name: k8srequiredlabels spec: crd: spec: names: kind: K8sRequiredLabels validation: type: object properties: labels: type: array items: type: string targets: - target: admission.k8s.gatekeeper.sh rego: | package k8srequiredlabels violation[{msg: msg}] { provided : {label | input.review.object.metadata.labels[label]} required : {label | label : input.parameters.labels[_]} missing : required - provided count(missing) 0 msg : sprintf(必须包含标签: %v, [missing]) } EOF # 创建约束要求所有Namespace必须有team标签 cat EOF | kubectl apply -f - apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sRequiredLabels metadata: name: ns-must-have-team spec: match: kinds: - apiGroups: [] kinds: [Namespace] parameters: labels: [team] EOF # 测试创建没有team标签的Namespace会被拒绝 kubectl create namespace test-ns # Error from server (Forbidden): admission webhook validation.gatekeeper.sh denied the request: [ns-must-have-team] 必须包含标签: {team} # 创建带标签的Namespace成功 kubectl create namespace test-ns --label teamplatform⚠️避坑警告Gatekeeper的策略是异步生效的刚创建约束后立即测试可能会漏网。建议等待几秒再验证。Falco运行时的安全摄像头Falco是什么Falco由Sysdig捐赠给CNCF是云原生领域的安全摄像头。它在运行时监控系统调用检测异常行为就像给服务器装了一个24小时不间断的监控探头。核心能力系统调用监控基于eBPF或内核模块⚡低延迟检测规则命中延迟 100ms丰富规则库内置100检测规则多平台输出支持Slack、PagerDuty、Webhook等效率技巧Falco的规则文件使用YAML格式支持宏Macros和列表Lists可以像搭积木一样组合复杂的检测逻辑。Falco架构图┌─────────────────────────────────────────────────────────────────┐ │ Falco 架构图 │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ Linux Kernel │ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────────┐ │ │ │ │ │ eBPF Probe │ │Kernel Module│ │ Userspace Probe │ │ │ │ │ │ (推荐) │ │ (传统) │ │ (gVisor等) │ │ │ │ │ └──────┬──────┘ └──────┬──────┘ └────────┬────────┘ │ │ │ │ └─────────────────┴──────────────────┘ │ │ │ │ │ │ │ │ │ ▼ │ │ │ │ ┌─────────────────┐ │ │ │ │ │ System Calls │ │ │ │ │ │ (系统调用流) │ │ │ │ │ └────────┬────────┘ │ │ │ └───────────────────────────┼───────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ Falco Daemon │ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────────┐ │ │ │ │ │ Event Engine│──▶ Rule Engine │──▶ Output Manager │ │ │ │ │ │ (事件处理) │ │ (规则匹配) │ │ (告警输出) │ │ │ │ │ └─────────────┘ └─────────────┘ └─────────────────┘ │ │ │ │ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ │ │ Raw Events │ │ YAML Rules │ │ Slack │ │ │ │ │ │ (原始事件) │ │ (检测规则) │ │ PagerDuty │ │ │ │ │ │ │ │ - 异常进程 │ │ Webhook │ │ │ │ │ │ │ │ - 文件篡改 │ │ stdout │ │ │ │ │ │ │ │ - 网络连接 │ │ File │ │ │ │ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────┘安装Falco# 添加Falco Helm仓库 helm repo add falcosecurity https://falcosecurity.github.io/charts helm repo update # 安装Falco使用eBPF驱动 helm install falco falcosecurity/falco \ --namespace falco \ --create-namespace \ --set driver.kindebpf \ --set ttytrue # 查看Falco日志 kubectl logs -n falco -l app.kubernetes.io/namefalco -f实战检测反向Shell反向Shell是黑客常用的攻击手段Falco可以轻易检测# 自定义规则检测反向Shell - rule: Reverse Shell desc: 检测到可能的反向Shell活动 condition: spawned_process and ( (proc.name bash or proc.name sh) and (fd.name contains /dev/tcp/ or fd.name contains /dev/udp/) ) or ( proc.name nc and (proc.args contains -e or proc.args contains -c) ) or ( proc.name python and (proc.args contains socket or proc.args contains subprocess) ) output: 反向Shell检测 用户%user.name 命令%proc.cmdline 容器%container.name 命名空间%k8s.ns.name priority: CRITICAL实战检测敏感文件访问# 检测/etc/shadow等敏感文件被读取 - rule: Read Sensitive File desc: 检测到敏感文件被读取 condition: open_read and (fd.name contains /etc/shadow or fd.name contains /etc/passwd or fd.name contains /etc/kubernetes/admin.conf or fd.name contains /root/.ssh/) and not proc.name in (cat, less, more, vim) output: 敏感文件访问 用户%user.name 进程%proc.name 文件%fd.name 容器%container.name priority: WARNING与Alertmanager集成# falcosidekick配置发送告警到Alertmanager helm upgrade falco falcosecurity/falco \ --namespace falco \ --set falcosidekick.enabledtrue \ --set falcosidekick.config.alertmanager.hostporthttp://alertmanager:9093⚠️避坑警告Falco的eBPF驱动在某些内核版本上可能不兼容。如果遇到问题可以尝试切换到内核模块驱动--set driver.kindkmod。内核级安全隔离Seccomp/AppArmor/SELinux如果把容器比作公寓Seccomp/AppArmor/SELinux就是门锁、监控和保安——它们在内核层面限制容器能做什么。三种机制对比特性SeccompAppArmorSELinux层级系统调用过滤文件/网络访问控制强制访问控制MAC复杂度中等较低较高默认发行版通用Ubuntu/DebianRHEL/CentOS/Fedora学习曲线中等平缓陡峭灵活性高中高效率技巧Kubernetes默认启用了RuntimeDefault Seccomp策略但大多数镜像还是以Unconfined模式运行。建议显式指定Seccomp配置文件。Seccomp实战SeccompSecure Computing Mode通过过滤系统调用限制容器权限# seccomp-profile.json - 自定义Seccomp配置 { defaultAction: SCMP_ACT_ERRNO, architectures: [SCMP_ARCH_X86_64, SCMP_ARCH_X86], syscalls: [ { names: [ accept, accept4, access, adjtimex, alarm, bind, brk, capget, capset, chdir, chmod, chown, clock_gettime, clone, close, connect, copy_file_range, creat ], action: SCMP_ACT_ALLOW }, { names: [execve, execveat], action: SCMP_ACT_ALLOW, args: [] }, { names: [mount, umount2, pivot_root], action: SCMP_ACT_ERRNO } ] }# Pod中使用自定义Seccomp配置 apiVersion: v1 kind: Pod metadata: name: secure-pod spec: securityContext: seccompProfile: type: Localhost localhostProfile: my-custom-profile.json containers: - name: app image: myapp:v1.0 securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: true runAsNonRoot: true runAsUser: 1000 capabilities: drop: - ALLAppArmor实战AppArmor使用路径-based的配置更容易上手# /etc/apparmor.d/docker-nginx #include tunables/global profile docker-nginx flags(attach_disconnected,mediate_deleted) { #include abstractions/base network inet tcp, network inet udp, network inet icmp, deny network raw, deny network packet, file, deny /etc/passwd r, deny /etc/shadow r, deny /root/** r, deny /proc/sys/** w, deny /sys/** w, capability chown, capability dac_override, capability setuid, capability setgid, capability net_bind_service, deny capability sys_admin, deny capability sys_ptrace, deny capability sys_module, }# Kubernetes中使用AppArmor apiVersion: v1 kind: Pod metadata: name: nginx-apparmor annotations: container.apparmor.security.beta.kubernetes.io/nginx: localhost/docker-nginx spec: containers: - name: nginx image: nginx:alpineSELinux实战SELinux使用标签Label系统控制访问# 查看容器的SELinux标签 kubectl get pod mypod -o yaml | grep seLinuxOptions # 在Pod中指定SELinux选项apiVersion: v1 kind: Pod metadata: name: selinux-pod spec: securityContext: seLinuxOptions: level: s0:c123,c456 role: system_r type: spc_t user: system_u containers: - name: app image: myapp:v1.0 securityContext: seLinuxOptions: level: s0:c123,c456⚠️避坑警告SELinux的调试非常困难建议先用setenforce 0临时关闭确认问题确实由SELinux引起后再调整策略。完整CI/CD安全流水线实战架构图┌─────────────────────────────────────────────────────────────────────────────┐ │ 完整CI/CD安全流水线架构 │ ├─────────────────────────────────────────────────────────────────────────────┤ │ │ │ Developer │ │ │ │ │ │ git push │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ GitHub Actions │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ │ │ 代码扫描 │─▶│ 单元测试 │─▶│ 构建镜像 │─▶│ Trivy扫描 │ │ │ │ │ │ CodeQL │ │ │ │ │ │ 漏洞检测 │ │ │ │ │ └──────────┘ └──────────┘ └──────────┘ └────┬─────┘ │ │ │ │ │ │ │ │ │ ┌───────────────────────────────────────────────┘ │ │ │ │ │ │ │ │ │ ▼ │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ │ │ 扫描通过? │─▶│ 镜像签名 │─▶│ 推送仓库 │ │ │ │ │ │ │ │ Cosign │ │ │ │ │ │ │ └──────────┘ └──────────┘ └────┬─────┘ │ │ │ │ │ │ │ │ └───────────────────────────────────┼─────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ Harbor Registry │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ │ │ 镜像存储 │ │ 漏洞扫描 │ │ 签名验证 │ │ │ │ │ │ │ │ (Clair) │ │ (Notary) │ │ │ │ │ └──────────┘ └──────────┘ └──────────┘ │ │ │ └───────────────────────────────────┬─────────────────────────────────┘ │ │ │ │ │ │ webhook │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ Kubernetes Cluster │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ │ │ OPA/Gate │─▶│ 准入控制 │─▶│ Pod创建 │─▶│ Falco监控 │ │ │ │ │ │ -keeper │ │ │ │ │ │ │ │ │ │ │ └──────────┘ └──────────┘ └──────────┘ └────┬─────┘ │ │ │ │ │ │ │ │ │ ┌───────────────────────────────────────────────┘ │ │ │ │ │ │ │ │ │ ▼ │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ │ │ Seccomp │ │AppArmor │ │ 运行时 │ │ │ │ │ │ 限制 │ │ 限制 │ │ 保护 │ │ │ │ │ └──────────┘ └──────────┘ └──────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────┘ │ │ │ │ ═══════════════════════════════════════════════════════════════════════ │ │ │ │ 【告警与响应】 │ │ │ │ Falco ──▶ Alertmanager ──▶ PagerDuty/Slack/邮件 │ │ │ └─────────────────────────────────────────────────────────────────────────────┘完整GitHub Actions工作流# .github/workflows/complete-security-pipeline.yml name: Complete Security Pipeline on: push: branches: [ main ] pull_request: branches: [ main ] env: REGISTRY: ghcr.io IMAGE_NAME: ${{ github.repository }} jobs: # 阶段1代码安全扫描 code-scan: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: Initialize CodeQL uses: github/codeql-action/initv3 with: languages: go, javascript - name: Autobuild uses: github/codeql-action/autobuildv3 - name: Perform CodeQL Analysis uses: github/codeql-action/analyzev3 # 阶段2构建与镜像扫描 build-and-scan: runs-on: ubuntu-latest needs: code-scan permissions: contents: read packages: write security-events: write steps: - name: Checkout uses: actions/checkoutv4 - name: Set up Docker Buildx uses: docker/setup-buildx-actionv3 - name: Build image run: | docker build -t test-image:${{ github.sha }} . - name: Run Trivy vulnerability scanner uses: aquasecurity/trivy-actionmaster with: image-ref: test-image:${{ github.sha }} format: sarif output: trivy-results.sarif severity: CRITICAL,HIGH exit-code: 1 - name: Upload Trivy scan results uses: github/codeql-action/upload-sarifv2 if: always() with: sarif_file: trivy-results.sarif # 阶段3镜像签名与推送 sign-and-push: runs-on: ubuntu-latest needs: build-and-scan if: github.event_name push github.ref refs/heads/main permissions: contents: read packages: write id-token: write steps: - name: Checkout uses: actions/checkoutv4 - name: Set up Docker Buildx uses: docker/setup-buildx-actionv3 - name: Login to Container Registry uses: docker/login-actionv3 with: registry: ${{ env.REGISTRY }} username: ${{ github.actor }} password: ${{ secrets.GITHUB_TOKEN }} - name: Build and push uses: docker/build-push-actionv5 with: context: . push: true tags: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }} - name: Install Cosign uses: sigstore/cosign-installerv3 - name: Sign image with Cosign run: | cosign sign --yes \ ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }}Kubernetes安全策略配置# security-policies.yaml --- # 强制使用非root用户运行 apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sPSPForbiddenRootUser metadata: name: forbid-root spec: match: kinds: - apiGroups: [] kinds: [Pod] excludedNamespaces: [kube-system] --- # 强制资源限制 apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sRequiredResources metadata: name: require-resources spec: match: kinds: - apiGroups: [] kinds: [Pod] parameters: limits: - cpu - memory --- # 禁止特权容器 apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sPSPPrivilegedContainer metadata: name: deny-privileged spec: match: kinds: - apiGroups: [] kinds: [Pod] --- # 默认安全上下文 apiVersion: v1 kind: LimitRange metadata: name: default-security namespace: default spec: limits: - default: cpu: 500m memory: 512Mi defaultRequest: cpu: 100m memory: 128Mi type: Container文末三件套1. 【源码获取】关注此系列获取后续更新后台回复’安全’获取完整源码和配置文件2. 【思考题】你们的安全扫描是在哪个阶段做的A. 构建阶段CI中扫描B. 部署阶段镜像仓库扫描C. 运行阶段实时监控D. 以上都有欢迎在评论区分享你的安全实践3. 【系列预告】云原生进阶之路可观测性→ Prometheus Grafana Jaeger 构建可观测体系高可用→ 多集群、灾备、自动故障转移服务网格→ Istio深度实践流量治理与安全防护总结云原生安全不是单一工具能解决的需要构建从构建-部署-运行的全链路防护阶段工具作用构建Trivy/Clair漏洞扫描签名Cosign/Notary镜像签名验证部署OPA/Gatekeeper策略准入控制运行Falco异常行为检测内核Seccomp/AppArmor/SELinux系统调用限制记住安全左移从源头开始。在构建阶段发现问题比在生产环境救火成本低100倍标签TrivyClairOPAFalco安全扫描容器安全云原生安全