本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

安全最佳实践

正确管理身份验证、访问控制和安全性对于安全使用 Terraform AWS Provider 至关重要。本节概述了以下方面的最佳实践：

在使用 Terraform 管理 AWS 基础设施时，遵循这些最佳实践有助于增强您的安全状况。

遵循最低权限原则

最低权限是一项基本的安全原则，指的是仅授予用户、进程或系统执行其预期功能所需的最低权限。它是访问控制的核心概念，也是防止未经授权的访问和潜在数据泄露的预防措施。

本节多次强调最低权限原则，因为它直接关系到Terraform如何对云提供商进行身份验证和运行操作，例如. AWS

当您使用 Terraform 配置和管理 AWS 资源时，它代表需要适当权限才能进行 API 调用的实体（用户或角色）行事。不遵循最低权限会带来重大安全风险：

使用 IAM 角色

尽可能使用 IAM 角色代替 IAM 用户，以增强使用 Terraform AWS 提供商的安全性。IAM 角色提供可自动轮换的临时安全证书，无需管理长期访问密钥。角色还通过 IAM 策略提供精确的访问控制。

使用 IAM 策略授予最低权限访问权限

谨慎构建 IAM 策略，确保角色和用户仅拥有其工作负载所需的最低权限集。从空策略开始，然后反复添加允许的服务和操作。要实现这一点，请执行以下操作：

精心构造的策略授予的访问权限刚好足以完成工作负载的职责，仅此而已。在操作层定义操作，只允许对特定资源 APIs 进行所需的呼叫。

遵循这种最佳做法可以缩小影响范围，并遵循职责分离和最小权限访问的基本安全原则。根据需要逐步开始严格和开放访问，而不是开始开放并稍后再尝试限制访问。

假设 IAM 角色进行本地身份验证

在本地运行 Terraform 时，请避免配置静态访问密钥。相反，可以使用 IAM 角色临时授予特权访问权限，而不会暴露长期证书。

首先，创建具有必要最低权限的 IAM 角色并添加信任关系，允许您的用户账户或联合身份担任 IAM 角色。这允许临时使用该角色。

信任关系策略示例：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/terraform-execution"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

然后，运行 AWS CLI 命令 aws sts assume-role 来检索该角色的短期证书。这些证书的有效期通常为一小时。

AWS CLI 命令示例：

aws sts assume-role --role-arn arn:aws:iam::111122223333:role/terraform-execution --role-session-name terraform-session-example

该命令的输出包含访问密钥、密钥和会话令牌，您可以使用这些令牌对以下内容进行身份验证 AWS：

{
    "AssumedRoleUser": {
        "AssumedRoleId": "AROA3XFRBF535PLBIFPI4:terraform-session-example",
        "Arn": "arn:aws:sts::111122223333:assumed-role/terraform-execution/terraform-session-example"
    },
    "Credentials": {
        "SecretAccessKey": " wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
        "SessionToken": " AQoEXAMPLEH4aoAH0gNCAPyJxz4BlCFFxWNE1OPTgk5TthT+FvwqnKwRcOIfrRh3c/LTo6UDdyJwOOvEVPvLXCrrrUtdnniCEXAMPLE/IvU1dYUg2RVAJBanLiHb4IgRmpRV3zrkuWJOgQs8IZZaIv2BXIa2R4OlgkBN9bkUDNCJiBeb/AXlzBBko7b15fjrBs2+cTQtpZ3CYWFXG8C5zqx37wnOE49mRl/+OtkIKGO7fAE",
        "Expiration": "2024-03-15T00:05:07Z",
        "AccessKeyId": "ASIAIOSFODNN7EXAMPLE"
    }
}

AWS 提供者还可以自动处理担任该角色的问题。

担任 IAM 角色的提供商配置示例：

provider "aws" {
  assume_role {
    role_arn     = "arn:aws:iam::111122223333:role/terraform-execution"
    session_name = "terraform-session-example"
  }
}

这会严格在 Terraform 会话期间授予更高的权限。临时密钥不能泄露，因为它们会在会话的最长持续时间后自动过期。

这种最佳做法的主要好处包括与长期访问密钥相比提高了安全性，对角色进行了精细的访问控制以获得最少权限，以及能够通过修改角色的权限轻松撤消访问权限。通过使用 IAM 角色，您还可以避免将机密直接存储在本地脚本或磁盘上，这有助于您在团队中安全地共享 Terraform 配置。

使用 IAM 角色进行亚马逊 EC2 身份验证

当您从亚马逊弹性计算云 (Amazon EC2) 实例运行 Terraform 时，请避免在本地存储长期证书。取而代之的是，使用 IAM 角色和实例配置文件自动授予最低权限权限。

首先，创建具有最低权限的 IAM 角色并将该角色分配给实例配置文件。实例配置文件允许 EC2 实例继承角色中定义的权限。然后，通过指定该实例配置文件来启动实例。该实例将通过附加的角色进行身份验证。

在运行任何 Terraform 操作之前，请验证该角色是否存在于实例元数据中，以确认证书已成功继承。

TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

curl -H "X-aws-ec2-metadata-token: $TOKEN" -s http://169.254.169.254/latest/meta-data/iam/security-credentials/

这种方法可以避免将永久 AWS 密钥硬编码到实例中的脚本或 Terraform 配置中。临时证书可通过实例角色和配置文件透明地提供给 Terraform。

这种最佳实践的主要好处包括提高长期证书的安全性、减少凭证管理开销以及开发、测试和生产环境之间的一致性。IAM 角色身份验证简化了 Terraform 从 EC2 实例运行，同时强制执行最低权限访问权限。

为 HCP Terraform 工作空间使用动态凭据

HCP Terraform 是一项由提供的托管服务 HashiCorp ，可帮助团队使用 Terraform 在多个项目和环境中配置和管理基础架构。在 HCP Terraform 中运行 Terraform 时，请使用动态凭据来简化和保护身份验证。 AWS Terraform 在每次运行时都会自动交换临时证书，无需担任 IAM 角色。

好处包括更轻松地轮换密钥、跨工作空间的集中式凭证管理、最低权限以及取消硬编码密钥。与长期访问密钥相比，依赖经过哈希处理的临时密钥可以提高安全性。

在中使用 IAM 角色 AWS CodeBuild

在中 AWS CodeBuild，使用分配给 CodeBuild 项目的 IAM 角色运行您的构建。这允许每个版本自动继承角色的临时证书，而不是使用长期密钥。

在 HCP Terraform 上远程运行 GitHub 操作

将 GitHub 操作工作流配置为在 HCP Terraform 工作空间上远程运行 Terraform。依赖动态凭证和远程状态锁定，而不是 GitHub 密钥管理。

将 GitHub 操作与 OIDC 配合使用并配置 “ AWS 凭证” 操作

使用 OpenID Connect (OIDC) 标准通过 IAM 联合操作身份。 GitHub 使用 “配置 AWS 证书” 操作将 GitHub 令牌交换为临时 AWS 证书，而无需长期访问密钥。

GitLab 与 OIDC 和 AWS CLI

使用 OIDC 标准通过 IAM 联合 GitLab 身份以进行临时访问。通过依赖 OIDC，您无需直接管理其中的长期 AWS 访问密钥。 GitLab交换凭证 just-in-time，这提高了安全性。根据 IAM 角色中的权限，用户还可以获得最低权限访问权限。

将独一无二的 IAM 用户与传统自动化工具配合使用

如果您的自动化工具和脚本缺乏对使用 IAM 角色的原生支持，则可以创建单个 IAM 用户来授予编程访问权限。最低权限原则仍然适用。最大限度地减少策略权限，并依赖每个管道或脚本使用不同的角色。当您迁移到更现代的工具或脚本时，请开始以原生方式支持角色并逐渐过渡到这些角色。

使用 Jenkins AWS 凭证插件

使用 Jenkins 中的AWS 凭据插件集中配置 AWS 凭据并将其动态注入构建中。这样可以避免在源代码管理中检查机密。

持续监控、验证和优化最低权限

随着时间的推移，授予的额外权限可能会超过所需的最低策略。持续分析访问权限以识别和删除任何不必要的权利。

持续监控访问密钥的使用情况

如果您无法避免使用访问密钥，请使用 IAM 凭证报告来查找超过 90 天的未使用访问密钥，并撤消用户账户和计算机角色中的非活动密钥。提醒管理员手动确认移除在职员工和系统的密钥。

监控密钥使用情况可以帮助您优化权限，因为您可以识别和删除未使用的授权。当您遵循访问密钥轮换的最佳实践时，它会限制凭据的有效期并强制执行最低权限的访问权限。

AWS 提供了多种服务和功能，可用于为管理员设置警报和通知。以下是一些选项：

持续验证 IAM 政策

使用 IAM Access Analyzer 评估附加到角色的策略，并识别任何未使用的服务或已授予的多余操作。实施定期访问审查，以手动验证策略是否符合当前要求。

将现有策略与 IAM Access Analyzer 生成的策略进行比较，并删除所有不必要的权限。您还应该向用户提供报告，并在宽限期过后自动撤销未使用的权限。这有助于确保最低限度的策略仍然有效。

主动且频繁地撤销过时的访问权限可以最大限度地减少在泄露期间可能面临风险的凭证。自动化提供了可持续、长期的凭证卫生和权限优化。遵循这一最佳实践，通过主动对 AWS 身份和资源强制执行最低权限来限制影响范围。

安全的远程状态存储

远程状态存储是指远程存储 Terraform 状态文件，而不是在运行 Terraform 的计算机上本地存储。状态文件至关重要，因为它可以跟踪 Terraform 提供的资源及其元数据。

未能保护远程状态可能会导致严重的问题，例如状态数据丢失、无法管理基础架构、无意中删除资源以及状态文件中可能存在的敏感信息泄露。因此，保护远程状态存储对于生产级 Terraform 的使用至关重要。

启用加密和访问控制

使用亚马逊简单存储服务 (Amazon S3) Simple Service 服务器端加密 (SSE) 对远程静态状态进行加密。

限制对协作工作流程的直接访问

遵循这些准则有助于保护敏感的资源属性，并避免与团队成员的更改发生冲突。加密和严格的访问保护有助于减少攻击面，而协作工作流程可提高工作效率。

使用 AWS Secrets Manager

Terraform 中有许多资源和数据源将秘密值以纯文本形式存储在状态文件中。避免将机密存储在状态下——改用AWS Secrets Manager。

与其尝试手动加密敏感值，不如依靠 Terraform 对敏感状态管理的内置支持。将敏感值导出到输出时，请确保将这些值标记为敏感。

持续扫描基础设施和源代码

持续主动扫描基础架构和源代码，以发现诸如泄露凭据或配置错误之类的风险，以加强您的安全状况。通过重新配置或修补资源来迅速解决发现的问题。

使用 AWS 服务进行动态扫描

使用 Amazon Inspector AWS Security Hub、A mazon Detectiv e 和 Amazon GuardDuty 等 AWS 原生工具跨账户和地区监控预配置的基础设施。在 Security Hub 中安排定期扫描，以跟踪部署和配置偏差。扫描 EC2 实例、Lambda 函数、容器、S3 存储桶和其他资源。

执行静态分析

将诸如 Checkov 之类的静态分析器直接嵌入到 CI/CD 管道中，以扫描 Terraform 配置代码 (HCL)，并在部署之前先发制人地识别风险。这样可以将安全检查移到开发过程的早期阶段（称为向左移动），并防止基础设施配置错误。

确保及时补救

对于所有扫描结果，请根据需要更新 Terraform 配置、应用补丁或手动重新配置资源，确保及时进行修复。通过解决根本原因来降低风险水平。

同时使用基础架构扫描和代码扫描可提供对 Terraform 配置、已配置资源和应用程序代码的分层见解。这通过预防、侦查和被动控制最大限度地提高了风险和合规性的覆盖范围，同时将安全性嵌入到软件开发生命周期 (SDLC) 的早期阶段。

强制执行政策检查

使用诸如 HashiCorp Sentinel 策略之类的代码框架为使用 Terraform 进行基础设施配置提供治理护栏和标准化模板。

Sentinel 策略可以定义对 Terraform 配置的要求或限制，以符合组织标准和最佳实践。例如，您可以使用 Sentinel 策略来：

将策略检查嵌入到 Terraform 配置生命周期中，可以主动执行标准和架构指南。Sentinel 提供共享的策略逻辑，有助于加快开发速度，同时防止未经批准的做法。