2. Terraform 基础回顾：Provider、Resource、Data Source、State 文件管理

在深入构建制品误差预算台账的审计日志采集配置之前，必须牢固掌握 Terraform 的核心抽象模型。本章将系统回顾四大基础概念：Provider（提供者）、Resource（资源）、Data Source（数据源）以及 State（状态文件）。这些概念是后续所有自动化配置的基石。

2.1 Provider：基础设施的驱动引擎

Provider 是 Terraform 与目标 API 交互的桥梁。每个 Provider 负责管理一类基础设施平台（如 AWS、Azure、GCP、Kubernetes、Datadog 等）。在审计日志场景中，我们通常需要同时使用多个 Provider 来协同工作。

Provider 的声明通常位于 Terraform 配置文件的顶部，通过 required_providers 块指定版本和来源。

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    datadog = {
      source  = "DataDog/datadog"
      version = "~> 3.0"
    }
  }
}

provider "aws" {
  region = "us-east-1"
}

provider "datadog" {
   = var.datadog_
  app_key = var.datadog_app_key
}

2.2 Resource：基础设施的声明式定义

Resource 是 Terraform 中最核心的构建块，用于声明性地定义基础设施中的具体对象。每个 Resource 对应一个 API 对象，Terraform 负责将其生命周期（创建、读取、更新、删除）映射到 Provider 的 API 调用。

在审计日志采集配置中，Resource 的典型用法包括：

• 日志组/主题：如 aws_cloudwatch_log_group、aws_sns_topic
• 采集代理配置：如 datadog_logs_archive、aws_cloudtrail
• 存储桶/容器：如 aws_s3_bucket（用于存储审计日志归档）
• IAM 角色/策略：如 aws_iam_role（用于授权日志写入）

# 创建 CloudTrail 用于记录所有管理事件
resource "aws_cloudtrail" "audit_trail" {
  name                          = "sre-audit-trail"
  s3_bucket_name                = aws_s3_bucket.audit_logs.id
  include_global_service_events = true
  is_multi_region_trail         = true
  enable_log_file_validation    = true

  event_selector {
    read_write_type           = "All"
    include_management_events = true
  }
}

# 创建 Datadog 日志归档
resource "datadog_logs_archive" "sre_archive" {
  name = "sre-audit-archive"
  s3_archive {
    bucket = aws_s3_bucket.audit_logs.bucket
    path   = "/datadog-archive/"
  }
}

2.3 Data Source：读取外部基础设施信息

Data Source 允许 Terraform 读取由外部或 Terraform 之外创建的基础设施信息。它不会创建或管理资源，而是提供只读查询能力。在审计日志场景中，Data Source 常用于：

• 获取现有 IAM 策略 ARN 以附加到日志角色
• 查询现有 KMS 密钥 ID 用于日志加密
• 读取 VPC/子网信息以部署日志采集代理
• 获取当前 AWS 账号 ID 或区域信息

# 获取当前 AWS 账号信息
data "aws_caller_identity" "current" {}

# 获取现有 KMS 密钥（用于日志加密）
data "aws_kms_key" "audit_key" {
  key_id = "alias/audit-log-key"
}

# 在 Resource 中引用 Data Source
resource "aws_cloudwatch_log_group" "audit_logs" {
  name              = "/aws/audit/sre-logs"
  kms_key_id        = data.aws_kms_key.audit_key.arn
  retention_in_days = 365

  tags = {
    Environment = "production"
    AccountID   = data.aws_caller_identity.current.account_id
  }
}

2.4 State 文件管理：基础设施的真相来源

State 文件是 Terraform 的核心状态数据库，记录了所有被管理资源的当前状态。它建立了配置代码与实际基础设施之间的映射关系。在审计日志场景中，State 文件本身也是审计对象，需要妥善保护。

State 文件的核心作用：

State 文件管理的最佳实践：

• 远程存储：使用 S3、Azure Storage、GCS 等后端存储 State，避免本地文件丢失
• 状态锁定：启用 DynamoDB（AWS）或 CosmosDB（Azure）实现并发锁定，防止多人同时操作
• 加密传输/存储：启用服务端加密（SSE）和传输层加密（TLS）
• 版本控制：启用 State 文件的版本管理，便于回滚审计配置

# 远程 State 后端配置示例（AWS S3 + DynamoDB）
terraform {
  backend "s3" {
    bucket         = "sre-terraform-state"
    key            = "audit-log-collection/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-state-lock"
  }
}

2.5 核心概念关系图

下图展示了 Provider、Resource、Data Source 和 State 文件之间的协作关系，以及它们在审计日志采集配置中的角色。

2.6 审计日志场景中的概念映射

将上述概念映射到实际的审计日志采集配置中，可以更清晰地理解每个组件的作用：