使用 HCP 进行基础设施镜像的漏洞和补丁管理

作者：Randy Keener

本技术文档概述了 HashiCorp 验证的、用于实施 30 天重铺周期以实现漏洞和补丁管理 (VPM) 的方法。通过自动化不可变基础设施的创建、测试和部署，该策略可最大程度地降低漏洞风险，同时确保跨云环境的一致性。HCP Terraform 和 HCP Packer 用于集中化镜像管理和自动化更新。

以下章节涵盖了先决条件、架构、流程和分步说明，以实现此解决方案并使用提供的代码存储库运行“价值证明”(PoV)。

遵循此模式将提供

• 30 天重铺策略：每 30 天使用已打补丁的镜像替换实例，以最大程度地减少暴露于漏洞的风险
• VPM 环境设置：使用 Terraform 配置来部署测试基础设施并验证镜像更新工作流
• 使用 HCP Packer 和 HCP Terraform 进行集中的基础设施和补丁管理

目标受众

本指南参考了以下角色

• 负责减少未解决漏洞的暴露时间并展示漏洞管理可衡量改进的安全团队
• 负责管理 HCP Terraform 和 HCP Packer 的平台团队

先决条件

实施具有 30 天重铺周期的不可变基础设施模型需要具备某些技术和组织上的先决条件。

1. 自动化工具和基础设施即代码 (IaC)
   • 需要 HCP Terraform 来进行声明式管理、自动化配置和基础设施组件的生命周期管理。
   • 需要 HCP Packer 来构建、版本控制和存储不可变镜像的元数据。与 CI/CD 流水线集成可确保自动化和定期的镜像更新。
   • 版本控制系统 (VCS)，例如 Github，已配置了 Github Actions 机密和变量。
2. 安全性和合规性框架
   • 需要预定义的安全性和合规性策略，通过自动化测试和验证来强制执行。这可能包括使用 Chef InSpec、OpenSCAP 或 HashiCorp Sentinel 等工具在镜像部署期间强制执行策略。
3. 涉及的应用程序必须与不可变基础设施兼容。

背景和最佳实践

传统的补丁管理方法通常是手动且被动的，这会产生一些问题

• 手动配置过程中的人为错误
• 补丁和配置过期的跟踪盲点
• 解决漏洞的漫长周期
• 由于云变化的快速步伐而增加的风险暴露

HashiCorp 的不可变基础设施方法用自动重铺取代了手动打补丁，确保每个部署的实例都一致运行最新的安全镜像。通过在 30 天内定期重铺所有镜像，可以降低漏洞被利用的风险。如果漏洞已被利用，并且攻击者已经建立了在组织内横向移动的机制，重铺将消除这些入侵，而原地打补丁可能会将其保留。

使用 Packer 集中化镜像管理

使用 Packer 集中化镜像管理，通过不可变镜像实现可扩展部署。平台团队管理安全一致的基础镜像，而开发人员构建应用程序镜像，以基础镜像作为起点，然后根据其应用程序需求进行调整。

• 平台团队应定义基础镜像要求，包括操作系统、安全补丁和必需的软件包。
• 使用 Packer 自动化基础镜像的创建。Packer 模板应进行版本控制，以确保可追溯性和可重复性。
• 将自动化测试集成到 Packer 构建过程中，以验证镜像。
• 使用 HashiCorp Sentinel 等工具进行策略即代码，以强制执行合规性。

自动化构建测试

在 Packer 构建阶段集成自动化测试，以在跨环境推广之前确保镜像的质量和可靠性。这降低了部署失败的风险并优化了资源利用。与 CI/CD 流水线集成时，它可自动化测试并确保只有经过验证的镜像才能跨环境传播。

30 天漏洞管理周期

本方法的核心是不可变基础设施，其中实例定期使用最新的安全镜像进行重铺（重新创建），从而在漏洞被利用之前将其消除。

自动化最佳实践

要充分利用 VPM 工作流，请采用以下自动化最佳实践

• 集成 CI/CD 流水线
  • 使用 GitHub Actions 或兼容的 CI/CD 工具自动化 Packer 构建。
  • 在特定的 Git 事件（例如，标签、发布）上触发构建，以确保只有经过验证的更改才会被部署。
• 使用 Webhook 进行通知
  • 配置 Webhook，以便在检测到漂移时立即通知工作区所有者。
  • 根据 Webhook 事件自动化重新部署，以最大程度地缩短响应时间。
• 实施 Sentinel 策略以实现合规性
  • 编写 Sentinel 策略以阻止部署不符合要求的镜像或基础设施。
  • 在 CI/CD 流水线中包含合规性检查，以便及早发现策略违规。

安全性和合规性注意事项

为维护安全合规的基础设施，请遵循以下指南

• 使用 InSpec、OpenSCAP 或 Ubuntu Security Guide (USG) 等工具验证所有镜像是否符合要求的安全标准。
• 使用 HashiCorp Sentinel 在整个镜像构建和部署生命周期中强制执行合规性。
• 集成 CVE 监控工具，以分类和优先处理漏洞以便进行修复。

镜像管理指南

集中的镜像管理流程包括基础镜像和应用程序镜像，最好在同一个存储库中。如果无法实现单个存储库，建议由同一团队管理这些镜像，以确保一致性和控制。

集中式方法允许应用程序团队通过向中央存储库发出拉取请求来做出贡献。这种方法有效地让应用程序团队参与镜像更新过程，从而在更新基础镜像时减轻了过时应用程序镜像的风险。

分散式方法（其中基础镜像集中管理，但应用程序团队维护其自己的应用程序镜像存储库）在人员管理方面存在挑战，例如确保应用程序团队及时发出通知和更新。

对于刚开始进行镜像管理的团队，建议采用集中式方法。通过集中管理，您可以控制更新过程，确保基础镜像和应用程序镜像在同一个存储库中得到一致的更新。

经过验证的架构

该架构包含一个自动化流水线，旨在简化基础设施和应用程序镜像的 30 天周期。此流水线包括镜像构建、基础设施部署和合规性验证等不同阶段，每个阶段都经过协调，以确保部署的效率、一致性和安全性。

以下各节将介绍架构的组成部分。

• 流水线始于使用 HashiCorp Packer 自动化创建基础设施镜像。预定义了配置，以确保镜像的一致性并满足基线标准。
• 使用 Packer 将所有镜像发布到 HCP Packer 工件注册表并安排撤销。
• Packer 模板的合并频率低于双周一次，但仅在 git 标签和发布时触发 CI 流水线运行 Packer 构建。
• 使用 HCP Terraform Explorer 跟踪和更新所有发生漂移的 HCP Terraform 工作区。
• 流水线自动化基础设施的配置和部署。
• 流水线执行合规性检查和安全扫描，以验证基础设施和已部署的应用程序均符合组织合规性要求。
• 任何不合规的元素都会触发警报，并且根据配置，可以阻止流水线继续进行，以防止潜在风险。

该架构专为持续集成和交付 (CI/CD) 环境设计，支持 30 天重铺周期，同时确保每次构建和部署都符合安全和合规性标准。通过自动化镜像构建、部署和合规性验证，您可以减少手动干预，降低运营风险，并提高整体基础设施的可靠性。

人员和流程考量

《Terraform：平台运营的指导手册》包含关于平台运营人员和流程建议的广泛讨论。

VPM 工作流

此工作流演示了从镜像创建到基础设施更新的完整 VPM 生命周期，使用了 HCP Packer 和 HCP Terraform。

VPM 工作流可细分为以下步骤

1. 将存储库导入版本控制
2. 配置 HCP 和 HCP Terraform
3. 创建 Packer 镜像并更新 HCP Packer 通道配置
4. 使用 Packer 镜像部署测试基础设施
5. 更新 Packer 镜像并更新 HCP Packer 通道配置
6. 验证漂移检测是否发出漂移警报并使用新镜像更新已部署的测试基础设施

将存储库导入版本控制

将 VPM 工作流所需的两个存储库导入到您的版本控制系统 (VCS) 中

• HashiCorp VPM 存储库
• HashiCorp VPM GitHub Actions Packer 存储库

1. 从两个存储库下载最新的发布 ZIP 文件
2. 将内容导入到您的 VCS 中
3. 创建具有访问您的 VPM 存储库权限的 GitHub Oauth 令牌

初始 HCP 和 HCP Terraform 配置

在 HCP 和 HCP Terraform 中创建必要项目、服务主体和工作区。

1. 为 VPM 环境创建 HCP 组织

2. 创建具有“Contributor”角色和“Organization-level”范围的服务主体 hcp-admin-sp

3. 为服务主体生成密钥（client ID 和 client secret）

4. 创建 HCP Terraform 组织

5. 为 Owners 团队生成 Team API 令牌

6. 创建用于 HCP 管理凭据的变量集，并激活选项在此变量集中优先变量值

7. 在变量集中定义以下变量

   键	值	类别	敏感
   HCP_CLIENT_ID	hcp-admin-sp 服务主体的客户端 ID	环境变量	有
   HCP_CLIENT_SECRET	hcp-admin-sp 服务主体的客户端密钥	环境变量	有
   TF_VAR_HCP_CLIENT_ID	hcp-admin-sp 服务主体的客户端 ID	环境变量	有
   TF_VAR_HCP_CLIENT_SECRET	hcp-admin-sp 服务主体的客户端密钥	环境变量	有
   TFE_TOKEN	Owners 团队 API 令牌	环境变量	有

   注意

   引导代码期望此变量集名为 HCP management credentials。如果您决定使用其他名称，请为变量 hcp_credentials_vs_name 提供备用名称作为参数值。

8. 配置 VCS 提供商，以便您的 HCP Terraform 组织可以访问您之前导入的 GitHub 存储库

引导环境

《HashiCorp VPM Repository》中的代码分为四个部分

在初次部署 VPM 环境时，您必须按以下顺序执行代码

1. 位于 bootstrap 目录中的代码
2. 位于 hcp-configuration 目录中的代码
3. 位于 hcp-terraform-configuration 目录中的代码

虽然 bootstrap 代码仅用于一次性使用，但其他两个目录中的代码可以作为长期存在的 HCP 和 HCP Terraform 配置的基础。

《pov-infrastructure》代码依赖于另一个存储库 HashiCorp VPM GitHub Actions Packer Repository，该存储库用于定义 Packer 模板和示例 GHA 工作流，以自动化 Packer 镜像的创建。

本文档中的说明假设您将 GitHub 作为您的 VCS 和 CI/CD 平台。但是，集成相对简单，适应到其他解决方案应该很容易实现。

引导 HCP Terraform

1. 在 Default Project 中创建一个新的工作区

   • 出现提示时，选择VCS 驱动的工作流
   • 选择您的 GitHub VCS 提供商
   • 选择您导入此设置配置的存储库
   • 将工作区名称设置为 hcp-bootstrap
   • 将 Terraform 工作目录设置为 bootstrap
   • 点击创建

2. 出现提示时，设置以下变量（将 vcs_repo_identifier 设置为指向导入的存储库）

   变量名称	值	类别	敏感	HCL
   github_oauth_token	\<OAuth 令牌>	terraform	有	没有
   hcp_configuration	{ workspace_name = "hcp-configuration" vcs_repo_branch = "main" working_directory = "hcp-configuration" vcs_repo_identifier = "owner/repository" }	terraform	没有	有
   hcp_terraform_configuration	{ workspace_name = "hcp-terraform-configuration" vcs_repo_branch = "main" working_directory = "hcp-terraform-configuration" vcs_repo_identifier = "owner/repository" }	terraform	没有	有
   vpm_pov_deploy_repo_identifier	(将其设置为此存储库的 git 存储库标识符，格式为 owner/repository)	terraform	没有	没有

3. 更新 HCP management credentials 变量集，以将其应用于此新工作区

4. 触发 Terraform 运行

《bootstrap》代码将

• 在 HCP Terraform 中创建一个项目，用于管理用于配置 HCP 和 HCP Terraform 的工作区。
• 将具有 HCP 管理凭据的变量集应用于该项目。
• 创建一个工作区来管理 HCP 配置，并将其链接到适当的 git 存储库。
• 创建一个工作区来管理 HCP Terraform 配置，并将其链接到适当的 git 存储库。

配置 HCP

1. 设置工作区变量
   • 如有必要，请设置工作区变量以覆盖默认值。
   • 检查 Inputs 部分中的默认值。
2. 应用配置
   • 访问 hcp-configuration 项目中的 hcp-configuration 工作区。
   • 启动 Terraform 运行
   • 验证所选的运行类型为Plan and Apply（标准）。

《hcp-configuration》代码将

• 为 VPM PoV 创建一个 HCP 项目。
• 创建一个项目级别的服务主体，用于创建和维护 Packer 镜像。
• 将 Contributor 角色分配给该服务主体。
• 创建一个项目级别的服务主体，用于查询 HCP Packer 注册表实例中的可用镜像。
• 将 Viewer 角色分配给该服务主体。
• 在 VPM PoV 的 HCP 项目中创建一个 HCP Packer 注册表。
• 配置所需的镜像存储桶和通道。

配置 HCP Terraform

1. 配置 AWS 访问
   • 创建 AWS OIDC 身份提供商以供 HCP Terraform 使用将需要具有足够权限的 AWS 凭据。
   • 您必须配置工作区以提供这些权限
     • 如果工作区使用远程执行模式，则可以使用静态凭据（请参阅教程 创建凭据变量集）
     • 如果工作区使用代理执行模式，则可以使用静态凭据或使用 IAM 角色（请参阅 代理身份验证）。
2. 设置工作区变量。如有必要，请设置工作区变量以覆盖默认值。检查 Inputs 部分中的默认值。
3. 应用配置
   • 访问 hcp-configuration 项目中的 hcp-terraform-configuration 工作区。
   • 启动 Terraform 运行
     • 验证选择的运行类型为 Plan and Apply（标准）。

《hcp-terraform-configuration》代码将

• 创建一个 HCP Terraform 项目来部署 VPM 工作流基础设施。
• 为 HCP Terraform 创建一个 AWS OIDC 身份提供商。
• 创建一个包含 AWS 动态凭据参数的变量集，并将其应用于该项目。
• 创建一个包含 HCP Packer 存储桶信息的变量集，并将其应用于该项目。
• 配置一个名为 HCP-Packer-VPM 的运行任务，并将其与之前创建的 HCP Packer 注册表关联。
• 在上述 HCP Terraform 项目下创建工作区以部署 VPM 基础设施。为每个工作区配置 HCP-Packer-VPM 运行任务（运行阶段设置为 Post-Plan，强制级别设置为 Advisory）。
• 创建一个管理员团队和一个开发人员团队，分别分配相应的权限，作为可能职责委托的示例。

构建初始 Packer 镜像

VPM 工作流使用 Packer 来构建和更新镜像。 《HashiCorp VPM GitHub Actions Packer Repository》包含 GitHub Action 工作流 (.github/workflows/)、Packer 流水线 (packer/) 和 Ansible 剧本 (ansible/) 来支持 VPM 工作流。

该代码包括 CI/CD 配置，用于自动化镜像的创建。此配置旨在与 GitHub Actions 一起使用。如果您使用不同的 CI/CD 系统，则必须将流水线配置移植到该系统。

GitHub Actions 工作流

位于 .github/workflows 中的三个工作流负责运行 Packer（与 HCP Packer 集成）。基础镜像工作流基于月度 cron 时间表或仓库推送触发。下游的 NGINX 和 MySQL 流水线由基础工作流成功完成新构建后执行的 Webhook 触发。这些工作流已针对 paths 和/或 ignore-paths 设置了默认值，以避免过多的流水线执行。

首先，构建 Packer 镜像。

1. 创建以下 GitHub Actions 变量

   目录	描述
   AWS_REGION	AMI 镜像的 AWS 区域
   AWS_GITHUB_ROLE_ARN	要承担的 AWS IAM 角色
   HCP_PROJECT_ID	Packer 注册表所在的 HCP 项目
   HCP_PACKER_BUCKET_BASE_NAME	要创建的 Packer 存储桶的名称
   PACKER_IMAGE_OWNER	Packer 镜像的元数据

   您可以手动设置这些变量，或使用 gh CLI。要使用 gh CLI，请首先创建一个定义了变量的文件（例如，命名为 repo_vars.env）

   AWS_REGION=<insert target AWS region>
   AWS_GITHUB_ROLE_ARN=<insert AWS IAM role to assume>
   HCP_PROJECT_ID=<insert HCP project ID for the HCP Packer registry>
   HCP_PACKER_BUCKET_BASE_NAME=<insert HCP Packer bucket name>
   PACKER_IMAGE_OWNER=<insert image owner>
   

   然后，在您的系统上从 git 存储库目录执行命令

   $ gh variable set -f repo_vars.env
   

2. 创建以下 GitHub Actions 机密

   机密名称	描述
   HCP_CLIENT_ID	HCP 服务主体客户端 ID
   HCP_CLIENT_SECRET	HCP 服务主体客户端密钥
   GH_PAT	具有触发工作流权限的 GitHub PAT

   根据 AWS 的配置方式，可能还需要其他机密。如果使用静态凭据，可以定义以下附加机密

   机密名称	描述
   AWS_ACCESS_KEY_ID	与 IAM 账户关联的 AWS 访问密钥 ID
   AWS_SECRET_ACCESS_KEY	与 IAM 账户关联的 AWS 密钥访问密钥
   AWS_SESSION_TOKEN	AWS 会话令牌

   请参阅 GitHub 的“配置 AWS 凭据”操作，了解使用 AWS 进行身份验证的推荐方法。

3. 使用 GitHub 存储库中的 Packer 模板构建基础镜像。

4. 创建镜像后，将版本分配给镜像存储桶的production通道。

   注意

   Terraform 代码部署的测试基础设施“订阅”了镜像存储桶的 production 通道。如果未将镜像版本分配给该通道，Terraform 配置将没有 AMI ID 可用，部署将失败。

此存储库中演示了四种示例流程

1. x86_64 Ubuntu 基础镜像，源自 Amazon，并应用了 CIS Level 1 基准
2. x86_64 Ubuntu 基础镜像，使用 Ansible 另外部署了 NGINX
3. x86_64 Ubuntu 基础镜像，使用 Ansible 另外部署了 MySQL
4. x86_64 RHEL 9.3 基础镜像，源自 Amazon，并应用了 CIS Level 1 基准

每个生成的镜像都部署到配置的 AWS 账户中，作为可用于计算配置的 AMI，并注册到 HCP Packer。

CIS Level 1 基准

由于 AWS/AMI 的要求，基准修复可能无法实现 100% 的 CIS Level 1 基准合规性。如有需要，可在 /var/lib/usg 处检查每个缓解过程的结果。

自定义

可以通过复制和修改模板化流水线和/或剧本来实现此存储库的自定义。基础镜像可以很容易地通过额外的 shell provisioner 进行补充，或者通过取消注释 Ansible provisioner 来包含安全代理或其他要求。基础镜像有一个相应的空剧本和需求文件，默认情况下未使用，并且可以根据需要启用。

使用 Terraform 部署测试基础设施

一旦创建了 Packer 镜像并将v1版本分配给镜像存储桶的production通道，下一步就是部署测试基础设施。

1. 验证 HCP Terraform 配置是否允许工作区配置云基础设施。这可以通过多种方式完成（静态凭据、动态凭据等），并且可以在工作区级别或项目级别进行配置（首选）。
2. 在每个工作区上执行 terraform apply 操作，以配置所需资源（例如，Nginx 和 MySQL VM）。
3. 部署后，等待健康检查和漂移检测报告完成，并确认没有标记的问题。

更新 Packer 镜像和通道

一旦更新了 Packer 镜像并将v2版本分配给镜像存储桶的production通道，下一步就是重新部署测试基础设施。

1. 更新 Packer 模板以解决漏洞。
2. 使用 CI/CD 流水线重新构建更新后的镜像。
3. 将新镜像版本分配给镜像存储桶的生产通道。
4. 撤销带有漏洞的镜像版本。

解决漂移并重新部署基础设施

当新镜像版本分配给镜像通道时，HCP Terraform 会检测到漂移。

1. 手动启动相关工作区内的健康检查运行，以避免等待下一个计划的健康检查（可能太遥远）。
2. 健康检查完成后，请在 HCP Terraform 中查看漂移检测报告，确认镜像版本更改已被检测为漂移。
3. 确认检测到漂移后，在 vpm-pov 项目内的相关工作区中启动 terraform apply。此操作将重新部署基础设施，更新虚拟机以使用新镜像。
4. 等待 terraform apply 成功完成。验证所有更新是否都已应用且没有错误，并且虚拟机现在正在使用新镜像。
5. 更新工作区后，触发新的健康检查，以确认漂移检测报告未显示任何问题，从而验证基础设施是最新的。

错误处理和调试

以下各节提供了有关 Packer 构建和 Terraform 部署过程中错误处理和调试的指南。

Packer 构建失败

• 使用 Packer post-processors 对构建的镜像运行测试。例如，您可以使用 shell-local post-processor 在镜像构建后本地执行测试脚本。
• 实施 Inspec 或 Serverspec 等测试框架，以验证镜像的配置和功能。这些工具可用于编写测试，确保您的镜像符合要求。
• 在运行 packer build 时使用 -on-error=ask 选项。这允许您选择在发生错误时是否清理或调试构建过程。这对于交互式调试特别有用。
• 如果遇到问题，请使用 -debug 标志重新运行构建。这将暂停每个步骤的构建过程，让您检查和排查环境。
• 在出错的情况下，您可以 SSH 进入暂存的 VM 以在本地排查 provisioner 脚本。这有助于识别日志中可能不明显的问​​题。
• 将 Packer 构建与 CI/CD 流水线集成。这使您可以自动化测试过程，并确保只有通过所有测试的镜像才能提升到下一个环境。

Terraform 部署问题

• 验证 IAM 角色和权限，确保 Terraform 能够访问云资源。
• 在应用更改之前运行 terraform plan 以识别配置错误。
• 如果部署失败，请查看漂移检测报告中的不一致之处。

结论

使用 HCP Packer 和 HCP Terraform 的 30 天重铺周期提供了可扩展的、主动的漏洞管理解决方案。通过自动化镜像创建、基础设施部署和漂移检测，该方法缩短了漏洞暴露窗口，同时确保了持续的合规性。

此 VPM 策略不仅加强了您组织的安全性，而且通过将手动补丁管理转向不可变基础设施，还减少了运营开销。

完成本教程后，请考虑以下后续步骤

• 自定义 Packer 模板和 Terraform 模块，以符合您组织的结构需求。
• 计划定期漂移检测，以及早识别和解决不一致之处。
• 集成其他工具和框架，以进一步简化补丁管理。
• 在将工作流迁移到生产环境时，执行更严格的合规性规则。

查看以下资源以获取更多信息

• HashiCorp验证设计
• HCP
  • 创建 HCP 帐户
  • 创建组织
  • 服务主体
  • HCP Packer 概述
  • HCP Terraform 和 Packer 集成
• HCP Terraform
  • 入门 - HCP Terraform
  • API 令牌
  • Owners 团队
  • 变量 (Variables)
  • 创建凭据变量集
  • 将 VCS 提供商连接到 HCP Terraform

• 最佳实践和配置
  • Packer 最佳实践
  • Terraform 配置​​文件设置
  • 使用 GitHub Actions 自动化 Packer

• CI/CD 部署模式
  • 远程模板和性能
• 测试和调试
  • 单元测试和调试
  • 调试技术
• 使用 HCP Packer 进行工件管理
• Packer 的 Git 集成
• HCP Packer 入门
• 构建/测试示例
  • DevSec PostgreSQL 基线测试
  • DevSec SSH 基线测试
  • SSL 基线测试
  • DevSec Nginx 基线测试