云原生安全实践：在AWS EKS中实现容器镜像扫描与策略执行

云原生安全实践：在AWS EKS中实现容器镜像扫描与策略执行

随着云原生技术的普及，容器化应用已成为现代软件交付的标准方式。然而，容器镜像的安全性问题也随之凸显。未经扫描的镜像可能包含已知漏洞、恶意软件或不安全的配置，直接部署到生产环境会带来严重的安全风险。

在AWS EKS（Elastic Kubernetes Service）环境中，构建一套自动化的容器镜像扫描与策略执行机制，是保障云原生应用安全的关键环节。本文将详细介绍如何在EKS中实现这一安全实践。

容器镜像安全威胁与扫描必要性

容器镜像由多层文件系统叠加而成，每一层都可能引入安全漏洞。常见的威胁包括：

• 基础镜像漏洞：使用的操作系统或语言运行时基础镜像包含未修复的CVE。
• 应用依赖漏洞：应用程序引入的第三方库存在安全缺陷。
• 敏感信息泄露：镜像中意外打包了密码、API密钥等敏感数据。
• 配置不当：以root权限运行、开放不必要的端口等。

镜像扫描工具能够对镜像进行静态分析，识别上述风险，并与漏洞数据库（如NVD）进行比对，生成详细报告。

AWS EKS 中的镜像扫描方案选型

在AWS生态中，有多种方式可以实现镜像扫描：

1. Amazon ECR 原生扫描：AWS Elastic Container Registry (ECR) 集成了基本的漏洞扫描功能，对推送到仓库的镜像自动扫描，并与Common Vulnerabilities and Exposures (CVE) 数据库同步。
2. 第三方扫描工具集成：如Trivy、Clair、Anchore Engine等，它们通常功能更强大，支持自定义策略，并能集成到CI/CD流水线中。
3. 策略执行与准入控制：借助Kubernetes的准入控制器（如OPA Gatekeeper、Kyverno），在Pod创建时拦截请求，根据镜像扫描结果决定是否允许部署。

本文将重点介绍结合Trivy（开源扫描器）与Kyverno（策略引擎）的方案，该方案灵活且功能强大。

实践步骤：集成 Trivy 与 Kyverno

步骤一：在CI/CD流水线中集成Trivy扫描

在构建镜像并推送到ECR后，立即触发扫描。以下是一个GitHub Actions工作流示例，它构建镜像、推送到ECR，并使用Trivy进行扫描：

# .github/workflows/build-and-scan.yml
name: Build, Push and Scanon:push:branches: [ main ]jobs:build-and-scan:runs-on: ubuntu-lateststeps:- name: Checkout codeuses: actions/checkout@v3- name: Configure AWS credentialsuses: aws-actions/configure-aws-credentials@v2with:aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}aws-region: us-east-1- name: Login to Amazon ECRid: login-ecruses: aws-actions/amazon-ecr-login@v1- name: Build, tag, and push image to Amazon ECRenv:ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}ECR_REPOSITORY: my-appIMAGE_TAG: ${{ github.sha }}run: |docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG- name: Run Trivy vulnerability scanneruses: aquasecurity/trivy-action@masterwith:image-ref: '${{ steps.login-ecr.outputs.registry }}/my-app:${{ github.sha }}'format: 'sarif'output: 'trivy-results.sarif'severity: 'CRITICAL,HIGH'# 可以在此处添加基于扫描结果失败工作流的逻辑

此步骤将安全左移，在镜像进入仓库前就发现问题。扫描报告可以上传到安全仪表板或用于后续策略决策。

步骤二：在EKS集群中安装Kyverno

Kyverno是一个Kubernetes原生策略管理工具，使用YAML编写策略，无需学习新语言。通过Helm安装：

# 添加Kyverno Helm仓库
helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update# 在EKS集群中安装Kyverno
helm install kyverno kyverno/kyverno -n kyverno --create-namespace \--set replicaCount=2 \--set image.registry="docker.io" \--set image.tag="v1.10.0"

安装后，Kyverno会作为动态准入控制器运行，拦截符合条件的Kubernetes API请求。

步骤三：编写并应用镜像安全策略

我们需要一个Kyverno策略，要求所有新创建的Pod所使用的镜像必须通过安全扫描，且不能包含严重（CRITICAL）级别的漏洞。

假设我们的CI/CD流程会在镜像的标签（Tag）中嵌入一个“安全签名”（例如，扫描通过后打上 scan-passed:v1 的标签），或者将扫描结果写入一个允许列表（Allow List）。这里展示一个基于镜像标签的简化策略：

# policy-require-safe-image.yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:name: require-safe-image
spec:validationFailureAction: Enforce # 阻止违规请求background: falserules:- name: check-image-tagmatch:resources:kinds:- Podvalidate:message: "Only images tagged with 'scan-passed' are allowed for deployment."pattern:spec:containers:- image: "*:scan-passed" # 要求镜像标签包含 'scan-passed'

应用此策略：

kubectl apply -f policy-require-safe-image.yaml

此后，任何尝试部署标签不为 scan-passed 的镜像的Pod都会被Kyverno拒绝。

更高级的场景：我们可以开发一个微服务，查询dblens SQL编辑器管理的安全扫描结果数据库。dblens SQL编辑器提供了直观的界面和强大的查询能力，能快速检索镜像的漏洞状态。Kyverno策略可以调用这个微服务进行校验，实现更动态、基于数据库记录的策略决策。例如，查询 SELECT is_compliant FROM image_scans WHERE image_digest = ? 来判断是否放行。

步骤四：实现运行时镜像扫描与策略联动（可选）

对于已经运行在集群中的镜像，我们可以定期执行运行时扫描，并联动策略进行响应。例如，使用Trivy的Kubernetes Operator定期扫描集群内所有Pod的镜像，如果发现新的高危漏洞，则通过Kyverno生成一个违规报告，甚至自动给相关命名空间打上标签，触发修复流程。

在这个过程中，团队可以使用 QueryNote（https://note.dblens.com）来协作记录和跟踪发现的安全事件。QueryNote 非常适合记录漏洞的上下文、修复步骤和根本原因分析，其与数据库的深度集成使得将扫描结果直接关联到分析笔记变得非常方便，提升了安全运维的效率和可追溯性。

总结

在AWS EKS中实现容器镜像扫描与策略执行，是一个多层次、纵深防御的安全实践。通过将 Trivy 等扫描工具集成到CI/CD流水线，我们可以实现“安全左移”，尽早发现漏洞。再通过 Kyverno 这样的Kubernetes原生策略引擎，在部署时进行强制拦截，确保只有符合安全标准的镜像才能运行。

整个安全流程的数据（如漏洞库、扫描结果、策略日志）的管理和查询至关重要。像 dblens 提供的数据库工具（如SQL编辑器和QueryNote），能够帮助安全团队高效地存储、查询和分析这些安全数据，并将分析过程与团队协作无缝结合，从而构建起一个闭环、可观测、可执行的云原生容器安全体系。

安全是一个持续的过程，除了技术工具，还需要配合明确的安全策略、定期的审计和团队的安全意识培训，才能最大程度地保障云原生应用的安全。