Cloud-basedIaCTHM

Introduction

探索基础设施即代码 (IaC) 的基础知识及其在现代云计算中的关键作用。我们将重点介绍使用 AWS CloudFormation 和 Terraform 的基于云的 IaC 用例，这些用例能够以可扩展、高效且安全的方式创建和管理云资源。

学习前提条件

从任务 2 开始，将参考 IaC 简介 房间中定义的概念和工具特性，因此完成这项工作是个好主意！

学习目标

• 了解基于云的 IaC 概念
• 安全的 IaC 实践
• 基于云的 IaC 中的安全注意事项

Terraform 101

Terraform 概述

Terraform 是一种用于配置的基础设施即代码工具，它允许用户在人性化配置文件中定义云和本地资源，该文件可以进行版本控制、重复使用和跨团队分发。Terraform 使用一致的工作流使基础设施的管理变得简单而可靠。此房间中的后续任务将介绍此配置和 Terraform 遵循的工作流。现在，让我们定义一些术语，这些术语对于理解 Terraform 如何配置和管理基础设施至关重要：

Terraform 的架构

现在我们知道了 Terraform 的作用。让我们来看看它是如何完成的。我们将研究 Terraform 的架构：

Terraform Core：顾名思义，Terraform Core 负责核心功能，允许用户使用 Terraform 配置和管理其基础设施。正如 IaC 简介 房间中提到的，Terraform 是一个声明性工具（提醒：这意味着定义了一个期望状态，并且该工具负责确保基础设施满足该期望状态，而不是用户声明实现期望状态所需的每个步骤），为了确保用户基础设施处于期望状态，Terraform Core 从两个来源获取输入：

• Terraform 配置文件：用户在这些配置文件中定义其基础设施的期望状态，换句话说，哪些资源构成了他们所需的基础设施。
• 状态：Terraform 有一个状态文件，用于跟踪已配置基础设施的当前状态。核心组件会根据配置文件中定义的所需状态检查此状态文件，如果存在已定义但未配置的资源（或相反），则会制定计划，说明如何将基础设施从当前状态转变为所需状态。默认情况下，此状态文件称为 terraform.tfstate，存储在 Terraform 运行的同一目录中。

我们可以在上图中看到，Terraform Core 从两个地方获取输入：用户定义的配置文件和 tfstate。如果所需状态（配置文件）与当前状态（tfstate）之间存在任何差异，则将使用提供程序执行所需的操作。

提供商：根据定义的资源，使用不同的提供商执行上述计划。提供商用于与云提供商、SaaS 提供商和其他 API 进行交互。例如，如果定义了像 EC2 实例这样的 AWS 资源，则将使用 AWS 提供商；如果定义了 Kubernetes 集群，则需要 Kubernetes 提供商。

对于 DevSecOps 工程师来说，此工具及其架构具有许多 IaC 工具的优势。Terraform 与其他 IaC 工具最大的不同可能在于能够使用这些提供商跨多个云提供商配置和管理资源。这意味着，如果您使用的基础设施具有 AWS 和 Azure 的基础设施资源，则 Terraform 可以用作多云环境的单一解决方案。这还可以防止供应商锁定，意味着基础设施可以更加灵活。Terraform 的另一个好处是声明性配置语言，它用于在配置文件中定义资源；它很容易理解，并且人类可读的格式使定义过程变得简单而精简。最重要的是，该工具的声明性支持版本控制和变更跟踪实践，允许团队成员在声明和开发基础设施期间进行协作并回滚到以前的基础设施迭代。下一个任务将进一步详细介绍如何定义这些资源。

Terraform Configuration

配置和 Terraform

现在我们知道了 Terraform 是什么以及它是如何工作的，让我们来看看如何使用 Terraform 配置文件定义所需状态。Terraform 配置文件是用一种名为 HCL（HashiCorp 配置语言）的声明性语言编写的，正如所讨论的，它易于理解且易于阅读。这种语言的主要目的是声明资源；这些资源代表基础设施对象。这些资源的组合定义构成了所需的基础设施状态。

为了向您举例说明，作为一名 DevSecOps 工程师，Terraform 配置文件可能如何使用，让我们考虑一个示例，其中我们想要使用 AWS 提供商定义一个简单的 VPC（虚拟私有云）。它看起来像这样：

provider "aws" { 
 region = "eu-west-2" 
}

# Create a VPC
resource "aws_vpc" "flynet_vpc" { 
 cidr_block = "10.0.0.0/16" 
 tags = { 
  Name = "flynet-vpc"
 }
}

代码有什么作用？ 在定义我们的提供商（在本例中为 AWS）后，此资源块用于定义 VPC。我们首先通过声明资源类型（在本例中为“aws_vpc”）来定义资源，然后定义此资源的名称。此示例为“flynet_vpc”。然后开始我们的 资源块，我们在其中定义资源参数。给出的参数将取决于正在定义的资源类型。例如，aws_vpc 将需要 CIDR 块（分配 IP 地址的方法）。我们还定义了可在 AWS 中使用的标签，以帮助实现资源、计费、访问控制等的自动化。

资源关系

有时，资源可能依赖于其他资源。定义具有依赖关系的资源时，将引用其所依赖的资源。例如，如果您被分配了一项任务来定义 AWS 安全组入口规则，允许从 VPC 内的任何源进行 SSH 访问，则您需要将以下代码块添加到配置文件中。

resource "aws_security_group" "example_security_group" {
 name = "example-security-group"
 description = "Example Security Group"
 vpc_id = aws_vpc.flynet_vpc.id #Reference to the VPC created above (format: resource_type.resource_name.id)

 # Ingress rule allowing SSH access from any source within the VPC
 ingress {
  #Since we are allowing SSH traffic , from port and to port should be set to port 22
  from_port = 22
  to_port = 22
  protocol = "tcp"
  cidr_blocks = [aws_vpc.flynet_vpc.cidr_block]
 }
}

代码有什么作用？ 在这里，您可以看到我们有一个资源块，它定义了一个 AWS 安全组（通过控制允许流量进入 EC2 计算机的方式来帮助保护 AWS 环境），它允许从 VPC 内的任何来源进行 SSH 访问。您可以在注释行中看到如何配置它以及如何从另一个资源块中引用资源。

基础设施模块化

作为 DevSecOps 工程师，您可能会使用大型、复杂的基础设施。Terraform 的另一个好处是它允许对基础设施进行模块化，也就是说，可以将基础设施分解并定义为模块化组件，而不是放在一个地方。这是大型组织中的常见做法，因为它简化了复杂基础设施配置的管理。让我们看看上面的示例配置是什么样子的。下面是目录“/tfconfig”及其中的文件的表示，并附有简短的注释来解释每个文件的用途：

tfconfig/
 -flynet_vpc_security.tf #Like mentioned, instead of having all resources defined in one file, resources can be paired up and defined in separate modular files
 -other_module.tf
 -variables.tf #some values will be used across two or many infrastructure modules, so instead of declaring these repeatedly in each .tf file it makes sense to paramaterise them in a file called variables.tf. These variables can then be directly referenced in the .tf file.
 -main.tf #main.tf acts as the central configuration file where the defined modules are all referenced in one place

如果我们考虑上面给出的例子，如果我们要使用这个结构定义一个 vpc，它可以像这样配置：

variables.tf

variable "vpc_cidr_block" {
 description = "CIDR block for the VPC"
 type = string #Set the type of variable (string,number,bool etc)
 default = "10.0.0.0/16" # Can be changed as needed
}

我们定义 VPC 的方式与本任务开始时相同，只是现在我们将其存储在 variables.tf 文件中。我们这样做是为了可以重用/引用它。这可以在任何 module.tf 文件中引用，例如，下面，我们有一个名为 flynet_vpc_security 的模块的代码块：

flynet_vpc_security.tf

cidr_block = var.vpc_cidr_block 
#Variable can be referenced using var. followed by variable name
Finally, this module (and all other module tf files) would be collected and referenced in the main.tf file like so:

main.tf

module "flynet_vpc_security" {
 source = "./flynet_vpc_security.tf" 
 #where module is defined (relative to current file)
}

module "other_module" {
 source = "./Other_module.tf"
}

考虑到我们示例中的基础设施设置多么原始，这种组织级别可能非常极端。但是，这是为了向您展示如何在较大的组织/公司中配置大规模基础设施。

Terraform Workflow

了解 Terraform 工作流

Terraform 工作流通常遵循四个步骤：编写、初始化、规划和应用。为了更好地理解此工作流以及它如何在配置基础设施时使 DevSecOps 工程师受益，让我们考虑开发过程中不同阶段的基础设施。在处理基础设施配置时，您往往会在不同阶段遇到不同的问题。为了说明这一点，让我们考虑三个时间点的 Terraform 工作流：

• 第 1 天（基础设施尚不存在，需要从头开始配置）
• 第 2 天及以后（基础设施已存在，但需要进行一些更改）
• 第 N 天（不再需要此基础设施的未定义时间点）

第 1 天

让我们看看 Terraform 工作流在基础设施配置的第一天是什么样子。您有一个没有设置基础设施的空环境，需要定义和配置此基础设施。使用 Terraform，您将遵循以下工作流程：

• 写入：在此部分工作流程中，您将在 Terraform 配置文件中定义基础设施的所需状态。如上一个任务中所述，这些配置文件用于定义所需组件，如果这些组件有关系，它们可以相互引用。

• 初始化：工作流程的下一部分是初始化。init 命令准备您的工作区（Terraform 配置文件所在的工作目录），以便 Terraform 可以应用您的更改。此准备包括下载依赖项等，例如，如果您的配置文件将“aws”定义为提供程序，则在初始化期间，Terraform 将下载 aws 提供程序插件。这是使用以下命令完成的：terraform init

• 计划：初始化工作区后，您现在应该计划您的更改。规划阶段考虑当前存在的基础设施（由于是第 1 天，因此不存在任何基础设施）与期望状态，并准备一个行动计划，如果应用该计划，将使基础设施与期望状态相匹配。它生成此执行计划，并会告诉用户在此过程中将添加/销毁哪些组件。这是使用以下命令完成的：terraform plan

• 应用：应用操作，将基础设施从当前状态转变为期望状态所需的步骤（计划中详细说明）。Terraform 会确定应按什么顺序创建这些基础设施资源。在我们上一个任务的示例中，我们定义了两个资源：VPC 和安全组。由于安全组引用 VPC 并因此依赖于它，因此 Terraform 将首先创建 VPC。这是使用以下命令完成的：<terraform apply

第 2 天及以后

第 2 天及以后是指基础设施配置后的任何一天；对现有基础设施进行更改时，工作流程会是什么样子？比如说，您想向基础设施添加一个组件。

• 初始化：在对基础设施配置进行任何更改后，应该首先运行 terraform init 命令。它将初始化工作区，就像从头开始创建基础设施一样。

• 计划：Terraform 计划不是必需的，但却是最佳实践，尤其是在已经存在的基础设施中。由计划命令生成的执行计划将向您准确显示正在从基础设施中删除或添加的内容。这可以在应用任何错误配置并破坏任何内容之前捕获它们。在这种情况下，计划将评估现有基础设施，并注意现有组件与所需状态匹配，因此无需进行任何更改，但尚未创建其他组件，需要创建以匹配所需状态，因此将被列为需要添加的资源。

• 应用：同样，Terraform 将使用在计划阶段制定的执行计划来配置定义的基础设施更改（请注意，如果您跳过计划阶段，Terraform 将自动创建一个执行计划，就像您已经创建了一样，并会要求您在执行之前批准该计划）。然后，状态文件将更新以反映当前状态现在与所需状态相匹配，因为已添加/配置了附加组件。

第 N 天

第 N 天表示未来不再需要基础设施的一天。也许它只是一个测试环境，或者它支持的应用程序已被搁置。既然不再需要这个基础设施，只需销毁它即可。

• 销毁：运行 terraform destroy 命令将处理此问题。从功能上讲，destroy 命令与 apply 命令非常相似，因为它采用一个计划（Terraform 在运行此命令时制定的销毁计划）并将其与当前存在的基础设施进行比较，并执行该计划的操作，而不是配置/取消配置资源发生变化，它会摧毁所有资源。

Cloudformation 101

CloudFormation 概述

CloudFormation 是一种用于自动配置和资源管理的 Amazon Web Services (AWS) IaC 工具。您可以使用 CloudFormation 模板以“声明性”方式描述您的基础设施，而无需通过 AWS 管理控制台或使用 AWS 命令行界面 (CLI) 手动配置资源。

声明性基础设施即代码

借助 CloudFormation，您可以使用 JSON 或 YAML 模板表达基础设施的期望状态。此模板定义资源、资源配置以及资源之间的关系。CloudFormation 提供和管理这些资源，使管理和复制基础设施更加容易。

模板和堆栈

CloudFormation 模板是一个文本文件，可作为您基础设施的蓝图。它包含描述各种 AWS 资源（如 EC2 实例、S3 存储桶等）的部分。当您使用模板创建资源时，它会形成一个 CloudFormation 堆栈。堆栈是 CloudFormation 的基本单元，它们代表一起创建、更新和删除的 AWS 资源集合。

示例

# CloudFormation Template
AWSTemplateFormatVersion: '2010-09-09'  # Version of the CloudFormation template syntax

Description: 'A simple CloudFormation template'  # Description of the template

Resources:  # Section where AWS resources are defined
  MyEC2Instance:  # Logical name of the resource
    Type: 'AWS::EC2::Instance'  # Type of AWS resource being created

    Properties:  # Properties specific to the resource type
      ImageId: 'ami-12345678'  # ID of the Amazon Machine Image (AMI) for the EC2 instance
      InstanceType: 't2.micro'  # Type of EC2 instance
      KeyName: 'my-key-pair'  # SSH key pair for accessing the instance

  MyS3Bucket:  # Another resource example
    Type: 'AWS::S3::Bucket'
    Properties:
      BucketName: 'my-s3-bucket'  # Name of the S3 bucket

Outputs:  # Section to define outputs for the template
  EC2InstanceId:  # Logical name for the output
    Description: 'ID of the EC2 instance'  # Description of the output
    Value: !Ref MyEC2Instance  # Reference to the EC2 instance resource

• AWSTemplateFormatVersion：指定 CloudFormation 模板版本。
• 说明：提供模板的简要说明。
• 资源：此部分定义要创建的 AWS 资源，例如 EC2 实例或 S3 存储桶。每个资源都有一个逻辑名称 (MyEC2Instance、MyS3Bucket)。类型表示 AWS 资源类型。属性保存资源的配置设置。
• 输出：此部分定义创建堆栈后显示的输出值。逻辑名称、说明和使用 !Ref 的资源引用。

注意：CloudFormation Designer 是一种用于直观地创建/验证这些模板的服务。阅读更多此处。

CloudFormation 架构

与 Terraform 类似，CloudFormation 遵循配置和管理的工作流程。为了更好地理解工作流程，我们需要了解 CloudFormation 及其架构的内部工作原理。

主架构和工作架构

CloudFormation 采用主工作架构。主架构通常是 AWS 中运行的 CloudFormation 服务，负责解释和处理 CloudFormation 模板。它管理整个堆栈创建、更新或删除编排。分布在 AWS 区域的工作节点负责执行资源的实际配置。

模板处理流程

• 模板提交：用户向 CloudFormation 服务提交以 JSON 或 YAML 编写的 CloudFormation 模板。模板指定所需的 AWS 资源及其配置。例如，可以将其存储在 S3 存储桶中。
• 模板验证：CloudFormation 服务验证提交的模板以确保其语法正确并遵循 AWS 资源规范。
• 主节点处理：主节点处理模板，创建一组资源配置指令。它根据依赖关系确定应以何种顺序创建资源。
• 资源配置：主节点与分布在不同 AWS 区域的工作节点进行通信。工作节点执行主节点提供的指令规定的资源的实际配置。
• 堆栈创建/更新：按指定顺序创建或更新资源，形成堆栈。堆栈代表已配置资源的完整集合。

事件驱动模型

CloudFormation 采用事件驱动模型。在堆栈创建、更新或删除过程中生成事件，CloudFormation 会记录这些事件。用户可以监控这些事件以跟踪堆栈操作的进度或识别任何问题。

回滚和回滚触发器

如果在堆栈创建或更新过程中发生错误，CloudFormation 可以自动触发回滚，将堆栈恢复到之前的状态。可以在模板中定义回滚触发器，以指定应发生回滚的条件。

跨堆栈引用

CloudFormation 支持跨堆栈引用，允许一个堆栈中的资源引用另一个堆栈中的资源。这对于管理跨多个堆栈的复杂应用程序和依赖项非常有用。

了解 CloudFormation 的架构可以深入了解该服务如何有效地管理 AWS 资源的编排和配置，从而确保可靠且一致的基础设施部署过程。

CloudFormation Configuration & Use Cases

Configuration and Concepts

模板结构

CloudFormation 模板由以下主要部分组成：

• AWSTemplateFormatVersion：指定 AWS CloudFormation 模板版本。
• 说明：描述模板。
• 参数：您可以在创建或更新堆栈时输入自定义值。
• 资源：定义要创建或管理的 AWS 资源。
• 输出：描述创建或更新堆栈后可以查询的值。

内在函数

CloudFormation 模板支持“内在函数”，可帮助您执行操作。内在函数的示例包括引用资源、执行计算和有条件地包含资源：

Resources:
  MyInstance:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: ami-12345678
      InstanceType: t2.micro

Outputs:
  InstanceId:
    Value: !Ref MyInstance

  PublicDnsName:
    Value: !GetAtt MyInstance.PublicDnsName

  SubstitutedString:
    Value: !Sub "Hello, ${MyInstance}" 

• Fn::Ref : 引用指定资源的值。
• Fn::GetAtt : 从模板中的资源获取属性的值。
• Fn::Sub : 执行字符串替换。

资源依赖关系

CloudFormation 中的资源可以相互依赖。例如，EC2 实例可能依赖于首先创建的 VPC。CloudFormation 会根据这些依赖关系自动处理资源创建和更新的顺序。

变更集

在对堆栈进行更改之前，CloudFormation 允许您使用变更集功能预览更改。这有助于在应用修改之前了解修改的影响。

用例

AWS 中有许多资源配置和管理用例。以下是一些示例：

基础设施配置和管理

CloudFormation 简化了创建和管理 AWS 资源的过程。它确保基础设施部署的一致性和可重复性，从而降低了配置错误的风险。

应用程序生命周期管理

CloudFormation 通常用于管理应用程序的整个生命周期。这包括配置资源、部署应用程序代码以及处理更新或回滚。

多环境部署

通常需要在多个环境（开发、测试、生产）中部署相同的基础设施。CloudFormation 允许您对每个环境使用具有不同参数值的相同模板。

资源扩展

随着应用程序或工作负载的增长，CloudFormation 可让您通过修改模板或使用 自动扩展 功能快速扩展基础设施。

CloudFormation 提供了一种通过代码管理 AWS 资源的强大且可扩展的方法，在云基础设施设置和维护方面具有自动化、一致性和协作方面的优势。

Terraform vs CloudFormation

Terraform 与 CloudFormation

CloudFormation

• 供应商锁定：AWS CloudFormation 与 AWS 服务紧密集成，使其成为以 AWS 为中心的环境的自然选择。
• 本机集成：与其他 AWS 服务无缝集成，提供直接资源引用和统一的管理体验。
• 服务覆盖：提供 AWS 服务的全面覆盖，通常包括发布后不久对新服务的支持。
• 学习曲线：对于熟悉 AWS 服务的人来说，学习 CloudFormation 可能更容易。

Terraform

• 云无关：Terraform 与云无关，支持多个云提供商，包括 AWS、Azure、Google Cloud 等。这使其成为混合或多云部署的多功能选择。
• 社区和模块：它有一个庞大而活跃的社区，使用模块允许可重复使用和共享代码。
• 状态管理：Terraform 使用状态文件来跟踪基础设施的当前状态，提供已部署资源的清晰视图。
• 语言灵活性：Terraform 使用的 HashiCorp 配置语言 (HCL) 专为可读性而设计，比 JSON 或 YAML 更灵活。

用例

Terraform 用例

1. 多云环境

***场景_*：**一家公司将其基础设施与多个云提供商（如 AWS、Azure 和 GCP）结合使用。

使用 Terraform 的原因：

• Terraform 为各种云平台提供提供商，使管理多云环境变得更加容易。
• 单个 Terraform 配置可以跨越不同的云提供商，从而允许在整个基础设施环境中实现一致的基础设施即代码 (IaC)。

2. 社区模块和提供商：

场景_：一家组织严重依赖社区贡献的模块和提供商来增强基础设施配置。

选择 Terraform 的原因：

• Terraform 拥有一个充满活力的社区，为各种服务和平台贡献可重复使用的模块和提供程序。
• 利用社区驱动的内容可以显著加快开发过程，并提供更广泛受众采用的最佳实践。

AWS CloudFormation 用例

1. 深度 AWS 集成

场景：企业的基础设施主要以 AWS 为中心，团队对 AWS 特定的服务和功能投入了大量资金。

选择 CloudFormation 的原因：

• AWS CloudFormation 提供与 AWS 服务的本机集成，使其非常适合管理 AWS 特定的资源。
• CloudFormation StackSets 和 Change Sets 等功能增强了对 AWS 特定资源和部署的管理。

2. 托管服务集成：

场景：组织大量使用 AWS 托管服务，例如 AWS Elastic Beanstalk 或 AWS OpsWorks。

采用 CloudFormation 的原因：

• AWS CloudFormation 与 AWS 托管服务无缝集成，简化了这些服务的配置和管理。
• CloudFormation 为许多 AWS 托管服务提供特定资源类型，从而允许在模板中实现更高级别的抽象。

Secure IaC

安全云 IaC 最佳实践

对于 CloudFormation 和 Terraform

• 版本控制：将 IaC 代码存储在 Git 等版本控制系统中，以跟踪更改、促进协作并维护版本历史记录。
• 最小权限原则：始终为凭证和 IaC 工具分配最小的权限和范围。仅授予执行操作所需的权限。
• 参数化敏感数据：使用参数化来处理凭证或 API 密钥，避免将机密直接硬编码到 IaC 代码中。
• 安全凭证管理：利用云平台的安全凭证管理解决方案或服务来安全地处理和存储敏感信息，例如用于秘密管理的保险库。
• 审计跟踪：启用日志记录和监控功能，以维护通过 IaC 工具所做的更改的审计跟踪。使用这些日志定期进行审查。
• 代码审查 实施代码审查以确保 IaC 代码符合最佳安全实践。协作审查流程可尽早发现潜在的安全问题。

查看源代码安全室以了解有关该区域的更多信息。

对于 AWS CloudFormation

• 使用 IAM 角色：为 CloudFormation 堆栈分配具有所需最低权限的身份和访问管理 (IAM) 角色。尽可能避免使用长期访问密钥。
• 安全模板存储：将 CloudFormation 模板存储在加密的 S3 存储桶 中，并限制只有授权用户或角色才能访问。
• 堆栈策略：实施堆栈策略来控制堆栈资源的更新并在更新期间强制执行特定条件。

对于 Terraform

• 后端状态加密：启用后端状态加密以保护存储在 Terraform 状态文件中的敏感信息。
• 使用远程后端 使用 Amazon S3 或 Azure 存储等后端远程存储 Terraform 状态。这增强了协作并提供了更好的安全性。
• 变量加密：使用变量时，考虑使用 HashiCorp Vault 等工具或其他安全密钥管理解决方案对敏感值进行加密。
• 提供商配置：使用环境变量、变量文件或其他安全方法安全地配置提供商凭据。

Practical

好的，我们已经了解了基于云的 IaC，涵盖了 Terraform 和 AWS CloudFormation。现在是时候向您实际演示一下，如果您是使用这些工具的 DevSecOps 工程师，您的日常工作可能会是什么样子。在这个静态站点中，您将看到一段文本；此文本代表您的基础设施。您的基础设施即代码！最初，您将看到一个相当不安全的基础设施，几乎没有任何安全性。然后，您将有机会选择要添加的资源块或要更改的变量，这将保护这个基础设施。一旦基础设施得到保护，并且您作为 DevSecOps 工程师的角色得到履行，旗帜就全属于您了！要开始您的基于云的冒险，请单击此任务右上角的绿色“查看站点”按钮。

1. 介绍菜单：

启动静态站点后，您将看到一个介绍菜单。此菜单提供重置基础设施、访问说明和构建基础设施等选项。选择您想要的选项以继续。

2. IaC 屏幕：

从介绍菜单中选择一个选项后，您将转到 IaC 配置屏幕。此屏幕模拟 Terraform 的各个阶段：初始化、计划和应用。

3. 指导模型：

静态站点充当指导模型，指导您完成 YAML 配置的基础知识。它采用了受 Scratch 和 Code Warrior 方法启发的用户友好方法。无需担心复杂的代码细节即可学习。

4. 交互部分：

在练习期间，您将与 YAML 配置文件中的可点击空白进行交互。这些空白代表要添加的组件以增强基础设施安全性。选择正确的选项来填写空白。

5. 标记标准：

练习包括三个阶段：审查、实施和销毁。成功完成每个阶段后，屏幕底部的菱形将亮起。

6. 消息：

• 欢迎消息：开始时，您会收到一条欢迎消息。
• 审核阶段消息：分析 YAML 配置文件是否存在安全漏洞，并在准备就绪后单击“下一步”。
• 实施阶段消息：填写空白以增强基础设施。启动 Terraform 工作流并按照说明操作。
• 销毁阶段消息：成功实施后，销毁基础设施。单击“Terraform 销毁”按钮。
• 配置文件：

利用提供的 YAML 配置文件表示基础设施。

在实施阶段，使用虚拟选项与可点击的空白进行交互。