华为云的HFA的自动化部署演示指导

华为云的HFA的自动化部署演示指导

本指导文档基于公司 Terraform 进行自动化部署 ， 在整个 HFA 的自动化部署演示过程中 ， 由于存在着 API 缺失 ， 或 Terraform （ Huawei Coud Provider ） 的模块缺失 ， 所以整体流程上 ， 即便 Console 可以配置相关功能 ， 也不是所有功能功能 ， 都能通过 Terraform 实现自动化处理 ， 我们在配置过程中 ， 仍然需要通过 Console 来创建账号。我们尽量将中间的常用方法 ， 编写成 Terraform 的 module ， 以便后续可以基于 Terraform module 功能 ， 来组织整个 HFA 的实施 ， 后续也可以独立调用这些 module 。例如 ： VPC Peering Cross Account 这个功能 ， 目前在 Enterprise Route 服务未发布之前 ， 多账号之间的访问关系 ， 都是通过 VPC Peering 实现的。我们在创建 HFA 的配置环境过程中 ， 使用 VPC Peering 进行账号之间的配置处理。未来这个指导文档会持续演进模式 ， 是通过编写 HFA 的场景模块 ， 来实现复杂 HFA 环境的构建。同时由大家来一起编写基础模块 ， 推动整个华为云上的部署自动化的实现。

 

1.%2 1 ： 环境准备

 

本指导最终希望 ， 通过这个 HFA 的自动化部署演示 ， 了解 Terraform 的基本部署框架和使用思路。本指导会持续迭代 ，

 

注意 ： 当前只是 HFA 的自动化演示方案 ， 再次强调只是一个单次的 Demo 执行方案 ， 当前不适用于企业级生产环境 ， 建议生产环境部署搭建联系 SA 或 PS ， 提供生产环境的搭建专业意见。 （ 如果要自己用于生产环境 ， 设计考量上要注意关于 state 文件和锁机制的处理 ， 以及如果用于 IaC ， 要考虑 Pipeline 的运行环境和权限设定。 ）

 

1.1.%3 1.1 基础知识

 

整体实施过程中 ， 主要通过 Huawei Foundation Architecture https://wiki.huawei.com/domains/4034/wiki/11269/WIKI2022012000017 的文档指引 ， 遵循此文档进行操作 ， 建议大家通过此 Wiki 的文档说明 ， 了解 HFA 的基础知识。

 

 

 

1.2.%3 1.2 主账号申请

 

对于华为员工而言 ， 你需要申请一个测试用的主账号 ， 以便创建各个成员账号。用于 HFA 的自动化环境准备。本指导文档基于员工测试用的国际账号实现。

 

注 1 ： 关于华为员工申请国际测试账号流程 ， 请去内网搜索 hwstaff_intl ， 请按搜索结果进行申请账号和预算金额 ， 需要相关主管审批后 ， 方可使用。

update:当前可以通过链接 ： http://3ms.huawei.com/km/blogs/details/12001385  来查询方法

 

注 2 ： 由于华为云在创建账号过程 ， 需要交互验证 ， 在成员账号在添加过程中 ， 用于接受验证码。建议您提前申请一个 Gmail 邮箱用于这个测试。主要用于接收验证邮件 Gmail 邮箱 +alias 创建同一个邮件下的别名。例如 ： mytest@gmail.com 是我申请的邮箱 ， 但是可以通过 mytest+devops@gmail.com ， mytest+share@gmail.com , mytest+sec@gmail.com , mytest+prod@gmail.com 来用于账号的交互验证。 这个功能并不是所有邮箱系统都支持 ， 目前 Gmail 和 outlook 邮箱支持 ， 大家可以自行选择。

 

 

 

2.%2 2 ： 创建华为云账号

 

我们确认 ， 您已经通过上面申请 ， 拥有了一个主账号 ， 目前我们要在这个主账号下 ， 创建对应的成员账号。相关账号问题 ， 请参考上面综述描述中 HFA 文档内的账号内容说明。

 

2.1.%3 2.1 账号设计

 

我们在账号设计上 ， 建议通过主账号 ， 主要用于付款和结算。主账号上 ， 不做任何服务实施相关工作。成员账号 ， 我们主要分为两类 ， 一类为核心账号 ， 主要由公司的运维人员和网络安全人员管理 ， 另外一类为一般账号 ， 可以理解为项目组的生产或非生产账号。当前账号设计表如下。

图 2.1 账号设计表

 

核心账号设计原则上 ， 我们基本上存在两个准则 ， 第一是客户服务在强监管条件下的日志留存和账号隔离策略。第二个是依据客户自身部门设定 ， 将相关功能存在于对应的账号。基本上是决定我们分拆账号还是合并账号的主要依据。而用于项目或相关其他部门的账号 ， 可以存在两种维度来处理 ， 生产账号和非生产账号 ， 在这个账号下面 ， 我们再以华为云特有的 Enterprise Project 来进行项目维度的分类。具体的实施方案 ， 可以和客户讨论来进行抉择 ， 是否需要单独的账号分类。

 

 

这里大家需要了解一个概念 ， 我们这样创建的主账号 （ Master Account ） 和成员账号 （ Member Account ） 都是这个账号的根用户 ， 所以我们可以指用账号名 （ 或邮箱、电话 ） + 密码进行登录。 而通常我们登录的 IAM 账号 ， 是以根账号 （ root account ） 为域 ， 再加上 IAM 用户名 + 密码进行登录的。所以在 Console 上登录 ， 存在以上的区别。在安全设计上 ， 我们也建议根账号创建后 ， 也不用于运维和登录使用。指用于紧急场景 ， 默认情况下 ， 建议封存密码方式保留。

 

2.2.%3 2.2 成员账号的创建

 

成员的账号的创建 ， 目前没有 API ， 只能通过 Console 进行创建 ， 而且需要交互处理 ， 用于接收电话或邮寄的验证码用于激活。

 

基于上面的账号分类 ， 我们来创建相关账号。最终实现的效果如下。

图 2.2 成员账号展示

 

 

2.2.1 创建 OU

 

 

创建账号过程中 ， 我们先创建 OU ， 分别创建 OU-CoreAccount 、 OU-EnvAccount, 请依次创建。截图只是指导 ， 请自行替换参数。

 

在主账号下 ， 选择 “ More ” -"Enterprise"-"Organizations and Accounts"

图 2.3 成员账号创建入口

 

创建 OU, 点击 "Create Organization"

图 2.4 成员账号 OU 创建

 

创建 OU-CoreAccount. 请遵循上面的步骤 ， 再次创建 OU-EnvAccount.

图 2.5 成员账号 OU 创建

2.2.2 创建账号

 

接下来 ， 依据规划的设计表 ， 我们将在对应的 OU 下 ， 创建我们的成员账号。分别是 : hwstaff_intl_apacod_transit, hwstaff_intl_apacod_sec, hwstaff_intl_apacod_common, hwstaff_intl_apacod_prod.

 

 

我们将依次在两个 OU 下 ， 添加上面的四个账号。重复性的操作。请自行修改参数添加。如图点击 “ Add Member Account ”

图 2.6 添加成员账号

 

如图点击 "Create Member Account"

图 2.7 添加成员账号

 

依据设计表 ， 填入我们之前预定义的名字。填入 “ Account Name ” 、 “ Email Address ” 和密码 ， 点击下一步。

图 2.8 添加成员账号

 

得到如图画面 ， 点击 Next

图 2.9 添加成员账号

这里显示我们的基本信息 ， 需要交互处理。获取验证码后 .

图 2.10 添加成员账号 - 获取验证码

输入验证码。点击提交。

图 2.11 添加成员账号 : 验证

 

完成后 ， 我们就成功创建了成员账号。

图 2.12 添加成员账号完成

2.3.%3 2.3 为成员账号分配费用

 

在如图示位置 ， 我们在我们创建的账号里面 ， 分配金额。

图 2.13 成员账号分配金额

2.4.%3 2.4 创建 IAM 运维账号 （ 使用这个账号生成 AK/SK ）

 

通过上面的管理 ， 我们已经创建所有成员账号的 root 用户。接下来 ， 您需要通过上面的 root 用户依次登录 ， 依据下面的表格 ， 创建每个账号下面的 ops_admin 的 IAM User, 用于我们后面作为运维管理的用户 ， 生成 AK/SK 并记录。

图 2.14 添加 ops_admin 的 IAM 账号

 

这里属于华为云账号的基本操作 ， 就不做赘述了。请创建好 ， 我们将使用这些相关账号 ， 进行我们 HFA 的环境部署。

 

 

需要说明的是 ， 这里的 AK/SK 在后续的脚本使用中会放到全局参数进行调用。请切记保留好相关账号 ， 不要发布到公网环境 ， 避免带来重大的安全隐患。待产品成熟的情况下 ， 我们建议您使用 Agency 实现。

3.%2 3: 通过 Terraform 部署 HFA

 

我们将通过 Terraform 进行华为云的 HFA 的部署 ， 再次需要强调的是 ， 当前的部署方案是一个自动化部署演示方案 ， 不是生产环境的最佳实践 ， 整个环境都是基于本地执行调用的。在生产环境的 IaC 架构中 ， 我们通常要对 tfstate 的存储 ， 以及状态锁进行相关设计 ， 以及调用过程中 ， 不使用到 AK/SK 。

 

如果有生产的需要。建议进行方案调整。同时 ， 在部署中 ， 我们采用了 AK/SK 的方式进行账号连接使用 , 而最佳实践 ， 通常我们建议在客户的运维账号中设计 , 使用 Agency 进行功能实现 ， 但是目前我们的 Agency 的服务功能限制 ， 导致可能功能不完善。在当前使用 AK/SK 方式下 ， 可以实现相对完善的功能。但是我们应该有意识的基于最佳实践进行功能实现。同时类似于网络 ， 我们目前缺少 ER(Enterprise Route) 的功能 ， 在实施 HFA 的过程中 ， 仍然通过 VPC Peering 进行实现。所以关于使用产品的 Limitation 要有了解。 VPC Peering 在单一账号下 ， 有 50 个 Peering 的硬限制 ； 默认只能建立 5 个 VPC 的软限制 ； VPC Peering 不能跨 Region 。

 

3.1.%3 3.1 Terraform 的实施框架

 

在当前这个部署结构中 ， 主要分为两个阶段 ：

 

第一个阶段 ： 运维的核心账号下所有账号的网络配置、连接和集中日志处理 ， 调整全局参数 ， 依次进入每个脚本路径 ， 调整参数 ， 执行脚本。

 

第二个阶段 ： 配置一般账号 ， 如测试、生产账号等 ， 连接核心账号的网络配置和集中日志等基线配置。

 

3.2.%3 3.2 功能设计

 

在针对华为云自动化设计实现上 ， 我们通常会依据华为云帮助文档来查看一些典型场景 ， 通常这些场景只有图形界面的实现方法。但是实际实施过程中 ， 我们应该注意 ， 存在明显差异。一定要验证方案。基本要遵循一些基本原则 ， 一般存在两个维度的完整性。

• 国内站 --》 国际站 --》合资云 （递减）

• Console控制台 --》 服务API --》 Terraform实现 （递减）

 

所以在进行方案设计的时候 ， 要知道自己的处境 ， 进行相关验证 ， 可能需要依据实际情况 ， 来调整实施的方案。在 IaC 对客户的承诺上 ， 要实测后给到客户。基于目前的产品能力 ， 大概率上全功能的 IaC 功能是不可能实现的。很多场景下 ， 受限于 API 、模块缺失 ， 交互方法导致完全没有办法自动化。

 

3.2.1 IAM 设计

 

在 IAM 设计中 ， 我们目前受限于 IAM Agency 的功能 ， 如果使用我们华为云的自有功能实现 Centralized Account 的功能 ， 会由于 IAM Agency 的原因会导致 ， 代理账号之后不是完整功能。

所以在 IAM 的账号设计上 ， 如果实现完整功能的话 ， 建议采用 Azure AD Enterprise 的管理集成 ， 或者以 ADFS 的方式进行 Console 的集成 ， 进行统一的 SSO 认证管理。否则目前我们华为云 ， 自身托管服务层面上 ， 没有 SSO 的原生服务。因此 ， 在本次的 HFA 发布中 ， 我们没有发布 IAM 的自动化实现。

 

3.2.2 网络设计

 

在网络设计实现上 ， 多账号之间 ， 目前由于 ER 这个产品功能尚未商用 ， 目前只在图形 Console 上存在这个服务 ， 目前尚未发布 API ， 所以 Terraform 也还没有模块支撑 ER 产品进行自动化实现。目前我们仍然基于 VPC Peering 的设计为客户提供相关网络访问的实现。在 VPC Peering 的功能中 ， 存在着一点误解 ， 我们华为的 VPC Peering 无法做到传递功能的 ， 也就是 A 和 B 配置 VPC Peering, B 和 C 配置 VPC Peering, 那么 A 和 C 能互访吗 ？ 事实上是可以的 ， 我们只需要在两边调整路由表即可。

图 3.2 网络架构图

设计说明 ：

1 ： 所有网络都从 Transit Account 进行连接。存在 4 个 VPC ， Ingress 和 Egress 一组 ， 分为 Prod 和 Non-Prod 进行区分。其中 Ingress 通过 ELB 进行流量导入 ， 通过 Egress 的 Nat Gatway 对于其他账号进行公网访问的支撑。

2 ： 核心账号都需要分别和 Transit 的 4 个 VPC 进行连接 ， 用于 Prod 和 Non-Prod 的对接。

3 ： 一般账号 ， 分为 Prod 和 Non-Prod 对接对应的 2 个 VPC, 分别是 Ingress 和 Egress 。

4 ： 关于账号之间的 East-West 流量 ， 都通过 Egress 进行访问互通。

 

关于地址规划如下 ：

图 3.3 网络规划图表

 

 

设计限制 ：

 

单一账号 ， 存在默认的 VPC Peering 的限制 ， 上限是 50 个 VPC ， 无法调整。基于这个设计 ， 我们如果没有新增 Core Account 的情况下 ， 我们可以增加的一般账号上限的计算方式如下 ： 50 - 4 x 2 = 42 /2 = 21

 

4 代表每个核心账号需要和 Transit 账号 VPC 连接的 VPC Peering 的数目 ， 2 代表除去 transit 账号 ， 其他两个核心账号。 每个一般账号需要至少 2 个 VPC Peering 对接到 Transit 账号上。所以 Transit 在当前设计下 ， 最多能容纳的通用账号是 21 个。具体情况 ， 请依照这个逻辑进行计算。

 

3.2.3 日志设计

当前在 HFA 日志的设计中 ， 我们主要对 CTS 的 System 、 Data 日志进行采集。同时建议开启 VPC Flow Logs 日志。但是由于 Terraform 模块功能尚未完成 ， 目前中央日志归档 ， VPC Flow Logs 均没有基础模块。所以无法完成自动化实现。

设计说明 ： 

1 ： CTS 和 VPC Flow Logs 配置默认本地归档存储。存档周期保留 1 个月。

2 ： CTS 和 VPC Flow Logs 配置远程归档到 Centralized Account(Security Account) 。保留周期按需配置 ， 建议至少 6 个月。

图 3.4 CTS 日志设计

目前自动化限制说明 ： VPC Flow Logs 没有 Terraform 模块 ， 无法进行自动化 ， 只能通过图形 Console 实现 ， LTS 的远程归档功能 ， 目前也没有 Terraform 模块 ， 只能在图形 Console 上配置。

3.2.4 监控告警设计

在目前默认的告警设计上 ， 只是针对 CTS 的关键性告警进行设定 ， 主要设定标准 ， 依据 HFA 的设计内容进行考量。关键配置表如下 ：

3.3.%3 3.3 实施部署 Terraform

 

我们在进行 Terraform 的自动化部署过程中 ， 采用的是单次执行原则 ， 不建议直接使用当前方式用于生产环境 ， 基于生产环境 ， 建议针对 tfstate 和 lock 进行相关设计。接下来 ， 我们详细介绍一下调用方法。

 

当前 Terraform 的设计结构上 ， 我们使用了全局变量 ， 同时采用切分调用场景 ， 依次处理网络、日志告警。每个场景下 ， 采用独立的变量和全局变量共同使用。

 

我们介绍一下主要的目录结构 ：

 

1: global-variables-modules // 全局参数模块 ， Terraform 默认没有全局参数的功能 ， 我们使用 module 的 Output 实现全局参数的设计。

 

2: hfa-core-account-playbook // 我们首先创建核心账号的功能 ， 依次调用网络、日志、告警的。

 

3: hfa-general-account-playbook // 我们初始化一般账号的基础脚本 ， 配置默认的网络、日志、告警等基线。

 

4: terrafrom-hwcloud-modules // 我们抽象出来的基本模块 ， VPC 、 VPC Peering 、 CTS 的基线告警等。

图 3.7 Terraform 项目目录图

 

基于您自己的本地环境 ， 执行 terraform 的安装 ， 具体方法 ， 可以参考 ：

https://www.terraform.io/downloads

 

以客户端为 Ubuntu/Debian 为例 ：

wget -O- https://apt.releases.hashicorp.com/gpg | gpg --dearmor | sudo tee /usr/share/keyrings/hashicorp-archive-keyring.gpg echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $( lsb_release -cs ) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list sudo apt update && sudo apt install terraform

 

 

创建执行目录 ， 获取全部执行文件。

mkdir /workdir

cd /workdir

git clone https://github.com/hwcloud-apac-pso/HFA-Automation-Terraform 

 

 

3.3.1 全局参数

 

我们首先修改全局参数 ， 基于上面的设计场景 ， 我们修改您申请的账号列表 ， 进行配置文件的修改。用于后面我们的调用。大家可以在前面的环境准备环节 ， 已经基于设计 ， 在上面创建了相关账号 ， 在 2.4 章节 ， 已经申请了 IAM 运维账号的 AK/SK 。

图3.8 全局参数表

 

请按您自己的实际值 ， 进行修改配置文件 global_vars.tf

执行命令 ：

 

# 进入全局参数目录
cd ./HFA-Automation-Terraform/global-variables-modules
# 依据上面参数文件，修改对应参数
vi global_vars.tf
# 执行terraform命令
terraform apply -auto-approve

 

3.3.2 核心账号网络环境调用

 

关于部分的调用 ， 我们主要先规划好地址段 ， 然后按照自己预设的网络规划来定义 VPC 和 Subnet, 调整参数来实现自己的规划目标。

3.3.3 核心账号中央日志调用

 

关于中央日志的实现部分 ， 我们目前只实现了本地的归档设计 ， 由于 Terraform 模块的缺失 ， 我们无法完成中央日志的归档自动化以及 VPC Log 的归档部门。目前仅是本地关于 CTS 的启用和归档。

 

 

在 CTS 的使用过程中 ， 我们首先要启用 CTS ， 这个必须在 Console 上先在所在区域点击过 Enable, 才能继续 Terrafrom 的脚本执行 ， 如图所示。否则无法调用脚本。

 

配置流程如下 ： “ Service List ” --> "Cloud Trace Service", 点击后 ， 出现如下截图 , 点击 "Enable and Authorize" 进行启用 CTS 的日志。

图 3.10 CTS 图形启用

参数配置修改 ， 参考如图

大多数参数我们已经屏蔽隐藏 ， 暴露在外部的 ， 只有日志的归档的保留周期。

执行命令 ：

# 进入核心账号日志配置脚本
cd ./HFA-Automation-Terraform/hfa-core-account-playbook/2.hfa-logs-playbook
# 依据上面参数文件，修改对应参数
vi input_local_vars.tf
# 执行terraform命令
terraform init
terraform apply -auto-approve

3.3.4 核心账号重要告警调用

 

关于重要告警部分的设计实现 ， 请参考设计描述的部分 ， 我们在此只提供了邮件和电话的通知方式 ， 可以选择两种 ， 或者只选择一个作为消息通知

当前调用 ， 只启用了邮件通知。如果需要电话通知 ， 请取消注释部分。

同样的在配置之前 ， 参考之前 3.3.3 的 CTS 的日志配置 ， 需要 Enable CTS 。

 

执行命令 ：

# 进入核心账号日志通知配置脚本
cd ./HFA-Automation-Terraform/hfa-core-account-playbook/3.hfa-notify-playbook
# 依据上面参数文件，修改对应参数
vi input_local_vars.tf
# 执行terraform命令
terraform init
terraform apply -auto-approve

 

同样在设定完成后 ， 一定记得在收到邮件或者短信的验证部分 ， 一定要点击确认。否则你仍然无法收到消息通知。

 

 

3.3.5 一般账号配置过程

 

关于一般账号的初始化 ， 通常也是基础架构组或者 SRE 工程师的职责。在这种账号的初始化过程中 ， 也要满足上述的所以基本要求 ， 基本等同于上述步骤的集合。其中网络连通的部分 ， 我们内部东西流量上需要和 Common Service 的网络连通。在南北流量上 ， 我们通过 transit 的 Prod Ingress 和 Egress 连接。

 

其中参数部分 , 请看如图 ， 红色部分关于核心账号部分 ， 直接从之前的核心账号拷贝过来。不需要修改。 而绿色部分 ， 是按照我们自己的规划和使用配置。

同样的在配置之前 ， 参考之前 3.3.3 的 CTS 的日志配置 ， 需要 Enable CTS 。

 

执行命令 ：

# 进入核心账号日志通知配置脚本
cd ./HFA-Automation-Terraform/hfa-core-account-playbook/3.hfa-notify-playbook
# 依据上面参数文件，修改对应参数
vi input_local_vars.tf
# 执行terraform命令
terraform init
terraform apply -auto-approve

 

同样在设定完成后 ， 一定记得在收到邮件或者短信的验证部分 ， 一定要点击确认。否则你仍然无法收到消息通知。

 

 

3.3.5 一般账号配置过程

 

关于一般账号的初始化 ， 通常也是基础架构组或者 SRE 工程师的职责。在这种账号的初始化过程中 ， 也要满足上述的所以基本要求 ， 基本等同于上述步骤的集合。其中网络连通的部分 ， 我们内部东西流量上需要和 Common Service 的网络连通。在南北流量上 ， 我们通过 transit 的 Prod Ingress 和 Egress 连接。

 

其中参数部分 , 请看如图 ， 红色部分关于核心账号部分 ， 直接从之前的核心账号拷贝过来。不需要修改。 而绿色部分 ， 是按照我们自己的规划和使用配置。