使用 Terraform 在企业规模上设置集中式日志记录 - AWS Prescriptive Guidance

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

使用 Terraform 在企业规模上设置集中式日志记录

Aarti Rajput、Yashwant Patel 和 Amazon Web Services 的 Nishtha Yadav

摘要

集中式日志记录对于组织的云基础架构至关重要,因为它提供了对其运营、安全性和合规性的可见性。随着您的组织跨多个账户扩展其 AWS 环境,结构化的日志管理策略成为运行安全操作、满足审计要求和实现卓越运营的基础。

这种模式提供了一个可扩展的安全框架,用于集中来自多个 AWS 账户 和服务的日志,从而在复杂 AWS 的部署中实现企业级日志管理。该解决方案使用Terraform实现自动化,Terraform是一种基础设施即代码(IaC)工具,可 HashiCorp 确保一致和可重复的部署,并最大限度地减少手动配置。通过结合亚马逊 CloudWatch 日志、Amazon Data Firehose 和亚马逊简单存储服务 (Amazon S3) Service,您可以实施一个强大的日志聚合和分析管道,该管道可提供:

  • 在整个组织中集中管理日志 AWS Organizations

  • 使用内置安全控件自动收集日志

  • 可扩展的日志处理和持久存储

  • 简化的合规报告和审计跟踪

  • 实时运营洞察和监控

该解决方案通过日志收集来自亚马逊 Elastic Kubernetes Service(Amazon EKS) AWS Lambda 容器、函数和亚马逊关系数据库服务(Amazon RDS)数据库实例的日志。 CloudWatch 它使用 CloudWatch 订阅过滤器自动将这些日志转发到专用的日志帐户。Firehose 管理着通往亚马逊 S3 的高吞吐量日志流管道,用于长期存储。亚马逊简单队列服务 (Amazon SQS) Simple Queue Service 配置为在创建对象时接收 Amazon S3 事件通知。这样可以与分析服务集成,包括:

  • 用于日志搜索、可视化和实时分析的 Amazon OpenSearch 服务

  • Amazon Athena 用于基于 SQL 的查询

  • 用于大规模处理的 Amazon EMR

  • 用于自定义转换的 Lambda

  • QuickSight 用于仪表板的 Amazon

所有数据均使用 AWS Key Management Service (AWS KMS) 进行加密,整个基础架构通过使用 Terraform 进行部署,以实现跨环境的一致配置。

这种集中式日志记录方法使组织能够改善其安全状况,保持合规性要求,并优化其 AWS 基础架构的运营效率。

先决条件和限制

先决条件

有关设置 AWS Control Tower、AFT 和应用程序账户的说明,请参阅 Epics 部分

必填账户

您的组织中 AWS Organizations 应包括以下账户:

  • 应用程序账户 — AWS 服务 (Amazon EKS、Lambda 和 Amazon RDS)运行和生成日志的一个或多个源账户

  • 日志存档帐户-用于集中日志存储和管理的专用帐户

产品版本

架构

下图说明了一种 AWS 集中式日志架构,该架构提供了一种可扩展的解决方案,用于收集、处理来自多个应用程序帐户的日志,并将其存储到一个专用的日志存档帐户中。该架构可以有效地处理来自 AWS 服务 Amazon RDS、Amazon EKS 和 Lambda 的日志,并通过简化的流程将这些日志路由到日志存档账户中的区域 S3 存储桶。

AWS 集中式日志架构,用于从多个应用程序账户收集日志。

该工作流程包括五个流程:

  1. 日志流进程

    • 日志流过程从应用程序账户开始,在那里 AWS 服务 生成各种类型的日志,例如来自 Amazon RDS 的常规日志、错误日志、审计日志、慢速查询日志、来自 Amazon EKS 的控制平面日志以及来自 Lambda 的函数执行和错误日志。

    • CloudWatch 用作初始收集点。它在每个应用程序帐户中的日志组级别收集这些日志。

    • 在中 CloudWatch,订阅筛选器决定应将哪些日志转发到中央账户。这些过滤器可让您精细控制日志转发,因此您可以指定确切的日志模式或完整的日志流进行集中化。

  2. 跨账号日志传输

    • 日志将移至日志存档帐户。 CloudWatch 订阅过滤器便于跨账户转账并保留区域背景。

    • 该架构建立了多个并行流,以有效地处理不同的日志源,从而确保最佳性能和可扩展性。

  3. 日志存档账户中的日志处理

    • 在日志存档账户中,Firehose 处理传入的日志流。

    • 每个区域都维护专用 Firehose 传输流,可以根据需要转换、转换或丰富日志。

    • 这些 Firehose 流将处理过的日志传送到日志存档账户中的 S3 存储桶,该账户与源应用程序帐户位于同一区域(图中的区域 A),以维护数据主权要求。

  4. 通知和其他工作流程

    • 当日志到达目标 S3 存储桶时,该架构会使用 Amazon SQS 实现通知系统。

    • 区域 SQS 队列支持异步处理,并且可以根据存储的日志触发其他工作流程、分析或警报系统。

  5. AWS KMS 为了安全

    AWS KMS 为了安全起见,该架构包含在内。 AWS KMS 为 S3 存储桶提供加密密钥。这样可以确保所有存储的日志保持静态加密,同时保留区域加密以满足数据驻留要求。

工具

AWS 服务

  • Amazon CloudWatch 是一项监控和可观察性服务,它以日志、指标和事件的形式收集监控和操作数据。它提供了在 AWS 和本地服务器上运行的 AWS 资源、应用程序和服务的统一视图。

  • CloudWatch 日志订阅过滤器是匹配传入日志事件中的模式并将匹配的日志事件传送到指定 AWS 资源以供进一步处理或分析的表达式。

  • AWS Control Tower Account F@@ actory For Terraform (AFT) 设置了 Terraform 管道来帮助你在中配置和自定义账户。 AWS Control Tower AFT 提供基于 Terraform 的账户配置,同时允许您使用来管理您的账户。 AWS Control Tower

  • Amazon Data Firehos e 向亚马逊 S3、亚马逊 Redshift 和亚马逊服务等目的地提供实时流数据。 OpenSearch 它会自动扩展以匹配您的数据吞吐量,并且无需持续管理。

  • Amazon Elastic Kubernetes Service(Amazon EKS)是一项托管容器编排服务,可通过使用 Kubernetes 轻松部署、管理和扩展容器化应用程序。它会自动管理 Kubernetes 控制平面节点的可用性和可扩展性。

  • AWS Key Management Service (AWS KMS) 创建和控制用于加密数据的加密密钥。 AWS KMS 与其他服务集成 AWS 服务 ,以帮助您保护使用这些服务存储的数据。

  • AWS Lambda是一项无服务器计算服务,允许您在不预配置或管理服务器的情况下运行代码。它通过根据每个触发器运行代码来自动扩展您的应用程序,并且仅按您使用的计算时间收费。

  • Amazon Relational Database Service (Amazon RDS) 是一项托管的关系数据库服务,可以轻松地在云中设置、操作和扩展关系数据库。它提供了经济实惠且可调整大小的容量,同时自动执行耗时的管理任务。

  • Amazon Simple Queue Service (Amazon SQS) 是一项消息队列服务,使您能够分离和扩展微服务、分布式系统和无服务器应用程序。它消除了管理和操作面向消息的中间件的复杂性。

  • Amazon Simple Storage Service (Amazon S3) 是一项基于云的对象存储服务,可提供可扩展性、数据可用性、安全性和性能。它可以从网络上的任何地方存储和检索任意数量的数据。

其他工具

  • Terraform 是一款基础设施即代码 (IaC) 工具 HashiCorp ,可帮助您创建和管理云和本地资源。

代码

此模式的代码可在 GitHub集中式日志存储库中找到。

最佳实践

操作说明

Task描述所需技能

使用 AFT 设置 AWS Control Tower 环境。

  1. AWS Control Tower 按照AWS Control Tower 文档中的说明进行部署。

  2. 按照AWS Control Tower 文档中的说明部署 AFT。

AWS 管理员

为组织启用资源共享。

  1. 使用管理账户凭据@@ 配置 AWS Command Line Interface (AWS CLI),这些凭据提供管理权限进行管理 AWS Control Tower。

  2. 使用任意 AWS CLI 命令运行以下命令 AWS 区域:

    aws ram enable-sharing-with-aws-organization

    这样,您就可以 AWS Organizations 跨所有支持 AWS Resource Access Manager (AWS RAM) 的地区在您的组织内部共享资源。

AWS 管理员

验证或配置应用程序帐户。

要为您的用例配置新的应用程序帐户,请通过 AFT 创建这些帐户。有关更多信息,请参阅 AWS Control Tower 文档中的向 AFT 开通新账户

AWS 管理员
Task描述所需技能

Application_account文件夹内容复制到aft-account-customizations存储库中。

  1. aft-account-customizations存储库的根路径Application_account中创建一个名为的文件夹。此存储库是在您设置 AFT 时自动创建的(参见之前的长篇故事)。

  2. 导航到 centralised-logging-at-enterprise-scale-using-terraform 存储库的根目录,复制该aft/account目录的内容,然后将其粘贴到您在aft-account-customizations存储库中步骤 1 中创建的Application_account目录中。

  3. centralised-logging-at-enterprise-scale-using-terraform存储库的根目录中,将该Application_account目录的内容复制到aft-account-customizations存储库的Application_account/terraform目录中。

  4. 在该aft-account-customizations/Application_account/terraform.tfvars文件中,确认所有参数都作为参数传递到相应的 Terraform 配置文件中。

DevOps 工程师

查看和编辑用于设置应用程序帐户的输入参数。

在此步骤中,您将设置用于在应用程序账户中创建资源的配置文件,包括 CloudWatch 日志组、 CloudWatch 订阅筛选条件、IAM 角色和策略以及 Amazon RDS、Amazon EKS 和 Lambda 函数的配置详细信息。

在存储aft-account-customizations库的Application_account文件夹中,根据贵组织的要求配置terraform.tfvars文件中的输入参数:

  • environment:将在其中部署资源的环境的名称(例如proddev、、staging)。

  • account_name:创建资源的 AWS 账户 位置的名称。

  • log_archive_account_id:将日志存档到的 AWS 账户 ID。

  • admin_role_name:将用于管理资源的管理角色的名称。

  • tags:代表要应用于所有资源的常用标签的键值对的映射。

  • rds_config:一个包含 Amazon RDS 实例配置详细信息的对象。

  • allowed_cidr_blocks:允许访问资源的 CIDR 块列表。

  • destination_name:一个变量,用于创建流式传输日志的 CloudWatch 目标的 Amazon 资源名称 (ARN)。

  • rds_parameters:一个包含 Amazon RDS 参数组设置的对象。

  • vpc_config:包含 VPC 配置详细信息的对象。

  • eks_config:一个包含 Amazon EKS 集群配置详细信息的对象。

  • lambda_config:一个包含 Lambda 函数配置详细信息的对象。

  • restrictive_cidr_range:安全组规则的限制 CIDR 范围列表。

  • target_account_id:将在其中部署资源的目标日志存档账户的 AWS 账户 ID。

DevOps 工程师
Task描述所需技能

Log_archive_account文件夹内容复制到aft-account-customizations存储库中。

  1. aft-account-customizations存储库的根路径Log_archive_account中创建一个名为的文件夹,此存储库是在您设置 AFT 时自动创建的。

  2. 导航到centralised-logging-at-enterprise-scale-using-terraform存储库的根目录,复制该aft/account目录的内容,然后将其粘贴到您在上一步中在aft-account-customizations存储库中创建的Log_archive_account目录中。

  3. centralised-logging-at-enterprise-scale-using-terraform存储库的根目录中,将该Log_archive_account目录的内容复制到aft-account-customizations存储库的Log_archive_account/terraform目录中。

  4. 在该aft-account-customizations/Log_archive_account/terraform.tfvars文件中,确认所有参数都作为参数传递到相应的 Terraform 配置文件中。

DevOps 工程师

查看和编辑用于设置日志存档帐户的输入参数。

在此步骤中,您将设置用于在日志存档账户中创建资源的配置文件,包括 Firehose 交付流、S3 存储桶、SQS 队列以及 IAM 角色和策略。

aft-account-customizations存储库的Log_archive_account文件夹中,根据贵组织的要求配置terraform.tfvars文件中的输入参数:

  • environment:将在其中部署资源的环境的名称(例如proddev、、staging)。

  • destination_name:用于创建流式传输日志的 CloudWatch 目标的 ARN 的变量。

  • source_account_ids:允许 AWS 账户 IDs 在日志目标上放置订阅过滤器的列表。您可以输入任意数量的帐户 IDs 以启用集中日志记录。

DevOps 工程师
Task描述所需技能

选项 1-从 AFT 部署 Terraform 配置文件。

在 AFT 中,AFT 管道是在您将包含配置更改的代码推送到 GitHub aft-account-customizations存储库后触发的。AFT 会自动检测更改并启动账户自定义流程。

对 Terraform (terraform.tfvars) 文件进行更改后,提交更改并将其推送到存储aft-account-customizations库:

$ git add * $ git commit -m "update message" $ git push origin main
注意

如果您使用的是其他分支(例如dev),请main替换为您的分支名称。

DevOps 工程师

选项 2-手动部署 Terraform 配置文件。

如果您不使用 AFT 或想要手动部署解决方案,则可以使用Application_accountLog_archive_account文件夹中的以下 Terraform 命令:

  1. 克隆 GitHub 存储库并在terraform.tfvars文件中配置输入参数。

  2. 运行以下命令:

    $ terraform init
  3. 预览更改:

    $ terraform plan

    此命令评估 Terraform 配置以确定资源的所需状态,并将其与基础架构的当前状态进行比较。

  4. 应用更改:

    $ terraform apply
  5. 查看计划中的更改,并在提示时键入 “” 以继续处理应用程序。

DevOps 工程师
Task描述所需技能

验证订阅过滤器。

要验证订阅过滤器是否正确地将日志从应用程序帐户日志组转发到日志存档帐户,请执行以下操作:

  1. 在应用程序帐户中,打开CloudWatch 控制台

  2. 在左侧导航窗格中,选择日志组

  3. 选择每个日志组(/aws/rds/aws/eks/aws/lambda),然后选择 “订阅筛选器” 选项卡。

    根据您在 Terraform 配置文件中指定的名称,您应该会看到指向目标 ARN 的有效订阅筛选器。

  4. 选择任何订阅过滤器以验证其配置和状态。

DevOps 工程师

验证 Firehose 直播。

要验证日志存档账户中的 Firehose 流是否成功处理应用程序日志,请执行以下操作:

  1. 在日志存档账户中,打开 Firehos e 控制台。

  2. 在左侧导航窗格中,选择 Firehos e 直播。

  3. 选择任何 Firehose 直播并验证以下内容:

    • 目标显示正确的 S3 存储桶。

    • 监控” 选项卡显示成功的交付指标。

    • 最近的配送时间戳是最新的。

DevOps 工程师

验证集中式 S3 存储桶。

要验证集中式 S3 存储桶是否正确接收和组织日志,请执行以下操作:

  1. 在日志存档账户中,打开 Amazon S3 控制台

  2. 选择每个中央日志存储桶。

  3. 浏览文件夹结构:AWSLogs/AccountID/Region/Service.

    您应该会看到按时间戳 (YYYY/MM/DD/HH) 组织的日志文件。

  4. 选择任何最近的日志文件并验证其格式和数据完整性。

DevOps 工程师

验证 SQS 队列。

要验证 SQS 队列是否收到有关新日志文件的通知,请执行以下操作:

  1. 在日志存档账户中,打开 Amazon SQS 控制台。

  2. 在左侧导航窗格中,选择 Queues (队列)

  3. 选择每个已配置的队列,然后选择 “发送和接收消息”。

    您应该会看到包含新日志文件的 S3 事件通知的消息。

  4. 选择任意一条消息以验证其是否包含正确的 S3 对象信息。

DevOps 工程师
Task描述所需技能

选项 1-从 AFT 停用 Terraform 配置文件。

当您删除 Terraform 配置文件并推送更改时,AFT 会自动启动资源删除过程。

  1. 导航到aft-account-customizations存储库。

  2. 转到 terraform 目录。

  3. 删除以下文件:

    • modules 目录

    • iam.tf

    • versions.tf

    • variables.tf

    • outputs.tf

    • terraform.tfvars

  4. 清除main.tf文件内容。

  5. 将您的更改推送到存储库:

    # Stage all changes $ git add * # Commit cleanup changes $ git commit -m "Remove AFT customizations" # Push to repository $ git push origin main
    注意

    如果您使用的是其他分支(例如dev),请main替换为您的分支名称。

DevOps 工程师

选项 2 — 手动清理 Terraform 资源。

如果您不使用 AFT 或者想要手动清理资源,请使用Application_accountLog_archive_account文件夹中的以下 Terraform 命令:

  1. 初始化 Terraform 配置:

    $ terraform init

    此命令初始化 Terraform 并确保访问当前状态。

  2. 预览清理更改:

    $ terraform destroy

    此命令评估哪些资源将被销毁,并将所需状态与基础架构的当前状态进行比较。

  3. 运行清理。当系统提示你时,键入 “是” 以确认并运行销毁计划。

DevOps 工程师

故障排除

事务解决方案

CloudWatch 日志目标未创建或处于非活动状态。

请验证以下内容:

  1. 在日志存档账户中,验证目标策略是否包括:

    • 正确的来源账户本金。

    • 正确的操作 (logs:PutSubscriptionFilter)。

    • 有效的目的地 ARN。

  2. 确认 Firehose 直播存在且处于活动状态。

  3. 验证附加到目标的 IAM 角色是否具有 Firehose 的权限。

订阅筛选失败或停留在待处理状态。

请检查以下事项:

  1. 在应用程序账户中,验证 IAM 角色是否具有:

    • 通话权限PutSubscriptionFilter

    • 与 L CloudWatch ogs 的信任关系。

  2. 确认目标 ARN 是否正确。

  3. 查看 CloudWatch 日志以获取特定的错误消息。

Firehose 传送流未显示任何传入记录。

请验证以下内容:

  1. 确认 Firehose IAM 角色是否具有:

    • 写入亚马逊 S3 的权限。

    • 如果启用了加密,则可以访问密 AWS KMS 钥。

  2. 查看以下 CloudWatch 指标:

    • IncomingRecords

    • DeliveryToS3.Records

  3. 验证缓冲区设置和传送配置。

相关资源