diff --git a/docs/.vitepress/src/layouts/LayoutDoc.vue b/docs/.vitepress/src/layouts/LayoutDoc.vue index 6abdd8c4600aaa5b4465b64c9c9b138bacf434f4..a5e0cb477edf5e769947e7c0b280ee30242b43e3 100644 --- a/docs/.vitepress/src/layouts/LayoutDoc.vue +++ b/docs/.vitepress/src/layouts/LayoutDoc.vue @@ -55,6 +55,13 @@ const props = defineProps({ }, }); +// 是否是贡献指南手册，直接显示 文档中心 > 贡献指南的具体章节 +const isContribute = computed(() => { + const pathHref = route.path.replace('.html', ''); + return pathHref.includes('/zh/Contribute') || pathHref.includes('/en/Contribute'); +}) + + // -------------------- 菜单 -------------------- let isScrolling = false; const menuStore = useMenuStore(); @@ -364,7 +371,7 @@ onUnmounted(() => {

{{ moduleNode?.label }}

- +
版本： {{ version }} @@ -402,7 +409,7 @@ onUnmounted(() => {

{{ moduleNode?.label }}

-
+
版本： {{ version }} diff --git a/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/_menu.md b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/_menu.md index 510670a31f24bd70a2ebf0d843d42d20ba6c9da3..d6f3fc92a9ddac035b1175b718e2d609199c1db8 100644 --- a/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/_menu.md +++ b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/_menu.md @@ -1,8 +1,28 @@ --- -label: 'OpenStack用户指南' +label: 'OpenStack SIG' ismanual: 'Y' -href: './openstack.md' -description: 'OpenStack是一个开源的云计算管理平台项目，可供可扩展的、灵活的云计算服务' +href: './index.md' +children: + - label: '贡献指导' + href: './contribute/rpm-packaging-reference.md' + children: + - label: 'RPM开发流程' + href: './contribute/rpm-packaging-reference.md' + - label: '安装指导' + children: + - label: 'devstack' + href: './install/devstack.md' + - label: 'antelope' + href: './install/antelope.md' + - label: '自研特性' + children: + - label: '虚拟机高低优先级' + href: './spec/priority_vm.md' + - label: '流量分散' + href: './spec/distributed-traffic.md' + - label: '操作及管理指导' + children: + - label: '安全指南' + href: './security/security-guide.md' --- - diff --git a/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/contribute/rpm-packaging-reference.md b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/contribute/rpm-packaging-reference.md new file mode 100644 index 0000000000000000000000000000000000000000..4fbb1dd0c211e8bc70eb752821a8bcc9e1d2c058 --- /dev/null +++ b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/contribute/rpm-packaging-reference.md @@ -0,0 +1,147 @@ +# SIG RPM 编包流程梳理 + +OpenStack SIG 有一项长期开发工作是进行 OpenStack 各版本相关 RPM 软件包的打包维护。为了方便新加入 SIG 的开发者更快了解 SIG 编包流程，在此对 SIG 编包流程进行梳理，以供参考。 + +## Excel表格说明 + +SIG 编包时，会以共享表格的形式，将需要处理的软件包整理出来，供开发者协同处理。当前表格格式如下： + +| Project Name | openEuler Repo | SIG | Repo version | Required (Min) Version | lt Version | ne Version | Upper Version | Status | Requires | Depth | Author | PR link | PR status | +|:------------:|:--------------:|:---:|:------------:|:----------------------:|:----------:|:----------:|:-------------:|:------:|:--------:|:-----:|:------:|:-------:|:---------:| +| pyrsistent| python-pyrsistent | sig-python-modules | 0.18.0 | 0.18.1 | | [] | 0.18.1 | Need Upgrade | [] | 13 | | | | +| ... | | | | | | | | | | | | | | + +“Project Name”列为软件项目名。“openEuler Repo”列为此项目在 openEuler gitee 上的仓库名，同时也是此项目在openEuler系统中的软件包名。所有 openEuler 的软件包仓库均存放于 SIG。 + +处理时首先查看“Status”列，该列表示软件包状态。软件包共有6种状态，开发者需要根据“Status”进行相应处理。 + +1. “OK”：当前版本直接可用，不需要处理。 +2. “Need Create Repo”：openEuler 系统中没有此软件包，需要在 Gitee 中的 src-openeuler repo 仓新建仓库。流程可参考社区指导文档：[新增软件包](https://gitee.com/openeuler/community/blob/master/zh/contributors/create-package.md)。创建并初始化仓库后，将软件包放入需要的 OBS 工程。 +3. “Need Create Branch”：仓库中没有所需分支，需要开发者创建并初始化。 +4. “Need Init Branch”：需要初始化分支并将此分支软件包放入需要的 OBS 工程。表明分支存在，但是里面并没有任何版本的源码包，开发者需要对此分支进行初始化，上传所需版本源码包及 spec 文件等。以22.09开发周期适配 Yoga 版本为例，此任务直接在 master 分支工作。get_gitee_project_version 项目状态为“Need Init Branch””，它对应的“python-neutron-tempest-plugin”仓库的master分支，在处理前，只有 README.md 和 README.en.md 两个文件，需要开发者初始化分支。 +5. “Need Downgrade”：降级软件包。此种情况靠后处理，与 SIG 确认后再操作。 +6. “Need Upgrade”：升级软件包。 + +确定好软件包对应的处理类型后，需要根据版本信息进行处理。“Repo version”列为当前仓库中对应分支的软件包版本。“Required (Min) Version”则是需要的最小版本，如果其后有"(Must)"标识，则表示必须使用此版本。“Upper Version”为可以使用的最高版本。如果“Required (Min) Version”和“Upper Version”不同，优先使用“Required (Min) Version”。比如升级软件包，优先升级到“Required (Min) Version”。 + +“Requires”列为软件包的依赖。“Depth”列表示软件包依赖层级。“Depth”为1的是“Depth”为0的软件包的依赖，以此类推，“Depth”高的软件包为“Depth”低的软件包的依赖。处理时应优先处理“Depth”高的行。但如果某个包，没有依赖（“Requires”为[]）,也可直接处理。如果某些包需要优先处理，应按照其“Requires”，优先处理其依赖。 + +处理一个软件包时，应首先在“Author”列标注自己的名字，以告诉其他开发者此包已有人处理。pr（pull request）提交后，将 pr 链接贴到“PR link”列。pr 合并后，应在“PR status”列标注“Done”。 + +## SIG 处理编包问题流程 + +目前 SIG 处理编包问题主要使用 SIG 自己编写的 oos 工具。oos 工具细节参考 [oos README](https://gitee.com/openeuler/openstack/blob/master/tools/oos/README.md)。不同“Status”处理时涉及的“升级”、“初始化分支”、“软件包放入 OBS 工程”等操作，oos 工具有对应实现。 + +以 Yoga 版本升级 python-pyrsistent 软件包为例，演示编包流程，帮助开发者熟悉 OpenStack SIG 基于 oos 工具的打包相关流程。在了解基础流程后，开发者可通过[oos README](https://gitee.com/openeuler/openstack/blob/master/tools/oos/README.md)了解其余操作。python-pyrsistent 软件包信息参见上文表格。该软件包需要从0.18.0版本升级到0.18.1版本。Yoga 版本是在22.09版本开发规划中，当前为22年5月，直接提交到master分支即可。 + +### 签署 CLA + +在 openEuler 社区提交贡献需要签署 [CLA](https://clasign.osinfra.cn/sign/Z2l0ZWUlMkZvcGVuZXVsZXI=)。 + +对于初次参与 openEuler 社区的开发者，可首先查看[openEuler 贡献攻略](https://www.openeuler.org/zh/community/contribution/)，概览整体贡献情况。 + +### 环境准备 + +```shell +dnf install rpm-build rpmdevtools git + +# 生成~/rpmbuild目录，oos默认工作路径也为此 +rpmdev-setuptree + +pip install openstack-sig-tool==1.0.6 +``` + +说明：openstack-sig-tool 在 1.1.0 版本对 `oos spec` 命令进行了[重构](https://gitee.com/openeuler/openstack/commit/9083ba741acdea4d986cb2a58069156693832d09)。如下流程涉及 `oos spec` 命令的操作对应 1.0.6 版本。建议安装新版 [oos](https://gitee.com/openeuler/openstack/tree/master/tools/oos), 并参考对应 [README](https://gitee.com/openeuler/openstack/blob/master/tools/oos/README.md) 使用。 + +### 生成个人 Gitee 帐户的 pat(personal access token) + +首先进入 Gitee 帐户的“设置”界面。 + +![设置](../img/contribute/rpm-packaging-reference/setting.png) + +选择“私人令牌”，然后点击“生成新令牌”。生成后单独保存好自己的私人令牌（pat），Gitee 上无法再次查看，如果丢失只能重新生成。 + +![私人令牌](../img/contribute/rpm-packaging-reference/pat.png) + +### 生成 python-pyrsistent 包的 spec 并提交 + +```shell +export GITEE_PAT= +oos spec push --name python-pyrsistent --version 0.18.1 -dp + +-dp, --do-push + [可选] 指定是否执行push到gitee仓库上并提交PR，如果不指定则只会提交到本地的仓库中 +``` + +注意此处 `--name` 参数为表格中的“Project Name”列。 + +`oos spec push` 命令会自动进行如下流程： + +1. fork `--name` 对应仓库到 pat 对应的 gitee 帐户。 +2. 将仓库 clone 到本地，默认路径为 `~/rpmbuild/src-repos`。 +3. 根据 `--name` 和 `--version` 下载源码包，并生成 spec 文件(读取仓库中原有 changelog)。此阶段默认路径为 `~/rpmbuild`。 +4. 本地运行 rpm 包构建。本地运行通过后，会自动将 spec 文件及源码包更新到 git 仓库。如果有 `-dp` 参数则自动进行 push 及创建 pr 操作。如果本地构建时失败，则停止流程。 + +如果本地构建失败，则可以修改生成的 spec 文件。然后执行： + +```shell +oos spec push --name python-pyrsistent --version 0.18.1 -dp -rs + +-rs, --reuse-spec + [可选] 复用已存在的spec文件，不再重新生成。 +``` + +如此循环，直至上传成功。 + +注1：升级时要通过 `oos spec push` 命令生成 spec 文件，不要使用 `oos spec build` 命令，push 命令会保留仓库中 现有 spec 的 changelog，build 命令则直接生成新的 changelog。 + +注2：处理错误时，可以参考仓库中现有的 spec 文件；当前 spec 除了 changelog 部分，其余为 oos 工具重新生成，前人遇到的错误，此处仍可能遇到，可参考前人操作结果问题。 + +注3：oos 命令还支持批量处理，可以参考 oos 的 [README](https://gitee.com/openeuler/openstack/blob/master/tools/oos/README.md) 自行尝试。 + +### PR 门禁检查 + +此时在自己的 gitee 帐户中可以看到 fork 过来的仓库。进入自己帐号中的仓库，可通过点击如下框起位置，可进入原仓库。 + +![访问原仓库](../img/contribute/rpm-packaging-reference/redirect_git_repo.png) + +原仓库中可以看到自动提交的 pr。Pr 中可以看到 openeuler-ci-bot 的评论： + +![门禁结果](../img/contribute/rpm-packaging-reference/gateway.png) + +openEuler 在 gitee 上托管的代码，提交 pr 会自动触发门禁。本地构建通过的，也有可能在门禁检查中构建失败。比如上图中此次提交便构建失败，可以点击框起部分，查看对应架构的 build details。 + +此时可以根据 build details 中日志中报错信息，对本地 spec 进行修改，而后再次执行： + +```shell +oos spec push --name python-pyrsistent --version 0.18.1 -dp -rs +``` + +线上会自动重新执行测试。 + +门禁详细信息及各项结果含义参考社区的[《门禁功能指导手册》](https://www.openeuler.org/zh/blog/zhengyaohui/2022-03-21-ci_guild.html)。 + +### PR 检视 + +当一个 pr 通过门禁检查后，需要由软件仓库所属 SIG 的 maintainer 进行 review。为了加速进程，门禁通过后，可以手动 @ 对应的 maintainer，请求帮忙检视。在 pr 提交后，openeuler-ci-bot 会有如下图所示评论，其中被 @ 的人即为当前仓库所属 SIG 的 maintainer。 + +![maintainer](../img/contribute/rpm-packaging-reference/maintainer.png) + +## 注意事项 + +这里对一些可能遇到的特殊问题进行记录。 + +### 测试未执行问题 + +oos 自动生成的 spec 文件中，%check 部分默认为 `%{__python3} setup.py test`。但是在有些包中，这样并不会真正执行测试，但门禁结果也显示通过。需要开发者人工辨别。参考方法如下： + +1. 如果是此前已有 spec 文件，可以参考之前的 spec 中 %check 部分如何书写。如果以前写的不是 `%{__python3} setup.py test`，便需要重点注意。 +2. 进入门禁的 build details(参见上文“PR 门禁检查”部分)，查看构建日志的 %check 部分。下图为进入 build details，然后选择“文本方式查看”的日志显示截图。可以看到显示实际运行测试数为0。 + +![check_log](../img/contribute/rpm-packaging-reference/check_log.png) + +### 包名不一致问题 + +小部分软件包可能会碰到，oos 自动生成的 spec 所使用的的包名与现有包名不一致。比如一个使用`-`,一个使用下划线`_`。此处以原本使用的包名为准，不修改原有包名。 + +作为临时的处理，开发者可以手动将 spec 文件相关地方改为原有包名。与此同时，oos 拥有 mapping 修正功能，开发者可以提交 issue，SIG 将在 oos 中进行修复。 diff --git a/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/contribute/rpm-packaging-reference/check_log.png b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/contribute/rpm-packaging-reference/check_log.png new file mode 100644 index 0000000000000000000000000000000000000000..5bcc020fcc6411a6b79dc117cbe262181c56bd63 Binary files /dev/null and b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/contribute/rpm-packaging-reference/check_log.png differ diff --git a/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/contribute/rpm-packaging-reference/gateway.png b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/contribute/rpm-packaging-reference/gateway.png new file mode 100644 index 0000000000000000000000000000000000000000..a3553b6b7a2e45f8d64c025efb72e99d7fa92154 Binary files /dev/null and b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/contribute/rpm-packaging-reference/gateway.png differ diff --git a/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/contribute/rpm-packaging-reference/maintainer.png b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/contribute/rpm-packaging-reference/maintainer.png new file mode 100644 index 0000000000000000000000000000000000000000..7ae5f77b2b25063e9c111df8c38373b42bc6ad9e Binary files /dev/null and b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/contribute/rpm-packaging-reference/maintainer.png differ diff --git a/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/contribute/rpm-packaging-reference/pat.png b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/contribute/rpm-packaging-reference/pat.png new file mode 100644 index 0000000000000000000000000000000000000000..9eaa84d9ab487ebd247d81dec6377aaaa2014276 Binary files /dev/null and b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/contribute/rpm-packaging-reference/pat.png differ diff --git a/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/contribute/rpm-packaging-reference/redirect_git_repo.png b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/contribute/rpm-packaging-reference/redirect_git_repo.png new file mode 100644 index 0000000000000000000000000000000000000000..702c63d95a5111c7725bb9cdcfa00f42c95fd9ee Binary files /dev/null and b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/contribute/rpm-packaging-reference/redirect_git_repo.png differ diff --git a/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/contribute/rpm-packaging-reference/setting.png b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/contribute/rpm-packaging-reference/setting.png new file mode 100644 index 0000000000000000000000000000000000000000..5f5784ee4ae6087a3ef11f2be4cfbb2dcb212728 Binary files /dev/null and b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/contribute/rpm-packaging-reference/setting.png differ diff --git a/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/install/ironic-err.png b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/install/ironic-err.png new file mode 100644 index 0000000000000000000000000000000000000000..1edfa4fee7013d859ff85a4afdd81e7cbbfda2a8 Binary files /dev/null and b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/install/ironic-err.png differ diff --git a/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/install/topology1.PNG b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/install/topology1.PNG new file mode 100644 index 0000000000000000000000000000000000000000..1a23d5dbd20f230cb22420a77647b06c370ebe87 Binary files /dev/null and b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/install/topology1.PNG differ diff --git a/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/install/topology2.PNG b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/install/topology2.PNG new file mode 100644 index 0000000000000000000000000000000000000000..847e82a6f92a13986487a5f3967df5ecf9e791c7 Binary files /dev/null and b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/install/topology2.PNG differ diff --git a/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/install/topology3.PNG b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/install/topology3.PNG new file mode 100644 index 0000000000000000000000000000000000000000..b0b4d37933d79377b7273ca6f4167793580231aa Binary files /dev/null and b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/install/topology3.PNG differ diff --git a/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/install/wechat_group_assistant.jpg b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/install/wechat_group_assistant.jpg new file mode 100644 index 0000000000000000000000000000000000000000..a07ac046cb721fae6dc36d3dcdd04231f16f7e96 Binary files /dev/null and b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/install/wechat_group_assistant.jpg differ diff --git a/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/openEuler.png b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/openEuler.png new file mode 100644 index 0000000000000000000000000000000000000000..0a242257486a45f292c96ee500ef82788dd75da8 Binary files /dev/null and b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/openEuler.png differ diff --git a/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/spec/l3_scheduler.png b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/spec/l3_scheduler.png new file mode 100644 index 0000000000000000000000000000000000000000..79c3429a6e5bb395b3c4fcc5c5be11b02b074e88 Binary files /dev/null and b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/spec/l3_scheduler.png differ diff --git a/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/spec/router_1.png b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/spec/router_1.png new file mode 100644 index 0000000000000000000000000000000000000000..69bb45752768f143e91d068986bc77314443abb4 Binary files /dev/null and b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/spec/router_1.png differ diff --git a/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/spec/router_2.png b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/spec/router_2.png new file mode 100644 index 0000000000000000000000000000000000000000..12ff927ee38407e0f6c5d41c9c1cfa1252165375 Binary files /dev/null and b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/spec/router_2.png differ diff --git a/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/spec/router_3.png b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/spec/router_3.png new file mode 100644 index 0000000000000000000000000000000000000000..344fe2aeda7a6d94596b6cb1c8887edca7a4b129 Binary files /dev/null and b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/img/spec/router_3.png differ diff --git a/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/index.md b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/index.md new file mode 100644 index 0000000000000000000000000000000000000000..6e4cffb85a3531a4d50674394a22938cba3f2a41 --- /dev/null +++ b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/index.md @@ -0,0 +1,176 @@ +# openEuler OpenStack SIG + +## SIG 工作目标和范围 + +- 在openEuler之上提供原生的OpenStack，构建开放可靠的云计算技术栈。 +- 定期召开会议，收集开发者、厂商诉求，讨论OpenStack社区发展。 + +## 组织会议 + +公开的会议时间：月度例会，每月中下旬的某个周三下午3:00-4:00(北京时间) + +会议链接：通过微信群消息和邮件列表发出 + +会议纪要： + +## OpenStack版本支持列表 + +OpenStack SIG通过用户反馈等方式收集OpenStack版本需求，经过SIG组内成员公开讨论决定OpenStack的版本演进路线。规划中的版本可能因为需求更变、人力变动等原因进行调整。OpenStack SIG欢迎更多开发者、厂商参与，共同完善openEuler的OpenStack支持。 + +● - 已支持 +○ - 规划中/开发中 +▲ - 部分openEuler版本支持 + +| | Queens | Rocky | Train | Ussuri | Victoria | Wallaby | Xena | Yoga | Antelope | +|:-----------------------:|:------:|:-----:|:-----:|:------:|:--------:|:-------:|:----:|:----:|:--------:| +| openEuler 20.03 LTS SP1 | | | ● | | | | | | | +| openEuler 20.03 LTS SP2 | ● | ● | | | | | | | | +| openEuler 20.03 LTS SP3 | ● | ● | ● | | | | | | | +| openEuler 20.03 LTS SP4 | | | ● | | | | | | | +| openEuler 21.03 | | | | | ● | | | | | +| openEuler 21.09 | | | | | | ● | | | | +| openEuler 22.03 LTS | | | ● | | | ● | | | | +| openEuler 22.03 LTS SP1 | | | ● | | | ● | | | | +| openEuler 22.03 LTS SP2 | | | ● | | | ● | | | | +| openEuler 22.03 LTS SP3 | | | ● | | | ● | | | | +| openEuler 22.03 LTS SP4 | | | ● | | | ● | | | | +| openEuler 22.09 | | | | | | | | ● | ● | +| openEuler 24.03 LTS | | | | | | ● | | | ● | +| openEuler 24.03 LTS SP1 | | | | | | ● | | | ● | +| openEuler 25.03 | | | | | | | | | ● | + +| | Queens | Rocky | Train | Victoria | Wallaby | Yoga | Antelope | +|:---------: |:------:|:-----:|:-----:|:--------:|:-------:|:----:|:--------:| +| Keystone | ● | ● | ● | ● | ● | ● | ● | +| Glance | ● | ● | ● | ● | ● | ● | ● | +| Nova | ● | ● | ● | ● | ● | ● | ● | +| Cinder | ● | ● | ● | ● | ● | ● | ● | +| Neutron | ● | ● | ● | ● | ● | ● | ● | +| Tempest | ● | ● | ● | ● | ● | ● | ● | +| Horizon | ● | ● | ● | ● | ● | ● | ● | +| Ironic | ● | ● | ● | ● | ● | ● | ● | +| Placement | | | ● | ● | ● | ● | ● | +| Trove | ● | ● | ● | | ● | ● | ● | +| Kolla | ● | ● | ● | | ● | ● | ● | +| Rally | ▲ | ▲ | | | | | | +| Swift | | | ● | | ● | ● | ● | +| Heat | | | ● | | ▲ | ● | ● | +| Ceilometer | | | ● | | ▲ | ● | ● | +| Aodh | | | ● | | ▲ | ● | ● | +| Cyborg | | | ● | | ▲ | ● | ● | +| Gnocchi | | | ● | | ● | ● | ● | +| OpenStack-helm | | | | | | ● | ● | +| Barbican | | | | | ▲ | | ● | +| Octavia | | | | | ▲ | | ● | +| Designate | | | | | ▲ | | ● | +| Manila | | | | | ▲ | | ● | +| Masakari | | | | | ▲ | | ● | +| Mistral | | | | | ▲ | | ● | +| Senlin | | | | | ▲ | | ● | +| Zaqar | | | | | ▲ | | ● | + +Note: + +1. openEuler 20.03 LTS SP2不支持Rally +2. Heat、Ceilometer、Swift、Aodh和Cyborg只在22.03 LTS以上版本支持 +3. Barbican、Octavia、Designate、Manila、Masakari、Mistral、Senlin和Zaqar只在22.03 LTS SP2以上版本支持 + +## oepkg软件仓地址列表 + +Queens、Rocky、Train版本的支持放在SIG官方认证的第三方软件平台oepkg: + +- 20.03-LTS-SP1 Train: + + 该Train版本不是纯原生代码，包含了智能网卡支持的相关代码，用户使用前请自行评审 + +- 20.03-LTS-SP2 Rocky： + +- 20.03-LTS-SP3 Rocky： + +- 20.03-LTS-SP2 Queens： + +- 20.03-LTS-SP3 Rocky： + +另外，20.03-LTS-SP1虽然有Queens、Rocky版本的软件包，但未经过验证，请谨慎使用： + +- 20.03-LTS-SP1 Queens: + +- 20.03-LTS-SP1 Rocky: + +## Maintainer的加入和退出 + +秉承开源开放的理念，OpenStack SIG在maintainer成员的加入和退出方面也有一定的规范和要求。 + +### 如何成为maintainer + +maintainer作为SIG的直接负责人，拥有代码合入、路标规划、提名maintainer等方面的权利，同时也有软件质量看护、版本开发的义务。如果您想成为OpenStack SIG的一名maintainer，需要满足以下几点要求： + +1. 持续参与OpenStack SIG开发贡献，不小于一个openEuler release周期（一般为3个月） +2. 持续参与OpenStack SIG代码检视，review排名应不低于SIG平均量 +3. 定时参加OpenStack SIG例会（一般为双周一次），一个openEuler release周期一般包括6次例会，缺席次数应不大于2次 + +加分项： + +1. 积极参加OpenStack SIG组织的各种活动，比如线上分享、线下meetup或峰会等。 +2. 帮助SIG扩展运营范围，进行联合技术创新，例如主动开源新项目，吸引新的开发者、厂商加入SIG等。 + +SIG maintainer每个季度会组织闭门会议，审视当前贡献数据，根据贡献者满足相关要求，经讨论达成一致后并且贡献者愿意担任maintainer一职时，SIG会向openEuler TC提出相关申请 + +### maintainer的退出 + +当SIG maintainer因为自身原因（工作变动、业务调整等原因），无法再担任maintainer一职时，可主动申请退出。 + +SIG maintainer每半年也会例行审视当前maintainer列表，如果发现有不再适合担任maintainer的贡献者（贡献不足、不再活跃等原因），经讨论达成一致后，会向openEuler TC提出相关申请。 + +### Maintainer列表 + +|姓名|Gitee ID|邮箱|公司| +|---|---|---|---| +|陈硕|[joec88](https://gitee.com/joec88)||中国联通| +|李昆山|[liksh](https://gitee.com/liksh)||中国联通| +|黄填华|[huangtianhua](https://gitee.com/huangtianhua)||华为| +|王玺源|[xiyuanwang](https://gitee.com/xiyuanwang)||华为| +|张帆|[zh-f](https://gitee.com/zh-f)||中国电信| +|张迎|[zhangy1317](https://gitee.com/zhangy1317)||中国联通| +|韩光宇|[han-guangyu](https://gitee.com/han-guangyu)||统信软件| +|王东兴|[desert-sailor](https://gitee.com/desert-sailor)||创达奥思维| +|郑挺|[tzing_t](https://gitee.com/tzing_t)||华为| + +## 如何贡献 + +OpenStack SIG秉承OpenStack社区4个Open原则（Open source、Open Design、Open Development、Open Community），欢迎开发者、用户、厂商以各种开源方式参与SIG贡献，包括但不限于： + +1. [提交Issue](https://gitee.com/openeuler/openstack/issues/new) + 如果您在使用OpenStack时遇到了任何问题，可以向SIG提交ISSUE，包括不限于使用疑问、软件包BUG、特性需求等等。 +2. 参与技术讨论 + 通过邮件列表、微信群、在线例会等方式，与SIG成员实时讨论OpenStack技术。 +3. 参与SIG的软件开发测试工作 + 1. OpenStack SIG跟随openEuler版本开发的节奏，每几个月对外发布不同版本的OpenStack，每个版本包含了几百个RPM软件包，开发者可以参与到这些RPM包的开发工作中。 + 2. OpenStack SIG包括一些来自厂商捐献、自主研发的项目，开发者可以参与相关项目的开发工作。 + 3. openEuler新版本发布后，用户可以测试试用对应的OpenStack，相关BUG和问题可以提交到SIG。 + 4. OpenStack SIG还提供了一系列提高开发效率的工具和文档，用户可以帮忙优化、完善。 +4. 技术预言、联合创新 + OpenStack SIG欢迎各种形式的联合创新，邀请各位开发者以开源的方式、以SIG为平台，创造属于国人的云计算新技术。如果您有idea或开发意愿，欢迎加入SIG。 + +当然，贡献形式不仅包含这些，其他任何与OpenStack相关、与开源相关的事务都可以带到SIG中。OpenStack SIG欢迎您的参与。 + +## 项目清单 + +SIG包含的全部项目： + +OpenStack包含项目众多，为了方便管理，设置了统一入口项目，用户、开发者对OpenStack SIG以及各OpenStack子项目有任何问题，可以在该项目中提交Issue。 + +- + +SIG同时联合各大厂商、开发者，创建了一系列自研项目： + +- +- +- +- +- + +## 交流群 + +添加小助手回复"加群"进入openEuler sig-OpenStack交流群 +![assistant](img/install/wechat_group_assistant.jpg) diff --git a/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/install/antelope.md b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/install/antelope.md new file mode 100644 index 0000000000000000000000000000000000000000..1749e7fd01954ec82d7a8459e6886ad9ff606528 --- /dev/null +++ b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/install/antelope.md @@ -0,0 +1,3720 @@ +# OpenStack Antelope 部署指南 + +[TOC] + +本文档是 openEuler OpenStack SIG 编写的基于 |openEuler 25.03 的 OpenStack 部署指南，内容由 SIG 贡献者提供。在阅读过程中，如果您有任何疑问或者发现任何问题，请[联系](https://gitee.com/openeuler/openstack#%E8%81%94%E7%B3%BB%E6%96%B9%E5%BC%8F)SIG维护人员，或者直接[提交issue](https://gitee.com/openeuler/openstack/issues) + +**约定** + +本章节描述文档中的一些通用约定。 + +| 名称 | 定义 | +|:----:|:----:| +| RABBIT_PASS | rabbitmq的密码，由用户设置，在OpenStack各个服务配置中使用 | +| CINDER_PASS | cinder服务keystone用户的密码，在cinder配置中使用| +| CINDER_DBPASS | cinder服务数据库密码，在cinder配置中使用| +| KEYSTONE_DBPASS | keystone服务数据库密码，在keystone配置中使用| +| GLANCE_PASS | glance服务keystone用户的密码，在glance配置中使用| +| GLANCE_DBPASS | glance服务数据库密码，在glance配置中使用| +| HEAT_PASS | 在keystone注册的heat用户密码，在heat配置中使用| +| HEAT_DBPASS | heat服务数据库密码，在heat配置中使用 | +| CYBORG_PASS | 在keystone注册的cyborg用户密码，在cyborg配置中使用| +| CYBORG_DBPASS | cyborg服务数据库密码，在cyborg配置中使用 | +| NEUTRON_PASS | 在keystone注册的neutron用户密码，在neutron配置中使用| +| NEUTRON_DBPASS | neutron服务数据库密码，在neutron配置中使用 | +| PROVIDER_INTERFACE_NAME | 物理网络接口的名称，在neutron配置中使用 | +| OVERLAY_INTERFACE_IP_ADDRESS | Controller控制节点的管理ip地址，在neutron配置中使用 | +| METADATA_SECRET | metadata proxy的secret密码，在nova和neutron配置中使用 | +| PLACEMENT_DBPASS | placement服务数据库密码，在placement配置中使用 | +| PLACEMENT_PASS | 在keystone注册的placement用户密码，在placement配置中使用 | +| NOVA_DBPASS | nova服务数据库密码，在nova配置中使用 | +| NOVA_PASS | 在keystone注册的nova用户密码，在nova,cyborg,neutron等配置中使用 | +| IRONIC_DBPASS | ironic服务数据库密码，在ironic配置中使用 | +| IRONIC_PASS | 在keystone注册的ironic用户密码，在ironic配置中使用 | +| IRONIC_INSPECTOR_DBPASS | ironic-inspector服务数据库密码，在ironic-inspector配置中使用| +| IRONIC_INSPECTOR_PASS | 在keystone注册的ironic-inspector用户密码，在ironic-inspector配置中使用 | + +OpenStack SIG 提供了多种基于 openEuler 部署 OpenStack 的方法，以满足不同的用户场景，请按需选择。 + +## 基于RPM部署 + +### 环境准备 + +本文档基于OpenStack经典的三节点环境进行部署，三个节点分别是控制节点(Controller)、计算节点(Compute)、存储节点(Storage)，其中存储节点一般只部署存储服务，在资源有限的情况下，可以不单独部署该节点，把存储节点上的服务部署到计算节点即可。 + +首先准备三个|openEuler 25.03环境，根据您的环境，下载对应的镜像并安装即可：[ISO镜像]、[qcow2镜像]。 + +下面的安装按照如下拓扑进行： + +```shell +controller：192.168.0.2 +compute： 192.168.0.3 +storage： 192.168.0.4 +``` + +如果您的环境IP不同，请按照您的环境IP修改相应的配置文件。 + +本文档的三节点服务拓扑如下图所示(只包含Keystone、Glance、Nova、Cinder、Neutron这几个核心服务，其他服务请参考具体部署章节)： + +![topology1](../img/install/topology1.PNG) +![topology2](../img/install/topology2.PNG) +![topology3](../img/install/topology3.PNG) + +在正式部署之前，需要对每个节点做如下配置和检查： + +1. 配置 |openEuler 25.03 官方 yum 源，需要启用 EPOL 软件仓以支持 OpenStack + + ```shell + yum update + yum install openstack-release-antelope + yum clean all && yum makecache + ``` + + **注意**：如果你的环境的YUM源没有启用EPOL，需要同时配置EPOL，确保EPOL已配置，如下所示。 + + ```shell + vi /etc/yum.repos.d/openEuler.repo + + [EPOL] + name=EPOL + baseurl=http://repo.openeuler.org/openEuler-24.03-LTS-SP1/EPOL/main/$basearch/ + enabled=1 + gpgcheck=1 + gpgkey=http://repo.openeuler.org/openEuler-24.03-LTS-SP1/OS/$basearch/RPM-GPG-KEY-openEuler + EOF + ``` + +2. 修改主机名以及映射 + + 每个节点分别修改主机名，以controller为例： + + ```shell + hostnamectl set-hostname controller + + vi /etc/hostname + 内容修改为controller + ``` + + 然后修改每个节点的`/etc/hosts`文件，新增如下内容: + + ```shell + 192.168.0.2 controller + 192.168.0.3 compute + 192.168.0.4 storage + ``` + +#### 时钟同步 + +集群环境时刻要求每个节点的时间一致，一般由时钟同步软件保证。本文使用`chrony`软件。步骤如下： + +**Controller节点**： + +1. 安装服务 + + ```shell + dnf install chrony + ``` + +2. 修改`/etc/chrony.conf`配置文件，新增一行 + + ```shell + # 表示允许哪些IP从本节点同步时钟 + allow 192.168.0.0/24 + ``` + +3. 重启服务 + + ```shell + systemctl restart chronyd + ``` + +**其他节点** + +1. 安装服务 + + ```shell + dnf install chrony + ``` + +2. 修改`/etc/chrony.conf`配置文件，新增一行 + + ```shell + # NTP_SERVER是controller IP，表示从这个机器获取时间，这里我们填192.168.0.2，或者在`/etc/hosts`里配置好的controller名字即可。 + server NTP_SERVER iburst + ``` + + 同时，要把`pool pool.ntp.org iburst`这一行注释掉，表示不从公网同步时钟。 + +3. 重启服务 + + ```shell + systemctl restart chronyd + ``` + +配置完成后，检查一下结果，在其他非controller节点执行`chronyc sources`，返回结果类似如下内容，表示成功从controller同步时钟。 + +```ini +MS Name/IP address Stratum Poll Reach LastRx Last sample +=============================================================================== +^* 192.168.0.2 4 6 7 0 -1406ns[ +55us] +/- 16ms +``` + +#### 安装数据库 + +数据库安装在控制节点，这里推荐使用mariadb。 + +1. 安装软件包 + + ```shell + dnf install mysql-config mariadb mariadb-server python3-PyMySQL + ``` + +2. 新增配置文件`/etc/my.cnf.d/openstack.cnf`，内容如下 + + ```shell + [mysqld] + bind-address = 192.168.0.2 + default-storage-engine = innodb + innodb_file_per_table = on + max_connections = 4096 + collation-server = utf8_general_ci + character-set-server = utf8 + ``` + +3. 启动服务器 + + ```shell + systemctl start mariadb + ``` + +4. 初始化数据库，根据提示进行即可 + + ```shell + mysql_secure_installation + ``` + + 示例如下： + + ```shell + NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB + SERVERS IN PRODUCTION USE! PLEASE READ EACH STEP CAREFULLY! + + In order to log into MariaDB to secure it, we'll need the current + password for the root user. If you've just installed MariaDB, and + haven't set the root password yet, you should just press enter here. + + Enter current password for root (enter for none): + + #这里输入密码，由于我们是初始化DB，直接回车就行 + + OK, successfully used password, moving on... + + Setting the root password or using the unix_socket ensures that nobody + can log into the MariaDB root user without the proper authorisation. + + You already have your root account protected, so you can safely answer 'n'. + + # 这里根据提示输入N + + Switch to unix_socket authentication [Y/n] N + + Enabled successfully! + Reloading privilege tables.. + ... Success! + + + You already have your root account protected, so you can safely answer 'n'. + + # 输入Y，修改密码 + + Change the root password? [Y/n] Y + + New password: + Re-enter new password: + Password updated successfully! + Reloading privilege tables.. + ... Success! + + + By default, a MariaDB installation has an anonymous user, allowing anyone + to log into MariaDB without having to have a user account created for + them. This is intended only for testing, and to make the installation + go a bit smoother. You should remove them before moving into a + production environment. + + # 输入Y，删除匿名用户 + + Remove anonymous users? [Y/n] Y + ... Success! + + Normally, root should only be allowed to connect from 'localhost'. This + ensures that someone cannot guess at the root password from the network. + + # 输入Y，关闭root远程登录权限 + + Disallow root login remotely? [Y/n] Y + ... Success! + + By default, MariaDB comes with a database named 'test' that anyone can + access. This is also intended only for testing, and should be removed + before moving into a production environment. + + # 输入Y，删除test数据库 + + Remove test database and access to it? [Y/n] Y + - Dropping test database... + ... Success! + - Removing privileges on test database... + ... Success! + + Reloading the privilege tables will ensure that all changes made so far + will take effect immediately. + + # 输入Y，重载配置 + + Reload privilege tables now? [Y/n] Y + ... Success! + + Cleaning up... + + All done! If you've completed all of the above steps, your MariaDB + installation should now be secure. + ``` + +5. 验证，根据第四步设置的密码，检查是否能登录mariadb + + ```shell + mysql -uroot -p + ``` + +#### 安装消息队列 + +消息队列安装在控制节点，这里推荐使用rabbitmq。 + +1. 安装软件包 + + ```shell + dnf install rabbitmq-server + ``` + +2. 启动服务 + + ```shell + systemctl start rabbitmq-server + ``` + +3. 配置openstack用户，`RABBIT_PASS`是openstack服务登录消息队里的密码，需要和后面各个服务的配置保持一致。 + + ```shell + rabbitmqctl add_user openstack RABBIT_PASS + rabbitmqctl set_permissions openstack ".*" ".*" ".*" + ``` + +#### 安装缓存服务 + +缓存服务安装在控制节点，这里推荐使用Memcached。 + +1. 安装软件包 + + ```shell + dnf install memcached python3-memcached + ``` + +2. 修改配置文件`/etc/sysconfig/memcached` + + ```shell + OPTIONS="-l 127.0.0.1,::1,controller" + ``` + +3. 启动服务 + + ```shell + systemctl start memcached + ``` + +### 部署服务 + +#### Keystone + +Keystone是OpenStack提供的鉴权服务，是整个OpenStack的入口，提供了租户隔离、用户认证、服务发现等功能，必须安装。 + +1. 创建 keystone 数据库并授权 + + ``` sql + mysql -u root -p + + MariaDB [(none)]> CREATE DATABASE keystone; + MariaDB [(none)]> GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'localhost' \ + IDENTIFIED BY 'KEYSTONE_DBPASS'; + MariaDB [(none)]> GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'%' \ + IDENTIFIED BY 'KEYSTONE_DBPASS'; + MariaDB [(none)]> exit + ``` + + ***注意*** + + **替换 `KEYSTONE_DBPASS`，为 Keystone 数据库设置密码** + +2. 安装软件包 + + ```shell + dnf install openstack-keystone httpd mod_wsgi + ``` + +3. 配置keystone相关配置 + + ```shell + vim /etc/keystone/keystone.conf + + [database] + connection = mysql+pymysql://keystone:KEYSTONE_DBPASS@controller/keystone + + [token] + provider = fernet + ``` + + ***解释*** + + [database]部分，配置数据库入口 + + [token]部分，配置token provider + +4. 同步数据库 + + ```shell + su -s /bin/sh -c "keystone-manage db_sync" keystone + ``` + +5. 初始化Fernet密钥仓库 + + ```shell + keystone-manage fernet_setup --keystone-user keystone --keystone-group keystone + keystone-manage credential_setup --keystone-user keystone --keystone-group keystone + ``` + +6. 启动服务 + + ```shell + keystone-manage bootstrap --bootstrap-password ADMIN_PASS \ + --bootstrap-admin-url http://controller:5000/v3/ \ + --bootstrap-internal-url http://controller:5000/v3/ \ + --bootstrap-public-url http://controller:5000/v3/ \ + --bootstrap-region-id RegionOne + ``` + + ***注意*** + + **替换 `ADMIN_PASS`，为 admin 用户设置密码** + +7. 配置Apache HTTP server + + - 打开httpd.conf并配置 + + ```shell + #需要修改的配置文件路径 + vim /etc/httpd/conf/httpd.conf + + #修改以下项，如果没有则新添加 + ServerName controller + ``` + + - 创建软链接 + + ```shell + ln -s /usr/share/keystone/wsgi-keystone.conf /etc/httpd/conf.d/ + ``` + + ***解释*** + + 配置 `ServerName` 项引用控制节点 + + ***注意*** + **如果 `ServerName` 项不存在则需要创建** + +8. 启动Apache HTTP服务 + + ```shell + systemctl enable httpd.service + systemctl start httpd.service + ``` + +9. 创建环境变量配置 + + ```shell + cat << EOF >> ~/.admin-openrc + export OS_PROJECT_DOMAIN_NAME=Default + export OS_USER_DOMAIN_NAME=Default + export OS_PROJECT_NAME=admin + export OS_USERNAME=admin + export OS_PASSWORD=ADMIN_PASS + export OS_AUTH_URL=http://controller:5000/v3 + export OS_IDENTITY_API_VERSION=3 + export OS_IMAGE_API_VERSION=2 + EOF + ``` + + ***注意*** + + **替换 `ADMIN_PASS` 为 admin 用户的密码** + +10. 依次创建domain, projects, users, roles + + - 需要先安装python3-openstackclient + + ```shell + dnf install python3-openstackclient + ``` + + - 导入环境变量 + + ```shell + source ~/.admin-openrc + ``` + + - 创建project `service`，其中 domain `default` 在 keystone-manage bootstrap 时已创建 + + ```shell + openstack domain create --description "An Example Domain" example + ``` + + ```shell + openstack project create --domain default --description "Service Project" service + ``` + + - 创建（non-admin）project `myproject`，user `myuser` 和 role `myrole`，为 `myproject` 和 `myuser` 添加角色`myrole` + + ```shell + openstack project create --domain default --description "Demo Project" myproject + openstack user create --domain default --password-prompt myuser + openstack role create myrole + openstack role add --project myproject --user myuser myrole + ``` + +11. 验证 + + - 取消临时环境变量OS_AUTH_URL和OS_PASSWORD： + + ```shell + source ~/.admin-openrc + unset OS_AUTH_URL OS_PASSWORD + ``` + + - 为admin用户请求token： + + ```shell + openstack --os-auth-url http://controller:5000/v3 \ + --os-project-domain-name Default --os-user-domain-name Default \ + --os-project-name admin --os-username admin token issue + ``` + + - 为myuser用户请求token： + + ```shell + openstack --os-auth-url http://controller:5000/v3 \ + --os-project-domain-name Default --os-user-domain-name Default \ + --os-project-name myproject --os-username myuser token issue + ``` + +#### Glance + +Glance是OpenStack提供的镜像服务，负责虚拟机、裸机镜像的上传与下载，必须安装。 + +**Controller节点**： + +1. 创建 glance 数据库并授权 + + ```sql + mysql -u root -p + + MariaDB [(none)]> CREATE DATABASE glance; + MariaDB [(none)]> GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'localhost' \ + IDENTIFIED BY 'GLANCE_DBPASS'; + MariaDB [(none)]> GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'%' \ + IDENTIFIED BY 'GLANCE_DBPASS'; + MariaDB [(none)]> exit + ``` + + ***注意:*** + + **替换 `GLANCE_DBPASS`，为 glance 数据库设置密码** + +2. 初始化 glance 资源对象 + + - 导入环境变量 + + ```shell + source ~/.admin-openrc + ``` + + - 创建用户时，命令行会提示输入密码，请输入自定义的密码，下文涉及到`GLANCE_PASS`的地方替换成该密码即可。 + + ```shell + openstack user create --domain default --password-prompt glance + User Password: + Repeat User Password: + ``` + + - 添加glance用户到service project并指定admin角色： + + ```shell + openstack role add --project service --user glance admin + ``` + + - 创建glance服务实体： + + ```shell + openstack service create --name glance --description "OpenStack Image" image + ``` + + - 创建glance API服务： + + ```shell + openstack endpoint create --region RegionOne image public http://controller:9292 + openstack endpoint create --region RegionOne image internal http://controller:9292 + openstack endpoint create --region RegionOne image admin http://controller:9292 + ``` + +3. 安装软件包 + + ```shell + dnf install openstack-glance + ``` + +4. 修改 glance 配置文件 + + ```shell + vim /etc/glance/glance-api.conf + + [database] + connection = mysql+pymysql://glance:GLANCE_DBPASS@controller/glance + + [keystone_authtoken] + www_authenticate_uri = http://controller:5000 + auth_url = http://controller:5000 + memcached_servers = controller:11211 + auth_type = password + project_domain_name = Default + user_domain_name = Default + project_name = service + username = glance + password = GLANCE_PASS + + [paste_deploy] + flavor = keystone + + [glance_store] + stores = file,http + default_store = file + filesystem_store_datadir = /var/lib/glance/images/ + ``` + + ***解释:*** + + [database]部分，配置数据库入口 + + [keystone_authtoken] [paste_deploy]部分，配置身份认证服务入口 + + [glance_store]部分，配置本地文件系统存储和镜像文件的位置 + +5. 同步数据库 + + ```shell + su -s /bin/sh -c "glance-manage db_sync" glance + ``` + +6. 启动服务： + + ```shell + systemctl enable openstack-glance-api.service + systemctl start openstack-glance-api.service + ``` + +7. 验证 + + - 导入环境变量 + + ```shell + source ~/.admin-openrcu + ``` + + - 下载镜像 + + ```shell + x86镜像下载： + wget http://download.cirros-cloud.net/0.4.0/cirros-0.4.0-x86_64-disk.img + + arm镜像下载： + wget http://download.cirros-cloud.net/0.4.0/cirros-0.4.0-aarch64-disk.img + ``` + + ***注意*** + + **如果您使用的环境是鲲鹏架构，请下载aarch64版本的镜像；已对镜像cirros-0.5.2-aarch64-disk.img进行测试。** + + - 向Image服务上传镜像： + + ```shell + openstack image create --disk-format qcow2 --container-format bare \ + --file cirros-0.4.0-x86_64-disk.img --public cirros + ``` + + - 确认镜像上传并验证属性： + + ```shell + openstack image list + ``` + +#### Placement + +Placement是OpenStack提供的资源调度组件，一般不面向用户，由Nova等组件调用，安装在控制节点。 + +安装、配置Placement服务前，需要先创建相应的数据库、服务凭证和API endpoints。 + +1. 创建数据库 + + - 使用root用户访问数据库服务： + + ```shell + mysql -u root -p + ``` + + - 创建placement数据库： + + ```sql + MariaDB [(none)]> CREATE DATABASE placement; + ``` + + - 授权数据库访问： + + ```sql + MariaDB [(none)]> GRANT ALL PRIVILEGES ON placement.* TO 'placement'@'localhost' \ + IDENTIFIED BY 'PLACEMENT_DBPASS'; + MariaDB [(none)]> GRANT ALL PRIVILEGES ON placement.* TO 'placement'@'%' \ + IDENTIFIED BY 'PLACEMENT_DBPASS'; + ``` + + 替换`PLACEMENT_DBPASS`为placement数据库访问密码。 + + - 退出数据库访问客户端： + + ```shell + exit + ``` + +2. 配置用户和Endpoints + + - source admin凭证，以获取admin命令行权限： + + ```shell + source ~/.admin-openrc + ``` + + - 创建placement用户并设置用户密码： + + ```shell + openstack user create --domain default --password-prompt placement + + User Password: + Repeat User Password: + ``` + + - 添加placement用户到service project并指定admin角色： + + ```shell + openstack role add --project service --user placement admin + ``` + + - 创建placement服务实体： + + ```shell + openstack service create --name placement \ + --description "Placement API" placement + ``` + + - 创建Placement API服务endpoints： + + ```shell + openstack endpoint create --region RegionOne \ + placement public http://controller:8778 + openstack endpoint create --region RegionOne \ + placement internal http://controller:8778 + openstack endpoint create --region RegionOne \ + placement admin http://controller:8778 + ``` + +3. 安装及配置组件 + + - 安装软件包： + + ```shell + dnf install openstack-placement-api + ``` + + - 编辑`/etc/placement/placement.conf`配置文件，完成如下操作： + + - 在`[placement_database]`部分，配置数据库入口： + + ```ini + [placement_database] + connection = mysql+pymysql://placement:PLACEMENT_DBPASS@controller/placement + ``` + + 替换`PLACEMENT_DBPASS`为placement数据库的密码。 + + - 在`[api]`和`[keystone_authtoken]`部分，配置身份认证服务入口： + + ```ini + [api] + auth_strategy = keystone + + [keystone_authtoken] + auth_url = http://controller:5000/v3 + memcached_servers = controller:11211 + auth_type = password + project_domain_name = Default + user_domain_name = Default + project_name = service + username = placement + password = PLACEMENT_PASS + ``` + + 替换`PLACEMENT_PASS`为placement用户的密码。 + + - 数据库同步，填充Placement数据库： + + ```shell + su -s /bin/sh -c "placement-manage db sync" placement + ``` + +4. 启动服务 + + 重启httpd服务： + + ```shell + systemctl restart httpd + ``` + +5. 验证 + + - source admin凭证，以获取admin命令行权限 + + ```shell + source ~/.admin-openrc + ``` + + - 执行状态检查： + + ```shell + placement-status upgrade check + ``` + + ```ini + +----------------------------------------------------------------------+ + | Upgrade Check Results | + +----------------------------------------------------------------------+ + | Check: Missing Root Provider IDs | + | Result: Success | + | Details: None | + +----------------------------------------------------------------------+ + | Check: Incomplete Consumers | + | Result: Success | + | Details: None | + +----------------------------------------------------------------------+ + | Check: Policy File JSON to YAML Migration | + | Result: Failure | + | Details: Your policy file is JSON-formatted which is deprecated. You | + | need to switch to YAML-formatted file. Use the | + | ``oslopolicy-convert-json-to-yaml`` tool to convert the | + | existing JSON-formatted files to YAML in a backwards- | + | compatible manner: https://docs.openstack.org/oslo.policy/ | + | latest/cli/oslopolicy-convert-json-to-yaml.html. | + +----------------------------------------------------------------------+ + ``` + + 这里可以看到``Policy File JSON to YAML Migration``的结果为Failure。这是因为在Placement中，JSON格式的policy文件从Wallaby版本开始已处于`deprecated`状态。可以参考提示，使用[oslopolicy-convert-json-to-yaml](https://docs.openstack.org/oslo.policy/latest/cli/oslopolicy-convert-json-to-yaml.html)工具 将现有的JSON格式policy文件转化为YAML格式。 + + ```shell + oslopolicy-convert-json-to-yaml --namespace placement \ + --policy-file /etc/placement/policy.json \ + --output-file /etc/placement/policy.yaml + mv /etc/placement/policy.json{,.bak} + ``` + + 注：当前环境中此问题可忽略，不影响运行。 + + - 针对placement API运行命令： + + - 安装osc-placement插件： + + ```shell + dnf install python3-osc-placement + ``` + + - 列出可用的资源类别及特性： + + ```shell + openstack --os-placement-api-version 1.2 resource class list --sort-column name + +----------------------------+ + | name | + +----------------------------+ + | DISK_GB | + | FPGA | + | ... | + + openstack --os-placement-api-version 1.6 trait list --sort-column name + +---------------------------------------+ + | name | + +---------------------------------------+ + | COMPUTE_ACCELERATORS | + | COMPUTE_ARCH_AARCH64 | + | ... | + ``` + +#### Nova + +Nova是OpenStack的计算服务，负责虚拟机的创建、发放等功能。 + +**Controller节点** + +在控制节点执行以下操作。 + +1. 创建数据库 + + - 使用root用户访问数据库服务： + + ```shell + mysql -u root -p + ``` + + - 创建`nova_api`、`nova`和`nova_cell0`数据库： + + ```sql + MariaDB [(none)]> CREATE DATABASE nova_api; + MariaDB [(none)]> CREATE DATABASE nova; + MariaDB [(none)]> CREATE DATABASE nova_cell0; + ``` + + - 授权数据库访问： + + ```sql + MariaDB [(none)]> GRANT ALL PRIVILEGES ON nova_api.* TO 'nova'@'localhost' \ + IDENTIFIED BY 'NOVA_DBPASS'; + MariaDB [(none)]> GRANT ALL PRIVILEGES ON nova_api.* TO 'nova'@'%' \ + IDENTIFIED BY 'NOVA_DBPASS'; + + MariaDB [(none)]> GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'localhost' \ + IDENTIFIED BY 'NOVA_DBPASS'; + MariaDB [(none)]> GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'%' \ + IDENTIFIED BY 'NOVA_DBPASS'; + + MariaDB [(none)]> GRANT ALL PRIVILEGES ON nova_cell0.* TO 'nova'@'localhost' \ + IDENTIFIED BY 'NOVA_DBPASS'; + MariaDB [(none)]> GRANT ALL PRIVILEGES ON nova_cell0.* TO 'nova'@'%' \ + IDENTIFIED BY 'NOVA_DBPASS'; + ``` + + 替换`NOVA_DBPASS`为nova相关数据库访问密码。 + + - 退出数据库访问客户端： + + ```sql + exit + ``` + +2. 配置用户和Endpoints + + - source admin凭证，以获取admin命令行权限： + + ```shell + source ~/.admin-openrc + ``` + + - 创建nova用户并设置用户密码： + + ```shell + openstack user create --domain default --password-prompt nova + + User Password: + Repeat User Password: + ``` + + - 添加nova用户到service project并指定admin角色： + + ```shell + openstack role add --project service --user nova admin + ``` + + - 创建nova服务实体： + + ```shell + openstack service create --name nova \ + --description "OpenStack Compute" compute + ``` + + - 创建Nova API服务endpoints： + + ```shell + openstack endpoint create --region RegionOne \ + compute public http://controller:8774/v2.1 + openstack endpoint create --region RegionOne \ + compute internal http://controller:8774/v2.1 + openstack endpoint create --region RegionOne \ + compute admin http://controller:8774/v2.1 + ``` + +3. 安装及配置组件 + + - 安装软件包： + + ```shell + dnf install openstack-nova-api openstack-nova-conductor \ + openstack-nova-novncproxy openstack-nova-scheduler + ``` + + - 编辑`/etc/nova/nova.conf`配置文件，完成如下操作： + + - 在`[default]`部分，启用计算和元数据的API，配置RabbitMQ消息队列入口，使用controller节点管理IP配置my_ip，显式定义log_dir： + + ```ini + [DEFAULT] + enabled_apis = osapi_compute,metadata + transport_url = rabbit://openstack:RABBIT_PASS@controller:5672/ + my_ip = 192.168.0.2 + log_dir = /var/log/nova + state_path = /var/lib/nova + ``` + + 替换`RABBIT_PASS`为RabbitMQ中openstack账户的密码。 + + - 在`[api_database]`和`[database]`部分，配置数据库入口： + + ```ini + [api_database] + connection = mysql+pymysql://nova:NOVA_DBPASS@controller/nova_api + + [database] + connection = mysql+pymysql://nova:NOVA_DBPASS@controller/nova + ``` + + 替换`NOVA_DBPASS`为nova相关数据库的密码。 + + - 在`[api]`和`[keystone_authtoken]`部分，配置身份认证服务入口： + + ```ini + [api] + auth_strategy = keystone + + [keystone_authtoken] + auth_url = http://controller:5000/v3 + memcached_servers = controller:11211 + auth_type = password + project_domain_name = Default + user_domain_name = Default + project_name = service + username = nova + password = NOVA_PASS + ``` + + 替换`NOVA_PASS`为nova用户的密码。 + + - 在`[vnc]`部分，启用并配置远程控制台入口： + + ```ini + [vnc] + enabled = true + server_listen = $my_ip + server_proxyclient_address = $my_ip + ``` + + - 在`[glance]`部分，配置镜像服务API的地址： + + ```ini + [glance] + api_servers = http://controller:9292 + ``` + + - 在`[oslo_concurrency]`部分，配置lock path： + + ```ini + [oslo_concurrency] + lock_path = /var/lib/nova/tmp + ``` + + - [placement]部分，配置placement服务的入口： + + ```ini + [placement] + region_name = RegionOne + project_domain_name = Default + project_name = service + auth_type = password + user_domain_name = Default + auth_url = http://controller:5000/v3 + username = placement + password = PLACEMENT_PASS + ``` + + 替换`PLACEMENT_PASS`为placement用户的密码。 + + - 数据库同步： + + - 同步nova-api数据库： + + ```shell + su -s /bin/sh -c "nova-manage api_db sync" nova + ``` + + - 注册cell0数据库： + + ```shell + su -s /bin/sh -c "nova-manage cell_v2 map_cell0" nova + ``` + + - 创建cell1 cell： + + ```shell + su -s /bin/sh -c "nova-manage cell_v2 create_cell --name=cell1 --verbose" nova + ``` + + - 同步nova数据库： + + ```shell + su -s /bin/sh -c "nova-manage db sync" nova + ``` + + - 验证cell0和cell1注册正确： + + ```shell + su -s /bin/sh -c "nova-manage cell_v2 list_cells" nova + ``` + +4. 启动服务 + + ```shell + systemctl enable \ + openstack-nova-api.service \ + openstack-nova-scheduler.service \ + openstack-nova-conductor.service \ + openstack-nova-novncproxy.service + + systemctl start \ + openstack-nova-api.service \ + openstack-nova-scheduler.service \ + openstack-nova-conductor.service \ + openstack-nova-novncproxy.service + ``` + +**Compute节点** + +在计算节点执行以下操作。 + +1. 安装软件包 + + ```shell + dnf install openstack-nova-compute + ``` + +2. 编辑`/etc/nova/nova.conf`配置文件 + + - 在`[default]`部分，启用计算和元数据的API，配置RabbitMQ消息队列入口，使用Compute节点管理IP配置my_ip，显式定义compute_driver、instances_path、log_dir： + + ```ini + [DEFAULT] + enabled_apis = osapi_compute,metadata + transport_url = rabbit://openstack:RABBIT_PASS@controller:5672/ + my_ip = 192.168.0.3 + compute_driver = libvirt.LibvirtDriver + instances_path = /var/lib/nova/instances + log_dir = /var/log/nova + ``` + + 替换`RABBIT_PASS`为RabbitMQ中openstack账户的密码。 + + - 在`[api]`和`[keystone_authtoken]`部分，配置身份认证服务入口： + + ```ini + [api] + auth_strategy = keystone + + [keystone_authtoken] + auth_url = http://controller:5000/v3 + memcached_servers = controller:11211 + auth_type = password + project_domain_name = Default + user_domain_name = Default + project_name = service + username = nova + password = NOVA_PASS + ``` + + 替换`NOVA_PASS`为nova用户的密码。 + + - 在`[vnc]`部分，启用并配置远程控制台入口： + + ```ini + [vnc] + enabled = true + server_listen = $my_ip + server_proxyclient_address = $my_ip + novncproxy_base_url = http://controller:6080/vnc_auto.html + ``` + + - 在`[glance]`部分，配置镜像服务API的地址： + + ```ini + [glance] + api_servers = http://controller:9292 + ``` + + - 在`[oslo_concurrency]`部分，配置lock path： + + ```ini + [oslo_concurrency] + lock_path = /var/lib/nova/tmp + ``` + + - [placement]部分，配置placement服务的入口： + + ```ini + [placement] + region_name = RegionOne + project_domain_name = Default + project_name = service + auth_type = password + user_domain_name = Default + auth_url = http://controller:5000/v3 + username = placement + password = PLACEMENT_PASS + ``` + + 替换`PLACEMENT_PASS`为placement用户的密码。 + +3. 确认计算节点是否支持虚拟机硬件加速（x86_64） + + 处理器为x86_64架构时，可通过运行如下命令确认是否支持硬件加速： + + ```shell + egrep -c '(vmx|svm)' /proc/cpuinfo + ``` + + 如果返回值为0则不支持硬件加速，需要配置libvirt使用QEMU而不是默认的KVM。编辑`/etc/nova/nova.conf`的`[libvirt]`部分： + + ```ini + [libvirt] + virt_type = qemu + ``` + + 如果返回值为1或更大的值，则支持硬件加速，不需要进行额外的配置。 + +4. 确认计算节点是否支持虚拟机硬件加速（arm64） + + 处理器为arm64架构时，可通过运行如下命令确认是否支持硬件加速： + + ```shell + virt-host-validate + # 该命令由libvirt提供，此时libvirt应已作为openstack-nova-compute依赖被安装，环境中已有此命令 + ``` + + 显示FAIL时，表示不支持硬件加速，需要配置libvirt使用QEMU而不是默认的KVM。 + + ```shell + QEMU: Checking if device /dev/kvm exists: FAIL (Check that CPU and firmware supports virtualization and kvm module is loaded) + ``` + + 编辑`/etc/nova/nova.conf`的`[libvirt]`部分： + + ```ini + [libvirt] + virt_type = qemu + ``` + + 显示PASS时，表示支持硬件加速，不需要进行额外的配置。 + + ```shell + QEMU: Checking if device /dev/kvm exists: PASS + ``` + +5. 配置qemu（仅arm64） + + 仅当处理器为arm64架构时需要执行此操作。 + + - 编辑`/etc/libvirt/qemu.conf`: + + ```ini + nvram = ["/usr/share/AAVMF/AAVMF_CODE.fd: \ + /usr/share/AAVMF/AAVMF_VARS.fd", \ + "/usr/share/edk2/aarch64/QEMU_EFI-pflash.raw: \ + /usr/share/edk2/aarch64/vars-template-pflash.raw"] + ``` + + - 编辑`/etc/qemu/firmware/edk2-aarch64.json` + + ```json + { + "description": "UEFI firmware for ARM64 virtual machines", + "interface-types": [ + "uefi" + ], + "mapping": { + "device": "flash", + "executable": { + "filename": "/usr/share/edk2/aarch64/QEMU_EFI-pflash.raw", + "format": "raw" + }, + "nvram-template": { + "filename": "/usr/share/edk2/aarch64/vars-template-pflash.raw", + "format": "raw" + } + }, + "targets": [ + { + "architecture": "aarch64", + "machines": [ + "virt-*" + ] + } + ], + "features": [ + + ], + "tags": [ + + ] + } + ``` + +6. 启动服务 + + ```shell + systemctl enable libvirtd.service openstack-nova-compute.service + systemctl start libvirtd.service openstack-nova-compute.service + ``` + +**Controller节点** + +在控制节点执行以下操作。 + +1. 添加计算节点到openstack集群 + + - source admin凭证，以获取admin命令行权限： + + ```shell + source ~/.admin-openrc + ``` + + - 确认nova-compute服务已识别到数据库中： + + ```shell + openstack compute service list --service nova-compute + ``` + + - 发现计算节点，将计算节点添加到cell数据库： + + ```shell + su -s /bin/sh -c "nova-manage cell_v2 discover_hosts --verbose" nova + ``` + + 结果如下： + + ```ini + Modules with known eventlet monkey patching issues were imported prior to eventlet monkey patching: urllib3. This warning can usually be ignored if the caller is only importing and not executing nova code. + Found 2 cell mappings. + Skipping cell0 since it does not contain hosts. + Getting computes from cell 'cell1': 6dae034e-b2d9-4a6c-b6f0-60ada6a6ddc2 + Checking host mapping for compute host 'compute': 6286a86f-09d7-4786-9137-1185654c9e2e + Creating host mapping for compute host 'compute': 6286a86f-09d7-4786-9137-1185654c9e2e + Found 1 unmapped computes in cell: 6dae034e-b2d9-4a6c-b6f0-60ada6a6ddc2 + ``` + +2. 验证 + + - 列出服务组件，验证每个流程都成功启动和注册： + + ```shell + openstack compute service list + ``` + + - 列出身份服务中的API端点，验证与身份服务的连接： + + ```shell + openstack catalog list + ``` + + - 列出镜像服务中的镜像，验证与镜像服务的连接： + + ```shell + openstack image list + ``` + + - 检查cells是否运作成功，以及其他必要条件是否已具备。 + + ```shell + nova-status upgrade check + ``` + +#### Neutron + +Neutron是OpenStack的网络服务，提供虚拟交换机、IP路由、DHCP等功能。 + +**Controller节点** + +1. 创建数据库、服务凭证和 API 服务端点 + + - 创建数据库： + + ```sql + mysql -u root -p + + MariaDB [(none)]> CREATE DATABASE neutron; + MariaDB [(none)]> GRANT ALL PRIVILEGES ON neutron.* TO 'neutron'@'localhost' IDENTIFIED BY 'NEUTRON_DBPASS'; + MariaDB [(none)]> GRANT ALL PRIVILEGES ON neutron.* TO 'neutron'@'%' IDENTIFIED BY 'NEUTRON_DBPASS'; + MariaDB [(none)]> exit; + ``` + + - 创建用户和服务，并记住创建neutron用户时输入的密码，用于配置NEUTRON_PASS： + + ```shell + source ~/.admin-openrc + openstack user create --domain default --password-prompt neutron + openstack role add --project service --user neutron admin + openstack service create --name neutron --description "OpenStack Networking" network + ``` + + - 部署 Neutron API 服务： + + ```shell + openstack endpoint create --region RegionOne network public http://controller:9696 + openstack endpoint create --region RegionOne network internal http://controller:9696 + openstack endpoint create --region RegionOne network admin http://controller:9696 + ``` + +2. 安装软件包 + + ```shell + dnf install -y openstack-neutron openstack-neutron-linuxbridge ebtables ipset openstack-neutron-ml2 + ``` + +3. 配置Neutron + + - 修改/etc/neutron/neutron.conf + + ```ini + [database] + connection = mysql+pymysql://neutron:NEUTRON_DBPASS@controller/neutron + + [DEFAULT] + core_plugin = ml2 + service_plugins = router + allow_overlapping_ips = true + transport_url = rabbit://openstack:RABBIT_PASS@controller + auth_strategy = keystone + notify_nova_on_port_status_changes = true + notify_nova_on_port_data_changes = true + + [keystone_authtoken] + www_authenticate_uri = http://controller:5000 + auth_url = http://controller:5000 + memcached_servers = controller:11211 + auth_type = password + project_domain_name = Default + user_domain_name = Default + project_name = service + username = neutron + password = NEUTRON_PASS + + [nova] + auth_url = http://controller:5000 + auth_type = password + project_domain_name = Default + user_domain_name = Default + region_name = RegionOne + project_name = service + username = nova + password = NOVA_PASS + + [oslo_concurrency] + lock_path = /var/lib/neutron/tmp + + [experimental] + linuxbridge = true + ``` + + - 配置ML2，ML2具体配置可以根据用户需求自行修改，本文使用的是provider network + linuxbridge** + + - 修改/etc/neutron/plugins/ml2/ml2_conf.ini + + ```shell + [ml2] + type_drivers = flat,vlan,vxlan + tenant_network_types = vxlan + mechanism_drivers = linuxbridge,l2population + extension_drivers = port_security + + [ml2_type_flat] + flat_networks = provider + + [ml2_type_vxlan] + vni_ranges = 1:1000 + + [securitygroup] + enable_ipset = true + ``` + + - 修改/etc/neutron/plugins/ml2/linuxbridge_agent.ini + + ```ini + [linux_bridge] + physical_interface_mappings = provider:PROVIDER_INTERFACE_NAME + + [vxlan] + enable_vxlan = true + local_ip = OVERLAY_INTERFACE_IP_ADDRESS + l2_population = true + + [securitygroup] + enable_security_group = true + firewall_driver = neutron.agent.linux.iptables_firewall.IptablesFirewallDriver + ``` + + - 配置Layer-3代理 + + - 修改/etc/neutron/l3_agent.ini + + ```shell + [DEFAULT] + interface_driver = linuxbridge + ``` + + 配置DHCP代理 + 修改/etc/neutron/dhcp_agent.ini + + ```ini + [DEFAULT] + interface_driver = linuxbridge + dhcp_driver = neutron.agent.linux.dhcp.Dnsmasq + enable_isolated_metadata = true + ``` + + - 配置metadata代理 + + - 修改/etc/neutron/metadata_agent.ini + + ```shell + [DEFAULT] + nova_metadata_host = controller + metadata_proxy_shared_secret = METADATA_SECRET + ``` + +4. 配置nova服务使用neutron，修改/etc/nova/nova.conf + + ```ini + [neutron] + auth_url = http://controller:5000 + auth_type = password + project_domain_name = default + user_domain_name = default + region_name = RegionOne + project_name = service + username = neutron + password = NEUTRON_PASS + service_metadata_proxy = true + metadata_proxy_shared_secret = METADATA_SECRET + ``` + +5. 创建/etc/neutron/plugin.ini的符号链接 + + ```shell + ln -s /etc/neutron/plugins/ml2/ml2_conf.ini /etc/neutron/plugin.ini + ``` + +6. 同步数据库 + + ```shell + su -s /bin/sh -c "neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head" neutron + ``` + +7. 重启nova api服务 + + ```shell + systemctl restart openstack-nova-api + ``` + +8. 启动网络服务 + + ```shell + systemctl enable neutron-server.service neutron-linuxbridge-agent.service \ + neutron-dhcp-agent.service neutron-metadata-agent.service neutron-l3-agent.service + systemctl start neutron-server.service neutron-linuxbridge-agent.service \ + neutron-dhcp-agent.service neutron-metadata-agent.service neutron-l3-agent.service + ``` + +**Compute节点** + +1. 安装软件包 + + ```shell + dnf install openstack-neutron-linuxbridge ebtables ipset -y + ``` + +2. 配置Neutron + + - 修改/etc/neutron/neutron.conf + + ```ini + [DEFAULT] + transport_url = rabbit://openstack:RABBIT_PASS@controller + auth_strategy = keystone + + [keystone_authtoken] + www_authenticate_uri = http://controller:5000 + auth_url = http://controller:5000 + memcached_servers = controller:11211 + auth_type = password + project_domain_name = Default + user_domain_name = Default + project_name = service + username = neutron + password = NEUTRON_PASS + + [oslo_concurrency] + lock_path = /var/lib/neutron/tmp + ``` + + - 修改/etc/neutron/plugins/ml2/linuxbridge_agent.ini + + ```ini + [linux_bridge] + physical_interface_mappings = provider:PROVIDER_INTERFACE_NAME + + [vxlan] + enable_vxlan = true + local_ip = OVERLAY_INTERFACE_IP_ADDRESS + l2_population = true + + [securitygroup] + enable_security_group = true + firewall_driver = neutron.agent.linux.iptables_firewall.IptablesFirewallDriver + ``` + + - 配置nova compute服务使用neutron，修改/etc/nova/nova.conf + + ```ini + [neutron] + auth_url = http://controller:5000 + auth_type = password + project_domain_name = default + user_domain_name = default + region_name = RegionOne + project_name = service + username = neutron + password = NEUTRON_PASS + ``` + +3. 重启nova-compute服务 + + ```shell + systemctl restart openstack-nova-compute.service + ``` + +4. 启动Neutron linuxbridge agent服务 + + ```shell + systemctl enable neutron-linuxbridge-agent + systemctl start neutron-linuxbridge-agent + ``` + +#### Cinder + +Cinder是OpenStack的存储服务，提供块设备的创建、发放、备份等功能。 + +**Controller节点**： + +1. 初始化数据库 + + `CINDER_DBPASS`是用户自定义的cinder数据库密码。 + + ```sql + mysql -u root -p + + MariaDB [(none)]> CREATE DATABASE cinder; + MariaDB [(none)]> GRANT ALL PRIVILEGES ON cinder.* TO 'cinder'@'localhost' IDENTIFIED BY 'CINDER_DBPASS'; + MariaDB [(none)]> GRANT ALL PRIVILEGES ON cinder.* TO 'cinder'@'%' IDENTIFIED BY 'CINDER_DBPASS'; + MariaDB [(none)]> exit + ``` + +2. 初始化Keystone资源对象 + + ```shell + source ~/.admin-openrc + + #创建用户时，命令行会提示输入密码，请输入自定义的密码，下文涉及到`CINDER_PASS`的地方替换成该密码即可。 + openstack user create --domain default --password-prompt cinder + + openstack role add --project service --user cinder admin + openstack service create --name cinderv3 --description "OpenStack Block Storage" volumev3 + + openstack endpoint create --region RegionOne volumev3 public http://controller:8776/v3/%\(project_id\)s + openstack endpoint create --region RegionOne volumev3 internal http://controller:8776/v3/%\(project_id\)s + openstack endpoint create --region RegionOne volumev3 admin http://controller:8776/v3/%\(project_id\)s + ``` + +3. 安装软件包 + + ```shell + dnf install openstack-cinder-api openstack-cinder-scheduler + ``` + +4. 修改cinder配置文件`/etc/cinder/cinder.conf` + + ```ini + [DEFAULT] + transport_url = rabbit://openstack:RABBIT_PASS@controller + auth_strategy = keystone + my_ip = 192.168.0.2 + + [database] + connection = mysql+pymysql://cinder:CINDER_DBPASS@controller/cinder + + [keystone_authtoken] + www_authenticate_uri = http://controller:5000 + auth_url = http://controller:5000 + memcached_servers = controller:11211 + auth_type = password + project_domain_name = Default + user_domain_name = Default + project_name = service + username = cinder + password = CINDER_PASS + + [oslo_concurrency] + lock_path = /var/lib/cinder/tmp + ``` + +5. 数据库同步 + + ```shell + su -s /bin/sh -c "cinder-manage db sync" cinder + ``` + +6. 修改nova配置`/etc/nova/nova.conf` + + ```ini + [cinder] + os_region_name = RegionOne + ``` + +7. 启动服务 + + ```shell + systemctl restart openstack-nova-api + systemctl start openstack-cinder-api openstack-cinder-scheduler + ``` + +**Storage节点**： + +Storage节点要提前准备至少一块硬盘，作为cinder的存储后端，下文默认storage节点已经存在一块未使用的硬盘，设备名称为`/dev/sdb`，用户在配置过程中，请按照真实环境信息进行名称替换。 + +Cinder支持很多类型的后端存储，本指导使用最简单的lvm为参考，如果您想使用如ceph等其他后端，请自行配置。 + +1. 安装软件包 + + ```shell + dnf install lvm2 device-mapper-persistent-data scsi-target-utils rpcbind nfs-utils openstack-cinder-volume openstack-cinder-backup + ``` + +2. 配置lvm卷组 + + ```shell + pvcreate /dev/sdb + vgcreate cinder-volumes /dev/sdb + ``` + +3. 修改cinder配置`/etc/cinder/cinder.conf` + + ```ini + [DEFAULT] + transport_url = rabbit://openstack:RABBIT_PASS@controller + auth_strategy = keystone + my_ip = 192.168.0.4 + enabled_backends = lvm + glance_api_servers = http://controller:9292 + + [keystone_authtoken] + www_authenticate_uri = http://controller:5000 + auth_url = http://controller:5000 + memcached_servers = controller:11211 + auth_type = password + project_domain_name = default + user_domain_name = default + project_name = service + username = cinder + password = CINDER_PASS + + [database] + connection = mysql+pymysql://cinder:CINDER_DBPASS@controller/cinder + + [lvm] + volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver + volume_group = cinder-volumes + target_protocol = iscsi + target_helper = lioadm + + [oslo_concurrency] + lock_path = /var/lib/cinder/tmp + ``` + +4. 配置cinder backup （可选） + + cinder-backup是可选的备份服务，cinder同样支持很多种备份后端，本文使用swift存储，如果您想使用如NFS等后端，请自行配置，例如可以参考[OpenStack官方文档](https://docs.openstack.org/cinder/2023.1/admin/nfs-backend.html)对NFS的配置说明。 + + 修改`/etc/cinder/cinder.conf`，在`[DEFAULT]`中新增 + + ```ini + [DEFAULT] + backup_driver = cinder.backup.drivers.swift.SwiftBackupDriver + backup_swift_url = SWIFT_URL + ``` + + 这里的`SWIFT_URL`是指环境中swift服务的URL，在部署完swift服务后，执行`openstack catalog show object-store`命令获取。 + +5. 启动服务 + + ```shell + systemctl start openstack-cinder-volume target + systemctl start openstack-cinder-backup (可选) + ``` + +至此，Cinder服务的部署已全部完成，可以在controller通过以下命令进行简单的验证 + +```shell +source ~/.admin-openrc +openstack storage service list +openstack volume list +``` + +#### Horizon + +Horizon是OpenStack提供的前端页面，可以让用户通过网页鼠标的操作来控制OpenStack集群，而不用繁琐的CLI命令行。Horizon一般部署在控制节点。 + +1. 安装软件包 + + ```shell + dnf install openstack-dashboard + ``` + +2. 修改配置文件`/etc/openstack-dashboard/local_settings` + + ```ini + OPENSTACK_HOST = "controller" + ALLOWED_HOSTS = ['*', ] + OPENSTACK_KEYSTONE_URL = "http://controller:5000/v3" + SESSION_ENGINE = 'django.contrib.sessions.backends.cache' + CACHES = { + 'default': { + 'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache', + 'LOCATION': 'controller:11211', + } + } + OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True + OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = "Default" + OPENSTACK_KEYSTONE_DEFAULT_ROLE = "member" + WEBROOT = '/dashboard' + POLICY_FILES_PATH = "/etc/openstack-dashboard" + + OPENSTACK_API_VERSIONS = { + "identity": 3, + "image": 2, + "volume": 3, + } + ``` + +3. 重启服务 + + ```shell + systemctl restart httpd + ``` + +至此，horizon服务的部署已全部完成，打开浏览器，输入`http://192.168.0.2/dashboard`，打开horizon登录页面。 + +#### Ironic + +Ironic是OpenStack的裸金属服务，如果用户需要进行裸机部署则推荐使用该组件。否则，可以不用安装。 + +在控制节点执行以下操作。 + +1. 设置数据库 + + 裸金属服务在数据库中存储信息，创建一个**ironic**用户可以访问的**ironic**数据库，替换**IRONIC_DBPASS**为合适的密码 + + ```sql + mysql -u root -p + + MariaDB [(none)]> CREATE DATABASE ironic CHARACTER SET utf8; + MariaDB [(none)]> GRANT ALL PRIVILEGES ON ironic.* TO 'ironic'@'localhost' \ + IDENTIFIED BY 'IRONIC_DBPASS'; + MariaDB [(none)]> GRANT ALL PRIVILEGES ON ironic.* TO 'ironic'@'%' \ + IDENTIFIED BY 'IRONIC_DBPASS'; + MariaDB [(none)]> exit + Bye + ``` + +2. 创建服务用户认证 + + - 创建Bare Metal服务用户 + + 替换`IRONIC_PASS`为ironic用户密码，`IRONIC_INSPECTOR_PASS`为ironic_inspector用户密码。 + + ```shell + openstack user create --password IRONIC_PASS \ + --email ironic@example.com ironic + openstack role add --project service --user ironic admin + openstack service create --name ironic \ + --description "Ironic baremetal provisioning service" baremetal + + openstack service create --name ironic-inspector --description "Ironic inspector baremetal provisioning service" baremetal-introspection + openstack user create --password IRONIC_INSPECTOR_PASS --email ironic_inspector@example.com ironic-inspector + openstack role add --project service --user ironic-inspector admin + ``` + + - 创建Bare Metal服务访问入口 + + ```shell + openstack endpoint create --region RegionOne baremetal admin http://192.168.0.2:6385 + openstack endpoint create --region RegionOne baremetal public http://192.168.0.2:6385 + openstack endpoint create --region RegionOne baremetal internal http://192.168.0.2:6385 + openstack endpoint create --region RegionOne baremetal-introspection internal http://192.168.0.2:5050/v1 + openstack endpoint create --region RegionOne baremetal-introspection public http://192.168.0.2:5050/v1 + openstack endpoint create --region RegionOne baremetal-introspection admin http://192.168.0.2:5050/v1 + ``` + +3. 安装组件 + + ```shell + dnf install openstack-ironic-api openstack-ironic-conductor python3-ironicclient + ``` + +4. 配置ironic-api服务 + + 配置文件路径/etc/ironic/ironic.conf + + - 通过**connection**选项配置数据库的位置，如下所示，替换**IRONIC_DBPASS**为**ironic**用户的密码，替换**DB_IP**为DB服务器所在的IP地址： + + ```ini + [database] + + # The SQ LAlchemy connection string used to connect to the + # database (string value) + # connection = mysql+pymysql://ironic:IRONIC_DBPASS@DB_IP/ironic + connection = mysql+pymysql://ironic:IRONIC_DBPASS@controller/ironic + ``` + + - 通过以下选项配置ironic-api服务使用RabbitMQ消息代理，替换**RPC_\***为RabbitMQ的详细地址和凭证 + + ```ini + [DEFAULT] + + # A URL representing the messaging driver to use and its full + # configuration. (string value) + # transport_url = rabbit://RPC_USER:RPC_PASSWORD@RPC_HOST:RPC_PORT/ + transport_url = rabbit://openstack:RABBIT_PASS@controller:5672/ + ``` + + 用户也可自行使用json-rpc方式替换rabbitmq + + - 配置ironic-api服务使用身份认证服务的凭证，替换**PUBLIC_IDENTITY_IP**为身份认证服务器的公共IP，替换**PRIVATE_IDENTITY_IP**为身份认证服务器的私有IP，替换 **IRONIC_PASS**为身份认证服务中**ironic**用户的密码，替换**RABBIT_PASS**为RabbitMQ中openstack账户的密码。： + + ```ini + [DEFAULT] + + # Authentication strategy used by ironic-api: one of + # "keystone" or "noauth". "noauth" should not be used in a + # production environment because all authentication will be + # disabled. (string value) + + auth_strategy=keystone + host = controller + memcache_servers = controller:11211 + enabled_network_interfaces = flat,noop,neutron + default_network_interface = noop + enabled_hardware_types = ipmi + enabled_boot_interfaces = pxe + enabled_deploy_interfaces = direct + default_deploy_interface = direct + enabled_inspect_interfaces = inspector + enabled_management_interfaces = ipmitool + enabled_power_interfaces = ipmitool + enabled_rescue_interfaces = no-rescue,agent + isolinux_bin = /usr/share/syslinux/isolinux.bin + logging_context_format_string = %(asctime)s.%(msecs)03d %(process)d %(levelname)s %(name)s [%(global_request_id)s %(request_id)s % (user_identity)s] %(instance)s%(message)s + + [keystone_authtoken] + # Authentication type to load (string value) + auth_type=password + # Complete public Identity API endpoint (string value) + # www_authenticate_uri=http://PUBLIC_IDENTITY_IP:5000 + www_authenticate_uri=http://controller:5000 + # Complete admin Identity API endpoint. (string value) + # auth_url=http://PRIVATE_IDENTITY_IP:5000 + auth_url=http://controller:5000 + # Service username. (string value) + username=ironic + # Service account password. (string value) + password=IRONIC_PASS + # Service tenant name. (string value) + project_name=service + # Domain name containing project (string value) + project_domain_name=Default + # User's domain name (string value) + user_domain_name=Default + + [agent] + deploy_logs_collect = always + deploy_logs_local_path = /var/log/ironic/deploy + deploy_logs_storage_backend = local + image_download_source = http + stream_raw_images = false + force_raw_images = false + verify_ca = False + + [oslo_concurrency] + + [oslo_messaging_notifications] + transport_url = rabbit://openstack:RABBIT_PASS@controller:5672/ + topics = notifications + driver = messagingv2 + + [oslo_messaging_rabbit] + amqp_durable_queues = True + rabbit_ha_queues = True + + [pxe] + ipxe_enabled = false + pxe_append_params = nofb nomodeset vga=normal coreos.autologin ipa-insecure=1 + image_cache_size = 204800 + tftp_root=/var/lib/tftpboot/cephfs/ + tftp_master_path=/var/lib/tftpboot/cephfs/master_images + + [dhcp] + dhcp_provider = none + ``` + + - 创建裸金属服务数据库表 + + ```shell + ironic-dbsync --config-file /etc/ironic/ironic.conf create_schema + ``` + + - 重启ironic-api服务 + + ```shell + sudo systemctl restart openstack-ironic-api + ``` + +5. 配置ironic-conductor服务 + + 如下为ironic-conductor服务自身的标准配置，ironic-conductor服务可以与ironic-api服务分布于不同节点，本指南中均部署与控制节点，所以重复的配置项可跳过。 + + - 替换使用conductor服务所在host的IP配置my_ip： + + ```ini + [DEFAULT] + + # IP address of this host. If unset, will determine the IP + # programmatically. If unable to do so, will use "127.0.0.1". + # (string value) + # my_ip=HOST_IP + my_ip = 192.168.0.2 + ``` + + - 配置数据库的位置，ironic-conductor应该使用和ironic-api相同的配置。替换**IRONIC_DBPASS**为**ironic**用户的密码： + + ```ini + [database] + + # The SQLAlchemy connection string to use to connect to the + # database. (string value) + connection = mysql+pymysql://ironic:IRONIC_DBPASS@controller/ironic + ``` + + - 通过以下选项配置ironic-api服务使用RabbitMQ消息代理，ironic-conductor应该使用和ironic-api相同的配置，替换**RABBIT_PASS**为RabbitMQ中openstack账户的密码： + + ```ini + [DEFAULT] + + # A URL representing the messaging driver to use and its full + # configuration. (string value) + transport_url = rabbit://openstack:RABBIT_PASS@controller:5672/ + ``` + + 用户也可自行使用json-rpc方式替换rabbitmq + + - 配置凭证访问其他OpenStack服务 + + 为了与其他OpenStack服务进行通信，裸金属服务在请求其他服务时需要使用服务用户与OpenStack Identity服务进行认证。这些用户的凭据必须在与相应服务相关的每个配置文件中进行配置。 + + ```shell + [neutron] - 访问OpenStack网络服务 + [glance] - 访问OpenStack镜像服务 + [swift] - 访问OpenStack对象存储服务 + [cinder] - 访问OpenStack块存储服务 + [inspector] - 访问OpenStack裸金属introspection服务 + [service_catalog] - 一个特殊项用于保存裸金属服务使用的凭证，该凭证用于发现注册在OpenStack身份认证服务目录中的自己的API URL端点 + ``` + + 简单起见，可以对所有服务使用同一个服务用户。为了向后兼容，该用户应该和ironic-api服务的[keystone_authtoken]所配置的为同一个用户。但这不是必须的，也可以为每个服务创建并配置不同的服务用户。 + + 在下面的示例中，用户访问OpenStack网络服务的身份验证信息配置为： + + ```ini + 网络服务部署在名为RegionOne的身份认证服务域中，仅在服务目录中注册公共端点接口 + + 请求时使用特定的CA SSL证书进行HTTPS连接 + + 与ironic-api服务配置相同的服务用户 + + 动态密码认证插件基于其他选项发现合适的身份认证服务API版本 + ``` + + 替换IRONIC_PASS为ironic用户密码。 + + ```ini + [neutron] + + # Authentication type to load (string value) + auth_type = password + # Authentication URL (string value) + auth_url=https://IDENTITY_IP:5000/ + # Username (string value) + username=ironic + # User's password (string value) + password=IRONIC_PASS + # Project name to scope to (string value) + project_name=service + # Domain ID containing project (string value) + project_domain_id=default + # User's domain id (string value) + user_domain_id=default + # PEM encoded Certificate Authority to use when verifying + # HTTPs connections. (string value) + cafile=/opt/stack/data/ca-bundle.pem + # The default region_name for endpoint URL discovery. (string + # value) + region_name = RegionOne + # List of interfaces, in order of preference, for endpoint + # URL. (list value) + valid_interfaces=public + + # 其他参考配置 + [glance] + endpoint_override = http://controller:9292 + www_authenticate_uri = http://controller:5000 + auth_url = http://controller:5000 + auth_type = password + username = ironic + password = IRONIC_PASS + project_domain_name = default + user_domain_name = default + region_name = RegionOne + project_name = service + + [service_catalog] + region_name = RegionOne + project_domain_id = default + user_domain_id = default + project_name = service + password = IRONIC_PASS + username = ironic + auth_url = http://controller:5000 + auth_type = password + ``` + + 默认情况下，为了与其他服务进行通信，裸金属服务会尝试通过身份认证服务的服务目录发现该服务合适的端点。如果希望对一个特定服务使用一个不同的端点，则在裸金属服务的配置文件中通过endpoint_override选项进行指定： + + ```ini + [neutron] + endpoint_override = + ``` + + - 配置允许的驱动程序和硬件类型 + + 通过设置enabled_hardware_types设置ironic-conductor服务允许使用的硬件类型： + + ```ini + [DEFAULT] + enabled_hardware_types = ipmi + ``` + + 配置硬件接口： + + ```ini + enabled_boot_interfaces = pxe + enabled_deploy_interfaces = direct,iscsi + enabled_inspect_interfaces = inspector + enabled_management_interfaces = ipmitool + enabled_power_interfaces = ipmitool + ``` + + 配置接口默认值： + + ```ini + [DEFAULT] + default_deploy_interface = direct + default_network_interface = neutron + ``` + + 如果启用了任何使用Direct deploy的驱动，必须安装和配置镜像服务的Swift后端。Ceph对象网关(RADOS网关)也支持作为镜像服务的后端。 + + - 重启ironic-conductor服务 + + ```shell + sudo systemctl restart openstack-ironic-conductor + ``` + +6. 配置ironic-inspector服务 + + - 安装组件 + + ```shell + dnf install openstack-ironic-inspector + ``` + + - 创建数据库 + + ```sql + # mysql -u root -p + + MariaDB [(none)]> CREATE DATABASE ironic_inspector CHARACTER SET utf8; + + MariaDB [(none)]> GRANT ALL PRIVILEGES ON ironic_inspector.* TO 'ironic_inspector'@'localhost' \ + IDENTIFIED BY 'IRONIC_INSPECTOR_DBPASS'; + MariaDB [(none)]> GRANT ALL PRIVILEGES ON ironic_inspector.* TO 'ironic_inspector'@'%' \ + IDENTIFIED BY 'IRONIC_INSPECTOR_DBPASS'; + MariaDB [(none)]> exit + Bye + ``` + + - 配置`/etc/ironic-inspector/inspector.conf` + + 通过**connection**选项配置数据库的位置，如下所示，替换**IRONIC_INSPECTOR_DBPASS**为**ironic_inspector**用户的密码 + + ```ini + [database] + backend = sqlalchemy + connection = mysql+pymysql://ironic_inspector:IRONIC_INSPECTOR_DBPASS@controller/ironic_inspector + min_pool_size = 100 + max_pool_size = 500 + pool_timeout = 30 + max_retries = 5 + max_overflow = 200 + db_retry_interval = 2 + db_inc_retry_interval = True + db_max_retry_interval = 2 + db_max_retries = 5 + ``` + + - 配置消息队列通信地址 + + ```ini + [DEFAULT] + transport_url = rabbit://openstack:RABBIT_PASS@controller:5672/ + ``` + + - 设置keystone认证 + + ```ini + [DEFAULT] + + auth_strategy = keystone + timeout = 900 + rootwrap_config = /etc/ironic-inspector/rootwrap.conf + logging_context_format_string = %(asctime)s.%(msecs)03d %(process)d %(levelname)s %(name)s [%(global_request_id)s %(request_id)s % (user_identity)s] %(instance)s%(message)s + log_dir = /var/log/ironic-inspector + state_path = /var/lib/ironic-inspector + use_stderr = False + + [ironic] + api_endpoint = http://IRONIC_API_HOST_ADDRRESS:6385 + auth_type = password + auth_url = http://PUBLIC_IDENTITY_IP:5000 + auth_strategy = keystone + ironic_url = http://IRONIC_API_HOST_ADDRRESS:6385 + os_region = RegionOne + project_name = service + project_domain_name = Default + user_domain_name = Default + username = IRONIC_SERVICE_USER_NAME + password = IRONIC_SERVICE_USER_PASSWORD + + [keystone_authtoken] + auth_type = password + auth_url = http://controller:5000 + www_authenticate_uri = http://controller:5000 + project_domain_name = default + user_domain_name = default + project_name = service + username = ironic_inspector + password = IRONICPASSWD + region_name = RegionOne + memcache_servers = controller:11211 + token_cache_time = 300 + + [processing] + add_ports = active + processing_hooks = $default_processing_hooks,local_link_connection,lldp_basic + ramdisk_logs_dir = /var/log/ironic-inspector/ramdisk + always_store_ramdisk_logs = true + store_data =none + power_off = false + + [pxe_filter] + driver = iptables + + [capabilities] + boot_mode=True + ``` + + - 配置ironic inspector dnsmasq服务 + + ```ini + # 配置文件地址：/etc/ironic-inspector/dnsmasq.conf + port=0 + interface=enp3s0 #替换为实际监听网络接口 + dhcp-range=192.168.0.40,192.168.0.50 #替换为实际dhcp地址范围 + bind-interfaces + enable-tftp + + dhcp-match=set:efi,option:client-arch,7 + dhcp-match=set:efi,option:client-arch,9 + dhcp-match=aarch64, option:client-arch,11 + dhcp-boot=tag:aarch64,grubaa64.efi + dhcp-boot=tag:!aarch64,tag:efi,grubx64.efi + dhcp-boot=tag:!aarch64,tag:!efi,pxelinux.0 + + tftp-root=/tftpboot #替换为实际tftpboot目录 + log-facility=/var/log/dnsmasq.log + ``` + + - 关闭ironic provision网络子网的dhcp + + ```shell + openstack subnet set --no-dhcp 72426e89-f552-4dc4-9ac7-c4e131ce7f3c + ``` + + - 初始化ironic-inspector服务的数据库 + + ```shell + ironic-inspector-dbsync --config-file /etc/ironic-inspector/inspector.conf upgrade + ``` + + - 启动服务 + + ```shell + systemctl enable --now openstack-ironic-inspector.service + systemctl enable --now openstack-ironic-inspector-dnsmasq.service + ``` + +7. 配置httpd服务 + + - 创建ironic要使用的httpd的root目录并设置属主属组，目录路径要和/etc/ironic/ironic.conf中[deploy]组中http_root 配置项指定的路径要一致。 + + ```shell + mkdir -p /var/lib/ironic/httproot + chown ironic.ironic /var/lib/ironic/httproot + ``` + + - 安装和配置httpd服务 + + - 安装httpd服务，已有请忽略 + + ```shell + dnf install httpd -y + ``` + + - 创建/etc/httpd/conf.d/openstack-ironic-httpd.conf文件，内容如下： + + ```ini + Listen 8080 + + + ServerName ironic.openeuler.com + + ErrorLog "/var/log/httpd/openstack-ironic-httpd-error_log" + CustomLog "/var/log/httpd/openstack-ironic-httpd-access_log" "%h %l %u %t \"%r\" %>s %b" + + DocumentRoot "/var/lib/ironic/httproot" + + Options Indexes FollowSymLinks + Require all granted + + LogLevel warn + AddDefaultCharset UTF-8 + EnableSendfile on + + ``` + + 注意监听的端口要和/etc/ironic/ironic.conf里[deploy]选项中http_url配置项中指定的端口一致。 + + - 重启httpd服务。 + + ```shell + systemctl restart httpd + ``` + +8. deploy ramdisk镜像下载或制作 + + 部署一个裸机节点总共需要两组镜像：deploy ramdisk images和user images。Deploy ramdisk images上运行有ironic-python-agent(IPA)服务，Ironic通过它进行裸机节点的环境准备。User images是最终被安装裸机节点上，供用户使用的镜像。 + + ramdisk镜像支持通过ironic-python-agent-builder或disk-image-builder工具制作。用户也可以自行选择其他工具制作。若使用原生工具，则需要安装对应的软件包。 + + 具体的使用方法可以参考[官方文档](https://docs.openstack.org/ironic/2023.1/install/deploy-ramdisk.html)，同时官方也有提供制作好的deploy镜像，可尝试下载。 + + 下文介绍通过ironic-python-agent-builder构建ironic使用的deploy镜像的完整过程。 + + - 安装 ironic-python-agent-builder + + ```shell + dnf install python3-ironic-python-agent-builder + + 或 + pip3 install ironic-python-agent-builder + dnf install qemu-img git + ``` + + - 制作镜像 + + 基本用法： + + ```shell + usage: ironic-python-agent-builder [-h] [-r RELEASE] [-o OUTPUT] [-e ELEMENT] [-b BRANCH] + [-v] [--lzma] [--extra-args EXTRA_ARGS] + [--elements-path ELEMENTS_PATH] + distribution + + positional arguments: + distribution Distribution to use + + options: + -h, --help show this help message and exit + -r RELEASE, --release RELEASE + Distribution release to use + -o OUTPUT, --output OUTPUT + Output base file name + -e ELEMENT, --element ELEMENT + Additional DIB element to use + -b BRANCH, --branch BRANCH + If set, override the branch that is used for ironic-python-agent + and requirements + -v, --verbose Enable verbose logging in diskimage-builder + --lzma Use lzma compression for smaller images + --extra-args EXTRA_ARGS + Extra arguments to pass to diskimage-builder + --elements-path ELEMENTS_PATH + Path(s) to custom DIB elements separated by a colon + ``` + + 操作实例： + + ```shell + # -o选项指定生成的镜像名 + # ubuntu指定生成ubuntu系统的镜像 + ironic-python-agent-builder -o my-ubuntu-ipa ubuntu + ``` + + 可通过设置`ARCH`环境变量（默认为amd64）指定所构建镜像的架构。如果是`arm`架构，需要添加： + + ```shell + export ARCH=aarch64 + ``` + + - 允许ssh登录 + + 初始化环境变量,设置用户名、密码，启用`sodo`权限；并添加`-e`选项使用相应的DIB元素。制作镜像操作如下： + + ```shell + export DIB_DEV_USER_USERNAME=ipa \ + export DIB_DEV_USER_PWDLESS_SUDO=yes \ + export DIB_DEV_USER_PASSWORD='123' + ironic-python-agent-builder -o my-ssh-ubuntu-ipa -e selinux-permissive -e devuser ubuntu + ``` + + - 指定代码仓库 + + 初始化对应的环境变量，然后制作镜像： + + ```shell + # 直接从gerrit上clone代码 + DIB_REPOLOCATION_ironic_python_agent=https://opendev.org/openstack/ironic-python-agent + DIB_REPOREF_ironic_python_agent=stable/2023.1 + + # 指定本地仓库及分支 + DIB_REPOLOCATION_ironic_python_agent=/home/user/path/to/repo + DIB_REPOREF_ironic_python_agent=my-test-branch + + ironic-python-agent-builder ubuntu + ``` + + 参考：[source-repositories](https://docs.openstack.org/diskimage-builder/latest/elements/source-repositories/README.html)。 + +9. 注意 + + 原生的openstack里的pxe配置文件的模版不支持arm64架构，需要自己对原生openstack代码进行修改： + 在W版中，社区的ironic仍然不支持arm64位的uefi pxe启动，表现为生成的grub.cfg文件(一般位于/tftpboot/下)格式不对而导致pxe启动失败。 + + 生成的错误配置文件： + + ![ironic-err](../img/install/ironic-err.png) + + 如上图所示，arm架构里寻找vmlinux和ramdisk镜像的命令分别是linux和initrd，上图所示的标红命令是x86架构下的uefi pxe启动。 + + 需要用户对生成grub.cfg的代码逻辑自行修改。 + + ironic向ipa发送查询命令执行状态请求的tls报错： + + 当前版本的ipa和ironic默认都会开启tls认证的方式向对方发送请求，跟据官网的说明进行关闭即可。 + + - 修改ironic配置文件(/etc/ironic/ironic.conf)下面的配置中添加ipa-insecure=1： + + ```ini + [agent] + verify_ca = False + [pxe] + pxe_append_params = nofb nomodeset vga=normal coreos.autologin ipa-insecure=1 + ``` + + - ramdisk镜像中添加ipa配置文件/etc/ironic_python_agent/ironic_python_agent.conf并配置tls的配置如下： + + /etc/ironic_python_agent/ironic_python_agent.conf (需要提前创建/etc/ ironic_python_agent目录） + + ```ini + [DEFAULT] + enable_auto_tls = False + ``` + + 设置权限： + + ```shell + chown -R ipa.ipa /etc/ironic_python_agent/ + ``` + + - ramdisk镜像中修改ipa服务的服务启动文件，添加配置文件选项 + + 编辑/usr/lib/systemd/system/ironic-python-agent.service文件 + + ```ini + [Unit] + Description=Ironic Python Agent + After=network-online.target + [Service] + ExecStartPre=/sbin/modprobe vfat + ExecStart=/usr/local/bin/ironic-python-agent --config-file /etc/ ironic_python_agent/ironic_python_agent.conf + Restart=always + RestartSec=30s + [Install] + WantedBy=multi-user.target + ``` + +#### Trove + +Trove是OpenStack的数据库服务，如果用户使用OpenStack提供的数据库服务则推荐使用该组件。否则，可以不用安装。 + +**Controller节点** + +1. 创建数据库。 + + 数据库服务在数据库中存储信息，创建一个trove用户可以访问的trove数据库，替换TROVE_DBPASS为合适的密码。 + + ```sql + CREATE DATABASE trove CHARACTER SET utf8; + GRANT ALL PRIVILEGES ON trove.* TO 'trove'@'localhost' IDENTIFIED BY 'TROVE_DBPASS'; + GRANT ALL PRIVILEGES ON trove.* TO 'trove'@'%' IDENTIFIED BY 'TROVE_DBPASS'; + ``` + +2. 创建服务凭证以及API端点。 + + 创建服务凭证。 + + ```shell + # 创建trove用户 + openstack user create --domain default --password-prompt trove + # 添加admin角色 + openstack role add --project service --user trove admin + # 创建database服务 + openstack service create --name trove --description "Database service" database + ``` + + 创建API端点。 + + ```shell + openstack endpoint create --region RegionOne database public http://controller:8779/v1.0/%\(tenant_id\)s + openstack endpoint create --region RegionOne database internal http://controller:8779/v1.0/%\(tenant_id\)s + openstack endpoint create --region RegionOne database admin http://controller:8779/v1.0/%\(tenant_id\)s + ``` + +3. 安装Trove。 + + ```shell + dnf install openstack-trove python-troveclient + ``` + +4. 修改配置文件。 + + 编辑/etc/trove/trove.conf。 + + ```ini + [DEFAULT] + bind_host=192.168.0.2 + log_dir = /var/log/trove + network_driver = trove.network.neutron.NeutronDriver + network_label_regex=.* + management_security_groups = + nova_keypair = trove-mgmt + default_datastore = mysql + taskmanager_manager = trove.taskmanager.manager.Manager + trove_api_workers = 5 + transport_url = rabbit://openstack:RABBIT_PASS@controller:5672/ + reboot_time_out = 300 + usage_timeout = 900 + agent_call_high_timeout = 1200 + use_syslog = False + debug = True + + [database] + connection = mysql+pymysql://trove:TROVE_DBPASS@controller/trove + + [keystone_authtoken] + auth_url = http://controller:5000/v3/ + auth_type = password + project_domain_name = Default + project_name = service + user_domain_name = Default + password = trove + username = TROVE_PASS + + [service_credentials] + auth_url = http://controller:5000/v3/ + region_name = RegionOne + project_name = service + project_domain_name = Default + user_domain_name = Default + username = trove + password = TROVE_PASS + + [mariadb] + tcp_ports = 3306,4444,4567,4568 + + [mysql] + tcp_ports = 3306 + + [postgresql] + tcp_ports = 5432 + ``` + + **解释：** + + > `[Default]`分组中`bind_host`配置为Trove控制节点的IP。\ + > `transport_url` 为`RabbitMQ`连接信息，`RABBIT_PASS`替换为RabbitMQ的密码。\ + > `[database]`分组中的`connection` 为前面在mysql中为Trove创建的数据库信息。\ + > Trove的用户信息中`TROVE_PASSWORD`替换为实际trove用户的密码。 + + 编辑/etc/trove/trove-guestagent.conf。 + + ```ini + [DEFAULT] + log_file = trove-guestagent.log + log_dir = /var/log/trove/ + ignore_users = os_admin + control_exchange = trove + transport_url = rabbit://openstack:RABBIT_PASS@controller:5672/ + rpc_backend = rabbit + command_process_timeout = 60 + use_syslog = False + debug = True + + [service_credentials] + auth_url = http://controller:5000/v3/ + region_name = RegionOne + project_name = service + password = TROVE_PASS + project_domain_name = Default + user_domain_name = Default + username = trove + + [mysql] + docker_image = your-registry/your-repo/mysql + backup_docker_image = your-registry/your-repo/db-backup-mysql:1.1.0 + ``` + + **解释：** + + > `guestagent`是trove中一个独立组件，需要预先内置到Trove通过Nova创建的虚拟机镜像中，在创建好数据库实例后，会起guestagent进程，负责通过消息队列（RabbitMQ）向Trove上报心跳，因此需要配置RabbitMQ的用户和密码信息。\ + > `transport_url` 为`RabbitMQ`连接信息，`RABBIT_PASS`替换为RabbitMQ的密码。\ + > Trove的用户信息中`TROVE_PASSWORD`替换为实际trove用户的密码。\ + > 从Victoria版开始，Trove使用一个统一的镜像来跑不同类型的数据库，数据库服务运行在Guest虚拟机的Docker容器中。 + +5. 数据库同步。 + + ```shell + su -s /bin/sh -c "trove-manage db_sync" trove + ``` + +6. 完成安装。 + + ```shell + # 配置服务自启 + systemctl enable openstack-trove-api.service openstack-trove-taskmanager.service \ + openstack-trove-conductor.service + + # 启动服务 + systemctl start openstack-trove-api.service openstack-trove-taskmanager.service \ + openstack-trove-conductor.service + ``` + +#### Swift + +Swift 提供了弹性可伸缩、高可用的分布式对象存储服务，适合存储大规模非结构化数据。 + +**Controller节点** + +1. 创建服务凭证以及API端点。 + + 创建服务凭证。 + + ```shell + # 创建swift用户 + openstack user create --domain default --password-prompt swift + # 添加admin角色 + openstack role add --project service --user swift admin + # 创建对象存储服务 + openstack service create --name swift --description "OpenStack Object Storage" object-store + ``` + + 创建API端点。 + + ```shell + openstack endpoint create --region RegionOne object-store public http://controller:8080/v1/AUTH_%\(project_id\)s + openstack endpoint create --region RegionOne object-store internal http://controller:8080/v1/AUTH_%\(project_id\)s + openstack endpoint create --region RegionOne object-store admin http://controller:8080/v1 + ``` + +2. 安装Swift。 + + ```shell + dnf install openstack-swift-proxy python3-swiftclient python3-keystoneclient \ + python3-keystonemiddleware memcached + ``` + +3. 配置proxy-server。 + + Swift RPM包里已经包含了一个基本可用的proxy-server.conf，只需要手动修改其中的ip和SWIFT_PASS即可。 + + ```ini + vim /etc/swift/proxy-server.conf + + [filter:authtoken] + paste.filter_factory = keystonemiddleware.auth_token:filter_factory + www_authenticate_uri = http://controller:5000 + auth_url = http://controller:5000 + memcached_servers = controller:11211 + auth_type = password + project_domain_id = default + user_domain_id = default + project_name = service + username = swift + password = SWIFT_PASS + delay_auth_decision = True + service_token_roles_required = True + ``` + +**Storage节点** + +1. 安装支持的程序包。 + + ```shell + dnf install openstack-swift-account openstack-swift-container openstack-swift-object + dnf install xfsprogs rsync + ``` + +2. 将设备/dev/sdb和/dev/sdc格式化为XFS。 + + ```shell + mkfs.xfs /dev/sdb + mkfs.xfs /dev/sdc + ``` + +3. 创建挂载点目录结构。 + + ```shell + mkdir -p /srv/node/sdb + mkdir -p /srv/node/sdc + ``` + +4. 找到新分区的UUID。 + + ```shell + blkid + ``` + +5. 编辑/etc/fstab文件并将以下内容添加到其中。 + + ```shell + UUID="" /srv/node/sdb xfs noatime 0 2 + UUID="" /srv/node/sdc xfs noatime 0 2 + ``` + +6. 挂载设备。 + + ```shell + mount /srv/node/sdb + mount /srv/node/sdc + ``` + + ***注意*** + + **如果用户不需要容灾功能，以上步骤只需要创建一个设备即可，同时可以跳过下面的rsync配置。** + +7. （可选）创建或编辑/etc/rsyncd.conf文件以包含以下内容: + + ```ini + [DEFAULT] + uid = swift + gid = swift + log file = /var/log/rsyncd.log + pid file = /var/run/rsyncd.pid + address = MANAGEMENT_INTERFACE_IP_ADDRESS + + [account] + max connections = 2 + path = /srv/node/ + read only = False + lock file = /var/lock/account.lock + + [container] + max connections = 2 + path = /srv/node/ + read only = False + lock file = /var/lock/container.lock + + [object] + max connections = 2 + path = /srv/node/ + read only = False + lock file = /var/lock/object.lock + ``` + + **替换MANAGEMENT_INTERFACE_IP_ADDRESS为存储节点上管理网络的IP地址** + + 启动rsyncd服务并配置它在系统启动时启动: + + ```shell + systemctl enable rsyncd.service + systemctl start rsyncd.service + ``` + +8. 配置存储节点。 + + 编辑/etc/swift目录的account-server.conf、container-server.conf和object-server.conf文件，替换bind_ip为存储节点上管理网络的IP地址。 + + ```ini + [DEFAULT] + bind_ip = 192.168.0.4 + ``` + + 确保挂载点目录结构的正确所有权。 + + ```shell + chown -R swift:swift /srv/node + ``` + + 创建recon目录并确保其拥有正确的所有权。 + + ```shell + mkdir -p /var/cache/swift + chown -R root:swift /var/cache/swift + chmod -R 775 /var/cache/swift + ``` + +**Controller节点创建并分发环** + +1. 创建账号环。 + + 切换到`/etc/swift`目录。 + + ```shell + cd /etc/swift + ``` + + 创建基础`account.builder`文件。 + + ```shell + swift-ring-builder account.builder create 10 1 1 + ``` + + 将每个存储节点添加到环中。 + + ```shell + swift-ring-builder account.builder add --region 1 --zone 1 \ + --ip STORAGE_NODE_MANAGEMENT_INTERFACE_IP_ADDRESS \ + --port 6202 --device DEVICE_NAME \ + --weight 100 + ``` + + > 替换STORAGE_NODE_MANAGEMENT_INTERFACE_IP_ADDRESS为存储节点上管理网络的IP地址。\ + > 替换DEVICE_NAME为同一存储节点上的存储设备名称。 + + ***注意*** + + **对每个存储节点上的每个存储设备重复此命令** + + 验证账号环内容。 + + ```shell + swift-ring-builder account.builder + ``` + + 重新平衡账号环。 + + ```shell + swift-ring-builder account.builder rebalance + ``` + +2. 创建容器环。 + + 切换到`/etc/swift`目录。 + + 创建基础`container.builder`文件。 + + ```shell + swift-ring-builder container.builder create 10 1 1 + ``` + + 将每个存储节点添加到环中。 + + ```shell + swift-ring-builder container.builder add --region 1 --zone 1 \ + --ip STORAGE_NODE_MANAGEMENT_INTERFACE_IP_ADDRESS + --port 6201 --device DEVICE_NAME \ + --weight 100 + ``` + + > 替换STORAGE_NODE_MANAGEMENT_INTERFACE_IP_ADDRESS为存储节点上管理网络的IP地址。\ + > 替换DEVICE_NAME为同一存储节点上的存储设备名称。 + + ***注意*** + + **对每个存储节点上的每个存储设备重复此命令** + + 验证容器环内容。 + + ```shell + swift-ring-builder container.builder + ``` + + 重新平衡容器环。 + + ```shell + swift-ring-builder container.builder rebalance + ``` + +3. 创建对象环。 + + 切换到`/etc/swift`目录。 + + 创建基础`object.builder`文件。 + + ```shell + swift-ring-builder object.builder create 10 1 1 + ``` + + 将每个存储节点添加到环中。 + + ```shell + swift-ring-builder object.builder add --region 1 --zone 1 \ + --ip STORAGE_NODE_MANAGEMENT_INTERFACE_IP_ADDRESS \ + --port 6200 --device DEVICE_NAME \ + --weight 100 + ``` + + > 替换STORAGE_NODE_MANAGEMENT_INTERFACE_IP_ADDRESS为存储节点上管理网络的IP地址。\ + > 替换DEVICE_NAME为同一存储节点上的存储设备名称。 + + ***注意*** + + **对每个存储节点上的每个存储设备重复此命令** + + 验证对象环内容。 + + ```shell + swift-ring-builder object.builder + ``` + + 重新平衡对象环。 + + ```shell + swift-ring-builder object.builder rebalance + ``` + +4. 分发环配置文件。 + + 将`account.ring.gz`，`container.ring.gz`以及 `object.ring.gz`文件复制到每个存储节点和运行代理服务的任何其他节点上的`/etc/swift`目录。 + +5. 编辑配置文件/etc/swift/swift.conf。 + + ```ini + [swift-hash] + swift_hash_path_suffix = test-hash + swift_hash_path_prefix = test-hash + + [storage-policy:0] + name = Policy-0 + default = yes + ``` + + **用唯一值替换 test-hash** + + 将swift.conf文件复制到/etc/swift每个存储节点和运行代理服务的任何其他节点上的目录。 + + 在所有节点上，确保配置目录的正确所有权。 + + ```shell + chown -R root:swift /etc/swift + ``` + +6. 完成安装 + + 在控制节点和运行代理服务的任何其他节点上，启动对象存储代理服务及其依赖项，并将它们配置为在系统启动时启动。 + + ```shell + systemctl enable openstack-swift-proxy.service memcached.service + systemctl start openstack-swift-proxy.service memcached.service + ``` + + 在存储节点上，启动对象存储服务并将它们配置为在系统启动时启动。 + + ```shell + systemctl enable openstack-swift-account.service \ + openstack-swift-account-auditor.service \ + openstack-swift-account-reaper.service \ + openstack-swift-account-replicator.service \ + openstack-swift-container.service \ + openstack-swift-container-auditor.service \ + openstack-swift-container-replicator.service \ + openstack-swift-container-updater.service \ + openstack-swift-object.service \ + openstack-swift-object-auditor.service \ + openstack-swift-object-replicator.service \ + openstack-swift-object-updater.service + + systemctl start openstack-swift-account.service \ + openstack-swift-account-auditor.service \ + openstack-swift-account-reaper.service \ + openstack-swift-account-replicator.service \ + openstack-swift-container.service \ + openstack-swift-container-auditor.service \ + openstack-swift-container-replicator.service \ + openstack-swift-container-updater.service \ + openstack-swift-object.service \ + openstack-swift-object-auditor.service \ + openstack-swift-object-replicator.service \ + openstack-swift-object-updater.service + ``` + +#### Cyborg + +Cyborg为OpenStack提供加速器设备的支持，包括 GPU, FPGA, ASIC, NP, SoCs, NVMe/NOF SSDs, ODP, DPDK/SPDK等等。 + +**Controller节点** + +1. 初始化对应数据库 + + ```sql + mysql -u root -p + + MariaDB [(none)]> CREATE DATABASE cyborg; + MariaDB [(none)]> GRANT ALL PRIVILEGES ON cyborg.* TO 'cyborg'@'localhost' IDENTIFIED BY 'CYBORG_DBPASS'; + MariaDB [(none)]> GRANT ALL PRIVILEGES ON cyborg.* TO 'cyborg'@'%' IDENTIFIED BY 'CYBORG_DBPASS'; + MariaDB [(none)]> exit; + ``` + +2. 创建用户和服务，并记住创建cybory用户时输入的密码，用于配置CYBORG_PASS + + ```shell + source ~/.admin-openrc + openstack user create --domain default --password-prompt cyborg + openstack role add --project service --user cyborg admin + openstack service create --name cyborg --description "Acceleration Service" accelerator + ``` + +3. 使用uwsgi部署Cyborg api服务 + + ```shell + openstack endpoint create --region RegionOne accelerator public http://controller/accelerator/v2 + openstack endpoint create --region RegionOne accelerator internal http://controller/accelerator/v2 + openstack endpoint create --region RegionOne accelerator admin http://controller/accelerator/v2 + ``` + +4. 安装Cyborg + + ```shell + dnf install openstack-cyborg + ``` + +5. 配置Cyborg + + 修改`/etc/cyborg/cyborg.conf` + + ```ini + [DEFAULT] + transport_url = rabbit://openstack:RABBIT_PASS@controller:5672/ + use_syslog = False + state_path = /var/lib/cyborg + debug = True + + [api] + host_ip = 0.0.0.0 + + [database] + connection = mysql+pymysql://cyborg:CYBORG_DBPASS@controller/cyborg + + [service_catalog] + cafile = /opt/stack/data/ca-bundle.pem + project_domain_id = default + user_domain_id = default + project_name = service + password = CYBORG_PASS + username = cyborg + auth_url = http://controller:5000/v3/ + auth_type = password + + [placement] + project_domain_name = Default + project_name = service + user_domain_name = Default + password = password + username = PLACEMENT_PASS + auth_url = http://controller:5000/v3/ + auth_type = password + auth_section = keystone_authtoken + + [nova] + project_domain_name = Default + project_name = service + user_domain_name = Default + password = NOVA_PASS + username = nova + auth_url = http://controller:5000/v3/ + auth_type = password + auth_section = keystone_authtoken + + [keystone_authtoken] + memcached_servers = localhost:11211 + signing_dir = /var/cache/cyborg/api + cafile = /opt/stack/data/ca-bundle.pem + project_domain_name = Default + project_name = service + user_domain_name = Default + password = CYBORG_PASS + username = cyborg + auth_url = http://controller:5000/v3/ + auth_type = password + ``` + +6. 同步数据库表格 + + ```shell + cyborg-dbsync --config-file /etc/cyborg/cyborg.conf upgrade + ``` + +7. 启动Cyborg服务 + + ```shell + systemctl enable openstack-cyborg-api openstack-cyborg-conductor openstack-cyborg-agent + systemctl start openstack-cyborg-api openstack-cyborg-conductor openstack-cyborg-agent + ``` + +#### Aodh + +Aodh可以根据由Ceilometer或者Gnocchi收集的监控数据创建告警，并设置触发规则。 + +**Controller节点** + +1. 创建数据库。 + + ```sql + CREATE DATABASE aodh; + GRANT ALL PRIVILEGES ON aodh.* TO 'aodh'@'localhost' IDENTIFIED BY 'AODH_DBPASS'; + GRANT ALL PRIVILEGES ON aodh.* TO 'aodh'@'%' IDENTIFIED BY 'AODH_DBPASS'; + ``` + +2. 创建服务凭证以及API端点。 + + 创建服务凭证。 + + ```shell + openstack user create --domain default --password-prompt aodh + openstack role add --project service --user aodh admin + openstack service create --name aodh --description "Telemetry" alarming + ``` + + 创建API端点。 + + ```shell + openstack endpoint create --region RegionOne alarming public http://controller:8042 + openstack endpoint create --region RegionOne alarming internal http://controller:8042 + openstack endpoint create --region RegionOne alarming admin http://controller:8042 + ``` + +3. 安装Aodh。 + + ```shell + dnf install openstack-aodh-api openstack-aodh-evaluator \ + openstack-aodh-notifier openstack-aodh-listener \ + openstack-aodh-expirer python3-aodhclient + ``` + +4. 修改配置文件。 + + ```ini + vim /etc/aodh/aodh.conf + + [database] + connection = mysql+pymysql://aodh:AODH_DBPASS@controller/aodh + + [DEFAULT] + transport_url = rabbit://openstack:RABBIT_PASS@controller + auth_strategy = keystone + + [keystone_authtoken] + www_authenticate_uri = http://controller:5000 + auth_url = http://controller:5000 + memcached_servers = controller:11211 + auth_type = password + project_domain_id = default + user_domain_id = default + project_name = service + username = aodh + password = AODH_PASS + + [service_credentials] + auth_type = password + auth_url = http://controller:5000/v3 + project_domain_id = default + user_domain_id = default + project_name = service + username = aodh + password = AODH_PASS + interface = internalURL + region_name = RegionOne + ``` + +5. 同步数据库。 + + ```shell + aodh-dbsync + ``` + +6. 完成安装。 + + ```shell + # 配置服务自启 + systemctl enable openstack-aodh-api.service openstack-aodh-evaluator.service \ + openstack-aodh-notifier.service openstack-aodh-listener.service + + # 启动服务 + systemctl start openstack-aodh-api.service openstack-aodh-evaluator.service \ + openstack-aodh-notifier.service openstack-aodh-listener.service + ``` + +#### Gnocchi + +Gnocchi是一个开源的时间序列数据库，可以对接Ceilometer。 + +**Controller节点** + +1. 创建数据库。 + + ```sql + CREATE DATABASE gnocchi; + GRANT ALL PRIVILEGES ON gnocchi.* TO 'gnocchi'@'localhost' IDENTIFIED BY 'GNOCCHI_DBPASS'; + GRANT ALL PRIVILEGES ON gnocchi.* TO 'gnocchi'@'%' IDENTIFIED BY 'GNOCCHI_DBPASS'; + ``` + +2. 创建服务凭证以及API端点。 + + 创建服务凭证。 + + ```shell + openstack user create --domain default --password-prompt gnocchi + openstack role add --project service --user gnocchi admin + openstack service create --name gnocchi --description "Metric Service" metric + ``` + + 创建API端点。 + + ```shell + openstack endpoint create --region RegionOne metric public http://controller:8041 + openstack endpoint create --region RegionOne metric internal http://controller:8041 + openstack endpoint create --region RegionOne metric admin http://controller:8041 + ``` + +3. 安装Gnocchi。 + + ```shell + dnf install openstack-gnocchi-api openstack-gnocchi-metricd python3-gnocchiclient + ``` + +4. 修改配置文件。 + + ```ini + vim /etc/gnocchi/gnocchi.conf + [api] + auth_mode = keystone + port = 8041 + uwsgi_mode = http-socket + + [keystone_authtoken] + auth_type = password + auth_url = http://controller:5000/v3 + project_domain_name = Default + user_domain_name = Default + project_name = service + username = gnocchi + password = GNOCCHI_PASS + interface = internalURL + region_name = RegionOne + + [indexer] + url = mysql+pymysql://gnocchi:GNOCCHI_DBPASS@controller/gnocchi + + [storage] + # coordination_url is not required but specifying one will improve + # performance with better workload division across workers. + # coordination_url = redis://controller:6379 + file_basepath = /var/lib/gnocchi + driver = file + ``` + +5. 同步数据库。 + + ```shell + gnocchi-upgrade + ``` + +6. 完成安装。 + + ```shell + # 配置服务自启 + systemctl enable openstack-gnocchi-api.service openstack-gnocchi-metricd.service + + # 启动服务 + systemctl start openstack-gnocchi-api.service openstack-gnocchi-metricd.service + ``` + +#### Ceilometer + +Ceilometer是OpenStack中负责数据收集的服务。 + +**Controller节点** + +1. 创建服务凭证。 + + ```shell + openstack user create --domain default --password-prompt ceilometer + openstack role add --project service --user ceilometer admin + openstack service create --name ceilometer --description "Telemetry" metering + ``` + +2. 安装Ceilometer软件包。 + + ```shell + dnf install openstack-ceilometer-notification openstack-ceilometer-central + ``` + +3. 编辑配置文件/etc/ceilometer/pipeline.yaml。 + + ```yaml + publishers: + # set address of Gnocchi + # + filter out Gnocchi-related activity meters (Swift driver) + # + set default archive policy + - gnocchi://?filter_project=service&archive_policy=low + ``` + +4. 编辑配置文件/etc/ceilometer/ceilometer.conf。 + + ```ini + [DEFAULT] + transport_url = rabbit://openstack:RABBIT_PASS@controller + + [service_credentials] + auth_type = password + auth_url = http://controller:5000/v3 + project_domain_id = default + user_domain_id = default + project_name = service + username = ceilometer + password = CEILOMETER_PASS + interface = internalURL + region_name = RegionOne + ``` + +5. 数据库同步。 + + ```shell + ceilometer-upgrade + ``` + +6. 完成控制节点Ceilometer安装。 + + ```shell + # 配置服务自启 + systemctl enable openstack-ceilometer-notification.service openstack-ceilometer-central.service + # 启动服务 + systemctl start openstack-ceilometer-notification.service openstack-ceilometer-central.service + ``` + +**Compute节点** + +1. 安装Ceilometer软件包。 + + ```shell + dnf install openstack-ceilometer-compute + dnf install openstack-ceilometer-ipmi # 可选 + ``` + +2. 编辑配置文件/etc/ceilometer/ceilometer.conf。 + + ```ini + [DEFAULT] + transport_url = rabbit://openstack:RABBIT_PASS@controller + + [service_credentials] + auth_url = http://controller:5000 + project_domain_id = default + user_domain_id = default + auth_type = password + username = ceilometer + project_name = service + password = CEILOMETER_PASS + interface = internalURL + region_name = RegionOne + ``` + +3. 编辑配置文件/etc/nova/nova.conf。 + + ```ini + [DEFAULT] + instance_usage_audit = True + instance_usage_audit_period = hour + + [notifications] + notify_on_state_change = vm_and_task_state + + [oslo_messaging_notifications] + driver = messagingv2 + ``` + +4. 完成安装。 + + ```shell + systemctl enable openstack-ceilometer-compute.service + systemctl start openstack-ceilometer-compute.service + systemctl enable openstack-ceilometer-ipmi.service # 可选 + systemctl start openstack-ceilometer-ipmi.service # 可选 + + # 重启nova-compute服务 + systemctl restart openstack-nova-compute.service + ``` + +#### Heat + +Heat是 OpenStack 自动编排服务，基于描述性的模板来编排复合云应用，也称为`Orchestration Service`。Heat 的各服务一般安装在`Controller`节点上。 + +**Controller节点** + +1. 创建**heat**数据库，并授予**heat**数据库正确的访问权限，替换**HEAT_DBPASS**为合适的密码 + + ```sql + mysql -u root -p + + MariaDB [(none)]> CREATE DATABASE heat; + MariaDB [(none)]> GRANT ALL PRIVILEGES ON heat.* TO 'heat'@'localhost' IDENTIFIED BY 'HEAT_DBPASS'; + MariaDB [(none)]> GRANT ALL PRIVILEGES ON heat.* TO 'heat'@'%' IDENTIFIED BY 'HEAT_DBPASS'; + MariaDB [(none)]> exit; + ``` + +2. 创建服务凭证，创建**heat**用户，并为其增加**admin**角色 + + ```shell + source ~/.admin-openrc + + openstack user create --domain default --password-prompt heat + openstack role add --project service --user heat admin + ``` + +3. 创建**heat**和**heat-cfn**服务及其对应的API端点 + + ```shell + openstack service create --name heat --description "Orchestration" orchestration + openstack service create --name heat-cfn --description "Orchestration" cloudformation + openstack endpoint create --region RegionOne orchestration public http://controller:8004/v1/%\(tenant_id\)s + openstack endpoint create --region RegionOne orchestration internal http://controller:8004/v1/%\(tenant_id\)s + openstack endpoint create --region RegionOne orchestration admin http://controller:8004/v1/%\(tenant_id\)s + openstack endpoint create --region RegionOne cloudformation public http://controller:8000/v1 + openstack endpoint create --region RegionOne cloudformation internal http://controller:8000/v1 + openstack endpoint create --region RegionOne cloudformation admin http://controller:8000/v1 + ``` + +4. 创建stack管理的额外信息 + + 创建 **heat** domain + + ```shell + openstack domain create --description "Stack projects and users" heat + ``` + + 在 **heat** domain下创建 **heat_domain_admin** 用户，并记下输入的密码，用于配置下面的`HEAT_DOMAIN_PASS` + + ```shell + openstack user create --domain heat --password-prompt heat_domain_admin + ``` + + 为 **heat_domain_admin** 用户增加 **admin** 角色 + + ```shell + openstack role add --domain heat --user-domain heat --user heat_domain_admin admin + ``` + + 创建 **heat_stack_owner** 角色 + + ```shell + openstack role create heat_stack_owner + ``` + + 创建 **heat_stack_user** 角色 + + ```shell + openstack role create heat_stack_user + ``` + +5. 安装软件包 + + ```shell + dnf install openstack-heat-api openstack-heat-api-cfn openstack-heat-engine + ``` + +6. 修改配置文件`/etc/heat/heat.conf` + + ```ini + [DEFAULT] + transport_url = rabbit://openstack:RABBIT_PASS@controller + heat_metadata_server_url = http://controller:8000 + heat_waitcondition_server_url = http://controller:8000/v1/waitcondition + stack_domain_admin = heat_domain_admin + stack_domain_admin_password = HEAT_DOMAIN_PASS + stack_user_domain_name = heat + + [database] + connection = mysql+pymysql://heat:HEAT_DBPASS@controller/heat + + [keystone_authtoken] + www_authenticate_uri = http://controller:5000 + auth_url = http://controller:5000 + memcached_servers = controller:11211 + auth_type = password + project_domain_name = default + user_domain_name = default + project_name = service + username = heat + password = HEAT_PASS + + [trustee] + auth_type = password + auth_url = http://controller:5000 + username = heat + password = HEAT_PASS + user_domain_name = default + + [clients_keystone] + auth_uri = http://controller:5000 + ``` + +7. 初始化**heat**数据库表 + + ```shell + su -s /bin/sh -c "heat-manage db_sync" heat + ``` + +8. 启动服务 + + ```shell + systemctl enable openstack-heat-api.service openstack-heat-api-cfn.service openstack-heat-engine.service + systemctl start openstack-heat-api.service openstack-heat-api-cfn.service openstack-heat-engine.service + ``` + +#### Tempest + +Tempest是OpenStack的集成测试服务，如果用户需要全面自动化测试已安装的OpenStack环境的功能,则推荐使用该组件。否则，可以不用安装。 + +**Controller节点**： + +1. 安装Tempest + + ```shell + dnf install openstack-tempest + ``` + +2. 初始化目录 + + ```shell + tempest init mytest + ``` + +3. 修改配置文件。 + + ```shell + cd mytest + vi etc/tempest.conf + ``` + + tempest.conf中需要配置当前OpenStack环境的信息，具体内容可以参考[官方示例](https://docs.openstack.org/tempest/latest/sampleconf.html) + +4. 执行测试 + + ```shell + tempest run + ``` + +5. 安装tempest扩展（可选） + OpenStack各个服务本身也提供了一些tempest测试包，用户可以安装这些包来丰富tempest的测试内容。在Antelope中，我们提供了Cinder、Glance、Keystone、Ironic、Trove的扩展测试，用户可以执行如下命令进行安装使用： + + ```shell + dnf install python3-cinder-tempest-plugin python3-glance-tempest-plugin python3-ironic-tempest-plugin python3-keystone-tempest-plugin python3-trove-tempest-plugin + ``` + +## 基于OpenStack SIG开发工具oos部署 + +`oos`(openEuler OpenStack SIG)是OpenStack SIG提供的命令行工具。其中`oos env`系列命令提供了一键部署OpenStack （`all in one`或三节点`cluster`）的ansible脚本，用户可以使用该脚本快速部署一套基于 openEuler RPM 的 OpenStack 环境。`oos`工具支持对接云provider（目前仅支持华为云provider）和主机纳管两种方式来部署 OpenStack 环境，下面以对接华为云部署一套`all in one`的OpenStack环境为例说明`oos`工具的使用方法。 + +1. 安装`oos`工具 + + ```shell + yum install openstack-sig-tool + ``` + +2. 配置对接华为云provider的信息 + + 打开`/usr/local/etc/oos/oos.conf`文件，修改配置为您拥有的华为云资源信息，AK/SK是用户的华为云登录密钥，其他配置保持默认即可（默认使用新加坡region），需要提前在云上创建对应的资源，包括： + + - 一个安全组，名字默认是`oos` + - 一个openEuler镜像，名称格式是openEuler-%(release)s-%(arch)s，例如`openEuler-25.03-arm64` + - 一个VPC，名称是`oos_vpc` + - 该VPC下面两个子网，名称是`oos_subnet1`、`oos_subnet2` + + ```ini + [huaweicloud] + ak = + sk = + region = ap-southeast-3 + root_volume_size = 100 + data_volume_size = 100 + security_group_name = oos + image_format = openEuler-%%(release)s-%%(arch)s + vpc_name = oos_vpc + subnet1_name = oos_subnet1 + subnet2_name = oos_subnet2 + ``` + +3. 配置 OpenStack 环境信息 + + 打开`/usr/local/etc/oos/oos.conf`文件，根据当前机器环境和需求修改配置。内容如下： + + ```shell + [environment] + mysql_root_password = root + mysql_project_password = root + rabbitmq_password = root + project_identity_password = root + enabled_service = keystone,neutron,cinder,placement,nova,glance,horizon,aodh,ceilometer,cyborg,gnocchi,kolla,heat,swift,trove,tempest + neutron_provider_interface_name = br-ex + default_ext_subnet_range = 10.100.100.0/24 + default_ext_subnet_gateway = 10.100.100.1 + neutron_dataplane_interface_name = eth1 + cinder_block_device = vdb + swift_storage_devices = vdc + swift_hash_path_suffix = ash + swift_hash_path_prefix = has + glance_api_workers = 2 + cinder_api_workers = 2 + nova_api_workers = 2 + nova_metadata_api_workers = 2 + nova_conductor_workers = 2 + nova_scheduler_workers = 2 + neutron_api_workers = 2 + horizon_allowed_host = * + kolla_openeuler_plugin = false + ``` + + **关键配置** + + | 配置项 | 解释 | + |---|---| + | enabled_service | 安装服务列表，根据用户需求自行删减 | + | neutron_provider_interface_name | neutron L3网桥名称 | + | default_ext_subnet_range | neutron私网IP段 | + | default_ext_subnet_gateway | neutron私网gateway | + | neutron_dataplane_interface_name | neutron使用的网卡，推荐使用一张新的网卡，以免和现有网卡冲突，防止all in one主机断连的情况 | + | cinder_block_device | cinder使用的卷设备名 | + | swift_storage_devices | swift使用的卷设备名 | + | kolla_openeuler_plugin | 是否启用kolla plugin。设置为True，kolla将支持部署openEuler容器(只在openEuler LTS上支持) | + +4. 华为云上面创建一台|openEuler 25.03的x86_64虚拟机，用于部署`all in one` 的 OpenStack + + ```shell + # sshpass在`oos env create`过程中被使用，用于配置对目标虚拟机的免密访问 + dnf install sshpass + oos env create -r 25.03 -f small -a x86 -n test-oos all_in_one + ``` + + 具体的参数可以使用`oos env create --help`命令查看 + +5. 部署OpenStack `all in one` 环境 + + ```shell + oos env setup test-oos -r antelope + ``` + + 具体的参数可以使用`oos env setup --help`命令查看 + +6. 初始化tempest环境 + + 如果用户想使用该环境运行tempest测试的话，可以执行命令`oos env init`，会自动把tempest需要的OpenStack资源自动创建好 + + ```shell + oos env init test-oos + ``` + +7. 执行tempest测试 + + 用户可以使用oos自动执行： + + ```shell + oos env test test-oos + ``` + + 也可以手动登录目标节点，进入根目录下的`mytest`目录，手动执行`tempest run` + +如果是以主机纳管的方式部署 OpenStack 环境，总体逻辑与上文对接华为云时一致，1、3、5、6步操作不变，跳过第2步对华为云provider信息的配置，在第4步改为纳管主机操作。 + +被纳管的虚机需要保证： + +- 至少有一张给oos使用的网卡，名称与配置保持一致，相关配置`neutron_dataplane_interface_name` +- 至少有一块给oos使用的硬盘，名称与配置保持一致，相关配置`cinder_block_device` +- 如果要部署swift服务，则需要新增一块硬盘，名称与配置保持一致，相关配置`swift_storage_devices` + +```shell +# sshpass在`oos env create`过程中被使用，用于配置对目标主机的免密访问 +dnf install sshpass +oos env manage -r 25.03 -i TARGET_MACHINE_IP -p TARGET_MACHINE_PASSWD -n test-oos +``` + +替换`TARGET_MACHINE_IP`为目标机ip、`TARGET_MACHINE_PASSWD`为目标机密码。具体的参数可以使用`oos env manage --help`命令查看。 diff --git a/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/install/devstack.md b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/install/devstack.md new file mode 100644 index 0000000000000000000000000000000000000000..187b8716ad433d62391722b328b186a7d83410fc --- /dev/null +++ b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/install/devstack.md @@ -0,0 +1,176 @@ +# 使用Devstack安装OpenStack + +[TOC] + +目前OpenStack原生Devstack项目已经支持在openEuler上安装OpenStack，其中openEuler 20.03 LTS SP2已经过验证，并且有上游官方CI保证质量。其他版本的openEuler需要用户自行测试(2022-04-25 openEuler master分支已验证)。 + +## 安装步骤 + +准备一个openEuler环境, 20.03 LTS SP2[虚拟机镜像地址](https://repo.openeuler.org/openEuler-20.03-LTS-SP2/virtual_machine_img/), master[虚拟机镜像地址](http://121.36.84.172/dailybuild/openEuler-Mainline/) + +1. 配置yum源 + + **openEuler 20.03 LTS SP2**： + + openEuler官方源中缺少了一些OpenStack需要的RPM包，因此需要先配上OpenStack SIG在oepkg中准备好的RPM源 + + ```shell + vi /etc/yum.repos.d/openeuler.repo + + [openstack] + name=openstack + baseurl=https://repo.oepkgs.net/openEuler/rpm/openEuler-20.03-LTS-SP2/budding-openeuler/openstack-master-ci/aarch64/ + enabled=1 + gpgcheck=0 + ``` + + **openEuler master**: + + 使用master的RPM源: + + ```shell + vi /etc/yum.repos.d/openeuler.repo + + [mainline] + name=mainline + baseurl=http://119.3.219.20:82/openEuler:/Mainline/standard_aarch64/ + gpgcheck=false + + [epol] + name=epol + baseurl=http://119.3.219.20:82/openEuler:/Epol/standard_aarch64/ + gpgcheck=false + ``` + +2. 前期准备 + + **openEuler 20.03 LTS SP2**： + + 在一些版本的openEuler官方镜像的默认源中，EPOL-update的URL可能配置不正确，需要修改 + + ```shell + vi /etc/yum.repos.d/openEuler.repo + + # 把[EPOL-UPDATE]URL改成 + baseurl=http://repo.openeuler.org/openEuler-20.03-LTS-SP2/EPOL/update/main/$basearch/ + ``` + + **openEuler master**: + + ```shell + yum remove python3-pip # 系统的pip与devstack pip冲突，需要先删除 + # master的虚机环境缺少了一些依赖，devstack不会自动安装，需要手动安装 + yum install iptables tar wget python3-devel httpd-devel iscsi-initiator-utils libvirt python3-libvirt qemu memcached + ``` + +3. 下载devstack + + ```shell + yum update + yum install git + cd /opt/ + git clone https://opendev.org/openstack/devstack.git + ``` + +4. 初始化devstack环境配置 + + ```shell + # 创建stack用户 + /opt/devstack/tools/create-stack-user.sh + # 修改目录权限 + chown -R stack:stack /opt/devstack + chmod -R 755 /opt/devstack + chmod -R 755 /opt/stack + # 切换到要部署的openstack版本分支，以yoga为例，不切换的话，默认安装的是master版本的openstack + git checkout stable/yoga + ``` + +5. 初始化devstack配置文件 + + ```shell + 切换到stack用户 + su stack + 此时，请确认stack用户的PATH环境变量是否包含了`/usr/sbin`，如果没有，则需要执行 + PATH=$PATH:/usr/sbin + 新增配置文件 + vi /opt/devstack/local.conf + + [[local|localrc]] + DATABASE_PASSWORD=root + RABBIT_PASSWORD=root + SERVICE_PASSWORD=root + ADMIN_PASSWORD=root + OVN_BUILD_FROM_SOURCE=True + ``` + + openEuler没有提供OVN的RPM软件包，因此需要配置`OVN_BUILD_FROM_SOURCE=True`, 从源码编译OVN + + 另外如果使用的是arm64虚拟机环境，则需要配置libvirt嵌套虚拟化，在`local.conf`中追加如下配置： + + ```shell + [[post-config|$NOVA_CONF]] + [libvirt] + cpu_mode=custom + cpu_model=cortex-a72 + ``` + + 如果安装Ironic，需要提前安装依赖： + + ```bash + sudo dnf install syslinux-nonlinux + ``` + + **openEuler master的特殊配置**： 由于devstack还没有适配最新的openEuler，我们需要手动修复一些问题： + + 1. 修改devstack源码 + + ```shell + vi /opt/devstack/tools/fixup_stuff.sh + 把fixup_openeuler方法中的所有echo语句删掉 + (echo '[openstack-ci]' + echo 'name=openstack' + echo 'baseurl=https://repo.oepkgs.net/openEuler/rpm/openEuler-20.03-LTS-SP2/budding-openeuler/openstack-master-ci/'$arch'/' + echo 'enabled=1' + echo 'gpgcheck=0') | sudo tee -a /etc/yum.repos.d/openstack-master.repo > /dev/null + ``` + + 2. 修改requirements源码 + + Yoga版keystone的依赖`setproctitle`的devstack默认版本不支持python3.10，需要升级，手动下载requirements项目并修改 + + ```shell + cd /opt/stack + git clone https://opendev.org/openstack/requirements --branch stable/yoga + vi /opt/stack/requirements/upper-constraints.txt + setproctitle===1.2.3 + ``` + + 3. OpenStack horizon有BUG，无法正常安装。这里我们暂时不安装horizon，修改`local.conf`，新增一行： + + ```shell + [[local|localrc]] + disable_service horizon + ``` + + 如果确实有对horizon的需求，则需要解决以下问题： + + ```shell + # 1. horizon依赖的pyScss默认为1.3.7版本，不支持python3.10 + # 解决方法：需要提前clone`requirements`项目并修改代码 + vi /opt/stack/requirements/upper-constraints.txt + pyScss===1.4.0 + + # 2. horizon依赖httpd的mod_wsgi插件，但目前openEuler的mod_wsgi构建异常（2022-04-25）（解决后yum install mod_wsgi即可），无法从yum安装 + # 解决方法：手动源码build mod_wsgi并配置，该过程较复杂，这里略过 + ``` + + 4. dstat服务依赖的`pcp-system-tools`构建异常（2022-04-25）（解决后yum install pcp-system-tools即可），无法从yum安装，暂时先不安装dstat + + ```shell + [[local|localrc]] + disable_service dstat + ``` + +6. 部署OpenStack + + 进入devstack目录，执行`./stack.sh`，等待OpenStack完成安装部署。 diff --git a/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/openstack.md b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/openstack.md deleted file mode 100644 index 12a6cbce8d096144d41d64509786a741dde07888..0000000000000000000000000000000000000000 --- a/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/openstack.md +++ /dev/null @@ -1,3 +0,0 @@ -# openEuler OpenStack - -openEuler OpenStack相关文档已迁移至[OpenStack SIG官网文档](https://openstack-sig.readthedocs.io/zh/latest/)。请访问链接获取详细信息。 diff --git a/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/security/security-guide.md b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/security/security-guide.md new file mode 100644 index 0000000000000000000000000000000000000000..6c3a9a838c1fe05a32ccc2cb6afd97760db23e46 --- /dev/null +++ b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/security/security-guide.md @@ -0,0 +1,9425 @@ +# OpenStack安全指南 + +本文翻译自[上游安全指南](https://gitee.com/link?target=https%3A%2F%2Fdocs.openstack.org%2Fsecurity-guide%2F) + +[TOC] + +## 摘要 + +本书提供了有关保护OpenStack云的最佳实践和概念信息。 + +本指南最后一次更新是在Train发布期间，记录了OpenStack Train、Stein和Rocky版本。它可能不适用于EOL版本（例如Newton）。我们建议您在计划为您的OpenStack云实施安全措施时，自行阅读本文。本指南仅供参考。OpenStack安全团队基于OpenStack社区的自愿贡献。您可以在OFTC IRC上的#OpenStack-Security频道中直接联系安全社区，或者通过向OpenStack-Discussion邮件列表发送主题标题中带有[Security]前缀的邮件来联系。 + +## 内容 + +- 约定 + + - 通知 + - 命令提示符 + +- 介绍 + + - 确定 + - 我们为什么以及如何写这本书 + - OpenStack简介 + - 安全边界和威胁 + - 选择支持软件 + +- 系统文档 + + - 系统文档要求 + +- 管理 + + - 持续的系统管理 + - 完整性生命周期 + - 管理界面 + +- 安全通信 + + - TLS和SSL简介 + - TLS代理和HTTP服务 + - 安全参考架构 + +- 端点 + + - APL端点配置建议 + +- 身份 + + - 认证 + - 身份验证方法 + - 授权 + - 政策 + - 令牌 + - 域 + - 联合梯形失真 + - 清单 + +- 仪表板 + + - 域名、仪表板升级和基本Web服务器配置 + - HTTPS、HSTS、XSS和SSRF + - 前端缓存和会话后端 + - 静态媒体 + - 密码 + - 密钥 + - 网站数据 + - 跨域资源共享 （CORS） + - 调试 + - 检查表 + +- 计算 + + - 虚拟机管理程序选择 + - 强化虚拟化层 + - 强化计算部署 + - 漏洞意识 + - 如何选择虚拟控制台 + - 检查表 + +- 块存储 + + - 音量擦除 + - 检查表 + +- 图像存储 + + - 检查表 + +- 共享文件系统 + + - 介绍 + - 网络和安全模型 + - 安全服务 + - 共享访问控制 + - 共享类型访问控制 + - 政策 + - 检查表 + +- 联网 + + - 网络架构 + - 网络服务 + - 网络服务安全最佳做法 + - 保护 OpenStack 网络服务 + - 检查表 + +- 对象存储 + + - 网络安全 + - 一般事务安全 + - 保护存储服务 + - 保护代理服务 + - 对象存储身份验证 + - 其他值得注意的项目 + +- 机密管理 + + - 现有技术摘要 + - 相关 Openstack 项目 + - 使用案例 + - 密钥管理服务 + - 密钥管理接口 + - 常见问题解答 + - 检查表 + +- 消息队列 + + - 邮件安全 + +- 数据处理 + + - 数据处理简介 + - 部署 + - 配置和强化 + +- 数据库 + + - 数据库后端注意事项 + - 数据库访问控制 + - 数据库传输安全性 + +- 租户数据隐私 + + - 数据隐私问题 + - 数据加密 + - 密钥管理 + +- 实例安全管理 + + - 实例的安全服务 + +- 监视和日志记录 + + - 取证和事件响应 + +- 合规 + + - 合规性概述 + - 了解审核流程 + - 合规活动 + - 认证和合规声明 + - 隐私 + +- 安全审查 + + - 体系结构页面指南 + +- 安全检查表 +- 附录 + + - 社区支持 + - 词汇表 + +## 约定 + +OpenStack 文档使用了几种排版约定。 + +### 注意事项 + +**注意** + +```shell +带有附加信息的注释，用于解释文本的某一部分。 +``` + +**重要** + +```shell +在继续之前，您必须注意这一点。 +``` + +**提示** + +```shell +一个额外但有用的实用建议。 +``` + +**警示** + +```shell +防止用户犯错误的有用信息。 +``` + +**警告** + +```shell +有关数据丢失风险或安全问题的关键信息。 +``` + +### 命令提示符 + +```shell +$ command +``` + +任何用户（包括root用户）都可以运行以$提示符为前缀的命令。 + +```shell +# command +``` + +root用户必须运行前缀为#提示符的命令。您还可以在这些命令前面加上sudo命令（如果可用），以运行这些命令。 + +## 介绍 + +《OpenStack 安全指南》是许多人经过五天协作的成果。本文档旨在提供部署安全 OpenStack 云的最佳实践指南。它旨在反映OpenStack社区的当前安全状态，并为由于复杂性或其他特定于环境的细节而无法列出特定安全控制措施的决策提供框架。 + +- 致谢 +- 我们为什么以及如何写这本书 + + - 目标 + - 如何 + +- OpenStack 简介 + + - 云类型 + - OpenStack 服务概述 + +- 安全边界和威胁 + + - 安全域 + - 桥接安全域 + - 威胁分类、参与者和攻击媒介 + +- 选择支持软件 + + - 团队专长 + - 产品或项目成熟度 + - 通用标准 + - 硬件问题 + +### 致谢 + +OpenStack 安全组要感谢以下组织的贡献，他们为本书的出版做出了贡献。这些组织是： + +![../_images/book-sprint-all-logos.png](https://docs.openstack.org/security-guide/_images/book-sprint-all-logos.png) + +### 我们为什么以及如何写这本书 + +随着 OpenStack 的普及和产品成熟，安全性已成为重中之重。OpenStack 安全组已经认识到需要一个全面而权威的安全指南。《OpenStack 安全指南》旨在概述提高 OpenStack 部署安全性的安全最佳实践、指南和建议。作者带来了他们在各种环境中部署和保护 OpenStack 的专业知识。 + +本指南是对《OpenStack 操作指南》的补充，可用于强化现有的 OpenStack 部署或评估 OpenStack 云提供商的安全控制。 + +#### 目标 + +- 识别 OpenStack 中的安全域 +- 提供保护 OpenStack 部署的指导 +- 强调当今 OpenStack 中的安全问题和潜在的缓解措施 +- 讨论即将推出的安全功能 +- 为知识获取和传播提供社区驱动的设施 + +#### 写作记录 + +与《OpenStack 操作指南》一样，我们遵循了本书的冲刺方法。书籍冲刺过程允许快速开发和制作大量书面作品。OpenStack 安全组的协调员重新邀请了 Adam Hyde 作为协调人。该项目在俄勒冈州波特兰市的OpenStack峰会上正式宣布。 + +由于该小组的一些关键成员离得很近，该团队聚集在马里兰州安纳波利斯。这是公共部门情报界成员、硅谷初创公司和一些大型知名科技公司之间的非凡合作。该书的冲刺在2013年6月的最后一周进行，第一版在五天内完成。 + +该团队包括： + +- Bryan D. Payne，星云 + Bryan D. Payne 博士是 Nebula 的安全研究总监，也是 OpenStack 安全组织 （OSSG） 的联合创始人。在加入 Nebula 之前，他曾在桑迪亚国家实验室、国家安全局、BAE Systems 和 IBM 研究院工作。他毕业于佐治亚理工学院计算机学院，获得计算机科学博士学位，专攻系统安全。Bryan 是《OpenStack 安全指南》的编辑和负责人，负责该指南在编写后的两年中持续增长。 + +- Robert Clark，惠普 + + Robert Clark 是惠普云服务的首席安全架构师，也是 OpenStack 安全组织 （OSSG） 的联合创始人。在被惠普招募之前，他曾在英国情报界工作。Robert 在威胁建模、安全架构和虚拟化技术方面拥有深厚的背景。Robert 拥有威尔士大学的软件工程硕士学位。 + +- Keith Basil ，红帽 + + Keith Basil 是红帽 OpenStack 的首席产品经理，专注于红帽的 OpenStack 产品管理、开发和战略。在美国公共部门，Basil 带来了为联邦民用机构和承包商设计授权、安全、高性能云架构的经验。 + +- Cody Bunch，拉克空间 + + Cody Bunch 是 Rackspace 的私有云架构师。Cody 与人合著了《The OpenStack Cookbook》的更新以及有关 VMware 自动化的书籍。 + +- Malini Bhandaru，英特尔 + + Malini Bhandaru 是英特尔的一名安全架构师。她拥有多元化的背景，曾在英特尔从事平台功能和性能方面的工作，在 Nuance 从事语音产品方面的工作，在 ComBrio 从事远程监控和管理工作，在 Verizon 从事网络商务工作。她拥有马萨诸塞大学阿默斯特分校的人工智能博士学位。 + +- Gregg Tally，约翰霍普金斯大学应用物理实验室 + + Gregg Tally 是 JHU/APL 网络系统部门非对称运营部的总工程师。他主要从事系统安全工程方面的工作。此前，他曾在斯巴达、迈克菲和可信信息系统公司工作，参与网络安全研究项目。 + +- Eric Lopez, 威睿 + + Eric Lopez 是 VMware 网络和安全业务部门的高级解决方案架构师，他帮助客户实施 OpenStack 和 VMware NSX（以前称为 Nicira 的网络虚拟化平台）。在加入 VMware（通过公司收购 Nicira）之前，他曾在 Q1 Labs、Symantec、Vontu 和 Brightmail 工作。他拥有加州大学伯克利分校的电气工程/计算机科学和核工程学士学位和旧金山大学的工商管理硕士学位。 + +- Shawn Wells，红帽 + + Shawn Wells 是红帽创新项目总监，专注于改进美国政府内部采用、促进和管理开源技术的流程。此外，Shawn 还是 SCAP 安全指南项目的上游维护者，该项目与美国军方、NSA 和 DISA 一起制定虚拟化和操作系统强化策略。Shawn曾是NSA的平民，利用大型分布式计算基础设施开发了SIGINT收集系统。 + +- Ben de Bont，惠普 + + Ben de Bont 是惠普云服务的首席战略官。在担任现职之前，Ben 领导 MySpace 的信息安全小组和 MSN Security 的事件响应团队。Ben 拥有昆士兰科技大学的计算机科学硕士学位。 + +- Nathanael Burton，国家安全局 + + 纳塔内尔·伯顿（Nathanael Burton）是美国国家安全局（National Security Agency）的计算机科学家。他在该机构工作了 10 多年，从事分布式系统、大规模托管、开源计划、操作系统、安全、存储和虚拟化技术方面的工作。他拥有弗吉尼亚理工大学的计算机科学学士学位。 + +- Vibha Fauver + + Vibha Fauver，GWEB，CISSP，PMP，在信息技术领域拥有超过15年的经验。她的专业领域包括软件工程、项目管理和信息安全。她拥有计算机与信息科学学士学位和工程管理硕士学位，专业和系统工程证书。 + +- Eric Windisch，云缩放 + + Eric Windisch 是 Cloudscaling 的首席工程师，他为 OpenStack 贡献了两年多。埃里克（Eric）在网络托管行业拥有十多年的经验，一直在敌对环境的战壕中，建立了租户隔离和基础设施安全性。自 2007 年以来，他一直在构建云计算基础设施和自动化。 + +- Andrew Hay，云道 + + Andrew Hay 是 CloudPassage， Inc. 的应用安全研究总监，负责领导该公司及其专为动态公有云、私有云和混合云托管环境构建的服务器安全产品的安全研究工作。 + +- Adam Hyde + + 亚当促成了这个 Book Sprint。他还创立了 Book Sprint 方法论，并且是最有经验的 Book Sprint 促进者。Adam 创立了 FLOSS Manuals，这是一个由 3,000 人组成的社区，致力于开发关于自由软件的自由手册。他还是 Booktype 的创始人和项目经理，Booktype 是一个用于在线和印刷书籍编写、编辑和出版的开源项目。 + +在冲刺期间，我们还得到了 Anne Gentle、Warren Wang、Paul McMillan、Brian Schott 和 Lorin Hochstein 的帮助。 + +这本书是在为期 5 天的图书冲刺中制作的。图书冲刺是一个高度协作、促进的过程，它将一个小组聚集在一起，在 3-5 天内制作一本书。这是一个由亚当·海德（Adam Hyde）创立和发展的特定方法的有力促进过程。有关更多信息，请访问BookSprints的Book Sprint网页。 + +#### 如何为本书做贡献 + +本书的最初工作是在一间空调过高的房间里进行的，该房间是整个文档冲刺期间的小组办公室。 + +要了解有关如何为 OpenStack 文档做出贡献的更多信息，请参阅 OpenStack 文档贡献者指南。 + +### OpenStack 简介 + +本指南提供了对 OpenStack 部署的安全见解。目标受众是云架构师、部署人员和管理员。此外，云用户会发现该指南在提供商选择方面既有教育意义又有帮助，而审计人员会发现它作为参考文档很有用，可以支持他们的合规性认证工作。本指南也推荐给任何对云安全感兴趣的人。 + +每个 OpenStack 部署都包含各种各样的技术，包括 Linux 发行版、数据库系统、消息队列、OpenStack 组件本身、访问控制策略、日志记录服务、安全监控工具等等。所涉及的安全问题同样多种多样也就不足为奇了，对这些问题的深入分析需要一些指南。我们努力寻找平衡点，提供足够的背景信息来理解OpenStack安全问题及其处理，并为进一步的信息提供外部参考。该指南可以从头到尾阅读，也可以像参考一样使用。 + +我们简要介绍了云的种类（私有云、公有云和混合云），然后在本章的其余部分概述了 OpenStack 组件及其相关的安全问题。 + +在整本书中，我们提到了几种类型的OpenStack云用户：管理员、操作员和用户。我们使用这些术语来标识每个角色具有的安全访问级别，尽管实际上，我们知道不同的角色通常由同一个人担任。 + +#### 云类型 + +OpenStack是采用云技术的关键推动因素，并具有几个常见的部署用例。这些模型通常称为公共模型、专用模型和混合模型。以下各节使用美国国家标准与技术研究院 （NIST） 对云的定义来介绍这些适用于 OpenStack 的不同类型的云。 + +#### 公有云 + +根据NIST的说法，公共云是基础设施向公众开放供消费的云。OpenStack公有云通常由服务提供商运行，可供个人、公司或任何付费客户使用。除了多种实例类型外，公有云提供商还可能公开一整套功能，例如软件定义网络或块存储。 + +就其性质而言，公有云面临更高的风险。作为公有云的使用者，您应该验证所选提供商是否具有必要的认证、证明和其他法规注意事项。作为公有云提供商，根据您的目标客户，您可能需要遵守一项或多项法规。此外，即使不需要满足法规要求，提供商也应确保租户隔离，并保护管理基础结构免受外部攻击。 + +#### 私有云 + +在频谱的另一端是私有云。正如NIST所定义的那样，私有云被配置为由多个消费者（如业务部门）组成的单个组织独占使用。云可能由组织、第三方或它们的某种组合拥有、管理和运营，并且可能存在于本地或外部。私有云用例多种多样，因此，它们各自的安全问题各不相同。 + +#### 社区云 + +NIST 将社区云定义为其基础结构仅供具有共同关注点（例如，任务、安全要求、策略或合规性注意事项）的组织的特定消费者社区使用。云可能由社区中的一个或多个组织、第三方或它们的某种组合拥有、管理和运营，并且它可能存在于本地或外部。 + +#### 混合云 + +NIST将混合云定义为两个或多个不同的云基础设施（如私有云、社区云或公共云）的组合，这些云基础设施仍然是唯一的实体，但通过标准化或专有技术绑定在一起，从而实现数据和应用程序的可移植性，例如用于云之间负载平衡的云爆发。例如，在线零售商可能会在允许弹性配置的公有云上展示其广告和目录。这将使他们能够以灵活、具有成本效益的方式处理季节性负载。一旦客户开始处理他们的订单，他们就会被转移到一个更安全的私有云中，该私有云符合PCI标准。 + +在本文档中，我们以类似的方式对待社区和混合云，仅从安全角度明确处理公有云和私有云的极端情况。安全措施取决于部署在私有公共连续体上的位置。 + +### OpenStack 服务概述 + +OpenStack 采用模块化架构，提供一组核心服务，以促进可扩展性和弹性作为核心设计原则。本章简要回顾了 OpenStack 组件、它们的用例和安全注意事项。 + +[![../_images/marketecture-diagram.png](https://docs.openstack.org/security-guide/_images/marketecture-diagram.png)](https://docs.openstack.org/security-guide/_images/marketecture-diagram.png) + +### 计算 + +OpenStack Compute 服务 （nova） 提供的服务支持大规模管理虚拟机实例、托管多层应用程序的实例、开发或测试环境、处理 Hadoop 集群的“大数据”或高性能计算。 + +计算服务通过与支持的虚拟机监控程序交互的抽象层来促进这种管理（我们稍后会更详细地讨论这个问题）。 + +在本指南的后面部分，我们将重点介绍虚拟化堆栈，因为它与虚拟机管理程序相关。 + +有关功能支持的当前状态的信息，请参阅 OpenStack Hypervisor 支持矩阵。 + +计算安全性对于OpenStack部署至关重要。强化技术应包括对强实例隔离的支持、计算子组件之间的安全通信以及面向公众的 API 终结点的复原能力。 + +#### 对象存储 + +OpenStack 对象存储服务 （swift） 支持在云中存储和检索任意数据。对象存储服务提供本机 API 和亚马逊云科技 S3 兼容 API。该服务通过数据复制提供高度的复原能力，并且可以处理 PB 级的数据。 + +请务必了解对象存储不同于传统的文件系统存储。对象存储最适合用于静态数据，例如媒体文件（MP3、图像或视频）、虚拟机映像和备份文件。 + +对象安全应侧重于传输中和静态数据的访问控制和加密。其他问题可能与系统滥用、非法或恶意内容存储以及交叉身份验证攻击媒介有关。 + +#### 块存储 + +OpenStack 块存储服务 （cinder） 为计算实例提供持久性块存储。块存储服务负责管理块设备的生命周期，从创建卷和附加到实例，再到释放。 + +块存储的安全注意事项与对象存储的安全注意事项类似。 + +#### 共享文件系统 + +共享文件系统服务（马尼拉）提供了一组用于管理多租户云环境中的共享文件系统的服务，类似于 OpenStack 通过 OpenStack 块存储服务项目提供基于块的存储管理的方式。使用共享文件系统服务，您可以创建远程文件系统，将文件系统挂载到实例上，然后从实例读取和写入文件系统中的数据。 + +#### 网络 + +OpenStack 网络服务（neutron，以前称为量子）为云用户（租户）提供各种网络服务，例如 IP 地址管理、DNS、DHCP、负载均衡和安全组（网络访问规则，如防火墙策略）。此服务为软件定义网络 （SDN） 提供了一个框架，允许与各种网络解决方案进行可插拔集成。 + +OpenStack Networking 允许云租户管理其访客网络配置。网络服务的安全问题包括网络流量隔离、可用性、完整性和机密性。 + +#### 仪表板 + +OpenStack 仪表板 （horizon） 为云管理员和云租户提供了一个基于 Web 的界面。使用此界面，管理员和租户可以预配、管理和监视云资源。仪表板通常以面向公众的方式部署，具有公共 Web 门户的所有常见安全问题。 + +#### 身份鉴别服务 + +OpenStack Identity 服务 （keystone） 是一项共享服务，可在整个云基础架构中提供身份验证和授权服务。Identity 服务具有对多种身份验证形式的可插入支持。 + +Identity 服务的安全问题包括对身份验证的信任、授权令牌的管理以及安全通信。 + +#### 镜像服务 + +OpenStack 镜像服务（glance）提供磁盘镜像管理服务，包括镜像发现、注册和根据需要向计算服务交付服务。 + +需要受信任的进程来管理磁盘映像的生命周期，以及前面提到的与数据安全有关的所有问题。 + +#### 数据处理服务 + +数据处理服务 （sahara） 提供了一个平台，用于配置、管理和使用运行常用处理框架的群集。 + +数据处理的安全注意事项应侧重于数据隐私和与预置集群的安全通信。 + +#### 其他配套技术 + +消息传递用于多个 OpenStack 服务之间的内部通信。默认情况下，OpenStack 使用基于 AMQP 的消息队列。与大多数 OpenStack 服务一样，AMQP 支持可插拔组件。现在，实现后端可以是 RabbitMQ、Qpid 或 ZeroMQ。 + +由于大多数管理命令都流经消息队列系统，因此消息队列安全性是任何 OpenStack 部署的主要安全问题，本指南稍后将对此进行详细讨论。 + +有几个组件使用数据库，尽管它没有显式调用。保护数据库访问是另一个安全问题，因此在本指南后面将更详细地讨论。 + +### 安全边界和威胁 + +云可以抽象为逻辑组件的集合，因为它们的功能、用户和共享的安全问题，我们称之为安全域。威胁参与者和向量根据其动机和对资源的访问进行分类。我们的目标是根据您的风险/漏洞保护目标，让您了解每个域的安全问题。 + +#### 安全域 + +安全域包括用户、应用程序、服务器或网络，它们在系统中具有共同的信任要求和期望。通常，它们具有相同的身份验证和授权 （AuthN/Z） 要求和用户。 + +尽管您可能希望进一步细分这些域（我们稍后将讨论在哪些方面可能合适），但我们通常指的是四个不同的安全域，它们构成了安全部署任何 OpenStack 云所需的最低限度。这些安全域包括： + +1. 公共域 +2. 访客域 +3. 管理域 +4. 数据域 + +我们之所以选择这些安全域，是因为它们可以独立映射，也可以组合起来，以表示给定 OpenStack 部署中大多数可能的信任区域。例如，某些部署拓扑可能由一个物理网络上的来宾域和数据域的组合组成，而其他拓扑则将这些域分开。在每种情况下，云操作员都应注意适当的安全问题。安全域应针对特定的 OpenStack 部署拓扑进行映射。域及其信任要求取决于云实例是公有云实例、私有云实例还是混合云实例。 + +![../_images/untrusted_trusted.png](https://docs.openstack.org/security-guide/_images/untrusted_trusted.png) + +#### 公共 + +公共安全域是云基础架构中完全不受信任的区域。它可以指整个互联网，也可以简单地指您无权访问的网络。任何具有机密性或完整性要求传输此域的数据都应使用补偿控制进行保护。 + +此域应始终被视为不受信任。 + +#### 访客 + +访客安全域通常用于计算实例到实例的流量，它处理由云上的实例生成的计算数据，但不处理支持云操作的服务，例如 API 调用。 + +如果公有云和私有云提供商对实例使用没有严格控制，也不允许对虚拟机进行不受限制的 Internet 访问，则应将此域视为不受信任的域。私有云提供商可能希望将此网络视为内部网络，并且只有在实施适当的控制以断言实例和所有关联租户都是可信的时。 + +#### 管理 + +管理安全域是服务交互的地方。有时称为“控制平面”，此域中的网络传输机密数据，例如配置参数、用户名和密码。命令和控制流量通常驻留在此域中，这需要强大的完整性要求。对此域的访问应受到高度限制和监视。同时，此域仍应采用本指南中描述的所有安全最佳做法。 + +在大多数部署中，此域被视为受信任的域。但是，在考虑 OpenStack 部署时，有许多系统将此域与其他域桥接起来，这可能会降低您可以对该域的信任级别。有关更多信息，请参阅桥接安全域。 + +#### 数据 + +数据安全域主要关注与OpenStack中的存储服务有关的信息。通过该网络传输的大多数数据都需要高度的完整性和机密性。在某些情况下，根据部署类型，可能还会有很强的可用性要求。 + +此网络的信任级别很大程度上取决于部署决策，因此我们不会为其分配任何默认的信任级别。 + +#### 桥接安全域 + +网桥是存在于多个安全域中的组件。必须仔细配置桥接具有不同信任级别或身份验证要求的安全域的任何组件。这些网桥通常是网络架构中的薄弱环节。桥接应始终配置为满足它所桥接的任何域的最高信任级别的安全要求。在许多情况下，由于攻击的可能性，桥接器的安全控制应该是主要关注点。 + +![../_images/bridging_security_domains_1.png](https://docs.openstack.org/security-guide/_images/bridging_security_domains_1.png) + +上图显示了桥接数据和管理域的计算节点;因此，应将计算节点配置为满足管理域的安全要求。同样，此图中的 API 端点正在桥接不受信任的公共域和管理域，应将其配置为防止从公共域传播到管理域的攻击。 + +![../_images/bridging_domains_clouduser.png](https://docs.openstack.org/security-guide/_images/bridging_domains_clouduser.png) + +在某些情况下，部署人员可能希望考虑将网桥保护到比它所在的任何域更高的标准。鉴于上述 API 端点示例，攻击者可能会从公共域以 API 端点为目标，利用它来入侵或访问管理域。 + +OpenStack的设计使得安全域的分离是很困难的。由于核心服务通常至少桥接两个域，因此在对它们应用安全控制时必须特别考虑。 + +#### 威胁分类、参与者和攻击向量 + +大多数类型的云部署（公有云或私有云）都会受到某种形式的攻击。在本章中，我们将对攻击者进行分类，并总结每个安全域中的潜在攻击类型。 + +#### 威胁参与者 + +威胁参与者是一种抽象的方式，用于指代您可能尝试防御的一类对手。参与者的能力越强，成功缓解和预防攻击所需的安全控制就越昂贵。安全性是成本、可用性和防御之间的权衡。在某些情况下，不可能针对我们在此处描述的所有威胁参与者保护云部署。那些部署OpenStack云的人将不得不决定其部署/使用的平衡点在哪里。 + +##### 情报机构 + +本指南认为是最有能力的对手。情报部门和其他国家行为者可以为目标带来巨大的资源。他们拥有超越任何其他参与者的能力。如果没有极其严格的控制措施，无论是人力还是技术，都很难防御这些行为者。 + +##### 严重有组织犯罪 + +能力强且受经济驱动的攻击者群体。能够资助内部漏洞开发和目标研究。近年来，俄罗斯商业网络（Russian Business Network）等组织的崛起，一个庞大的网络犯罪企业，已经证明了网络攻击如何成为一种商品。工业间谍活动属于严重的有组织犯罪集团。 + +##### 高能力的团队 + +这是指“黑客行动主义者”类型的组织，他们通常没有商业资助，但可能对服务提供商和云运营商构成严重威胁。 + +##### 有动机的个人 + +这些攻击者单独行动，以多种形式出现，例如流氓或恶意员工、心怀不满的客户或小规模的工业间谍活动。 + +##### 脚本攻击者 + +自动漏洞扫描/利用。非针对性攻击。通常，只有这些行为者之一的滋扰、妥协才会对组织的声誉构成重大风险。 + +![../_images/threat_actors.png](https://docs.openstack.org/security-guide/_images/threat_actors.png) + +#### 公有云和私有云注意事项 + +私有云通常由企业或机构在其网络内部和防火墙后面部署。企业将对允许哪些数据退出其网络有严格的政策，甚至可能为特定目的使用不同的云。私有云的用户通常是拥有云的组织的员工，并且能够对其行为负责。员工通常会在访问云之前参加培训课程，并且可能会参加定期安排的安全意识培训。相比之下，公有云不能对其用户、云用例或用户动机做出任何断言。对于公有云提供商来说，这会立即将客户机安全域推入完全不受信任的状态。 + +公有云攻击面的一个显着区别是，它们必须提供对其服务的互联网访问。实例连接、通过 Internet 访问文件以及与云控制结构（如 API 端点和仪表板）交互的能力是公有云的必备条件。 + +公有云和私有云用户的隐私问题通常是截然相反的。在私有云中生成和存储的数据通常由云运营商拥有，他们能够部署数据丢失防护 （DLP） 保护、文件检查、深度数据包检查和规范性防火墙等技术。相比之下，隐私是采用公有云基础设施的主要障碍之一，因为前面提到的许多控制措施并不存在。 + +#### 出站攻击和声誉风险 + +应仔细考虑云部署中潜在的出站滥用。无论是公有云还是私有云，云往往都有大量可用资源。通过黑客攻击或授权访问在云中建立存在点的攻击者（例如流氓员工）可以使这些资源对整个互联网产生影响。具有计算服务的云是理想的 DDoS 和暴力引擎。对于公有云来说，这个问题更为紧迫，因为它们的用户在很大程度上是不负责任的，并且可以迅速启动大量一次性实例进行出站攻击。如果一家公司因托管恶意软件或对其他网络发起攻击而闻名，可能会对公司的声誉造成重大损害。预防方法包括出口安全组、出站流量检查、客户教育和意识，以及欺诈和滥用缓解策略。 + +#### 攻击类型 + +该图显示了上一节中描述的参与者可能预期的典型攻击类型。请注意，此图不排除有不可预期的攻击类型。 + +![../_images/high-capability.png](https://docs.openstack.org/security-guide/_images/high-capability.png) + +攻击类型 + +每种攻击形式的规范性防御超出了本文档的范围。上图可以帮助您就应防范哪些类型的威胁和威胁参与者做出明智的决定。对于商业公有云部署，这可能包括预防严重犯罪。对于那些为政府使用部署私有云的人来说，应该建立更严格的保护机制，包括精心保护的设施和供应链。相比之下，那些建立基本开发或测试环境的人可能需要限制较少的控制（中间）。 + +### 选择支持软件 + +您选择的支持软件（如消息传递和负载平衡）可能会对云产生严重的安全影响。为组织做出正确的选择非常重要。本节提供了选择支持软件的一些一般准则。 + +为了选择最佳支持软件，请考虑以下因素： + +- 团队专业知识 +- 产品或项目成熟度 +- 通用标准 +- 硬件问题 + +#### 团队专业知识 + +团队越熟悉特定产品、其配置和特殊性，就越少会出现配置错误。此外，将员工的专业知识分散到整个组织中可以增加系统的可用性，允许分工，并在团队成员不可用时减轻问题。 + +#### 产品或项目成熟度 + +给定产品或项目的成熟度对您的安全状况至关重要。部署云后，产品成熟度会产生许多影响： + +- 专业知识的可用性 +- 活跃的开发人员和用户社区 +- 更新的及时性和可用性 +- 事件响应 + +#### 通用标准 + +通用标准是一个国际标准化的软件评估过程，政府和商业公司使用它来验证软件技术的性能是否如宣传的那样。 + +#### 硬件问题 + +考虑运行软件的硬件的可支持性。此外，请考虑硬件中可用的其他功能，以及您选择的软件如何支持这些功能。 + +## 系统文档 + +OpenStack 云部署的系统文档应遵循组织中企业信息技术系统的模板和最佳实践。组织通常有合规性要求，这可能需要一个整体的系统安全计划来清点和记录给定系统的架构。整个行业都面临着与记录动态云基础架构和保持信息最新相关的共同挑战。 + +- 系统文档要求 + + - 系统角色和类型 + - 系统清单 + - 网络拓扑 + - 服务、协议和端口 + +### 系统文档要求 + +#### 系统角色和类型 + +通常构成 OpenStack 安装的两种广义节点类型是： + +##### 基础设施节点 + +运行与云相关的服务，例如 OpenStack Identity 服务、消息队列服务、存储、网络以及支持云运行所需的其他服务。 + +##### 计算、存储或其他资源节点 + +为云提供存储容量或虚拟机。 + +#### 系统清单 + +文档应提供OpenStack环境的一般描述，并涵盖使用的所有系统（例如，生产、开发或测试）。记录系统组件、网络、服务和软件通常提供全面覆盖和考虑安全问题、攻击媒介和可能的安全域桥接点所需的鸟瞰图。系统清单可能需要捕获临时资源，例如虚拟机或虚拟磁盘卷，否则这些资源将成为传统 IT 系统中的持久性资源。 + +#### 硬件清单 + +对书面文档没有严格合规性要求的云可能会受益于配置管理数据库 （CMDB）。CMDB通常用于硬件资产跟踪和整体生命周期管理。通过利用 CMDB，组织可以快速识别云基础设施硬件，例如计算节点、存储节点或网络设备。CMDB可以帮助识别网络上存在的资产，这些资产可能由于维护不足、保护不足或被取代和遗忘而存在漏洞。如果底层硬件支持必要的自动发现功能，则 OpenStack 置备系统可以提供一些基本的 CMDB 功能。 + +#### 软件清单 + +与硬件一样，OpenStack 部署中的所有软件组件都应记录在案。示例包括： + +- 系统数据库，例如 MySQL 或 mongoDB +- OpenStack 软件组件，例如 Identity 或 Compute +- 支持组件，例如负载均衡器、反向代理、DNS 或 DHCP 服务 + +在评估库、应用程序或软件类别中泄露或漏洞的影响时，软件组件的权威列表可能至关重要。 + +#### 网络拓扑 + +应提供网络拓扑，并突出显示安全域之间的数据流和桥接点。网络入口和出口点应与任何 OpenStack 逻辑系统边界一起标识。可能需要多个图表来提供系统的完整视觉覆盖。网络拓扑文档应包括系统代表租户创建的虚拟网络，以及 OpenStack 创建的虚拟机实例和网关。 + +#### 服务、协议和端口 + +了解有关组织资产的信息通常是最佳做法。资产表可以帮助验证安全要求，并帮助维护标准安全组件，例如防火墙配置、服务端口冲突、安全修正区域和合规性。此外，该表还有助于理解 OpenStack 组件之间的关系。该表可能包括： + +- OpenStack 部署中使用的服务、协议和端口。 +- 云基础架构中运行的所有服务的概述。 + +强烈建议 OpenStack 部署记录与此类似的信息。该表可以根据从 CMDB 派生的信息创建，也可以手动构建。 + +下面提供了一个表格示例： + +| 服务 | 协议 | 端口 | 目的 | 使用者 | 安全域 | +| -------- | ----- | -------- | ------------------------------ | --------- | ------------------------------------ | +| beam.smp | AMQP | 5672/tcp | AMQP 消息服务 | RabbitMQ | 管理域 | +| tgtd | iSCSI | 3260/tcp | iSCSI 发起程序服务 | iSCSI | 私有（数据网络） | +| sshd | ssh | 22/tcp | 允许安全登录到节点和来宾虚拟机 | Various | 按需配置作用于管理域、公共域和访客域 | +| mysqld | mysql | 3306/tcp | 数据库服务 | Various | 管理域 | +| apache2 | http | 443/tcp | 仪表板 | Tenants | 公共域 | +| dnsmasq | dns | 53/tcp | DNS 服务 | Guest VMs | 访客域 | + +## 管理 + +云部署是一个不断变化的系统。机器老化和故障，软件过时，漏洞被发现。当配置中出现错误或遗漏时，或者必须应用软件修复时，必须以安全但方便的方式进行这些更改。这些更改通常通过配置管理来解决。 + +保护云部署不被恶意实体配置或操纵非常重要。由于云中的许多系统都采用计算和网络虚拟化，因此 OpenStack 面临着明显的挑战，必须通过完整性生命周期管理来解决这些挑战。 + +管理员必须对云执行命令和控制，以实现各种操作功能。理解和保护这些指挥和控制设施非常重要。 + +- 持续的系统管理 + + - 漏洞管理 + - 配置管理 + - 安全备份和恢复 + - 安全审计工具 + +- 完整性生命周期 + + - 安全引导 + - 运行时验证 + - 服务器加固 + +- 管理界面 + + - 仪表板 + - OpenStack 接口 + - 安全外壳 （SSH） + - 管理实用程序 + - 带外管理接口 + +### 持续的系统管理 + +云系统总会存在漏洞，其中一些可能是安全问题。因此，准备好应用安全更新和常规软件更新至关重要。这涉及到配置管理工具的智能使用，下面将对此进行讨论。这还涉及了解何时需要升级。 + +#### 漏洞管理 + +有关安全相关更改的公告，请订阅 OpenStack Announce 邮件列表。安全通知还会通过下游软件包发布，例如，通过您可能作为软件包更新的一部分订阅的 Linux 发行版。 + +OpenStack组件只是云中软件的一小部分。与所有这些其他组件保持同步也很重要。虽然某些数据源是特定于部署的，但云管理员必须订阅必要的邮件列表，以便接收适用于组织环境的任何安全更新的通知。通常，这就像跟踪上游 Linux 发行版一样简单。 + +**注意** + +```shell +OpenStack 通过两个渠道发布安全信息。 + +- OpenStack 安全公告 （OSSA） 由 OpenStack 漏洞管理团队 （VMT） 创建。它们与核心OpenStack服务中的安全漏洞有关。有关 VMT 的更多信息，请参阅漏洞管理流程。 +- OpenStack 安全说明 （OSSN） 由 OpenStack 安全组 （OSSG） 创建，以支持 VMT 的工作。OSSN解决了支持软件和常见部署配置中的问题。本指南中引用了它们。安全说明存档在OSSN上。 +``` + +##### 分类 + +收到安全更新通知后，下一步是确定此更新对给定云部署的重要性。在这种情况下，拥有预定义的策略很有用。现有的漏洞评级系统（如通用漏洞评分系统 （CVSS））无法正确考虑云部署。 + +在此示例中，我们引入了一个评分矩阵，该矩阵将漏洞分为三类：权限提升、拒绝服务和信息泄露。了解漏洞的类型及其在基础架构中发生的位置将使您能够做出合理的响应决策。 + +权限提升描述了用户使用系统中其他用户的权限进行操作的能力，绕过适当的授权检查。来宾用户执行的操作允许他们以管理员权限执行未经授权的操作，这是此类漏洞的一个示例。 + +拒绝服务是指被利用的漏洞，可能导致服务或系统中断。这既包括使网络资源不堪重负的分布式攻击，也包括通常由资源分配错误或输入引起的系统故障缺陷引起的单用户攻击。 + +信息泄露漏洞会泄露有关您的系统或操作的信息。这些漏洞的范围从调试信息泄露到关键安全数据（如身份验证凭据和密码）的暴露。 + +| | 攻击者位置/权限级别 | | | | +| -------------------- | ------------------- | ------- | -------- | -------- | +| | 外部 | 云用户 | 云管理员 | 控制平面 | +| 权限提升（3 级） | 紧急 | n/a | n/a | n/a | +| 权限提升（2 个级别） | 紧急 | 紧急 | n/a | n/a | +| 特权提升（1 级） | 紧急 | 紧急 | 紧急 | n/a | +| 拒绝服务 | 高 | 中 | 低 | 低 | +| 信息披露 | 紧急/高 | 紧急/高 | 中/低 | 低 | + +该表说明了一种通用方法，该方法根据漏洞在部署中发生的位置和影响来衡量漏洞的影响。例如，计算 API 节点上的单级权限提升可能允许 API 的标准用户升级为具有与节点上的 root 用户相同的权限。 + +我们建议云管理员使用此表作为模型，以帮助定义要针对各种安全级别执行的操作。例如，关键级别的安全更新可能需要快速升级云，而低级别的更新可能需要更长的时间才能完成。 + +##### 测试更新 + +在生产环境中部署任何更新之前，应对其进行测试。通常，这需要有一个单独的测试云设置，该设置首先接收更新。在软件和硬件方面，此云应尽可能接近生产云。应在性能影响、稳定性、应用程序影响等方面对更新进行全面测试。特别重要的是验证更新理论上解决的问题（例如特定漏洞）是否已实际修复。 + +##### 部署更新 + +完全测试更新后，可以将其部署到生产环境。应使用下面所述的配置管理工具完全自动化此部署。 + +#### 配置管理 + +生产质量的云应始终使用工具来自动执行配置和部署。这消除了人为错误，并允许云更快地扩展。自动化还有助于持续集成和测试。 + +在构建 OpenStack 云时，强烈建议在设计和实现时考虑配置管理工具或框架。通过配置管理，您可以避免在构建、管理和维护像 OpenStack 这样复杂的基础架构时固有的许多陷阱。通过生成配置管理实用程序所需的清单、说明书或模板，您可以满足许多文档和法规报告要求。此外，配置管理还可以作为业务连续性计划 （BCP） 和数据恢复 （DR） 计划的一部分，您可以在其中将节点或服务重建回 DR 事件中的已知状态或给定的妥协状态。 + +此外，当与 Git 或 SVN 等版本控制系统结合使用时，您可以跟踪环境随时间推移而发生的更改，并重新调解可能发生的未经授权的更改。例如，文件 `nova.conf` 或其他配置文件不符合您的标准，您的配置管理工具可以还原或替换该文件，并将您的配置恢复到已知状态。最后，配置管理工具也可用于部署更新;简化安全补丁流程。这些工具具有广泛的功能，在该领域非常有用。保护云的关键点是选择一种配置管理工具并使用它。 + +有许多配置管理解决方案;在撰写本文时，市场上有两个在支持 OpenStack 环境方面非常强大的公司：Chef 和 Puppet。下面提供了此空间中的工具的非详尽列表： + +- Chef +- Puppet +- Salt Stack +- Ansible + +##### 策略更改 + +每当更改策略或配置管理时，最好记录活动并备份新集的副本。通常，此类策略和配置存储在受版本控制的存储库（如 Git）中。 + +#### 安全备份和恢复 + +在整个系统安全计划中包括备份过程和策略非常重要。有关 OpenStack 备份和恢复功能和过程的概述，请参阅有关备份和恢复的 OpenStack 操作指南。 + +- 确保只有经过身份验证的用户和备份客户端才能访问备份服务器。 +- 使用数据加密选项来存储和传输备份。 +- 使用专用且强化的备份服务器。备份服务器的日志必须每天进行监视，并且只有少数人可以访问。 +- 定期测试数据恢复选项，包括存储在安全备份中的镜像，是确保灾难恢复准备的关键部分。在发生安全漏洞或受损时，终止运行中的实例并从已知的安全镜像备份中重新启动实例确实是最佳做法。这有助于确保受损的实例被消除，并且可以迅速从备份的镜像中重新部署干净、可信赖的版本。 + +#### 安全审计工具 + +安全审核工具可以补充配置管理工具。安全审核工具可自动执行验证给定系统配置是否满足大量安全控制的过程。这些工具有助于弥合从安全配置指南文档（例如，STIG 和 NSA 指南）到特定系统安装的差距。例如，SCAP 可以将正在运行的系统与预定义的配置文件进行比较。SCAP 输出一份报告，详细说明配置文件中的哪些控件已满足，哪些控件未通过，哪些控件未选中。 + +将配置管理和安全审计工具相结合，形成了一个强大的组合。审核工具将突出显示部署问题。配置管理工具简化了更改每个系统的过程，以解决审计问题。以这种方式一起使用，这些工具有助于维护满足从基本强化到合规性验证等安全要求的云环境。 + +配置管理和安全审计工具将给云带来另一层复杂性。这种复杂性带来了额外的安全问题。考虑到其安全优势，我们认为这是一种可接受的风险权衡。对于这些工具的操作安全性保障超出了本指南的范围。 + +### 完整性生命周期 + +我们将完整性生命周期定义为一个深思熟虑的过程，它确保我们始终在整个云中以预期的配置运行预期的软件。此过程从安全引导开始，并通过配置管理和安全监控进行维护。本章就如何处理完整性生命周期过程提供了建议。 + +#### 安全引导 + +云中的节点，包括计算、存储、网络、服务和混合节点，应该有一个自动化的配置过程。这确保了节点的一致和正确配置。这也便于安全补丁、升级、故障修复和其他关键变更。由于这个过程安装了在云中具有最高特权级别的新软件，因此验证安装正确的软件非常重要，包括启动过程的最早阶段。 + +有多种技术可以验证这些早期启动阶段。这些通常需要硬件支持，例如可信平台模块 （TPM）、英特尔可信执行技术 （TXT）、动态信任根测量 （DRTM） 和统一可扩展固件接口 （UEFI） 安全启动。在本书中，我们将所有这些统称为安全启动技术。我们建议使用安全启动，同时承认部署此启动所需的许多部分需要高级技术技能才能为每个环境自定义工具。与本指南中的许多其他建议相比，使用安全启动需要更深入的集成和自定义。TPM 技术虽然在大多数商务级笔记本电脑和台式机中很常见数年，但现在已与支持的 BIOS 一起在服务器中可用。正确的规划对于成功的安全启动部署至关重要。 + +有关安全启动部署的完整教程超出了本书的范围。相反，我们在这里提供了一个框架，用于将安全启动技术与典型的节点预配过程集成。有关更多详细信息，云架构师应参考相关规范和软件配置手册。 + +##### 节点配置 + +节点应使用预引导执行环境（PXE）进行配置。这大大减少了重新部署节点所需的工作量。典型的过程涉及节点从服务器接收各种引导阶段（即执行的软件逐渐复杂）。 + +![../_images/node-provisioning-pxe.png](https://docs.openstack.org/security-guide/_images/node-provisioning-pxe.png) + +我们建议在管理安全域中使用单独的隔离网络进行置备。此网络将处理所有 PXE 流量，以及上面描述的后续启动阶段下载。请注意，节点引导过程从两个不安全的操作开始：DHCP 和 TFTP。然后，引导过程使用 TLS 下载部署节点所需的其余信息。这可能是操作系统安装程序、由 Chef 或 Puppet 管理的基本安装，甚至是直接写入磁盘的完整文件系统映像。 + +虽然在 PXE 启动过程中使用 TLS 更具挑战性，但常见的 PXE 固件项目（如 iPXE）提供了这种支持。通常，这涉及在了解允许的 TLS 证书链的情况下构建 PXE 固件，以便它可以正确验证服务器证书。这通过限制不安全的纯文本网络操作的数量来提高攻击者的门槛。 + +##### 验证启动 + +通常，有两种不同的策略来验证启动过程。传统的安全启动将验证在过程中的每个步骤运行的代码，并在代码不正确时停止启动。启动证明将记录在每个步骤中运行的代码，并将此信息提供给另一台计算机，以证明启动过程按预期完成。在这两种情况下，第一步都是在运行之前测量每段代码。在这种情况下，测量实际上是代码的 SHA-1 哈希值，在执行之前获取。哈希存储在 TPM 的平台配置寄存器 （PCR） 中。 + +**注意** + +```shell +此处使用 SHA-1，因为这是 TPM 芯片支持的内容。 +``` + +每个 TPM 至少有 24 个 PCR。2005 年 3 月的 TCG 通用服务器规范 v1.0 定义了启动时完整性测量的 PCR 分配。下表显示了典型的PCR配置。上下文指示这些值是根据节点硬件（固件）还是根据节点上置备的软件确定的。某些值受固件版本、磁盘大小和其他低级信息的影响。因此，在配置管理方面采取良好的做法非常重要，以确保部署的每个系统都完全按照预期进行配置。 + +| 注册 | 测量内容 | 上下文 | +| ---------------- | ------------------------------------------------- | ------ | +| PCR-00 | 核心信任根测量 （CRTM）、BIOS 代码、主机平台扩展 | 硬件 | +| PCR-01 | 主机平台配置 | 硬件 | +| PCR-02 | 选项 ROM 代码 | 硬件 | +| PCR-03 | 选项 ROM 配置和数据 | 硬件 | +| PCR-04 | 初始程序加载程序 （IPL） 代码。例如，主引导记录。 | 软件 | +| PCR-05 | IPL 代码配置和数据 | 软件 | +| PCR-06 | 状态转换和唤醒事件 | 软件 | +| PCR-07 | 主机平台制造商控制 | 软件 | +| PCR-08 | 特定于平台，通常是内核、内核扩展和驱动程序 | 软件 | +| PCR-09 | 特定于平台，通常是 Initramfs | 软件 | +| PCR-10 至 PCR-23 | 特定于平台 | 软件 | + +安全启动可能是构建云的一个选项，但需要在硬件选择方面进行仔细规划。例如，确保您具有 TPM 和英特尔 TXT 支持。然后验证节点硬件供应商如何填充 PCR 值。例如，哪些值可用于验证。通常，上表中软件上下文下列出的 PCR 值是云架构师可以直接控制的值。但即使这些也可能随着云中软件的升级而改变。配置管理应链接到 PCR 策略引擎，以确保验证始终是最新的。 + +每个制造商都必须为其服务器提供 BIOS 和固件代码。不同的服务器、虚拟机监控程序和操作系统将选择填充不同的 PCR。在大多数实际部署中，不可能根据已知的良好数量（“黄金测量”）验证每个PCR。经验表明，即使在单个供应商的产品线中，给定PCR的测量过程也可能不一致。建议为每个服务器建立基线，并监视 PCR 值以查找意外更改。第三方软件可能可用于协助 TPM 预配和监视过程，具体取决于所选的虚拟机监控程序解决方案。 + +初始程序加载程序 （IPL） 代码很可能是 PXE 固件，假设采用上述节点部署策略。因此，安全启动或启动证明过程可以测量所有早期启动代码，例如 BIOS、固件、PXE 固件和内核映像。确保每个节点都安装了这些部件的正确版本，为构建节点软件堆栈的其余部分奠定了坚实的基础。 + +根据所选的策略，在发生故障时，节点将无法启动，或者它可以将故障报告给云中的另一个实体。为了实现安全引导，节点将无法引导，管理安全域中的置备服务必须识别这一点并记录事件。对于启动证明，当检测到故障时，节点将已经在运行。在这种情况下，应通过禁用节点的网络访问来立即隔离节点。然后，应分析事件的根本原因。无论哪种情况，策略都应规定在失败后如何继续。云可能会自动尝试重新配置节点一定次数。或者，它可能会立即通知云管理员调查问题。此处的正确策略是特定于部署和故障模式的。 + +##### 节点加固 + +此时，我们知道节点已使用正确的内核和底层组件启动。下一步是强化操作系统，它从一组行业公认的强化控件开始。以下指南是很好的示例： + +安全技术实施指南 （STIG） + +国防信息系统局 （DISA）（隶属于美国国防部）发布适用于各种操作系统、应用程序和硬件的 STIG 内容。这些控件在未附加任何许可证的情况下发布。 + +互联网安全中心 （CIS） 基准测试 + +CIS 会定期发布安全基准以及自动应用这些安全控制的自动化工具。这些基准测试是在具有一些限制的知识共享许可下发布的。 + +这些安全控制最好通过自动化方法应用。自动化确保每次对每个系统都以相同的方式应用控制，并且它们还提供了一种用于审核现有系统的快速方法。自动化有多种选择： + +OpenSCAP + +OpenSCAP 是一个开源工具，它采用 SCAP 内容（描述安全控制的 XML 文件）并将该内容应用于各种系统。目前可用的大多数内容都适用于 Red Hat Enterprise Linux 和 CentOS，但这些工具适用于任何 Linux 或 Windows 系统。 + +ansible 加固 + +ansible-hardening 项目提供了一个 Ansible 角色，可将安全控制应用于各种 Linux 操作系统。它还可用于审核现有系统。仔细检查每个控制措施，以确定它是否可能对生产系统造成损害。这些控件基于 Red Hat Enterprise Linux 7 STIG。 + +完全加固的系统是一个具有挑战性的过程，可能需要对某些系统进行大量更改。其中一些更改可能会影响生产工作负载。如果系统无法完全加固，强烈建议进行以下两项更改，以便在不造成重大中断的情况下提高安全性： + +###### 强制访问控制 （MAC） + +强制访问控制会影响系统上的所有用户，包括 root，内核的工作是根据当前安全策略审查活动。如果活动不在允许的策略范围内，则会被阻止，即使对于 root 用户也是如此。有关更多详细信息，请查看下面关于 sVirt、SELinux 和 AppArmor 的讨论。 + +###### 删除软件包并停止服务 + +确保系统安装的软件包数量尽可能少，并且运行的服务数量尽可能少。删除不需要的软件包可以更轻松地进行修补，并减少系统上可能导致违规的项目数量。停止不需要的服务会缩小系统上的攻击面，并使攻击更加困难。 + +我们还建议对生产节点执行以下附加步骤： + +###### 只读文件系统 + +尽可能使用只读文件系统。确保可写文件系统不允许执行。这可以使用 `noexec` 中的 、 `nosuid` 和 `nodev` 挂载选项来处理 `/etc/fstab` 。 + +###### 系统验证 + +最后，节点内核应该有一种机制来验证节点的其余部分是否以已知的良好状态启动。这提供了从引导验证过程到验证整个系统的必要链接。执行此操作的步骤将特定于部署。例如，内核模块可以在使用 dm-verity 挂载文件系统之前验证组成文件系统的块的哈希值。 + +#### 运行时验证 + +一旦节点运行，我们需要确保它随着时间的推移保持良好的状态。从广义上讲，这包括配置管理和安全监控。这些领域中每个领域的目标都不同。通过检查这两者，我们可以更好地确保系统按预期运行。我们将在管理部分讨论配置管理，并在下面讨论安全监控。 + +##### 入侵检测系统 + +基于主机的入侵检测工具对于自动验证云内部也很有用。有各种各样的基于主机的入侵检测工具可用。有些是免费提供的开源项目，而另一些则是商业项目。通常，这些工具会分析来自各种来源的数据，并根据规则集和/或训练生成安全警报。典型功能包括日志分析、文件完整性检查、策略监控和 rootkit 检测。更高级（通常是自定义）工具可以验证内存中进程映像是否与磁盘上的可执行文件匹配，并验证正在运行的进程的执行状态。 + +对于云架构师来说，一个关键的策略决策是如何处理安全监控工具的输出。实际上有两种选择。首先是提醒人类进行调查和/或采取纠正措施。这可以通过在云管理员的日志或事件源中包含安全警报来完成。第二种选择是让云自动采取某种形式的补救措施，以及记录事件。补救措施可能包括从重新安装节点到执行次要服务配置的任何内容。但是，由于可能存在误报，自动补救措施可能具有挑战性。 + +当安全监视工具为良性事件生成安全警报时，会发生误报。由于安全监控工具的性质，误报肯定会不时发生。通常，云管理员可以调整安全监控工具以减少误报，但这也可能同时降低整体检测率。在云中设置安全监控系统时，必须了解并考虑这些经典的权衡。 + +基于主机的入侵检测工具的选择和配置具有高度的部署特异性。我们建议从探索以下开源项目开始，这些项目实现了各种基于主机的入侵检测和文件监控功能。 + +- OSSEC +- Samhain +- Tripwire +- AIDE + +网络入侵检测工具是对基于主机的工具的补充。OpenStack 没有内置特定的网络 IDS，但 OpenStack Networking 提供了一种插件机制，可以通过 Networking API 启用不同的技术。此插件体系结构将允许租户开发 API 扩展，以插入和配置自己的高级网络服务，例如防火墙、入侵检测系统或虚拟机之间的 VPN。 + +与基于主机的工具类似，基于网络的入侵检测工具的选择和配置是特定于部署的。Snort 是领先的开源网络入侵检测工具，也是了解更多信息的良好起点。 + +对于基于网络和主机的入侵检测系统，有一些重要的安全注意事项。 + +- 重要的是要考虑将网络 IDS 放置在云上（例如，将其添加到网络边界和/或敏感网络周围）。放置位置取决于您的网络环境，但请确保监控 IDS 可能对您的服务产生的影响，具体取决于您选择添加的位置。网络 IDS 通常无法检查加密流量（如 TLS）的内容。但是，网络 IDS 在识别网络上的异常未加密流量方面仍可能提供一些好处。 +- 在某些部署中，可能需要在安全域网桥上的敏感组件上添加基于主机的 IDS。基于主机的 IDS 可能会通过组件上遭到入侵或未经授权的进程来检测异常活动。IDS 应在管理网络上传输警报和日志信息。 + +#### 服务器加固 + +云环境中的服务器，包括 undercloud 和 overcloud 基础架构，应实施强化最佳实践。由于操作系统和服务器强化很常见，因此此处不涵盖适用的最佳实践，包括但不限于日志记录、用户帐户限制和定期更新，但应应用于所有基础结构。 + +##### 文件完整性管理（FIM） + +文件完整性管理 （FIM） 是确保敏感系统或应用程序配置文件等文件不会损坏或更改以允许未经授权的访问或恶意行为的方法。这可以通过实用程序（如 Samhain）来完成，该实用程序将创建指定资源的校验和哈希，然后定期验证该哈希，或者通过 DMVerity 等工具来完成，该工具可以获取块设备的哈希值，并在系统访问这些哈希值时对其进行验证，然后再将其呈现给用户。 + +这些应该放在适当的位置，以监控和报告对系统、虚拟机管理程序和应用程序配置文件（如 和 `/etc/keystone/keystone.conf` ）以及内核模块（如 `/etc/pam.d/system-auth` virtio）的更改。最佳做法是使用 lsmod 命令来显示系统上定期加载的内容，以帮助确定 FIM 检查中应包含或不应包含的内容。 + +### 管理界面 + +管理员需要对云执行命令和控制，以实现各种操作功能。理解和保护这些指挥和控制设施非常重要。 + +OpenStack 为运维人员和租户提供了多种管理界面： + +- OpenStack 仪表板 （horizon） +- OpenStack 接口 +- 安全外壳 （SSH） +- OpenStack 管理实用程序，例如 nova-manage 和 glance-manage +- 带外管理接口，如 IPMI + +#### 仪表板 + +OpenStack 仪表板 （horizon） 为管理员和租户提供了一个基于 Web 的图形界面，用于置备和访问基于云的资源。仪表板通过调用 OpenStack API 与后端服务进行通信。 + +##### 功能 + +- 作为云管理员，仪表板提供云大小和状态的整体视图。您可以创建用户和租户/项目，将用户分配给租户/项目，并对可供他们使用的资源设置限制。 +- 仪表板为租户用户提供了一个自助服务门户，用于在管理员设置的限制范围内预配自己的资源。 +- 仪表板为路由器和负载平衡器提供 GUI 支持。例如，仪表板现在实现了所有主要的网络功能。 +- 它是一个可扩展的 Django Web 应用程序，允许轻松插入第三方产品和服务，例如计费、监控和其他管理工具。 +- 仪表板还可以为服务提供商和其他商业供应商打造品牌。 + +##### 安全注意事项 + +- 仪表板要求在 Web 浏览器中启用 Cookie 和 JavaScript。 +- 托管仪表板的 Web 服务器应配置为使用 TLS，以确保数据已加密。 +- Horizon Web Service 及其用于与后端通信的 OpenStack API 都容易受到 Web 攻击媒介（如拒绝服务）的攻击，因此必须对其进行监控。 +- 现在可以通过仪表板将镜像文件直接从用户的硬盘上传到 OpenStack 镜像服务（尽管存在许多部署/安全隐患）。对于多 GB 的映像，仍强烈建议使用 `glance` CLI 进行上传。 +- 通过仪表盘创建和管理安全组。安全组允许对安全策略进行 L3-L4 数据包筛选，以保护虚拟机。 + +##### 参考书目 + +OpenStack.org，ReleaseNotes/Liberty。2015. OpenStack Liberty 发行说明 + +#### OpenStack 接口 + +OpenStack API 是一个 RESTful Web 服务端点，用于访问、配置和自动化基于云的资源。操作员和用户通常通过命令行实用程序（例如， `nova` 或）、特定于语言的库或 `glance` 第三方工具访问 API。 + +##### 功能 + +- To the cloud administrator, the API provides an overall view of the size and state of the cloud deployment and allows the creation of users, tenants/projects, assigning users to tenants/projects, and specifying resource quotas on a per tenant/project basis. + 对于云管理员来说，API 提供了云部署大小和状态的整体视图，并允许创建用户、租户/项目、将用户分配给租户/项目，以及为每个租户/项目指定资源配额。 +- The API provides a tenant interface for provisioning, managing, and accessing their resources. + API 提供了一个租户接口，用于预配、管理和访问其资源。 + +##### 安全注意事项 + +- 应为 TLS 配置 API 服务，以确保数据已加密。 +- 作为 Web 服务，OpenStack API 容易受到熟悉的网站攻击媒介的影响，例如拒绝服务攻击。 + +#### 安全外壳 （SSH） + +使用安全外壳 （SSH） 访问来管理 Linux 和 Unix 系统已成为行业惯例。SSH 使用安全的加密原语进行通信。鉴于 SSH 在典型 OpenStack 部署中的范围和重要性，了解部署 SSH 的最佳实践非常重要。 + +##### 主机密钥指纹 + +经常被忽视的是 SSH 主机的密钥管理需求。由于 OpenStack 部署中的大多数或所有主机都将提供 SSH 服务，因此对与这些主机的连接充满信心非常重要。不能低估的是，未能提供合理安全且可访问的方法来验证 SSH 主机密钥指纹是滥用和利用的成熟时机。 + +所有 SSH 守护程序都具有专用主机密钥，并在连接时提供主机密钥指纹。此主机密钥指纹是未签名公钥的哈希值。在与这些主机建立 SSH 连接之前，必须知道这些主机密钥指纹。验证主机密钥指纹有助于检测中间人攻击。 + +通常，在安装 SSH 守护程序时，将生成主机密钥。在主机密钥生成过程中，主机必须具有足够的熵。主机密钥生成期间的熵不足可能导致窃听 SSH 会话。 + +生成 SSH 主机密钥后，主机密钥指纹应存储在安全且可查询的位置。一个特别方便的解决方案是使用 RFC-4255 中定义的 SSHFP 资源记录的 DNS。为了安全起见，有必要部署 DNSSEC。 + +#### 管理实用程序 + +OpenStack Management Utilities 是进行 API 调用的开源 Python 命令行客户端。每个 OpenStack 服务都有一个客户端（例如，nova、glance）。除了标准的 CLI 客户端之外，大多数服务都具有管理命令行实用程序，用于直接调用数据库。这些专用管理实用程序正在慢慢被弃用。 + +##### 安全注意事项 + +- 在某些情况下，专用管理实用程序 （*-manage） 使用直接数据库连接。 +- 确保包含凭据信息的 .rc 文件是安全的。 + +##### 参考书目 + +OpenStack.org，“OpenStack 最终用户指南”部分。2016. OpenStack 命令行客户端概述。 + +OpenStack.org，使用 OpenStack RC 文件设置环境变量。2016. 下载并获取 OpenStack RC 文件。 + +#### 带外管理接口 + +OpenStack 管理依赖于带外管理接口（如 IPMI 协议）来访问运行 OpenStack 组件的节点。IPMI 是一种非常流行的规范，用于远程管理、诊断和重新启动服务器，无论操作系统正在运行还是系统崩溃。 + +##### 安全注意事项 + +- 使用强密码并保护它们，或使用客户端 TLS 身份验证。 +- 确保网络接口位于其自己的专用（管理或单独的）网络上。使用防火墙或其他网络设备隔离管理域。 +- 如果您使用 Web 界面与 BMC/IPMI 交互，请始终使用 TLS 接口，例如 HTTPS 或端口 443。此 TLS 接口不应使用自签名证书（通常是默认的），但应具有使用正确定义的完全限定域名 （FQDN） 的受信任证书。 +- 监控管理网络上的流量。与繁忙的计算节点相比，异常可能更容易跟踪。 + +带外管理界面通常还包括图形计算机控制台访问。这些接口通常可以加密，但不一定是默认的。请参阅系统软件文档以加密这些接口。 + +##### 参考书目 + +SANS 技术研究所，InfoSec Handlers 日记博客。2012. 黑客攻击已关闭的服务器。 + +## 安全通信 + +设备间通信是一个严重的安全问题。在大型项目错误（如 Heartbleed）或更高级的攻击（如 BEAST 和 CRIME）之间，通过网络进行安全通信的方法变得越来越重要。但是，应该记住，加密应该作为更大的安全策略的一部分来应用。端点的入侵意味着攻击者不再需要破坏所使用的加密，而是能够在系统处理消息时查看和操纵消息。 + +本章将回顾有关配置 TLS 以保护内部和外部资源的几个功能，并指出应特别注意的特定类别的系统。 + +- TLS 和 SSL 简介 + + - 证书颁发机构 + - TLS 库 + - 加密算法、密码模式和协议 + - 总结 + +- TLS 代理和 HTTP 服务 + + - 例子 + - HTTP 严格传输安全性 + - 完美前向保密 + +- 安全参考架构 + + - SSL/TLS 代理在前面 + - SSL/TLS 与 API 端点位于同一物理主机上 + - 负载均衡器上的 SSL/TLS + - 外部和内部环境的加密分离 + +### TLS 和 SSL 简介 + +在某些情况下，需要安全来确保 OpenStack 部署中网络流量的机密性或完整性。这通常是使用加密措施实现的，例如传输层安全性 （TLS） 协议。 + +在典型部署中，通过公共网络传输的所有流量都是安全的，但安全最佳实践要求内部流量也必须得到保护。仅仅依靠安全域分离进行保护是不够的。如果攻击者获得对虚拟机监控程序或主机资源的访问权限，破坏 API 端点或任何其他服务，则他们一定无法轻松注入或捕获消息、命令或以其他方式影响云的管理功能。 + +所有域都应使用 TLS 进行保护，包括管理域服务和服务内通信。TLS 提供了确保用户与 OpenStack 服务之间以及 OpenStack 服务本身之间通信的身份验证、不可否认性、机密性和完整性的机制。 + +由于安全套接字层 （SSL） 协议中已发布的漏洞，我们强烈建议优先使用 TLS 而不是 SSL，并且在任何情况下都禁用 SSL，除非需要与过时的浏览器或库兼容。 + +公钥基础设施 （PKI） 是用于保护网络通信的框架。它由一组系统和流程组成，以确保在验证各方身份的同时可以安全地发送流量。此处描述的 PKI 配置文件是由 PKIX 工作组开发的 Internet 工程任务组 （IETF） 公钥基础结构 （PKIX） 配置文件。PKI的核心组件包括： + +**数字证书** + +签名公钥证书是具有实体的可验证数据、其公钥以及其他一些属性的数据结构。这些证书由证书颁发机构 （CA） 颁发。由于证书由受信任的 CA 签名，因此一旦验证，与实体关联的公钥将保证与所述实体相关联。用于定义这些证书的最常见标准是 X.509 标准。X.509 v3 是当前的标准，在 RFC5280 中进行了详细描述。证书由 CA 颁发，作为证明在线实体身份的机制。CA 通过从证书创建消息摘要并使用其私钥对摘要进行加密，对证书进行数字签名。 + + **结束实体** + +作为证书主题的用户、进程或系统。最终实体将其证书请求发送到注册机构 （RA） 进行审批。如果获得批准，RA 会将请求转发给证书颁发机构 （CA）。证书颁发机构验证请求，如果信息正确，则生成证书并签名。然后，此签名证书将发送到证书存储库。 + +**信赖方** + +接收数字签名证书的终结点，该证书可参考证书上列出的公钥进行验证。信赖方应能够验证证书的链上，确保它不存在于 CRL 中，并且还必须能够验证证书的到期日期。 + +**证书颁发机构 （CA）** + +CA 是受信任的实体，无论是最终方还是依赖证书进行证书策略、管理处理和证书颁发的一方。 + +**注册机构 （RA）** + +CA 将某些管理功能委派给的可选系统，这包括在 CA 颁发证书之前对终端实体进行身份验证等功能。 + +**证书吊销列表 （CRL）** + +证书吊销列表 （CRL） 是已吊销的证书序列号列表。在 PKI 模型中，不应信任提供这些证书的最终实体。吊销可能由于多种原因而发生，例如密钥泄露、CA 泄露。 + +**CRL 发行人** + +CA 将证书吊销列表的发布委托给的可选系统。 + +**证书存储库** + +存储和查找最终实体证书和证书吊销列表的位置 - 有时称为证书捆绑包。 + +PKI 构建了一个框架，用于提供加密算法、密码模式和协议，以保护数据和身份验证。强烈建议使用公钥基础结构 （PKI） 保护所有服务，包括对 API 终结点使用 TLS。仅靠传输或消息的加密或签名是不可能解决所有这些问题的。主机本身必须是安全的，并实施策略、命名空间和其他控制措施来保护其私有凭据和密钥。但是，密钥管理和保护的挑战并没有减少这些控制的必要性，也没有降低它们的重要性。 + +#### 证书颁发机构 + +许多组织都建立了公钥基础设施，其中包含自己的证书颁发机构 （CA）、证书策略和管理，他们应该使用这些证书为内部 OpenStack 用户或服务颁发证书。公共安全域面向 Internet 的组织还需要由广泛认可的公共 CA 签名的证书。对于通过管理网络进行的加密通信，建议不要使用公共 CA。相反，我们期望并建议大多数部署部署自己的内部 CA。 + +建议 OpenStack 云架构师考虑对内部系统和面向客户的服务使用单独的 PKI 部署。这使云部署人员能够保持对其 PKI 基础设施的控制，并且使内部系统的证书请求、签名和部署变得更加容易。高级配置可以对不同的安全域使用单独的 PKI 部署。这允许部署人员保持环境的加密隔离，确保颁发给一个环境的证书不被另一个环境识别。 + +用于在面向 Internet 的云端点（或客户接口，其中客户预计不会安装除标准操作系统提供的证书捆绑包以外的任何内容）上支持 TLS 的证书应使用安装在操作系统证书捆绑包中的证书颁发机构进行预配。典型的知名供应商包括 Let's Encrypt、Verisign 和 Thawte，但还有许多其他供应商。 + +在创建和签署证书方面存在管理、策略和技术方面的挑战。在这个领域，云架构师或操作员可能希望寻求行业领导者和供应商的建议，以及此处推荐的指导。 + +#### TLS 库 + +OpenStack 生态系统中的组件、服务和应用程序或 OpenStack 的依赖项已实现或可以配置为使用 TLS 库。OpenStack 中的 TLS 和 HTTP 服务通常使用 OpenSSL 实现，OpenSSL 具有已针对 FIPS 140-2 验证的模块。但是，请记住，每个应用程序或服务在使用 OpenSSL 库的方式上仍可能引入弱点。 + +#### 加密算法、密码模式和协议 + +建议至少使用 TLS 1.2。旧版本（如 TLS 1.0、1.1 和所有版本的 SSL（TLS 的前身）容易受到多种公开已知的攻击，因此不得使用。TLS 1.2 可用于广泛的客户端兼容性，但在启用此协议时要小心。仅当存在强制性兼容性要求并且您了解所涉及的风险时，才启用 TLS 版本 1.1。 + +使用 TLS 1.2 并同时控制客户端和服务器时，密码套件应限制为 `ECDHE-ECDSA-AES256-GCM-SHA384` .在不控制这两个终结点并使用 TLS 1.1 或 1.2 的情况下，更通用 `HIGH:!aNULL:!eNULL:!DES:!3DES:!SSLv3:!TLSv1:!CAMELLIA` 的是合理的密码选择。 + +但是，由于本书并不打算全面介绍密码学，因此我们不希望规定在OpenStack服务中应该启用或禁用哪些特定的算法或密码模式。我们想推荐一些权威的参考资料，以提供更多信息： + +- 国家安全局，Suite B 密码学 +- OWASP密码学指南 +- OWASP 传输层保护备忘单 +- SoK：SSL 和 HTTPS：重温过去的挑战并评估证书信任模型增强功能 +- 世界上最危险的代码：在非浏览器软件中验证SSL证书 +- OpenSSL 和 FIPS 140-2 + +#### 总结 + +鉴于 OpenStack 组件的复杂性和部署可能性的数量，您必须注意确保每个组件都获得 TLS 证书、密钥和 CA 的适当配置。后续部分将讨论以下服务： + +- 计算 API 端点 +- 身份 API 端点 +- 网络 API 端点 +- 存储 API 端点 +- 消息服务器 +- 数据库服务器 +- 仪表板 + +### TLS 代理和 HTTP 服务 + +OpenStack的终端是提供API给公共网络上的终端用户和管理网络上的其他OpenStack服务的HTTP服务。强烈建议所有这些请求，无论是内部还是外部，都使用TLS进行操作。为了实现这个目标，API服务必须部署在TLS代理后面，该代理能够建立和终止TLS会话。下表提供了可用于此目的的开源软件的非详尽列表： + +- Pound + +- Stud + +- Nginx + +- Apache httpd + +在软件终端性能不足的情况下，硬件加速器可能值得探索作为替代选项。请务必注意任何选定的 TLS 代理将处理的请求的大小。 + +#### 示例 + +下面我们提供了一些更流行的 Web 服务器/TLS 终结器中启用 TLS 的推荐配置设置示例。 + +在深入研究配置之前，我们简要讨论密码的配置元素及其格式。有关可用密码和 OpenSSL 密码列表格式的更详尽处理，请参阅：密码。 + +```shell +ciphers = "HIGH:!RC4:!MD5:!aNULL:!eNULL:!EXP:!LOW:!MEDIUM" +``` + +或 + +```shell +ciphers = "kEECDH:kEDH:kRSA:HIGH:!RC4:!MD5:!aNULL:!eNULL:!EXP:!LOW:!MEDIUM" +``` + +密码字符串选项由 “：” 分隔，而 “！” 提供紧接着的元素的否定。元素顺序指示首选项，除非被限定符（如 HIGH）覆盖。让我们仔细看看上面示例字符串中的元素。 + +**kEECDH:kEDH** + +临时椭圆曲线 Diffie-Hellman（缩写为 EECDH 和 ECDHE）。 + +Ephemeral Diffie-Hellman（缩写为 EDH 或 DHE）使用素数场群。 + +这两种方法都提供完全前向保密 （PFS）。有关正确配置 PFS 的更多讨论，请参阅完全前向保密。 + +临时椭圆曲线要求服务器配置命名曲线，并提供比主字段组更好的安全性和更低的计算成本。但是，主要字段组的实现范围更广，因此通常两者都包含在列表中。 + +**kRSA** + +分别使用 RSA 交换、身份验证或两者之一的密码套件。 + +**HIGH** + +在协商阶段选择可能的最高安全密码。这些密钥通常具有长度为 128 位或更长的密钥。 + +**!RC4** + +没有 RC4。RC4 在 TLS V3 的上下文中存在缺陷。请参阅 TLS 和 WPA 中 RC4 的安全性。 + +**!MD5** + +没有 MD5。MD5 不具有防冲突功能，因此不接受消息验证码 （MAC） 或签名。 + +**!aNULL:!eNULL** + +Disallows clear text. 不允许明文。 + +**!EXP** + +不允许导出加密算法，这些算法在设计上往往很弱，通常使用 40 位和 56 位密钥。 + +美国对密码学系统的出口限制已被取消，不再需要支持。 + +**!LOW:!MEDIUM** + +不允许使用低（56 或 64 位长密钥）和中等（128 位长密钥）密码，因为它们容易受到暴力攻击（示例 2-DES）。此规则仍允许三重数据加密标准 （Triple DES），也称为三重数据加密算法 （TDEA） 和高级加密标准 （AES），每个标准都具有大于等于 128 位的密钥，因此更安全。 + +**Protocols** + +协议通过SSL_CTX_set_options启用/禁用。建议禁用 SSLv2/v3 并启用 TLS。 + +##### Pound + +此 Pound 示例启用 `AES-NI` 加速，这有助于提高具有支持此功能的处理器的系统的性能。默认配置文件位于 `/etc/pound/pound.cfg` Ubuntu、RHEL、CentOS、 `/etc/pound.cfg` openSUSE 和 SUSE Linux Enterprise 上。 + +```shell +## see pound(8) for details +daemon 1 +###################################################################### +## global options: +User "swift" +Group "swift" +#RootJail "/chroot/pound" +## Logging: (goes to syslog by default) +## 0 no logging +## 1 normal +## 2 extended +## 3 Apache-style (common log format) +LogLevel 0 +## turn on dynamic scaling (off by default) +# Dyn Scale 1 +## check backend every X secs: +Alive 30 +## client timeout +#Client 10 +## allow 10 second proxy connect time +ConnTO 10 +## use hardware-acceleration card supported by openssl(1): +SSLEngine "aesni" +# poundctl control socket +Control "/var/run/pound/poundctl.socket" +###################################################################### +## listen, redirect and ... to: +## redirect all swift requests on port 443 to local swift proxy +ListenHTTPS + Address 0.0.0.0 + Port 443 + Cert "/etc/pound/cert.pem" + ## Certs to accept from clients + ## CAlist "CA_file" + ## Certs to use for client verification + ## VerifyList "Verify_file" + ## Request client cert - don't verify + ## Ciphers "AES256-SHA" + ## allow PUT and DELETE also (by default only GET, POST and HEAD)?: + NoHTTPS11 0 + ## allow PUT and DELETE also (by default only GET, POST and HEAD)?: + xHTTP 1 + Service + BackEnd + Address 127.0.0.1 + Port 80 + End + End +End +``` + +##### Stud + +密码行可以根据您的需要进行调整，但这是一个合理的起点。默认配置文件位于目录中 `/etc/stud` 。但是，默认情况下不提供它。 + +```shell +# SSL x509 certificate file. +pem-file = " +# SSL protocol. +tls = on +ssl = off +# List of allowed SSL ciphers. +# OpenSSL's high-strength ciphers which require authentication +# NOTE: forbids clear text, use of RC4 or MD5 or LOW and MEDIUM strength ciphers +ciphers = "HIGH:!RC4:!MD5:!aNULL:!eNULL:!EXP:!LOW:!MEDIUM" +# Enforce server cipher list order +prefer-server-ciphers = on +# Number of worker processes +workers = 4 +# Listen backlog size +backlog = 1000 +# TCP socket keepalive interval in seconds +keepalive = 3600 +# Chroot directory +chroot = "" +# Set uid after binding a socket +user = "www-data" +# Set gid after binding a socket +group = "www-data" +# Quiet execution, report only error messages +quiet = off +# Use syslog for logging +syslog = on +# Syslog facility to use +syslog-facility = "daemon" +# Run as daemon +daemon = off +# Report client address using SENDPROXY protocol for haproxy +# Disabling this until we upgrade to HAProxy 1.5 +write-proxy = off +``` + +##### Nginx + +此 Nginx 示例需要 TLS v1.1 或 v1.2 才能获得最大的安全性。可以根据您的需要调整生产线 `ssl_ciphers` ，但这是一个合理的起点。缺省配置文件为 `/etc/nginx/nginx.conf` 。 + +```shell +server { + listen : ssl; + ssl_certificate ; + ssl_certificate_key ; + ssl_protocols TLSv1.1 TLSv1.2; + ssl_ciphers HIGH:!RC4:!MD5:!aNULL:!eNULL:!EXP:!LOW:!MEDIUM + ssl_session_tickets off; + + server_name _; + keepalive_timeout 5; + + location / { + + } +} +``` + +##### Apache + +默认配置文件位于 `/etc/apache2/apache2.conf` Ubuntu、RHEL 和 CentOS、 `/etc/httpd/conf/httpd.conf` `/etc/apache2/httpd.conf` openSUSE 和 SUSE Linux Enterprise 上。 + +```shell +:80> + ServerName + RedirectPermanent / https:/// + +:443> + ServerName + SSLEngine On + SSLProtocol +TLSv1 +TLSv1.1 +TLSv1.2 + SSLCipherSuite HIGH:!RC4:!MD5:!aNULL:!eNULL:!EXP:!LOW:!MEDIUM + SSLCertificateFile /path/.crt + SSLCACertificateFile /path/.crt + SSLCertificateKeyFile /path/.key + WSGIScriptAlias / + WSGIDaemonProcess horizon user= group= processes=3 threads=10 + Alias /static + > + # For http server 2.2 and earlier: + Order allow,deny + Allow from all + + # Or, in Apache http server 2.4 and later: + # Require all granted + + +``` + +Apache 中的计算 API SSL 端点，必须与简短的 WSGI 脚本配对。 + +```shell +:8447> + ServerName + SSLEngine On + SSLProtocol +TLSv1 +TLSv1.1 +TLSv1.2 + SSLCipherSuite HIGH:!RC4:!MD5:!aNULL:!eNULL:!EXP:!LOW:!MEDIUM + SSLCertificateFile /path/.crt + SSLCACertificateFile /path/.crt + SSLCertificateKeyFile /path/.key + SSLSessionTickets Off + WSGIScriptAlias / + WSGIDaemonProcess osapi user= group= processes=3 threads=10 + > + # For http server 2.2 and earlier: + Order allow,deny + Allow from all + + # Or, in Apache http server 2.4 and later: + # Require all granted + + +``` + +#### HTTP 严格传输安全 + +建议所有生产部署都使用 HTTP 严格传输安全性 （HSTS）。此标头可防止浏览器在建立单个安全连接后建立不安全的连接。如果您已将 HTTP 服务部署在公共域或不受信任的域上，则 HSTS 尤为重要。要启用 HSTS，请将 Web 服务器配置为发送包含所有请求的标头，如下所示： + +```shell +Strict-Transport-Security: max-age=31536000; includeSubDomains +``` + +在测试期间从 1 天的短暂停开始，并在测试表明您没有给用户带来问题后将其提高到一年。请注意，一旦此标头设置为较大的超时，它（根据设计）就很难禁用。 + +#### 完全前向保密 + +配置 TLS 服务器以实现完美的前向保密需要围绕密钥大小、会话 ID 和会话票证进行仔细规划。此外，对于多服务器部署，共享状态也是一个重要的考虑因素。上面的 Apache 和 Nginx 示例配置禁用了会话票证选项，以帮助缓解其中一些问题。实际部署可能希望启用此功能以提高性能。这可以安全地完成，但需要特别考虑密钥管理。此类配置超出了本指南的范围。我们建议阅读 ImperialViolet 的 How to botch TLS forward secrecy 作为理解问题空间的起点。 + +### 安全参考架构 + +建议在 TLS 代理和 HTTP 服务的公用网络和管理网络上使用 SSL/TLS。但是，如果实际在任何地方部署 SSL/TLS 太困难，我们建议您评估您的 OpenStack SSL/TLS 需求，并遵循此处讨论的架构之一。 + +在评估其 OpenStack SSL/TLS 需求时，应该做的第一件事是识别威胁。您可以将这些威胁分为外部攻击者和内部攻击者类别，但由于 OpenStack 的某些组件在公共和管理网络上运行，因此界限往往会变得模糊。 + +对于面向公众的服务，威胁非常简单。用户将使用其用户名和密码对 Horizon 和 Keystone 进行身份验证。用户还将使用其 keystone 令牌访问其他服务的 API 端点。如果此网络流量未加密，则攻击者可以使用中间人攻击截获密码和令牌。然后，攻击者可以使用这些有效凭据执行恶意操作。所有实际部署都应使用 SSL/TLS 来保护面向公众的服务。 + +对于部署在管理网络上的服务，由于安全域与网络安全的桥接，威胁并不那么明确。有权访问管理网络的管理员总是有可能决定执行恶意操作。在这种情况下，如果允许攻击者访问私钥，SSL/TLS 将无济于事。当然，并不是管理网络上的每个人都被允许访问私钥，因此使用 SSL/TLS 来保护自己免受内部攻击者的攻击仍然很有价值。即使允许访问您的管理网络的每个人都是 100% 受信任的，仍然存在未经授权的用户通过利用错误配置或软件漏洞访问您的内部网络的威胁。必须记住，用户在 OpenStack Compute 节点中的实例上运行自己的代码，这些节点部署在管理网络上。如果漏洞允许他们突破虚拟机管理程序，他们将可以访问您的管理网络。在管理网络上使用 SSL/TLS 可以最大程度地减少攻击者可能造成的损害。 + +#### SSL/TLS 代理在前面 + +人们普遍认为，最好尽早加密敏感数据，并尽可能晚地解密。尽管有这种最佳实践，但在OpenStack服务前面使用SSL / TLS代理并在之后使用清晰的通信似乎是很常见的，如下所示： + +![../_images/secure-arch-ref-1.png](https://docs.openstack.org/security-guide/_images/secure-arch-ref-1.png) + +如上图所示，使用 SSL/TLS 代理的一些问题： + +- OpenStack 服务中的原生 SSL/TLS 的性能/扩展性不如 SSL 代理（特别是对于像 Eventlet 这样的 Python 实现）。 +- OpenStack 服务中的原生 SSL/TLS 没有像更成熟的解决方案那样经过仔细审查/审计。 +- 本机 SSL/TLS 配置很困难（没有很好的文档记录、测试或跨服务保持一致）。 +- 权限分离（OpenStack 服务进程不应直接访问用于 SSL/TLS 的私钥）。 +- 流量检查需要负载均衡。 + +以上所有问题都是有道理的，但它们都不能阻止在管理网络上使用 SSL/TLS。让我们考虑下一个部署模型。 + +#### 与 API 端点位于同一物理主机上的 SSL/TLS + +![../_images/secure-arch-ref-2.png](https://docs.openstack.org/security-guide/_images/secure-arch-ref-2.png) + +这与前面的 SSL/TLS 代理非常相似，但 SSL/TLS 代理与 API 端点位于同一物理系统上。API 端点将配置为仅侦听本地网络接口。与 API 端点的所有远程通信都将通过 SSL/TLS 代理进行。通过此部署模型，我们将解决 SSL/TLS 代理中的许多要点：将使用性能良好的经过验证的 SSL 实现。所有服务都将使用相同的 SSL 代理软件，因此 API 端点的 SSL 配置将是一致的。OpenStack 服务进程将无法直接访问用于 SSL/TLS 的私钥，因为您将以不同的用户身份运行 SSL 代理，并使用权限限制访问（以及使用 SELinux 之类的额外强制访问控制）。理想情况下，我们会让 API 端点在 Unix 套接字上监听，这样我们就可以使用权限和强制访问控制来限制对它的访问。不幸的是，根据我们的测试，这在 Eventlet 中目前似乎不起作用。这是一个很好的未来发展目标。 + +#### SSL/TLS负载平衡器 + +需要检查流量的高可用性或负载均衡部署会怎样？以前的部署模型（与 API 端点位于同一物理主机上的 SSL/TLS）不允许进行深度数据包检测，因为流量是加密的。如果仅出于基本路由目的而需要检查流量，则负载均衡器可能没有必要访问未加密的流量。HAProxy 能够在握手期间提取 SSL/TLS 会话 ID，然后可以使用该 ID 来实现会话亲和性（会话 ID 配置详细信息 此处 ）。HAProxy还可以使用TLS服务器名称指示（SNI）扩展来确定应将流量路由到的位置（SNI配置详细信息请在此处）。这些功能可能涵盖了一些最常见的负载均衡器需求。在这种情况下，HAProxy 将能够将 HTTPS 流量直接传递到 API 端点系统： + +![../_images/secure-arch-ref-3.png](https://docs.openstack.org/security-guide/_images/secure-arch-ref-3.png) + +#### 外部和内部环境的加密分离 + +如果您希望对外部和内部环境进行加密分离，该怎么办？公有云提供商可能希望其面向公众的服务（或代理）使用由 CA 颁发的证书，该证书链接到受信任的根 CA，该根 CA 分布在流行的 SSL/TLS Web 浏览器软件中。对于内部服务，可能希望改用自己的 PKI 来颁发 SSL/TLS 证书。可以通过在网络边界终止 SSL，然后使用内部颁发的证书重新加密来实现这种加密分离。流量将在面向公众的 SSL/TLS 代理上短时间内未加密，但永远不会以明文形式通过网络传输。如果负载均衡器上确实需要深度数据包检测，也可以使用用于实现加密分离的相同重新加密方法。下面是此部署模型的样子：下面是此部署模型的外观: + +![../_images/secure-arch-ref-4.png](https://docs.openstack.org/security-guide/_images/secure-arch-ref-4.png) + +与大多数事情一样，需要权衡取舍。主要的权衡是在安全性和性能之间。加密是有代价的，但被黑客入侵也是有代价的。每个部署的安全性和性能要求都会有所不同，因此如何使用 SSL/TLS 最终将由个人决定。 + +## API 端点 + +使用 OpenStack 云的过程是通过查询 API 端点开始的。虽然公共和专用终结点面临不同的挑战，但这些是高价值资产，如果遭到入侵，可能会带来重大风险。 + +本章建议对面向公共和私有的 API 端点进行安全增强。 + +- API 端点配置建议 + + - 内部 API 通信 + - 粘贴件和中间件 + - API 端点进程隔离和策略 + - API 终端节点速率限制 + +### API 端点配置建议 + +#### 内部 API 通信 + +OpenStack 提供面向公众和私有的 API 端点。默认情况下，OpenStack 组件使用公开定义的端点。建议将这些组件配置为在适当的安全域中使用 API 端点。 + +服务根据 OpenStack 服务目录选择各自的 API 端点。这些服务可能不遵守列出的公共或内部 API 端点值。这可能会导致内部管理流量路由到外部 API 终结点。 + +##### 在身份服务目录中配置内部 URL + +Identity 服务目录应了解您的内部 URL。虽然默认情况下不使用此功能，但可以通过配置来利用它。此外，一旦此行为成为默认行为，它应该与预期的更改向前兼容。 + +要为终结点注册内部 URL，请执行以下操作： + +```shell +$ openstack endpoint create identity \ + --region RegionOne internal \ + https://MANAGEMENT_IP:5000/v3 +``` + +替换为 `MANAGEMENT_IP` 控制器节点的管理 IP 地址。 + +##### 为内部 URL 配置应用程序 + +您可以强制某些服务使用特定的 API 端点。因此，建议必须将每个与另一个服务的 API 通信的 OpenStack 服务显式配置为访问正确的内部 API 端点。 + +每个项目都可能呈现定义目标 API 端点的不一致方式。OpenStack 的未来版本试图通过一致地使用身份服务目录来解决这些不一致问题。 + +**配置示例 #1：nova** + +```shell +cinder_catalog_info='volume:cinder:internalURL' +glance_protocol='https' +neutron_url='https://neutron-host:9696' +neutron_admin_auth_url='https://neutron-host:9696' +s3_host='s3-host' +s3_use_ssl=True +``` + +**配置示例 #2：cinder** + +```shell +glance_host = 'https://glance-server' +``` + +#### 粘贴和中间件 + +OpenStack 中的大多数 API 端点和其他 HTTP 服务都使用 Python Paste Deploy 库。从安全角度来看，此库允许通过应用程序的配置来操作请求筛选器管道。此链中的每个元素都称为中间件。更改管道中筛选器的顺序或添加其他中间件可能会产生不可预知的安全影响。 + +通常，实现者会添加中间件来扩展 OpenStack 的基本功能。我们建议实现者仔细考虑将非标准软件组件添加到其 HTTP 请求管道中可能带来的风险。 + +有关粘贴部署的更多信息，请参阅 Python 粘贴部署文档。 + +#### API 端点进程隔离和策略 + +您应该隔离 API 端点进程，尤其是那些位于公共安全域中的进程，应尽可能隔离。在部署允许的情况下，API 端点应部署在单独的主机上，以增强隔离性。 + +##### 命名空间 + +现在，许多操作系统都提供分区化支持。Linux 支持命名空间将进程分配到独立的域中。本指南的其他部分更详细地介绍了系统区隔。 + +##### 网络策略 + +由于 API 端点通常桥接多个安全域，因此您必须特别注意 API 进程的划分。有关此区域的其他信息，请参阅桥接安全域。 + +通过仔细建模，您可以使用网络 ACL 和 IDS 技术在网络服务之间强制实施显式点对点通信。作为一项关键的跨域服务，这种显式强制执行对 OpenStack 的消息队列服务非常有效。 + +要实施策略，您可以配置服务、基于主机的防火墙（例如 iptables）、本地策略（SELinux 或 AppArmor）以及可选的全局网络策略。 + +##### 强制访问控制 + +您应该将 API 端点进程彼此隔离，并隔离计算机上的其他进程。这些进程的配置不仅应通过任意访问控制，还应通过强制访问控制来限制这些进程。这些增强的访问控制的目标是帮助遏制和升级 API 端点安全漏洞。通过强制访问控制，此类违规行为会严重限制对资源的访问，并针对此类事件提供早期警报。 + +#### API 端点速率限制 + +速率限制是一种控制基于网络的应用程序接收事件频率的方法。如果不存在可靠的速率限制，则可能导致应用程序容易受到各种拒绝服务攻击。对于 API 尤其如此，因为 API 的本质是旨在接受高频率的类似请求类型和操作。 + +在 OpenStack 中，建议通过速率限制代理或 Web 应用程序防火墙为所有端点（尤其是公共端点）提供额外的保护层。 + +在配置和实现任何速率限制功能时，运营商必须仔细规划并考虑其 OpenStack 云中用户和服务的个人性能需求，这一点至关重要。 + +提供速率限制的常见解决方案是 Nginx、HAProxy、OpenPose 或 Apache 模块，例如 mod_ratelimit、mod_qos 或 mod_security。 + +## 身份鉴别 + +Keystone身份服务为OpenStack系列服务专门提供身份、令牌、目录和策略服务。身份服务组织为一组内部服务，通过一个或多个端点暴露。这些服务中的许多是由前端以组合方式使用的。例如，身份验证调用通过身份服务验证用户和项目凭据。如果成功，它将使用令牌服务创建并返回令牌。更多信息可以在Keystone开发者文档中找到。 + +- 认证 + + - 无效的登录尝试 + - 多因素认证 + +- 认证方法 + + - 内部实施的认证方法 + - 外部认证方法 + +- 授权 + + - 建立正式的访问控制策略 + - 服务授权 + - 管理原用户 + - 终端用户 + +- 策略 +- 令牌 + + - Fernet 令牌 + - JWT 令牌 + +- 域 +- 联合 Keystone + + - 为什么要使用联合鉴别 + +- 检查表 + + - Check-Identity-01：配置文件的用户/组所有权是否设置为 keystone？ + - Check-Identity-02：是否为身份配置文件设置了严格权限 + - Check-Identity-03：是否为 Identity 启用了 TLS？ + - Check-Identity-04：（已过时） + - Check-Identity-05：是否 max_request_body_size 设置为默认值 （114688）？ + - check-identity-06:禁用/etc/keystone/keystone.conf中的管理令牌 + - check-identity-07:/etc/keystone/keystone.conf中的不安全_调试为假 + - check-identity-08:使用/etc/keystone/keystone.conf中的Fernet令牌 + +### 认证 + +身份认证是任何实际OpenStack部署中不可或缺的一部分，因此应该仔细考虑系统设计的这一方面。本主题的完整处理超出了本指南的范围，但是以下各节介绍了一些关键主题。 + +从根本上说，身份认证是确认身份的过程 - 用户实际上是他们声称的身份。一个熟悉的示例是在登录系统时提供用户名和密码。 + +OpenStack 身份鉴别服务（keystone）支持多种身份验证方法，包括用户名和密码、LDAP 和外部身份验证方法。身份认证成功后，身份鉴别服务会向用户提供用于后续服务请求的授权令牌。 + +传输层安全性 （TLS） 使用 X.509 证书在服务和人员之间提供身份验证。尽管 TLS 的默认模式是仅服务器端身份验证，但证书也可用于客户端身份验证。 + +#### 无效的登录尝试 + +从 Newton 版本开始，身份鉴别服务可以在多次登录尝试失败后限制对帐户的访问。重复失败登录尝试的模式通常是暴力攻击的指标（请参阅攻击类型）。这种类型的攻击在公有云部署中更为普遍。 + +对于需要此功能的旧部署，可以使用外部身份验证系统进行预防，该系统在配置的登录尝试失败次数后锁定帐户。然后，只有通过进一步的侧信道干预才能解锁该帐户。 + +如果无法预防，则可以使用检测来减轻损害。检测涉及频繁查看访问控制日志，以识别未经授权的帐户访问尝试。可能的补救措施包括检查用户密码的强度，或通过防火墙规则阻止攻击的网络源。Keystone 服务器上限制连接数的防火墙规则可用于降低攻击效率，从而劝阻攻击者。 + +此外，检查帐户活动是否存在异常登录时间和可疑操作，并采取纠正措施（如禁用帐户）也很有用。通常，信用卡提供商采用这种方法进行欺诈检测和警报。 + +#### 多因素身份验证 + +采用多重身份验证对特权用户帐户进行网络访问。身份鉴别服务通过可提供此功能的 Apache Web 服务器支持外部身份验证服务。服务器还可以使用证书强制执行客户端身份验证。 + +此建议可防止暴力破解、社会工程以及可能泄露管理员密码的狙击和大规模网络钓鱼攻击。 + +### 身份验证方法 + +#### 内部实现的认证方式 + +身份认证服务可以将用户凭据存储在 SQL 数据库中，也可以使用符合 LDAP 的目录服务器。身份数据库可以与其他 OpenStack 服务使用的数据库分开，以降低存储凭据泄露的风险。 + +当您使用用户名和密码进行身份验证时，身份服务不会强制执行 NIST Special Publication 800-118（草案）中推荐的有关密码强度、过期或失败身份验证尝试的策略。希望执行更严格密码策略的组织应考虑使用身份服务的扩展或外部认证服务。 + +LDAP 简化了身份认证与组织现有目录服务和用户帐户管理流程的集成。 + +OpenStack 中的身份验证和授权策略可以委托给其他服务。一个典型的用例是寻求部署私有云的组织，并且已经在 LDAP 系统中拥有员工和用户的数据库。使用此身份验证机构，将对身份服务的请求委托给 LDAP 系统，然后 LDAP 系统将根据其策略进行授权或拒绝。身份验证成功后，身份鉴别服务会生成一个令牌，用于访问授权服务。 + +请注意，如果 LDAP 系统具有为用户定义的属性，例如 admin、finance、HR 等，则必须将这些属性映射到身份鉴别中的角色和组，以供各种 OpenStack 服务使用。该文件 `/etc/keystone/keystone.conf` 将 LDAP 属性映射到身份属性。 + +不得允许身份服务写入用于 OpenStack 部署之外的身份验证的 LDAP 服务，因为这将允许具有足够权限的 keystone 用户对 LDAP 目录进行更改。这将允许在更广泛的组织内进行权限升级，或促进对其他信息和资源的未经授权的访问。在这样的部署中，用户配置将超出 OpenStack 部署的范围。 + +**注意** + +```shell +有一个关于 keystone.conf 权限的 OpenStack 安全说明 （OSSN）。 + +有一个关于潜在 DoS 攻击的 OpenStack 安全说明 （OSSN）。 +``` + +#### 外部认证方式 + +本组织可能希望实现外部身份验证，以便与现有身份验证服务兼容，或强制实施更强的身份验证策略要求。尽管密码是最常见的身份验证形式，但它们可以通过多种方法泄露，包括击键记录和密码泄露。外部身份验证服务可以提供替代形式的身份验证，以最大程度地降低弱密码带来的风险。 + + 这些包括： + +**密码策略实施** + +要求用户密码符合长度、字符多样性、过期或登录尝试失败的最低标准。在外部身份验证方案中，这将是原始身份存储上的密码策略。 + +**多因素身份验证** + +身份验证服务要求用户根据他们拥有的内容（如一次性密码令牌或 X.509 证书）和他们知道的内容（如密码）提供信息。 + +**Kerberos** + +一种使用“票证”进行双向认证的网络协议，用于保护客户端和服务器之间的通信。Kerberos 票证授予票证可安全地为特定服务提供票证。 + +### 授权 + +身份服务支持组和角色的概念。用户属于组，而组具有角色列表。OpenStack 服务引用尝试访问该服务的用户的角色。OpenStack 策略执行器中间件会考虑与每个资源关联的策略规则，然后考虑用户的组/角色和关联，以确定是否允许访问所请求的资源。 + +策略实施中间件支持对 OpenStack 资源进行细粒度的访问控制。策略中深入讨论了策略的行为。 + +#### 建立正式的访问控制策略 + +在配置角色、组和用户之前，请记录 OpenStack 安装所需的访问控制策略。这些策略应与组织的任何法规或法律要求保持一致。将来对访问控制配置的修改应与正式策略保持一致。策略应包括创建、删除、禁用和启用帐户以及为帐户分配权限的条件和过程。定期查看策略，并确保配置符合批准的策略。 + +#### 服务授权 + +云管理员必须为每个服务定义一个具有管理员角色的用户，如《OpenStack 管理员指南》中所述。此服务帐户为服务提供对用户进行身份验证的授权。 + +可以将计算和对象存储服务配置为使用身份服务来存储身份验证信息。存储身份验证信息的其他选项包括使用“tempAuth”文件，但不应将其部署在生产环境中，因为密码以纯文本形式显示。 + +身份鉴别服务支持对 TLS 进行客户端身份验证，该身份验证可能已启用。除了用户名和密码之外，TLS 客户端身份验证还提供了额外的身份验证因素，从而提高了用户标识的可靠性。当用户名和密码可能被泄露时，它降低了未经授权访问的风险。但是，向用户颁发证书会产生额外的管理开销和成本，这在每次部署中都可能不可行。 + +**注意** + +```shell +我们建议您将客户端身份验证与 TLS 结合使用，以便对身份鉴别服务进行身份验证。 +``` + +云管理员应保护敏感的配置文件免遭未经授权的修改。这可以通过强制性访问控制框架（如 SELinux）来实现，包括 `/etc/keystone/keystone.conf` X.509 证书。 + +使用 TLS 的客户端身份验证需要向服务颁发证书。这些证书可以由外部或内部证书颁发机构签名。默认情况下，OpenStack 服务会根据受信任的 CA 检查证书签名的有效性，如果签名无效或 CA 不可信，连接将失败。云部署人员可以使用自签名证书。在这种情况下，必须禁用有效性检查，或者应将证书标记为受信任。若要禁用自签名证书的验证，请在 `/etc/nova/api.paste.ini` 文件的 `[filter:authtoken]` “部分”中进行设置 `insecure=False` 。此设置还会禁用其他组件的证书。 + +#### 管理员用户 + +我们建议管理员用户使用身份服务和支持 2 因素身份验证的外部身份验证服务（例如证书）进行身份验证。这样可以降低密码可能被泄露的风险。此建议符合 NIST 800-53 IA-2（1） 指南，即使用多重身份验证对特权帐户进行网络访问。 + +#### 终端用户 + +身份鉴别服务可以直接提供最终用户身份验证，也可以配置为使用外部身份验证方法以符合组织的安全策略和要求。 + +### 政策 + +每个 OpenStack 服务都在关联的策略文件中定义其资源的访问策略。例如，资源可以是 API 访问、附加到卷或启动实例的能力。策略规则以 JSON 格式指定，文件称为 `policy.json` .此文件的语法和格式在配置参考中进行了讨论。 + +云管理员可以修改或更新这些策略，以控制对各种资源的访问。确保对访问控制策略的任何更改都不会无意中削弱任何资源的安全性。另请注意，对 `policy.json` 文件的更改会立即生效，并且不需要重新启动服务。 + +以下示例显示了该服务如何将创建、更新和删除资源的访问权限限制为仅具有角色 `cloud_admin` 的用户，该角色已定义为 `role = admin` 和 `domain_id = admin_domain_id` 的结合，而 get 和 list 资源可供角色为 `cloud_admin` 或 `admin` 的用户使用。 + +```shell +{ + "admin_required": "role:admin", + "cloud_admin": "rule:admin_required and domain_id:admin_domain_id", + "service_role": "role:service", + "service_or_admin": "rule:admin_required or rule:service_role", + "owner" : "user_id:%(user_id)s or user_id:%(target.token.user_id)s", + "admin_or_owner": "(rule:admin_required and domain_id:%(target.token.user.domain.id)s) or rule:owner", + "admin_or_cloud_admin": "rule:admin_required or rule:cloud_admin", + "admin_and_matching_domain_id": "rule:admin_required and domain_id:%(domain_id)s", + "service_admin_or_owner": "rule:service_or_admin or rule:owner", + + "default": "rule:admin_required", + + "identity:get_service": "rule:admin_or_cloud_admin", + "identity:list_services": "rule:admin_or_cloud_admin", + "identity:create_service": "rule:cloud_admin", + "identity:update_service": "rule:cloud_admin", + "identity:delete_service": "rule:cloud_admin", + + "identity:get_endpoint": "rule:admin_or_cloud_admin", + "identity:list_endpoints": "rule:admin_or_cloud_admin", + "identity:create_endpoint": "rule:cloud_admin", + "identity:update_endpoint": "rule:cloud_admin", + "identity:delete_endpoint": "rule:cloud_admin", + +} +``` + +### 令牌 + +用户通过身份验证后，将生成一个令牌，用于授权和访问 OpenStack 环境。代币可以具有可变的生命周期;但是，expiry 的默认值为 1 小时。建议的过期值应设置为较低的值，以便内部服务有足够的时间完成任务。如果令牌在任务完成之前过期，云可能会变得无响应或停止提供服务。例如，计算服务将磁盘映像传输到虚拟机监控程序以进行本地缓存所需的时间。允许在使用有效的服务令牌时提取过期的令牌。 + +令牌通常在 Identity 服务响应的较大上下文的结构中传递。这些响应还提供了各种 OpenStack 服务的目录。列出了每个服务的名称、内部访问、管理员访问和公共访问的访问终结点。 + +可以使用标识 API 吊销令牌。 + +在 Stein 版本中，有两种受支持的令牌类型：fernet 和 JWT。 + +fernet 和 JWT 令牌都不需要持久性。Keystone 令牌数据库不再因身份验证的副作用而遭受膨胀。过期令牌的修剪会自动进行。也不再需要跨多个节点进行复制。只要每个 keystone 节点共享相同的存储库，就可以在所有节点上立即创建和验证令牌。 + +#### Fernet 令牌 + +Fernet 令牌是 Stein 支持的令牌提供程序（默认）。Fernet 是一种安全的消息传递格式，专门设计用于 API 令牌。它们是轻量级的（范围在 180 到 240 字节之间），并减少了运行云所需的运营开销。身份验证和授权元数据被整齐地捆绑到消息打包的有效负载中，然后对其进行加密并作为 fernet 令牌登录。 + +#### JWT 令牌 + +JSON Web 签名 （JWS） 令牌是在 Stein 版本中引入的。与fernet相比，JWS通过限制需要共享对称加密密钥的主机数量，为运营商提供了潜在的好处。这有助于防止可能已在部署中站稳脚跟的恶意参与者扩散到其他节点。 + +有关这些令牌提供程序之间差异的更多详细信息，请参阅此处 + +### 域 + +域是项目、用户和组的高级容器。因此，它们可用于集中管理所有基于 keystone 的身份组件。随着帐户域的引入，服务器、存储和其他资源现在可以在逻辑上分组到多个项目（以前称为租户）中，这些项目本身可以分组到类似主帐户的容器下。此外，可以在一个帐户域中管理多个用户，并为每个项目分配不同的角色。 + +Identity V3 API 支持多个域。不同域的用户可能在不同的身份验证后端中表示，甚至具有不同的属性，这些属性必须映射到一组角色和权限，这些角色和权限在策略定义中用于访问各种服务资源。 + +如果规则可以仅指定对管理员用户和属于租户的用户的访问权限，则映射可能很简单。在其他情况下，云管理员可能需要批准每个租户的映射例程。 + +特定于域的身份验证驱动程序允许使用特定于域的配置文件为多个域配置标识服务。启用驱动程序并设置特定于域的配置文件位置发生在 `keystone.conf` 文件 `[identity]` 部分中： + +```shell +[identity] +domain_specific_drivers_enabled = True +domain_config_dir = /etc/keystone/domains +``` + +任何没有特定于域的配置文件的域都将使用主 `keystone.conf` 文件中的选项。 + +### 联合鉴权 + +重要定义： + +**服务提供商 （SP）** + +向委托人或其他系统实体提供服务的系统实体，在本例中，OpenStack Identity 是服务提供者。 + +**身份提供商 （IdP）** + +目录服务（如 LDAP、RADIUS 和 Active Directory）允许用户使用用户名和密码登录，是身份提供商处身份验证令牌（例如密码）的典型来源。 + +联合鉴权是一种在 IdP 和 SP 之间建立信任的机制，在本例中，是在身份提供者和 OpenStack Cloud 提供的服务之间建立信任。它提供了一种安全的方法，可以使用现有凭据跨多个端点访问云资源，例如服务器、卷和数据库。凭证由用户的 IdP 维护。 + +#### 为什么要使用联合身份？ + +两个根本原因： + +1. 降低复杂性使部署更易于保护。 +2. 它为您和您的用户节省了时间。 + +- 集中管理帐户，防止 OpenStack 基础架构内部的重复工作。 +- 减轻用户负担。单点登录允许使用单一身份验证方法来访问许多不同的服务和环境。 +- 将密码恢复过程的责任转移到 IdP。 + +进一步的理由和细节可以在 Keystone 关于联合的文档中找到。 + +### 检查表 + +#### Check-Identity-01：配置文件的用户/组所有权是否设置为 keystone？ + +配置文件包含组件平稳运行所需的关键参数和信息。如果非特权用户有意或无意地修改或删除任何参数或文件本身，则会导致严重的可用性问题，从而导致对其他最终用户的拒绝服务。因此，此类关键配置文件的用户和组所有权必须设置为该组件所有者。此外，包含目录应具有相同的所有权，以确保正确拥有新文件。 + +运行以下命令： + +```shell +$ stat -L -c "%U %G" /etc/keystone/keystone.conf | egrep "keystone keystone" +$ stat -L -c "%U %G" /etc/keystone/keystone-paste.ini | egrep "keystone keystone" +$ stat -L -c "%U %G" /etc/keystone/policy.json | egrep "keystone keystone" +$ stat -L -c "%U %G" /etc/keystone/logging.conf | egrep "keystone keystone" +$ stat -L -c "%U %G" /etc/keystone/ssl/certs/signing_cert.pem | egrep "keystone keystone" +$ stat -L -c "%U %G" /etc/keystone/ssl/private/signing_key.pem | egrep "keystone keystone" +$ stat -L -c "%U %G" /etc/keystone/ssl/certs/ca.pem | egrep "keystone keystone" +$ stat -L -c "%U %G" /etc/keystone | egrep "keystone keystone" +``` + +**通过：**如果所有这些配置文件的用户和组所有权都设置为 keystone。上述命令显示 keystone keystone 的输出。 + +**失败：**如果上述命令未返回任何输出，因为用户或组所有权可能已设置为除 keystone 以外的任何用户。 + +推荐于：内部实现的身份验证方法。 + +#### Check-Identity-02：是否为 Identity 配置文件设置了严格权限？ + +与前面的检查类似，建议对此类配置文件设置严格的访问权限。 + +运行以下命令： + +```shell +$ stat -L -c "%a" /etc/keystone/keystone.conf +$ stat -L -c "%a" /etc/keystone/keystone-paste.ini +$ stat -L -c "%a" /etc/keystone/policy.json +$ stat -L -c "%a" /etc/keystone/logging.conf +$ stat -L -c "%a" /etc/keystone/ssl/certs/signing_cert.pem +$ stat -L -c "%a" /etc/keystone/ssl/private/signing_key.pem +$ stat -L -c "%a" /etc/keystone/ssl/certs/ca.pem +$ stat -L -c "%a" /etc/keystone +``` + +还可以进行更广泛的限制：如果包含目录设置为 750，则保证此目录中新创建的文件具有所需的权限。 + +**通过：**如果权限设置为 640 或更严格，或者包含目录设置为 750。 + +**失败：**如果权限未设置为至少 640/750。 + +推荐于：内部实现的身份验证方法。 + +#### Check-Identity-03：是否为 Identity 启用了 TLS？ + +OpenStack 组件使用各种协议相互通信，通信可能涉及敏感或机密数据。攻击者可能会尝试窃听频道以访问敏感信息。因此，所有组件都必须使用安全通信协议（如 HTTPS）相互通信。 + +如果将 HTTP/WSGI 服务器用于标识，则应在 HTTP/WSGI 服务器上启用 TLS。 + +**通过：**如果在 HTTP 服务器上启用了 TLS。 + +**失败：**如果 HTTP 服务器上未启用 TLS。 + +推荐于：安全通信。 + +#### Check-Identity-04：（已过时） + +#### Check-Identity-05：是否 `max_request_body_size` 设置为默认值 （114688）？ + +该参数 `max_request_body_size` 定义每个请求的最大正文大小（以字节为单位）。如果未定义最大大小，攻击者可以构建任意大容量请求，导致服务崩溃，最终导致拒绝服务攻击。分配最大值可确保阻止任何恶意的超大请求，从而确保组件的持续可用性。 + +**通过：**如果参数 `max_request_body_size` in `/etc/keystone/keystone.conf` 的值设置为默认值 （114688） 或根据您的环境设置的某个合理值。 + +**失败：**如果未设置参数 `max_request_body_size` 值。 + +#### check-identity-06:禁用/etc/keystone/keystone.conf中的管理令牌 + +管理员令牌通常用于引导 Identity。此令牌是最有价值的标识资产，可用于获取云管理员权限。 + +**通过：**如果 `admin_token` under `[DEFAULT]` section in `/etc/keystone/keystone.conf` 被禁用。并且， `AdminTokenAuthMiddleware` under `[filter:admin_token_auth]` 从 `/etc/keystone/keystone-paste.ini` + +**失败：**如果 `admin_token` 设置了 under `[DEFAULT]` 部分并 `AdminTokenAuthMiddleware` 存在于 `keystone-paste.ini` 中。 + +**建议** + +```shell +禁用 `admin_token` 意味着它的值为 `` 。 +``` + +#### check-identity-07:/etc/keystone/keystone.conf中的不安全_调试为假 + +如果 `insecure_debug` 设置为 true，则服务器将在 HTTP 响应中返回信息，这些信息可能允许未经身份验证或经过身份验证的用户获取比正常情况更多的信息，例如有关身份验证失败原因的其他详细信息。 + +**通过：**如果 `insecure_debug` under `[DEFAULT]` section in `/etc/keystone/keystone.conf` 为 false。 + +**失败：**如果 `insecure_debug` under `[DEFAULT]` section in `/etc/keystone/keystone.conf` 为 true。 + +#### check-identity-08:使用/etc/keystone/keystone.conf中的Fernet令牌 + +OpenStack Identity 服务提供 `uuid` 和 `fernet` 作为令牌提供者。 `uuid` 令牌必须持久化，并被视为不安全。 + +**通过：**如果 section in `/etc/keystone/keystone.conf` 下的 `[token]` 参数 `provider` 值设置为 fernet。 + +**失败：**如果 section 下的 `[token]` 参数 `provider` 值设置为 uuid。 + +## 仪表板 + +Dashboard （horizon） 是 OpenStack 仪表板，它为用户提供了一个自助服务门户，以便在管理员设置的限制范围内配置自己的资源。其中包括预置用户、定义实例变种、上传虚拟机 （VM） 映像、管理网络、设置安全组、启动实例以及通过控制台访问实例。 + +仪表板基于 Django Web 框架，确保 Django 的安全部署实践直接应用于 Horizon。本指南提供了一组 Django 安全建议。更多信息可以通过阅读 Django 文档找到。 + +仪表板附带默认安全设置，并具有部署和配置文档。 + +- 域名、仪表板升级和基本 Web 服务器配置 + + - 域名 + - 基本 Web 服务器配置 + - 允许的主机 + - 映像上传 + +- HTTPS、HSTS、XSS 和 SSRF + + - 跨站点脚本 （XSS） + - 跨站点请求伪造 （CSRF） + - 跨帧脚本 （XFS） + - HTTPS协议 + - HTTP 严格传输安全 （HSTS） + +- 前端缓存和会话后端 + + - 前端缓存 + - 会话后端 + +- 静态媒体 +- 密码 +- 密钥 +- 网站数据 +- 跨域资源共享 （CORS） +- 调试 +- 检查表 + + - Check-Dashboard-01：用户/配置文件组是否设置为 root/horizon？ + - Check-Dashboard-02：是否为 Horizon 配置文件设置了严格权限？ + - Check-Dashboard-03：参数是否 DISALLOW_IFRAME_EMBED 设置为 True ？ + - Check-Dashboard-04：参数是否 CSRF_COOKIE_SECURE 设置为 True ？ + - Check-Dashboard-05：参数是否 SESSION_COOKIE_SECURE 设置为 True ？ + - Check-Dashboard-06：参数是否 SESSION_COOKIE_HTTPONLY 设置为 True ？ + - Check-Dashboard-07： PASSWORD_AUTOCOMPLETE 设置为 False ？ + - Check-Dashboard-08： DISABLE_PASSWORD_REVEAL 设置为 True ？ + - Check-Dashboard-09： ENFORCE_PASSWORD_CHECK 设置为 True ？ + - Check-Dashboard-10：是否 PASSWORD_VALIDATOR 已配置？ + - Check-Dashboard-11：是否 SECURE_PROXY_SSL_HEADER 已配置？ + +### 域名、仪表板升级和基本 Web 服务器配置 + +#### 域名 + +许多组织通常在总体组织域的子域中部署 Web 应用程序。用户很自然地期望 `openstack.example.org` .在此上下文中，通常存在部署在同一个二级命名空间中的应用程序。此名称结构非常方便，并简化了名称服务器的维护。 + +我们强烈建议将仪表板部署到二级域，例如 ，而不是在任何级别的共享子域上部署仪表板，例如 `https://example.com` `https://openstack.example.org` 或 `https://horizon.openstack.example.org` 。我们还建议不要部署到裸内部域，例如 `https://horizon/` .这些建议基于浏览器同源策略的限制。 + +如果将仪表板部署在还托管用户生成内容的域中，则本指南中提供的建议无法有效防范已知攻击，即使此内容驻留在单独的子域中也是如此。用户生成的内容可以包含任何类型的脚本、图像或上传内容。大多数主要的 Web 存在（包括 googleusercontent.com、fbcdn.com、github.io 和 twimg.co）都使用这种方法将用户生成的内容与 Cookie 和安全令牌隔离开来。 + +如果您不遵循有关二级域的建议，请避免使用 Cookie 支持的会话存储，并采用 HTTP 严格传输安全 （HSTS）。当部署在子域上时，仪表板的安全性等同于部署在同一二级域上的安全性最低的应用程序。 + +#### 基本的 Web 服务器配置 + +仪表板应部署为 HTTPS 代理（如 Apache 或 Nginx）后面的 Web 服务网关接口 （WSGI） 应用程序。如果 Apache 尚未使用，我们建议使用 Nginx，因为它是轻量级的，并且更容易正确配置。 + +使用 Nginx 时，我们建议 gunicorn 作为 WSGI 主机，并具有适当数量的同步工作线程。使用 Apache 时，我们建议 `mod_wsgi` 托管仪表板。 + +#### 允许的主机 + +使用 OpenStack 仪表板提供的完全限定主机名配置设置 `ALLOWED_HOSTS` 。提供此设置后，如果传入 HTTP 请求的“Host：”标头中的值与此列表中的任何值都不匹配，则将引发错误，并且请求者将无法继续。如果未能配置此选项，或者在指定的主机名中使用通配符，将导致仪表板容易受到与虚假 HTTP 主机标头关联的安全漏洞的影响。 + +有关更多详细信息，请参阅 Django 文档。 + +#### Horizon 镜像上传 + +我们建议实施者禁用HORIZON_IMAGES_ALLOW_UPLOAD，除非他们已实施防止资源耗尽和拒绝服务的计划。 + +### HTTPS、HSTS、XSS 和 SSRF + +#### 跨站脚本 （XSS） + +与许多类似的系统不同，OpenStack 仪表板允许在大多数字段中使用整个 Unicode 字符集。这意味着开发人员犯错误的自由度较小，这些错误为跨站点脚本 （XSS） 打开了攻击媒介。 + +Dashboard 为开发人员提供了避免创建 XSS 漏洞的工具，但它们只有在开发人员正确使用它们时才有效。审核任何自定义仪表板，特别注意 `mark_safe` 函数的使用、与自定义模板标记的使用 `is_safe` 、 `safe` 模板标记的使用、关闭自动转义的任何位置，以及任何可能评估不当转义数据的 JavaScript。 + +#### 跨站请求伪造 （CSRF） + +Django 有专门的中间件用于跨站请求伪造 （CSRF）。有关更多详细信息，请参阅 Django 文档。 + +OpenStack 仪表板旨在阻止开发人员在引入线程时使用自定义仪表板引入跨站点脚本漏洞。应审核使用多个 JavaScript 实例的仪表板是否存在漏洞，例如不当使用 `@csrf_exempt` 装饰器。在放宽限制之前，应仔细评估任何不遵循这些建议的安全设置的仪表板。 + +#### 跨帧脚本 （XFS） + +传统浏览器仍然容易受到跨帧脚本 （XFS） 漏洞的攻击，因此 OpenStack 仪表板提供了一个选项 `DISALLOW_IFRAME_EMBED` ，允许在部署中不使用 iframe 的情况下进行额外的安全强化。 + +#### HTTPS 函数 + +使用来自公认的证书颁发机构 （CA） 的有效受信任证书，将仪表板部署在安全 HTTPS 服务器后面。仅当信任根预安装在所有用户浏览器中时，私有组织颁发的证书才适用。 + +配置对仪表板域的 HTTP 请求，以重定向到完全限定的 HTTPS URL。 + +#### HTTP 严格传输安全 （HSTS） + +强烈建议使用 HTTP 严格传输安全 （HSTS）。 + +**注意** + +```shell +如果您在 Web 服务器前面使用 HTTPS 代理，而不是使用具有 HTTPS 功能的 HTTP 服务器，请修改该 `SECURE_PROXY_SSL_HEADER` 变量。有关修改 `SECURE_PROXY_SSL_HEADER` 变量的信息，请参阅 Django 文档。 +``` + +有关 HTTPS 配置（包括 HSTS 配置）的更具体建议和服务器配置，请参阅“安全通信”一章。 + +### 前端缓存和会话后端 + +#### 前端缓存 + +我们不建议在仪表板中使用前端缓存工具。仪表板正在渲染直接由 OpenStack API 请求生成的动态内容，前端缓存层（如 varnish）可能会阻止显示正确的内容。在 Django 中，静态媒体直接从 Apache 或 Nginx 提供，并且已经受益于 Web 主机缓存。 + +#### 会话后端 + +Horizon 的默认会话后端 `django.contrib.sessions.backends.signed_cookies` 将用户数据保存在浏览器中存储的已签名但未加密的 Cookie 中。由于每个仪表板实例都是无状态的，因此前面提到的方法提供了实现最简单的会话后端扩展的能力。 + +应该注意的是，在这种类型的实现中，敏感的访问令牌将存储在浏览器中，并将随着每个请求的发出而传输。后端确保会话数据的完整性，即使传输的数据仅通过 HTTPS 加密。 + +如果您的架构允许共享存储，并且您正确配置了缓存，我们建议您将其设置为 `SESSION_ENGINE` `django.contrib.sessions.backends.cache` 并用作基于缓存的会话后端，并将 memcached 作为缓存。Memcached 是一种高效的内存键值存储，用于存储数据块，可在高可用性和分布式环境中使用，并且易于配置。但是，您需要确保没有数据泄漏。Memcached 利用备用 RAM 来存储经常访问的数据块，就像重复访问信息的内存缓存一样。由于 memcached 使用本地内存，因此不会产生数据库和文件系统使用开销，从而导致直接从 RAM 而不是从磁盘访问数据。 + +我们建议使用 memcached 而不是本地内存缓存，因为它速度快，数据保留时间更长，多进程安全，并且能够在多个服务器上共享缓存，但仍将其视为单个缓存。 + +要启用 memcached，请执行以下命令： + +```shell +SESSION_ENGINE = 'django.contrib.sessions.backends.cache' +CACHES = { + 'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache' +} +``` + +有关更多详细信息，请参阅 Django 文档。 + +### 静态媒体 + +仪表板的静态媒体应部署到仪表板域的子域，并由 Web 服务器提供服务。使用外部内容分发网络 （CDN） 也是可以接受的。此子域不应设置 Cookie 或提供用户提供的内容。媒体也应使用 HTTPS 提供。 + +Django 媒体设置记录在 Django 文档中。 + +Dashboard 的默认配置使用 django_compressor 来压缩和缩小 CSS 和 JavaScript 内容，然后再提供这些内容。此过程应在部署仪表板之前静态完成，而不是使用默认的请求内动态压缩，并将生成的文件与已部署的代码一起复制到 CDN 服务器。压缩应在非生产生成环境中完成。如果这不可行，我们建议完全禁用资源压缩。不应在生产计算机上安装联机压缩依赖项（较少，Node.js）。 + +### 密码 + +密码管理应该是云管理计划不可或缺的一部分。关于密码的权威教程超出了本书的范围;但是，云管理员应参考 NIST 企业密码管理特别出版物指南第 4 章中推荐的最佳实践。 + +无论是通过仪表板还是其他应用程序，基于浏览器的 OpenStack 云访问都会引入额外的注意事项。现代浏览器都支持某种形式的密码存储和自动填充记住的站点的凭据。这在使用不容易记住或键入的强密码时非常有用，但如果客户端的物理安全性受到威胁，可能会导致浏览器成为薄弱环节。如果浏览器的密码存储本身不受强密码保护，或者如果允许密码存储在会话期间保持解锁状态，则很容易获得对系统的未经授权的访问。 + +KeePassX 和 Password Safe 等密码管理应用程序非常有用，因为大多数应用程序都支持生成强密码和定期提醒生成新密码。最重要的是，密码存储仅短暂保持解锁状态，从而降低了密码泄露和通过浏览器或系统入侵进行未经授权的资源访问的风险。 + +### 密钥 + +仪表板依赖于某些安全功能的共享 `SECRET_KEY` 设置。密钥应为随机生成的字符串，长度至少为 64 个字符，必须在所有活动仪表板实例之间共享。泄露此密钥可能允许远程攻击者执行任意代码。轮换此密钥会使现有用户会话和缓存失效。请勿将此密钥提交到公共存储库。 + +### Cookies + +会话Cookies应设置为 HTTPONLY： + +```shell +SESSION_COOKIE_HTTPONLY = True +``` + +切勿将 CSRF 或会话 Cookie 配置为具有带前导点的通配符域。使用 HTTPS 部署时，应保护 Horizon 的会话和 CSRF Cookie： + +```shell +CSRF_COOKIE_SECURE = True +SESSION_COOKIE_SECURE = True +``` + +### 跨域资源共享 （CORS） + +将 Web 服务器配置为在每次响应时发送限制性 CORS 标头，仅允许仪表板域和协议： + +```shell +Access-Control-Allow-Origin: https://example.com/ +``` + +永远不允许通配符来源。 + +### 调试 + +建议在生产环境中将 `DEBUG` 该设置设置为 `False` 。如果 `DEBUG` 设置为 True，则当抛出异常时，Django 将显示堆栈跟踪和敏感的 Web 服务器状态信息。 + +### 检查表 + +#### Check-Dashboard-01：用户/配置文件组是否设置为 root/horizon？ + +配置文件包含组件平稳运行所需的关键参数和信息。如果非特权用户有意或无意地修改或删除任何参数或文件本身，则会导致严重的可用性问题，从而导致对其他最终用户的拒绝服务。因此，此类关键配置文件的用户所有权必须设置为 root，组所有权必须设置为 horizon。 + +运行以下命令： + +```shell +$ stat -L -c "%U %G" /etc/openstack-dashboard/local_settings.py | egrep "root horizon" +``` + +通过：如果配置文件的用户和组所有权分别设置为 root 和 horizon。上面的命令显示了根地平线的输出。 + +失败：如果上述命令未返回任何输出，因为用户和组所有权可能已设置为除 root 以外的任何用户或除 Horizon 以外的任何组。 + +#### Check-Dashboard-02：是否为 Horizon 配置文件设置了严格权限？ + +与前面的检查类似，建议对此类配置文件设置严格的访问权限。 + +运行以下命令： + +```shell +$ stat -L -c "%a" /etc/openstack-dashboard/local_settings.py +``` + +通过：如果权限设置为 640 或更严格。640 的权限转换为所有者 r/w、组 r，而对其他人没有权限，即“u=rw，g=r，o=”。请注意，使用 Check-Dashboard-01 时：用户/配置文件组是否设置为 root/horizon？权限设置为 640，则 root 用户具有读/写访问权限，Horizon 具有对这些配置文件的读取访问权限。也可以使用以下命令验证访问权限。仅当此命令支持 ACL 时，它才在您的系统上可用。 + +```shell +$ getfacl --tabular -a /etc/openstack-dashboard/local_settings.py +getfacl: Removing leading '/' from absolute path names +# file: etc/openstack-dashboard/local_settings.py +USER root rw- +GROUP horizon r-- +mask r-- +other --- +``` + +失败：如果权限未设置为至少 640。 + +#### Check-Dashboard-03：参数是否 `DISALLOW_IFRAME_EMBED` 设置为 `True` ？ + +`DISALLOW_IFRAME_EMBED` 可用于防止 OpenStack Dashboard 嵌入到 iframe 中。 + +旧版浏览器仍然容易受到跨帧脚本 （XFS） 漏洞的影响，因此此选项允许在部署中未使用 iframe 的情况下进行额外的安全强化。 + +默认设置为 True。 + +通过：如果参数 `DISALLOW_IFRAME_EMBED` in `/etc/openstack-dashboard/local_settings.py` 的值设置为 `True` 。 + +失败：如果参数 `DISALLOW_IFRAME_EMBED` in `/etc/openstack-dashboard/local_settings.py` 的值设置为 `False` 。 + +推荐用于：HTTPS、HSTS、XSS 和 SSRF。 + +#### Check-Dashboard-04：参数是否 `CSRF_COOKIE_SECURE` 设置为 `True` ？ + +CSRF（跨站点请求伪造）是一种攻击，它迫使最终用户在他/她当前经过身份验证的 Web 应用程序上执行未经授权的命令。成功的 CSRF 漏洞可能会危及最终用户的数据和操作。如果目标最终用户具有管理员权限，这可能会危及整个 Web 应用程序。 + +通过：如果参数 `CSRF_COOKIE_SECURE` in `/etc/openstack-dashboard/local_settings.py` 的值设置为 `True` 。 + +失败：如果参数 `CSRF_COOKIE_SECURE` in `/etc/openstack-dashboard/local_settings.py` 的值设置为 `False` 。 + +推荐于：Cookies。 + +#### Check-Dashboard-05：参数是否 `SESSION_COOKIE_SECURE` 设置为 `True` ？ + +“SECURE”cookie 属性指示 Web 浏览器仅通过加密的 HTTPS （SSL/TLS） 连接发送 cookie。此会话保护机制是强制性的，以防止通过 MitM（中间人）攻击泄露会话 ID。它确保攻击者无法简单地从 Web 浏览器流量中捕获会话 ID。 + +通过：如果参数 `SESSION_COOKIE_SECURE` in `/etc/openstack-dashboard/local_settings.py` 的值设置为 `True` 。 + +失败：如果参数 `SESSION_COOKIE_SECURE` in `/etc/openstack-dashboard/local_settings.py` 的值设置为 `False` 。 + +推荐于：Cookies。 + +#### Check-Dashboard-06：参数是否 `SESSION_COOKIE_HTTPONLY` 设置为 `True` ？ + +“HTTPONLY”cookie 属性指示 Web 浏览器不允许脚本（例如 JavaScript 或 VBscript）通过 DOM `document.cookie` 对象访问 cookie。此会话 ID 保护是必需的，以防止通过 XSS 攻击窃取会话 ID。 + +通过：如果参数 `SESSION_COOKIE_HTTPONLY` in `/etc/openstack-dashboard/local_settings.py` 的值设置为 `True` 。 + +失败：如果参数 `SESSION_COOKIE_HTTPONLY` in `/etc/openstack-dashboard/local_settings.py` 的值设置为 `False` 。 + +推荐于：Cookies。 + +#### Check-Dashboard-07： `PASSWORD_AUTOCOMPLETE` 设置为 `False` ？ + +应用程序用于为用户提供便利的常见功能是将密码本地缓存在浏览器中（在客户端计算机上），并在所有后续请求中“预先键入”。虽然此功能对普通用户来说非常友好，但同时，它引入了一个缺陷，因为在客户端计算机上使用相同帐户的任何人都可以轻松访问用户帐户，从而可能导致用户帐户受损。 + +通过：如果参数 `PASSWORD_AUTOCOMPLETE` in `/etc/openstack-dashboard/local_settings.py` 的值设置为 `off` 。 + +失败：如果参数 `PASSWORD_AUTOCOMPLETE` in `/etc/openstack-dashboard/local_settings.py` 的值设置为 `on` 。 + +#### Check-Dashboard-08： `DISABLE_PASSWORD_REVEAL` 设置为 `True` ？ + +与之前的检查类似，建议不要显示密码字段。 + +通过：如果参数 `DISABLE_PASSWORD_REVEAL` in `/etc/openstack-dashboard/local_settings.py` 的值设置为 `True` 。 + +失败：如果参数 `DISABLE_PASSWORD_REVEAL` in `/etc/openstack-dashboard/local_settings.py` 的值设置为 `False` 。 + +**注意** + +```shell +此选项是在 Kilo 版本中引入的。 +``` + +#### Check-Dashboard-09： `ENFORCE_PASSWORD_CHECK` 设置为 `True` ？ + +设置为 `ENFORCE_PASSWORD_CHECK` True 将在“更改密码”窗体上显示“管理员密码”字段，以验证是否确实是管理员登录的要更改密码。 + +通过：如果参数 `ENFORCE_PASSWORD_CHECK` in `/etc/openstack-dashboard/local_settings.py` 的值设置为 `True` 。 + +失败：如果参数 `ENFORCE_PASSWORD_CHECK` in `/etc/openstack-dashboard/local_settings.py` 的值设置为 `False` 。 + +#### Check-Dashboard-10：是否 `PASSWORD_VALIDATOR` 已配置？ + +允许正则表达式验证用户密码的复杂性。 + +通过：如果参数 `PASSWORD_VALIDATOR` in `/etc/openstack-dashboard/local_settings.py` 的值设置为 defaul 之外的任何值，则允许所有 “regex”： '.*'， + +失败：如果参数 `PASSWORD_VALIDATOR` in `/etc/openstack-dashboard/local_settings.py` 的值设置为允许所有 “regex”： '.*' + +#### Check-Dashboard-11：是否 `SECURE_PROXY_SSL_HEADER` 已配置？ + +如果 OpenStack Dashboard 部署在代理后面，并且代理从所有传入请求中剥离 `X-Forwarded-Proto` 标头，或者设置标头 `X-Forwarded-Proto` 并将其发送到 Dashboard，但仅适用于最初通过 HTTPS 传入的请求，那么您应该考虑配置 `SECURE_PROXY_SSL_HEADER` + +更多信息可以在 Django 文档中找到。 + +通过：如果参数 `SECURE_PROXY_SSL_HEADER` in `/etc/openstack-dashboard/local_settings.py` 的值设置为 `'HTTP_X_FORWARDED_PROTO', 'https'` + +失败：如果参数 `SECURE_PROXY_SSL_HEADER` in `/etc/openstack-dashboard/local_settings.py` 的值未设置为 `'HTTP_X_FORWARDED_PROTO', 'https'` 或注释掉。 + +## 计算 + +OpenStack 计算服务 （nova） 在整个云中的许多位置运行，并与各种内部服务进行交互。OpenStack 计算服务提供了多种配置选项，这些选项可能是特定于部署的。 + +在本章中，我们将介绍有关计算安全性的一般最佳实践，以及可能导致安全问题的特定已知配置。 `nova.conf` 文件和 `/var/lib/nova` 位置应受到保护。应实施集中式日志记录、 `policy.json` 文件和强制访问控制框架等控制措施。 + +- 虚拟机管理程序选择 + + - OpenStack 中的虚拟机管理程序 + - 纳入排除标准 + - 团队专长 + - 产品或项目成熟度 + - 认证和证明 + - 通用标准 + - 加密标准 + - FIPS 140-2 + - 硬件问题 + - 虚拟机管理程序与裸机 + - 虚拟机管理程序内存优化 + - KVM 内核 Samepage 合并 + - XEN透明页面共享 + - 内存优化的安全注意事项 + - 其他安全功能 + - 书目 + +- 强化虚拟化层 + + - 物理硬件（PCI 直通） + - 虚拟硬件 （QEMU） + - 最小化 QEMU 代码库 + - 编译器强化 + - 安全加密虚拟化 + - 强制访问控制 + - sVirt：SELinux 和虚拟化 + - 标签和类别 + - SELinux 用户和角色 + - 布尔值 + +- 强化计算部署 + + - OpenStack 漏洞管理团队 + - OpenStack 安全说明 + - OpenStack-dev 邮件列表 + - 虚拟机管理程序邮件列表 + +- 漏洞意识 + + - OpenStack 漏洞管理团队 + - OpenStack 安全说明 + - OpenStack-讨论邮件列表 + - 虚拟机管理程序邮件列表 + +- 如何选择虚拟控制台 + + - 虚拟网络计算机 （VNC） + - 独立计算环境的简单协议 （SPICE） + +- 检查表 + + - Check-Compute-01：配置文件的用户/组所有权是否设置为 root/nova？ + - Check-Compute-02：是否为配置文件设置了严格的权限？ + - Check-Compute-03：Keystone 是否用于身份验证？ + - Check-Compute-04：是否使用安全协议进行身份验证？ + - Check-Compute-05：Nova 与 Glance 的通信是否安全？ + +### 虚拟机管理程序选择 + +#### OpenStack 中的虚拟机管理程序 + +无论OpenStack是部署在私有数据中心内，还是作为公共云服务部署，底层虚拟化技术都能在可扩展性、资源效率和正常运行时间方面提供企业级功能。虽然在许多 OpenStack 支持的虚拟机管理程序技术中通常都具有这种高级优势，但每个虚拟机管理程序的安全架构和功能都存在显著差异，尤其是在考虑弹性 OpenStack 环境特有的安全威胁向量时。随着应用程序整合到单个基础架构即服务 （IaaS） 平台中，虚拟机管理程序级别的实例隔离变得至关重要。安全隔离的要求在商业、政府和军事社区中都适用。 + +在 OpenStack 框架中，您可以在众多虚拟机管理程序平台和相应的 OpenStack 插件中进行选择，以优化您的云环境。在本指南的上下文中，重点介绍了虚拟机管理程序选择注意事项，因为它们与对安全性至关重要的功能集有关。但是，这些注意事项并不意味着对特定虚拟机管理程序的优缺点进行详尽的调查。NIST 在特别出版物 800-125“完整虚拟化技术安全指南”中提供了其他指导。 + +#### 选择标准 + +作为虚拟机管理程序选择过程的一部分，您必须考虑许多重要因素，以帮助改善您的安全状况。具体来说，您必须熟悉以下方面： + +- 团队专长 +- 产品或项目成熟度 +- 通用标准 +- 认证和证明 +- 硬件问题 +- 虚拟机管理程序与裸机 +- 其他安全功能 + +此外，强烈建议在为 OpenStack 部署选择虚拟机管理程序时评估以下与安全相关的标准： *虚拟机管理程序是否经过通用标准认证？如果是这样，达到什么水平？* 底层密码学是否经过第三方认证？ + +#### 团队专长 + +最有可能的是，在选择虚拟机管理程序时，最重要的方面是您的员工在管理和维护特定虚拟机管理程序平台方面的专业知识。您的团队对给定产品、其配置及其怪癖越熟悉，配置错误就越少。此外，在给定的虚拟机管理程序上将员工专业知识分布在整个组织中可以提高系统的可用性，允许职责分离，并在团队成员不可用时缓解问题。 + +#### 产品或项目成熟度 + +给定虚拟机管理程序产品或项目的成熟度对您的安全状况也至关重要。部署云后，产品成熟度会产生许多影响：给定虚拟机管理程序产品或项目的成熟度对您的安全状况也至关重要。部署云后，产品成熟度会产生许多影响： + +- 专业知识的可用性 +- 活跃的开发人员和用户社区 +- 更新的及时性和可用性 +- 发病率响应 + +虚拟机管理程序成熟度的最大指标之一是围绕它的社区的规模和活力。由于这涉及安全性，因此如果您需要额外的云操作员，社区的质量会影响专业知识的可用性。这也表明了虚拟机管理程序的广泛部署，进而导致任何参考架构和最佳实践的战备状态。 + +此外，社区的质量，因为它围绕着KVM或Xen等开源虚拟机管理程序，对错误修复和安全更新的及时性有直接影响。在调查商业和开源虚拟机管理程序时，您必须查看它们的发布和支持周期，以及发布错误或安全问题与补丁或响应之间的时间差。最后，OpenStack 计算支持的功能因所选的虚拟机管理程序而异。请参阅 OpenStack Hypervisor Support Matrix，了解 Hypervisor 对 OpenStack 计算功能的支持。 + +#### 认证和证明 + +选择虚拟机管理程序时，另一个考虑因素是各种正式认证和证明的可用性。虽然它们可能不是特定组织的要求，但这些认证和证明说明了特定虚拟机管理程序平台所经过的测试的成熟度、生产准备情况和彻底性。 + +#### 通用标准 + +通用标准是一个国际标准化的软件评估过程，政府和商业公司使用它来验证软件技术是否如宣传的那样。在政府部门，NSTISSP 第 11 号规定美国政府机构只能采购已通过通用标准认证的软件，该政策自 2002 年 7 月起实施。 + +**注意** + +OpenStack尚未通过通用标准认证，但许多可用的虚拟机管理程序都经过了认证。 + +除了验证技术能力外，通用标准流程还评估技术的开发方式。 + +- 如何进行源代码管理？ +- 如何授予用户对构建系统的访问权限？ +- 该技术在分发前是否经过加密签名？ + +KVM 虚拟机管理程序已通过美国政府和商业发行版的通用标准认证。这些已经过验证，可以将虚拟机的运行时环境彼此分离，从而提供基础技术来实施实例隔离。除了虚拟机隔离之外，KVM 还通过了通用标准认证： + +```shell +"...provide system-inherent separation mechanisms to the resources of virtual +machines. This separation ensures that large software component used for +virtualizing and simulating devices executing for each virtual machine +cannot interfere with each other. Using the SELinux multi-category +mechanism, the virtualization and simulation software instances are +isolated. The virtual machine management framework configures SELinux +multi-category settings transparently to the administrator." +``` + +虽然许多虚拟机管理程序供应商（如 Red Hat、Microsoft 和 VMware）已获得通用标准认证，但其基础认证功能集有所不同，但我们建议评估供应商声明，以确保它们至少满足以下要求： + +| | | +| ------------------ | ------------------------------------------------------------ | +| 审计 | 该系统提供了审核大量事件的功能，包括单个系统调用和受信任进程生成的事件。审计数据以 ASCII 格式收集在常规文件中。系统提供了一个用于搜索审计记录的程序。系统管理员可以定义一个规则库，以将审核限制为他们感兴趣的事件。这包括将审核限制为特定事件、特定用户、特定对象或所有这些的组合的能力。审计记录可以传输到远程审计守护程序。 | +| 自主访问控制 | 自主访问控制 （DAC） 限制对基于 ACL 的文件系统对象的访问，这些对象包括用户、组和其他人员的标准 UNIX 权限。访问控制机制还可以保护 IPC 对象免受未经授权的访问。该系统包括 ext4 文件系统，它支持 POSIX ACL。这允许定义对此类文件系统中文件的访问权限，精确到单个用户的粒度。 | +| 强制访问控制 | 强制访问控制 （MAC） 根据分配给主体和对象的标签来限制对对象的访问。敏感度标签会自动附加到进程和对象。使用这些标签强制实施的访问控制策略派生自 Bell-LaPadula 模型。SELinux 类别附加到虚拟机及其资源。如果虚拟机的类别与所访问资源的类别相同，则使用这些类别强制实施的访问控制策略将授予虚拟机对资源的访问权限。TOE 实现非分层类别来控制对虚拟机的访问。 | +| 基于角色的访问控制 | 基于角色的访问控制 （RBAC） 允许角色分离，无需全能的系统管理员。 | +| 对象重用 | 文件系统对象、内存和 IPC 对象在被属于其他用户的进程重用之前会被清除。 | +| 安全管理 | 系统安全关键参数的管理由管理用户执行。一组需要 root 权限（或使用 RBAC 时需要特定角色）的命令用于系统管理。安全参数存储在特定文件中，这些文件受系统的访问控制机制保护，防止非管理用户未经授权的访问。 | +| 安全通信 | 系统支持使用 SSH 定义可信通道。支持基于密码的身份验证。在评估的配置中，这些协议仅支持有限数量的密码套件。 | +| 存储加密 | 系统支持加密块设备，通过 `dm_crypt` 提供存储机密性。 | +| TSF 保护 | 在运行时，内核软件和数据受到硬件内存保护机制的保护。内核的内存和进程管理组件确保用户进程无法访问内核存储或属于其他进程的存储。非内核 TSF 软件和数据受 DAC 和进程隔离机制保护。在评估的配置中，保留用户 ID root 拥有定义 TSF 配置的目录和文件。通常，包含内部 TSF 数据的文件和目录（如配置文件和批处理作业队列）也受到 DAC 权限的保护，不会被读取。系统以及硬件和固件组件需要受到物理保护，以防止未经授权的访问。系统内核调解对硬件机制本身的所有访问，但程序可见的 CPU 指令函数除外。此外，还提供了防止堆栈溢出攻击的机制。 | + +#### 密码学标准 + +OpenStack 中提供了多种加密算法，用于识别和授权、数据传输和静态数据保护。选择虚拟机管理程序时，我们建议采用以下算法和实现标准： + +| 算法 | 密钥长度 | 预期目的 | 安全功能 | 执行标准 | +| -------------------------------- | --------------------- | ------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | +| AES | 128、192 或 256 位 | 加密/解密 | 受保护的数据传输，保护静态数据 | [RFC 4253](http://www.ietf.org/rfc/rfc4253.txt) | +| TDES | 168 位 | 加密/解密 | 受保护的数据传输 | [RFC 4253](http://www.ietf.org/rfc/rfc4253.txt) | +| RSA | 1024、2048 或 3072 位 | 身份验证、密钥交换 | 识别和身份验证，受保护的数据传输 | [U.S. NIST FIPS PUB 186-3](http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf) | +| DSA | L=1024，N=160位 | 身份验证、密钥交换 | 识别和身份验证，受保护的数据传输 | [U.S. NIST FIPS PUB 186-3](http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf) | +| Serpent | 128、192 或 256 位 | 加密/解密 | 静态数据保护 | | +| Twofish | 128、192 或 256 位 | 加密/解密 | 静态数据保护 | | +| SHA-1 | | 消息摘要 | 保护静态数据，受保护的数据传输 | [U.S. NIST FIPS PUB 180-3](http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf) | +| SHA-2（224、256、384 或 512 位） | | 消息摘要 | Protection for data at rest, identification and authentication 保护静态数据、识别和身份验证 | [U.S. NIST FIPS PUB 180-3](http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf) | + +#### FIPS 140-2 + +在美国，美国国家科学技术研究院 （NIST） 通过称为加密模块验证计划的过程对加密算法进行认证。NIST 认证算法符合联邦信息处理标准 140-2 （FIPS 140-2），确保： + +```shell +"... Products validated as conforming to FIPS 140-2 are accepted by the Federal +agencies of both countries [United States and Canada] for the protection of +sensitive information (United States) or Designated Information (Canada). +The goal of the CMVP is to promote the use of validated cryptographic +modules and provide Federal agencies with a security metric to use in +procuring equipment containing validated cryptographic modules." +``` + +在评估基本虚拟机管理程序技术时，请考虑虚拟机管理程序是否已通过 FIPS 140-2 认证。根据美国政府政策，不仅强制要求符合 FIPS 140-2，而且正式认证表明已对加密算法的给定实现进行了审查，以确保符合模块规范、加密模块端口和接口;角色、服务和身份验证;有限状态模型;人身安全;操作环境;加密密钥管理;电磁干扰/电磁兼容性（EMI/EMC）;自检;设计保证;以及缓解其他攻击。 + +#### 硬件问题 + +在评估虚拟机管理程序平台时，请考虑运行虚拟机管理程序的硬件的可支持性。此外，请考虑硬件中可用的其他功能，以及您在 OpenStack 部署中选择的虚拟机管理程序如何支持这些功能。为此，每个虚拟机管理程序都有自己的硬件兼容性列表 （HCL）。在选择兼容的硬件时，从安全角度来看，提前了解哪些基于硬件的虚拟化技术是重要的，这一点很重要。 + +| 描述 | 科技 | 解释 | +| ------------------ | ------------------- | ----------------------------------- | +| I/O MMU | VT-d / AMD-Vi | 保护 PCI 直通所必需的 | +| 英特尔可信执行技术 | Intel TXT / SEM | 动态证明服务是必需的 | +| PCI-SIG I/O 虚拟化 | SR-IOV, MR-IOV, ATS | 需要允许安全共享 PCI Express 设备 | +| 网络虚拟化 | VT-c | 提高虚拟机管理程序上的网络 I/O 性能 | + +#### 虚拟机管理程序与裸机 + +重要的是要认识到使用 Linux 容器 （LXC） 或裸机系统与使用 KVM 等虚拟机管理程序之间的区别。具体来说，本安全指南的重点主要基于拥有虚拟机管理程序和虚拟化平台。但是，如果您的实现需要使用裸机或 LXC 环境，则必须注意该环境部署方面的特殊差异。 + +在重新预配之前，请确保最终用户已正确清理节点的数据。此外，在重用节点之前，必须保证硬件未被篡改或以其他方式受到损害。 + +**注意** + +虽然OpenStack有一个裸机项目，但对运行裸机的特殊安全影响的讨论超出了本书的范围。 + +由于书本冲刺的时间限制，该团队选择在我们的示例实现和架构中使用 KVM 作为虚拟机管理程序。 + +**注意** + +有一个关于在计算中使用 LXC 的 OpenStack 安全说明。 + +#### Hypervisor 内存优化 + +许多虚拟机监控程序使用内存优化技术将内存过量使用到来宾虚拟机。这是一项有用的功能，可用于部署非常密集的计算群集。实现此目的的一种方法是通过重复数据消除或共享内存页。当两个虚拟机在内存中具有相同的数据时，让它们引用相同的内存是有好处的。 + +通常，这是通过写入时复制 （COW） 机制实现的。这些机制已被证明容易受到侧信道攻击，其中一个 VM 可以推断出另一个 VM 的状态，并且可能不适用于并非所有租户都受信任或共享相同信任级别的多租户环境。 + +#### KVM 内核同页合并 + +在版本 2.6.32 中引入到 Linux 内核中，内核相同页合并 （KSM） 在 Linux 进程之间整合了相同的内存页。由于 KVM 虚拟机管理程序下的每个客户机虚拟机都在自己的进程中运行，因此 KSM 可用于优化虚拟机之间的内存使用。 + +#### XEN 透明页面共享 + +XenServer 5.6 包含一个名为透明页面共享 （TPS） 的内存过量使用功能。TPS 扫描 4 KB 区块中的内存以查找任何重复项。找到后，Xen 虚拟机监视器 （VMM） 将丢弃其中一个重复项，并记录第二个副本的引用。 + +#### 内存优化的安全注意事项 + +传统上，内存重复数据消除系统容易受到侧信道攻击。KSM 和 TPS 都已被证明容易受到某种形式的攻击。在学术研究中，攻击者能够通过分析攻击者虚拟机上的内存访问时间来识别相邻虚拟机上运行的软件包和版本，以及软件下载和其他敏感信息。 + +如果云部署需要强租户分离（如公有云和某些私有云的情况），部署人员应考虑禁用 TPS 和 KSM 内存优化。 + +#### 其他安全功能 + +选择虚拟机管理程序平台时要考虑的另一件事是特定安全功能的可用性。特别是功能。例如，Xen Server 的 XSM 或 Xen 安全模块、sVirt、Intel TXT 或 AppArmor。 + +下表按常见虚拟机管理程序平台列出了这些功能。 + +| | XSM | sVirt | TXT | AppArmor | cgroups | MAC 策略 | +| ------- | ---- | ----- | ---- | -------- | ------- | -------- | +| KVM | | X | X | X | X | X | +| Xen | X | | X | | | | +| ESXi | | | X | | | | +| Hyper-V | | | | | | | + +**注意** + +```shell +此表中的功能可能不适用于所有虚拟机管理程序，也可能无法在虚拟机管理程序之间直接映射。 +``` + +#### 参考书目 + +- Sunar、Eisenbarth、Inci、Gorka Irazoqui Apecechea。对 Xen 和 VMware 进行细粒度跨虚拟机攻击是可能的！2014。 +- Artho、Yagi、Iijima、Kuniyasu Suzaki。内存重复数据删除对客户机操作系统的威胁。2011 年。 +- KVM：基于内核的虚拟机。内核相同页合并。2010。 +- Xen 项目，Xen 安全模块：XSM-FLASK。2014。 +- SELinux 项目，SVirt。2011。 +- Intel.com，采用英特尔可信执行技术 （Intel TXT） 的可信计算池。 +- AppArmor.net，AppArmor 主页。2011。 +- Kernel.org，CGroups。2004。 +- 计算机安全资源中心。完整虚拟化技术安全指南。2011。 +- 国家信息保障伙伴关系，国家安全电信和信息系统安全政策。2003。 + +### 加固虚拟化层 + +在本章的开头，我们将讨论实例对物理和虚拟硬件的使用、相关的安全风险以及缓解这些风险的一些建议。然后，我们将讨论如何使用安全加密虚拟化技术来加密支持该技术的基于 AMD 的机器上的虚拟机的内存。在本章的最后，我们将讨论 sVirt，这是一个开源项目，用于将 SELinux 强制访问控制与虚拟化组件集成。 + +#### 物理硬件（PCI直通） + +许多虚拟机管理程序都提供一种称为 PCI 直通的功能。这允许实例直接访问节点上的硬件。例如，这可用于允许实例访问提供计算统一设备架构 （CUDA） 以实现高性能计算的视频卡或 GPU。此功能存在两种类型的安全风险：直接内存访问和硬件感染。 + +直接内存访问 （DMA） 是一种功能，它允许某些硬件设备访问主机中的任意物理内存地址。视频卡通常具有此功能。但是，不应向实例授予任意物理内存访问权限，因为这将使其能够全面了解主机系统和在同一节点上运行的其他实例。在这些情况下，硬件供应商使用输入/输出内存管理单元 （IOMMU） 来管理 DMA 访问。我们建议云架构师应确保虚拟机监控程序配置为使用此硬件功能。 + +KVM: KVM： + +如何在 KVM 中使用 VT-d 分配设备 + +Xen: Xen： + +Xen VTd Howto Xen VTd 贴士指南 + +**注意** + +IOMMU 功能由 Intel 作为 VT-d 销售，由 AMD 以 AMD-Vi 销售。 + +当实例对固件或设备的某些其他部分进行恶意修改时，就会发生硬件感染。由于此设备由其他实例或主机操作系统使用，因此恶意代码可能会传播到这些系统中。最终结果是，一个实例可以在其安全域之外运行代码。这是一个重大的漏洞，因为重置物理硬件的状态比重置虚拟硬件更难，并且可能导致额外的暴露，例如访问管理网络。 + +硬件感染问题的解决方案是特定于域的。该策略是确定实例如何修改硬件状态，然后确定在使用硬件完成实例时如何重置任何修改。例如，一种选择可能是在使用后重新刷新固件。需要平衡硬件寿命和安全性，因为某些固件在大量写入后会出现故障。安全引导中所述的 TPM 技术是一种用于检测未经授权的固件更改的解决方案。无论选择哪种策略，都必须了解与此类硬件共享相关的风险，以便针对给定的部署方案适当缓解这些风险。 + +由于与 PCI 直通相关的风险和复杂性，默认情况下应禁用它。如果为特定需求启用，则需要制定适当的流程，以确保硬件在重新发行之前是干净的。 + +#### 虚拟硬件 （QEMU） + +运行虚拟机时，虚拟硬件是为虚拟机提供硬件接口的软件层。实例使用此功能提供可能需要的网络、存储、视频和其他设备。考虑到这一点，环境中的大多数实例将专门使用虚拟硬件，少数实例需要直接硬件访问。主要的开源虚拟机管理程序使用 QEMU 来实现此功能。虽然 QEMU 满足了对虚拟化平台的重要需求，但它已被证明是一个非常具有挑战性的软件项目。QEMU 中的许多功能都是通过大多数开发人员难以理解的低级代码实现的。QEMU 虚拟化的硬件包括许多传统设备，这些设备有自己的一套怪癖。综上所述，QEMU 一直是许多安全问题的根源，包括虚拟机管理程序突破攻击。 + +采取积极主动的措施来强化 QEMU 非常重要。我们建议执行三个具体步骤： + +- 最小化代码库。 +- 使用编译器强化。 +- 使用强制访问控制，例如 sVirt、SELinux 或 AppArmor。 + +确保您的 iptables 具有过滤网络流量的默认策略，并考虑检查现有规则集以了解每个规则并确定是否需要扩展该策略。 + +#### 最小化 QEMU 代码库 + +我们建议通过从系统中删除未使用的组件来最小化 QEMU 代码库。QEMU 为许多不同的虚拟硬件设备提供支持，但给定实例只需要少量设备。最常见的硬件设备是 virtio 设备。某些旧实例将需要访问特定硬件，这些硬件可以使用 glance 元数据指定： + +```shell +$ glance image-update \ +--property hw_disk_bus=ide \ +--property hw_cdrom_bus=ide \ +--property hw_vif_model=e1000 \ +f16-x86_64-openstack-sda +``` + +云架构师应决定向云用户提供哪些设备。任何不需要的东西都应该从 QEMU 中删除。此步骤需要在修改传递给 QEMU 配置脚本的选项后重新编译 QEMU。要获得最新选项的完整列表，只需从 QEMU 源目录中运行 ./configure --help。确定部署所需的内容，并禁用其余选项。 + +#### 编译器加固 + +使用编译器强化选项强化 QEMU。现代编译器提供了多种编译时选项，以提高生成的二进制文件的安全性。这些功能包括只读重定位 （RELRO）、堆栈金丝雀、从不执行 （NX）、位置无关可执行文件 （PIE） 和地址空间布局随机化 （ASLR）。 + +许多现代 Linux 发行版已经在构建启用编译器强化的 QEMU，我们建议在继续操作之前验证现有的可执行文件。可以帮助您进行此验证的一种工具称为 checksec.sh + +RELocation 只读 （RELRO） + +强化可执行文件的数据部分。gcc 支持完整和部分 RELRO 模式。对于QEMU来说，完整的RELLO是您的最佳选择。这将使全局偏移表成为只读的，并在生成的可执行文件中将各种内部数据部分放在程序数据部分之前。 + +栈保护 + +将值放在堆栈上并验证其是否存在，以帮助防止缓冲区溢出攻击。 + +从不执行 （NX） + +也称为数据执行保护 （DEP），确保无法执行可执行文件的数据部分。 + +位置无关可执行文件 （PIE） + +生成一个独立于位置的可执行文件，这是 ASLR 所必需的。 + +地址空间布局随机化 （ASLR） + +这确保了代码和数据区域的放置都是随机的。当使用 PIE 构建可执行文件时，由内核启用（所有现代 Linux 内核都支持 ASLR）。 + +编译 QEMU 时，建议对 GCC 使用以下编译器选项： + +```shell +CFLAGS="-arch x86_64 -fstack-protector-all -Wstack-protector \ +--param ssp-buffer-size=4 -pie -fPIE -ftrapv -D_FORTIFY_SOURCE=2 -O2 \ +-Wl,-z,relro,-z,now" +``` + +我们建议在编译 QEMU 可执行文件后对其进行测试，以确保编译器强化正常工作。 + +大多数云部署不会手动构建软件，例如 QEMU。最好使用打包来确保该过程是可重复的，并确保最终结果可以轻松地部署在整个云中。下面的参考资料提供了有关将编译器强化选项应用于现有包的一些其他详细信息。 + +DEB 封装： + +硬化指南 + +RPM 包： + +如何创建 RPM 包 + +#### 安全加密虚拟化 + +安全加密虚拟化 （SEV） 是 AMD 的一项技术，它允许使用 VM 唯一的密钥对 VM 的内存进行加密。SEV 在 Train 版本中作为技术预览版提供，在某些基于 AMD 的机器上提供 KVM 客户机，用于评估技术。 + +nova 配置指南的 KVM 虚拟机管理程序部分包含配置计算机和虚拟机管理程序所需的信息，并列出了 SEV 的几个限制。 + +SEV 为正在运行的 VM 使用的内存中的数据提供保护。但是，虽然 SEV 与 OpenStack 集成的第一阶段支持虚拟机加密内存，但重要的是它不提供 SEV 固件提供的 `LAUNCH_MEASURE` or `LAUNCH_SECRET` 功能。这意味着受 SEV 保护的 VM 使用的数据可能会受到控制虚拟机监控程序的有动机的对手的攻击。例如，虚拟机监控程序计算机上的恶意管理员可以为具有后门和间谍软件的租户提供 VM 映像，这些后门和间谍软件能够窃取机密，或者替换 VNC 服务器进程以窥探发送到 VM 控制台或从 VM 控制台发送的数据，包括解锁全磁盘加密解决方案的密码。 + +为了减少恶意管理员未经授权访问数据的机会，使用 SEV 时应遵循以下安全做法： + +- VM 应使用完整磁盘加密解决方案。 +- 应在 VM 上使用引导加载程序密码。 + +此外，应将标准安全最佳做法用于 VM，包括以下内容： + +- VM 应得到良好的维护，包括定期进行安全扫描和修补，以确保 VM 持续保持强大的安全态势。 +- 与 VM 的连接应使用加密和经过身份验证的协议，例如 HTTPS 和 SSH。 +- 应考虑使用其他安全工具和流程，并将其用于适合数据敏感度级别的 VM。 + +#### 强制访问控制 + +编译器加固使攻击 QEMU 进程变得更加困难。但是，如果攻击者得逞，则需要限制攻击的影响。强制访问控制通过将 QEMU 进程上的权限限制为仅需要的权限来实现此目的。这可以通过使用 sVirt、SELinux 或 AppArmor 来实现。使用 sVirt 时，SELinux 配置为在单独的安全上下文下运行每个 QEMU 进程。AppArmor 可以配置为提供类似的功能。我们在以下 sVirt 和实例隔离部分中提供了有关 sVirt 和实例隔离的更多详细信息：SELinux 和虚拟化。 + +特定的 SELinux 策略可用于许多 OpenStack 服务。CentOS 用户可以通过安装 selinux-policy 源码包来查看这些策略。最新的策略出现在 Fedora 的 selinux-policy 存储库中。rawhide-contrib 分支包含以 `.te` 结尾的文件，例如 `cinder.te` ，这些文件可以在运行 SELinux 的系统上使用。 + +OpenStack 服务的 AppArmor 配置文件当前不存在，但 OpenStack-Ansible 项目通过将 AppArmor 配置文件应用于运行 OpenStack 服务的每个容器来处理此问题。 + +#### sVirt：SELinux 和虚拟化 + +凭借独特的内核级架构和国家安全局 （NSA） 开发的安全机制，KVM 为多租户提供了基础隔离技术。安全虚拟化 （sVirt） 技术的发展起源于 2002 年，是 SELinux 对现代虚拟化的应用。SELinux 旨在应用基于标签的分离控制，现已扩展为在虚拟机进程、设备、数据文件和代表它们执行操作的系统进程之间提供隔离。 + +OpenStack 的 sVirt 实现旨在保护虚拟机管理程序主机和虚拟机免受两个主要威胁媒介的侵害： + +虚拟机监控程序威胁 + +在虚拟机中运行的受损应用程序会攻击虚拟机监控程序以访问底层资源。例如，当虚拟机能够访问虚拟机监控程序操作系统、物理设备或其他应用程序时。此威胁向量存在相当大的风险，因为虚拟机监控程序上的入侵可能会感染物理硬件并暴露其他虚拟机和网段。 + +虚拟机（多租户）威胁 + +在 VM 中运行的受损应用程序会攻击虚拟机监控程序，以访问或控制另一个虚拟机及其资源。这是虚拟化特有的威胁向量，存在相当大的风险，因为大量虚拟机文件映像可能因单个应用程序中的漏洞而受到损害。这种虚拟网络攻击是一个主要问题，因为用于保护真实网络的管理技术并不直接适用于虚拟环境。 + +每个基于 KVM 的虚拟机都是一个由 SELinux 标记的进程，从而有效地在每个虚拟机周围建立安全边界。此安全边界由 Linux 内核监视和强制执行，从而限制虚拟机访问其边界之外的资源，例如主机数据文件或其他 VM。 + +无论虚拟机内运行的客户机操作系统如何，都会提供 sVirt 隔离。可以使用 Linux 或 Windows VM。此外，许多 Linux 发行版在操作系统中提供 SELinux，使虚拟机能够保护内部虚拟资源免受威胁。 + +#### 标签和类别 + +基于 KVM 的虚拟机实例使用其自己的 SELinux 数据类型进行标记，称为 `svirt_image_t` 。内核级保护可防止未经授权的系统进程（如恶意软件）操纵磁盘上的虚拟机映像文件。关闭虚拟机电源后，映像的存储 `svirt_image_t` 方式如下所示： + +```shell +system_u:object_r:svirt_image_t:SystemLow image1 +system_u:object_r:svirt_image_t:SystemLow image2 +system_u:object_r:svirt_image_t:SystemLow image3 +system_u:object_r:svirt_image_t:SystemLow image4 +``` + +该 `svirt_image_t` 标签唯一标识磁盘上的图像文件，允许 SELinux 策略限制访问。当基于 KVM 的计算映像通电时，sVirt 会将随机数字标识符附加到映像中。sVirt 能够为每个虚拟机管理程序节点最多分配 524,288 个虚拟机的数字标识符，但大多数 OpenStack 部署极不可能遇到此限制。 + +此示例显示了 sVirt 类别标识符： + +```shell +system_u:object_r:svirt_image_t:s0:c87,c520 image1 +system_u:object_r:svirt_image_t:s0:419,c172 image2 +``` + +#### SELinux 用户和角色 + +SELinux 管理用户角色。可以通过 `-Z` 标志或使用 semanage 命令查看这些内容。在虚拟机管理程序上，只有管理员才能访问系统，并且应该围绕管理用户和系统上的任何其他用户具有适当的上下文。有关更多信息，请参阅 SELinux 用户文档。 + +#### 布尔值 + +为了减轻管理 SELinux 的管理负担，许多企业 Linux 平台利用 SELinux 布尔值来快速改变 sVirt 的安全态势。 + +基于 Red Hat Enterprise Linux 的 KVM 部署使用以下 sVirt 布尔值： + +| sVirt SELinux 布尔值 | 描述 | +| -------------------- | ----------------------------------- | +| virt_use_common | 允许 virt 使用串行或并行通信端口。 | +| virt_use_fusefs | 允许 virt 读取 FUSE 挂载的文件。 | +| virt_use_nfs | 允许 virt 管理 NFS 挂载的文件。 | +| virt_use_samba | 允许 virt 管理 CIFS 挂载的文件。 | +| virt_use_sanlock | 允许受限的虚拟访客与 sanlock 交互。 | +| virt_use_sysfs | 允许 virt 管理设备配置 （PCI）。 | +| virt_use_usb | 允许 virt 使用 USB 设备。 | +| virt_use_xserver | 允许虚拟机与 X Window 系统交互。 | + +### 加固计算部署 + +任何OpenStack部署的主要安全问题之一是围绕敏感文件（如 `nova.conf` 文件）的安全性和控制。此配置文件通常包含在 `/etc` 目录中，包含许多敏感选项，包括配置详细信息和服务密码。应为所有此类敏感文件授予严格的文件级权限，并通过文件完整性监视 （FIM） 工具（如 iNotify 或 Samhain）监视更改。这些实用程序将获取处于已知良好状态的目标文件的哈希值，然后定期获取该文件的新哈希值，并将其与已知良好的哈希值进行比较。如果发现警报被意外修改，则可以创建警报。 + +可以检查文件的权限，我移动到文件所在的目录并运行 ls -lh 命令。这将显示有权访问文件的权限、所有者和组，以及其他信息，例如上次修改文件的时间和创建时间。 + +该 `/var/lib/nova` 目录用于保存有关给定计算主机上的实例的详细信息。此目录也应被视为敏感目录，并具有严格强制执行的文件权限。此外，应定期备份它，因为它包含与该主机关联的实例的信息和元数据。 + +如果部署不需要完整的虚拟机备份，建议排除该 `/var/lib/nova/instances` 目录，因为它的大小将与该节点上运行的每个 VM 的总空间一样大。如果部署确实需要完整 VM 备份，则需要确保成功备份此目录。 + +监视是 IT 基础结构的关键组件，我们建议监视和分析计算日志文件，以便可以创建有意义的警报。 + +#### OpenStack 漏洞管理团队 + +我们建议在发布安全问题和建议时及时了解它们。OpenStack 安全门户是一个中央门户，可以在这里协调建议、通知、会议和流程。此外，OpenStack 漏洞管理团队 （VMT） 门户通过将 Bug 标记为“此 bug 是安全漏洞”来协调 OpenStack 项目内的补救措施，以及调查负责任地（私下）向 VMT 披露的报告 bug 的过程。VMT 流程页面中概述了更多详细信息，并生成了 OpenStack 安全公告 （OSSA）。此 OSSA 概述了问题和修复程序，并链接到原始错误和补丁托管位置。 + +#### OpenStack 安全注意事项 + +报告的安全漏洞被发现是配置错误的结果，或者不是严格意义上的 OpenStack 的一部分，这些漏洞将被起草到 OpenStack 安全说明 （OSSN） 中。这些问题包括配置问题，例如确保身份提供程序映射以及非 OpenStack，但关键问题（例如影响 OpenStack 使用的平台的 Bashbug/Ghost 或 Venom 漏洞）。当前的 OSSN 集位于安全说明 wiki 中。 + +#### OpenStack-dev 邮件列表 + +所有错误、OSSA 和 OSSN 都通过 openstack-discuss 邮件列表公开发布，主题行中带有 [security] 主题。我们建议订阅此列表以及邮件过滤规则，以确保不会遗漏 OSSN、OSSA 和其他重要公告。openstack-discuss 邮件列表通过 OpenStack Development Mailing List 进行管理。openstack-discuss 使用《项目团队指南》中定义的标记。 + +#### 虚拟机管理程序邮件列表 + +在实施OpenStack时，核心决策之一是使用哪个虚拟机管理程序。我们建议您了解与您选择的虚拟机管理程序相关的公告。以下是几个常见的虚拟机管理程序安全列表： + +Xen： + + + +VMWare： + + + +其他（KVM 等）： + + + +### 漏洞意识 + +#### OpenStack 漏洞管理团队 + +我们建议在发布安全问题和建议时及时了解它们。OpenStack 安全门户是一个中央门户，可以在这里协调建议、通知、会议和流程。此外，OpenStack 漏洞管理团队 （VMT） 门户协调 OpenStack 内部的补救措施，以及调查负责任地（私下）向 VMT 披露的报告错误的过程，方法是将错误标记为“此错误是安全漏洞”。VMT 流程页面中概述了更多详细信息，并生成了 OpenStack 安全公告 （OSSA）。此 OSSA 概述了问题和修复程序，并链接到原始错误和补丁托管位置。 + +#### OpenStack 安全注意事项 + +报告的安全漏洞被发现是配置错误的结果，或者不是严格意义上的 OpenStack 的一部分，将被起草到 OpenStack 安全说明 （OSSN） 中。这些问题包括配置问题，例如确保身份提供商映射，以及非 OpenStack 但关键的问题，例如影响 OpenStack 使用的平台的 Bashbug/Ghost 或 Venom 漏洞。当前的 OSSN 集位于安全说明 wiki 中。 + +#### OpenStack-discuss 邮件列表 + +所有 bug、OSSA 和 OSSN 都通过 openstack-discuss 邮件列表公开发布，主题行中包含 [security] 主题。我们建议订阅此列表以及邮件过滤规则，以确保不会遗漏 OSSN、OSSA 和其他重要公告。openstack-discuss 邮件列表通过 进行管理。openstack-discuss 使用《项目团队指南》中定义的标记。 + +#### 虚拟机管理程序邮件列表 + +在实施OpenStack时，核心决策之一是使用哪个虚拟机管理程序。我们建议您了解与您选择的虚拟机管理程序相关的公告。以下是几个常见的虚拟机管理程序安全列表： + +- Xen： + + + +- VMWare： + + + +- 其他（KVM 等）： + + + +### 如何选择虚拟控制台 + +云架构师需要做出的有关计算服务配置的一个决定是使用 VNC 还是 SPICE。 + +#### 虚拟网络计算机 （VNC） + +OpenStack 可以配置为使用虚拟网络计算机 （VNC） 协议为租户和管理员提供对实例的远程桌面控制台访问。 + +##### 功能 + +1. OpenStack Dashboard （horizon） 可以使用 HTML5 noVNC 客户端直接在网页上为实例提供 VNC 控制台。这要求 `nova-novncproxy` 服务从公用网络桥接到管理网络。 +2. `nova` 命令行实用程序可以返回 VNC 控制台的 URL，以供 nova Java VNC 客户端访问。这要求 `nova-xvpvncproxy` 服务从公用网络桥接到管理网络。 + +##### 安全注意事项 + +1. 默认情况下， `nova-novncproxy` 和 `nova-xvpvncproxy` 服务会打开经过令牌身份验证的面向公众的端口。 +2. 默认情况下，远程桌面流量未加密。可以启用 TLS 来加密 VNC 流量。请参阅 TLS 和 SSL 简介以获取适当的建议。 + +##### 参考书目 + +1. blog.malchuk.ru, OpenStack VNC Security. 2013. [Secure Connections to VNC ports](http://blog.malchuk.ru/2013/05/21/47) + blog.malchuk.ru，OpenStack VNC 安全性。2013. 与 VNC 端口的安全连接 +2. OpenStack Mailing List, [OpenStack] nova-novnc SSL configuration - Havana. 2014. [OpenStack nova-novnc SSL Configuration](http://lists.openstack.org/pipermail/openstack/2014-February/005357.html) + OpenStack 邮件列表，[OpenStack] nova-novnc SSL 配置 - 哈瓦那。2014. OpenStack nova-novnc SSL配置 +3. Redhat.com/solutions，在 OpenStack 中使用 SSL 加密 nova-novacproxy。2014. OpenStack nova-novncproxy SSL加密 + +#### 独立计算环境的简单协议 （SPICE） + +作为 VNC 的替代方案，OpenStack 使用独立计算环境的简单协议 （SPICE） 协议提供对客户机虚拟机的远程桌面访问。 + +##### 功能 + +1. OpenStack Dashboard （horizon） 直接在实例网页上支持 SPICE。这需要服务 `nova-spicehtml5proxy` 。 +2. nova 命令行实用程序可以返回 SPICE 控制台的 URL，以供 SPICE-html 客户端访问。 + +##### 限制 + +1. 尽管 SPICE 与 VNC 相比具有许多优势，但 spice-html5 浏览器集成目前不允许管理员利用这些优势。为了利用 多显示器、USB 直通等 SPICE 功能，我们建议管理员在管理网络中使用独立的 SPICE 客户端。 + +##### 安全注意事项 + +1. 默认情况下，该 `nova-spicehtml5proxy` 服务会打开经过令牌身份验证的面向公众的端口。 +2. 功能和集成仍在不断发展。我们将在下一个版本中访问这些功能并提出建议。 +3. 与 VNC 的情况一样，目前我们建议从管理网络使用 SPICE，此外还限制使用少数人。 + +##### 参考书目 + +1. OpenStack 管理员指南。SPICE控制台。SPICE控制台。 +2. bugzilla.redhat.com， Bug 913607 - RFE： 支持通过 websockets 隧道传输 SPICE。2013. RedHat 错误913607。 + +### 检查表 + +#### Check-Compute-01：配置文件的用户/组所有权是否设置为 root/nova？ + +配置文件包含组件平稳运行所需的关键参数和信息。如果非特权用户有意或无意地修改或删除任何参数或文件本身，则会导致严重的可用性问题，从而导致拒绝向其他最终用户提供服务。此类关键配置文件的用户所有权必须设置为 `nova` ， `root` 并且组所有权必须设置为 。此外，包含目录应具有相同的所有权，以确保正确拥有新文件。 + +运行以下命令： + +```shell +$ stat -L -c "%U %G" /etc/nova/nova.conf | egrep "root nova" +$ stat -L -c "%U %G" /etc/nova/api-paste.ini | egrep "root nova" +$ stat -L -c "%U %G" /etc/nova/policy.json | egrep "root nova" +$ stat -L -c "%U %G" /etc/nova/rootwrap.conf | egrep "root nova" +$ stat -L -c "%U %G" /etc/nova | egrep "root nova" +``` + +通过：如果所有这些配置文件的用户和组所有权分别设置为 `root` 和 `nova` 。上述命令显示 的 `root nova` 输出。 + +失败：如果上述命令未返回任何输出，则用户和组所有权可能已设置为除 以外的任何用户或除 `nova` 以外的 `root` 任何组。 + +推荐于：计算。 + +#### Check-Compute-02：是否为配置文件设置了严格的权限？ + +与前面的检查类似，我们建议为此类配置文件设置严格的访问权限。 + +运行以下命令： + +```shell +$ stat -L -c "%a" /etc/nova/nova.conf +$ stat -L -c "%a" /etc/nova/api-paste.ini +$ stat -L -c "%a" /etc/nova/policy.json +$ stat -L -c "%a" /etc/nova/rootwrap.conf +``` + +还可以进行更广泛的限制：如果包含目录设置为 750，则保证此目录中新创建的文件具有所需的权限。 + +通过：如果权限设置为 640 或更严格，或者包含目录设置为 750。640/750 的权限转换为所有者 r/w、组 r，而对其他人没有权限。例如，“u=rw，g=r，o=”。 + +**注意** + +```shell +如果 Check-Compute-01：配置文件的用户/组所有权是否设置为 root/nova？权限设置为 640，root 具有读/写访问权限，nova 具有对这些配置文件的读取访问权限。也可以使用以下命令验证访问权限。仅当此命令支持 ACL 时，它才在您的系统上可用。 +``` + +```shell +$ getfacl --tabular -a /etc/nova/nova.conf +getfacl: Removing leading '/' from absolute path names +# file: etc/nova/nova.conf +USER root rw- +GROUP nova r-- +mask r-- +other --- +``` + +失败：如果权限未设置为至少 640/750。 + +推荐于：计算。 + +#### Check-Compute-03：Keystone 是否用于身份验证？ + +**注意** + +```shell +此项仅适用于 OpenStack 版本 Rocky 及之前版本，因为 `auth_strategy` Stein 中已弃用。 +``` + +OpenStack 支持各种身份验证策略，如 noauth 和 keystone。如果使用 noauth 策略，那么用户无需任何身份验证即可与 OpenStack 服务进行交互。这可能是一个潜在的风险，因为攻击者可能会获得对 OpenStack 组件的未经授权的访问。我们强烈建议所有服务都必须使用其服务帐户通过 keystone 进行身份验证。 + +在Ocata之前： + +通过：如果 section in 下的参数 `auth_strategy` 设置为 `keystone` 。 `[DEFAULT]` `/etc/nova/nova.conf` + +失败：如果 section 下的 `[DEFAULT]` 参数 `auth_strategy` 值设置为 `noauth` 或 `noauth2` 。 + +在Ocata之后： + +通过：如果 under `[api]` 或 `[DEFAULT]` section in `/etc/nova/nova.conf` 的参数 `auth_strategy` 值设置为 `keystone` 。 + +失败：如果 or `[DEFAULT]` 部分下的 `[api]` 参数 `auth_strategy` 值设置为 `noauth` 或 `noauth2` 。 + +#### Check-Compute-04：是否使用安全协议进行身份验证？ + +OpenStack 组件使用各种协议相互通信，通信可能涉及敏感或机密数据。攻击者可能会尝试窃听频道以访问敏感信息。所有组件必须使用安全通信协议相互通信。 + +通过：如果 section in `/etc/nova/nova.conf` 下的参数值设置为 Identity API 端点开头， `https://` 并且 same `/etc/nova/nova.conf` 中同一 `[keystone_authtoken]` 部分下的 `[keystone_authtoken]` 参数 `www_authenticate_uri` `insecure` 值设置为 `False` 。 + +失败：如果 in `/etc/nova/nova.conf` 部分下的 `[keystone_authtoken]` 参数 `www_authenticate_uri` 值未设置为以 开头的身份 API 端点， `https://` 或者同一 `/etc/nova/nova.conf` 部分中的参数 `insecure` `[keystone_authtoken]` 值设置为 `True` 。 + +#### Check-Compute-05：Nova 与 Glance 的通信是否安全？ + +OpenStack 组件使用各种协议相互通信，通信可能涉及敏感或机密数据。攻击者可能会尝试窃听频道以访问敏感信息。所有组件必须使用安全通信协议相互通信。 + +通过：如果 section in 下的参数值设置为 `False` ，并且 section in `/etc/nova/nova.conf` `/etc/nova/nova.conf` 下的 `[glance]` `[glance]` 参数 `api_insecure` `api_servers` 值设置为以 `https://` 开头的值。 + +失败：如果 in `/etc/nova/nova.conf` 节下的参数值设置为 `True` ，或者 in `/etc/nova/nova.conf` 节下的 `[glance]` `[glance]` 参数 `api_insecure` `api_servers` 值设置为不以 `https://` 开头的值。 + +## 块存储 + +OpenStack Block Storage （cinder） 是一项服务，它提供软件（服务和库）来自助管理持久性块级存储设备。这将创建对块存储资源的按需访问，以便与 OpenStack 计算 （nova） 实例一起使用。通过将块存储池虚拟化到各种后端存储设备（可以是软件实现或传统硬件存储产品），通过抽象创建软件定义存储。其主要功能是管理块设备的创建、附加和分离。消费者不需要知道后端存储设备的类型或它的位置。 + +计算实例通过行业标准存储协议（如 iSCSI、以太网 ATA 或光纤通道）存储和检索块存储。这些资源通过 OpenStack 原生标准 HTTP RESTful API 进行管理和配置。有关 API 的更多详细信息，请参阅 OpenStack 块存储文档。 + +- 卷擦除 +- 检查表 + - Check-Block-01：配置文件的用户/组所有权是否设置为 root/cinder？ + - Check-Block-02：是否为配置文件设置了严格的权限？ + - Check-Block-03：Keystone 是否用于身份验证？ + - Check-Block-04：是否启用了 TLS 进行身份验证？ + - Check-Block-05：cinder 是否通过 TLS 与 nova 通信？ + - Check-Block-06：cinder 是否通过 TLS 与 glance 通信？ + - Check-Block-07： NAS 是否在安全的环境中运行？ + - Check-Block-08：请求正文的最大大小是否设置为默认值 （114688）？ + - Check-Block-09：是否启用了卷加密功能？ + +**注意** + +```shell +虽然本章目前对具体指南的介绍很少，但预计将遵循标准的强化实践。本节将扩展相关信息。 +``` + +### 卷擦除 + +有几种方法可以擦除块存储设备。传统的方法是将 `lvm_type` 设置为 `thin` ，如果使用 LVM 后端，则使用 `volume_clear` 该参数。或者，如果使用卷加密功能，则在删除卷加密密钥时不需要卷擦除。有关设置的详细信息，请参阅卷加密部分中的 OpenStack 配置参考文档，以及有关密钥删除的 Castellan 使用文档 + +**注意** + +```shell +在较旧的 OpenStack 版本中， `lvm_type=default` 用于表示擦除。虽然此方法仍然有效，但 `lvm_type=default` 不建议用于设置安全删除。 +``` + +该 `volume_clear` 参数可以设置为 `zero` 。该 `zero` 参数将向设备写入一次零传递。 + +有关该 `lvm_type` 参数的更多信息，请参阅 cinder 项目文档的精简置备中的 LVM 和超额订阅部分。 + +有关该 `volume_clear` 参数的详细信息，请参阅 cinder 项目文档的 Cinder 配置选项部分。 + +#### 检查表 + +#### Check-Block-01：配置文件的用户/组所有权是否设置为 root/cinder？ + +配置文件包含组件平稳运行所需的关键参数和信息。如果非特权用户有意或无意地修改或删除任何参数或文件本身，则会导致严重的可用性问题，从而导致拒绝向其他最终用户提供服务。因此，此类关键配置文件的用户所有权必须设置为 root，组所有权必须设置为 cinder。此外，包含目录应具有相同的所有权，以确保正确拥有新文件。 + +运行以下命令： + +```shell +$ stat -L -c "%U %G" /etc/cinder/cinder.conf | egrep "root cinder" +$ stat -L -c "%U %G" /etc/cinder/api-paste.ini | egrep "root cinder" +$ stat -L -c "%U %G" /etc/cinder/policy.json | egrep "root cinder" +$ stat -L -c "%U %G" /etc/cinder/rootwrap.conf | egrep "root cinder" +$ stat -L -c "%U %G" /etc/cinder | egrep "root cinder" +``` + +通过：如果所有这些配置文件的用户和组所有权分别设置为 root 和 cinder。上面的命令显示了根煤渣的输出。 + +失败：如果上述命令未返回任何输出，因为用户和组所有权可能已设置为除 root 以外的任何用户或除 cinder 以外的任何组。 + +#### Check-Block-02：是否为配置文件设置了严格的权限？ + +与前面的检查类似，我们建议为此类配置文件设置严格的访问权限。 + +运行以下命令： + +```shell +$ stat -L -c "%a" /etc/cinder/cinder.conf +$ stat -L -c "%a" /etc/cinder/api-paste.ini +$ stat -L -c "%a" /etc/cinder/policy.json +$ stat -L -c "%a" /etc/cinder/rootwrap.conf +$ stat -L -c "%a" /etc/cinder +``` + +还可以进行更广泛的限制：如果包含目录设置为 750，则保证此目录中新创建的文件具有所需的权限。 + +通过：如果权限设置为 640 或更严格，或者包含目录设置为 750。640/750 的权限转换为所有者 r/w、组 r，而对其他人没有权限，即“u=rw，g=r，o=”。请注意，使用 Check-Block-01 时：配置文件的用户/组所有权是否设置为 root/cinder？权限设置为 640，root 具有读/写访问权限，cinder 具有对这些配置文件的读取访问权限。也可以使用以下命令验证访问权限。仅当此命令支持 ACL 时，它才在您的系统上可用。 + +```shell +$ getfacl --tabular -a /etc/cinder/cinder.conf +getfacl: Removing leading '/' from absolute path names +# file: etc/cinder/cinder.conf +USER root rw- +GROUP cinder r-- +mask r-- +other --- +``` + +失败：如果权限未设置为至少 640。 + +#### Check-Block-03：Keystone 是否用于身份验证？ + +**注意** + +```shell +此项仅适用于 OpenStack 版本 Rocky 及之前版本，因为 `auth_strategy` Stein 中已弃用。 +``` + +OpenStack 支持各种身份验证策略，如 noauth、keystone 等。如果使用“noauth”策略，那么用户无需任何身份验证即可与OpenStack服务进行交互。这可能是一个潜在的风险，因为攻击者可能会获得对 OpenStack 组件的未经授权的访问。因此，我们强烈建议所有服务都必须使用其服务帐户通过 keystone 进行身份验证。 + +通过：如果 section in 下的参数 `auth_strategy` 设置为 `keystone` 。 `[DEFAULT]` `/etc/cinder/cinder.conf` + +失败：如果 section 下的 `[DEFAULT]` 参数 `auth_strategy` 值设置为 `noauth` 。 + +#### Check-Block-04：是否启用了 TLS 进行身份验证？ + +OpenStack 组件使用各种协议相互通信，通信可能涉及敏感/机密数据。攻击者可能会尝试窃听频道以访问敏感信息。因此，所有组件都必须使用安全的通信协议相互通信。 + +通过：如果 section in `/etc/cinder/cinder.conf` 下的参数值设置为 Identity API 端点开头， `https://` 并且 same `/etc/cinder/cinder.conf` 中同一 `[keystone_authtoken]` 部分下的 `[keystone_authtoken]` 参数 `www_authenticate_uri` `insecure` 值设置为 `False` 。 + +失败：如果 in `/etc/cinder/cinder.conf` 部分下的 `[keystone_authtoken]` 参数 `www_authenticate_uri` 值未设置为以 开头的身份 API 端点， `https://` 或者同一 `/etc/cinder/cinder.conf` 部分中的参数 `insecure` `[keystone_authtoken]` 值设置为 `True` 。 + +#### Check-Block-05：cinder 是否通过 TLS 与 nova 通信？ + +OpenStack 组件使用各种协议相互通信，通信可能涉及敏感/机密数据。攻击者可能会尝试窃听频道以访问敏感信息。因此，所有组件都必须使用安全的通信协议相互通信。 + +通过：如果 section in 下的参数 `nova_api_insecure` 设置为 `False` 。 `[DEFAULT]` `/etc/cinder/cinder.conf` + +失败：如果 section in 下的参数 `nova_api_insecure` 设置为 `True` 。 `[DEFAULT]` `/etc/cinder/cinder.conf` + +#### Check-Block-06：cinder 是否通过 TLS 与 glance 通信？ + +与之前的检查（Check-Block-05：cinder 是否通过 TLS 与 nova 通信？）类似，我们建议所有组件使用安全通信协议相互通信。 + +通过：如果 in 部分下的 `[DEFAULT]` 参数值设置为 `False` 并且参数 `glance_api_servers` `glance_api_insecure` 值设置为以 `https://` 开头 `/etc/cinder/cinder.conf` 的值。 + +失败：如果将 section in 下的参数值设置为 `True` 或参数 `glance_api_servers` `glance_api_insecure` 值设置为不以 `https://` 开头的值。 `[DEFAULT]` `/etc/cinder/cinder.conf` + +#### Check-Block-07： NAS 是否在安全的环境中运行？ + +Cinder 支持 NFS 驱动程序，其工作方式与传统的块存储驱动程序不同。NFS 驱动程序实际上不允许实例在块级别访问存储设备。相反，文件是在 NFS 共享上创建的，并映射到模拟块储存设备的实例。Cinder 通过在创建 Cinder 卷时控制文件权限来支持此类文件的安全配置。Cinder 配置还可以控制是以 root 用户身份还是当前 OpenStack 进程用户身份运行文件操作。 + +通过：如果 section in 下的参数 `nas_secure_file_permissions` 设置为 `auto` 。 `[DEFAULT]` `/etc/cinder/cinder.conf` 如果设置为 `auto` ，则在 cinder 启动期间进行检查以确定是否存在现有的 cinder 卷，任何卷都不会将选项设置为 `True` ，并使用安全文件权限。检测现有卷会将选项设置为 `False` ，并使用当前不安全的方法来处理文件权限。如果 section in 下的参数 `nas_secure_file_operations` 设置为 `auto` 。 `[DEFAULT]` `/etc/cinder/cinder.conf` 当设置为“auto”时，在 cinder 启动期间进行检查以确定是否存在现有的 cinder 卷，任何卷都不会将选项设置为 `True` ，安全且不以 `root` 用户身份运行。对现有卷的检测会将选项设置为 `False` ，并使用当前方法以 `root` 用户身份运行操作。对于新安装，会编写一个“标记文件”，以便随后重新启动 cinder 将知道原始确定是什么。 + +失败：如果 section in 下的参数值设置为 `False` ，并且 section in `/etc/cinder/cinder.conf` `/etc/cinder/cinder.conf` 下的 `[DEFAULT]` `[DEFAULT]` 参数 `nas_secure_file_permissions` `nas_secure_file_operations` 值设置为 `False` 。 + +#### Check-Block-08：请求正文的最大大小是否设置为默认值 （114688）？ + +如果未定义每个请求的最大正文大小，攻击者可以构建任意较大的osapi请求，导致服务崩溃，最终导致拒绝服务攻击。分配最大值可确保阻止任何恶意超大请求，从而确保服务的持续可用性。 + +通过：如果 section in 下的参数值设置为 `114688` `114688` ，或者 section in `/etc/cinder/cinder.conf` `/etc/cinder/cinder.conf` 下的 `[oslo_middleware]` `[DEFAULT]` 参数 `osapi_max_request_body_size` `max_request_body_size` 值设置为 。 + +失败：如果 section in 下的参数值未设置为 `114688` ， `114688` 或者 section in `/etc/cinder/cinder.conf` `/etc/cinder/cinder.conf` 下的 `[oslo_middleware]` `[DEFAULT]` 参数 `osapi_max_request_body_size` `max_request_body_size` 值未设置为 。 + +#### Check-Block-09：是否启用了卷加密功能？ + +未加密的卷数据使卷托管平台成为攻击者特别高价值的目标，因为它允许攻击者读取许多不同 VM 的数据。此外，物理存储介质可能会被窃取、重新装载和从另一台计算机访问。加密卷数据可以降低这些风险，并为卷托管平台提供深度防御。块存储 （cinder） 能够在将卷数据写入磁盘之前对其进行加密，因此建议开启卷加密功能。有关说明，请参阅 Openstack Cinder 服务配置文档的卷加密部分。 + +通过：如果 1） 设置了 in `[key_manager]` 部分下的参数值，2） 设置了 in 下的 `[key_manager]` 参数 `backend` `backend` 值，以及 3） 如果正确遵循了 `/etc/cinder/cinder.conf` `/etc/nova/nova.conf` 上述文档中的说明。 + +若要进一步验证，请在完成卷加密设置并为 LUKS 创建卷类型后执行这些步骤，如上述文档中所述。 + +1. 创建 VM： + + ```shell + $ openstack server create --image cirros-0.3.1-x86_64-disk --flavor m1.tiny TESTVM + ``` + +2. 创建加密卷并将其附加到 VM： + + ```shell + $ openstack volume create --size 1 --type LUKS 'encrypted volume' + $ openstack volume list + $ openstack server add volume --device /dev/vdb TESTVM 'encrypted volume' + ``` + +3. 在 VM 上，将一些文本发送到新附加的卷并同步它： + + ```shell + # echo "Hello, world (encrypted /dev/vdb)" >> /dev/vdb + # sync && sleep 2 + ``` + +4. 在托管 cinder 卷服务的系统上，同步以刷新 I/O 缓存，然后测试是否可以找到字符串： + + ```shell + # sync && sleep 2 + # strings /dev/stack-volumes/volume-* | grep "Hello" + ``` + +搜索不应返回写入加密卷的字符串。 + +失败：如果未设置 in 部分下的参数值，或者未设置 in `/etc/cinder/cinder.conf` `/etc/nova/nova.conf` 部分下的 `[key_manager]` `[key_manager]` 参数 `backend` `backend` 值，或者未正确遵循上述文档中的说明。 + +## 图像存储 + +OpenStack Image Storage （glance） 是一项服务，用户可以在其中上传和发现旨在与其他服务一起使用的数据资产。这目前包括图像和元数据定义。 + +映像服务包括发现、注册和检索虚拟机映像。Glance 有一个 RESTful API，允许查询 VM 映像元数据以及检索实际映像。 + +有关该服务的更多详细信息，请参阅 OpenStack Glance 文档。 + +- 检查表 + - Check-Image-01：配置文件的用户/组所有权是否设置为 root/glance？ + - Check-Image-02：是否为配置文件设置了严格的权限？ + - Check-Image-03：Keystone 是否用于身份验证？ + - Check-Image-04：是否启用了 TLS 进行身份验证？ + - Check-Image-05：是否阻止了屏蔽端口扫描？ + +**注意** + +```shell +虽然本章目前对具体指南的介绍很少，但预计将遵循标准的强化实践。本节将扩展相关信息。 +``` + +### 检查表 + +#### Check-Image-01：配置文件的用户/组所有权是否设置为 root/glance？ + +配置文件包含组件平稳运行所需的关键参数和信息。如果非特权用户有意或无意地修改或删除任何参数或文件本身，则会导致严重的可用性问题，从而导致拒绝向其他最终用户提供服务。因此，必须将此类关键配置文件的用户所有权设置为 `glance` ， `root` 并且必须将组所有权设置为 。此外，包含目录应具有相同的所有权，以确保正确拥有新文件。 + +运行以下命令： + +```shell +$ stat -L -c "%U %G" /etc/glance/glance-api-paste.ini | egrep "root glance" +$ stat -L -c "%U %G" /etc/glance/glance-api.conf | egrep "root glance" +$ stat -L -c "%U %G" /etc/glance/glance-cache.conf | egrep "root glance" +$ stat -L -c "%U %G" /etc/glance/glance-manage.conf | egrep "root glance" +$ stat -L -c "%U %G" /etc/glance/glance-registry-paste.ini | egrep "root glance" +$ stat -L -c "%U %G" /etc/glance/glance-registry.conf | egrep "root glance" +$ stat -L -c "%U %G" /etc/glance/glance-scrubber.conf | egrep "root glance" +$ stat -L -c "%U %G" /etc/glance/glance-swift-store.conf | egrep "root glance" +$ stat -L -c "%U %G" /etc/glance/policy.json | egrep "root glance" +$ stat -L -c "%U %G" /etc/glance/schema-image.json | egrep "root glance" +$ stat -L -c "%U %G" /etc/glance/schema.json | egrep "root glance" +$ stat -L -c "%U %G" /etc/glance | egrep "root glance" +``` + +通过：如果所有这些配置文件的用户和组所有权分别设置为 root 和 glance。上面的命令显示了 root glance 的输出。 + +失败：如果上述命令不返回任何输出。 + +#### Check-Image-02：是否为配置文件设置了严格的权限？ + +与前面的检查类似，我们建议您为此类配置文件设置严格的访问权限。 + +运行以下命令： + +```shell +$ stat -L -c "%a" /etc/glance/glance-api-paste.ini +$ stat -L -c "%a" /etc/glance/glance-api.conf +$ stat -L -c "%a" /etc/glance/glance-cache.conf +$ stat -L -c "%a" /etc/glance/glance-manage.conf +$ stat -L -c "%a" /etc/glance/glance-registry-paste.ini +$ stat -L -c "%a" /etc/glance/glance-registry.conf +$ stat -L -c "%a" /etc/glance/glance-scrubber.conf +$ stat -L -c "%a" /etc/glance/glance-swift-store.conf +$ stat -L -c "%a" /etc/glance/policy.json +$ stat -L -c "%a" /etc/glance/schema-image.json +$ stat -L -c "%a" /etc/glance/schema.json +$ stat -L -c "%a" /etc/glance +``` + +还可以进行更广泛的限制：如果包含目录设置为 750，则保证此目录中新创建的文件具有所需的权限。 + +通过：如果权限设置为 640 或更严格，或者包含目录设置为 750。640/750 的权限转换为所有者 r/w、组 r，而对其他人没有权限。例如， `u=rw,g=r,o=` . + +**注意** + +```shell +使用 Check-Image-01： Devices / Group Ownership of config files 是否设置为 root/glance？，权限设置为 640，则 root 具有读/写访问权限，glance 具有对这些配置文件的读取访问权限。也可以使用以下命令验证访问权限。仅当此命令支持 ACL 时，它才在您的系统上可用。 +``` + +```shell +$ getfacl --tabular -a /etc/glance/glance-api.conf +getfacl: Removing leading '/' from absolute path names +# file: /etc/glance/glance-api.conf +USER root rw- +GROUP glance r-- +mask r-- +other --- +``` + +失败：如果权限未设置为至少 640。 + +#### Check-Image-03：Keystone 是否用于身份验证？ + +**注意** + +```shell +此项仅适用于 OpenStack 版本 Rocky 及之前版本，因为 `auth_strategy` Stein 中已弃用。 +``` + +OpenStack 支持各种身份验证策略，包括 noauth 和 keystone。如果使用该 `noauth` 策略，则用户无需任何身份验证即可与 OpenStack 服务进行交互。这可能是一个潜在的风险，因为攻击者可能会获得对 OpenStack 组件的未经授权的访问。我们强烈建议所有服务都必须使用其服务帐户通过 keystone 进行身份验证。 + +通过：如果 section in 下的参数值设置为 ， `keystone` 并且 section in `/etc/glance/glance-api.conf` `/etc/glance /glance-registry.conf` 下的 `[DEFAULT]` `[DEFAULT]` 参数 `auth_strategy` `auth_strategy` 值设置为 `keystone` 。 + +失败：如果 section in 下的参数值设置为 `noauth` 或 section in `/etc/glance/glance-api.conf` `/etc/glance/glance- registry.conf` 下的 `[DEFAULT]` `[DEFAULT]` 参数 `auth_strategy` `auth_strategy` 值设置为 `noauth` 。 + +#### Check-Image-04：是否启用了 TLS 进行身份验证？ + +OpenStack 组件使用各种协议相互通信，通信可能涉及敏感或机密数据。攻击者可能会尝试窃听频道以访问敏感信息。所有组件必须使用安全的通信协议相互通信。 + +通过：如果 section in 下的参数值设置为以 开头的 Identity API 端点 `https://` ，并且该参数 `insecure` `www_authenticate_uri` 的值位于 same `/etc/glance/glance-registry.conf` 中的同一 `[keystone_authtoken]` 部分下，则设置为 `False` 。 `[keystone_authtoken]` `/etc/glance/glance-api.conf` + +失败：如果 中的 `/etc/glance/glance-api.conf` 部分下的 `[keystone_authtoken]` 参数 `www_authenticate_uri` 值未设置为以 `https://` 开头的标识 API 端点，或者同一 `/etc/glance/glance-api.conf` 部分中的参数 `insecure` `[keystone_authtoken]` 值设置为 `True` 。 + +#### Check-Image-05：是否阻止了屏蔽端口扫描？ + +Glance 提供的映像服务 API v1 中的 `copy_from` 功能可允许攻击者执行屏蔽的网络端口扫描。如果启用了 v1 API，则应将此策略设置为受限值。 + +通过：如果参数 `copy_from` in `/etc/glance/policy.json` 的值设置为受限值，例如 `role:admin` . + +失败：未设置参数 `copy_from` in `/etc/glance/policy.json` 的值。 + +## 共享文件系统 + +共享文件系统服务（manila）提供了一组服务，用于管理多租户云环境中的共享文件系统。它类似于OpenStack通过OpenStack块存储服务（cinder）项目提供基于块的存储管理的方式。使用共享文件系统服务，您可以创建共享文件系统并管理其属性，例如可见性、可访问性和使用配额。 + +共享文件系统服务适用于使用以下共享文件系统协议的各种存储提供程序：NFS、CIFS、GlusterFS 和 HDFS。 + +共享文件系统服务的用途与 Amazon Elastic File System （EFS） 相同。 + +- 介绍 + - 一般安全信息 +- 网络和安全模型 + - 共享后端模式 + - 扁平化网络与分段化网络 + - 网络插件 +- 安全服务 + - 安全服务简介 + - 安全服务管理 +- 共享访问控制 +- 共享类型访问控制 +- 政策 +- 检查表 + - Check-Shared-01：配置文件的用户/组所有权是否设置为 root/manila？ + - Check-Shared-02：是否为配置文件设置了严格的权限？ + - Check-Shared-03：OpenStack Identity 是否用于身份验证？ + - Check-Shared-04：是否启用了 TLS 进行身份验证？ + - Check-Shared-05：共享文件系统是否通过 TLS 与计算联系？ + - Check-Shared-06：共享文件系统是否通过 TLS 与网络联系？ + - Check-Shared-07：共享文件系统是否通过 TLS 与块存储联系？ + - Check-Shared-08：请求正文的最大大小是否设置为默认值 （114688）？ + +### 介绍 + +共享文件系统服务（马尼拉）旨在在单节点或跨多个节点运行。共享文件系统服务由四个主要服务组成，它们类似于块存储服务： + +- `manila-api` +- `manila-scheduler` +- `manila-share` +- `manila-data` + +manila-api + +提供稳定 RESTful API 的服务。该服务在整个共享文件系统服务中对请求进行身份验证和路由。有 python-manilaclient 可以与 API 交互。有关共享文件系统 API 的更多详细信息，请参阅 OpenStack 共享文件系统 API。 + +manila-share + +负责管理共享文件服务设备，特别是后端设备。 + +manila-scheduler + +负责安排请求并将其路由到相应的 `manila-share` 服务。它通过选择一个后端，同时过滤除一个后端之外的所有后端来实现这一点。 + +manila-data + +此服务负责管理数据操作，如果不单独处理，可能需要很长时间才能完成，并阻止其他服务。 + +共享文件系统服务使用基于 SQL 的中央数据库，该数据库由系统中的所有共享文件系统服务共享。它可以使用 ORM SQLALcvery 支持的任何 SQL 方言，但仅使用 MySQL 和 PostgreSQL 数据库进行测试。 + +使用 SQL，共享文件系统服务类似于其他 OpenStack 服务，可以与任何 OpenStack 部署一起使用。有关 API 的更多详细信息，请参阅 OpenStack 共享文件系统 API 说明。有关 CLI 用法和配置的更多详细信息，请参阅共享文件系统云管理指南。 + +下图中，您可以看到共享文件系统服务的不同部分如何相互交互。 + +![../_images/manila-intro.png](https://docs.openstack.org/security-guide/_images/manila-intro.png) + +除了已经描述的服务之外，您还可以在图像上看到另外两个实体： `python-manilaclient` 和 `storage controller` 。 + +python-manilaclient + +命令行界面，用于通过 `manila-api` 与共享文件系统服务进行交互，以及用于以编程方式与共享文件系统服务交互的 Python 模块。 + +Storage controller + +通常是一个金属盒，带有旋转磁盘、以太网端口和某种软件，允许网络客户端在磁盘上读取和写入文件。还有一些在任意硬件上运行的纯软件存储控制器，群集控制器可能允许多个物理设备显示为单个存储控制器，或纯虚拟存储控制器。 + +共享是远程的、可装载的文件系统。您可以一次将共享装载到多个主机，也可以由多个用户从多个主机访问共享。 + +共享文件系统服务可以使用不同的网络类型：扁平网络、VLAN、VXLAN 或 GRE，并支持分段网络。此外，还有不同的网络插件，它们提供了与 OpenStack 提供的网络服务的各种集成方法。 + +不同供应商创建了大量共享驱动程序，这些驱动程序支持不同的硬件存储解决方案，例如 NetApp 集群模式 Data ONTAP （ cDOT ）驱动程序，华为 NAS 驱动程序或 GlusterFS 驱动程序。每个共享驱动程序都是一个 Python 类，可以为后端设置并在后端运行以管理共享操作，其中一些操作可能是特定于供应商的。后端是 manila-share 服务的一个实例。 + +客户端用于身份验证和授权的配置数据可以由安全服务存储。可以配置和使用 LDAP、Kerberos 或 Microsoft Active Directory 身份验证服务等协议。 + +除非未在 `policy.json` 中显式更改，否则管理员或拥有共享的租户都能够管理对共享的访问。访问管理是通过创建访问规则来完成的，该规则通过 IP 地址、用户、组或 TLS 证书进行身份验证。可用的身份验证方法取决于您配置和使用的共享驱动程序和安全服务。 + +**注意** + +```shell +不同的驱动程序支持不同的访问选项，具体取决于使用的共享文件系统协议。支持的共享文件系统协议包括 NFS、CIFS、GlusterFS 和 HDFS。例如，通用（块存储作为后端）驱动程序不支持用户和证书身份验证方法。它还不支持任何安全服务，例如 LDAP、Kerberos 或 Active Directory。有关不同驱动程序支持的功能的详细信息，请参阅马尼拉共享功能支持映射。 +``` + +作为管理员，您可以创建共享类型，使计划程序能够在创建共享之前筛选后端。共享类型具有额外的规范，您可以为计划程序设置这些规范，以筛选和权衡后端，以便为请求创建共享的用户选择适当的共享类型。共享和共享类型可以创建为公共或私有。此可见性级别定义其他租户是否能够看到这些对象并对其进行操作。管理员可以为身份服务中的特定用户或租户添加对专用共享类型的访问权限。因此，您授予访问权限的用户可以看到可用的共享类型，并使用它们创建共享。 + +不同用户及其角色的 API 调用权限由策略决定，就像在其他 OpenStack 服务中一样。 + +标识服务可用于共享文件系统服务中的身份验证。请参阅“身份”部分中的身份服务安全性的详细信息。 + +#### 一般安全信息 + +与其他 OpenStack 项目类似，共享文件系统服务已注册到 Identity 服务，因此您可以使用 manila endpoints 命令查找共享服务 v1 和 v2 的 API 端点： + +```shell +$ manila endpoints ++-------------+-----------------------------------------+ +| manila | Value | ++-------------+-----------------------------------------+ +| adminURL | http://172.18.198.55:8786/v1/20787a7b...| +| region | RegionOne | +| publicURL | http://172.18.198.55:8786/v1/20787a7b...| +| internalURL | http://172.18.198.55:8786/v1/20787a7b...| +| id | 82cc5535aa444632b64585f138cb9b61 | ++-------------+-----------------------------------------+ + ++-------------+-----------------------------------------+ +| manilav2 | Value | ++-------------+-----------------------------------------+ +| adminURL | http://172.18.198.55:8786/v2/20787a7b...| +| region | RegionOne | +| publicURL | http://172.18.198.55:8786/v2/20787a7b...| +| internalURL | http://172.18.198.55:8786/v2/20787a7b...| +| id | 2e8591bfcac4405fa7e5dc3fd61a2b85 | ++-------------+-----------------------------------------+ +``` + +默认情况下，共享文件系统 API 服务仅侦听 `tcp6` 类型同时支持 IPv4 和 IPv6 的端口 `8786` 。 + +**注意** + +该端口是共享文件系统服务的默认端口 `8786` 。它可以更改为任何其他端口，但此更改也应在配置文件中的 选项中进行，该选项 `osapi_share_listen_port` 默认为 `8786` 。 + +在 `/etc/manila/` 目录中，您可以找到几个配置文件： + +```shell +api-paste.ini +manila.conf +policy.json +rootwrap.conf +rootwrap.d + +./rootwrap.d: +share.filters +``` + +建议您将共享文件系统服务配置为在非 root 服务帐户下运行，并更改文件权限，以便只有系统管理员才能修改它们。共享文件系统服务要求只有管理员才能写入配置文件，而服务只能通过其在组中的 `manila` 组成员身份读取它们。其他人一定无法读取这些文件，因为这些文件包含不同服务的管理员密码。 + +应用检查 Check-Shared-01：配置文件的用户/组所有权是否设置为 root/manila？和 Check-Shared-02：是否为配置文件设置了严格的权限？从清单中验证权限设置是否正确。 + +**注意** + +```shell +文件中的 manila-rootwrap 配置和文件中 `rootwrap.conf` `rootwrap.d/share.filters` 共享节点的 manila-rootwrap 命令过滤器应归 root 用户所有，并且只能由 root 用户写入。 +``` + +**建议** + +```shell +manila 配置文件 `manila.conf` 可以放置在任何位置。默认情况下，该路径 `/etc/manila/manila.conf` 是必需的。 +``` + +### 网络和安全模型 + +共享文件系统服务中的共享驱动程序是一个 Python 类，可以为后端设置并在其中运行以管理共享操作，其中一些操作是特定于供应商的。后端是 manila-share 服务的实例。共享文件系统服务中有许多由不同供应商创建的共享驱动程序。每个共享驱动程序都支持一种或多种后端模式：共享服务器和无共享服务器。管理员通过在配置文件中 `manila.conf` 指定模式来选择使用哪种模式。它使用了一个选项 `driver_handles_share_servers` 。 + +共享服务器模式可以配置为扁平网络，也可以配置分段网络。这取决于网络提供商。 + +如果您想使用不同的配置，则可以为不同的模式使用相同的硬件使用单独的驱动程序。根据选择的模式，管理员可能需要通过配置文件提供更多配置详细信息。 + +#### 共享后端模式 + +每个共享驱动程序至少支持一种可能的驱动程序模式： + +- 共享服务器模式 +- 无共享服务器模式 + +设置共享服务器模式或无共享服务器模式的 `manila.conf` 配置选项是 `driver_handles_share_servers` 选项。它指示驱动程序是自行处理共享服务器，还是期望共享文件系统服务执行此操作。 + +| 模式 | 配置选项 | 描述 | +| ------------ | ----------------------------------- | ------------------------------------------------------------ | +| 共享服务器 | driver_handles_share_servers =True | 共享驱动程序创建共享服务器并管理或处理共享服务器生命周期。 | +| 无共享服务器 | driver_handles_share_servers =False | 管理员（而不是共享驱动程序）使用某些网络接口（而不是共享服务器的存在）管理裸机存储。 | + +无共享服务器模式 + +在这种模式下，驱动程序基本上没有任何网络要求。假定由驱动程序管理的存储控制器具有所需的所有网络接口。共享文件系统服务将期望驱动程序直接设置共享，而无需事先创建任何共享服务器。此模式对应于某些现有驱动程序已在执行的操作，但它使管理员可以明确选择。在此模式下，共享创建时不需要共享网络，也不得提供共享网络。 + +**注意** + +```shell +在无共享服务器模式下，共享文件系统服务将假定所有租户都已可访问用于导出任何共享的网络接口。 +``` + +在无共享服务器模式下，共享驱动程序不处理存储生命周期。管理员应处理存储、网络接口和其他主机配置。在此模式下，管理员可以将存储设置为导出共享的主机。此模式的主要特征是存储不由共享文件系统服务处理。租户中的用户共享公共网络、主机、处理器和网络管道。如果管理员或代理之前配置的存储没有正确的平衡调整，它们可能会相互阻碍。在公有云中，所有网络容量可能都由一个客户端使用，因此管理员应注意不要发生这种情况。平衡调整可以通过任何方式完成，而不一定是使用 OpenStack 工具。 + +共享服务器模式 + +在此模式下，驱动程序能够创建共享服务器并将其插入现有网络。提供新的共享服务器时，驱动程序需要来自共享文件系统服务的 IP 地址和子网。 + +与无共享服务器模式不同，在共享服务器模式下，用户具有一个共享网络和一个为每个共享网络创建的共享服务器。因此，所有用户都有单独的 CPU、CPU 时间、网络、容量和吞吐量。 + +您还可以在共享服务器和无共享服务器后端模式下配置安全服务。但是，如果没有共享服务器后端模式，管理员应在主机上手动设置所需的身份验证服务。在共享服务器模式下，可以使用共享驱动程序支持的任何现有安全服务自动配置共享文件系统服务。 + +#### 扁平化与分段化网络 + +共享文件系统服务允许使用不同类型的网络： + +- `flat` +- `GRE` +- `VLAN` +- `VXLAN` + +**注意** + +```shell +共享文件系统服务只是将有关网络的信息保存在数据库中，而真正的网络则由网络提供商提供。在OpenStack中，它可以是传统网络（nova-network）或网络（neutron）服务，但共享文件系统服务甚至可以在OpenStack之外工作。这是允许的， `StandaloneNetworkPlugin` 可以与任何网络平台一起使用，并且不需要OpenStack中的某些特定网络服务，如Networking或Legacy网络服务。您可以在其配置文件中设置网络参数。 +``` + +在共享服务器后端模式下，共享驱动程序为每个共享网络创建和管理共享服务器。此模式可分为两种变体： + +- 共享服务器后端模式下的扁平网络 +- 共享服务器后端模式下的分段网络 + +最初，在创建共享网络时，您可以设置 OpenStack Networking （neutron） 的网络和子网，也可以设置 Legacy 网络 （nova-network） 服务网络。第三种方法是在没有旧版网络和网络服务的情况下配置网络。 `StandaloneNetworkPlugin` 可与任何网络平台一起使用。您可以在其配置文件中设置网络参数。 + +**建议** + +```shell +所有使用 OpenStack Compute 服务的共享驱动程序都不使用网络插件。在 Mitaka 版本中，它是 Windows 和通用驱动程序。这些共享驱动器具有其他选项并使用不同的方法。 +``` + +创建共享网络后，共享文件系统服务将检索由网络提供商确定的网络信息：网络类型、分段标识符（如果网络使用分段）和 CIDR 表示法中的 IP 块，以便从中分配网络。 + +共享服务器后端模式下的扁平网络 + +在此模式下，某些存储控制器可以创建共享服务器，但由于物理或逻辑网络的各种限制，所有共享服务器都必须位于扁平网络上。在此模式下，共享驱动程序需要一些东西来为共享服务器预配 IP 地址，但 IP 将全部来自同一子网，并且假定所有租户都可以访问该子网本身。 + +共享网络的安全服务部分指定安全要求，例如 AD 或 LDAP 域或 Kerberos 域。共享文件系统服务假定安全服务中引用的任何主机都可以从创建共享服务器的子网访问，这限制了可以使用此模式的情况数。 + +共享服务器后端模式下的分段网络 + +在此模式下，共享驱动程序能够创建共享服务器并将其插入到现有的分段网络。共享驱动程序期望共享文件系统服务为每个新的共享服务器提供子网定义。此定义应包括分段类型、分段 ID 以及与分段类型相关的任何其他信息。 + +**注意** + +```shell +某些共享驱动程序可能不支持所有类型的分段，有关详细信息，请参阅正在使用的驱动程序的规范。 +``` + +#### 网络插件 + +共享文件系统服务体系结构定义了用于网络资源调配的抽象层。它允许管理员从不同的选项中进行选择，以决定如何将网络资源分配给其租户的网络存储。有几个网络插件提供了与OpenStack提供的网络服务的各种集成方法。 + +网络插件允许使用 OpenStack Networking 和 Legacy 网络服务的任何功能、配置。可以使用网络服务支持的任何网络分段，也可以使用传统网络 （nova-network） 服务的扁平网络或 VLAN 分段网络，也可以使用插件来独立于 OpenStack 网络服务指定网络。有关如何使用不同网络插件的详细信息，请参阅共享文件系统服务网络插件。 + +### 安全服务 + +对于客户端的身份验证和授权，可以选择使用不同的网络身份验证协议配置共享文件系统存储服务。支持的身份验证协议包括 LDAP、Kerberos 和 Microsoft Active Directory 身份验证服务。 + +#### 安全服务介绍 + +创建共享并获取其导出位置后，用户无权装载该共享并处理文件。共享文件系统服务需要显式授予对新共享的访问权限。 + +用于身份验证和授权 （AuthN/AuthZ） 的客户机配置数据可以通过 存储 `security services` 。如果使用的驱动程序和后端支持 LDAP、Kerberos 或 Microsoft Active Directory，则共享文件系统服务可以使用它们。身份验证服务也可以在没有共享文件系统服务的情况下进行配置。 + +**注意** + +```shell +在某些情况下，需要显式指定其中一项安全服务，例如，NetApp、EMC 和 Windows 驱动程序需要 Active Directory 才能创建与 CIFS 协议的共享。 +``` + +#### 安全服务管理 + +安全服务是共享文件系统服务（马尼拉）实体，它抽象出一组选项，这些选项为特定共享文件系统协议（如 Active Directory 域或 Kerberos 域）定义安全域。安全服务包含共享文件系统创建加入给定域的服务器所需的所有信息。 + +使用 API，用户可以创建、更新、查看和删除安全服务。安全服务的设计基于以下假设： + +- 租户提供安全服务的详细信息。 +- 管理员关心安全服务：他们配置此类安全服务的服务器端。 +- 在共享文件系统 API 中，a `security_service` 与 `share_networks` 关联。 +- 共享驱动程序使用安全服务中的数据来配置新创建的共享服务器。 + +创建安全服务时，可以选择以下身份验证服务之一： + +| 身份验证服务 | 描述 | +| ------------ | ------------------------------------------------------------ | +| LDAP | 轻量级目录访问协议。用于通过 IP 网络访问和维护分布式目录信息服务的应用程序协议。 | +| Kerberos | 网络身份验证协议，它基于票证工作，允许通过非安全网络进行通信的节点以安全的方式相互证明其身份。 | +| 活动目录 | Microsoft 为 Windows 域网络开发的目录服务。使用 LDAP、Microsoft 的 Kerberos 版本和 DNS。 | + +共享文件系统服务允许您使用以下选项配置安全服务： + +- 租户网络内部使用的 DNS IP 地址。 +- 安全服务的 IP 地址或主机名。 +- 安全服务的域。 +- 租户使用的用户名或组名。 +- 如果指定用户名，则需要一个用户密码。 + +现有安全服务实体可以与共享网络实体相关联，这些实体通知共享文件系统服务一组共享的安全性和网络配置。您还可以查看指定共享网络的所有安全服务的列表，并取消它们与共享网络的关联。 + +有关通过 API 管理安全服务的详细信息，请参阅安全服务 API。您还可以通过 python-manilaclient 管理安全服务，请参阅安全服务 CLI 管理。 + +管理员和作为共享所有者的用户可以通过创建访问规则，并通过 IP 地址、用户、组或 TLS 证书进行身份验证来管理对共享的访问。身份验证方法取决于您配置和使用的共享驱动程序和安全服务。 + +因此，作为管理员，您可以将后端配置为通过网络使用特定的身份验证服务，它将存储用户。身份验证服务可以在没有共享文件系统和标识服务的客户端上运行。 + +**注意** + +```shell +不同的共享驱动程序支持不同的身份验证服务。有关不同驱动程序支持功能的详细信息，请参阅马尼拉共享功能支持映射。驱动程序对特定身份验证服务的支持并不意味着可以使用任何共享文件系统协议对其进行配置。支持的共享文件系统协议包括 NFS、CIFS、GlusterFS 和 HDFS。有关特定驱动程序及其安全服务配置的信息，请参阅驱动程序供应商的文档。 +``` + +某些驱动程序支持安全服务，而其他驱动程序不支持上述任何安全服务。例如，具有 NFS 或 CIFS 共享文件系统协议的通用驱动程序仅支持通过 IP 地址的身份验证方法。 + +**建议** + +```shell +- 在大多数情况下，支持 CIFS 共享文件系统协议的驱动程序可以配置为使用 Active Directory 并通过用户身份验证管理访问。 +- 支持 GlusterFS 协议的驱动程序可以通过 TLS 证书进行身份验证。 +- 使用支持 NFS 协议的驱动程序，通过 IP 地址进行身份验证是唯一受支持的选项。 +- 由于 HDFS 共享文件系统协议使用 NFS 访问，因此也可以将其配置为通过 IP 地址进行身份验证。 + +但请注意，通过 IP 进行的身份验证是最不安全的身份验证类型。 +``` + +共享文件系统服务实际使用情况的建议配置是使用 CIFS 共享协议创建共享，并向其添加 Microsoft Active Directory 目录服务。在此配置中，您将获得集中式数据库以及将Kerberos和LDAP方法结合在一起的服务。这是一个真实的用例，对于生产共享文件系统来说很方便。 + +### 共享访问控制 + +共享文件系统服务允许授予或拒绝其他客户端对服务的不同实体的访问。 + +将共享作为文件系统的可远程挂载实例，可以管理对指定共享的访问，并列出指定共享的权限。 + +共享可以是公共的，也可以是私有的。这是共享的可见性级别，用于定义其他租户是否可以看到共享。默认情况下，所有共享都创建为专用共享。创建共享时，请使用密钥 `--public` 将共享公开，供其他租户查看共享列表并查看其详细信息。 + +根据 policy.json 文件，管理员和作为共享所有者的用户可以通过创建访问规则来管理对共享的访问。使用 manila access-allow、manila access-deny 和 manila access-list 命令，您可以相应地授予、拒绝和列出对指定共享的访问权限。 + +**建议** + +```shell +默认情况下，当创建共享并具有其导出位置时，共享文件系统服务期望任何人都无法通过装载共享来访问该共享。请注意，您使用的共享驱动程序可以更改此配置，也可以直接在共享存储上更改。要确保访问共享，请检查导出协议的挂载配置。 +``` + +刚创建共享时，没有与之关联的默认访问规则和装载权限。这可以在正在使用的导出协议的挂载配置中看到。例如，存储上有一个 NFS 命令 `exportfs` 或 `/etc/exports` 文件，用于控制每个远程共享并定义可以访问它的主机。如果没有人可以挂载共享，则为空。对于远程 CIFS 服务器，有一个 `net conf list` 显示配置的命令。 `hosts deny` 参数应由共享驱动程序设置 `0.0.0.0/0` ，这意味着任何主机都被拒绝挂载共享。 + +使用共享文件系统服务，可以通过指定以下支持的共享访问级别之一来授予或拒绝对共享的访问： + +- rw。读取和写入 （RW） 访问。这是默认值。 +- ro。只读 （RO） 访问。 + +**建议** + +```shell +当管理员为某些特定编辑者或贡献者提供读写 （RW） 访问权限并为其余用户（查看者）提供只读 （RO） 访问权限时，RO 访问级别在公共共享中会很有帮助。 +``` + +您还必须指定以下受支持的身份验证方法之一： + +- ip。通过实例的 IP 地址对实例进行身份验证。有效格式为 XX.XX.XX.XX 或 XX.XX.XX.XX/XX。例如，0.0.0.0/0。 +- cert。通过 TLS 证书对实例进行身份验证。将 TLS 标识指定为 IDENTKEY。有效值是证书公用名 （CN） 中长度不超过 64 个字符的任何字符串。 +- user。按指定的用户名或组名进行身份验证。有效值是一个字母数字字符串，可以包含一些特殊字符，长度为 4 到 32 个字符。 + +**注意** + +```shell +支持的身份验证方法取决于您配置和使用的共享驱动程序、安全服务和共享文件系统协议。支持的共享文件系统协议包括 NFS、CIFS、GlusterFS 和 HDFS。支持的安全服务包括 LDAP、Kerberos 协议或 Microsoft Active Directory 服务。有关不同驱动程序支持功能的详细信息，请参阅马尼拉共享功能支持映射。 +``` + +下面是与通用驱动程序共享的 NFS 示例。创建共享后，它具有导出位置 `10.254.0.3:/shares/share-b2874f8d-d428-4a5c-b056-e6af80a995de` 。如果您尝试使用 `10.254.0.4` IP 地址将其挂载到主机上，您将收到“权限被拒绝”消息。 + +```shell +# mount.nfs -v 10.254.0.3:/shares/share-b2874f8d-d428-4a5c-b056-e6af80a995de /mnt +mount.nfs: timeout set for Mon Oct 12 13:07:47 2015 +mount.nfs: trying text-based options 'vers=4,addr=10.254.0.3,clientaddr=10.254.0.4' +mount.nfs: mount(2): Permission denied +mount.nfs: access denied by server while mounting 10.254.0.3:/shares/share-b2874f8d-... +``` + +作为管理员，您可以通过 SSH 连接到具有 IP 地址的 `10.254.0.3` 主机，检查其 `/etc/exports` 上的文件并查看它是否为空： + +```shell +# cat /etc/exports +# +``` + +我们在示例中使用的通用驱动程序不支持任何安全服务，因此使用 NFS 共享文件系统协议，我们只能通过 IP 地址授予访问权限： + +```shell +$ manila access-allow Share_demo2 ip 10.254.0.4 ++--------------+--------------------------------------+ +| Property | Value | ++--------------+--------------------------------------+ +| share_id | e57c25a8-0392-444f-9ffc-5daadb9f756c | +| access_type | ip | +| access_to | 10.254.0.4 | +| access_level | rw | +| state | new | +| id | 62b8e453-d712-4074-8410-eab6227ba267 | ++--------------+--------------------------------------+ +``` + +规则进入状态 `active` 后，我们可以再次连接到 `10.254.0.3` 主机并检查 `/etc/exports` 文件，并查看是否添加了带有规则的行： + +```shell +# cat /etc/exports +/shares/share-b2874f8d-d428-4a5c-b056-e6af80a995de 10.254.0.4(rw,sync,wdelay,hide,nocrossmnt,secure,root_squash,no_all_squash,no_subtree_check,secure_locks,acl,anonuid=65534,anongid=65534,sec=sys,rw,root_squash,no_all_squash) +``` + +现在，我们可以使用 IP 地址 `10.254.0.4` 在主机上挂载共享，并拥有 `rw` 共享权限： + +```shell +# mount.nfs -v 10.254.0.3:/shares/share-b2874f8d-d428-4a5c-b056-e6af80a995de /mnt +# ls -a /mnt +. .. lost+found +# echo "Hello!" > /mnt/1.txt +# ls -a /mnt +. .. 1.txt lost+found +# +``` + +### 共享类型访问控制 + +共享类型是管理员定义的“服务类型”，由租户可见描述和租户不可见键值对列表（额外规范）组成。manila-scheduler 使用额外的规范来做出调度决策，驱动程序控制共享创建。 + +管理员可以创建和删除共享类型，还可以管理在共享文件系统服务中赋予它们含义的额外规范。租户可以列出共享类型，并可以使用它们创建新共享。有关管理共享类型的详细信息，请参阅共享文件系统 API 和共享类型管理文档。 + +共享类型可以创建为公共和私有。这是共享类型的可见性级别，用于定义其他租户是否可以在共享类型列表中看到它，并使用它来创建新共享。 + +默认情况下，共享类型创建为公共类型。创建共享类型时，请使用 `--is_public` 参数集 设置为 `False` 私有共享类型，这将防止其他租户在共享类型列表中看到它并使用它创建新共享。另一方面，公共共享类型可供云中的每个租户使用。 + +共享文件系统服务允许管理员授予或拒绝对租户的专用共享类型的访问权限。还可以获取有关指定专用共享类型的访问权限的信息。 + +**建议** + +```shell +由于共享类型由于其额外的规范而有助于在用户创建共享之前筛选或选择后端，因此使用对共享类型的访问权限，可以限制客户端选择特定的后端。 +``` + +例如，作为管理员租户中的管理员用户，可以创建名为 `my_type` 的专用共享类型，并在列表中查看它。在控制台示例中，省略了登录和注销，并提供了环境变量以显示当前登录的用户。 + +```shell +$ env | grep OS_ +... +OS_USERNAME=admin +OS_TENANT_NAME=admin +... +$ manila type-list --all ++----+--------+-----------+-----------+-----------------------------------+-----------------------+ +| ID | Name | Visibility| is_default| required_extra_specs | optional_extra_specs | ++----+--------+-----------+-----------+-----------------------------------+-----------------------+ +| 4..| my_type| private | - | driver_handles_share_servers:False| snapshot_support:True | +| 5..| default| public | YES | driver_handles_share_servers:True | snapshot_support:True | ++----+--------+-----------+-----------+-----------------------------------+-----------------------+ +``` + +`demo` 租户中的 `demo` 用户可以列出类型，并且命名 `my_type` 的专用共享类型对他不可见。 + +```shell +$ env | grep OS_ +... +OS_USERNAME=demo +OS_TENANT_NAME=demo +... +$ manila type-list --all ++----+--------+-----------+-----------+----------------------------------+----------------------+ +| ID | Name | Visibility| is_default| required_extra_specs | optional_extra_specs | ++----+--------+-----------+-----------+----------------------------------+----------------------+ +| 5..| default| public | YES | driver_handles_share_servers:True| snapshot_support:True| ++----+--------+-----------+-----------+----------------------------------+----------------------+ +``` + +管理员可以授予对租户 ID 等于 df29a37db5ae48d19b349fe947fada46 的演示租户的专用共享类型的访问权限： + +```shell +$ env | grep OS_ +... +OS_USERNAME=admin +OS_TENANT_NAME=admin +... +$ openstack project list ++----------------------------------+--------------------+ +| ID | Name | ++----------------------------------+--------------------+ +| ... | ... | +| df29a37db5ae48d19b349fe947fada46 | demo | ++----------------------------------+--------------------+ +$ manila type-access-add my_type df29a37db5ae48d19b349fe947fada46 +``` + +因此，现在演示租户中的用户可以看到专用共享类型，并在共享创建中使用它： + +```shell +$ env | grep OS_ +... +OS_USERNAME=demo +OS_TENANT_NAME=demo +... +$ manila type-list --all ++----+--------+-----------+-----------+-----------------------------------+-----------------------+ +| ID | Name | Visibility| is_default| required_extra_specs | optional_extra_specs | ++----+--------+-----------+-----------+-----------------------------------+-----------------------+ +| 4..| my_type| private | - | driver_handles_share_servers:False| snapshot_support:True | +| 5..| default| public | YES | driver_handles_share_servers:True | snapshot_support:True | ++----+--------+-----------+-----------+-----------------------------------+- +``` + +要拒绝对指定项目的访问，请使用 manila type-access-remove 命令。 + +**建议** + +```shell +一个真实的生产用例显示了共享类型的用途和对它们的访问，当你有两个后端时：廉价的 LVM 作为公共存储，昂贵的 Ceph 作为私有存储。在这种情况下，可以向某些租户授予访问权限，并使用 `user/group` 身份验证方法进行访问。 +``` + +### 政策 + +共享文件系统服务有自己的基于角色的访问策略。它们确定哪个用户可以以哪种方式访问哪些对象，并在服务的 `policy.json` 文件中定义。 + +**建议** + +```shell +配置文件 `policy.json` 可以放置在任何位置。默认情况下，该路径 `/etc/manila/policy.json` 是必需的。 +``` + +每当对共享文件系统服务进行 API 调用时，策略引擎都会使用相应的策略定义来确定是否可以接受该调用。 + +策略规则确定在什么情况下允许 API 调用。当 `/etc/manila/policy.json` 规则为空字符串时，该文件具有始终允许操作的规则： `""` ;基于用户角色或规则的规则;带有布尔表达式的规则。下面是共享文件系统服务 `policy.json` 的文件片段。从一个OpenStack版本到另一个OpenStack版本，可以对其进行更改。 + +```shell +{ + "context_is_admin": "role:admin", + "admin_or_owner": "is_admin:True or project_id:%(project_id)s", + "default": "rule:admin_or_owner", + "share_extension:quotas:show": "", + "share_extension:quotas:update": "rule:admin_api", + "share_extension:quotas:delete": "rule:admin_api", + "share_extension:quota_classes": "", +} +``` + +必须将用户分配到策略中引用的组和角色。当使用用户管理命令时，服务会自动完成此操作。 + +**注意** + +```shell +任何更改 `/etc/manila/policy.json` 都会立即生效，这允许在共享文件系统服务运行时实施新策略。手动修改策略可能会产生意想不到的副作用，因此不鼓励这样做。有关详细信息，请参阅 policy.json 文件。 +``` + +### 检查表 + +#### Check-Shared-01：配置文件的用户/组所有权是否设置为 root/manila？ + +配置文件包含组件平稳运行所需的关键参数和信息。如果非特权用户有意或无意地修改或删除任何参数或文件本身，则会导致严重的可用性问题，从而导致拒绝向其他最终用户提供服务。因此，此类关键配置文件的用户所有权必须设置为 root，组所有权必须设置为 manila。此外，包含目录应具有相同的所有权，以确保正确拥有新文件。 + +运行以下命令： + +```shell +$ stat -L -c "%U %G" /etc/manila/manila.conf | egrep "root manila" +$ stat -L -c "%U %G" /etc/manila/api-paste.ini | egrep "root manila" +$ stat -L -c "%U %G" /etc/manila/policy.json | egrep "root manila" +$ stat -L -c "%U %G" /etc/manila/rootwrap.conf | egrep "root manila" +$ stat -L -c "%U %G" /etc/manila | egrep "root manila" +``` + +通过：如果所有这些配置文件的用户和组所有权分别设置为 root 和 manila。上面的命令显示了根马尼拉的输出。 + +失败：如果上述命令未返回任何输出，因为用户和组所有权可能已设置为除 root 以外的任何用户或马尼拉以外的任何组。 + +#### Check-Shared-02：是否为配置文件设置了严格的权限？ + +与前面的检查类似，建议对此类配置文件设置严格的访问权限。 + +运行以下命令： + +```shell +$ stat -L -c "%a" /etc/manila/manila.conf +$ stat -L -c "%a" /etc/manila/api-paste.ini +$ stat -L -c "%a" /etc/manila/policy.json +$ stat -L -c "%a" /etc/manila/rootwrap.conf +$ stat -L -c "%a" /etc/manila +``` + +还可以进行更广泛的限制：如果包含目录设置为 750，则保证此目录中新创建的文件具有所需的权限。 + +通过：如果权限设置为 640 或更严格，或者包含目录设置为 750。640 的权限转换为所有者 r/w、组 r，而对其他人没有权限，即“u=rw，g=r，o=”。请注意，使用 Check-Shared-01：配置文件的用户/组所有权是否设置为 root/manila？权限设置为 640，root 具有读/写访问权限，manila 具有对这些配置文件的读取访问权限。也可以使用以下命令验证访问权限。仅当此命令支持 ACL 时，它才在您的系统上可用。 + +```shell +$ getfacl --tabular -a /etc/manila/manila.conf +getfacl: Removing leading '/' from absolute path names +# file: etc/manila/manila.conf +USER root rw- +GROUP manila r-- +mask r-- +other --- +``` + +失败：如果权限未设置为至少 640。 + +#### Check-Shared-03：OpenStack Identity 是否用于身份验证？ + +**注意** + +```shell +此项仅适用于 OpenStack 版本 Rocky 及之前版本，因为 `auth_strategy` Stein 中已弃用。 +``` + +OpenStack 支持各种身份验证策略，如 noauth 和 keystone。如果使用 ' `noauth` ' 策略，则用户无需任何身份验证即可与 OpenStack 服务进行交互。这可能是一个潜在的风险，因为攻击者可能会获得对 OpenStack 组件的未经授权的访问。因此，强烈建议所有服务都必须使用其服务帐户通过 keystone 进行身份验证。 + +通过：如果 section in 下的参数 `auth_strategy` 设置为 `keystone` 。 `[DEFAULT]` `manila.conf` + +失败：如果 section 下的 `[DEFAULT]` 参数 `auth_strategy` 值设置为 `noauth` 。 + +#### Check-Shared-04：是否启用了 TLS 进行身份验证？ + +OpenStack 组件使用各种协议相互通信，通信可能涉及敏感或机密数据。攻击者可能会尝试窃听频道以访问敏感信息。所有组件必须使用安全通信协议相互通信。 + +通过：如果 section in `/etc/manila/manila.conf` 下的参数值设置为 Identity API 端点开头， `https://` 并且 same `/etc/manila/manila.conf` 中同一 `[keystone_authtoken]` 部分下的 `[keystone_authtoken]` 参数 `www_authenticate_uri` `insecure` 值设置为 `False` 。 + +失败：如果 in `/etc/manila/manila.conf` 部分下的 `[keystone_authtoken]` 参数 `www_authenticate_uri` 值未设置为以 开头的身份 API 端点， `https://` 或者同一 `/etc/manila/manila.conf` 部分中的参数 `insecure` `[keystone_authtoken]` 值设置为 `True` 。 + +#### Check-Shared-05：共享文件系统是否通过 TLS 与计算联系？ + +**注意** + +```shell +此项仅适用于 OpenStack 版本 Train 及之前版本，因为 `auth_strategy` Ussuri 中已弃用。 +``` + +OpenStack 组件使用各种协议相互通信，通信可能涉及敏感或机密数据。攻击者可能会尝试窃听频道以访问敏感信息。因此，所有组件都必须使用安全的通信协议相互通信。 + +通过：如果 section in 下的参数 `nova_api_insecure` 设置为 `False` 。 `[DEFAULT]` `manila.conf` + +失败：如果 section in 下的参数 `nova_api_insecure` 设置为 `True` 。 `[DEFAULT]` `manila.conf` + +#### Check-Shared-06：共享文件系统是否通过 TLS 与网络联系？ + +**注意** + +```shell +此项仅适用于 OpenStack 版本 Train 及之前版本，因为 `auth_strategy` Ussuri 中已弃用。 +``` + +与之前的检查（Check-Shared-05：共享文件系统是否通过 TLS 与计算联系？）类似，建议所有组件必须使用安全通信协议相互通信。 + +通过：如果 section in 下的参数 `neutron_api_insecure` 设置为 `False` 。 `[DEFAULT]` `manila.conf` + +失败：如果 section in 下的参数 `neutron_api_insecure` 设置为 `True` 。 `[DEFAULT]` `manila.conf` + +#### Check-Shared-07：共享文件系统是否通过 TLS 与块存储联系？ + +**注意** + +```shell +此项仅适用于 OpenStack 版本 Train 及之前版本，因为 `auth_strategy` Ussuri 中已弃用。 +``` + +与之前的检查（Check-Shared-05：共享文件系统是否通过 TLS 与计算联系？）类似，建议所有组件必须使用安全通信协议相互通信。 + +通过：如果 section in 下的参数 `cinder_api_insecure` 设置为 `False` 。 `[DEFAULT]` `manila.conf` + +失败：如果 section in 下的参数 `cinder_api_insecure` 设置为 `True` 。 `[DEFAULT]` `manila.conf` + +#### Check-Shared-08：请求正文的最大大小是否设置为默认值 （114688）？ + +如果未定义每个请求的最大正文大小，攻击者可以构建任意较大的OSAPI请求，导致服务崩溃，最终导致拒绝服务攻击。分配最大值可确保阻止任何恶意超大请求，从而确保服务的持续可用性。 + +通过：如果 in 节下的参数值设置为 ，或者 in `manila.conf` `manila.conf` 节下的 `[oslo_middleware]` `[DEFAULT]` 参数 `max_request_body_size` `osapi_max_request_body_size` 值设置为 `114688` 。 `114688` 下面的 `[DEFAULT]` 参数 `osapi_max_request_body_size` 已弃用，最好使用 [oslo_middleware]/ `max_request_body_size` 。 + +失败：如果 in `manila.conf` 节下的参数值未设置为 `114688` ，或者 in `manila.conf` 节下的 `[DEFAULT]` `[oslo_middleware]` 参数 `max_request_body_size` `osapi_max_request_body_size` 值未设置为 `114688` 。 + +## 联网 + +OpenStack 网络服务 （neutron） 使最终用户或租户能够定义、利用和使用网络资源。OpenStack Networking 提供了一个面向租户的 API，用于定义云中实例的网络连接和 IP 寻址，以及编排网络配置。随着向以 API 为中心的网络服务的过渡，云架构师和管理员应考虑最佳实践来保护物理和虚拟网络基础架构和服务。 + +OpenStack Networking 采用插件架构设计，通过开源社区或第三方服务提供 API 的可扩展性。在评估架构设计要求时，确定 OpenStack Networking 核心服务中有哪些功能、第三方产品提供的任何其他服务以及需要在物理基础架构中实现哪些补充服务非常重要。 + +本节简要概述了在实现 OpenStack Networking 时应考虑哪些流程和最佳实践。 + +- 网络架构 + - 在物理服务器上放置 OpenStack Networking 服务 +- 网络服务 + - 使用 VLAN 和隧道的 L2 隔离 + - 网络服务 + - 网络服务扩展 + - 网络服务限制 +- 网络服务安全最佳做法 + - OpenStack Networking 服务配置 + +- 保护 OpenStack 网络服务 + - 项目网络服务工作流程 + - 网络资源策略引擎 + - 安全组 + - 配额 + - 缓解 ARP 欺骗 + +- 检查表 + - Check-Neutron-01：配置文件的用户/组所有权是否设置为 root/neutron？ + - Check-Neutron-02：是否为配置文件设置了严格的权限？ + - Check-Neutron-03：Keystone是否用于身份验证？ + - Check-Neutron-04：是否使用安全协议进行身份验证？ + - Check-Neutron-05：Neutron API 服务器上是否启用了 TLS？ + +### 网络架构 + +OpenStack Networking 是一个独立的服务，通常在多个节点上部署多个进程。这些进程彼此交互，并与其他 OpenStack 服务交互。OpenStack Networking 服务的主要进程是 neutron-server，这是一个 Python 守护进程，它公开 OpenStack Networking API，并将租户请求传递给一组插件进行额外处理。 + +OpenStack Networking 组件包括： + +neutron 服务器（neutron-server 和 neutron-*-plugin） + +此服务在网络节点上运行，为网络 API 及其扩展提供服务。它还强制执行每个端口的网络模型和 IP 寻址。neutron-server 需要间接访问持久性数据库。这是通过插件实现的，插件使用 AMQP（高级消息队列协议）与数据库进行通信。 + +插件代理 （neutron-*-agent） + +在每个计算节点上运行，以管理本地虚拟交换机 （vswitch） 配置。您使用的插件决定了运行哪些代理。此服务需要消息队列访问，并取决于所使用的插件。一些插件，如 OpenDaylight（ODL） 和开放虚拟网络 （OVN），在计算节点上不需要任何 python 代理。 + +DHCP 代理 （neutron-dhcp-agent） + +为租户网络提供DHCP服务。此代理在所有插件中都是相同的，并负责维护 DHCP 配置。neutron-dhcp-agent 需要消息队列访问。可选，具体取决于插件。 + +L3 代理（neutron-L3-agent） + +为租户网络上的虚拟机提供 L3/NAT 转发。需要消息队列访问权限。可选，具体取决于插件。 + +网络提供商服务（SDN 服务器/服务） + +为租户网络提供其他网络服务。这些 SDN 服务可以通过 REST API 等通信通道与 neutron-server、neutron-plugin 和 plugin-agents 进行交互。 + +下图显示了 OpenStack Networking 组件的架构和网络流程图： + +[![../_images/sdn-connections.png](https://docs.openstack.org/security-guide/_images/sdn-connections.png)](https://docs.openstack.org/security-guide/_images/sdn-connections.png) + +#### OpenStack Networking 服务在物理服务器上的放置 + +本指南重点介绍一个标准架构，其中包括一个云控制器主机、一个网络主机和一组用于运行 VM 的计算虚拟机监控程序。 + +##### 物理服务器的网络连接 + +[![../_images/1aa-network-domains-diagram.png](https://docs.openstack.org/security-guide/_images/1aa-network-domains-diagram.png)](https://docs.openstack.org/security-guide/_images/1aa-network-domains-diagram.png) + +标准的 OpenStack Networking 设置最多有四个不同的物理数据中心网络： + +- 管理网络 + + 用于 OpenStack 组件之间的内部通信。此网络上的 IP 地址应只能在数据中心内访问，并被视为管理安全域。 + +- 访客网络 + + 用于云部署中的 VM 数据通信。此网络的 IP 寻址要求取决于所使用的 OpenStack Networking 插件以及租户对虚拟网络所做的网络配置选择。此网络被视为客户机安全域。 + +- 外部网络 + + 用于在某些部署方案中为 VM 提供 Internet 访问权限。Internet 上的任何人都可以访问此网络上的 IP 地址。此网络被视为属于公共安全域。 + +- API网络 + + 向租户公开所有 OpenStack API，包括 OpenStack 网络 API。Internet 上的任何人都可以访问此网络上的 IP 地址。这可能与外部网络是同一网络，因为可以为使用 IP 分配范围的外部网络创建一个子网，以便仅使用 IP 块中小于全部范围的 IP 地址。此网络被视为公共安全域。 + +有关更多信息，请参阅《OpenStack 管理员指南》。 + +### 网络服务 + +在设计 OpenStack 网络基础架构的初始架构阶段，确保提供适当的专业知识来协助设计物理网络基础架构，确定适当的安全控制和审计机制非常重要。 + +OpenStack Networking 增加了一层虚拟化网络服务，使租户能够构建自己的虚拟网络。目前，这些虚拟化服务还没有传统网络的成熟。在采用这些虚拟化服务之前，请考虑这些服务的当前状态，因为它决定了您可能需要在虚拟化和传统网络边界上实现哪些控制。 + +#### 使用 VLAN 和隧道的 L2 隔离 + +OpenStack Networking 可以采用两种不同的机制对每个租户/网络组合进行流量隔离：VLAN（IEEE 802.1Q 标记）或使用 GRE 封装的 L2 隧道。OpenStack 部署的范围和规模决定了您应该使用哪种方法进行流量隔离或隔离。 + +##### VLANs + +VLAN 在特定物理网络上实现为数据包，其中包含具有特定 VLAN ID （VID） 字段值的 IEEE 802.1Q 标头。共享同一物理网络的 VLAN 网络在 L2 上彼此隔离，甚至可以有重叠的 IP 地址空间。每个支持 VLAN 网络的不同物理网络都被视为一个单独的 VLAN 中继，具有不同的 VID 值空间。有效的 VID 值为 1 到 4094。 + +VLAN 配置的复杂性取决于您的 OpenStack 设计要求。为了让 OpenStack Networking 能够有效地使用 VLAN，您必须分配一个 VLAN 范围（每个租户一个），并将每个计算节点物理交换机端口转换为 VLAN 中继端口。 + +**注意** + +```shell +如果您打算让您的网络支持超过 4094 个租户，则 VLAN 可能不是您的正确选择，因为需要多个“黑客”才能将 VLAN 标记扩展到超过 4094 个租户。 +``` + +##### L2 隧道 + +网络隧道使用唯一的“tunnel-id”封装每个租户/网络组合，该 ID 用于标识属于该组合的网络流量。租户的 L2 网络连接与物理位置或基础网络设计无关。通过将流量封装在 IP 数据包中，该流量可以跨越第 3 层边界，无需预配置 VLAN 和 VLAN 中继。隧道为网络数据流量增加了一层混淆，从监控的角度降低了单个租户流量的可见性。 + +OpenStack Networking 目前支持 GRE 和 VXLAN 封装。 + +提供 L2 隔离的技术选择取决于将在部署中创建的租户网络的范围和大小。如果您的环境的 VLAN ID 可用性有限或将具有大量 L2 网络，我们建议您使用隧道。 + +#### 网络服务 + +租户网络隔离的选择会影响租户服务的网络安全和控制边界的实现方式。以下附加网络服务已经可用或目前正在开发中，以增强 OpenStack 网络架构的安全态势。 + +##### 访问控制列表 + +OpenStack 计算在与旧版 nova-network 服务一起部署时直接支持租户网络流量访问控制，或者可以将访问控制推迟到 OpenStack Networking 服务。 + +请注意，旧版 nova-network 安全组使用 iptables 应用于实例上的所有虚拟接口端口。 + +安全组允许管理员和租户指定流量类型以及允许通过虚拟接口端口的方向（入口/出口）。安全组规则是有状态的 L2-L4 流量过滤器。 + +使用网络服务时，建议在此服务中启用安全组，并在计算服务中禁用安全组。 + +##### L3 路由和 NAT + +OpenStack Networking 路由器可以连接多个 L2 网络，并且还可以提供连接一个或多个私有 L2 网络到共享外部网络（例如用于访问互联网的公共网络）的网关。 + +L3 路由器在将路由器上行链路到外部网络的网关端口上提供基本的网络地址转换 （NAT） 功能。默认情况下，此路由器会 SNAT（静态 NAT）所有流量，并支持浮动 IP，这会创建从外部网络上的公共 IP 到连接到路由器的其他子网上的专用 IP 的静态一对一映射。 + +我们建议利用每个租户的 L3 路由和浮动 IP 来实现租户 VM 的更精细连接。 + +##### 服务质量 （QoS） + +默认情况下，服务质量 （QoS） 策略和规则由云管理员管理，这会导致租户无法创建特定的 QoS 规则，也无法将特定端口附加到策略。在某些用例中，例如某些电信应用程序，管理员可能信任租户，因此允许他们创建自己的策略并将其附加到端口。这可以通过修改 `policy.json` 文件和特定文档来实现。将与扩展一起发布。 + +网络服务 （neutron） 支持 Liberty 及更高版本中的带宽限制 QoS 规则。此 QoS 规则已命名 `QosBandwidthLimitRule` ，它接受两个非负整数，以千比特/秒为单位： + +- `max-kbps` ：带宽 +- `max-burst-kbps` ：突发缓冲区 + +已 `QoSBandwidthLimitRule` 在 neutron Open vSwitch、Linux 网桥和单根输入/输出虚拟化 （SR-IOV） 驱动程序中实现。 + +在 Newton 中，添加了 QoS 规则 `QosDscpMarkingRule` 。此规则在 IPv4 （RFC 2474） 上的服务标头类型和 IPv6 上的流量类标头中标记差分服务代码点 （DSCP） 值，这些值适用于应用规则的虚拟机的所有流量。这是一个 6 位标头，具有 21 个有效值，表示数据包在遇到拥塞时穿过网络时的丢弃优先级。防火墙还可以使用它来将有效或无效流量与其访问控制列表进行匹配。 + +端口镜像服务涉及将进入或离开一个端口的数据包副本发送到另一个端口，该端口通常与被镜像数据包的原始目的地不同。Tap-as-a-Service （TaaS） 是 OpenStack 网络服务 （neutron） 的扩展。它为租户虚拟网络提供远程端口镜像功能。此服务主要旨在帮助租户（或云管理员）调试复杂的虚拟网络，并通过监视与其关联的网络流量来了解其 VM。TaaS 遵循租户边界，其镜像会话能够跨越多个计算和网络节点。它是一个必不可少的基础设施组件，可用于向各种网络分析和安全应用程序提供数据。 + +##### 负载均衡 + +OpenStack Networking 的另一个特性是负载均衡器即服务 （LBaaS）。LBaaS 参考实现基于 HA-Proxy。OpenStack Networking 中的扩展正在开发第三方插件，以便为虚拟接口端口提供广泛的 L4-L7 功能。 + +##### 防火墙 + +FW-as-a-Service（FWaaS）被认为是OpenStack Networking的Kilo版本的实验性功能。FWaaS 满足了管理和利用典型防火墙产品提供的丰富安全功能的需求，这些产品通常比当前安全组提供的要全面得多。飞思卡尔和英特尔都开发了第三方插件作为OpenStack Networking的扩展，以在Kilo版本中支持此组件。有关 FWaaS 管理的更多详细信息，请参阅《OpenStack 管理员指南》中的防火墙即服务 （FWaaS） 概述。 + +在设计 OpenStack Networking 基础架构时，了解可用网络服务的当前特性和局限性非常重要。了解虚拟网络和物理网络的边界将有助于在您的环境中添加所需的安全控件。 + +#### 网络服务扩展 + +开源社区或使用 OpenStack Networking 的 SDN 公司提供的已知插件列表可在 OpenStack neutron 插件和驱动程序 wiki 页面上找到。 + +#### 网络服务限制 + +OpenStack Networking 具有以下已知限制： + +重叠的 IP 地址 + +如果运行 neutron-l3-agent 或 neutron-dhcp-agent 的节点使用重叠的 IP 地址，则这些节点必须使用 Linux 网络命名空间。默认情况下，DHCP 和 L3 代理使用 Linux 网络命名空间，并在各自的命名空间中运行。但是，如果主机不支持多个命名空间，则 DHCP 和 L3 代理应在不同的主机上运行。这是因为 L3 代理和 DHCP 代理创建的 IP 地址之间没有隔离。 + +如果不存在网络命名空间支持，则 L3 代理的另一个限制是仅支持单个逻辑路由器。 + +多主机 DHCP 代理 + +OpenStack Networking 支持多个具有负载均衡功能的 L3 和 DHCP 代理。但是，不支持虚拟机位置的紧密耦合。换言之，在创建虚拟机时，默认虚拟机调度程序不会考虑代理的位置。 + +L3 代理不支持 IPv6 + +neutron-l3-agent 被许多插件用于实现 L3 转发，仅支持 IPv4 转发。 + +### 网络服务安全最佳做法 + +要保护 OpenStack Networking，您必须了解如何将租户实例创建的工作流过程映射到安全域。 + +有四个主要服务与 OpenStack Networking 交互。在典型的 OpenStack 部署中，这些服务映射到以下安全域： + +- OpenStack 仪表板：公共和管理 +- OpenStack Identity：管理 +- OpenStack 计算节点：管理和客户端 +- OpenStack 网络节点：管理、客户端，以及可能的公共节点，具体取决于正在使用的 neutron-plugin。 +- SDN 服务节点：管理、访客和可能的公共服务，具体取决于使用的产品。 + +[![../_images/1aa-logical-neutron-flow.png](https://docs.openstack.org/security-guide/_images/1aa-logical-neutron-flow.png)](https://docs.openstack.org/security-guide/_images/1aa-logical-neutron-flow.png) + +要隔离 OpenStack Networking 服务与其他 OpenStack 核心服务之间的敏感数据通信，请将这些通信通道配置为仅允许通过隔离的管理网络进行通信。 + +#### OpenStack Networking 服务配置 + +##### 限制 API 服务器的绑定地址：neutron-server + +要限制 OpenStack Networking API 服务为传入客户端连接绑定网络套接字的接口或 IP 地址，请在 neutron.conf 文件中指定 bind_host 和 bind_port，如下所示： + +```shell +# Address to bind the API server +bind_host = IP ADDRESS OF SERVER + +# Port the bind the API server to +bind_port = 9696 +``` + +##### 限制 OpenStack Networking 服务的 DB 和 RPC 通信 + +OpenStack Networking 服务的各种组件使用消息队列或数据库连接与 OpenStack Networking 中的其他组件进行通信。 + +对于需要直接数据库连接的所有组件，建议您遵循数据库身份验证和访问控制中提供的准则。 + +建议您遵循队列身份验证和访问控制中提供的准则，适用于需要 RPC 通信的所有组件。 + +### 保护 OpenStack 网络服务 + +本节讨论 OpenStack Networking 配置最佳实践，因为它们适用于 OpenStack 部署中的项目网络安全。 + +#### 项目网络服务工作流 + +OpenStack Networking 为用户提供网络资源和配置的自助服务。云架构师和运维人员必须评估其设计用例，以便为用户提供创建、更新和销毁可用网络资源的能力。 + +#### 网络资源策略引擎 + +OpenStack Networking 中的策略引擎及其配置文件 `policy.json` 提供了一种方法，可以对用户在项目网络方法和对象上提供更细粒度的授权。OpenStack Networking 策略定义会影响网络可用性、网络安全和整体 OpenStack 安全性。云架构师和运维人员应仔细评估其对用户和项目访问网络资源管理的策略。有关 OpenStack Networking 策略定义的更详细说明，请参阅《OpenStack 管理员指南》中的“身份验证和授权”部分。 + +**注意** + +```shell +请务必查看默认网络资源策略，因为可以修改此策略以适合您的安全状况。 +``` + +如果您的 OpenStack 部署为不同的安全域提供了多个外部访问点，那么限制项目将多个 vNIC 连接到多个外部访问点的能力非常重要，这将桥接这些安全域，并可能导致不可预见的安全危害。通过利用 OpenStack Compute 提供的主机聚合功能，或者将项目虚拟机拆分为具有不同虚拟网络配置的多个项目项目，可以降低这种风险。 + +#### 安全组 + +OpenStack Networking 服务使用比 OpenStack Compute 中内置的安全组功能更灵活、更强大的机制提供安全组功能。因此，在使用 OpenStack Network 时，应始终禁用内置安全组， `nova.conf` 并将所有安全组调用代理到 OpenStack Networking API。如果不这样做，将导致两个服务同时应用冲突的安全策略。要将安全组代理到 OpenStack Networking，请使用以下配置值： + +- `firewall_driver` 必须设置为 `nova.virt.firewall.NoopFirewallDriver` ，以便 nova-compute 本身不执行基于 iptables 的过滤。 +- `security_group_api` 必须设置为 `neutron` 以便将所有安全组请求代理到 OpenStack Networking 服务。 + +安全组是安全组规则的容器。安全组及其规则允许管理员和项目指定允许通过虚拟接口端口的流量类型和方向（入口/出口）。在 OpenStack Networking 中创建虚拟接口端口时，该端口与安全组相关联。有关端口安全组默认行为的更多详细信息，请参阅网络安全组行为文档。可以将规则添加到默认安全组，以便根据每个部署更改行为。 + +使用 OpenStack Compute API 修改安全组时，更新后的安全组将应用于实例上的所有虚拟接口端口。这是因为 OpenStack Compute 安全组 API 是基于实例的，而不是基于端口的，如 OpenStack Networking 中所示。 + +#### 配额 + +配额提供了限制项目可用的网络资源数量的功能。您可以对所有项目强制实施默认配额。包括 `/etc/neutron/neutron.conf` 以下配额选项： + +```shell +[QUOTAS] +# resource name(s) that are supported in quota features +quota_items = network,subnet,port + +# default number of resource allowed per tenant, minus for unlimited +#default_quota = -1 + +# number of networks allowed per tenant, and minus means unlimited +quota_network = 10 + +# number of subnets allowed per tenant, and minus means unlimited +quota_subnet = 10 + +# number of ports allowed per tenant, and minus means unlimited +quota_port = 50 + +# number of security groups allowed per tenant, and minus means unlimited +quota_security_group = 10 + +# number of security group rules allowed per tenant, and minus means unlimited +quota_security_group_rule = 100 + +# default driver to use for quota checks +quota_driver = neutron.quota.ConfDriver +``` + +OpenStack Networking 还通过配额扩展 API 支持每个项目的配额限制。要启用每个项目的配额，必须在 中设置选项 `quota_driver` `neutron.conf` 。 + +```shell +quota_driver = neutron.db.quota.driver.DbQuotaDriver +``` + +#### 缓解 ARP 欺骗 + +使用扁平网络时，不能假定共享同一第 2 层网络（或广播域）的项目彼此完全隔离。这些项目可能容易受到 ARP 欺骗的攻击，从而有可能遭受中间人攻击。 + +如果使用支持 ARP 字段匹配的 Open vSwitch 版本，则可以通过启用 Open vSwitch 代理 `prevent_arp_spoofing` 选项来帮助降低此风险。此选项可防止实例执行欺骗攻击;它不能保护他们免受欺骗攻击。请注意，此设置预计将在 Ocata 中删除，该行为将永久处于活动状态。 + +例如，在 `/etc/neutron/plugins/ml2/openvswitch_agent.ini` ： + +```shell +prevent_arp_spoofing = True +``` + +除 Open vSwitch 外，其他插件也可能包含类似的缓解措施;建议您在适当的情况下启用此功能。 + +**注意** + +```shell +即使启用 `prevent_arp_spoofing` 了扁平网络，也无法提供完整的项目隔离级别，因为所有项目流量仍会发送到同一 VLAN。 +``` + +### 检查表 + +#### Check-Neutron-01：配置文件的用户/组所有权是否设置为 root/neutron？ + +配置文件包含组件平稳运行所需的关键参数和信息。如果非特权用户有意或无意地修改或删除任何参数或文件本身，则会导致严重的可用性问题，从而导致对其他最终用户的拒绝服务。因此，此类关键配置文件的用户所有权必须设置为 root，组所有权必须设置为 neutron。此外，包含目录应具有相同的所有权，以确保正确拥有新文件。 + +运行以下命令： + +```shell +$ stat -L -c "%U %G" /etc/neutron/neutron.conf | egrep "root neutron" +$ stat -L -c "%U %G" /etc/neutron/api-paste.ini | egrep "root neutron" +$ stat -L -c "%U %G" /etc/neutron/policy.json | egrep "root neutron" +$ stat -L -c "%U %G" /etc/neutron/rootwrap.conf | egrep "root neutron" +$ stat -L -c "%U %G" /etc/neutron | egrep "root neutron" +``` + +通过：如果所有这些配置文件的用户和组所有权分别设置为 root 和 neutron。上面的命令显示了根中子的输出。 + +失败：如果上述命令未返回任何输出，因为用户和组所有权可能已设置为除 root 以外的任何用户或除 neutron 以外的任何组。 + +#### Check-Neutron-02：是否为配置文件设置了严格的权限？ + +与前面的检查类似，建议对此类配置文件设置严格的访问权限。 + +运行以下命令： + +```shell +$ stat -L -c "%a" /etc/neutron/neutron.conf +$ stat -L -c "%a" /etc/neutron/api-paste.ini +$ stat -L -c "%a" /etc/neutron/policy.json +$ stat -L -c "%a" /etc/neutron/rootwrap.conf +$ stat -L -c "%a" /etc/neutron +``` + +还可以进行更广泛的限制：如果包含目录设置为 750，则保证此目录中新创建的文件具有所需的权限。 + +通过：如果权限设置为 640 或更严格，或者包含目录设置为 750。640 的权限转换为所有者 r/w、组 r，而对其他人没有权限，即“u=rw，g=r，o=”。 + +请注意，使用 Check-Neutron-01：配置文件的用户/组所有权是否设置为 root/neutron？权限设置为 640，root 具有读/写访问权限，neutron 具有对这些配置文件的读取访问权限。也可以使用以下命令验证访问权限。仅当此命令支持 ACL 时，它才在您的系统上可用。 + +```shell +$ getfacl --tabular -a /etc/neutron/neutron.conf +getfacl: Removing leading '/' from absolute path names +# file: etc/neutron/neutron.conf +USER root rw- +GROUP neutron r-- +mask r-- +other --- +``` + +失败：如果权限没有设置至少为640。 + +#### Check-Neutron-03：Keystone是否用于身份验证？ + +**注意** + +```shell +此项仅适用于 OpenStack 版本 Rocky 及之前版本，因为 `auth_strategy` Stein 中已弃用。 +``` + +OpenStack 支持各种身份验证策略，如 noauth、keystone 等。如果使用“noauth”策略，那么用户无需任何身份验证即可与OpenStack服务进行交互。这可能是一个潜在的风险，因为攻击者可能会获得对 OpenStack 组件的未经授权的访问。因此，强烈建议所有服务都必须使用其服务帐户通过 keystone 进行身份验证。 + +通过：如果 section in 下的参数 `auth_strategy` 设置为 `keystone` 。 `[DEFAULT]` `/etc/neutron/neutron.conf` + +失败：如果 section 下的 `[DEFAULT]` 参数 `auth_strategy` 值设置为 `noauth` 或 `noauth2` 。 + +#### Check-Neutron-04：是否使用安全协议进行身份验证？ + +OpenStack 组件使用各种协议相互通信，通信可能涉及敏感/机密数据。攻击者可能会尝试窃听频道以访问敏感信息。因此，所有组件都必须使用安全的通信协议相互通信。 + +通过：如果 section in `/etc/neutron/neutron.conf` 下的参数值设置为 Identity API 端点开头， `https://` 并且 same `/etc/neutron/neutron.conf` 中同一 `[keystone_authtoken]` 部分下的 `[keystone_authtoken]` 参数 `www_authenticate_uri` `insecure` 值设置为 `False` 。 + +失败：如果 in `/etc/neutron/neutron.conf` 部分下的 `[keystone_authtoken]` 参数 `www_authenticate_uri` 值未设置为以 开头的身份 API 端点， `https://` 或者同一 `/etc/neutron/neutron.conf` 部分中的参数 `insecure` `[keystone_authtoken]` 值设置为 `True` 。 + +#### Check-Neutron-05：Neutron API 服务器上是否启用了 TLS？ + +与之前的检查类似，建议在 API 服务器上启用安全通信。 + +通过：如果 section in 下的参数 `use_ssl` 设置为 `True` 。 `[DEFAULT]` `/etc/neutron/neutron.conf` + +失败：如果 section in 下的参数 `use_ssl` 设置为 `False` 。 `[DEFAULT]` `/etc/neutron/neutron.conf` + +## 对象存储 + +OpenStack 对象存储 （swift） 服务提供通过 HTTP 存储和检索数据的软件。对象（数据 blob）存储在组织层次结构中，该层次结构提供匿名只读访问、ACL 定义的访问，甚至临时访问。对象存储支持通过中间件实现的多种基于令牌的身份验证机制。 + +应用程序通过行业标准的 HTTP RESTful API 在对象存储中存储和检索数据。对象存储的后端组件遵循相同的 RESTful 模型，尽管某些 API（例如管理持久性的 API）对集群是私有的。有关 API 的更多详细信息，请参阅 OpenStack Storage API。 + +对象存储的组件分为以下主要组： + +1. 代理服务 +2. 身份验证服务 +3. 存储服务 + - 账户服务 + - 容器服务 + - 对象服务 + +[![_images/swift_network_diagram-1.png](https://docs.openstack.org/security-guide/_images/swift_network_diagram-1.png)](https://docs.openstack.org/security-guide/_images/swift_network_diagram-1.png) + +OpenStack 对象存储管理指南 （2013） 中的示例图 + +**注意** + +```shell +对象存储安装不必位于 Internet 上，也可以是私有云，其中公共交换机是组织内部网络基础架构的一部分。 +``` + +### 网络安全 + +要保护对象存储服务，首先要保护网络组件。如果您跳过了网络章节，请返回到网络部分。 + +rsync 协议用于在存储服务节点之间复制数据以实现高可用性。此外，在客户端端点和云环境之间来回中继数据时，代理服务会与存储服务进行通信。 + +**警告** + +```shell +对象存储不对节点间通信进行加密或身份验证。这就是您在体系结构图中看到专用交换机或专用网络 （[V]LAN） 的原因。这个数据域也应该与其他OpenStack数据网络分开。有关安全域的进一步讨论，请参阅安全边界和威胁。 +``` + +**建议** + +```shell +对数据域中的存储节点使用专用 （V）LAN 网段。 +``` + +这需要代理节点具有双接口（物理或虚拟）： + +1. 一个作为消费者访问的公共界面。 +2. 另一个作为可以访问存储节点的专用接口。 + +下图演示了一种可能的网络体系结构。 + +[![_images/swift_network_diagram-2.png](https://docs.openstack.org/security-guide/_images/swift_network_diagram-2.png)](https://docs.openstack.org/security-guide/_images/swift_network_diagram-2.png) + +具有管理节点（OSAM）的对象存储网络架构 + +### 一般服务安全 + +#### 以非 root 用户身份运行服务 + +我们建议您将对象存储服务配置为在非 root （UID 0） 服务帐户下运行。一个建议是 `swift` 具有主组 `swift` 的用户名。例如， `proxy-server` 对象存储服务包括、、 `container-server` `account-server` 。有关设置和配置的详细步骤，请参阅《安装指南》的“添加对象存储”一章的 OpenStack 文档索引。 + +**注意** + +```shell +上面的链接默认为Ubuntu版本。 +``` + +##### 文件权限 + +该 `/etc/swift` 目录包含有关环形拓扑和环境配置的信息。建议使用以下权限： + +```shell +# chown -R root:swift /etc/swift/* +# find /etc/swift/ -type f -exec chmod 640 {} \; +# find /etc/swift/ -type d -exec chmod 750 {} \; +``` + +这将限制只有 root 用户能够修改配置文件，同时允许服务通过其 `swift` 在组中的组成员身份读取它们。 + +#### 保护存储服务 + +以下是各种存储服务的默认侦听端口： + +| 服务名称 | 港口 | 类型 | +| -------- | ---- | ---- | +| 账户服务 | 6002 | TCP | +| 容器服务 | 6001 | TCP | +| 对象服务 | 6000 | TCP | +| 同步 [1] | 873 | TCP | + +如果使用 ssync 而不是 rsync，则使用对象服务端口来维护持久性。 + +**重要** + +```shell +在存储节点上不进行身份验证。如果能够在其中一个端口上连接到存储节点，则无需身份验证即可访问或修改数据。为了防止此问题，您应该遵循之前给出的有关使用专用存储网络的建议。 +``` + +##### 对象存储帐户术语 + +对象存储帐户不是用户帐户或凭据。下面对这些关系进行说明： + +| 对象存储帐户 | 容器的收集;不是用户帐户或身份验证。哪些用户与该帐户相关联以及他们如何访问该帐户取决于所使用的身份验证系统。请参阅对象存储身份验证。 | +| ------------ | ------------------------------------------------------------ | +| 对象存储容器 | 对象的集合。容器上的元数据可用于 ACL。ACL 的含义取决于所使用的身份验证系统。 | +| 对象存储对象 | 实际数据对象。对象级别的 ACL 也可以与元数据一起使用，并且取决于所使用的身份验证系统。 | + +在每个级别，您都有 ACL，用于指示谁拥有哪种类型的访问权限。ACL 是根据正在使用的身份验证系统进行解释的。最常用的两种身份验证提供程序类型是 Identity service （keystone） 和 TempAuth。自定义身份验证提供程序也是可能的。有关更多信息，请参阅对象存储身份验证。 + +#### 保护代理服务 + +代理节点应至少具有两个接口（物理或虚拟）：一个公共接口和一个专用接口。防火墙或服务绑定可能会保护公共接口。面向公众的服务是一个 HTTP Web 服务器，用于处理端点客户端请求、对其进行身份验证并执行相应的操作。专用接口不需要任何侦听服务，而是用于建立与专用存储网络上的存储节点的传出连接。 + +##### HTTP 监听端口 + +如前所述，您应该将 Web 服务配置为非 root（无 UID 0）用户 `swift` 。需要使用大于 1024 的端口才能轻松完成此操作，并避免以 root 身份运行 Web 容器的任何部分。通常，使用 HTTP REST API 并执行身份验证的客户端会自动从身份验证响应中检索所需的完整 REST API URL。OpenStack 的 REST API 允许客户端对一个 URL 进行身份验证，然后被告知对实际服务使用完全不同的 URL。例如，客户端向 进行身份验证，并获取其身份验证密钥和存储 URL（代理节点或负载均衡器的 URL） 响应。 + +将 Web 服务器配置为以非 root 用户身份启动和运行的方法因 Web 服务器和操作系统而异。 + +##### 负载均衡器 + +如果使用 Apache 的选项不可行，或者为了提高性能，您希望减轻 TLS 工作，则可以使用专用的网络设备负载平衡器。这是在使用多个代理节点时提供冗余和负载平衡的常用方法。 + +如果选择卸载 TLS，请确保负载均衡器和代理节点之间的网络链路位于专用 （V）LAN 网段上，以便网络上的其他节点（可能已泄露）无法窃听（嗅探）未加密的流量。如果发生此类违规行为，攻击者可以访问端点客户端或云管理员凭据并访问云数据。 + +您使用的身份验证服务（例如身份服务（keystone）或TempAuth）将决定如何在对端点客户端的响应中配置不同的URL，以便它们使用负载平衡器而不是单个代理节点。 + +#### 对象存储身份验证 + +对象存储使用 WSGI 模型来提供中间件功能，该功能不仅提供通用可扩展性，还用于端点客户端的身份验证。身份验证提供程序定义存在的角色和用户类型。有些使用传统的用户名和密码凭据，而另一些则可能利用 API 密钥令牌甚至客户端 x.509 证书。自定义提供程序可以集成到使用自定义中间件中。 + +对象存储默认自带两个认证中间件模块，其中任何一个模块都可以作为开发自定义认证中间件的示例代码。 + +##### TempAuth 函数 + +TempAuth 是对象存储的默认身份验证。与 Identity 相比，它将用户帐户、凭据和元数据存储在对象存储本身中。有关更多信息，请参阅对象存储 （swift） 文档的身份验证系统部分。 + +##### Keystone + +Keystone 是 OpenStack 中常用的身份提供程序。它还可用于对象存储中的身份验证。Identity 中已提供保护 keystone 的覆盖范围。 + +#### 其他值得注意的事项 + +在 中 `/etc/swift` ，在每个节点上，都有一个设置和一个 `swift_hash_path_prefix` `swift_hash_path_suffix` 设置。提供这些是为了减少存储对象发生哈希冲突的可能性，并避免一个用户覆盖另一个用户的数据。 + +此值最初应使用加密安全的随机数生成器进行设置，并在所有节点上保持一致。确保它受到适当的 ACL 保护，并且您有备份副本以避免数据丢失。 + +## 机密管理 + +操作员通过使用各种加密应用程序来保护云部署中的敏感信息。例如，对静态数据进行加密或对映像进行签名以证明其未被篡改。在所有情况下，这些加密功能都需要某种密钥材料才能运行。 + +机密管理描述了一组旨在保护软件系统中的关键材料的技术。传统上，密钥管理涉及硬件安全模块 （HSM） 的部署。这些设备已经过物理强化，可防止篡改。 + +随着技术的进步，需要保护的秘密物品的数量已经从密钥材料增加到包括证书对、API 密钥、系统密码、签名密钥等。这种增长产生了对更具可扩展性的密钥管理方法的需求，并导致创建了许多提供可扩展动态密钥管理的软件服务。本章介绍了目前存在的服务，并重点介绍了那些能够集成到OpenStack云中的服务。 + +- 现有技术摘要 +- 相关 Openstack 项目 +- 使用案例 + - 镜像签名验证 + - 卷加密 + - 临时磁盘加密 + - Sahara + - Magnum + - Octavia/LBaaS + - Swift + - 配置文件中的密码 +- Barbican + - 概述 + - 加密插件 + - 简单的加密插件 + - PKCS#11加密插件 + - 密钥商店插件 + - KMIP插件 + - Dogtag 插件 + - Vault 插件 +- Castellan + - 概述 +- 常见问题解答 +- 检查表 + - Check-Key-Manager-01：配置文件的所有权是否设置为 root/barbican？ + - Check-Key-Manager-02：是否为配置文件设置了严格的权限？ + - Check-Key-Manager-03：OpenStack Identity 是否用于身份验证？ + - Check-Key-Manager-04：是否启用了 TLS 进行身份验证？ + +### 现有技术摘要 + +在OpenStack中，有两种推荐用于机密管理的解决方案，即Barbican和Castellan。本章将概述不同的方案，以帮助操作员选择使用哪个密钥管理器。 + +第三种不受支持的方法是固定/硬编码密钥。众所周知，某些 OpenStack 服务可以选择在其配置文件中指定密钥。这是最不安全的操作方式，我们不建议在任何类型的生产环境中使用。 + +其他解决方案包括 KeyWhiz、Confidant、Conjur、EJSON、Knox 和 Red October，但在本文档的讨论范围之外，无法涵盖所有可用的 Key Manager。 + +对于机密的存储，强烈建议使用硬件安全模块 （HSM） 。HSM 可以有多种形式。传统设备是机架式设备，如以下博客文章中所示。 + +### 相关 Openstack 项目 + +Castellan 是一个库，它提供了一个简单的通用接口来存储、生成和检索机密。大多数 Openstack 服务都使用它进行机密管理。作为一个图书馆，Castellan 本身并不提供秘密存储。相反，需要部署后端实现。 + +请注意，Castellan 不提供任何身份验证。它只是通过身份验证凭据（例如Keystone令牌）传递到后端。 + +Barbican 是一个 OpenStack 服务，为 Castellan 提供后端。Barbican 需要并验证 keystone 身份验证令牌，以识别访问或存储密钥的用户和项目。然后，它应用策略来确定是否允许访问。它还提供了许多额外的有用功能来改进密钥管理，包括配额、每个密钥的 ACL、跟踪密钥使用者以及密钥容器中的密钥分组。例如，明锐直接与巴比肯（而不是卡斯特拉兰）集成，以利用其中一些功能。 + +Barbican 有许多后端插件，可用于将机密安全地存储在本地数据库或 HSM 中。 + +目前，Barbican 是 Castellan 唯一可用的后端。然而，有几个后端正在开发中，包括 KMIP、Dogtag、Hashicorp Vault 和 Custodia。对于那些不希望部署 Barbican 并且密钥管理需求相对简单的部署人员来说，使用这些后端之一可能是一个可行的替代方案。但是，在检索密钥时，缺少的是多租户和租户策略的实施，以及上面提到的任何额外功能。 + +### 使用案例 + +#### 镜像签名验证 + +验证镜像签名可确保镜像自原始上传以来不会被替换或更改。镜像签名验证功能使用 Castellan 作为其密钥管理器来存储加密签名。镜像签名和证书 UUID 将与镜像一起上传到镜像 （glance） 服务。Glance 在从密钥管理器检索证书后验证签名。启动镜像时，计算服务 （nova） 在从密钥管理器检索证书后验证签名。 + +有关更多详细信息，请参阅可信映像文档。 + +#### 卷加密 + +卷加密功能使用 Castellan 提供静态数据加密。当用户创建加密卷类型并使用该类型创建卷时，块存储 （cinder） 服务会请求密钥管理器创建要与该卷关联的密钥。当卷附加到实例时，nova 会检索密钥。 + +有关详细信息，请参阅数据加密部分。和卷加密。 + +#### 临时磁盘加密 + +临时磁盘加密功能可解决数据隐私问题。临时磁盘是虚拟主机操作系统使用的临时工作空间。如果不加密，可以在此磁盘上访问敏感的用户信息，并且在卸载磁盘后可能会保留残留信息。 + +临时磁盘加密功能可以通过安全包装器与密钥管理服务交互，并通过按租户提供临时磁盘加密密钥来支持数据隔离。建议使用后端密钥存储以增强安全性（例如，HSM 或 KMIP 服务器可用作 barbican 后端密钥存储）。 + +有关详细信息，请参阅临时磁盘加密文档。 + +#### Sahara + +Sahara在操作过程中生成并存储多个密码。为了加强Sahara对密码的使用，可以指示它使用外部密钥管理器来存储和检索这些密钥。要启用此功能，必须首先在堆栈中部署一个 OpenStack Key Manager 服务。 + +在堆栈上部署密钥管理器服务后，必须将 sahara 配置为启用密钥的外部存储。Sahara 使用 Castellan 库与 OpenStack Key Manager 服务进行交互。此库提供对密钥管理器的可配置访问。 + +有关详细信息，请参阅 Sahara 高级配置指南。 + +#### Magnum + +为了使用本机客户端（ `docker` 或 `kubectl` 分别）提供对 Docker Swarm 或 Kubernetes 的访问，magnum 使用 TLS 证书。要存储证书，建议使用 Barbican 或 Magnum 数据库 （ `x590keypair` ）。 + +也可以使用本地目录 （ `local` ），但被认为是不安全的，不适合生产环境。 + +有关为 Magnum 设置证书管理器的更多详细信息，请参阅容器基础架构管理服务文档。 + +#### Octavia/LBaaS + +Neutron 和 Octavia 项目的 LBaaS（负载均衡器即服务）功能需要证书及其私钥来为 TLS 连接提供负载均衡。Barbican 可用于存储此敏感信息。 + +有关详细信息，请参阅如何创建 TLS 负载均衡器和部署以 TLS 结尾的 HTTPS 负载均衡器。 + +#### Swift + +对称密钥可用于加密 Swift 容器，以降低用户数据被读取的风险，如果未经授权的一方要获得对磁盘的物理访问权限。 + +有关更多详细信息，请参阅官方 swift 文档中的对象加密部分。 + +#### 配置文件中的密码 + +OpenStack 服务的配置文件包含许多纯文本密码。例如，这些包括服务用户用于向 keystone 进行身份验证以验证 keystone 令牌的密码。 + +目前没有对这些密码进行模糊处理的解决方案。建议通过文件权限适当地保护这些文件。 + +目前正在努力将这些密钥存储在 Castellan 后端，然后让 oslo.config 使用 Castellan 来检索这些密钥。 + +### Barbican + +#### 概述 + +Barbican 是一个 REST API，旨在安全存储、配置和管理密码、加密密钥和 X.509 证书等机密。它旨在对所有环境都有用，包括大型短暂云。 + +Barbican 与多个 OpenStack 功能集成，可以直接集成，也可以作为 Castellan 的后端集成。 + +Barbican 通常用作密钥管理系统，以实现图像签名验证、卷加密等用例。这些用例在用例中进行了概述 + +##### Barbican 基于角色的访问控制 + +待定 + +##### 机密存储后端 + +Key Manager 服务具有插件架构，允许部署程序将密钥存储在一个或多个密钥存储中。机密存储可以是基于软件的（如软件令牌），也可以是基于硬件设备（如硬件安全模块 （HSM））的。本节介绍当前可用的插件，并讨论每个插件的安全状况。插件已启用并使用配置文件中的 `/etc/barbican/barbican.conf` 设置进行配置。 + +有两种类型的插件：加密插件和机密存储插件。 + +#### 加密插件 + +加密插件将机密存储为 Barbican 数据库中的加密 blob。调用该插件来加密密钥存储上的密钥，并在密钥检索时解密密钥。目前有两种类型的存储插件可用：Simple Crypto 插件和 PKCS#11 加密插件。 + +#### 简单的加密插件 + +默认情况下，在 中 `barbican.conf` 配置了简单的加密插件。该插件使用单个对称密钥（KEK - 或“密钥加密密钥”），该密钥以纯文本形式存储在 `barbican.conf` 文件中，以加密和解密所有机密。此插件被认为是不太安全的选项，仅适用于开发和测试，因为主密钥以纯文本形式存储在配置文件中，因此不建议在生产部署中使用。 + +#### PKCS#11 加密插件 + +PKCS#11 加密插件可用于与使用 PKCS#11 协议的硬件安全模块 （HSM） 连接。机密由项目特定的密钥加密密钥 （KEK） 加密 （并在检索时解密） 。KEK 受主 KEK （MKEK） 保护（加密）。MKEK 与 HMAC 一起驻留在 HSM 中。由于每个项目都使用不同的 KEK，并且由于 KEK 以加密形式（而不是配置文件中的明文）存储在数据库中，因此 PKCS#11 插件比简单的加密插件安全得多。它是 Barbican 部署中最受欢迎的后端。 + +#### 机密存储插件 + +密钥存储插件与安全存储系统接口，以将密钥存储在这些系统中。密钥存储插件有三种类型：KMIP 插件、Dogtag 插件和 Vault 插件。 + +#### KMIP 插件 + +密钥管理互操作性协议 （KMIP） 密钥存储插件用于与启用了 KMIP 的设备（如硬件安全模块 （HSM））进行通信。密钥直接安全地存储在启用了 KMIP 的设备中，而不是存储在 Barbican 数据库中。Barbican 数据库维护对密钥位置的引用，以供以后检索。该插件可以配置为使用用户名和密码或使用客户端证书向启用了 KMIP 的设备进行身份验证。此信息存储在 Barbican 配置文件中。 + +#### Dogtag 插件 + +Dogtag 秘密存储插件用于与 Dogtag 通信。Dogtag 是对应于 Red Hat 证书系统的上游项目，Red Hat Certificate System 是一个通用标准/FIPS 认证的 PKI 解决方案，包含证书管理器 （CA） 和密钥恢复机构 （KRA），用于安全存储机密。KRA 将机密作为加密的 blob 存储在其内部数据库中，主加密密钥存储在基于软件的 NSS 安全数据库中，或存储在硬件安全模块 （HSM） 中。基于软件的 NSS 数据库配置为不希望使用 HSM 的部署提供了安全选项。KRA 是 FreeIPA 的一个组件，因此可以使用 FreeIPA 服务器配置插件。以下博客文章中提供了有关如何使用 FreeIPA 设置 Barbican 的更详细说明。 + +#### Vault 插件 + +Vault 是 Hashicorp 开发的秘密存储，用于安全访问机密和其他对象，例如 API 密钥、密码或证书。保险柜为任何机密提供统一的界面，同时提供严格的访问控制并记录详细的审核日志。Vault 企业版还允许与 HSM 集成以进行自动解封、提供 FIPS 密钥存储和熵增强。但是，Vault 插件的缺点是它不支持多租户，因此所有密钥都将存储在同一个键/值密钥引擎下。挂载点。 + +##### 威胁分析 + +Barbican 团队与 OpenStack 安全项目合作，对最佳实践 Barbican 部署进行了安全审查。安全审查的目的是识别服务设计和体系结构中的弱点和缺陷，并提出解决这些问题的控制或修复措施。 + +巴比肯威胁分析确定了八项安全发现和两项建议，以提高巴比肯部署的安全性。这些结果可以在安全分析存储库中查看，以及 Barbican 体系结构图和体系结构描述页。 + +### Castellan + +#### 概述 + +Castellan 是由 Barbican 团队开发的通用密钥管理器界面。它使项目能够使用可配置的密钥管理器，该管理器可以特定于部署。 + +### 常见问题解答 + +​ 1.在 OpenStack 中安全存储密钥的推荐方法是什么？ + +在OpenStack中安全地存储和管理密钥的推荐方法是使用Barbican。 + +​ 2.我为什么要使用Barbican？ + +Barbican 是一种 OpenStack 服务，它支持多租户，并使用 Keystone 令牌进行身份验证。这意味着对密钥的访问是通过租户和 RBAC 角色的 OpenStack 策略来控制的。 + +Barbican 具有多个可插拔后端，可以使用 PKCS#11 或 KMIP 与基于软件和硬件的安全模块进行通信。 + +​ 3.如果我不想使用Barbican怎么办？ + +在 Openstack 上下文中，需要管理两种类型的密钥 - 需要密钥失真令牌才能访问的密钥，以及不需要密钥验证令牌的密钥。 + +需要 keystone 身份验证的密钥的一个示例是特定项目拥有的密码和密钥。例如，这些包括项目加密煤渣卷的加密密钥或项目概览图像的签名密钥。 + +不需要 keystone 令牌即可访问的密钥示例包括服务配置文件中服务用户的密码或不属于任何特定项目的加密密钥。 + +需要 keystone 令牌的机密应使用 Barbican 进行存储。 + +不需要 keystone 身份验证的密钥可以存储在任何密钥存储中，该密钥存储实现了通过 Castellan 公开的简单密钥存储 API。这也包括巴比肯。 + +​ 4.如何使用 Vault、Keywhiz、Custodia 等...？ + +如果已为该密钥管理器编写了 Castellan 插件，则您选择的密钥管理器可以与该密钥管理器一起使用。一旦该插件被编写出来，直接使用该插件或在 Barbican 后面使用该插件是相对微不足道的。 + +目前，Vault 和 Custodia 插件正在为 Queens 周期开发。 + +### 检查表 + +#### Check-Key-Manager-01：配置文件的所有权是否设置为 root/barbican？ + +配置文件包含组件平稳运行所需的关键参数和信息。如果非特权用户有意或无意地修改或删除任何参数或文件本身，则会导致严重的可用性问题，从而导致拒绝向其他最终用户提供服务。此类关键配置文件的用户所有权必须设置为 root，组所有权必须设置为 barbican。此外，包含目录应具有相同的所有权，以确保正确拥有新文件。 + +运行以下命令： + +```shell +$ stat -L -c "%U %G" /etc/barbican/barbican.conf | egrep "root barbican" +$ stat -L -c "%U %G" /etc/barbican/barbican-api-paste.ini | egrep "root barbican" +$ stat -L -c "%U %G" /etc/barbican/policy.json | egrep "root barbican" +$ stat -L -c "%U %G" /etc/barbican | egrep "root barbican" +``` + +通过：如果所有这些配置文件的用户和组所有权分别设置为 root 和 barbican。上面的命令显示了 root / barbican 的输出。 + +失败：如果上述命令未返回任何输出，则用户和组所有权可能已设置为除 root 以外的任何用户或除 barbican 以外的任何组。 + +#### Check-Key-Manager-02：是否为配置文件设置了严格的权限？ + +与前面的检查类似，我们建议为此类配置文件设置严格的访问权限。 + +运行以下命令： + +```shell +$ stat -L -c "%a" /etc/barbican/barbican.conf +$ stat -L -c "%a" /etc/barbican/barbican-api-paste.ini +$ stat -L -c "%a" /etc/barbican/policy.json +$ stat -L -c "%a" /etc/barbican +``` + +还可以进行更广泛的限制：如果包含目录设置为 750，则保证此目录中新创建的文件具有所需的权限。 + +通过：如果权限设置为 640 或更严格，或者包含目录设置为 750。640 的权限转换为所有者 r/w、组 r，而对其他人没有权限，例如“u=rw，g=r，o=”。 + +**注意** + +```shell +使用 Check-Key-Manager-01：配置文件的所有权是否设置为 root/barbican？权限设置为 640，root 具有读/写访问权限，Barbican 具有对这些配置文件的读取访问权限。也可以使用以下命令验证访问权限。仅当此命令支持 ACL 时，它才在您的系统上可用。 +``` + +```shell +$ getfacl --tabular -a /etc/barbican/barbican.conf +getfacl: Removing leading '/' from absolute path names +# file: etc/barbican/barbican.conf +USER root rw- +GROUP barbican r-- +mask r-- +other --- +``` + +失败：如果权限设置大于 640。 + +#### Check-Key-Manager-03：OpenStack Identity 是否用于身份验证？ + +OpenStack 支持各种身份验证策略，如 `noauth` 和 `keystone` 。如果使用该 `noauth` 策略，则用户无需任何身份验证即可与 OpenStack 服务进行交互。这可能是一个潜在的风险，因为攻击者可能会获得对 OpenStack 组件的未经授权的访问。我们强烈建议所有服务都必须使用其服务帐户通过 keystone 进行身份验证。 + +通过：如果参数 `authtoken` 列在 中的 `pipeline:barbican-api-keystone` `barbican-api-paste.ini` 部分下。 + +失败：如果 中的 `pipeline:barbican-api-keystone` `barbican-api-paste.ini` 部分下缺少该参数 `authtoken` 。 + +#### Check-Key-Manager-04：是否启用了 TLS 进行身份验证？ + +OpenStack 组件使用各种协议相互通信，通信可能涉及敏感或机密数据。攻击者可能会尝试窃听频道以访问敏感信息。所有组件必须使用安全通信协议相互通信。 + +通过：如果 section in `/etc/barbican/barbican.conf` 下的参数值设置为 Identity API 端点开头， `https://` 并且 same `/etc/barbican/barbican.conf` 中同一 `[keystone_authtoken]` 部分下的 `[keystone_authtoken]` 参数 `www_authenticate_uri` `insecure` 值设置为 `False` 。 + +失败：如果 in `/etc/barbican/barbican.conf` 部分下的 `[keystone_authtoken]` 参数 `www_authenticate_uri` 值未设置为以 开头的身份 API 端点， `https://` 或者同一 `/etc/barbican/barbican.conf` 部分中的参数 `insecure` `[keystone_authtoken]` 值设置为 `True` 。 + +## 消息队列 + +消息队列服务促进了 OpenStack 中的进程间通信。OpenStack 支持以下消息队列服务后端： + +- RabbitMQ +- Qpid +- ZeroMQ 或 0MQ + +RabbitMQ 和 Qpid 都是高级消息队列协议 （AMQP） 框架，它们为点对点通信提供消息队列。队列实现通常部署为集中式或分散式队列服务器池。ZeroMQ 通过 TCP 套接字提供直接的点对点通信。 + +消息队列有效地促进了跨 OpenStack 部署的命令和控制功能。一旦允许访问队列，就不会执行进一步的授权检查。可通过队列访问的服务会验证实际消息负载中的上下文和令牌。但是，您必须注意令牌的到期日期，因为令牌可能可重播，并且可以授权基础结构中的其他服务。 + +OpenStack 不支持消息级别的安全性，例如消息签名。因此，您必须对消息传输本身进行安全和身份验证。对于高可用性 （HA） 配置，您必须执行队列对队列的身份验证和加密。 + +通过 ZeroMQ 消息传递，IPC 套接字在单个机器上使用。由于这些套接字容易受到攻击，因此请确保云运营商已保护它们。 + +- 消息安全 + - 消息传输安全 + - 队列身份验证和访问控制 + - 消息队列进程隔离和策略 + +### 消息安全 + +本节讨论 OpenStack 中使用的三种最常见的消息队列解决方案的安全强化方法：RabbitMQ、Qpid 和 ZeroMQ。 + +#### 消息传输安全 + +基于 AMQP 的解决方案（Qpid 和 RabbitMQ）支持使用 TLS 的传输级安全性。ZeroMQ 消息传递本身不支持 TLS，但使用标记的 IPsec 或 CIPSO 网络标签可以实现传输级安全性。 + +我们强烈建议为您的消息队列启用传输级加密。将 TLS 用于消息传递客户端连接可以保护通信在传输到消息传递服务器的过程中不被篡改和窃听。以下是有关如何为两个常用消息传递服务器 Qpid 和 RabbitMQ 配置 TLS 的指南。在配置消息传递服务器用于验证客户机连接的可信证书颁发机构 （CA） 捆绑软件时，建议仅将其限制为用于节点的 CA，最好是内部管理的 CA。受信任的 CA 捆绑包将确定哪些客户端证书将获得授权，并通过设置 TLS 连接的客户端-服务器验证步骤。请注意，在安装证书和密钥文件时，请确保文件权限受到限制，例如使用 `chmod 0600` ，并且所有权限制为消息传递服务器守护程序用户，以防止消息传递服务器上的其他进程和用户进行未经授权的访问。 + +##### RabbitMQ 服务器 SSL 配置 + +应将以下行添加到系统范围的 RabbitMQ 配置文件中，通常 `/etc/rabbitmq/rabbitmq.config` ： + +```shell +[ + {rabbit, [ + {tcp_listeners, [] }, + {ssl_listeners, [{"", 5671}] }, + {ssl_options, [{cacertfile,"/etc/ssl/cacert.pem"}, + {certfile,"/etc/ssl/rabbit-server-cert.pem"}, + {keyfile,"/etc/ssl/rabbit-server-key.pem"}, + {verify,verify_peer}, + {fail_if_no_peer_cert,true}]} + ]} +]. +``` + +请注意，该 `tcp_listeners` 选项设置为 `[]` 阻止它侦听非 SSL 端口。应将该 `ssl_listeners` 选项限制为仅在管理网络上侦听服务。 + +有关 RabbitMQ SSL 配置的更多信息，请参阅： + +- RabbitMQ 配置 +- RabbitMQ SSL协议 + +##### Qpid 服务器 SSL 配置 + +Apache 基金会为 Qpid 提供了消息传递安全指南。请参阅： + +- Apache Qpid SSL + +#### 队列认证和访问控制 + +RabbitMQ 和 Qpid 提供身份验证和访问控制机制，用于控制对队列的访问。ZeroMQ 不提供此类机制。 + +简单身份验证和安全层 （SASL） 是 Internet 协议中用于身份验证和数据安全的框架。RabbitMQ 和 Qpid 都提供 SASL 和其他可插入的身份验证机制，而不仅仅是简单的用户名和密码，从而可以提高身份验证安全性。虽然 RabbitMQ 支持 SASL，但 OpenStack 中的支持目前不允许请求特定的 SASL 身份验证机制。OpenStack 中的 RabbitMQ 支持允许通过未加密的连接进行用户名和密码身份验证，或者将用户名和密码与 X.509 客户端证书结合使用，以建立安全的 TLS 连接。 + +我们建议在所有 OpenStack 服务节点上配置 X.509 客户端证书，以便客户端连接到消息传递队列，并在可能的情况下（目前仅 Qpid）使用 X.509 客户端证书执行身份验证。使用用户名和密码时，应按服务和节点创建帐户，以便对队列的访问进行更精细的可审核性。 + +在部署之前，请考虑排队服务器使用的 TLS 库。Qpid 使用 Mozilla 的 NSS 库，而 RabbitMQ 使用 Erlang 的 TLS 模块，该模块使用 OpenSSL。 + +##### 身份验证配置示例：RabbitMQ + +在 RabbitMQ 服务器上，删除默认 `guest` 用户： + +```shell +# rabbitmqctl delete_user guest +``` + +在 RabbitMQ 服务器上，对于与消息队列通信的每个 OpenStack 服务或节点，请设置用户帐户和权限： + +```shell +# rabbitmqctl add_user compute01 RABBIT_PASS +# rabbitmqctl set_permissions compute01 ".*" ".*" ".*" +``` + +将RABBIT_PASS替换为合适的密码。 + +有关其他配置信息，请参阅： + +- RabbitMQ 访问控制 +- RabbitMQ 身份验证 +- RabbitMQ 插件 +- RabbitMQ SASL 外部身份验证 + +##### OpenStack 服务配置：RabbitMQ + +```shell +[DEFAULT] +rpc_backend = nova.openstack.common.rpc.impl_kombu +rabbit_use_ssl = True +rabbit_host = RABBIT_HOST +rabbit_port = 5671 +rabbit_user = compute01 +rabbit_password = RABBIT_PASS +kombu_ssl_keyfile = /etc/ssl/node-key.pem +kombu_ssl_certfile = /etc/ssl/node-cert.pem +kombu_ssl_ca_certs = /etc/ssl/cacert.pem +``` + +##### 身份验证配置示例：Qpid + +有关配置信息，请参阅： + +- Apache Qpid 身份验证 +- Apache Qpid 授权 + +##### OpenStack 服务配置：Qpid + +```shell +[DEFAULT] +rpc_backend = nova.openstack.common.rpc.impl_qpid +qpid_protocol = ssl +qpid_hostname = +qpid_port = 5671 +qpid_username = compute01 +qpid_password = QPID_PASS +``` + +（可选）如果将 SASL 与 Qpid 一起使用，请通过添加以下内容来指定正在使用的 SASL 机制： + +```shell +qpid_sasl_mechanisms = +``` + +#### 消息队列进程隔离和策略 + +每个项目都提供了许多发送和使用消息的服务。每个发送消息的二进制文件都应该使用队列中的消息，如果只是回复的话。 + +消息队列服务进程应彼此隔离，并应与计算机上的其他进程隔离。 + +##### 命名空间 + +强烈建议在 OpenStack Compute Hypervisor 上运行的所有服务使用网络命名空间。这将有助于防止 VM 来宾和管理网络之间的网络流量桥接。 + +使用 ZeroMQ 消息传递时，每个主机必须至少运行一个 ZeroMQ 消息接收器，以接收来自网络的消息并通过 IPC 将消息转发到本地进程。在 IPC 命名空间中为每个项目运行一个独立的消息接收器是可能的，也是可取的，以及同一项目中的其他服务。 + +##### 网络策略 + +队列服务器应仅接受来自管理网络的连接。这适用于所有实现。这应通过服务配置来实现，并可选择通过全局网络策略强制实施。 + +使用 ZeroMQ 消息传递时，每个项目都应在专用于属于该项目的服务的端口上运行单独的 ZeroMQ 接收方进程。这相当于 AMQP 的控制交换概念。 + +##### 强制访问控制 + +使用强制访问控制 （MAC） 和自由访问控制 （DAC） 将进程的配置限制为仅这些进程。此限制可防止这些进程与在同一台计算机上运行的其他进程隔离。 + +## 数据处理 + +数据处理服务（sahara）提供了一个平台，用于使用Hadoop和Spark等处理框架来配置和管理实例集群。通过 OpenStack Dashboard 或 REST API，用户能够上传和执行框架应用程序，这些应用程序可以访问对象存储或外部提供程序中的数据。数据处理控制器使用编排服务 （heat） 创建实例集群，这些集群可以作为长期运行的组存在，这些组可以根据请求进行扩展和收缩，也可以作为为单个工作负载创建的瞬态组存在。 + +- 数据处理简介 + - 架构 + - 涉及的技术 + - 用户对资源的访问权限 +- 部署 + - 控制器对集群的网络访问 +- 配置和强化 + - TLS + - 基于角色的访问控制策略 + - 安全组 + - 代理域 + - 自定义网络拓扑 + - 间接访问 + - 根包装 + - 日志记录 + - 参考书目 + +### 数据处理简介 + +数据处理服务控制器将负责创建、维护和销毁为其集群创建的任何实例。控制器将使用网络服务在自身和集群实例之间建立网络路径。它还将管理要在集群上运行的用户应用程序的部署和生命周期。集群中的实例包含框架处理引擎的核心，数据处理服务提供了多个选项来创建和管理与这些实例的连接。 + +数据处理资源（群集、作业和数据源）按身份服务中定义的项目进行分隔。这些资源在项目中共享，了解使用该服务的人员的访问需求非常重要。通过使用基于角色的访问控制，可以进一步限制项目中的活动（例如启动集群、上传作业等）。 + +在本章中，我们将讨论如何评估数据处理用户对其应用程序、他们使用的数据以及他们在项目中的预期功能的需求。我们还将演示服务控制器及其集群的一些强化技术，并提供各种控制器配置和用户管理方法的示例，以确保足够的安全和隐私级别。 + +#### 架构 + +下图显示了数据处理服务如何适应更大的 OpenStack 生态系统的概念视图。 + +![../_images/data_processing_architecture.png](https://docs.openstack.org/security-guide/_images/data_processing_architecture.png) + +数据处理服务在集群配置过程中大量使用计算、编排、镜像和块存储服务。它还将使用在群集创建期间提供的由网络服务创建的一个或多个网络来管理实例。当用户运行框架应用程序时，控制器和集群将访问对象存储服务。鉴于这些服务用法，我们建议按照系统文档中概述的说明对安装的所有组件进行编目。 + +#### 涉及的技术 + +数据处理服务负责部署和管理多个应用程序。为了全面了解所提供的安全选项，我们建议操作员大致熟悉这些应用程序。突出显示的技术列表分为两部分：第一部分，对安全性影响较大的高优先级应用程序，第二部分，支持影响较小的应用程序。 + +更高的影响 + +- Hadoop +- Hadoop安全模式文档 +- HDFS +- Spark +- Spark 安全 +- Storm +- Zookeeper + +较低的影响 + +- Oozie +- Hive +- Pig + +这些技术构成了与数据处理服务一起部署的框架的核心。除了这些技术之外，该服务还包括第三方供应商提供的捆绑框架。这些捆绑框架是使用上述相同核心部分以及供应商包含的配置和应用程序构建的。有关第三方框架捆绑包的更多信息，请参阅以下链接： + +- Cloudera CDH +- Hortonworks Data Platform +- MapR + +#### 用户访问资源 + +数据处理服务的资源（集群、作业和数据源）在项目范围内共享。尽管单个控制器安装可以管理多组资源，但这些资源的范围将限定为单个项目。鉴于此限制，我们建议密切监视项目中的用户成员身份，以保持资源的适当隔离。 + +由于部署此服务的组织的安全要求会根据其特定需求而有所不同，因此我们建议运营商将重点放在数据隐私、集群管理和最终用户应用程序上，作为评估用户需求的起点。这些决策将有助于指导配置用户对服务的访问的过程。有关数据隐私的扩展讨论，请参阅租户数据隐私。 + +数据处理安装的默认假设是用户将有权访问其项目中的所有功能。如果需要更精细的控制，数据处理服务会提供策略文件（如策略中所述）。这些配置将高度依赖于安装组织的需求，因此没有关于其使用的一般建议：有关详细信息，请参阅基于角色的访问控制策略。 + +### 部署 + +与许多其他 OpenStack 服务一样，数据处理服务被部署为在连接到堆栈的主机上运行的应用程序。从 Kilo 版本开始，它能够以分布式方式部署多个冗余控制器。与其他服务一样，它也需要一个数据库来存储有关其资源的信息。请参阅数据库。请务必注意，数据处理服务将需要管理多个标识服务信任，直接与业务流程和网络服务通信，并可能在代理域中创建用户。由于这些原因，控制器将需要访问控制平面，因此我们建议将其与其他服务控制器一起安装。 + +数据处理直接与多个 OpenStack 服务交互： + +- 计算 +- 身份验证 +- 联网 +- 对象存储 +- 配器 +- 块存储（可选） + +建议记录这些服务与数据处理控制器之间的所有数据流和桥接点。请参阅系统文档。 + +数据处理服务使用对象存储服务来存储作业二进制文件和数据源。希望访问完整数据处理服务功能的用户将需要在他们正在使用的项目中存储对象。 + +网络服务在群集的配置中起着重要作用。在预配之前，用户应为群集实例提供一个或多个网络。关联网络的操作类似于通过仪表板启动实例时分配网络的过程。控制器使用这些网络对其集群的实例和框架进行管理访问。 + +另外值得注意的是身份服务。数据处理服务的用户需要在其项目中具有适当的角色，以允许为其集群预置实例。使用代理域配置的安装需要特别注意。请参阅代理域。具体而言，数据处理服务将需要能够在代理域中创建用户。 + +#### 控制器对集群的网络访问 + +数据处理控制器的主要任务之一是与其生成的实例进行通信。这些实例是预置的，然后根据所使用的框架进行配置。控制器和实例之间的通信使用安全外壳 （SSH） 和 HTTP 协议。 + +在预配集群时，将在用户提供的网络中为每个实例提供一个 IP 地址。第一个网络通常称为数据处理管理网络，实例可以使用网络服务为此网络分配的固定 IP 地址。控制器还可以配置为除了固定地址之外，还对实例使用浮动 IP 地址。与实例通信时，控制器将首选浮动地址（如果启用）。 + +对于固定和浮动 IP 地址无法提供所需功能的情况，控制器可以通过两种替代方法提供访问：自定义网络拓扑和间接访问。自定义网络拓扑功能允许控制器通过配置文件中提供的 shell 命令访问实例。间接访问用于指定用户在集群置备期间可用作代理网关的实例。这些选项通过配置和强化中的用法示例进行讨论。 + +### 配置和强化 + +有多个配置选项和部署策略可以提高数据处理服务的安全性。服务控制器通过主配置文件和一个或多个策略文件进行配置。使用数据局部性功能的安装还将具有两个附加文件，用于指定计算节点和对象存储节点的物理位置。 + +#### TLS系统 + +与许多其他 OpenStack 控制器一样，数据处理服务控制器可以配置为需要 TLS 连接。 + +Pre-Kilo 版本将需要 TLS 代理，因为控制器不允许直接 TLS 连接。TLS 代理和 HTTP 服务中介绍了如何配置 TLS 代理，我们建议按照其中的建议创建此类安装。 + +从 Kilo 版本开始，数据处理控制器允许直接 TLS 连接，我们建议这样做。启用此行为需要对控制器配置文件进行一些小的调整。 + +**例。配置对控制器的 TLS 访问** + +```shell +[ssl] +ca_file = cafile.pem +cert_file = certfile.crt +key_file = keyfile.key +``` + +#### 基于角色的访问控制策略 + +数据处理服务使用策略文件（如策略中所述）来配置基于角色的访问控制。使用策略文件，操作员可以限制组对特定数据处理功能的访问。 + +执行此操作的原因将根据安装的组织要求而更改。通常，这些细粒度控件用于操作员需要限制数据处理服务资源的创建、删除和检索的情况。需要限制项目内访问的操作员应充分意识到，需要有其他方法让用户访问服务的核心功能（例如，配置集群）。 + +**例。允许所有用户使用所有方法（默认策略）** + +```shell +{ + "default": "" +} +``` + +**例。禁止对非管理员用户进行映像注册表操作** + +```shell +{ + "default": "", + + "data-processing:images:register": "role:admin", + "data-processing:images:unregister": "role:admin", + "data-processing:images:add_tags": "role:admin", + "data-processing:images:remove_tags": "role:admin" +} +``` + +#### 安全组 + +数据处理服务允许将安全组与为其集群预置的实例相关联。无需其他配置，该服务将对预置集群的任何项目使用默认安全组。如果请求，可以使用不同的安全组，或者存在一个自动选项，该选项指示服务根据所访问框架指定的端口创建安全组。 + +对于生产环境，我们建议手动控制安全组，并创建一组适合安装的组规则。通过这种方式，操作员可以确保默认安全组将包含所有适当的规则。有关安全组的扩展讨论，请参阅安全组。 + +#### 代理域 + +将对象存储服务与数据处理结合使用时，需要添加存储访问凭据。使用代理域，数据处理服务可以改用来自标识服务的委派信任，以允许通过域中创建的临时用户进行存储访问。要使此委派机制起作用，必须将数据处理服务配置为使用代理域，并且操作员必须为代理用户配置身份域。 + +数据处理控制器保留为对象存储访问提供的用户名和密码的临时存储。使用代理域时，控制器将为代理用户生成此对，并且此用户的访问将仅限于身份信任的访问。我们建议在控制器或其数据库具有与公共网络之间的路由的任何安装中使用代理域。 + +**示例：为名为“dp_proxy”的代理域进行配置** + +```shell +[DEFAULT] +use_domain_for_proxy_users = true +proxy_user_domain_name = dp_proxy +proxy_user_role_names = Member +``` + +#### 自定义网络拓扑 + +数据处理控制器可以配置为使用代理命令来访问其集群实例。通过这种方式，可以为不使用网络服务直接提供的网络的安装创建自定义网络拓扑。对于需要限制控制器和实例之间访问的安装，我们建议使用此选项。 + +**示例：通过指定的中继机访问实例** + +```shell +[DEFAULT] +proxy_command='ssh relay-machine-{tenant_id} nc {host} {port}' +``` + +**示例：通过自定义网络命名空间访问实例** + +```shell +[DEFAULT] +proxy_command='ip netns exec ns_for_{network_id} nc {host} {port}' +``` + +#### 间接访问 + +对于控制器对集群所有实例的访问权限有限的安装，由于对浮动 IP 地址或安全规则的限制，可以配置间接访问。这允许将某些实例指定为集群其他实例的代理网关。 + +只有在定义将构成数据处理集群的节点组模板时，才能启用此配置。它作为运行时选项提供，可在群集置备过程中启用。 + +#### Rootwrap + +在为网络访问创建自定义拓扑时，可能需要允许非 root 用户运行代理命令。对于这些情况，oslo rootwrap 软件包用于为非 root 用户提供运行特权命令的工具。此配置要求与数据处理控制器应用程序关联的用户位于 sudoers 列表中，并在配置文件中启用该选项。或者，可以提供备用 rootwrap 命令。 + +**示例：启用 rootwrap 用法并显示默认命令** + +```shell +[DEFAULT] +use_rootwrap=True +rootwrap_command=’sudo sahara-rootwrap /etc/sahara/rootwrap.conf’ +``` + +关于 rootwrap 项目的更多信息，请参考官方文档： + +#### 日志 + +监视服务控制器的输出是一个强大的取证工具，如监视和日志记录中更详细地描述的那样。数据处理服务控制器提供了几个选项来设置日志记录的位置和级别。 + +**示例：将日志级别设置为高于警告并指定输出文件。** + +```shell +[DEFAULT] +verbose = true +log_file = /var/log/data-processing.log +``` + +#### 参考书目 + +OpenStack.org，欢迎来到Sahara！2016.Sahara项目文档 + +Apache 软件基金会，欢迎来到 Apache Hadoop！2016. Apache Hadoop 项目 + +Apache 软件基金会，安全模式下的 Hadoop。2016. Hadoop 安全模式文档 + +Apache 软件基金会，HDFS 用户指南。2016. Hadoop HDFS 文档 + +Apache 软件基金会，Spark。2016. Spark项目 + +Apache 软件基金会，Spark Security。2016. Spark 安全文档 + +Apache 软件基金会，Apache Storm。2016. Storm 项目 + +Apache 软件基金会，Apache Zookeeper。2016. Zookeeper 项目 + +Apache 软件基金会，Apache Oozie Workflow Scheduler for Hadoop。2016. Oozie项目 + +Apache 软件基金会，Apache Hive。2016. Hive + +Apache 软件基金会，欢迎来到 Apache Pig。2016.Pig + +Apache 软件基金会，Cloudera 产品文档。2016. Cloudera CDH 文档 + +Hortonworks，Hortonworks。2016. Hortonworks 数据平台文档 + +MapR Technologies，用于 MapR 融合数据平台的 Apache Hadoop。2016. MapR 项目 + +## 数据库 + +数据库服务器的选择是 OpenStack 部署安全性的一个重要考虑因素。在决定使用数据库服务器时，应考虑多种因素，但在本本书的范围内，将只讨论安全注意事项。OpenStack 支持多种数据库类型。有关更多信息，请参阅《OpenStack 管理员指南》。 + +《安全指南》目前主要针对 PostgreSQL 和 MySQL。 + +- 数据库后端注意事项 + - 数据库后端的安全参考 +- 数据库访问控制 + - OpenStack 数据库访问模型 + - 数据库身份验证和访问控制 + - 要求用户帐户需要 SSL 传输 + - 使用 X.509 证书进行身份验证 + - OpenStack 服务数据库配置 + - Nova-conductor +- 数据库传输安全性 + - 数据库服务器 IP 地址绑定 + - 数据库传输 + - MySQL SSL配置 + - PostgreSQL SSL 配置 + +### 数据库后端注意事项 + +PostgreSQL 具有许多理想的安全功能，例如 Kerberos 身份验证、对象级安全性和加密支持。PostgreSQL 社区在提供可靠的指导、文档和工具以促进积极的安全实践方面做得很好。 + +MySQL拥有庞大的社区，被广泛采用，并提供高可用性选项。MySQL还能够通过插件身份验证机制提供增强的客户端身份验证。MySQL社区中的分叉发行版提供了许多可供考虑的选项。根据对安全态势的全面评估和为给定发行版提供的支持级别，选择MySQL的特定实现非常重要。 + +#### 数据库后端的安全参考 + +建议部署 MySQL 或 PostgreSQL 的用户参考现有的安全指南。下面列出了一些参考资料： + +MySQL数据库： + +- OWASP MySQL强化 + +- MySQL 可插入身份验证 +- MySQL中的安全性 + +PostgreSQL格式： + +- OWASP PostgreSQL 强化 +- PostgreSQL 数据库中的总体安全性 + +### 数据库访问控制 + +每个核心 OpenStack 服务（计算、身份、网络、块存储）都将状态和配置信息存储在数据库中。在本章中，我们将讨论当前在OpenStack中使用数据库的方式。我们还探讨了安全问题，以及数据库后端选择的安全后果。 + +#### OpenStack 数据库访问模型 + +OpenStack 项目中的所有服务都访问单个数据库。目前没有用于创建基于表或行的数据库访问限制的参考策略。 + +在OpenStack中，没有对数据库操作进行精细控制的一般规定。访问权限和特权的授予仅基于节点是否有权访问数据库。在这种情况下，有权访问数据库的节点可能具有 DROP、INSERT 或 UPDATE 函数的完全权限。 + +##### 精细访问控制 + +默认情况下，每个 OpenStack 服务及其进程都使用一组共享凭据访问数据库。这使得审核数据库操作和撤消服务及其进程对数据库的访问权限变得特别困难。 + +![../_images/databaseusername.png](https://docs.openstack.org/security-guide/_images/databaseusername.png) + +##### Nova-conductor + +计算节点是 OpenStack 中最不受信任的服务，因为它们托管租户实例。引入该 `nova-conductor` 服务作为数据库代理，充当计算节点和数据库之间的中介。我们将在本章后面讨论其后果。 + +我们强烈建议： + +- 所有数据库通信都与管理网络隔离 +- 使用 TLS 保护通信 +- 为每个 OpenStack 服务端点创建唯一的数据库用户帐户（如下图所示） + +![../_images/databaseusernamessl.png](https://docs.openstack.org/security-guide/_images/databaseusernamessl.png) + +#### 数据库认证和访问控制 + +考虑到访问数据库的风险，我们强烈建议为每个需要访问数据库的节点创建唯一的数据库用户帐户。这样做有助于更好地进行分析和审核，以确保合规性，或者在节点遭到入侵时，通过在检测到该节点时删除该节点对数据库的访问来隔离受感染的主机。创建这些每个服务终结点数据库用户帐户时，应注意确保将其配置为需要 TLS。或者，为了提高安全性，建议除了用户名和密码外，还使用 X.509 证书身份验证来配置数据库帐户。 + +##### 权限 + +应创建并保护一个单独的数据库管理员 （DBA） 帐户，该帐户具有创建/删除数据库、创建用户帐户和更新用户权限的完全权限。这种简单的责任分离方法有助于防止意外配置错误，降低风险并缩小危害范围。 + +为 OpenStack 服务和每个节点创建的数据库用户帐户的权限应仅限于与该节点所属的服务相关的数据库。 + +#### 要求用户帐户需要 SSL 传输 + +##### 配置示例 #1：（MySQL） + +```shell +GRANT ALL ON dbname.* to 'compute01'@'hostname' IDENTIFIED BY 'NOVA_DBPASS' REQUIRE SSL; +``` + +##### 配置示例 #2：（PostgreSQL） + +在文件中 `pg_hba.conf` ： + +```shell +hostssl dbname compute01 hostname md5 +``` + +请注意，此命令仅添加通过 SSL 进行通信的功能，并且是非独占的。应禁用可能允许未加密传输的其他访问方法，以便 SSL 是唯一的访问方法。 + +该 `md5` 参数将身份验证方法定义为哈希密码。我们在以下部分中提供了一个安全身份验证示例。 + +##### OpenStack 服务数据库配置 + +如果数据库服务器配置为使用 TLS 传输，则需要指定用于 SQLAlchemy 查询中的初始连接字符串的证书颁发机构信息。 + +###### MySQL `:sql_connection` 的字符串示例 + +```shell +sql_connection = mysql://compute01:NOVA_DBPASS@localhost/nova?charset=utf8&ssl_ca=/etc/mysql/cacert.pem +``` + +#### 使用 X.509 证书进行身份验证 + +通过要求使用 X.509 客户端证书进行身份验证，可以增强安全性。以这种方式对数据库进行身份验证可以为与数据库建立连接的客户端提供更好的身份保证，并确保通信是加密的。 + +##### 配置示例 #1：（MySQL） + +```shell +GRANT ALL on dbname.* to 'compute01'@'hostname' IDENTIFIED BY 'NOVA_DBPASS' REQUIRE SUBJECT +'/C=XX/ST=YYY/L=ZZZZ/O=cloudycloud/CN=compute01' AND ISSUER +'/C=XX/ST=YYY/L=ZZZZ/O=cloudycloud/CN=cloud-ca'; +``` + +##### 配置示例 #2：（PostgreSQL） + +```shell +hostssl dbname compute01 hostname cert +``` + +#### OpenStack 服务数据库配置 + +如果数据库服务器配置为需要 X.509 证书进行身份验证，则需要为数据库后端指定相应的 SQLAlchemy 查询参数。这些参数指定用于初始连接字符串的证书、私钥和证书颁发机构信息。 + +MySQL 的 X.509 证书身份验证 `:sql_connection` 字符串示例： + +```shell +sql_connection = mysql://compute01:NOVA_DBPASS@localhost/nova? +charset=utf8&ssl_ca = /etc/mysql/cacert.pem&ssl_cert=/etc/mysql/server-cert.pem&ssl_key=/etc/mysql/server-key.pem +``` + +#### Nova-conductor + +OpenStack Compute 提供了一个称为 nova-conductor 的子服务，用于代理数据库连接，其主要目的是让 nova 计算节点与 nova-conductor 连接以满足数据持久性需求，而不是直接与数据库通信。 + +Nova-conductor 通过 RPC 接收请求并代表调用服务执行操作，而无需授予对数据库、其表或其中数据的精细访问权限。Nova-conductor 实质上将直接数据库访问从计算节点中抽象出来。 + +这种抽象的优点是将服务限制为使用参数执行方法，类似于存储过程，从而防止大量系统直接访问或修改数据库数据。这是在不在数据库本身的上下文或范围内存储或执行这些过程的情况下完成的，这是对典型存储过程的常见批评。 + +![../_images/novaconductor.png](https://docs.openstack.org/security-guide/_images/novaconductor.png) + +遗憾的是，此解决方案使更细粒度的访问控制和审核数据访问的能力的任务复杂化。由于 nova-conductor 服务通过 RPC 接收请求，因此它突出了提高消息传递安全性的重要性。任何有权访问消息队列的节点都可以执行 nova-conductor 提供的这些方法，并有效地修改数据库。 + +请注意，由于 nova-conductor 仅适用于 OpenStack Compute，因此对于其他 OpenStack 组件（如 Telemetry（云高计）、网络和块存储）的运行，可能仍然需要从计算主机直接访问数据库。 + +若要禁用 nova-conductor，请将以下内容放入 `nova.conf` 文件中（在计算主机上）： + +```shell +[conductor] +use_local = true +``` + +### 数据库传输安全性 + +本章介绍与数据库服务器之间的网络通信相关的问题。这包括 IP 地址绑定和使用 TLS 加密网络流量。 + +#### 数据库服务器 IP 地址绑定 + +若要隔离服务和数据库之间的敏感数据库通信，强烈建议将数据库服务器配置为仅允许通过隔离的管理网络与数据库进行通信。这是通过限制数据库服务器为传入客户端连接绑定网络套接字的接口或 IP 地址来实现的。 + +##### 限制 MySQL 的绑定地址 + +在 `my.cnf` ： + +```shell +[mysqld] +... +bind-address +``` + +##### 限制 PostgreSQL 的监听地址 + +在 `postgresql.conf` ： + +```shell +listen_addresses = +``` + +#### 数据库传输 + +除了将数据库通信限制为管理网络外，我们还强烈建议云管理员将其数据库后端配置为需要 TLS。将 TLS 用于数据库客户端连接可保护通信不被篡改和窃听。正如下一节将讨论的那样，使用 TLS 还提供了通过 X.509 证书（通常称为 PKI）执行数据库用户身份验证的框架。以下是有关如何为两个流行的数据库后端 MySQL 和 PostgreSQL 配置 TLS 的指南。 + +**注意** + +```shell +安装证书和密钥文件时，请确保文件权限受到限制，例如 `chmod 0600` ，所有权限制为数据库守护程序用户，以防止数据库服务器上的其他进程和用户进行未经授权的访问。 +``` + +#### MySQL SSL配置 + +应在系统范围的MySQL配置文件中添加以下行： + +在 `my.cnf` ： + +```shell +[[mysqld]] +... +ssl-ca = /path/to/ssl/cacert.pem +ssl-cert = /path/to/ssl/server-cert.pem +ssl-key = /path/to/ssl/server-key.pem +``` + +（可选）如果您希望限制用于加密连接的 SSL 密码集。有关密码列表和用于指定密码字符串的语法，请参阅密码： + +```shell +ssl-cipher = 'cipher:list' +``` + +#### PostgreSQL SSL 配置 + +应在系统范围的 PostgreSQL 配置文件中添加以下行。 `postgresql.conf` + +```shell +ssl = true +``` + +（可选）如果您希望限制用于加密连接的 SSL 密码集。有关密码列表和用于指定密码字符串的语法，请参阅密码： + +```shell +ssl-ciphers = 'cipher:list' +``` + +服务器证书、密钥和证书颁发机构 （CA） 文件应放在以下文件的 $PGDATA 目录中： + +- `$PGDATA/server.crt` - 服务器证书 +- `$PGDATA/server.key` - 私钥对应于 `server.crt` +- `$PGDATA/root.crt` - 可信证书颁发机构 +- `$PGDATA/root.crl` - 证书撤销列表 + +## 租户数据隐私 + +OpenStack旨在支持多租户，这些租户很可能有不同的数据要求。作为云构建者或运营商，您必须确保您的 OpenStack 环境能够解决数据隐私问题和法规。在本章中，我们将讨论与 OpenStack 实现相关的数据驻留和处置。 + +- 数据隐私问题 + - 数据驻留 + - 数据处置 +- 数据加密 + - 卷加密 + - 临时磁盘加密 + - 对象存储对象 + - 块存储性能和后端 + - 网络数据 +- 密钥管理 + - 参考书目: + +### 数据隐私问题 + +#### 数据驻留 + +在过去几年中，数据的隐私和隔离一直被认为是采用云的主要障碍。过去，对谁拥有云中数据以及云运营商是否可以最终信任这些数据的保管人的担忧一直是重大问题。 + +许多 OpenStack 服务维护属于租户的数据和元数据或参考租户信息。 + +存储在 OpenStack 云中的租户数据可能包括以下项目： + +- 对象存储对象 +- 计算实例临时文件系统存储 +- 计算实例内存 +- 块存储卷数据 +- 用于计算访问的公钥 +- 映像服务中的虚拟机映像 +- 计算机快照 +- 传递给 OpenStack Compute 的配置驱动器扩展的数据 + +OpenStack 云存储的元数据包括以下非详尽项目： + +- 组织名称 +- 用户的“真实姓名” +- 正在运行的实例、存储桶、对象、卷和其他配额相关项目的数量或大小 +- 运行实例或存储数据的小时数 +- 用户的 IP 地址 +- 内部生成的用于计算映像捆绑的私钥 + +#### 数据处置 + +OpenStack运营商应努力提供一定程度的租户数据处置保证。最佳实践建议操作员在处置、释放组织控制或释放以供重复使用之前对云系统介质（数字和非数字）进行清理。鉴于信息的特定安全域和敏感性，清理方法应实现适当级别的强度和完整性。 + +“清理过程会从介质中删除信息，因此无法检索或重建信息。清理技术，包括清除、清除、加密擦除和销毁，可防止在重复使用或释放处置此类介质时向未经授权的个人披露信息。NIST 特别出版物 800-53 修订版 4 + +NIST建议的安全控制措施中采用的一般数据处置和清理指南。云运营商应： + +1. 跟踪、记录和验证介质清理和处置操作。 +2. 测试清理设备和程序以验证其性能是否正常。 +3. 在将便携式可移动存储设备连接到云基础架构之前，先对其进行清理。 +4. 销毁无法清理的云系统介质。 + +在 OpenStack 部署中，您需要解决以下问题： + +- 安全数据擦除 +- 实例内存清理 +- 块存储卷数据 +- 计算实例临时存储 +- 裸机服务器清理 + +##### 数据未安全删除 + +在OpenStack中，某些数据可能会被删除，但在上述NIST标准的上下文中不会被安全删除。这通常适用于存储在数据库中的大多数或全部上述定义的元数据和信息。这可以通过数据库和/或系统配置进行自动吸尘和定期可用空间擦除来修复。 + +##### 实例内存清理 + +特定于各种虚拟机管理程序的是实例内存的处理。OpenStack Compute 中没有定义此行为，尽管通常期望 hypervisor 在删除实例和/或创建实例时尽最大努力清理内存。 + +Xen 显式地为实例分配专用内存区域，并在实例（或 Xen 术语中的域）销毁时清理数据。KVM 在很大程度上依赖于 Linux 页面管理;KVM 文档中定义了一组与 KVM 分页相关的复杂规则。 + +需要注意的是，使用 Xen 内存气球功能可能会导致信息泄露。我们强烈建议避免使用此功能。 + +对于这些和其他虚拟机管理程序，我们建议参考特定于虚拟机管理程序的文档。 + +##### Cinder 卷数据 + +强烈建议使用 OpenStack 卷加密功能。下面“卷加密”下的“数据加密”部分对此进行了讨论。使用此功能时，通过安全地删除加密密钥来完成数据销毁。最终用户可以在创建卷时选择此功能，但请注意，管理员必须先执行卷加密功能的一次性设置。有关此设置的说明，请参阅“配置参考”的“块存储”部分的“卷加密”下。 + +如果不使用 OpenStack 卷加密功能，那么其他方法通常更难启用。如果使用后端插件，则可能存在独立的加密方法或非标准覆盖解决方案。OpenStack Block Storage 的插件将以多种方式存储数据。许多插件特定于供应商或技术，而其他插件则更多地是围绕文件系统（如 LVM 或 ZFS）的 DIY 解决方案。安全销毁数据的方法因插件而异，因供应商的解决方案而异，也因文件系统而异。 + +一些后端（如 ZFS）将支持写入时复制，以防止数据泄露。在这些情况下，从未写入块中读取将始终返回零。其他后端（如 LVM）可能本身不支持此功能，因此块存储插件负责在将之前写入的块交给用户之前覆盖它们。请务必查看所选卷后端提供哪些保证，并查看哪些中介可用于未提供的保证。 + +##### 镜像服务延时删除功能 + +OpenStack 镜像服务具有延迟删除功能，该功能将在定义的时间段内等待镜像的删除。如果存在安全问题，建议通过编辑 `etc/glance/glance-api.conf` 文件并将 `delayed_delete` 选项设置为 False 来禁用此功能。 + +##### 计算软删除功能 + +OpenStack Compute 具有软删除功能，该功能使被删除的实例在定义的时间段内处于软删除状态。实例可以在此时间段内恢复。若要禁用软删除功能，请编辑 `etc/nova/nova.conf` 文件并将该 `reclaim_instance_interval` 选项留空。 + +##### 计算实例临时存储 + +请注意，OpenStack 临时磁盘加密功能提供了一种改进临时存储隐私和隔离的方法，无论是在主动使用期间还是在销毁数据时。与加密块存储一样，只需删除加密密钥即可有效地销毁数据。 + +在创建和销毁临时存储时，提供数据隐私的替代措施将在一定程度上取决于所选的虚拟机管理程序和 OpenStack 计算插件。 + +用于计算的 libvirt 插件可以直接在文件系统上或 LVM 中维护临时存储。文件系统存储通常不会在删除数据时覆盖数据，但可以保证不会向用户提供脏盘区。 + +当使用 LVM 支持的基于块的临时存储时，OpenStack 计算软件必须安全地擦除块以防止信息泄露。过去曾存在与不当擦除的临时块存储设备相关的信息泄露漏洞。 + +文件系统存储对于临时块存储设备来说是一种比 LVM 更安全的解决方案，因为无法为用户提供脏盘区。但是，需要注意的是，用户数据不会被破坏，因此建议对后备文件系统进行加密。 + +##### 裸机服务器清理 + +用于计算的裸机服务器驱动程序正在开发中，此后已转移到一个名为 ironic 的单独项目中。在撰写本文时，具有讽刺意味的是，似乎没有解决驻留在物理硬件中的租户数据的清理问题。 + +此外，裸机系统的租户可以修改系统固件。安全引导中所述的 TPM 技术提供了一种用于检测未经授权的固件更改的解决方案。 + +### 数据加密 + +该选项可供实施者加密租户数据，无论这些数据存储在磁盘上或通过网络传输，例如下面描述的 OpenStack 卷加密功能。这超出了用户在将自己的数据发送给提供商之前加密自己的数据的一般建议。 + +代表租户加密数据的重要性很大程度上与提供商承担的攻击者可能访问租户数据的风险有关。政府可能有要求，也有每个策略的要求，私有合同，甚至与公共云提供商的私有合同有关的判例法。建议在选择租户加密策略之前进行风险评估和法律顾问。 + +按实例或按对象加密比按项目、按租户、按主机和按云聚合降序进行加密更可取。这项建议与实施的复杂性和难度相反。目前，在某些项目中，很难或不可能实现像每个租户一样松散的加密。我们建议实现者尽最大努力加密租户数据。 + +通常，数据加密与可靠地销毁租户和每个实例数据的能力呈正相关，只需丢弃密钥即可。应该指出的是，在这样做时，以可靠和安全的方式销毁这些密钥变得非常重要。 + +Opportunities to encrypt data for users are present: +存在为用户加密数据的机会： + +- 对象存储对象 +- 网络数据 + +#### 卷加密 + +OpenStack 中的卷加密功能支持基于每个租户的隐私保护。从 Kilo 版本开始，支持以下功能： + +- 创建和使用加密卷类型，通过仪表板或命令行界面启动 + - 启用加密并选择加密算法和密钥大小等参数 +- iSCSI 数据包中包含的卷数据已加密 +- 如果原始卷已加密，则支持加密备份 +- 仪表板指示卷加密状态。包括卷已加密的指示，并包括算法和密钥大小等加密参数 +- 通过安全包装器与密钥管理服务交互 + - 后端密钥存储支持卷加密，以增强安全性（例如，硬件安全模块 （HSM） 或 KMIP 服务器可用作 barbican 后端密钥存储） + +#### 临时磁盘加密 + +临时磁盘加密功能可解决数据隐私问题。临时磁盘是虚拟主机操作系统使用的临时工作空间。如果不加密，可以在此磁盘上访问敏感的用户信息，并且在卸载磁盘后可能会保留残留信息。从 Kilo 版本开始，支持以下临时磁盘加密功能： + +- 创建和使用加密的 LVM 临时磁盘（注意：目前 OpenStack 计算服务仅支持 LVM 格式的加密临时磁盘） + - 计算配置 ， `nova.conf` 在“[ephemeral_storage_encryption]”部分中具有以下默认参数 + - 选项：“密码 = AES-XTS-plain64” + - 此字段设置用于加密临时存储的密码和模式。NIST建议将AES-XTS专门用于磁盘存储，该名称是使用XTS加密模式的AES加密的简写。可用的密码取决于内核支持。在命令行中，输入“cryptsetup benchmark”以确定可用选项（并查看基准测试结果），或转到 /proc/crypto + - 选项： 'enabled = false' + - 要使用临时磁盘加密，请设置选项：“enabled = true” + - 选项：“key_size = 512” + - 请注意，后端密钥管理器可能存在密钥大小限制，可能需要使用“key_size = 256”，这仅提供 128 位的 AES 密钥大小。除了 AES 所需的加密密钥外，XTS 还需要自己的“调整密钥”。这通常表示为单个大键。在这种情况下，使用 512 位设置，AES 将使用 256 位，XTS 将使用 256 位。（见NIST） +- 通过安全包装器与密钥管理服务交互 + - 密钥管理服务将通过为每个租户提供临时磁盘加密密钥来支持数据隔离 + - 后端密钥存储支持临时磁盘加密，以增强安全性（例如，HSM 或 KMIP 服务器可用作 barbican 后端密钥存储） + - 使用密钥管理服务时，当不再需要临时磁盘时，只需删除密钥即可取代覆盖临时磁盘存储区域 + +#### 对象存储对象 + +对象存储 （swift） 支持对存储节点上的静态对象数据进行可选加密。对象数据的加密旨在降低在未经授权的一方获得对磁盘的物理访问权限时读取用户数据的风险。 + +静态数据加密由中间件实现，中间件可能包含在代理服务器 WSGI 管道中。该功能是 swift 集群内部的，不通过 API 公开。客户端不知道 swift 服务内部的此功能对数据进行了加密;内部加密的数据不应通过 swift API 返回给客户端。 + +以下数据在 swift 中静态时被加密： + +- 对象内容。例如，对象 PUT 请求正文的内容 +- 具有非零内容的对象的实体标记 （ETag） +- 所有自定义用户对象元数据值。例如，使用 `X-Object-Meta-` 带有 PUT 或 POST 请求的前缀标头发送的元数据 + +上述列表中未包含的任何数据或元数据均未加密，包括： + +- 帐户、容器和对象名称 +- 帐户和容器自定义用户元数据值 +- 所有自定义用户元数据名称 +- 对象内容类型值 +- 对象大小 +- 系统元数据 + +有关对象存储加密的部署、操作或实施的更多信息，请参阅有关对象加密的 swift 开发人员文档。 + +#### 块存储性能和后端 + +启用操作系统时，可以使用 Intel 和 AMD 处理器中当前可用的硬件加速功能来增强 OpenStack Volume Encryption 性能。OpenStack 卷加密功能和 OpenStack 临时磁盘加密功能都用于 `dm-crypt` 保护卷数据。 `dm-crypt` 是 Linux 内核版本 2.6 及更高版本中的透明磁盘加密功能。启用卷加密后，加密数据将通过 iSCSI 发送到块存储，从而同时保护传输中的数据和静态数据。使用硬件加速时，这两种加密功能对性能的影响都会降到最低。 + +虽然我们建议使用 OpenStack 卷加密功能，但块存储支持多种替代后端来提供可挂载卷，其中一些还可能提供卷加密。由于后端如此之多，并且必须从每个供应商处获取信息，因此指定在任何一个供应商中实施加密的建议超出了本指南的范围。 + +#### 网络数据 + +计算的租户数据可以通过 IPsec 或其他隧道进行加密。这在OpenStack中并不常见或标准，但对于有动力和感兴趣的实现者来说，这是一个选项。 + +同样，加密数据在通过网络传输时将保持加密状态。 + +### 密钥管理 + +为了解决经常提到的租户数据隐私和限制云提供商责任的问题，OpenStack社区对使数据加密更加普遍的兴趣越来越大。对于最终用户来说，在将数据保存到云之前对其进行加密相对容易，这是租户对象（如媒体文件、数据库存档等）的可行路径。在某些情况下，客户端加密用于加密虚拟化技术保存的数据，这需要客户端交互（例如提供密钥）来解密数据以供将来使用。为了无缝地保护数据并使其可访问，而无需给客户带来管理其密钥的负担，并以交互方式向他们提供 OpenStack 中的密钥管理服务。作为OpenStack的一部分，提供加密和密钥管理服务可以简化静态数据安全采用，并解决客户对隐私或数据滥用的担忧，同时也限制了云提供商的责任。这有助于减少提供商在多租户公有云中的事件调查期间处理租户数据时的责任。 + +卷加密和临时磁盘加密功能依赖于密钥管理服务（例如，barbican）来创建和安全存储密钥。密钥管理器是可插入的，以方便需要第三方硬件安全模块 （HSM） 或使用密钥管理交换协议 （KMIP） 的部署，该协议由名为 PyKMIP 的开源项目支持。 + +#### 参考书目 + +- OpenStack.org，欢迎来到 barbican 的开发者文档！2014。Barbican 开发者文档 +- oasis-open.org，OASIS 密钥管理互操作性协议 （KMIP）。2014年。KMIP +- PyKMIP 库 +- 机密管理 机密管理 + +## 实例安全管理 + +在虚拟化环境中运行实例的优点之一是，它为安全控制开辟了新的机会，而这些控制在部署到裸机上时通常不可用。有几种技术可以应用于虚拟化堆栈，为云租户带来更好的信息保障。 + +具有强烈安全要求的 OpenStack 部署人员或用户可能需要考虑部署这些技术。并非所有情况都适用。在某些情况下，由于规范性业务需求，可能会排除在云中使用技术。同样，某些技术会检查实例数据，例如运行状态，这对系统用户来说可能是不希望的。 + +在本章中，我们将探讨这些技术，并描述它们可用于增强实例或底层实例安全性的情况。我们还试图强调可能存在隐私问题的地方。这些包括数据传递、内省或提供熵源。在本节中，我们将重点介绍以下附加安全服务： + +- 实例的熵 +- 将实例调度到节点 +- 受信任的映像 +- 实例迁移 +- 监控、警报和报告 +- 更新和补丁 +- 防火墙和其他基于主机的安全控制 +- 实例的安全服务 + - 实例的熵 + - 将实例调度到节点 + - 受信任的映像 + - 实例迁移 + - 监控、警报和报告 + - 更新和补丁 + - 防火墙和其他基于主机的安全控制 + +### 实例的安全服务 + +#### 实例的熵 + +我们认为熵是指实例可用的随机数据的质量和来源。加密技术通常严重依赖随机性，需要高质量的熵池才能从中汲取。虚拟机通常很难获得足够的熵来支持这些操作，这称为熵饥饿。熵饥饿可以表现为看似无关的事情。例如，启动时间慢可能是由于实例等待 ssh 密钥生成造成的。熵饥饿还可能促使用户在实例中使用质量较差的熵源，从而使在云中运行的应用程序整体安全性降低。 + +幸运的是，云架构师可以通过为云实例提供高质量的熵源来解决这些问题。这可以通过在云中拥有足够的硬件随机数生成器 （HRNG） 来支持实例来实现。在这种情况下，“足够”在某种程度上是特定于域的。对于日常操作，现代 HRNG 可能会产生足够的熵来支持 50-100 个计算节点。高带宽 HRNG（例如英特尔 Ivy Bridge 和更新的处理器提供的 RdRand 指令）可能会处理更多节点。对于给定的云，架构师需要了解应用程序要求，以确保有足够的熵可用。 + +Virtio RNG 是一个随机数生成器，默认情况下用作 `/dev/random` 熵源，但可以配置为使用硬件 RNG 或熵收集守护程序 （EGD） 等工具，以提供一种通过分布式系统公平安全地分配熵的方法。Virtio RNG 是使用用于创建实例的元数据的 `hw_rng` 属性启用的。 + +#### 将实例调度到节点 + +在创建实例之前，必须选择用于镜像实例化的主机。此选择由 `nova-scheduler` 确定如何分派计算和卷请求的 执行。 + +这是 `FilterScheduler` OpenStack Compute的默认调度程序，尽管存在其他调度程序（请参阅 OpenStack Configuration Reference 中的 Scheduling 部分）。这与“过滤器提示”协同工作，以决定实例的启动位置。此主机选择过程允许管理员满足许多不同的安全性和合规性要求。例如，根据云部署类型，如果数据隔离是主要问题，则可以选择尽可能让租户实例驻留在相同的主机上。相反，出于可用性或容错原因，可以尝试将租户的实例驻留在尽可能多的不同主机上。 + +筛选器计划程序分为四大类： + +基于资源的筛选器 + +这些筛选器将根据虚拟机监控程序主机集的利用率创建实例，并可以在可用或使用的属性（如 RAM、IO 或 CPU 利用率）上触发。 + +基于映像的过滤器 + +这将根据使用的映像（例如 VM 的操作系统或使用的映像类型）委派实例创建。 + +基于环境的过滤器 + +此筛选器将基于外部详细信息创建实例，例如在特定 IP 范围内、跨可用区或与其他实例位于同一主机上。 + +自定义条件 + +此筛选器将根据用户或管理员提供的条件（如信任或元数据分析）委派实例创建。 + +可以同时应用多个筛选器，例如，筛选器用于确保在一组特定主机的成员上创建实例，以及 `ServerGroupAntiAffinity` 用于确保不会在另一组特定主机上创建同一实例的筛选器 `ServerGroupAffinity` 。应仔细分析这些筛选器，以确保它们不会相互冲突，并导致阻止创建实例的规则。 + +![../_images/filteringWorkflow1.png](https://docs.openstack.org/security-guide/_images/filteringWorkflow1.png) + +`GroupAffinity` 和 `GroupAntiAffinity` 筛选器冲突，不应同时启用。 + +筛选器 `DiskFilter` 能够超额订阅磁盘空间。虽然通常不是问题，但对于精简预配的存储设备来说，这可能是一个问题，并且此筛选器应与应用经过充分测试的配额一起使用。 + +我们建议您禁用过滤器，这些过滤器可以分析用户提供的内容或可操作的内容，例如元数据。 + +#### 可信镜像 + +在云环境中，用户使用预安装的映像或他们自己上传的映像。在这两种情况下，用户都应该能够确保他们正在使用的图像没有被篡改。验证图像的能力是安全性的基本要求。从映像源到使用映像的目标需要信任链。这可以通过对从受信任来源获取的映像进行签名并在使用前验证签名来实现。下面将讨论获取和创建已验证图像的各种方法，然后介绍图像签名验证功能。 + +##### 镜像创建过程 + +OpenStack 文档提供了有关如何创建映像并将其上传到映像服务的指导。此外，假定您有一个安装和强化操作系统的过程。因此，以下各项将提供有关如何确保将映像安全地传输到 OpenStack 中的额外指导。有多种选项可用于获取图像。每个步骤都有特定的步骤，有助于验证图像的出处。 + +第一个选项是从受信任的来源获取启动媒体。 + +```shell +$ mkdir -p /tmp/download_directorycd /tmp/download_directory +$ wget http://mirror.anl.gov/pub/ubuntu-iso/CDs/precise/ubuntu-12.04.2-server-amd64.iso +$ wget http://mirror.anl.gov/pub/ubuntu-iso/CDs/precise/SHA256SUMS +$ wget http://mirror.anl.gov/pub/ubuntu-iso/CDs/precise/SHA256SUMS.gpg +$ gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 0xFBB75451 +$ gpg --verify SHA256SUMS.gpg SHA256SUMSsha256sum -c SHA256SUMS 2>&1 | grep OK +``` + +第二种选择是使用 OpenStack 虚拟机映像指南。在这种情况下，您需要遵循组织的操作系统强化准则或受信任的第三方（如 Linux STIG）提供的准则。 + +最后一种选择是使用自动映像生成器。以下示例使用 Oz 映像生成器。OpenStack 社区最近创建了一个值得研究的新工具：disk-image-builder。我们尚未从安全角度评估此工具。 + +RHEL 6 CCE-26976-1 示例，这将有助于在 OZ 中实施 NIST 800-53 第 AC-19（d）节。 + +```shell + +``` + +建议避免手动映像构建过程，因为它很复杂且容易出错。此外，使用 Oz 等自动化系统进行映像构建，或使用 Chef 或 Puppet 等配置管理实用程序进行启动后映像强化，使您能够生成一致的映像，并跟踪基础映像在一段时间内是否符合其各自的强化准则。 + +如果订阅公有云服务，则应与云提供商联系，了解用于生成其默认映像的过程的概述。如果提供商允许您上传自己的映像，则需要确保在使用映像创建实例之前能够验证映像是否未被修改。为此，请参阅以下有关图像签名验证的部分，如果无法使用签名，请参阅以下段落。 + +映像从节点上的映像服务传输到计算服务。应通过通过 TLS 运行来保护此传输。映像位于节点上后，将使用基本校验和对其进行验证，然后根据要启动的实例的大小扩展其磁盘。如果稍后在此节点上以相同的实例大小启动同一映像，则会从同一扩展映像启动该映像。由于此扩展映像在启动前默认不会重新验证，因此它可能已被篡改。除非在生成的映像中对文件执行手动检查，否则用户不会意识到篡改。 + +##### 映像签名验证 + +OpenStack 中现在提供了一些与映像签名相关的功能。从 Mitaka 版本开始，映像服务可以验证这些已签名的映像，并且为了提供完整的信任链，计算服务可以选择在映像启动之前执行映像签名验证。在映像启动之前成功进行签名验证可确保已签名的映像未更改。启用此功能后，可以检测到未经授权的映像修改（例如，修改映像以包含恶意软件或 rootkit）。 + +管理员可以通过在文件中将 `verify_glance_signatures` 标志设置为来 `True` 启用实例签名 `/etc/nova/nova.conf` 验证。启用后，计算服务会在从影像服务检索签名实例时自动对其进行验证。如果此验证失败，则不会启动。《OpenStack 操作指南》提供了有关如何创建和上传签名映像以及如何使用此功能的指导。有关更多信息，请参阅《操作指南》中的添加签名映像。 + +#### 实例迁移 + +OpenStack 和底层虚拟化层提供在 OpenStack 节点之间实时迁移映像，使您能够无缝地执行 OpenStack 计算节点的滚动升级，而无需实例停机。但是，实时迁移也存在重大风险。若要了解所涉及的风险，以下是在实时迁移期间执行的高级步骤： + +1. 在目标主机上启动实例 +2. 传输内存 +3. 停止客户机和同步磁盘 +4. 传输状态 +5. 启动客户机 + +##### 实时迁移风险 + +在实时迁移过程的各个阶段，实例运行时、内存和磁盘的内容以纯文本形式通过网络传输。因此，在使用实时迁移时需要解决一些风险。以下详尽列表详细介绍了其中的一些风险： + +- 拒绝服务 （DoS）：如果在迁移过程中出现故障，实例可能会丢失。 +- 数据泄露：必须安全地处理内存或磁盘传输。 +- 数据操纵：如果内存或磁盘传输未得到安全处理，则攻击者可以在迁移过程中操纵用户数据。 +- 代码注入：如果内存或磁盘传输未得到安全处理，则攻击者可以在迁移期间操纵磁盘或内存中的可执行文件。 + +##### 实时迁移缓解措施 + +有几种方法可以缓解与实时迁移相关的一些风险，以下列表详细介绍了其中的一些方法： + +- 禁用实时迁移 +- I隔离的迁移网络 +- 加密实时迁移 + +##### 禁用实时迁移 + +目前，OpenStack 中默认启用实时迁移。可以通过向 nova `policy.json` 文件添加以下行来禁用实时迁移： + +```shell +{ + "compute_extension:admin_actions:migrate": "!", + "compute_extension:admin_actions:migrateLive": "!", +} +``` + +##### 迁移网络 + +一般做法是，实时迁移流量应限制在管理安全域内，请参阅安全边界和威胁。对于实时迁移流量，由于其纯文本性质以及您正在传输正在运行的实例的磁盘和内存内容，因此建议您进一步将实时迁移流量分离到专用网络上。将流量隔离到专用网络可以降低暴露风险。 + +##### 加密实时迁移 + +如果有足够的业务案例来保持实时迁移的启用状态，则 libvirtd 可以为实时迁移提供加密隧道。但是，此功能目前尚未在 OpenStack Dashboard 或 nova-client 命令中公开，只能通过手动配置 libvirtd 来访问。然后，实时迁移过程将更改为以下高级步骤： + +1. 实例数据从虚拟机管理程序复制到 libvirtd。 +2. 在源主机和目标主机上的 libvirtd 进程之间创建加密隧道。 +3. 目标 libvirtd 主机将实例复制回底层虚拟机管理程序。 + +#### 监控、告警和报告 + +由于 OpenStack 虚拟机是能够跨主机复制的服务器映像，因此日志记录的最佳实践同样适用于物理主机和虚拟主机。应记录操作系统级和应用程序级事件，包括对主机和数据的访问事件、用户添加和删除、权限更改以及环境规定的其他事件。理想情况下，您可以将这些日志配置为导出到日志聚合器，该聚合器收集日志事件，将它们关联起来进行分析，并存储它们以供参考或进一步操作。实现此目的的一个常见工具是 ELK 堆栈，即 Elasticsearch、Logstash 和 Kibana。 + +应定期查看这些日志，例如由网络运营中心 （NOC） 实时查看，或者如果环境不够大而不需要 NOC，则日志应定期进行日志审查过程。 + +很多时候，有趣的事件会触发警报，该警报将发送给响应方以采取行动。通常，此警报采用包含相关消息的电子邮件形式。一个有趣的事件可能是重大故障，也可能是挂起故障的已知运行状况指示器。用于管理告警的两个常见实用程序是 Nagios 和 Zabbix。 + +#### 更新和补丁 + +虚拟机监控程序运行独立的虚拟机。此虚拟机管理程序可以在操作系统中运行，也可以直接在硬件上运行（称为裸机）。对虚拟机监控程序的更新不会向下传播到虚拟机。例如，如果部署使用的是 XenServer，并且具有一组 Debian 虚拟机，则对 XenServer 的更新不会更新 Debian 虚拟机上运行的任何内容。 + +因此，我们建议分配虚拟机的明确所有权，并由这些所有者负责虚拟机的强化、部署和持续功能。我们还建议定期部署更新。这些补丁应在尽可能接近生产环境的环境中进行测试，以确保补丁背后的问题的稳定性和解决方案。 + +#### 防火墙和其他基于主机的安全控制 + +最常见的操作系统包括基于主机的防火墙，以提高安全性。虽然我们建议虚拟机运行尽可能少的应用程序（如果可能的话，达到单一用途实例的程度），但应分析虚拟机上运行的所有应用程序，以确定应用程序需要访问哪些系统资源、运行所需的最低特权级别，以及将进出虚拟机的预期网络流量。此预期流量应作为允许的流量（或列入白名单）添加到基于主机的防火墙中，以及任何必要的日志记录和管理通信，例如 SSH 或 RDP。应在防火墙配置中明确拒绝所有其他流量。 + +在 Linux 虚拟机上，上述应用程序配置文件可以与 audit2allow 等工具结合使用，以构建 SELinux 策略，以进一步保护大多数 Linux 发行版上的敏感系统信息。SELinux 使用用户、策略和安全上下文的组合来划分应用程序运行所需的资源，并将其与其他不需要的系统资源区分开来。 + +OpenStack 为主机和网络提供安全组，以增加对给定项目中虚拟机的深度防御。这些规则类似于基于主机的防火墙，因为它们根据端口、协议和地址允许或拒绝传入流量，但安全组规则仅适用于传入流量，而基于主机的防火墙规则能够应用于传入和传出流量。主机和网络安全组规则也可能发生冲突并拒绝合法流量。我们建议确保为正在使用的网络正确配置安全组。有关详细信息，请参阅本指南中的安全组。 + +## 监视和日志记录 + +在云环境中，硬件、操作系统、虚拟机管理器、OpenStack 服务、云用户活动（例如创建实例和附加存储）、网络以及使用在各种实例上运行的应用程序的最终用户混合在一起。 + +日志记录的基础知识：配置、设置日志级别、日志文件的位置、如何使用和自定义日志，以及如何集中收集日志，这些在 OpenStack 操作指南中都有很好的介绍。 + +- 取证和事件响应 + - 监控用例 + - 参考书目 + +### 取证和事件响应 + +日志的生成和收集是安全监控 OpenStack 基础架构的重要组成部分。日志提供对管理员、租户和来宾日常操作的可见性，以及计算、网络和存储以及构成 OpenStack 部署的其他组件中的活动。 + +日志不仅对主动安全和持续合规性活动很有价值，而且也是调查和响应事件的宝贵信息源。 + +例如，分析身份服务或其替代身份验证系统的访问日志会提醒我们登录失败、频率、源 IP、事件是否仅限于选择帐户和其他相关信息。日志分析支持检测。 + +可以采取措施来缓解潜在的恶意活动，例如将 IP 地址列入黑名单、建议加强用户密码或停用被视为休眠的用户帐户。 + +#### 监控用例 + +事件监控是一种更主动的方法，可以保护环境，提供实时检测和响应。有几种工具可以帮助进行监控。 + +对于OpenStack云实例，我们需要监控硬件、OpenStack服务和云资源使用情况。后者源于希望具有弹性，以适应用户的动态需求。 + +以下是在实施日志聚合、分析和监控时需要考虑的几个重要用例。这些用例可以通过各种应用程序、工具或脚本来实现和监控。有开源和商业解决方案，一些运营商开发自己的内部解决方案。这些工具和脚本可以生成事件，这些事件可以通过电子邮件发送给管理员或在集成仪表板中查看。请务必考虑可能适用于您的特定网络的其他用例，以及您可能认为的异常行为。 + +- 检测日志生成缺失是一个具有很高价值的事件。此类事件将表明服务失败，甚至表示入侵者暂时关闭了日志记录或修改了日志级别以隐藏其踪迹。 +- 应用程序事件（如计划外的启动或停止事件）也是要监视和检查可能的安全隐患的事件。 +- OpenStack 服务机器上的操作系统事件（如用户登录或重新启动）也为系统的正确和不当使用提供了有价值的见解。 +- 能够检测OpenStack服务器上的负载还可以通过引入其他服务器进行负载平衡来做出响应，以确保高可用性。 +- 其他可操作的事件包括网络网桥关闭、计算节点上的 IP 表被刷新，以及随之而来的对实例的访问丢失，导致客户不满意。 +- 为了降低在身份服务中删除用户、租户或域时孤立实例的安全风险，我们讨论了在系统中生成通知，并让 OpenStack 组件适当地响应这些事件，例如终止实例、断开连接的卷、回收 CPU 和存储资源等。 + +云将托管许多虚拟实例，并且监视这些实例超出了可能仅包含 CRUD 事件的硬件监视和日志文件。 + +安全监控控制（如入侵检测软件、防病毒软件以及间谍软件检测和删除实用程序）可以生成日志，显示攻击或入侵发生的时间和方式。在云计算机上部署这些工具可提供价值和保护。云用户，即在云上运行实例的用户，可能也希望在其实例上运行此类工具。 + +#### 参考书目 + +Siwczak, Piotr，在 OpenStack 云中进行监控的一些实际注意事项。2012. + +blog.sflow.com， sflow：主机 sFlow 分布式代理。2012. + +blog.sflow.com，sflow：LAN 和 WAN。2009. + +blog.sflow.com、sflow：快速检测大流量 sFlow 与 NetFlow/IPFIX。2013. + +## 合规 + +OpenStack 部署可能需要出于多种目的进行合规性活动，例如法规和法律要求、客户需求、隐私注意事项和安全最佳实践。合规功能对企业及其客户很重要。合规意味着遵守法规、规范、标准和法律。它还用于描述有关评估、审核和认证的组织状态。如果操作得当，合规性可以统一和加强本指南中讨论的其他安全主题。 + +本章有几个目标： + +- 查看常见的安全原则。 +- 讨论常见的控制框架和认证资源，以实现行业认证或监管机构认证。 +- 在评估 OpenStack 部署时，可作为审计人员的参考。 +- 介绍特定于 OpenStack 和云环境的隐私注意事项。 +- 合规性概述 + - 安全原则 + - 常见控制框架 + - 审核参考 +- 了解审核流程 + - 确定审计范围 + - 审计阶段 + - 内部审计 + - 准备外部审计 + - 外部审计 + - 合规性维护 +- 合规活动 + - 信息安全管理系统（ISMS） + - 风险评估 + - 访问和日志审查 + - 备份和灾难恢复 + - 安全培训 + - 安全审查 + - 漏洞管理 + - 数据分类 + - 异常过程 +- 认证和合规声明 + - 商业标准 + - 政府标准 +- 隐私 + +### 合规性概述 + +#### 安全原则 + +行业标准安全原则为合规性认证和证明提供了基准。如果在整个 OpenStack 部署过程中考虑和引用这些原则，则可以简化认证活动。 + +##### 分层防御 + +确定云架构中存在风险的位置，并应用控制措施来降低风险。在重大关注领域，分层防御提供多种互补控制，将风险管理到可接受的水平。例如，为了确保云租户之间的充分隔离，我们建议强化 QEMU，使用支持 SELinux 的虚拟机管理程序，实施强制访问控制策略，并减少整体攻击面。基本原则是用多层防御来强化关注区域，这样，如果任何一层受到损害，其他层将存在以提供保护并最大限度地减少暴露。 + +##### 安全失败 + +在发生故障的情况下，系统应配置为在关闭的安全状态中失败。例如，如果TLS证书验证未通过，即CNAME与服务器的DNS名称不匹配，应通过切断网络连接来安全失败。在这种情况下，软件通常会以开放方式失败，允许连接在没有CNAME匹配的情况下继续进行，这样不够安全，也不建议。 + +##### 最小权限 + +仅授予用户和系统服务的最低访问级别。这种访问基于角色、职责和工作职能。这种最小特权安全原则已写入多个国际政府安全策略中，例如美国境内的 NIST 800-53 第 AC-6 节。 + +##### 分隔 + +系统应以这样一种方式隔离，即如果一台计算机或系统级服务受到损害，其他系统的安全性将保持不变。实际上，SELinux 的启用和正确使用有助于实现这一目标。 + +##### 促进隐私 + +应尽量减少可以收集的有关系统及其用户的信息量。 + +##### 日志记录能力 + +实施适当的日志记录以监控未经授权的使用、事件响应和取证。我们强烈建议选定的审计子系统通过通用标准认证，该标准在大多数国家/地区提供不可证明的事件记录。 + +#### 常用控制框架 + +以下是组织可用于构建其安全控制的控制框架列表。 + +云安全联盟 （CSA） 通用控制矩阵 （CCM） + +CSA CCM 专门用于提供基本的安全原则，以指导云供应商并帮助潜在的云客户评估云提供商的整体安全风险。CSA CCM 提供了一个跨 16 个安全域保持一致的控制框架。云控制矩阵的基础在于其与其他行业标准、法规和控制框架的定制关系，例如：ISO 27001：2013、COBIT 5.0、PCI：DSS v3、AICPA 2014 信任服务原则和标准，并增强了服务组织控制报告证明的内部控制方向。 + +CSA CCM 通过减少云中的安全威胁和漏洞来加强现有的信息安全控制环境，提供标准化的安全和运营风险管理，并寻求规范化安全期望、云分类和术语以及在云中实施的安全措施。 + +ISO 27001/2:2013 ISO 27001/2：2013 认证 + +ISO 27001 信息安全标准和认证多年来一直用于评估和区分组织是否符合信息安全最佳实践。该标准由两部分组成：定义信息安全管理系统 （ISMS） 的强制性条款和包含按领域组织的控制列表的附录 A。 + +信息安全管理系统通过应用风险管理流程来保持信息的机密性、完整性和可用性，并使相关方相信风险得到充分管理。 + +可信安全原则 + +信托服务是一套基于一套核心原则和标准的专业认证和咨询服务，用于解决 IT 系统和隐私计划的风险和机遇。通常称为 SOC 审计，这些原则定义了要求是什么，组织有责任定义满足要求的控制措施。 + +#### 审计参考 + +OpenStack在许多方面都是创新的，但是用于审计OpenStack部署的过程相当普遍。审核员将根据两个标准评估流程：控制是否有效设计以及控制是否有效运行。了解审计师如何评估控制措施是否有效设计和运行，将在“了解审计过程”一节中讨论。 + +用于审核和评估云部署的最常见框架包括前面提到的 ISO 27001/2 信息安全标准、ISACA 的信息和相关技术控制目标 （COBIT） 框架、特雷德韦委员会赞助组织委员会 （COSO） 和信息技术基础设施库 （ITIL）。审计通常包括一个或多个这些框架中的重点领域。幸运的是，这些框架之间有很多重叠，因此采用框架的组织将在审计时处于有利地位。 + +### 了解审核流程 + +信息系统安全合规性依赖于两个基本流程的完成： + +安全控制的实施和操作 + +使信息系统与范围内的标准和法规保持一致涉及内部任务，这些任务必须在正式评估之前进行。审核员可能会参与此状态，以进行差距分析，提供指导，并增加成功认证的可能性。 + +独立验证和确认 + +在许多信息系统获得认证状态之前，需要向中立的第三方证明系统安全控制已实施并有效运行，符合范围内的标准和法规。许多认证需要定期审核，以确保持续认证，这被认为是总体持续监控实践的一部分。 + +#### 确定审计范围 + +确定审计范围，特别是需要哪些控制措施，以及如何设计或修改OpenStack部署以满足这些控制措施，应该是最初的规划步骤。 + +在出于合规性目的确定 OpenStack 部署范围时，应优先考虑对敏感服务的控制，例如命令和控制功能以及基本虚拟化技术。这些设施的妥协可能会影响整个 OpenStack 环境。 + +缩小范围有助于确保 OpenStack 架构师建立针对特定部署量身定制的高质量安全控制，但最重要的是确保这些实践不会遗漏安全强化中的区域或功能。一个常见的例子是PCI-DSS准则，其中与支付相关的基础设施可能会受到安全问题的审查，但支持服务被忽视，并且容易受到攻击。 + +在解决合规性问题时，您可以通过确定适用于多个认证的常见领域和标准来提高效率并减少工作量。本书中讨论的许多审计原则和准则将有助于确定这些控制措施，此外，一些外部实体提供了全面的清单。以下是一些示例： + +云安全联盟云控制矩阵 （CCM） 可帮助云提供商和消费者评估云提供商的整体安全性。CSA CMM 提供了一个控制框架，该框架映射到许多行业公认的标准和法规，包括 ISO 27001/2、ISACA、COBIT、PCI、NIST、Jericho Forum 和 NERC CIP。 + +《SCAP 安全指南》是另一个有用的参考。这仍然是一个新兴的来源，但我们预计这将发展成为一个工具，其控件映射更侧重于美国联邦政府的认证和建议。例如，SCAP 安全指南目前包含安全技术实施指南 （STIG） 和 NIST-800-53 的一些映射。 + +这些控制映射将有助于识别跨认证的通用控制标准，并为审核员和被审核方提供对特定合规性认证和证明的控制集中问题区域的可见性。 + +#### 审计的阶段 + +审计有四个不同的阶段，尽管大多数利益相关者和控制所有者只会参与一两个阶段。四个阶段是规划、实地考察、报告和总结。下面将讨论这些阶段中的每一个。 + +规划阶段通常在实地工作开始前两周到六个月进行。在此阶段，将讨论并最终确定时间范围、时间表、要评估的控制措施和控制所有者等审计项目。对资源可用性、公正性和成本的担忧也得到了解决。 + +实地考察阶段是审计中最明显的部分。这是审计员在现场的地方，与控制所有者面谈，记录现有的控制措施，并确定任何问题。需要注意的是，审计师将使用两部分流程来评估现有的控制措施。第一部分是评估控制的设计有效性。在这里，审计员将评估控制是否能够有效地预防或检测和纠正弱点和缺陷。控件必须通过此测试才能在第二阶段进行评估。这是因为对于设计无效的控件，没有必要考虑它是否有效运行。第二部分是运营效率。操作有效性测试将确定如何应用控制措施，应用控制措施的一致性以及由谁或以何种方式应用控制措施。一项控制可能依赖于其他控制（间接控制），如果它们依赖于其他控制，则审计师可能需要额外的证据来证明这些间接控制的运作有效性，以确定控制的整体运作有效性。 + +在报告阶段，管理层将对在实地工作阶段发现的任何问题进行验证。出于后勤目的，一些活动（例如问题验证）可能会在实地工作阶段执行。管理层还需要提供补救计划来解决问题，并确保它们不会再次发生。将向利益攸关方和管理层分发一份总体报告草稿，供其审查。商定的修改被纳入，更新后的草案将送交高级管理层审查和批准。一旦高级管理层批准报告，该报告就会定稿并分发给执行管理层。任何问题都会输入到组织使用的问题跟踪或风险跟踪机制中。 + +总结阶段是审计正式终止的地方。此时，管理层将开始整改活动。使用过程和通知确保将任何与审计相关的信息都被移至安全存储库0。 + +#### 内部审计 + +部署云后，就该进行内部审计了。现在是时候将上面确定的控件与云中使用的设计、功能和部署策略进行比较了。目标是了解每个控件的处理方式以及存在差距的位置。记录所有发现以备将来参考。 + +在审计OpenStack云时，了解OpenStack架构固有的多租户环境是很重要的。需要关注的一些关键领域包括数据处置、虚拟机管理程序安全性、节点强化和身份验证机制。 + +#### 准备外部审计 + +一旦内部审计结果看起来不错，就该为外部审计做准备了。在此阶段需要采取几项关键行动，这些行动概述如下： + +- 保持内部审计的良好记录。这些将在外部审计期间证明很有用，因此您可以准备好回答有关将合规性控制映射到特定部署的问题。 +- 部署自动化测试工具，确保云长期保持合规。 +- 选择审计员。 + +选择审计师可能具有挑战性。理想情况下，您正在寻找具有云合规性审核经验的人。OpenStack经验是另一大优势。通常，最好咨询经历过此过程的人进行转诊。成本可能会因参与范围和所考虑的审计公司而有很大差异。 + +#### 外部审计 + +这是正式的审计过程。审计员将测试特定认证范围内的安全控制措施，并要求提供证据要求，以证明这些控制措施在审计窗口内也已到位（例如，SOC 2 审计通常在 6-12 个月内评估安全控制措施）。任何控制失败都会被记录下来，并将记录在外部审计师的最终报告中。根据 OpenStack 部署的类型，客户可能会查看这些报告，因此避免控制失败非常重要。这就是为什么审计准备如此重要的原因。 + +#### 合规性维护 + +该过程不会因单一的外部审计而结束。大多数认证都需要持续的合规活动，这意味着要定期重复审核过程。我们建议将自动合规性验证工具集成到云中，以确保其始终合规。除了其他安全监控工具之外，还应该这样做。请记住，目标既是安全性，也是合规性。如果在上述任何一项方面都失败，将使未来的审计变得非常复杂。 + +### 合规活动 + +有许多标准活动将极大地帮助合规过程。本章概述了一些最常见的合规性活动。这些并不是OpenStack所特有的，但是本书中提供了相关章节的参考资料，作为有用的上下文。 + +#### 信息安全管理系统 （ISMS） + +信息安全管理系统 （ISMS） 是组织创建和维护的一套全面的策略和流程，用于管理信息资产的风险。云部署最常见的 ISMS 是 ISO/IEC 27001/2，它为安全控制和实践奠定了坚实的基础，以实现更严格的合规性认证。该标准于 2013 年进行了更新，以反映云服务的日益使用，并更加强调衡量和评估组织的 ISMS 性能。 + +#### 风险评估 + +风险评估框架可识别组织或服务中的风险，并指定这些风险的所有权，以及实施和缓解策略。风险适用于服务的所有领域，从技术控制到环境灾难场景和人为因素。例如，恶意内部人员。可以使用多种机制对风险进行评级。例如，可能性与影响。OpenStack 部署风险评估可以包括控制差距。 + +#### 访问和日志审查 + +需要定期访问和日志审查，以确保服务部署中的身份验证、授权和问责制。有关这些主题的 OpenStack 的具体指南在监控和日志记录中进行了深入讨论。 + +OpenStack Identity 服务支持云审计数据联合 （CADF） 通知，提供审计数据以符合安全性、操作和业务流程。有关更多信息，请参阅 Keystone 开发人员文档。 + +#### 备份和灾难恢复 + +灾难恢复 （DR） 和业务连续性规划 （BCP） 计划是 ISMS 和合规性活动的常见要求。这些计划必须定期测试并记录在案。在 OpenStack 中，关键区域位于管理安全域中，以及任何可以识别单点故障 （SPOF） 的地方。 + +#### 安全培训 + +针对特定角色的年度安全培训是几乎所有合规性认证和证明的强制性要求。为了优化安全培训的有效性，一种常见的方法是提供特定于角色的培训，例如向开发人员、操作人员和非技术人员提供培训。基于此强化指南的其他云安全或 OpenStack 安全培训将是理想的选择。 + +#### 安全审查 + +由于OpenStack是一个流行的开源项目，因此许多代码库和架构已经过个人贡献者、组织和企业的审查。从安全角度来看，这可能是有利的，但是对于服务提供商来说，安全审查的需求仍然是一个关键的考虑因素，因为部署各不相同，而且安全性并不总是贡献者的主要关注点。全面的安全审查过程可能包括架构审查、威胁建模、源代码分析和渗透测试。有许多用于进行安全审查的技术和建议，可以在公开发布中找到。一个经过充分测试的例子是 Microsoft SDL，它是作为 Microsoft 可信计算计划的一部分创建的。 + +#### 漏洞管理 + +安全更新对于任何 IaaS 部署（无论是私有部署还是公共部署）都至关重要。易受攻击的系统扩大了攻击面，是攻击者的明显目标。常见的扫描技术和漏洞通知服务可以帮助缓解这种威胁。重要的是，扫描要经过身份验证，并且缓解策略要超越简单的外围强化。OpenStack 等多租户架构特别容易受到虚拟机管理程序漏洞的影响，因此这是漏洞管理系统的关键部分。 + +#### 数据分类 + +数据分类定义了一种对信息进行分类和处理的方法，通常用于保护客户信息免遭意外或故意盗窃、丢失或不当披露。最常见的情况是，这涉及将信息分类为敏感或非敏感信息，或个人身份信息 （PII）。根据部署的上下文，可以使用各种其他分类标准（政府、医疗保健）。基本原则是明确定义和使用数据分类。最常见的保护机制包括行业标准加密技术。 + +#### 异常过程 + +异常过程是 ISMS 的重要组成部分。当某些操作不符合组织定义的安全策略时，必须记录这些操作。需要包括适当的理由、描述和缓解细节，并由有关当局签署。OpenStack 默认配置在满足各种合规性标准方面可能会有所不同，应记录不符合合规性要求的区域，并考虑潜在的修复程序以对社区做出贡献。 + +### 认证和合规声明 + +合规性和安全性不是排他性的，必须一起解决。如果不进行安全强化，OpenStack 部署不太可能满足合规性要求。下面的列表提供了 OpenStack 架构师的基础知识和指导，以实现对商业和政府认证和标准的合规性。 + +#### 商业标准 + +对于OpenStack的商业部署，我们建议将SOC 1/2与ISO 2700 1/2相结合，作为OpenStack认证活动的起点。这些认证规定的所需安全活动有助于为安全最佳实践和通用控制标准奠定基础，从而有助于实现更严格的合规性活动，包括政府证明和认证。 + +完成这些初始认证后，其余认证将更加特定于部署。例如，处理信用卡交易的云需要 PCI-DSS，存储医疗保健信息的云需要 HIPAA，联邦政府内部的云可能需要 FedRAMP/FISMA 和 ITAR 认证。 + +##### SOC 1 （SSAE 16） / ISAE 3402 + +服务组织控制 （SOC） 标准由美国注册会计师协会 （AICPA） 定义。SOC 控制评估服务提供商的相关财务报表和断言，例如是否遵守《萨班斯-奥克斯利法案》。 SOC 1 取代了审计准则第 70 号声明 （SAS 70） II 类报告。这些控制措施通常包括范围内的物理数据中心。 + +有两种类型的 SOC 1 报告： + +- 类型 1 - 报告管理层对服务组织系统的描述的公允性，以及控制设计是否适合实现截至指定日期的描述中包含的相关控制目标。 +- 类型 2 - 报告管理层对服务组织系统的描述的公允性，以及控制措施的设计和运营有效性是否适合在特定时期内实现描述中包含的相关控制目标 + +有关详细信息，请参阅AICPA关于与用户实体财务报告内部控制相关的服务组织控制的报告。 + +##### SOC 2 函数 + +服务组织控制 （SOC） 2 是对影响服务组织用于处理用户数据的系统的安全性、可用性和处理完整性以及这些系统处理的信息的机密性和隐私性的控制的自我证明。用户示例包括负责服务组织治理的人员、服务组织的客户、监管机构、业务合作伙伴、供应商以及了解服务组织及其控制措施的其他人员。 + +有两种类型的 SOC 2 报告： + +- 类型 1 - 报告管理层对服务组织系统的描述的公允性，以及控制设计是否适合实现截至指定日期的描述中包含的相关控制目标。 +- 类型 2 - 报告管理层对服务组织系统的描述的公允性，以及控制的设计和运营有效性的适用性，以在特定时期内实现描述中包含的相关控制目标。 + +有关详细信息，请参阅 AICPA 关于服务组织中与安全性、可用性、处理完整性、机密性或隐私相关的控制的报告。 + +##### SOC 3 函数 + +服务组织控制 （SOC） 3 是服务组织的信任服务报告。这些报告旨在满足以下用户的需求：这些用户希望确保服务组织中与安全性、可用性、处理完整性、机密性或隐私相关的控制措施，但没有有效使用 SOC 2 报告所需的知识。这些报告是根据 AICPA/加拿大特许会计师协会 （CICA） 关于安全性、可用性、处理完整性、机密性和隐私的信托服务原则、标准和插图编写的。由于 SOC 3 报告是通用报告，因此可以作为印章自由分发或发布在网站上。 + +有关详细信息，请参阅服务组织的 AICPA 信任服务报告。 + +##### ISO 27001/2 认证 + +ISO/IEC 27001/2 标准取代了 BS7799-2，是信息安全管理体系 （ISMS） 的规范。ISMS 是组织为管理信息资产风险而创建和维护的一整套策略和过程。这些风险基于用户信息的机密性、完整性和可用性 （CIA）。中央情报局的安全三合会已被用作本书大部分章节的基础。 + +有关详细信息，请参阅 ISO 27001。 + +##### HIPAA / HITECH + +健康保险流通与责任法案 （HIPAA） 是美国国会的一项法案，用于管理患者健康记录的收集、存储、使用和销毁。该法案规定，受保护的健康信息（PHI）必须对未经授权的人员“不可用、不可读或无法破译”，并且应解决“静态”和“动态”数据的加密问题。 + +HIPAA 不是认证，而是保护医疗保健数据的指南。与 PCI-DSS 类似，PCI 和 HIPPA 最重要的问题是不会发生信用卡信息和健康数据泄露的情况。在发生违规行为时，将仔细审查云提供商是否符合 PCI 和 HIPPA 控制措施。如果证明合规，提供商将立即实施补救控制、违规通知责任以及用于额外合规活动的大量支出。如果不合规，云提供商可能会面临现场审计团队、罚款、潜在的商家 ID （PCI） 丢失以及巨大的声誉影响。 + +拥有 PHI 的用户或组织必须支持 HIPAA 要求，并且是 HIPAA 涵盖的实体。如果实体打算使用某项服务，或者在本例中，使用可能使用、存储或访问该 PHI 的 OpenStack 云，则必须签署业务伙伴协议 （BAA）。BAA 是 HIPAA 涵盖的实体与 OpenStack 服务提供商之间的合同，要求提供商根据 HIPAA 要求处理该 PHI。如果服务提供商不处理 PHI，例如安全控制和强化，那么他们将受到 HIPAA 的罚款和处罚。 + +OpenStack 架构师解释和响应 HIPAA 声明，数据加密仍然是核心实践。目前，这将要求使用行业标准加密算法对 OpenStack 部署中包含的任何受保护的健康信息进行加密。未来潜在的OpenStack项目，如对象加密，将促进HIPAA准则的遵守。 + +有关详细信息，请参阅《健康保险流通与责任法案》。 + +##### PCI-DSS + +支付卡行业数据安全标准 （PCI DSS） 由支付卡行业标准委员会定义，旨在加强对持卡人数据的控制，以减少信用卡欺诈。年度合规性验证由外部合格安全评估机构 （QSA） 进行评估，该评估机构会根据持卡人的交易量创建合规报告 （ROC），或通过自我评估问卷 （SAQ） 进行评估。 + +存储、处理或传输支付卡详细信息的 OpenStack 部署在 PCI-DSS 的范围内。所有未从处理支付数据的系统或网络中正确分割的 OpenStack 组件都属于 PCI-DSS 的准则。PCI-DSS 上下文中的分段不支持多租户，而是物理分离（主机/网络）。 + +有关详细信息，请参阅 PCI 安全标准。 + +#### 政府标准 + +##### FedRAMP + +“联邦风险和授权管理计划 （FedRAMP） 是一项政府范围的计划，它为云产品和服务的安全评估、授权和持续监控提供了一种标准化方法”。NIST 800-53 是 FISMA 和 FedRAMP 的基础，后者要求专门选择安全控制以在云环境中提供保护。由于安全控制的特殊性以及满足政府标准所需的文档量，FedRAMP 可能非常密集。 + +有关详细信息，请参阅 FedRAMP。 + +##### ITAR + +《国际武器贸易条例》（ITAR） 是一套美国政府法规，用于控制美国军需品清单 （USML） 和相关技术数据中与国防相关的物品和服务的进出口。ITAR通常被云提供商视为“操作一致性”，而不是正式认证。这通常涉及按照 FISMA 要求，遵循基于 NIST 800-53 框架的做法实施隔离的云环境，并辅以限制仅访问“美国人”和背景筛选的额外控制措施。 + +有关详细信息，请参阅《国际武器贸易条例》（ITAR）。 + +##### FISMA + +《联邦信息安全管理法》要求政府机构制定一项全面的计划，以实施众多政府安全标准，并在 2002 年的《电子政务法》中颁布。FISMA概述了一个过程，该过程利用多个NIST出版物，准备了一个信息系统来存储和处理政府数据。 + +此过程分为三个主要类别： + +系统分类： + +信息系统将收到联邦信息处理标准出版物 199 （FIPS 199） 中定义的安全类别。这些类别反映了系统入侵的潜在影响。 + +控件选择： + +根据 FIPS 199 中定义的系统安全类别，组织利用 FIPS 200 来确定信息系统的特定安全控制要求。例如，如果系统被归类为“中等”，则可能会引入强制要求“安全密码”的要求。 + +控制定制： + +一旦确定了系统安全控制措施，OpenStack 架构师将利用 NIST 800-53 来提取量身定制的控制措施选择。例如，规范什么是“安全密码”。 + +### 隐私 + +隐私是合规计划中越来越重要的元素。客户对企业的要求越来越高，他们越来越有兴趣从隐私的角度了解他们的数据是如何被处理的。 + +OpenStack部署可能需要证明符合组织的隐私政策，以及美国-欧盟。安全港框架、ISO/IEC 29100：2011 隐私框架或其他特定于隐私的准则。在美国，美国注册会计师协会（AICPA）已经定义了10个隐私重点领域，在商业环境中部署OpenStack可能希望证明其中的部分或全部原则。 + +为了帮助 OpenStack 架构师保护个人数据，我们建议 OpenStack 架构师查看 NIST 出版物 800-122，标题为“保护个人身份信息 （PII） 机密性指南”。本指南逐步完成保护过程： + +> "...由机构维护的有关个人的任何信息，包括 （1） 可用于区分或追踪个人身份的任何信息，例如姓名、社会安全号码、出生日期和地点、母亲的婚前姓氏或生物识别记录;（2）与个人有联系或可联系的任何其他信息，如医疗、教育、财务和就业信息......” + +全面的隐私管理需要大量的准备、思考和投资。在构建全球OpenStack云时，还引入了额外的复杂性，例如，在美国和更严格的欧盟隐私法之间的差异中导航。此外，在处理敏感的 PII 时需要格外小心，其中可能包括信用卡号或医疗记录等信息。这些敏感数据不仅受隐私法的约束，还受监管和政府法规的约束。通过遵循既定的最佳实践，包括政府发布的最佳实践，可以为OpenStack部署创建和实践一个全面的隐私管理政策。 + +## 安全审查 + +OpenStack社区安全审查的目标是识别OpenStack项目设计或实现中的弱点。虽然这些弱点很少见，但可能会对OpenStack部署的安全性产生灾难性的影响，因此应该努力将这些缺陷在已发布项目中的可能性降到最低。在安全审查过程中，应了解并记录以下内容： + +- 系统的所有入口点 +- 风险资产 +- 数据持久化的位置 +- 数据如何在系统组件之间传输 +- 数据格式和转换 +- 项目的外部依赖项 +- 一组商定的调查结果和/或缺陷 +- 项目如何与外部依赖项交互 + +对 OpenStack 可交付存储库执行安全审查的一个常见原因是协助漏洞管理团队 （VMT） 监督。OpenStack VMT 列出了受监督的存储库，其中漏洞的报告接收和披露由 VMT 管理。虽然不是严格的要求，但某种形式的安全审查、审计或威胁分析可以帮助每个人更轻松地查明系统更容易出现漏洞的区域，并在它们成为用户问题之前解决它们。 + +OpenStack VMT 建议，对项目推荐的部署进行架构审查是一种适当的安全审查形式，在审查需求与 OpenStack 规模的项目资源需求之间取得平衡。安全架构审查通常也称为威胁分析、安全分析或威胁建模。在OpenStack安全审查的背景下，这些术语是架构安全审查的同义词，它可以识别项目或参考架构设计中的缺陷，并可能导致进一步的调查工作来验证部分实现。 + +对于新项目以及第三方未进行安全审查或无法共享其结果的情况，预计安全审查将是正常途径。需要安全审查的项目的信息将在即将到来的安全审查过程中提供。 + +如果第三方已经执行了安全审查，或者项目更喜欢使用第三方来执行审查，则在即将到来的第三方安全审查过程中将提供有关如何获取该第三方审查的输出并将其提交验证的信息。 + +无论哪种情况，对文档工件的要求都是相似的 - 项目必须提供最佳实践部署的架构图。虽然强烈建议作为所有团队开发周期的一部分，但漏洞扫描和静态分析扫描不足以作为第三方审查的证据。 + +- 架构页面指南 + - 标题、版本信息、联系方式 + - 项目描述和目的 + - 主要用户和用例 + - 外部依赖关系和关联的安全假设 + - 组件 + - 服务架构图 + - 数据资产 + - 数据资产影响分析 + - 接口 + - 资源 + +### 架构页面指南 + +架构页面的目的是记录服务或项目的体系结构、用途和安全控制。它应该记录该项目的最佳实践部署。 + +架构页面有一些关键部分，下面将更详细地解释这些部分： + +- 标题、版本信息、联系方式 +- 项目描述和目的 +- 主要用户和用例 +- 外部依赖关系和关联的安全假设 +- 组件 +- 架构图 +- 数据资产 +- 数据资产影响分析 +- 接口 + +#### 标题、版本信息、联系方式 + +本部分为架构页面添加标题，提供评审状态（草稿、准备评审、已审核），并捕获项目的发布和版本（如果相关）。它还记录了项目的 PTL、负责生成架构页面、图表和完成评审的项目架构师（这可能是也可能不是 PTL）和安全评审员。 + +#### 项目描述和目的 + +本节将包含项目的简要说明，以向第三方介绍该服务。这应该是一两个段落，可以从 wiki 或其他文档中剪切/粘贴。包括相关演示文稿和更多文档的链接（如果有）。 + +例如： + +“Anchor 是一种公钥基础设施 （PKI） 服务，它使用自动证书请求验证来自动做出颁发决策。证书的颁发时间很短（通常为 12-48 小时），以避免与 CRL 和 OCSP 相关的有缺陷的吊销问题。 + +#### 主要用户和用例 + +已实现架构的预期主要用户及其用例的列表。“用户”可以是 OpenStack 中的参与者或其他服务。 + +例如： + +1. 最终用户将使用系统来存储敏感数据，例如密码、加密密钥等。 +2. 云管理员将使用管理 API 来管理资源配额。 + +#### 外部依赖和相关的安全假设 + +外部依赖项是服务操作所需的不受控制的项，如果它们受到威胁或变得不可用，可能会影响服务。这些项目通常不在开发人员的控制范围内，但在部署者的控制范围内，或者它们可能由第三方操作。设备应被视为外部依赖项。 + +例如： + +- Nova 计算服务依赖于外部身份验证和授权服务。在典型部署中，此依赖关系将由 keystone 服务实现。 +- Barbican 依赖于硬件安全模块 （HSM） 设备的使用。 + +#### 组件 + +已部署项目的组件列表，不包括外部实体。每个组件都应命名并简要描述其用途，并使用使用的主要技术（例如 Python、MySQL、RabbitMQ）进行标记。 + +例如： + +- keystone 监听器进程 （Python）：使用 keystone 服务发布的 keystone 事件的 Python 进程。 +- 数据库 （MySQL）：MySQL 数据库，用于存储与其托管实体及其元数据相关的巴比肯状态数据。 + +#### 服务架构图 + +架构图显示了系统的逻辑布局，以便安全审阅者可以与项目团队一起逐步完成架构。它是一个逻辑图，显示组件如何交互、它们如何连接到外部实体以及通信跨越信任边界的位置。有关架构图的更多信息，包括符号键，将在即将发布的架构图指南中给出。可以在任何可以生成使用键中符号的图表的工具中绘制图表，但强烈建议 draw.io。 + +此示例显示了 barbican 架构图： + +![../_images/security_review_barbican_architecture.png](https://docs.openstack.org/security-guide/_images/security_review_barbican_architecture.png) + +#### 数据资产 + +数据资产是攻击者可能针对的用户数据、高价值数据、配置项、授权令牌或其他项。数据项集因项目而异，但一般而言，应将其视为对项目预期操作至关重要的类别。所需的详细程度在某种程度上取决于上下文。数据通常可以分组，例如“用户数据”、“机密数据”或“配置文件”，但也可以是单数，例如“管理员身份令牌”或“用户身份令牌”或“数据库配置文件”。 + +数据资产应包括该资产持久化位置的声明。 + +例如： + +- 机密数据 - 密码、加密密钥、RSA 密钥 - 保留在数据库 [PKCS#11] 或 HSM [KMIP] 或 [KMIP、Dogtag] 中 +- RBAC 规则集 - 保留在 policy.json 中 +- RabbitMQ 凭证 - 保留在 barbican.conf 中 +- keystone 事件队列凭据 - 保留在 barbican.conf 中 +- 中间件配置 - 保留在粘贴 .ini 中 + +#### 数据资产影响分析 + +数据资产影响分析分解了每个数据资产的机密性、完整性或可用性损失的影响。项目架构师应该尝试完成这项工作，因为他们最详细地了解他们的项目，但 OpenStack 安全项目 （OSSP） 将在安全审查期间与项目一起解决这 个问题，并可能添加或更新影响细节。 + +例如： + +- RabbitMQ 凭据： + - 完整性故障影响：barbican 和 Workers 无法再访问队列。拒绝服务。 + - 机密性故障影响：攻击者可以将新任务添加到队列中，这些任务将由工作人员执行。攻击者可能耗尽用户配额。拒绝服务。用户将无法创建真正的机密。 + - 可用性故障影响：如果没有对队列的访问权限，barbican 无法再创建新密钥。 +- Keystone 凭据： + - 完整性故障影响：barbican 将无法验证用户凭据并失败。拒绝服务。 + - 机密性故障影响：恶意用户可能会滥用其他 OpenStack 服务（取决于 keystone 角色配置），但 barbican 不受影响。如果用于令牌验证的服务帐户也具有 barbican 管理员权限，则恶意用户可以操纵 barbican 管理员功能。 + - 可用性故障影响：barbican 将无法验证用户凭据并失败。拒绝服务。 + +#### 接口 + +接口列表捕获了审查范围内的接口。这包括架构图上跨越信任边界或不使用行业标准加密协议（如 TLS 或 SSH）的模块之间的连接。对于每个接口，将捕获以下信息： + +> - 使用的协议 +> - 通过该接口传输的任何数据资产 +> - 有关用于连接到该接口的身份验证的信息 +> - 接口用途的简要说明。 + +记录格式如下： + +从>到[传输方式]： + +- 动态资产 +- 身份认证？ +- 描述 + +例如： + +1. 客户端>API 进程 [TLS]： + - 传输中的资产：用户密钥失真凭据、明文密钥、HTTP 谓词、密钥 ID、路径 + - 对 keystone 凭据或明文机密的访问被视为系统的完全安全故障 - 此接口必须具有强大的机密性和完整性控制。 + +#### 资源 + +列出与项目相关的资源，例如描述其部署和用法的 Wiki 页面，以及指向代码存储库和相关演示文稿的链接。 + +## 安全检查表 + +- 身份服务检查表 +- 仪表板检查表 +- 计算服务检查表 +- 块存储服务检查表 +- 共享文件系统服务检查表 +- 网络服务检查表 + +## 附录 + +- 社区支持 +- 词汇表 + +### 社区支持 + +以下资源可帮助您运行和使用 OpenStack。OpenStack社区不断改进和增加OpenStack的主要功能，但如果您有任何问题，请随时提问。使用以下资源获取 OpenStack 支持并对安装进行故障排除。 + +#### 文档 + +有关可用的 OpenStack 文档，请参阅 docs.openstack.org。 + +以下指南解释了如何安装概念验证 OpenStack 云及其相关组件： + +- Rocky 安装指南 + +以下书籍介绍了如何配置和运行 OpenStack 云： + +- 架构设计指南 +- Rocky 管理员指南 +- Rocky 配置指南 +- Rocky 网络指南 +- 高可用性指南 +- 安全指南 +- 虚拟机映像指南 + +以下书籍介绍了如何使用命令行客户端： + +- Rocky API 绑定 + +以下文档提供了 OpenStack API 的参考和指导信息： + +- API 文档 + +以下指南提供了有关如何为 OpenStack 文档做出贡献的信息： + +- 文档贡献者指南 + +#### OpenStack wiki + +OpenStack wiki 包含广泛的主题，但有些信息可能很难找到或只有几页深。幸运的是，Wiki 搜索功能使您能够按标题或内容进行搜索。如果您搜索特定信息，例如有关网络或 OpenStack 计算的信息，您可以找到大量相关材料。更多内容一直在添加，因此请务必经常回来查看。您可以在任何 OpenStack wiki 页面的右上角找到搜索框。 + +#### Launchpad bug 区域 + +OpenStack 社区重视您的设置和测试工作，并希望得到您的反馈。要记录bug，您必须注册一个 Launchpad 帐户。您可以在 Launchpad bug 区域中查看现有bug并报告bug。使用搜索功能确定bug是否已报告或已修复。如果您的bug似乎仍未报告，请填写bug报告。 + +一些提示： + +- 给出一个清晰、简洁的总结。 +- 在描述中提供尽可能多的详细信息。粘贴命令输出或堆栈跟踪、屏幕截图链接以及可能有用的任何其他信息。 +- 请务必包括您正在使用的软件和软件包版本，尤其是在使用开发分支（如 `"Kilo release" vs git commit bc79c3ecc55929bac585d04a03475b72e06a3208` . +- 任何特定于部署的信息都很有用，例如您使用的是 Ubuntu 14.04 还是正在执行多节点安装。 + +以下 Launchpad Bug 区域可用： + +- Bugs：OpenStack 块存储 （cinder） +- Bugs：OpenStack 计算（nova） +- Bugs：OpenStack 仪表板（horizon） +- Bugs：OpenStack 身份认证（keystone） +- Bugs：OpenStack 镜像服务 （glance） +- Bugs：OpenStack 网络（neutron） +- Bugs：OpenStack 对象存储 （swift） +- Bugs：应用程序目录 （murano） +- Bugs：裸机服务（ironic） +- Bugs：集群服务（senlin） +- Bugs：容器基础架构管理服务（magnum） +- Bugs：数据处理服务（sahara） +- Bugs：数据库服务 （trove） +- Bugs：DNS服务（designate） +- Bugs：密钥管理服务（barbican） +- Bugs：监控 （monasca） +- Bugs：编排 （heat） +- Bugs：评级 （cloudkitty） +- Bugs：共享文件系统 （manila） +- Bugs：遥测（ceilometer） +- Bugs：遥测v3 （gnocchi） +- Bugs：工作流服务 （mistral） +- Bugs：消息传递服务 （zaqar） +- Bugs：容器服务 （zun） +- Bugs：OpenStack API 文档 （developer.openstack.org） +- Bugs：OpenStack 文档 （docs.openstack.org） + +#### 文档反馈 + +要提供有关文档的反馈，请加入我们在 OFTC IRC 网络上的 IRC 频道 `#openstack-doc` ，或在 Launchpad 中报告错误并选择文档所属的特定项目。 + +#### OpenStack IRC 频道 + +OpenStack 社区位于 OFTC 网络上的 #openstack IRC 频道中。您可以在这里提问，获取即时反馈，解决紧急问题。要安装 IRC 客户端或使用基于浏览器的客户端，请访问 （Mac OS X）、mIRC （Windows） 或 XChat （Linux）。当您在 IRC 频道中并且想要共享代码或命令输出时，通常接受的方法是使用 Paste Bin。OpenStack 项目有一个Paste网站。只需将较长的文本或日志粘贴到 Web 表单中，即可获得一个URL，可以将其粘贴到频道中。OpenStack IRC 频道处于 `#openstack` . `irc.oftc.net` 您可以在 wiki 的 IRC 页面上找到所有 OpenStack IRC 频道的列表。 + +#### OpenStack 邮件列表 + +获得答案和见解的一个好方法是将您的问题或有问题的场景发布到 OpenStack 邮件列表中。您可以向可能遇到类似问题的其他人学习和提供帮助。要订阅或查看存档，请访问一般的 OpenStack 邮件列表。如果您对特定项目或开发的其他邮件列表感兴趣，请参阅邮件列表。 + +#### OpenStack 发行包 + +以下 Linux 发行版为 OpenStack 提供社区支持的软件包： + +- **CentOS, Fedora, and Red Hat Enterprise Linux:** +- **openSUSE and SUSE Linux Enterprise Server:** +- **Ubuntu:** + +### 词汇表 + +本词汇表提供了一系列术语和定义，用于定义 OpenStack 相关概念的词汇表。 + +要添加到 OpenStack 术语表，请克隆 openstack/openstack-manuals 存储库，并通过 OpenStack 贡献过程更新源文件 `doc/common/glossary.rst` 。 + +#### 0-9 + +- 2023.1 Antelope + + OpenStack 第 27 版的代号。此版本是基于“年”之后形成的新版本标识过程的第一个版本。年内释放计数“，Antelope是一种敏捷而亲切的动物，也是一种蒸汽机车的类型。 + +- 2023.2 Bobcat + + OpenStack 第 28 版的代号。 + +- 2024.1 Caracal + + OpenStack 第 29 版的代号。 + +- 6to4 + + 一种允许 IPv6 数据包通过 IPv4 网络传输的机制，提供迁移到 IPv6 的策略。 + +#### A + +绝对限制 + +客户机虚拟机的不可逾越限制。 设置包括总 RAM 大小、最大 vCPU 数和最大磁盘大小。 + +访问控制列表（ACL） + +附加到对象的权限列表。ACL 指定哪些用户或系统进程有权访问对象。它还定义可以对指定对象执行哪些操作。典型 ACL 中的每个条目都指定一个主题和一个操作。例如，文件的 ACL 条目 `(Alice, delete)` 授予 Alice 删除该文件的权限。 + +访问密钥 + +Amazon EC2 访问密钥的替代术语。请参阅 EC2 访问密钥。 + +账户 + +对象存储中账户的上下文。不要与身份验证服务中的用户帐户混淆，例如 Active Directory、/etc/passwd、OpenLDAP、OpenStack Identity 等。 + +账户审核员 + +通过对后端 SQLite 数据库运行查询，检查指定对象存储帐户中缺少的副本以及不正确或损坏的对象。 + +账户数据库 + +一个 SQLite 数据库，其中包含对象存储帐户和相关元数据，并且帐户服务器可以访问该数据库。 + +账户回收器 + +一个对象存储工作线程，用于扫描和删除帐户数据库，并且帐户服务器已标记为删除。 + +账户服务器 + +列出对象存储中的容器，并将容器信息存储在帐户数据库中。 + +账户服务 + +对象存储组件，提供列表、创建、修改、审计等账号服务。不要与 OpenStack Identity 服务、OpenLDAP 或类似的用户帐户服务混淆。 + +会计 + +计算服务通过事件通知和系统使用情况数据工具提供会计信息。 + +活动目录 + +Microsoft 基于 LDAP 的身份验证和身份服务。在 OpenStack 中受支持。 + +主/主配置 + +在具有主/主配置的高可用性设置中，多个系统一起分担负载，如果其中一个系统发生故障，则负载将分配给其余系统。 + +主/备配置 + +在具有主/备配置的高可用性设置中，系统设置为使其他资源联机以替换那些出现故障的资源。 + +地址池 + +分配给项目的一组固定和/或浮动 IP 地址，可由项目中的 VM 实例使用或分配给项目。 + +地址解析协议 （ARP） + +将三层IP地址解析为二层链路本地地址的协议。 + +管理员 API + +授权管理员可访问的 API 调用子集，最终用户或公共 Internet 通常无法访问这些调用。它们可以作为单独的服务 （keystone） 存在，也可以是另一个 API （nova） 的子集。 + +管理员服务器 + +在 Identity 服务的上下文中，提供对管理 API 的访问的工作进程。 + +管理员 + +负责安装、配置和管理 OpenStack 云的人员。 + +高级消息队列协议 （AMQP） + +OpenStack 组件用于服务内部通信的开放标准消息传递协议，由 RabbitMQ、Qpid 或 ZeroMQ 提供。 + +高级 RISC 机器 （ARM） + +低功耗 CPU 常见于移动和嵌入式设备中。由 OpenStack 支持。 + +警报 + +计算服务可以通过其通知系统发送警报，该系统包括用于创建自定义通知驱动程序的工具。警报可以发送到并在仪表板上显示。 + +分配 + +从地址池中获取浮动 IP 地址，以便将其与来宾 VM 实例上的固定 IP 相关联的过程。 + +Amazon 内核映像 （AKI） + +VM 容器格式和磁盘格式。受Image服务支持。 + +Amazon 系统映像 （AMI） + +VM 容器格式和磁盘格式。受Image服务支持。 + +Amazon Ramdisk 映像 （ARI） + +VM 容器格式和磁盘格式。受Image服务支持。 + +Anvil + +将名为 DevStack 的基于 shell 脚本的项目移植到 Python 的项目。 + +AODH + +OpenStack 遥测服务的一部分;提供报警功能。 + +Apache + +Apache 软件基金会支持 Apache 开源软件项目的 Apache 社区。这些项目为公共利益提供软件产品。 + +Apache 许可证 2.0 + +所有 OpenStack 核心项目都是根据 Apache License 2.0 许可证的条款提供的。 + +Apache Web 服务器 + +目前在 Internet 上使用的最常用的 Web 服务器软件。 + +API 端点 + +客户端为访问 API 而与之通信的守护程序、工作程序或服务。API 终结点可以提供任意数量的服务，例如身份验证、销售数据、性能指标、计算 VM 命令、人口普查数据等。 + +API 扩展 + +扩展某些 OpenStack 核心 API 的自定义模块。 + +API 扩展插件 + +网络插件或网络 API 扩展的替代术语。 + +API 密钥 + +API 令牌的替代术语。 + +API 服务器 + +运行提供 API 端点的守护程序或工作线程的任何节点。 + +API 令牌 + +传递给 API 请求并由 OpenStack 用于验证客户端是否有权运行请求的操作。 + +API 版本 + +在 OpenStack 中，项目的 API 版本是 URL 的一部分。例如， `example.com/nova/v1/foobar` . + +小应用程序 + +可以嵌入到网页中的 Java 程序。 + +应用程序目录服务（murano） + +提供应用程序目录服务的项目，以便用户可以在管理应用程序生命周期的同时，在应用程序抽象级别上编写和部署复合环境。 + +应用程序编程接口（API） + +用于访问服务、应用程序或程序的规范集合。包括服务调用、每个调用的必需参数以及预期的返回值。 + +应用服务器 + +一种软件，它使另一种软件在网络上可用。 + +应用服务提供者商（ASP） + +租用专用应用程序的公司，这些应用程序可帮助企业和组织以更低的成本提供附加服务。 + +可分配 + +用于维护 Linux 内核防火墙模块中的地址解析协议数据包过滤规则的工具。在计算中与 iptables、ebtables 和 ip6tables 一起使用，为 VM 提供防火墙服务。 + +关联 + +将计算浮动 IP 地址与固定 IP 地址关联的过程。 + +异步 JavaScript 和 XML （AJAX） + +一组相互关联的 Web 开发技术，用于在客户端创建异步 Web 应用程序。在地平线中广泛使用。 + +以太网 ATA （AoE） + +在以太网中建立隧道的磁盘存储协议。 + +附加 + +在网络中将 VIF 或 vNIC 连接到 L2 网络的过程。在计算上下文中，此过程将存储卷连接到实例。 + +附件（网络） + +接口 ID 与逻辑端口的关联。将接口插入端口。 + +审计 + +通过系统使用情况数据工具在计算中提供。 + + 审计员 + +验证对象存储对象、容器和帐户完整性的工作进程。审核员是对象存储帐户审计员、容器审计员和对象审计员的统称。 + +Austin + +OpenStack 初始版本的代号。首届设计峰会在美国德克萨斯州奥斯汀举行。 + +auth 节点 + +对象存储授权节点的替代术语。 + +身份验证 + +通过私钥、秘密令牌、密码、指纹或类似方法确认用户、进程或客户端确实是他们所说的人的过程。 + +身份验证令牌 + +身份验证后提供给客户端的文本字符串。必须由用户或进程在对 API 端点的后续请求中提供。 + +AuthN + +提供身份验证服务的标识服务组件。 + +授权 + +验证用户、进程或客户端是否有权执行操作的行为。 + +授权节点 + +提供授权服务的对象存储节点。 + +AuthZ + +提供高级授权服务的身份组件。 + +自动确认 + +RabbitMQ 中的配置设置，用于启用或禁用消息确认。默认启用。 + +自动声明 + +一个 Compute RabbitMQ 设置，用于确定在程序启动时是否自动创建消息交换。 + +可用区 + +用于容错的隔离区域的 Amazon EC2 概念。不要与 OpenStack Compute 区域或单元混淆。 + +AWS CloudFormation 模板 + +AWS CloudFormation 允许 Amazon Web Services （AWS） 用户创建和管理相关资源的集合。编排服务支持与 CloudFormation 兼容的格式 （CFN）。 + +#### B + +后端 + +对用户进行模糊处理的交互和进程，例如计算卷挂载、守护程序向 iSCSI 目标传输数据或对象存储对象完整性检查。 + +后端目录 + +身份服务目录服务用于存储和检索有关客户端可用的 API 端点的信息的存储方法。示例包括 SQL 数据库、LDAP 数据库或 KVS 后端。 + +后端存储 + +用于保存和检索服务信息的持久性数据存储，例如对象存储对象列表、客户机虚拟机的当前状态、用户名列表等。此外，映像服务用于获取和存储 VM 映像的方法。选项包括对象存储、本地挂载的文件系统、RADOS 块设备、VMware 数据存储和 HTTP。 + +备份、恢复和灾难恢复服务（freezer） + +提供用于备份、还原和恢复文件系统、实例或数据库备份的集成工具的项目。 + +带宽 + +通信资源（如 Internet）使用的可用数据量。表示用于下载内容的数据量或可供下载的数据量。 + +barbican + +Key Manager 服务的代号。 + +裸机 + +映像服务容器格式，指示 VM 映像不存在容器。 + +裸机服务（ironic） + +OpenStack 服务，它提供服务和关联的库，能够以安全感知和容错的方式管理和配置物理机。 + +基础映像 + +OpenStack 提供的映像。 + +Bell-LaPadula 模型 + +一种安全模型，侧重于数据机密性和对机密信息的受控访问。该模型将实体分为主体和客体。将主体的许可与主体的分类进行比较，以确定主体是否被授权用于特定的访问模式。间隙或分类方案用晶格表示。 + +基准服务（反弹） + +OpenStack项目，为单个OpenStack组件的性能分析和基准测试以及完整的生产OpenStack云部署提供了一个框架。 + +Bexar + +2011 年 2 月发布的与 OpenStack 相关的项目的分组版本。它仅包括计算 （nova） 和对象存储 （swift）。Bexar 是 OpenStack 第二个版本的代号。设计峰会在美国德克萨斯州圣安东尼奥举行，这里是贝克萨尔县的县城。 + +二进制 + +仅由 1 和 0 组成的信息，这是计算机的语言。 + +位 + +位是以 2 为基数的个位数（0 或 1）。带宽使用量以每秒位数为单位。 + +每秒比特数 （BPS） + +通用测量数据从一个地方传输到另一个地方的速度。 + +块设备 + +一种以块的形式移动数据的设备。这些设备节点连接设备，例如硬盘、CD-ROM 驱动器、闪存驱动器和其他可寻址内存区域。 + +区块迁移 + +KVM 使用的一种虚拟机实时迁移方法，用于在用户启动的切换期间将实例从一台主机撤离到另一台主机，停机时间非常短。不需要共享存储。由计算支持。 + +块存储 API + +单独终结点上的 API，用于为计算 VM 附加、分离和创建块存储。 + +块存储服务（cinder） + +OpenStack 服务，它实现了服务和库，通过在其他块存储设备之上的抽象和自动化，提供对块存储资源的按需自助访问。 + +BMC（基板管理控制器） + +IPMI架构中的智能，它是一种专用的微控制器，嵌入在计算机主板上并充当服务器。管理系统管理软件和平台硬件之间的接口。 + +可启动磁盘映像 + +一种 VM 映像类型，以单个可启动文件的形式存在。 + +Bootstrap 协议 （BOOTP） + +网络客户端用于从配置服务器获取 IP 地址的网络协议。在使用 FlatDHCP 管理器或 VLAN 管理器网络管理器时，通过 dnsmasq 守护程序进行计算中提供。 + +边界网关协议 （BGP） + +边界网关协议是一种连接自治系统的动态路由协议。该协议被认为是互联网的骨干，将不同的网络连接起来，形成一个更大的网络。 + +浏览器 + +使计算机或设备能够访问 Internet 的任何客户端软件。 + +构建器文件 + +包含对象存储用于重新配置环或在发生严重故障后从头开始重新创建环的配置信息。 + +扩展 + +在主环境资源受限时，利用辅助环境按需弹性构建实例的做法。 + +按钮类 + +地平线中的一组相关按钮类型。用于启动、停止和挂起 VM 的按钮位于一个类中。用于关联和取消关联浮动 IP 地址的按钮位于另一个类中，依此类推。 + +字节 + +构成单个字符的位集;一个字节通常有 8 位。 + +#### C + +缓存修剪器 + +将映像服务虚拟机映像缓存保持在或低于其配置的最大大小的程序。 + +Cactus + +2011 年春季发布的 OpenStack 项目分组版本。它包括计算 （nova）、对象存储 （swift） 和图像服务 （glance）。Cactus 是美国德克萨斯州的一个城市，是 OpenStack 第三个版本的代号。当OpenStack版本从3个月延长到6个月时，该版本的代号发生了变化，以匹配最接近上一次峰会的地理位置。 + +调用 + +OpenStack 消息队列软件使用的 RPC 原语之一。发送消息并等待响应。 + +能力 + +定义单元的资源，包括 CPU、存储和网络。可以应用于一个单元或整个单元内的特定服务。 + +容量缓存 + +计算后端数据库表，其中包含当前工作负载、可用 RAM 量以及每个主机上运行的 VM 数。用于确定 VM 在哪个主机上启动。 + +容量更新程序 + +监视 VM 实例并根据需要更新容量缓存的通知驱动程序。 + +投射 + +OpenStack 消息队列软件使用的 RPC 原语之一。发送消息，不等待响应。 + +目录 + +用户在使用 Identity 服务进行身份验证后可用的 API 端点列表。 + +目录服务 + +一种身份服务，列出用户在使用 Identity 服务进行身份验证后可用的 API 端点。 + +测高仪 + +OpenStack Telemetry 服务的一部分;收集和存储来自其他 OpenStack 服务的指标。 + +单元格 + +在子关系和父关系中提供计算资源的逻辑分区。如果父单元无法提供请求的资源，则请求将从父单元传递到子单元。 + +单元格转发 + +一个“计算”选项，该选项使父单元能够在父单元无法提供所请求的资源时将资源请求传递给子单元。 + +单元格管理器 + +计算组件，其中包含单元中每个主机的当前功能列表，并根据需要路由请求。 + +CentOS 操作系统 + +与 OpenStack 兼容的 Linux 发行版。 + +Ceph 函数 + +可大规模扩展的分布式存储系统，由对象存储、块存储和兼容 POSIX 的分布式文件系统组成。与OpenStack兼容。 + +CephFS + +Ceph 提供的符合 POSIX 标准的文件系统。 + +证书颁发机构 （CA） + +在密码学中，颁发数字证书的实体。数字证书通过证书的指定主体证明公钥的所有权。这使其他人（依赖方）能够依赖与认证公钥相对应的私钥所做的签名或断言。在这种信任关系模型中，CA 是证书主体（所有者）和依赖证书的一方的受信任第三方。CA 是许多公钥基础结构 （PKI） 方案的特征。在 OpenStack 中，Compute 为 cloudpipe VPN 和 VM 映像解密提供了一个简单的证书颁发机构。 + +挑战握手身份验证协议 （CHAP） + +计算支持的 iSCSI 身份验证方法。 + +机会调度器 + +计算使用的一种计划方法，用于从池中随机选择可用主机。 + +自上次更改以来 + +一个计算 API 参数，该参数允许下载自上次请求以来对所请求项的更改，而不是下载一组新的数据并将其与旧数据进行比较。 + +Chef + +支持 OpenStack 部署的操作系统配置管理工具。 + +子单元格 + +如果请求的资源（如 CPU 时间、磁盘存储或内存）在父单元中不可用，则该请求将转发到其关联的子单元。如果子单元可以满足请求，则它确实可以。否则，它会尝试将请求传递给其任何子级。 + +cinder + +块存储服务的代号。 + +CirrOS + +一个最小的 Linux 发行版，设计用作云（如 OpenStack）上的测试映像。 + +Cisco neutron 插件 + +适用于 Cisco 设备和技术（包括 UCS 和 Nexus）的网络插件。 + +云架构师 + +计划、设计和监督云创建的人。 + +云审计数据联邦 （CADF） + +Cloud Auditing Data Federation （CADF） 是用于审核事件数据的规范。CADF 受 OpenStack Identity 支持。 + +云计算 + +一种模型，支持访问可配置计算资源（如网络、服务器、存储、应用程序和服务）的共享池，这些资源可以快速配置和发布，只需最少的管理工作或服务提供商交互。 + +云计算基础设施 + +支持云计算模型的计算要求所需的硬件和软件组件，例如服务器、存储、网络和虚拟化软件。 + +云计算平台软件 + +通过互联网提供不同的服务。这些资源包括数据存储、服务器、数据库、网络和软件等工具和应用程序。只要电子设备可以访问网络，它就可以访问数据和运行它的软件程序。 + +云计算服务架构 + +云服务体系结构定义了在企业业务网络边界内和跨企业业务网络边界实施的整体云计算服务和解决方案。考虑核心业务需求，并将其与可能的云解决方案相匹配。 + +云控制器 + +表示云全局状态的计算组件的集合;通过队列与服务（例如身份认证、对象存储和节点/存储工作线程）进行通信。 + +云控制器节点 + +运行网络、卷、API、调度程序和映像服务的节点。每个服务都可以分解为单独的节点，以实现可伸缩性或可用性。 + +云数据管理接口（CDMI） + +SINA标准定义了一个RESTful API，用于管理云中的对象，目前在OpenStack中不受支持。 + +云基础设施管理接口（CIMI） + +正在进行的云管理规范。目前在 OpenStack 中不受支持。 + +云技术 + +云是由管理和自动化软件编排的虚拟源工具。这包括原始处理能力、内存、网络、基于云的应用程序的存储。 + +cloud-init 函数 + +通常安装在 VM 映像中的包，用于在启动后使用从元数据服务检索到的信息（如 SSH 公钥和用户数据）执行实例的初始化。 + +cloudadmin + +计算 RBAC 系统中的默认角色之一。授予完整的系统访问权限。 + +Cloudbase-初始化 + +提供来宾初始化功能的 Windows 项目，类似于 cloud-init。 + +cloudpipe + +一种基于每个项目创建 VPN 的计算服务。 + +CloudPipe 镜像 + +作为 cloudpipe 服务器的预制 VM 镜像。从本质上讲，OpenVPN运行在Linux上。 + +集群服务（senlin） + +实现集群服务和库的项目，用于管理由其他 OpenStack 服务公开的同构对象组。 + +命令过滤器 + +列出计算 rootwrap 工具中允许的命令。 + +命令行界面 （CLI） + +一个基于文本的客户端，可帮助您创建脚本以与 OpenStack 云进行交互。 + +通用 Internet 文件系统 （CIFS） + +文件共享协议。它是 Microsoft 开发和使用的原始服务器消息块 （SMB） 协议的公共或开放变体。与 SMB 协议一样， CIFS 在更高级别运行并使用 TCP/IP 协议。 + +公共库 （oslo） + +生成一组 python 库的项目，其中包含 OpenStack 项目共享的代码。这些库提供的 API 应该是高质量、稳定、一致、有文档记录的和普遍适用的。 + +社区项目 + +一个没有得到OpenStack技术委员会正式认可的项目。如果项目足够成功，它可能会被提升为孵化项目，然后被提升为核心项目，或者它可能与主代码主干合并。 + +压缩 + +通过特殊编码减小文件大小，文件可以再次解压缩为原始内容。OpenStack 支持 Linux 文件系统级别的压缩，但不支持对对象存储对象或镜像服务虚拟机映像等内容进行压缩。 + +计算 API （nova API） + +nova-api 守护程序提供对 nova 服务的访问。可以与其他 API 通信，例如 Amazon EC2 API。 + +计算控制器 + +计算组件，用于选择要在其上启动 VM 实例的合适主机。 + +计算主机 + +专用于运行计算节点的物理主机。 + +计算节点 + +运行 nova-compute 守护程序的节点，该守护程序管理提供各种服务（如 Web 应用程序和分析）的 VM 实例。 + +计算服务 （nova） + +OpenStack 核心项目，用于实现服务和相关库，以提供对计算资源（包括裸机、虚拟机和容器）的大规模可扩展、按需、自助访问。 + +计算工作进程 + +在每个计算节点上运行并管理 VM 实例生命周期的计算组件，包括运行、重新启动、终止、附加/分离卷等。由 nova-compute 守护程序提供。 + +串联对象 + +对象存储组合并发送到客户端的一组分段对象。 + +导体 + +在计算中，conductor 是代理来自计算进程的数据库请求的进程。使用 conductor 可以提高安全性，因为计算节点不需要直接访问数据库。 + +congress + +治理服务的代码名称。 + +一致性窗口 + +所有客户端都可以访问新的对象存储对象所需的时间。 + +控制台日志 + +包含计算中 Linux VM 控制台的输出。 + +容器 + +在对象存储中组织和存储对象。类似于 Linux 目录的概念，但不能嵌套。影像服务容器格式的替代术语。 + +容器审核员 + +通过对 SQLite 后端数据库的查询，检查指定对象存储容器中缺少副本或不正确的对象。 + +容器数据库 + +存储对象存储容器和容器元数据的 SQLite 数据库。容器服务器访问此数据库。 + +容器格式 + +映像服务使用的包装器，其中包含 VM 映像及其关联的元数据，例如计算机状态、OS 磁盘大小等。 + +容器基础设施管理服务（magnum） + +该项目提供一组用于预配、扩展和管理容器编排引擎的服务。 + +容器服务器 + +管理容器的对象存储服务器。 + +容器服务 + +提供创建、删除、列表等容器服务的对象存储组件。 + +内容分发网络 （CDN） + +内容分发网络是用于将内容分发到客户端的专用网络，通常位于客户端附近以提高性能。 + +持续交付 + +一种软件工程方法，团队在短周期内生产软件，确保软件可以随时可靠地发布，并且在发布软件时手动发布。 + +持续部署 + +一种软件发布过程，该过程使用自动化测试来验证对代码库的更改是否正确且稳定，以便立即自主部署到生产环境。 + +持续集成 + +每天多次将所有开发人员的工作副本合并到共享主线的做法。 + +控制器节点 + +云控制器节点的替代术语。 + +核心 API + +根据上下文，核心 API 可以是 OpenStack API 或特定核心项目的主 API，例如计算、网络、映像服务等。 + +核心服务 + +由 Interop 工作组定义为核心的官方 OpenStack 服务。目前由块存储服务（cinder）、计算服务（nova）、身份服务（keystone）、镜像服务（glance）、网络服务（neutron）和对象存储服务（swift）组成。 + +成本 + +在计算分布式计划程序下，这是通过查看每个主机相对于所请求的 VM 实例的风格的功能来计算的。 + +凭证 + +只有用户知道或可访问的数据，用于验证用户是否是他所说的人。在身份验证期间，将凭据提供给服务器。示例包括密码、密钥、数字证书和指纹。 + +CRL 函数 + +PKI 模型中的证书吊销列表 （CRL） 是已吊销的证书列表。不应信任提供这些证书的最终实体。 + +跨域资源共享 （CORS） + +一种机制，允许从资源来源域之外的另一个域请求网页上的许多资源（例如，字体、JavaScript）。特别是，JavaScript 的 AJAX 调用可以使用 XMLHttpRequest 机制。 + +Crowbar + +SUSE 的开源社区项目，旨在提供所有必要的服务，以快速部署和管理云。 + +当前工作负载 + +计算容量缓存的一个元素，根据给定主机上当前正在进行的生成、快照、迁移和调整大小操作的数量进行计算。 + +客户 + +项目的替代术语。 + +自定义模块 + +用户创建的 Python 模块，由 horizon 加载，用于更改仪表板的外观。 + +#### D + +守护进程 + +在后台运行并等待请求的进程。可能侦听也可能不侦听 TCP 或 UDP 端口。不要与工人混淆。 + +仪表板（horizon） + +OpenStack 项目，为所有 OpenStack 服务提供可扩展的、统一的、基于 Web 的用户界面。 + +数据加密 + +镜像服务和计算都支持加密的虚拟机 （VM） 镜像（但不支持实例）。OpenStack 支持使用 HTTPS、SSL、TLS 和 SSH 等技术进行传输中数据加密。对象存储不支持应用程序级别的对象加密，但可能支持使用磁盘加密的存储。 + +数据丢失防护（DLP） 软件 + +用于保护敏感信息并通过检测和拒绝数据传输来防止其泄漏到网络边界之外的软件程序。 + +数据处理服务（sahara） + +OpenStack 项目，提供可扩展的数据处理堆栈和关联的管理接口。 + +数据存储 + +数据库服务支持的数据库引擎。 + +数据库 ID + +为对象存储数据库的每个副本指定的唯一 ID。 + +数据库复制器 + +一个对象存储组件，用于将帐户、容器和对象数据库中的更改复制到其他节点。 + +数据库服务（trove） + +一个集成项目，为关系和非关系数据库引擎提供可扩展且可靠的云数据库即服务功能。 + +解除分配 + +删除浮动 IP 地址和固定 IP 地址之间的关联的过程。删除此关联后，浮动 IP 将返回到地址池。 + +Debian + +与 OpenStack 兼容的 Linux 发行版。 + +重复数据删除 + +在磁盘块、文件和/或对象级别查找重复数据以最大程度地减少存储使用的过程 - 目前在 OpenStack 中不受支持。 + +默认面板 + +用户访问仪表板时显示的默认面板。 + +默认项目 + +如果在创建用户时未指定任何项目，则会将新用户分配给此项目。 + +默认令牌 + +一个标识服务令牌，该令牌不与特定项目关联，并交换为作用域内令牌。 + +延迟删除 + +影像服务中的一个选项，用于在预定义的秒数后删除影像，而不是立即删除影像。 + +交付方式 + +Compute RabbitMQ消息投递模式的设置;可以设置为瞬态或持久性。 + +拒绝服务 （DoS） + +拒绝服务 （DoS） 是拒绝服务攻击的简称。这是阻止合法用户使用服务的恶意尝试。 + +已弃用的身份验证 + +计算中的一个选项，使管理员能够通过 `nova-manage` 命令创建和管理用户，而不是使用标识服务。 + +指定 + +DNS 服务的代号。 + +桌面即服务 + +一个平台，它提供了一套桌面环境，用户可以通过访问这些环境从任何位置接收桌面体验。这可以提供通用、开发甚至同构测试环境。 + +开发者 + +计算 RBAC 系统中的默认角色之一，也是分配给新用户的默认角色。 + +设备 ID + +将对象存储分区映射到物理存储设备。 + +设备权重 + +根据每个设备的存储容量，在对象存储设备之间按比例分配分区。 + +开发堆栈 + +使用 shell 脚本快速构建完整 OpenStack 开发环境的社区项目。 + +DHCP代理 + +为虚拟网络提供 DHCP 服务的 OpenStack Networking 代理。 + +Diablo + +2011 年秋季发布的与 OpenStack 相关的项目的分组版本，是 OpenStack 的第四个版本。它包括计算 （nova 2011.3）、对象存储 （swift 1.4.3） 和镜像服务 （glance）。Diablo是OpenStack第四个版本的代号。设计峰会在美国加利福尼亚州圣克拉拉附近的湾区举行，Diablo是附近的城市。 + +直接消费者 + +Compute RabbitMQ 的一个元素，在执行 RPC 调用时生效。它通过唯一的独占队列连接到直接交换，发送消息，然后终止。 + +直接交换 + +RPC 调用期间在 Compute RabbitMQ 中创建的路由表;为每个调用的 RPC 调用创建一个。 + +直接发布者 + +RabbitMQ 的元素，用于提供对传入 MQ 消息的响应。 + +解除关联 + +删除浮动 IP 地址和固定 IP 之间的关联，从而将浮动 IP 地址返回到地址池的过程。 + +自主访问控制 （DAC） + +控制使用者访问对象的能力，同时使用户能够做出策略决策并分配安全属性。传统的用户、组和读-写-执行权限的 UNIX 系统就是 DAC 的一个示例。 + +磁盘加密 + +能够在文件系统、磁盘分区或整个磁盘级别加密数据。在计算 VM 中受支持。 + +磁盘格式 + +VM 的磁盘映像在映像服务后端存储中存储的基础格式。例如，AMI、ISO、QCOW2、VMDK 等。 + +分散 + +在对象存储中，用于测试和确保对象和容器分散以确保容错的工具。 + +分布式虚拟路由器 （DVR） + +使用 OpenStack Networking （neutron） 时实现高可用性多主机路由的机制。 + +Django + +在地平线中广泛使用的 Web 框架。 + +DNS 记录 + +指定有关特定域并属于该域的信息的记录。 + +DNS服务（指定） + +OpenStack 项目，以与技术无关的方式提供对权威 DNS 服务的可扩展、按需、自助访问。 + +dnsmasq + +为虚拟网络提供 DNS、DHCP、BOOTP 和 TFTP 服务的守护程序。 + +域 + +标识 API v3 实体。表示项目、组和用户的集合，用于定义用于管理 OpenStack Identity 实体的管理边界。在 Internet 上，将网站与其他网站分开。通常，域名有两个或多个部分，用点分隔。例如，yahoo.com、usa.gov、harvard.edu 或 mail.yahoo.com。此外，域是包含一条或多条记录的所有 DNS 相关信息的实体或容器。 + +域名系统（DNS） + +用于确定 Internet 域名到地址和地址到名称解析的系统。DNS 通过将 IP 地址转换为更易于记忆的地址来帮助浏览 Internet。例如，将 111.111.111.1 转换为 \。所有域及其组件（如邮件服务器）都利用 DNS 解析到适当的位置。DNS服务器通常设置在主从关系中，以便主服务器故障调用从服务器。还可以对 DNS 服务器进行群集或复制，以便对一个 DNS 服务器所做的更改自动传播到其他活动服务器。在计算中，支持将 DNS 条目与浮动 IP 地址、节点或单元相关联，以便主机名在重新启动时保持一致。 + +下载 + +将数据（通常以文件的形式）从一台计算机传输到另一台计算机。 + +持久交换 + +服务器重新启动时保持活动状态的 Compute RabbitMQ 消息交换。 + +持久队列 + +一个 Compute RabbitMQ 消息队列，在服务器重新启动时保持活动状态。 + +动态主机配置协议 （DHCP） + +一种网络协议，用于配置连接到网络的设备，以便它们可以使用 Internet 协议 （IP） 在该网络上进行通信。该协议在客户端-服务器模型中实现，其中 DHCP 客户端从 DHCP 服务器请求配置数据，例如 IP 地址、默认路由以及一个或多个 DNS 服务器地址。一种在引导时自动为主机配置网络的方法。由网络和计算提供。 + +动态超文本标记语言 （DHTML） + +使用 HTML、JavaScript 和级联样式表使用户能够与网页交互或显示简单动画的页面。 + +#### E + +东西向流量 + +同一云或数据中心中的服务器之间的网络流量。另请参阅南北向流量。 + +EBS 启动卷 + +包含可启动 VM 映像的 Amazon EBS 存储卷，OpenStack 目前不支持该映像。 + +ebtables + +用于 Linux 桥接防火墙的过滤工具，支持过滤通过 Linux 桥接的网络流量。在计算中与 arptables、iptables 和 ip6tables 一起使用，以确保网络通信的隔离。 + +EC2 函数 + +Amazon 商业计算产品，类似于计算。 + +EC2 访问密钥 + +与 EC2 私有密钥一起使用以访问计算 EC2 API。 + +EC2 API + +OpenStack 支持通过计算访问 Amazon EC2 API。 + +EC2 兼容性 API + +使 OpenStack 能够与 Amazon EC2 通信的计算组件。 + +EC2 私有密钥 + +与计算 EC2 API 通信时与 EC2 访问密钥一起使用;用于对每个请求进行数字签名。 + +边缘计算 + +在云中运行更少的进程，并将这些进程移动到本地。 + +弹性块存储 （EBS） + +Amazon 商业块存储产品。 + +封装 + +将一种数据包类型置于另一种数据包类型中，以提取或保护数据。示例包括 GRE、MPLS 或 IPsec。 + +加密 + +OpenStack支持HTTPS、SSH、SSL、TLS、数字证书、数据加密等加密技术。 + +端点 + +请参阅 API 端点。 + +端点注册表 + +身份服务目录的替代术语。 + +端点模板 + +URL 和端口号端点列表，指示可以访问服务（如对象存储、计算、标识等）的位置。 + +企业云计算 + +位于防火墙后面的计算环境，为企业提供软件、基础设施和平台服务。 + +实体 + +任何想要连接到网络（网络连接服务）提供的网络服务的硬件或软件。实体可以通过实现 VIF 来利用网络。 + +临时映像 + +不保存对其卷所做的更改并在实例终止后将其恢复到原始状态的 VM 映像。 + +临时卷 + +不保存对其所做的更改并在当前用户放弃控制权时恢复到其原始状态的卷。 + +Essex + +2012 年 4 月发布的与 OpenStack 相关的项目的分组版本，是 OpenStack 的第五个版本。它包括计算（nova 2012.1）、对象存储（swift 1.4.8）、图像（glance）、身份（keystone）和仪表板（horizon）。Essex 是 OpenStack 第五个版本的代号。设计峰会在美国马萨诸塞州波士顿举行，Essex是附近的城市。 + +ESXi + +支持 OpenStack 的虚拟机管理程序。 + +ETag 函数 + +对象存储中对象的 MD5 哈希值，用于确保数据完整性。 + +euca2ools + +用于管理 VM 的命令行工具集合;大多数都与OpenStack兼容。 + +Eucalyptus Kernel Image （EKI） + +与 ERI 一起使用以创建 EMI。 + +Eucalyptus机器映像 （EMI） + +映像服务支持的虚拟机镜像容器格式。 + +Eucalyptus Ramdisk 镜像 （ERI） + +与 EKI 一起使用以创建 EMI。 + +撤离 + +将一个或所有虚拟机 （VM） 实例从一台主机迁移到另一台主机的过程，与共享存储实时迁移和块迁移兼容。 + +交换 + +RabbitMQ 消息交换的替代术语。 + +交换类型 + +Compute RabbitMQ 中的路由算法。 + +独占队列 + +由 RabbitMQ 中的直接使用者连接到 - 计算，消息只能由当前连接使用。 + +扩展属性 （xattr） + +文件系统选项，用于存储所有者、组、权限、修改时间等以外的其他信息。底层对象存储文件系统必须支持扩展属性。 + +扩展 + +API 扩展或插件的替代术语。在 Identity 服务的上下文中，这是特定于实现的调用，例如添加对 OpenID 的支持。 + +外部网络 + +通常用于 Internet 访问的网段。 + +额外规格 + +指定计算确定从何处开始新实例时的其他要求。示例包括最小网络带宽或 GPU 量。 + +#### F + +FakeLDAP + +创建用于测试身份和计算的本地 LDAP 目录的简单方法。需要 Redis。 + +fan-out交换 + +在 RabbitMQ 和 Compute 中，调度程序服务使用消息传递接口从计算、卷和网络节点接收功能消息。 + +联合身份 + +一种在身份提供商和 OpenStack 云之间建立信任的方法。 + +Fedora + +与 OpenStack 兼容的 Linux 发行版。 + +光纤通道 + +存储协议在概念上类似于 TCP/IP;封装 SCSI 命令和数据。 + +以太网光纤通道 （FCoE） + +光纤通道协议在以太网内通过隧道传输。 + +填充优先调度器 + +计算计划方法，尝试用 VM 填充主机，而不是在各种主机上启动新 VM。 + +过滤器 + +计算计划过程中的步骤，当无法运行 VM 的主机被淘汰且未被选中时。 + +防火墙 + +用于限制主机和/或节点之间的通信，在计算中使用 iptables、arptables、ip6tables 和 ebtables 实现。 + +防火墙即服务 （FWaaS） + +提供外围防火墙功能的网络扩展。 + +固定 IP 地址 + +每次启动实例时都与同一实例关联的 IP 地址通常不对最终用户或公共 Internet 访问，并用于管理实例。 + +平面管理器 + +计算组件为授权节点提供 IP 地址，并假定 DHCP、DNS 以及路由配置和服务由其他设备提供。 + +平面模式注入 + +一种计算网络方法，在实例启动之前将操作系统网络配置信息注入到 VM 映像中。 + +平面网络 + +虚拟网络类型，不使用VLAN或隧道来分隔项目流量。每个平面网络通常需要定义由桥接映射定义的单独的底层物理接口。但是，平面网络可以包含多个子网。FlatDHCP 管理器 + +提供 dnsmasq（DHCP、DNS、BOOTP、TFTP）和 radvd（路由）服务的计算组件。 + +规格 + +VM 实例类型的替代术语 + +规格ID + +每种计算或映像服务虚拟机规格或实例类型的 UUID。 + +浮动 IP 地址 + +项目可以与 VM 关联的 IP 地址，以便实例在每次启动时都具有相同的公有 IP 地址。您可以创建一个浮动 IP 地址池，并在实例启动时将其分配给实例，以保持一致的 IP 地址以维护 DNS 分配。 + +Folsom + +2012 年秋季发布的与 OpenStack 相关的项目的分组版本，是 OpenStack 的第六个版本。它包括计算 （nova）、对象存储 （swift）、身份 （keystone）、网络 （neutron）、映像服务 （glance） 以及卷或块存储 （cinder）。Folsom 是 OpenStack 第六个版本的代号。设计峰会在美国加利福尼亚州旧金山举行，福尔瑟姆是附近的城市。 + +FormPost + +对象存储中间件，通过网页上的表单上传（发布）图像。 + +freezer + +备份、还原和灾难恢复服务的代号。 + +前端 + +用户与服务交互的点;可以是 API 端点、仪表板或命令行工具。 + +#### G + +网关 + +通常分配给路由器的 IP 地址，用于在不同网络之间传递网络流量。 + +通用接收卸载 （GRO） + +某些网络接口驱动程序的功能，在传送到内核 IP 堆栈之前，将许多较小的接收数据包合并为一个大数据包。 + +通用路由封装 （GRE） + +在虚拟点对点链路中封装各种网络层协议的协议。 + +glance + +影像服务的代号。 + +glance API 服务器 + +图像 API 的替代名称。 + +glance 注册表 + +映像服务映像注册表的替代术语。 + +全局端点模板 + +包含可用于所有项目的服务的标识服务终结点模板。 + +GlusterFS + +一个旨在聚合 NAS 主机的文件系统，与 OpenStack 兼容。 + +gnocchi + +OpenStack Telemetry 服务的一部分;提供索引器和时序数据库。 + +golden映像 + +一种操作系统安装方法，其中创建最终的磁盘映像，然后由所有节点使用，无需修改。 + +治理服务（大会） + +该项目在任何云服务集合中提供治理即服务，以便监视、实施和审核动态基础结构上的策略。 + +图形交换格式 （GIF） + +一种通常用于网页上的动画图像的图像文件。 + +图形处理单元 （GPU） + +OpenStack 目前不支持根据 GPU 的存在来选择主机。 + +绿色线程 + +Python 使用的协作线程模型;减少争用条件，并且仅在进行特定库调用时进行上下文切换。每个 OpenStack 服务都是它自己的线程。 + +Grizzly + +OpenStack 第七个版本的代号。设计峰会在美国加利福尼亚州圣地亚哥举行，Grizzly是加利福尼亚州州旗的一个元素。 + +分组 + +Identity v3 API 实体。表示特定域所拥有的用户集合。 + +客户机操作系统 + +在虚拟机监控程序的控制下运行的操作系统实例。 + +#### H + +Hadoop + +Apache Hadoop 是一个开源软件框架，支持数据密集型分布式应用程序。 + +Hadoop 分布式文件系统 （HDFS） + +一种分布式、高度容错的文件系统，设计用于在低成本商用硬件上运行。 + +交接 + +对象存储中的一种对象状态，其中由于驱动器故障而自动创建对象的新副本。 + +HAProxy 函数 + +为基于 TCP 和 HTTP 的应用程序提供负载平衡器，将请求分散到多个服务器。 + +硬重启 + +一种重新启动类型，其中按下物理或虚拟电源按钮，而不是正常、正确地关闭操作系统。 + +Havana + +OpenStack 第八版的代号。设计峰会在美国俄勒冈州波特兰市举行，Havana是俄勒冈州的一个非法人社区。 + +健康监视器 + +确定 VIP 池的后端成员是否可以处理请求。一个池可以有多个与之关联的运行状况监视器。当池有多个与之关联的监视器时，所有监视器都会检查池的每个成员。所有监视器都必须声明成员运行状况良好，才能保持活动状态。 + +heat + +业务流程服务的代号。 + +Heat 编排模板 （HOT） + +以 OpenStack 原生格式的 Heat 输入。 + +高可用性 （HA） + +高可用性系统设计方法和相关服务实施可确保在合同测量期间达到预先安排的运营绩效水平。高可用性系统力求最大限度地减少系统停机时间和数据丢失。 + +horizon + +仪表板的代号。 + +Horizon 插件 + +OpenStack Dashboard （horizon） 的插件。 + +主机 + +物理计算机，而不是 VM 实例（节点）。 + +主机聚合 + +一种将可用性区域进一步细分为虚拟机管理程序池（公共主机的集合）的方法。 + +主机总线适配器 （HBA） + +插入 PCI 插槽（如光纤通道或网卡）的设备。 + +混合云 + +混合云是由两个或多个云（私有云、社区云或公有云）组成的，这些云仍然是不同的实体，但绑定在一起，提供多种部署模型的优势。混合云还意味着能够将主机托管、托管和/或专用服务与云资源连接起来。 + +混合云计算 + +混合了本地、私有云和第三方公有云服务，并在两个平台之间进行编排。 + +Hyper-V + +OpenStack 支持的虚拟机管理程序之一。 + +超链接 + +包含指向其他网站的链接的任何类型的文本，常见于单击一个或多个单词会打开其他网站的文档中。 + +超文本传输协议 （HTTP） + +用于分布式、协作式、超媒体信息系统的应用协议。它是万维网数据通信的基础。超文本是在包含文本的节点之间使用逻辑链接（超链接）的结构化文本。HTTP是交换或传输超文本的协议。 + +安全超文本传输协议 （HTTPS）一种加密通信协议，用于通过计算机网络进行安全通信，在 Internet 上的部署特别广泛。从技术上讲，它本身不是一个协议;相反，它是简单地将超文本传输协议 （HTTP） 分层在 TLS 或 SSL 协议之上的结果，从而将 TLS 或 SSL 的安全功能添加到标准 HTTP 通信中。大多数 OpenStack API 端点和许多组件间通信都支持 HTTPS 通信。 + +虚拟机管理程序 + +仲裁和控制 VM 对实际底层硬件的访问的软件。 + +虚拟机管理程序池 + +通过主机聚合组合在一起的虚拟机管理程序的集合。 + +#### I + +Icehouse + +OpenStack 第九个版本的代号。设计峰会在香港举行，Ice House是该市的一条街道的名字。 + +身份证号码 + +与身份中的每个用户关联的唯一数字 ID，在概念上类似于 Linux 或 LDAP UID。 + +身份验证 API + +Identity 服务 API 的替代术语。 + +身份验证后端 + +Identity 服务用于检索用户信息的源;例如，OpenLDAP 服务器。 + +身份提供者 + +一种目录服务，允许用户使用用户名和密码登录。它是身份验证令牌的典型来源。 + +身份服务（keystone） + +促进 API 客户端身份验证、服务发现、分布式多项目授权和审计的项目。它提供了一个用户映射到他们可以访问的 OpenStack 服务的中央目录。它还为 OpenStack 服务注册端点，并充当通用身份验证系统。 + +身份服务 API + +用于访问通过 keystone 提供的 OpenStack Identity 服务的 API。 + +IETF （英语） + +Internet 工程任务组 （IETF） 是一个开放标准组织，负责制定 Internet 标准，尤其是与 TCP/IP 相关的标准。 + +映像 + +用于创建或重建服务器的特定操作系统 （OS） 的文件集合。OpenStack 提供预构建的映像。您还可以从已启动的服务器创建自定义映像或快照。自定义映像可用于数据备份，或用作其他服务器的“黄金”映像。 + +映像API + +用于管理 VM 映像的映像服务 API 终结点。处理客户端对 VM 的请求，更新注册表服务器上的映像服务元数据，并与存储适配器通信以从后端存储上传 VM 映像。 + +映像缓存 + +由图像服务用于获取本地主机上的图像，而不是在每次请求图像时从图像服务器重新下载图像。 + +映像 ID + +URI 和 UUID 的组合，用于通过镜像 API 访问镜像服务虚拟机镜像。 + +映像成员 + +可以在映像服务中访问给定 VM 映像的项目列表。 + +映像所有者 + +拥有镜像服务虚拟机镜像的项目。 + +映像注册表 + +可通过映像服务获取的 VM 映像的列表。 + +映像服务（glance） + +OpenStack 服务，它提供服务和关联的库来存储、浏览、共享、分发和管理可启动磁盘映像、与初始化计算资源密切相关的其他数据以及元数据定义。 + +映像状态 + +镜像服务中虚拟机镜像的当前状态，不要与正在运行的实例的状态混淆。 + +映像存储 + +映像服务用于存储虚拟机映像的后端存储，选项包括对象存储、本地挂载的文件系统、RADOS 块设备、VMware 数据存储或 HTTP。 + +映像 UUID + +映像服务用于唯一标识每个 VM 映像的 UUID。 + +孵化项目 + +社区项目可以提升到此状态，然后提升为核心项目 + +基础设施优化服务（观察者） + +OpenStack项目，旨在为基于OpenStack的多项目云提供灵活且可扩展的资源优化服务。 + +基础架构即服务 （IaaS） + +IaaS 是一种配置模型，在这种模型中，组织外包数据中心的物理组件，例如存储、硬件、服务器和网络组件。服务提供商拥有设备，并负责设备的安装、操作和维护。客户通常按使用量付费。IaaS 是一种提供云服务的模型。 + +Ingress 过滤 + +筛选传入网络流量的过程。由计算支持。 + +INI 格式 + +OpenStack 配置文件使用 INI 格式来描述选项及其值。它由部分和键值对组成。 + +注入 + +在启动实例之前将文件放入虚拟机映像的过程。 + +每秒输入/输出操作数 （IOPS） + +IOPS 是一种常见的性能度量，用于对计算机存储设备（如硬盘驱动器、固态驱动器和存储区域网络）进行基准测试。 + +实例 + +正在运行的 VM 或处于已知状态（如挂起）的 VM，可以像硬件服务器一样使用。 + +实例ID + +例如UUID的替代术语。 + +实例状态 + +来宾虚拟机映像的当前状态。 + +实例隧道网络 + +用于计算节点和网络节点之间的实例流量隧道的网段。 + + 实例类型 + +描述可供用户使用的各种虚拟机映像的参数;包括 CPU、存储和内存等参数。风味的替代术语。 + +实例类型 ID + +特定实例 ID 的替代术语。 + +实例 UUID + +分配给每个来宾 VM 实例的唯一 ID。 + +智能平台管理接口（IPMI） + +IPMI 是系统管理员用于计算机系统带外管理和监控其操作的标准化计算机系统接口。通俗地说，它是一种使用直接网络连接管理计算机的方法，无论它是否打开;连接到硬件，而不是操作系统或登录 shell。 + +接口 + +提供与其他设备或介质的连接的物理或虚拟设备。 + +接口 ID + +UUID 形式的网络 VIF 或 vNIC 的唯一 ID。 + +互联网控制消息协议 （ICMP） + +网络设备用于控制消息的网络协议。例如，ping 使用 ICMP 来测试连接。 + +互联网协议 （IP） + +Internet 协议套件中的主要通信协议，用于跨网络边界中继数据报。 + +互联网服务提供商 （ISP） + +任何向个人或企业提供互联网访问的企业。 + +互联网小型计算机系统接口（iSCSI） + +封装 SCSI 帧以通过 IP 网络传输的存储协议。受计算、对象存储和镜像服务支持。 + +IO + +输入和输出的缩写。 + +IP 地址 + +Internet 上每个计算机系统唯一的编号。地址使用了两个版本的 Internet 协议 （IP）：IPv4 和 IPv6。 + +IP 地址管理 （IPAM） + +自动执行 IP 地址分配、解除分配和管理的过程。目前由 Compute、melange 和 Networking 提供。 + +ip6tables + +用于在 Linux 内核中设置、维护和检查 IPv6 数据包过滤规则表的工具。在 OpenStack 计算中，ip6tables 与 arptables、ebtables 和 iptables 一起使用，为节点和虚拟机创建防火墙。 + +ipset + +对 iptables 的扩展，允许创建同时匹配整个 IP 地址“集”的防火墙规则。这些集驻留在索引数据结构中以提高效率，尤其是在具有大量规则的系统上。 + +iptables + +iptables 与 arptables 和 ebtables 一起使用，可在 Compute 中创建防火墙。iptables 是 Linux 内核防火墙（作为不同的 Netfilter 模块实现）提供的表及其存储的链和规则。目前不同的内核模块和程序用于不同的协议：iptables 适用于 IPv4，ip6tables 适用于 IPv6，arptables 适用于 ARP，ebtables 用于以太网帧。需要 root 权限才能操作。 + +ironic + +裸机服务的代号。 + +iSCSI 限定名称 （IQN） + +IQN 是最常用的 iSCSI 名称格式，用于唯一标识 iSCSI 网络中的节点。所有 IQN 都遵循 iqn.yyyy-mm.domain：identifier 模式，其中“yyyy-mm”是域名注册的年份和月份，“domain”是颁发组织的反向域名，“identifier”是一个可选字符串，使同一域名下的每个 IQN 都是唯一的。例如，“iqn.2015-10.org.openstack.408ae959bce1”。 + +ISO9660 + +镜像服务支持的虚拟机镜像磁盘格式之一。 + +ITSEC 函数 + +计算 RBAC 系统中的默认角色，可以隔离任何项目中的实例。 + +#### J + +Java + +一种编程语言，用于创建通过网络涉及多台计算机的系统。 + +JavaScript + +一种用于生成网页的脚本语言。 + +JavaScript 对象表示法 （JSON） + +OpenStack 中支持的响应格式之一。 + +框架的形状 + +现代以太网网络中的功能，支持高达约 9000 字节的帧。 + +Juno + +OpenStack 第十版的代号。设计峰会在美国佐治亚州亚特兰大举行，Juno是佐治亚州的一个非法人社区。 + +#### K + +Kerberos + +一种基于票证的网络身份验证协议。Kerberos 允许节点通过非安全网络进行通信，并允许节点以安全的方式相互证明其身份。 + +基于内核的虚拟机 （KVM） + +支持 OpenStack 的虚拟机管理程序。KVM 是适用于 Linux on x86 硬件的完整虚拟化解决方案，包含虚拟化扩展（Intel VT 或 AMD-V）、ARM、IBM Power 和 IBM zSeries。它由一个可加载的内核模块组成，该模块提供核心虚拟化基础架构和特定于处理器的模块。 + +密钥管理器服务（barbican） + +该项目产生一个秘密存储和生成系统，能够为希望启用加密功能的服务提供密钥管理。 + +keystone + +Identity 服务的代号。 + +快速启动 + +用于在基于 Red Hat、Fedora 和 CentOS 的 Linux 发行版上自动进行系统配置和安装的工具。 + +Kilo + +OpenStack 第 11 版的代号。设计峰会在法国巴黎举行。由于名称选择的延迟，该版本仅被称为 K。由于 `k` kilo 是单位符号，而 kilogram 参考工件存放在巴黎附近的塞夫尔 Pavillon de Breteuil 中，因此社区选择了 Kilo 作为版本名称。 + +L + +大对象 + +Object Storage 中大于 5 GB 的对象。 + +启动板 + +OpenStack 的协作站点。 + + 二层（L2）代理 + +为虚拟网络提供第 2 层连接的 OpenStack Networking 代理。 + +二层网络 + +OSI 网络体系结构中用于数据链路层的术语。数据链路层负责媒体访问控制、流量控制以及检测和纠正物理层中可能发生的错误。 + +三层 （L3） 代理 + +OpenStack Networking 代理，为虚拟网络提供第 3 层（路由）服务。 + +三层网络 + +在 OSI 网络体系结构中用于网络层的术语。网络层负责数据包转发，包括从一个节点到另一个节点的路由。 + +Liberty + +OpenStack 第 12 版的代号。设计峰会在加拿大温哥华举行，Liberty是加拿大萨斯喀彻温省一个村庄的名字。 + +libvirt + +OpenStack 用来与许多受支持的虚拟机管理程序进行交互的虚拟化 API 库。 + +轻量级目录访问协议 （LDAP） + +用于通过 IP 网络访问和维护分布式目录信息服务的应用程序协议。 + +Linux 操作系统 + +类Unix计算机操作系统，在自由和开源软件开发和分发的模式下组装。 + +Linux桥接 + +使多个 VM 能够在计算中共享单个物理 NIC 的软件。 + +Linux Bridge neutron 插件 + +使 Linux 网桥能够理解网络端口、接口连接和其他抽象。 + +Linux 容器 （LXC） + +支持 OpenStack 的虚拟机管理程序。 + +实时迁移 + +计算中能够将正在运行的虚拟机实例从一台主机移动到另一台主机，在切换期间仅发生少量服务中断。 + +负载均衡器 + +负载均衡器是属于云帐户的逻辑设备。它用于根据定义为其配置一部分的条件在多个后端系统或服务之间分配工作负载。 + +负载均衡 + +在两个或多个节点之间分散客户端请求以提高性能和可用性的过程。 + +负载均衡器即服务（LBaaS） + +使网络能够在指定实例之间均匀分配传入请求。 + +负载均衡服务（octavia） + +该项目旨在以与技术无关的方式提供对负载均衡器服务的可扩展、按需、自助服务访问。 + +逻辑卷管理器 （LVM） + +提供一种在大容量存储设备上分配空间的方法，该方法比传统的分区方案更灵活。 + +#### M + +magnum + +容器基础结构管理服务的代号。 + +管理 API + +管理 API 的替代术语。 + +管理网络 + +用于管理的网段，公共 Internet 无法访问。 + +管理器 + +相关代码的逻辑分组，例如块存储卷管理器或网络管理器。 + +清单 + +用于跟踪对象存储中大型对象的段。 + +manifest 对象 + +一个特殊的对象存储对象，其中包含大型对象的清单。 + +manila + +OpenStack 共享文件系统服务的代号。 + +manila分享 + +负责管理共享文件系统服务设备，特别是后端设备。 + +最大传输单元 （MTU） + +特定网络介质的最大帧或数据包大小。以太网通常为 1500 字节。 + +机制驱动 程序 + +模块化第 2 层 （ML2） neutron 插件的驱动程序，为虚拟实例提供第 2 层连接。单个 OpenStack 安装可以使用多个机制驱动程序。 + +melange + +OpenStack Network Information Service 的项目名称。将与网络合并。 + +成员关系 + +镜像服务虚拟机镜像与项目之间的关联。允许与指定项目共享图像。 + +成员列表 + +可以在映像服务中访问给定 VM 映像的项目列表。 + +内存缓存 + +对象存储用于缓存的分布式内存对象缓存系统。 + +内存过量分配 + +能够根据主机的实际内存使用情况启动新的 VM 实例，而不是根据每个正在运行的实例认为其可用的 RAM 量来做出决定。也称为 RAM 过量使用。 + +消息代理 + +用于在计算中提供 AMQP 消息传递功能的软件包。默认包为 RabbitMQ。 + +消息总线 + +所有 AMQP 消息用于计算中的云间通信的主要虚拟通信线路。 + +消息队列 + +将来自客户端的请求传递给相应的工作线程，并在作业完成后将输出返回给客户端。 + +消息服务 （zaqar） + +该项目提供消息传递服务，该服务以高效、可扩展和高度可用的方式提供各种分布式应用程序模式，并创建和维护关联的 Python 库和文档。 + +元数据服务器 （MDS） + +存储 CephFS 元数据。 + +元数据代理 + +为实例提供元数据服务的 OpenStack Networking 代理。 + +迁移 + +将 VM 实例从一台主机移动到另一台主机的过程。 + +mistral + +工作流服务的代号。 + +Mitaka + +OpenStack 第 13 版的代号。设计峰会在日本东京举行。Mitaka是东京的一座城市。 + +模块化第 2 层 （ML2）neutron插件 + +可以在网络中同时使用多种二层网络技术，如802.1Q和VXLAN。 + +monasca + +OpenStack 监控的代号。 + +监控 （LBaaS） + +LBaaS 功能，使用 `ping` 命令、TCP 和 HTTP/HTTPS GET 提供可用性监控。 + +监视器 （Mon） + +一个 Ceph 组件，用于与外部客户端通信、检查数据状态和一致性以及执行仲裁功能。 + +监控 （monasca） + +OpenStack 服务，为指标、复杂事件处理和日志记录提供多项目、高度可扩展、高性能、容错的监控即服务解决方案。为高级监控服务构建一个可扩展的平台，运营商和项目都可以使用该平台来获得运营洞察力和可见性，确保可用性和稳定性。 + +多云计算 + +在单个网络架构中使用多种云计算和存储服务。 + +多云 SDK + +提供多云抽象层并包含对 OpenStack 的支持的 SDK。这些 SDK 非常适合编写需要使用多种类型的云提供商的应用程序，但可能会公开一组更有限的功能。 + +多因素身份验证 + +使用两个或多个凭据（如密码和私钥）的身份验证方法。目前在 Identity 中不受支持。 + +多主机 + +传统 （nova） 网络的高可用性模式。每个计算节点处理 NAT 和 DHCP，并充当其上所有 VM 的网关。一个计算节点上的网络故障不会影响其他计算节点上的 VM。 + +multinic 函数 + +计算中的工具，允许每个虚拟机实例连接多个 VIF。 + +murano + +应用程序目录服务的代号。 + +#### N + +Nebula + +NASA 于 2010 年以开源形式发布，是 Compute 的基础。 + +网络管理员 + +计算 RBAC 系统中的默认角色之一。允许用户为实例分配可公开访问的 IP 地址并更改防火墙规则。 + +NetApp 卷驱动程序 + +使计算能够通过 NetApp OnCommand 配置管理器与 NetApp 存储设备进行通信。 + +网络 + +在实体之间提供连接的虚拟网络。例如，共享网络连接的虚拟端口的集合。在网络术语中，网络始终是第 2 层网络。 + +网络地址转换 （NAT） + +在传输过程中修改 IP 地址信息的过程。由计算和网络支持。 + +网络控制器 + +一个计算守护程序，用于协调节点的网络配置，包括 IP 地址、VLAN 和桥接。还管理公共网络和专用网络的路由。 + +网络文件系统 （NFS） + +一种使文件系统在网络上可用的方法。由 OpenStack 支持。 + +网络 ID + +分配给网络中每个网段的唯一 ID。与网络 UUID 相同。 + +网络管理器 + +用于管理各种网络组件（如防火墙规则、IP 地址分配等）的计算组件。 + +网络命名空间 + +Linux 内核功能，在单个主机上提供独立的虚拟网络实例，具有单独的路由表和接口。类似于物理网络设备上的虚拟路由和转发 （VRF） 服务。 + +网络节点 + +运行 Network Worker 守护程序的任何计算节点。 + +网络段 + +表示网络中虚拟的隔离 OSI 第 2 层子网。 + +网络服务标头 （NSH） + +提供沿实例化服务路径进行元数据交换的机制。 + +网络时间协议 （NTP） + +通过与可信、准确的时间源通信来保持主机或节点时钟正确的方法。 + +网络 UUID + +网络网段的唯一 ID。 + +网络工作进程 + +`nova-network` worker 守护进程;提供诸如为启动的 nova 实例提供 IP 地址等服务。 + +网络 API（Neutron API） + +用于访问 OpenStack Networking 的 API。提供可扩展的体系结构以启用自定义插件创建。 + +网络服务（neutron） + +OpenStack 项目，它实现了服务和相关库，以提供按需、可扩展且与技术无关的网络抽象。 + +neutron + +OpenStack Networking 服务的代号。 + +neutron API + +网络 API 的替代名称。 + +Neutron 管理器 + +启用计算和网络集成，使网络能够对来宾 VM 执行网络管理。 + +Neutron 插件 + +网络中的接口，使组织能够为高级功能（如 QoS、ACL 或 IDS）创建自定义插件。 + +Newton + +OpenStack 第 14 版的代号。设计峰会在美国德克萨斯州奥斯汀举行。该版本以位于德克萨斯州奥斯汀市第九街 1013 号的“Newton House”命名。被列入国家史迹名录。 + +Nexenta 卷驱动程序 + +为计算中的 NexentaStor 设备提供支持。 + +NFV 编排服务（tacker） + +OpenStack 服务，旨在实现网络功能虚拟化 （NFV） 编排服务和库，用于网络服务和虚拟网络功能 （VNF） 的端到端生命周期管理。 + +Nginx 函数 + +HTTP 和反向代理服务器、邮件代理服务器和通用 TCP/UDP 代理服务器。 + +无 ACK + +在 Compute RabbitMQ 中禁用服务器端消息确认。提高性能但降低可靠性。 + +节点 + +在主机上运行的 VM 实例。 + +非持久交换 + +服务重新启动时清除的消息交换。其数据不会写入持久性存储。 + +非持久队列 + +服务重新启动时清除的消息队列。其数据不会写入持久性存储。 + +非持久化卷 + +临时卷的替代术语。 + +南北向流量 + +用户或客户端（北）与服务器（南）之间的网络流量，或进入云（南）和云外（北）的流量。另请参阅东西向流量。 + +nova + +OpenStack 计算服务的代号。 + +Nova API 接口 + +计算 API 的替代术语。 + +nova-network （新星网络） + +一个计算组件，用于管理 IP 地址分配、防火墙和其他与网络相关的任务。这是旧版网络选项，也是网络的替代方法。 + +#### O + +对象 + +对象存储保存的数据的 BLOB;可以是任何格式。 + +对象审计器 + +打开对象服务器的所有对象，并验证每个对象的 MD5 哈希、大小和元数据。 + +对象过期 + +Object Storage 中的一个可配置选项，用于在经过指定时间或达到特定日期后自动删除对象。 + +对象哈希 + +对象存储对象的唯一 ID。 + +对象路径哈希 + +对象存储用于确定对象在环中的位置。将对象映射到分区。 + +对象复制器 + +一个对象存储组件，用于将对象复制到远程分区以实现容错。 + +对象服务器 + +负责管理对象的对象存储组件。 + +对象存储 API + +用于访问 OpenStack 对象存储的 API。 + +对象存储设备 （OSD） + +Ceph 存储守护进程。 + +对象存储服务（swift） + +OpenStack 核心项目，为固定数字内容提供最终一致性和冗余的存储和检索。 + +对象版本控制 + +允许用户在对象存储容器上设置标志，以便对容器内的所有对象进行版本控制。 + +Ocata + +OpenStack 第 15 版的代号。设计峰会在西班牙巴塞罗那举行。Ocata是巴塞罗那北部的一个海滩。 + +Octavia + +负载平衡服务的代号。 + +Oldie + +长时间运行的对象存储进程的术语。可以指示挂起的进程。 + +开放云计算接口（OCCI） + +用于管理计算、数据和网络资源的标准化接口，目前在 OpenStack 中不受支持。 + +开放虚拟化格式 （OVF） + +打包 VM 映像的标准。在 OpenStack 中受支持。 + +打开 vSwitch + +Open vSwitch 是在开源 Apache 2.0 许可证下获得许可的生产质量的多层虚拟交换机。它旨在通过编程扩展实现大规模网络自动化，同时仍支持标准管理接口和协议（例如 NetFlow、sFlow、SPAN、RSPAN、CLI、LACP、802.1ag）。 + +Open vSwitch（OVS）代理 + +为网络插件提供底层 Open vSwitch 服务的接口。 + +打开 vSwitch neutron 插件 + +在网络中提供对 Open vSwitch 的支持。 + +OpenDev + +OpenDev 是一个协作开源软件开发的空间。 + +OpenDev 的使命是为开源软件项目提供项目托管、持续集成工具和虚拟协作空间。OpenDev 本身是自托管在这套工具上，包括代码审查、持续集成、etherpad、wiki、代码浏览等。这意味着 OpenDev 本身就像一个开源项目一样运行，您可以加入我们并帮助运行系统。此外，运行的所有服务本身都是开源软件。 + +OpenStack 项目是使用 OpenDev 的最大项目。 + +OpenLDAP + +开源 LDAP 服务器。受计算和标识支持。 + +OpenStack + +OpenStack 是一个云操作系统，可控制整个数据中心的大型计算、存储和网络资源池，所有这些资源都通过仪表板进行管理，该仪表板使管理员能够进行控制，同时授权用户通过 Web 界面配置资源。OpenStack 是一个根据 Apache License 2.0 许可的开源项目。 + +OpenStack 代码名称 + +每个 OpenStack 版本都有一个代号。代号按字母顺序排列：Austin, Bexar, Cactus, Diablo, Essex, Folsom, Grizzly, Havana, Icehouse, Juno, Kilo, Liberty, Mitaka, Newton, Ocata, Pike, Queens, Rocky, Stein, Train, Ussuri, Victoria, Wallaby, Xena, Yoga, Zed。 + +Wallaby 是新策略选择的第一个代号：代号由社区按照字母顺序选择，有关详细信息，请参阅发布名称标准。 + +维多利亚的名字是姓氏，其中代号是靠近相应OpenStack设计峰会举办地的城市或县。一个例外，称为沃尔登例外，被授予州旗中听起来特别酷的元素。代号由大众投票选出。 + +与此同时，随着OpenStack发行版的字母表用完，技术委员会改变了命名过程，将发行号和发行版名称作为识别码。版本号将是主要标识符：“year”。年内发布计数“，该名称将主要用于营销目的。第一个这样的版本是 2023.1 Antelope。紧随其后的是 2023.2 Bobcat、2024.1 Caracal。 + +openSUSE + +与 OpenStack 兼容的 Linux 发行版。 + +操作员 + +负责规划和维护 OpenStack 安装的人员。 + +可选服务 + +由 Interop 工作组定义为可选的官方 OpenStack 服务。目前，由 Dashboard （horizon）、Telemetry 服务 （Telemetry）、Orchestration 服务 （heat）、Database 服务 （trove）、Bare Metal 服务 （ironic） 等组成。 + +编排服务（heat） + +OpenStack 服务，它通过 OpenStack 原生 REST API 使用声明性模板格式编排复合云应用程序。 + +orphan + +在对象存储的上下文中，这是一个在升级、重新启动或重新加载服务后不会终止的过程。 + +Oslo + +Common Libraries 项目的代号。 + +#### P + +panko + +OpenStack Telemetry 服务的一部分;提供事件存储。 + +父单元格 + +如果请求的资源（如 CPU 时间、磁盘存储或内存）在父单元中不可用，则该请求将转发到关联的子单元。 + +分区 + +对象存储中用于存储对象的存储单元。它存在于设备之上，并被复制以实现容错。. + +分区索引 + +包含环内所有对象存储分区的位置。 + +分区偏移值 + +对象存储用于确定数据应驻留在哪个分区上。 + +路径 MTU 发现 （PMTUD） + +IP 网络中用于检测端到端 MTU 并相应地调整数据包大小的机制。 + +暂停 + +未发生任何更改（内存未更改、网络通信停止等）的 VM 状态;VM 已冻结，但未关闭。 + +PCI直通 + +为客户机虚拟机提供对 PCI 设备的独占访问权限。目前在 OpenStack Havana 及更高版本中受支持。 + +持久消息 + +存储在内存和磁盘上的消息。失败或重新启动后，消息不会丢失。 + +持久卷 + +将保存对这些类型的磁盘卷所做的更改。 + +个性文件 + +用于自定义 Compute 实例的文件。它可用于注入 SSH 密钥或特定的网络配置。 + +Pike + +OpenStack 第 16 版的代号。OpenStack峰会在美国马萨诸塞州波士顿举行。该版本以马萨诸塞州收费公路命名，通常缩写为马萨诸塞州收费公路，这是 90 号州际公路最东端的路段。 + +平台即服务（PaaS） + +为使用者提供操作系统，通常还为语言运行时和库（统称为“平台”）提供，消费者可以在其上运行自己的应用程序代码，而无需提供对底层基础结构的任何控制。平台即服务提供商的示例包括 Cloud Foundry 和 OpenShift。 + +插件 + +为网络 API 或计算 API 提供实际实现的软件组件，具体取决于上下文。 + +策略服务 + +标识组件，提供规则管理接口和基于规则的授权引擎。 + +基于策略的路由 （PBR） + +提供一种机制，用于根据网络管理员定义的策略实现数据包转发和路由。 + +池 + +一组逻辑设备，例如 Web 服务器，您可以将其组合在一起以接收和处理流量。负载平衡功能选择池中的哪个成员处理在 VIP 地址上收到的新请求或连接。每个VIP都有一个游泳池。 + +池成员 + +在负载平衡系统中的后端服务器上运行的应用程序。 + +端口 + +网络中的虚拟网络端口;VIF / vNIC 连接到端口。 + +端口 UUID + +网络端口的唯一 ID。 + +预置 + +在基于 Debian 的 Linux 发行版上自动进行系统配置和安装的工具。 + +私有云 + +一个企业或组织独占使用的计算资源。 + +私有映像 + +仅对指定项目可用的映像服务虚拟机映像。 + +私有 IP 地址 + +用于管理和管理的 IP 地址，不可用于公共 Internet。 + +专用网络 + +网络控制器提供虚拟网络，使计算服务器能够相互交互以及与公用网络交互。所有计算机都必须具有公共和专用网络接口。专用网络接口可以是平面网络接口，也可以是 VLAN 网络接口。扁平化网络接口由具有扁平化管理器的flat_interface控制。VLAN 网络接口由带有 VLAN 管理器的 `vlan_interface` 选件控制。 + +项目 + +项目代表了OpenStack中“所有权”的基本单位，因为OpenStack中的所有资源都应该由特定项目拥有。在 OpenStack Identity 中，项目必须由特定域拥有。 + +项目 ID + +Identity 服务分配给每个项目的唯一 ID。 + +项目 VPN + +cloudpipe 的替代术语。 + +混杂模式 + +使网络接口将其接收的所有流量传递到主机，而不是仅传递寻址到它的帧。 + +受保护的属性 + +通常，只有云管理员才能访问的映像服务映像上的额外属性。限制哪些用户角色可以对该属性执行 CRUD 操作。云管理员可以将任何映像属性配置为受保护。 + +提供者 + +有权访问所有主机和实例的管理员。 + +代理节点 + +提供Object Storage代理服务的节点。 + +代理服务器 + +对象存储的用户通过代理服务器与服务进行交互，代理服务器又在环内查找所请求数据的位置，并将结果返回给用户。 + +公共 API + +用于服务到服务通信和最终用户交互的 API 终结点。 + +公有云 + +许多用户可通过 Internet 访问的数据中心。 + +公共镜像 + +可供所有项目使用的镜像服务虚拟机镜像。 + +公网 IP 地址 + +最终用户可访问的 IP 地址。 + +公钥认证 + +使用密钥而不是密码的身份验证方法。 + +公网 + +网络控制器提供虚拟网络，使计算服务器能够相互交互以及与公用网络交互。所有计算机都必须具有公共和专用网络接口。公用网络接口由该 `public_interface` 选项控制。 + +Puppet + +OpenStack支持的操作系统配置管理工具。 + +Python 模型 + +OpenStack中广泛使用的编程语言。 + +#### Q + +QEMU 写入时复制 2 （QCOW2） + +镜像服务支持的虚拟机镜像磁盘格式之一。 + +Qpid + +penStack支持的消息队列软件;RabbitMQ 的替代品。 + +服务质量 （QoS） + +保证某些网络或存储要求以满足应用程序提供商和最终用户之间的服务级别协议 （SLA） 的能力。通常包括网络带宽、延迟、抖动校正和可靠性等性能要求，以及每秒输入/输出操作数 （IOPS） 中的存储性能、限制协议和峰值负载下的性能预期。 + +隔离 + +如果对象存储发现对象、容器或帐户已损坏，则会将其置于此状态，不会被复制，客户端无法读取，并且会重新复制正确的副本。 + +Queens + +OpenStack 第 17 版的代号。OpenStack峰会在澳大利亚悉尼举行。该版本以新南威尔士州南海岸地区的皇后庞德河命名。 + +Quick EMUlator （QEMU） （快速 EMUlator） + +QEMU 是一个通用的开源机器仿真器和虚拟化器。OpenStack 支持的虚拟机管理程序之一，通常用于开发目的。 + +配额 + +在计算和块存储中，能够基于每个项目设置资源限制。 + +#### R + +RabbitMQ 模型 + +OpenStack 使用的默认消息队列软件。 + +Rackspace 云文件 + +2010 年由 Rackspace 开源发布;对象存储的基础。 + +RADOS 块设备 （RBD） + +Ceph 组件，使 Linux 块设备能够在多个分布式数据存储上进行条带化。 + +radvd + +路由器通告守护程序，由计算 VLAN 管理器和 FlatDHCP 管理器用于为 VM 实例提供路由服务。 + +rally + +Benchmark 服务的代号。 + +RAM过滤器 + +启用或禁用 RAM 过量分配的计算设置。 + +RAM 过量分配 + +能够根据主机的实际内存使用情况启动新的 VM 实例，而不是根据每个正在运行的实例认为其可用的 RAM 量来做出决定。也称为内存过量使用。 + +速率限制 + +对象存储中的可配置选项，用于限制每个帐户和/或每个容器的数据库写入。 + +原始 + +映像服务支持的虚拟机映像磁盘格式之一;非结构化磁盘映像。 + +重新平衡 + +在环中的所有驱动器之间分配对象存储分区的过程;在初始环创建期间和环重新配置后使用。 + +重启 + +对服务器进行软重启或硬重启。通过软重启，操作系统会发出重新启动信号，从而可以正常关闭所有进程。硬重启相当于重启服务器。虚拟化平台应确保重新启动操作已成功完成，即使在基础域/VM 暂停或停止/停止的情况下也是如此。 + +重建 + +删除服务器上的所有数据，并将其替换为指定的映像。服务器 ID 和 IP 地址保持不变。 + +侦察 + +用于收集计量的对象存储组件。 + +记录 + +属于特定域，用于指定有关该域的信息。有几种类型的 DNS 记录。每种记录类型都包含用于描述该记录用途的特定信息。示例包括邮件交换 （MX） 记录，它指定特定域的邮件服务器;和名称服务器 （NS） 记录，用于指定域的权威名称服务器。 + +记录 ID + +数据库中的一个数字，每次进行更改时都会递增。对象存储在复制时使用。 + +Red Hat Enterprise Linux （RHEL） （英语） + +与 OpenStack 兼容的 Linux 发行版。 + +参考架构 + +OpenStack 云的推荐架构。 + +区域 + +具有专用 API 端点的离散 OpenStack 环境，通常仅与其他区域共享身份 （keystone）。 + +注册表 + +影像服务注册表的替代术语。 + +注册表服务器 + +向客户端提供虚拟机镜像元数据信息的镜像服务。 + +可靠、自主的分布式对象存储 + +（雷达） + +在 Ceph 中提供对象存储的组件集合。类似于 OpenStack Object Storage。 + +远程过程调用 （RPC） + +计算RabbitMQ 用于服务内通信的方法。 + +副本 + +通过创建对象存储对象、帐户和容器的副本来提供数据冗余和容错，以便在底层存储发生故障时不会丢失它们。 + +副本数量 + +对象存储环中数据的副本数。 + +复制 + +将数据复制到单独的物理设备以实现容错和性能的过程。 + +复制器 + +对象存储后端进程，用于创建和管理对象副本。 + +请求 ID + +分配给发送到计算的每个请求的唯一 ID。 + +救援映像 + +一种特殊类型的 VM 映像，在将实例置于救援模式时启动。允许管理员挂载实例的文件系统以更正问题。 + +调整大小 + +将现有服务器转换为其他风格，从而扩展或缩减服务器。保存原始服务器以在出现问题时启用回滚。必须测试并明确确认所有调整大小，此时将删除原始服务器。 + +RESTful + +一种使用 REST 或具象状态传输的 Web 服务 API。REST是用于万维网的超媒体系统的架构风格 + +环 + +将对象存储数据映射到分区的实体。每个服务（例如帐户、对象和容器）都存在一个单独的环。 + +环构建器 + +在对象存储中构建和管理环，为设备分配分区，并将配置推送到其他存储节点。 + +Rocky + +OpenStack 第 18 版的代号。OpenStack峰会在加拿大温哥华举行。该版本以落基山脉命名。 + +角色 + +用户为执行一组特定操作而假定的个性。角色包括一组权限和特权。担任该角色的用户将继承这些权利和特权。 + +基于角色的访问控制 （RBAC） + +提供用户可以执行的操作的预定义列表，例如启动或停止 VM、重置密码等。在标识和计算中均受支持，可以使用仪表板进行配置。 + +角色 ID + +分配给每个身份服务角色的字母数字 ID。 + +根本原因分析（RCA）服务（Vitrage） + +OpenStack项目旨在组织、分析和可视化OpenStack警报和事件，深入了解问题的根本原因，并在直接检测到问题之前推断出它们的存在。 + +rootwrap + +计算的一项功能，允许非特权“nova”用户以 Linux root 用户身份运行指定的命令列表。 + +循环调度器 + +在可用主机之间均匀分配实例的计算计划程序的类型。 + +路由器 + +在不同网络之间传递网络流量的物理或虚拟网络设备。 + +路由密钥 + +计算直接交换、扇出交换和主题交换使用此密钥来确定如何处理消息;处理方式因 Exchange 类型而异。 + +RPC 驱动程序 + +模块化系统，允许更改 Compute 的底层消息队列软件。例如，从 RabbitMQ 到 ZeroMQ 或 Qpid。 + +rsync + +由对象存储用于推送对象副本。 + +RXTX 限 制 + +计算 VM 实例可以发送和接收的网络流量的绝对限制。 + +RXTX 配额 + +对计算 VM 实例可以发送和接收的网络流量的软限制。 + +#### S + +sahara + +数据处理服务的代号。 + +SAML 断言 + +包含标识提供者提供的有关用户的信息。这表示用户已通过身份验证。 + +沙盒 + +一个虚拟空间，可以在其中安全地运行新的或未经测试的软件。 + +调度器管理器 + +一个计算组件，用于确定 VM 实例的启动位置。采用模块化设计，支持多种调度程序类型。 + +作用域令牌 + +与特定项目关联的身份服务 API 访问令牌。 + +洗涤器 + +检查并删除未使用的虚拟机;实现延迟删除的影像服务组件。 + +密钥 + +只有用户知道的文本字符串;与访问密钥一起使用，以向计算 API 发出请求。 + +安全启动 + +系统固件验证启动过程中涉及的代码的真实性的过程。 + +安全外壳 （SSH） + +用于通过加密通信通道访问远程主机的开源工具，计算支持 SSH 密钥注入。 + +安全组 + +应用于计算实例的一组网络流量筛选规则。 + +分段对象 + +已分解为多个部分的对象存储大型对象。重新组合的对象称为串联对象。 + +自助服务 + +对于 IaaS，常规（非特权）帐户能够在不涉及管理员的情况下管理虚拟基础架构组件（如网络）。 + +SELinux 函数 + +Linux 内核安全模块，提供用于支持访问控制策略的机制。 + +senlin + +群集服务的代码名称。 + +服务器 + +为该系统上运行的客户端软件提供显式服务的计算机，通常管理各种计算机操作。服务器是计算系统中的 VM 实例。风格和图像是创建服务器时的必要元素。 + +服务器映像 + +VM 映像的替代术语。 + +服务器 UUID + +分配给每个来宾 VM 实例的唯一 ID。 + +服务 + +OpenStack 服务，例如计算、对象存储或映像服务。提供一个或多个端点，用户可以通过这些端点访问资源和执行操作。 + +服务目录 + +Identity 服务目录的替代术语。 + +服务功能链 （SFC） + +对于给定的服务，SFC 是所需服务功能及其应用顺序的抽象视图。 + +服务 ID + +分配给 Identity 服务目录中可用的每个服务的唯一 ID。 + +服务水平协议 （SLA） + +确保服务可用性的合同义务。 + +服务项目 + +包含目录中列出的所有服务的特殊项目。 + +服务提供者 + +向其他系统实体提供服务的系统。在联合身份的情况下，OpenStack 身份是服务提供者。 + +服务注册 + +一种身份服务功能，使服务（如计算）能够自动注册到目录。 + +服务令牌 + +管理员定义的令牌，由计算用于与身份服务进行安全通信。 + +会话后端 + +Horizon 用于跟踪客户端会话的存储方法，例如本地内存、Cookie、数据库或 memcached。 + +会话持久化 + +负载平衡服务的一项功能。只要某个服务处于联机状态，它就会尝试强制将服务的后续连接重定向到同一节点。 + +会话存储 + +用于存储和跟踪客户端会话信息的 Horizon 组件。通过 Django 会话框架实现。 + +共享 + +共享文件系统服务上下文中的远程可挂载文件系统。您可以一次将共享装载到多个主机，也可以由多个用户从多个主机访问共享。 + +共享网络 + +共享文件系统服务上下文中的实体，用于封装与网络服务的交互。如果所选驱动程序在需要此类交互的模式下运行，则需要指定共享网络以创建共享。 + +共享文件系统 API + +提供稳定 RESTful API 的共享文件系统服务。该服务在整个共享文件系统服务中对请求进行身份验证和路由。有 python-manilaclient 可以与 API 交互。 + +共享文件系统服务（manila） + +该服务提供一组服务，用于管理多项目云环境中的共享文件系统，类似于 OpenStack 通过 OpenStack Block Storage 服务项目提供基于块的存储管理。使用共享文件系统服务，您可以创建远程文件系统并将文件系统挂载到您的实例上。您还可以在文件系统中读取和写入实例中的数据。 + +共享 IP 地址 + +可分配给共享 IP 组中的 VM 实例的 IP 地址。公共 IP 地址可以在多个服务器之间共享，以便在各种高可用性方案中使用。当 IP 地址共享到另一台服务器时，将修改云网络限制，使每个服务器都能侦听和响应该 IP 地址。您可以选择指定修改目标服务器网络配置。共享 IP 地址可以与许多标准检测信号工具（如 keepalive）一起使用，这些工具可监视故障并管理 IP 故障转移。 + +共享 IP 组 + +可以与组的其他成员共享 IP 的服务器集合。组中的任何服务器都可以与组中的任何其他服务器共享一个或多个公共 IP。除了共享 IP 组中的第一台服务器外，服务器必须启动到共享 IP 组中。一台服务器只能是一个共享 IP 组的成员。 + +共享存储 + +可由多个客户端同时访问的块存储，例如 NFS。 + +Sheepdog + +面向 QEMU 的分布式块存储系统，由 OpenStack 提供支持。 + +简单云身份管理 （SCIM） + +用于在云中管理身份的规范，目前不受 OpenStack 支持。 + +独立计算环境的简单协议 （SPICE） + +SPICE 提供对客户机虚拟机的远程桌面访问。它是 VNC 的替代品。OpenStack支持SPICE。 + +单根 I/O 虚拟化 （SR-IOV） + +当由物理 PCIe 设备实现时，该规范使其能够显示为多个单独的 PCIe 设备。这使多个虚拟化客户机能够共享对物理设备的直接访问，从而提供比等效虚拟设备更高的性能。目前在 OpenStack Havana 及更高版本中受支持。 + +SmokeStack + +针对核心 OpenStack API 运行自动化测试;用 Rails 编写。 + +快照 + +OpenStack 存储卷或映像的时间点副本。使用存储卷快照备份卷。使用映像快照来备份数据，或作为其他服务器的“黄金”映像。 + +软重启 + +通过操作系统命令正确重启 VM 实例的受控重启。 + +软件开发工具包 （SDK） + +包含代码、示例和文档，您可以使用这些代码、示例和文档以所选语言创建应用程序。 + +软件开发生命周期自动化服务（solum） + +OpenStack项目，旨在通过自动化从源到映像的过程，并简化以应用程序为中心的部署，使云服务更易于使用并与应用程序开发过程集成。 + +软件定义网络 （SDN） + +为网络管理员提供一种方法，通过抽象较低级别的功能来管理计算机网络服务。 + +SolidFire 卷驱动程序 + +SolidFire iSCSI 存储设备的块存储驱动程序。 + +solum + +软件开发生命周期自动化服务的代号。 + +点差优先调度器 + +计算 VM 计划算法，尝试以最小的负载在主机上启动新 VM。 + +SQLAlchemy + +用于 Python 的开源 SQL 工具包，用于 OpenStack。 + +SQLite + +一个轻量级的 SQL 数据库，在许多 OpenStack 服务中用作默认的持久化存储方法。 + +堆栈 + +由编排服务根据给定模板（AWS CloudFormation 模板或 Heat 编排模板 （HOT））创建和管理的一组 OpenStack 资源。 + +StackTach + +捕获计算 AMQP 通信的社区项目;对调试很有用。 + +静态 IP 地址 + +固定 IP 地址的替代术语。 + +静态网页 + +对象存储的 WSGI 中间件组件，将容器数据作为静态网页提供。 + +Stein + +OpenStack 第 19 版的代号。OpenStack峰会在德国柏林举行。该版本以柏林的 Steinstraße 街命名。 + +存储后端 + +服务用于持久性存储的方法，例如 iSCSI、NFS 或本地磁盘。 + +存储管理器 + +一个 XenAPI 组件，它提供可插入接口以支持各种持久性存储后端。 + +存储管理器后端 + +XenAPI 支持的持久性存储方法，例如 iSCSI 或 NFS。 + +存储节点 + +提供容器服务、账户服务和对象服务的对象存储节点;控制帐户数据库、容器数据库和对象存储。 + +存储服务 + +提供容器服务、账户服务和对象服务的对象存储节点;控制帐户数据库、容器数据库和对象存储。 + +存储服务 + +对象存储对象服务、容器服务和帐户服务的集合名称。 + +策略 + +指定镜像服务或身份使用的认证源。在数据库服务中，它是指为数据存储实现的扩展。 + +子域 + +父域中的域。无法注册子域。子域使您能够委派域。子域本身可以有子域，因此可以进行三级、四级、五级和更深级别的嵌套。 + +子网 + +IP 网络的逻辑细分。 + +SUSE Linux Enterprise Server （SLES） （英语） + +与 OpenStack 兼容的 Linux 发行版。 + +挂起 + +虚拟机实例将暂停，其状态将保存到主机的磁盘中。 + +交换 + +操作系统使用的基于磁盘的虚拟内存，用于提供比系统上实际可用的内存更多的内存。 + +swift + +OpenStack 对象存储服务的代号。 + +swift 多合一 （SAIO） + +Swift 中间件 + +提供附加功能的对象存储组件的统称。 + +Swift 代理服务器 + +充当对象存储的网守，并负责对用户进行身份验证。 + +Swift 存储节点 + +运行对象存储帐户、容器和对象服务的节点。 + +同步点 + +自上次容器和帐户数据库在对象存储中的节点之间同步以来的时间点。 + +系统管理员 + +计算 RBAC 系统中的默认角色之一。使用户能够将其他用户添加到项目中，与与项目关联的 VM 映像进行交互，以及启动和停止 VM 实例。 + +系统使用情况 + +一个计算组件，它与通知系统一起收集计量和使用情况信息。此信息可用于计费。 + +#### T + +Tacker + +NFV 编排服务的代码名称 + +遥测服务（telemetry） + +OpenStack项目收集包含已部署云的物理和虚拟资源利用率的测量值，保留此数据以供后续检索和分析，并在满足定义的条件时触发操作。 + +TempAuth 函数 + +Object Storage中的一种身份验证工具，使Object Storage本身能够执行身份验证和授权。经常用于测试和开发。 + +Tempest + +自动化软件测试套件，旨在针对 OpenStack 核心项目的主干运行。 + +TempURL + +一个对象存储中间件组件，用于创建用于临时对象访问的 URL。 + +租户 + +一组用户;用于隔离对计算资源的访问。项目的替代术语。 + +租户 API + +项目可访问的 API。 + +租户端点 + +与一个或多个项目关联的身份服务 API 端点。 + +租户 ID + +项目 ID 的替代术语。 + +令牌 + +用于访问 OpenStack API 和资源的字母数字文本字符串。 + +令牌服务 + +一个身份服务组件，用于在用户或项目通过身份验证后管理和验证令牌。 + +逻辑删除 + +用于标记已删除的对象存储对象;确保对象在删除后不会在另一个节点上更新。 + +主题发布者 + +执行 RPC 调用时创建的进程;用于将消息推送到主题交换。 + +Torpedo + +用于针对 OpenStack API 运行自动化测试的社区项目。 + +Train + +OpenStack 第 20 版的代号。OpenStack 基础架构峰会在美国科罗拉多州丹佛市举行。 + +丹佛的两次项目团队聚会会议在从市中心到机场的火车线旁边的一家酒店举行。那里的交叉信号灯过去曾出现过某种故障，导致它们在火车正常驶来时没有停下车厢。因此，火车在经过该地区时必须鸣喇叭。显然，住在酒店里，乘坐火车24/7吹喇叭，不太理想。结果，出现了许多关于丹佛和火车的笑话——因此这个版本被称为火车。 + +交易 ID + +分配给每个对象存储请求的唯一 ID;用于调试和跟踪。 + +瞬态 + +非耐用品的替代术语。 + +瞬态交换 + +非持久交换的替代术语。 + +瞬态消息 + +存储在内存中并在服务器重新启动后丢失的消息。 + +瞬态队列 + +非持久队列的替代术语。 + +TripleO + +OpenStack-on-OpenStack 程序。OpenStack Deployment 程序的代号。 + +Trove + +OpenStack 数据库服务的代号。 + +可信平台模块（TPM） + +专用微处理器，用于将加密密钥整合到设备中，以验证和保护硬件平台。 + +#### U + +Ubuntu + +基于 Debian 的 Linux 发行版。 + +无作用域令牌 + +Identity 服务默认令牌的替代术语。 + +更新器 + +一组对象存储组件的统称，用于处理容器和对象的排队和失败的更新。 + +用户 + +在 OpenStack Identity 中，实体代表单个 API 使用者，并由特定域拥有。在 OpenStack 计算中，用户可以与角色和/或项目相关联。 + +用户数据 + +用户在启动实例时可以指定的数据 Blob。实例可以通过元数据服务或配置驱动器访问此数据。通常用于传递实例在启动时运行的 shell 脚本。 + +用户模式 Linux （UML） + +支持 OpenStack 的虚拟机管理程序。 + +Ussuri + +OpenStack 第 21 版的代号。OpenStack基础设施峰会在中华人民共和国上海举行。该版本以乌苏里河命名。 + +#### V + +Victoria + +OpenStack 第 22 版的代号。OpenDev + PTG 计划在加拿大不列颠哥伦比亚省温哥华举行。该版本以不列颠哥伦比亚省首府维多利亚命名。 + +由于 COVID-19，现场活动被取消。该事件正在虚拟化。 + +VIF UUID + +分配给每个网络 VIF 的唯一 ID。 + +虚拟中央处理器 （vCPU） + +细分物理 CPU。然后，实例可以使用这些分区。 + +虚拟磁盘映像 （VDI） + +映像服务支持的虚拟机映像磁盘格式之一。 + +虚拟可扩展局域网 （VXLAN） + +一种网络虚拟化技术，试图减少与大型云计算部署相关的可伸缩性问题。它使用类似 VLAN 的封装技术将以太网帧封装在 UDP 数据包中。 + +虚拟硬盘 （VHD） + +镜像服务支持的虚拟机镜像磁盘格式之一。 + +虚拟 IP 地址 （VIP） + +在负载平衡器上配置的 Internet 协议 （IP） 地址，供连接到负载平衡服务的客户端使用。传入连接将根据负载均衡器的配置分发到后端节点。 + +虚拟机 （VM） + +在虚拟机监控程序上运行的操作系统实例。多个 VM 可以在同一物理主机上同时运行。 + +虚拟网络 + +网络中的 L2 网段。 + +虚拟网络计算 （VNC） + +用于远程控制台访问 VM 的开源 GUI 和 CLI 工具。 + +虚拟网络接口 （VIF） + +插入网络网络中的端口的接口。通常属于 VM 的虚拟网络接口。 + +虚拟网络 + +使用物理网络基础架构上的虚拟机和覆盖网络组合实现网络功能虚拟化（如交换、路由、负载平衡和安全性）的通用术语。 + +虚拟端口 + +虚拟接口连接到虚拟网络的连接点。 + +虚拟专用网络 （VPN） + +由 Compute 以 cloudpipes 的形式提供，这些专用实例用于按项目创建 VPN。 + +虚拟服务器 + +VM 或来宾的替代术语。 + +虚拟交换机 （vSwitch） + +在主机或节点上运行并提供基于硬件的网络交换机的特性和功能的软件。 + +虚拟 VLAN + +虚拟网络的替代术语。 + +VirtualBox + +支持 OpenStack 的虚拟机管理程序。 + +Vitrage + +Root Cause Analysis服务的代码名称。 + +VLAN 管理器 + +一个 Compute 组件，它提供 dnsmasq 和 radvd，并设置与 cloudpipe 实例之间的转发。 + +VLAN 网络 + +网络控制器提供虚拟网络，使计算服务器能够相互交互以及与公用网络交互。所有计算机都必须具有公共和专用网络接口。VLAN 网络是一个专用网络接口，由 VLAN 管理器 `vlan_interface` 选项控制。 + +虚拟机磁盘（VMDK） + +镜像服务支持的虚拟机镜像磁盘格式之一。 + +虚拟机映像 + +映像的替代术语。 + +虚拟机远程控制 （VMRC） + +使用 Web 浏览器访问 VM 实例控制台的方法。由计算支持。 + +VMware API 接口 + +支持在计算中与 VMware 产品进行交互。 + +VMware NSX Neutron 插件 + +在 Neutron 中提供对 VMware NSX 的支持。 + +VNC 代理 + +一个计算组件，允许用户通过 VNC 或 VMRC 访问其 VM 实例的控制台。 + +卷 + +基于磁盘的数据存储通常表示为具有支持扩展属性的文件系统的 iSCSI 目标;可以是持久的，也可以是短暂的。 + +卷 API + +块存储 API 的替代名称。 + +卷控制器 + +一个块存储组件，用于监督和协调存储卷操作。 + +卷驱动程序 + +卷插件的替代术语。 + +卷 ID + +应用于块存储控制下每个存储卷的唯一 ID。 + +卷管理器 + +用于创建、附加和分离持久性存储卷的块存储组件。 + +卷节点 + +运行 cinder-volume 守护程序的块存储节点。 + +卷插件 + +为块存储卷管理器提供对新型和专用后端存储类型的支持。 + +卷工作器 + +一个 cinder 组件，它与后端存储交互，以管理卷的创建和删除以及计算卷的创建，由 cinder-volume 守护程序提供。 + +vSphere + +支持 OpenStack 的虚拟机管理程序。 + +#### W + +Wallaby + +OpenStack 第 23 版的代号。小袋鼠原产于澳大利亚，在这个命名期开始时，澳大利亚正在经历前所未有的野火。 + +Watcher + +基础结构优化服务的代号。 + +权重 + +对象存储设备用于确定哪些存储设备适合作业。设备按大小加权。 + +加权成本 + +决定在计算中启动新 VM 实例的位置时所使用的每个成本的总和。 + +加权 + +一个计算过程，用于确定 VM 实例是否适合特定主机的作业。例如，主机上的 RAM 不足、主机上的 CPU 过多等。 + +工作者 + +侦听队列并执行任务以响应消息的守护程序。例如， cinder-volume worker 管理存储阵列上的卷创建和删除。 + +工作流服务 （mistral） + +OpenStack服务提供了一种基于YAML的简单语言来编写工作流（任务和转换规则），以及一种允许上传、修改、大规模和高度可用的方式运行它们、管理和监控工作流执行状态和单个任务状态的服务。 + +#### X + +X.509 + +X.509 是定义数字证书的最广泛使用的标准。它是一种数据结构，包含主题（实体）可识别信息，例如其名称及其公钥。证书还可以包含一些其他属性，具体取决于版本。X.509 的最新标准版本是 v3。 + +Xen + +Xen 是一个使用微内核设计的虚拟机管理程序，它提供的服务允许多个计算机操作系统在同一计算机硬件上同时执行。 + +Xen API + +Xen 管理 API，受 Compute 支持。 + +Xen 云平台 （XCP） + +支持 OpenStack 的虚拟机管理程序。 + +Xen Storage Manager 卷驱动程序 + +支持与 Xen Storage Manager API 进行通信的块存储卷插件。 + +Xena + +OpenStack 第 24 版的代号。该版本以虚构的战士公主命名。 + +XenServer + +An OpenStack-supported hypervisor. 支持 OpenStack 的虚拟机管理程序。 + +XFS 函数 + +由 Silicon Graphics 创建的高性能 64 位文件系统。在并行 I/O 操作和数据一致性方面表现出色。 + +#### Y + +Yoga + +OpenStack 第 25 版的代号。该版本以来自印度的一所哲学学校命名，该学校具有心理和身体实践。 + +#### Z + +Yoga + +消息服务的代号。 + +Zed + +OpenStack 第 26 版的代号。该版本以字母 Z 的发音命名。 + +ZeroMQ + +OpenStack 支持的消息队列软件。RabbitMQ 的替代品。也拼写为 0MQ。 + +Zuul + +Zuul 是一个开源 CI/CD 平台，专门用于在登陆单个补丁之前跨多个系统和应用程序进行门控更改。 + +Zuul 用于 OpenStack 开发，以确保只有经过测试的代码才会被合并。 diff --git a/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/spec/distributed-traffic.md b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/spec/distributed-traffic.md new file mode 100644 index 0000000000000000000000000000000000000000..91d742f9238c9fc8d89f606dc8801239455e9776 --- /dev/null +++ b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/spec/distributed-traffic.md @@ -0,0 +1,309 @@ +# 流量分散 + +## 概述 + +OpenStack为用户提供计算和网络服务。用户创建虚拟机并连接Router可以访问外部网络，同时可以开启浮动IP的端口映射，让外部网络的设备访问虚拟机内部的服务。但与此同时，随着虚拟机和浮动IP +端口映射的数量的增多，网络节点的压力也越来越大，必须找到分散网络节点流量，疏解网络节点压力的方法。本方案实现了在OpenStack环境中将网络节点流量分散，保证兼容支持L3 +HA和DVR，同时又将网络资源使用最小化。 + +## 背景 + +用户创建虚拟机并连接Router的基本流程如下。 + +1. 用户提前创建内部网络和外部网络。 +2. 创建Router时指定External Gateway为提前创建的外部网络。 +3. 将Router和创建好的内部网络进行连接。 +4. 创建虚拟机实例时指定内部网络。 +5. 利用创建的外部网络创建浮动IP。 +6. 为虚拟机实例开启浮动IP端口映射。 + +经过上面的操作，用户创建的虚拟机实例可以访问到外部网络，外部网络的设备也可以根据浮动IP指定的端口访问虚拟机实例内部的服务。 + +在一个基本的OpenStack环境中虚拟机实例的流量走向如下所示。 + +![单个虚拟机网络流量](../img/spec/router_1.png) + +在用户创建完多个实例后，虚拟机实例可能会均匀分布在各个计算节点，虚拟机的流量走向可能如下图所示。 + +![多个虚拟机网络流量](../img/spec/router_2.png) + +可以看到，不论虚拟机的东西流量还是南北流量都会经过Network-1节点，这无疑加大了网络节点的负载，同时当网络节点发生故障时不能很好的进行故障恢复。 +那么是否可以将同一子网绑定多个Router，在OpenStack中同一子网可以绑定多个Router，但是子网在绑定Router时默认会将子网的网关地址绑定到Router上，一个子网只有一个网关地址，同时这个网关地址又会在DHCP服务中用到，用于给虚拟机实例提供下一跳的网关地址，于是乎即使将子网绑定到多个Router上，虚拟机内部下一跳的网关地址还会是子网的网关地址，而且Router选择的网络节点用户是不可控的，难免会出现虽然子网绑定了两个Router，但是这两个Router在同一个网络节点上的尴尬场面。 + +为了分散流量OpenStack有应对的策略，可以将neutron的DVR功能打开，为预防网络节点的单点故障也可以打开neutron的L3 +HA，但是上述方法也有它们的局限性。 + +DVR的流量分散有比较大的局限性，原因有以下几点。 +DVR只是作用于同一Router下不同计算节点的虚拟机实例之间的东西流量，已经绑定浮动IP虚拟机的南北流量，对于未绑定浮动IP的虚拟机访问外部网络依据需要经过网络节点。 + +生产环境下，给每个虚拟机都绑定浮动IP是不切实际的，但是可以通过开启浮动IP的端口映射，让多台虚拟机对应一个浮动IP，但在目前的OpenStack版本中，不论是否开启DVR，浮动IP的端口映射的实现都是在网络节点的网络命名空间中完成的。 +最后一点，DVR模式下，为了让虚拟机的南北流量不经过网络节点，从计算节点上直接走出，都会在每个计算节点上生成一个fip开头的网络命名空间，即使虚拟机不会绑定浮动IP。而这个fip网络命名空间中会占用一个外部网络的IP地址，这无疑会加大网络资源的消耗。 + +L3 HA也有几点不足，开启L3 HA后，Router利用keepalived会在几个网络节点之间进行选择，只有Keepalived的状态为Master +的网络节点才会担任真正的流量运输的任务，而对于网络节点选择，用户无权干涉。虽然neutron中给出了Router的默认调度策略，也就是最少Router数，Router会调度到Router个数最少的网络节点上。而且在底层keepalived开启的模式是非抢占的，也就是当vip发生漂移后，即使主服务器恢复正常，也不会自动将资源从备用服务器手中抢占回来，这又增加了对于真正运行Router的网络节点的不确定性。 + +总结一下，现有的技术方案做不到真正的流量分发，即使在开启DVR后，一方面会有一些额外网络资源的损耗，同时又因为Router的网络节点的不确定性，导致虚拟机的南北流量无法做到很好的分发。 + +## 需要解决的问题 + +实现DVR模式和L3 HA模式下以及Legacy模式下网络分发。首先要解决以下几个技术问题： + +1. Router可以指定网络节点，不论是否开启L3 HA。 +2. 同一子网绑定多个Router时，DHCP服务能为不同计算节点的虚拟机提供不同的路由方式。 +3. 在用户使用端口映射时，可以将Router的External Gateway的IP地址作为外部网络的地址。 + +## 实现方案 + +### 解决指定L3 agent的问题 + +首先修改Router的底层数据库为其添加一个configurations字段，用于存储Router的相关配置信息，configurations的格式如下所示。 + +```json +{ + "configurations": { + "preferred_agent": "network-1" + } +} +``` + +在未开启L3 HA时，preferred_agent字段用于指定Router位于的网络节点。 +在开启L3 HA时，configurations的格式如下所示。 + +```json +{ + "configurations": { + "slave_agents": [ + "compute-1" + ], + "master_agent": "network-1" + } +} +``` + +master_agent用于指定Master角色的网络节点，slave_agents用于指定Slave角色的网络节点数组。 + +然后要修改Router的创建逻辑，需要为Router新增一个调度方法。Neutron中router_scheduler_driver默认是LeastRoutersScheduler（最少Router个数的网络节点），继承该类新增调度方法，可以根据Router的configurations字段选择指定的网络节点。 + +![L3 Scheduler](../img/spec/l3_scheduler.png) + +最后需要修改neutron-l3-agent的Router更新的逻辑代码，由于neutron-l3-agent启动时会初始化一个资源队列用于更新资源状态，同时开启一个守护线程用于读取资源队列，每次网络资源状态有变化（创建、删除或者更新）时，就会添加到该队列中，最后根据资源的类型和状态确定将要执行的动作。 +这里Router创建完后，neutron-l3-agent最后会执行_process_added_router方法，先调用RouterInfo的initialize方法，再调用process方法。 +initialize方法主要涉及到Router信息的一些初始化，包括网络命名空间的创建、port的创建、keepalived进程的初始化等等。 +process方法中会做下面几个操作。 + +1. 设置内部的Port，用于连接内部网络； +2. 设置外部Port，用于连接外部网络； +3. 更新路由表； +4. 对于开启L3 HA的Router，需要设置HA的Port，然后开启keepalived进程。 +5. 对于开启DVR的Router，还需要设置一下fip命名空间中的Port。 + +这里只需要考虑L3 HA开启的情况，因为在未开启L3 +HA时，neutron-server创建完Router后，经过新的调度方法选择特定的网络节点，RPC调用直接发送给特定网络节点的neutron-l3-agent服务。开启L3 +HA时，调度方法会选择出master和slave网络节点，并且RPC调用会发送给这些网络节点上的neutron-l3-agent服务。 +neutron-l3-agent会为每个Router启动一个keepalived进程用于L3 +HA，所以需要在keepalived初始化时，将keepalived启动逻辑修改。利用configurations字段的信息，获取master和slave网络节点，同时和当前网络节点的信息判断，确定网络节点的角色。最后，因为指定了master和slave节点，避免出现master网络节点宕机恢复后，vip依旧在slave节点的情况，要把keepalived的模式改为抢占模式。 + +### 解决路由问题 + +解决同一子网绑定多个Router后，虚拟机实例的路由问题。DHCP协议功能不仅包括和DNS服务器分配还包括网关地址分配，也就是可以通过DHCP协议将路由信息传给虚拟机实例。在OpenStack中，虚拟机实例的DHCP由neutron-dhcp-agent提供，neutron-dhcp-agent的核心功能基本由dnsmasq完成。 + +dnsmasq中提供tag标签，可以为指定IP地址添加标签，然后可以根据标签下发配置。 +dnsmasq的host配置文件如下所示。 + +```bash +fa:16:3e:28:a5:0a,host-172-16-0-1.openstacklocal,172.16.0.1,set:subnet-6a4db541-e563-43ff-891b-aa8c05c988c5 +fa:16:3e:2b:dd:88,host-172-16-0-10.openstacklocal,172.16.0.10,set:subnet-6a4db541-e563-43ff-891b-aa8c05c988c5 +fa:16:3e:a1:96:fc,host-172-16-0-207.openstacklocal,172.16.0.207,set:compute-1-subnet-6a4db541-e563-43ff-891b-aa8c05c988c5 +fa:16:3e:45:b4:1a,host-172-16-10-1.openstacklocal,172.16.10.1,set:subnet-faeec4d1-2c0c-4f7a-bc9b-0af562694902 +``` + +dnsmasq的option配置文件如下所示。 + +```bash +tag:subnet-faeec4d1-2c0c-4f7a-bc9b-0af562694902,option:dns-server,8.8.8.8 +tag:subnet-faeec4d1-2c0c-4f7a-bc9b-0af562694902,option:classless-static-route,172.16.0.0/24,0.0.0.0,169.254.169.254/32,172.16.0.2,0.0.0.0/0,172.16.0.1 +tag:subnet-faeec4d1-2c0c-4f7a-bc9b-0af562694902,249,172.16.0.0/24,0.0.0.0,169.254.169.254/32,172.16.0.2,0.0.0.0/0,172.16.0.1 +tag:subnet-faeec4d1-2c0c-4f7a-bc9b-0af562694902,option:router,172.16.0.1 +tag:compute-1-subnet-6a4db541-e563-43ff-891b-aa8c05c988c5,option:classless-static-route,172.16.10.0/24,0.0.0.0,169.254.169.254/32,172.16.0.2,0.0.0.0/0,172.16.0.10 +tag:compute-1-subnet-6a4db541-e563-43ff-891b-aa8c05c988c5,249,172.16.0.0/24,0.0.0.0,169.254.169.254/32,172.16.0.2,0.0.0.0/0,172.16.0.10 +tag:compute-1-subnet-6a4db541-e563-43ff-891b-aa8c05c988c5,option:router,172.16.0.10 +``` + +可以看到IP172.16.0.207被打上了compute-1开头的tag，匹配到option文件后，172.16.0.207的虚拟机的默认路由网关地址就会从172.16.0.1变为172.16.0.10。当然这一切的前提子网需要绑定多个Router。 +同时为neutron-dhcp-agent提供可供管理员修改的配置项，用于指定计算节点和网络节点的关系，可以是一对一，可以是多对一。 + +### 解决Router Gateway端口转发的问题 + +将原本基于浮动IP的端口映射改为基于Router的External Gateway的方式。原因有二： + +1. 基于浮动IP的端口映射，对于原本就要使用Router的External Gateway的用户就会多占用一个外部网络的IP，为减少外部网络IP的使用改用External + Gateway的方式进行端口映射。 +2. 基于浮动IP的端口映射，依赖Router的网络命名空间来做NAT，不开启L3 + HA时，同一子网在绑定多个Router后，由于端口映射创建的逻辑，NAT会发生在子网网关地址所在的Router的网络命名空间中（特定的网络节点），不会分散在各个Router的网络命名空间中（每个网络节点）。这样在端口映射时，会增加网络节点的压力。 + 实现方式和基于浮动IP的端口映射类似，与之不同的是External Gateway不需要选择Router，因为External + Gateway本来和Router就是相关联的。基于浮动IP的端口映射在选择Router时，选择的是子网的网关地址所在的Router。 + +最后，在实现上面三个部分后，用户实现流量分散的步骤如下。 + +1. 用户修改neutron-dhcp-agent的配置文件，修改计算节点和网络节点的映射关系。例如三个网络节点、三个计算节点，配置compute-1走network-1节点，compute-2和compute-3走network-2节点。 +2. 利用neutron的API创建多个Router并指定网络节点，并将Router绑定到同一子网。 +3. 利用子网网络创建多个虚拟机实例。 + +虚拟机实例的网络流量的流向如下图所示。 + +![网络流量](../img/spec/router_3.png) + +可以看到，VM-1访问外部网络经过的是network-1节点，VM-2和VM-3访问外部网络经过的是network-2节点。同时VM-1、VM-2和VM-3又是在同一个子网下，可以互相访问。 + +# API + +## 查看路由器网关端口转发列表 + +```text +GET /v2.0/routers/{router_id}/gateway_port_forwardings + +Response +{ + "gateway_port_forwardings": [ + { + "id": "67a70b09-f9e7-441e-bd49-7177fe70bb47", + "external_port": 34203, + "protocol": "tcp", + "internal_port_id": "b671c61a-95c3-49cd-89f2-b7e817d1f486", + "internal_ip_address": "172.16.0.196", + "internal_port": 518, + "gw_ip_address": "192.168.57.234" + } + ] +} +``` + +## 查看路由器网关端口转发 + +```text +GET /v2.0/routers/{router_id}/gateway_port_forwardings/{port_forwarding_id} + +Response +{ + "gateway_port_forwarding": { + "id": "67a70b09-f9e7-441e-bd49-7177fe70bb47", + "external_port": 34203, + "protocol": "tcp", + "internal_port_id": "b671c61a-95c3-49cd-89f2-b7e817d1f486", + "internal_ip_address": "172.16.0.196", + "internal_port": 518, + "gw_ip_address": "192.168.57.234" + } +} +``` + +## 创建路由器网关端口转发 + +```text +POST /v2.0/routers/{router_id}/gateway_port_forwardings +Request Body +{ + "gateway_port_forwarding": { + "external_port": int, + "internal_port": int, + "internal_ip_address": "string", + "protocol": "tcp", + "internal_port_id": "string" + } +} + +Response +{ + "gateway_port_forwarding": { + "id": "da554833-b756-4626-9900-6256c361f94b", + "external_port": 14122, + "protocol": "tcp", + "internal_port_id": "b671c61a-95c3-49cd-89f2-b7e817d1f486", + "internal_ip_address": "172.16.0.196", + "internal_port": 3634, + "gw_ip_address": "192.168.57.234" + } +} +``` + +## 更新路由器网关端口转发 + +```text +PUT /v2.0/routers/{router_id}/gateway_port_forwardings/{port_forwarding_id} +Request Body +{ + "gateway_port_forwarding": { + "external_port": int, + "internal_port": int, + "internal_ip_address": "string", + "protocol": "tcp", + "internal_port_id": "string" + } +} + +Response +{ + "gateway_port_forwarding": { + "id": "da554833-b756-4626-9900-6256c361f94b", + "external_port": 14122, + "protocol": "tcp", + "internal_port_id": "b671c61a-95c3-49cd-89f2-b7e817d1f486", + "internal_ip_address": "172.16.0.196", + "internal_port": 3634, + "gw_ip_address": "192.168.57.234" + } +} +``` + +## 删除路由器网关端口转发 + +```text +DELETE /v2.0/routers/{router_id}/gateway_port_forwardings/{port_forwarding_id} +``` + +## 新建路由器 + +```text +POST /v2.0/routers +Request Body +{ + "router": { + "name": "string", + "admin_state_up": true, + "configurations": { + "preferred_agent": "string", + "master_agent": "string", + "slave_agents": [ + "string" + ] + } + } +} +``` + +## 更新路由器 + +```text +PUT /v2.0/routers/{router_id} +Request Body +{ + "router": { + "name": "string", + "admin_state_up": true, + "configurations": { + "preferred_agent": "string", + "master_agent": "control01", + "slave_agents": [ + "control01" + ] + } + } +} +``` + +# 开发节奏 + +* 2023-07-28到2023-08-30 完成开发 +* 2023-09-01到2023-11-15 测试、问题修复 +* 2023-11-30引入openEuler 20.03 LTS SP4版本 +* 2023-12-30引入openEuler 22.03 LTS SP3版本 diff --git a/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/spec/openkite.md b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/spec/openkite.md new file mode 100644 index 0000000000000000000000000000000000000000..13fb9725ba39cd96bdf8c106d057a53a9cba8269 --- /dev/null +++ b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/spec/openkite.md @@ -0,0 +1,322 @@ +# 1、前序 + +## 1.1、 软件许可协议 + +本软件基于LGPL V3协议，请用户和开发者注意LGPL协议的要求，其中最重要的一点是**不允许fork项目闭源**。 + +## 1.2、 软件用途 + +## 1.3、 开发人员名单 + +## 1.4、 生命开发周期 + +## 1.5、 功能开发顺序 + +# 2、开发规范约定 + +## 2.1、 窗体控件命名规范 + +- 控件原名称\_窗体\_控件名称组合体首字母大写 +- 示例： + + ```cpp + 按钮原名称：pushButton 主窗体 菜单按钮 + 命名规范：pushButton_MainWindow_Menu + + 按钮原名称：toolButton 主窗体 上传按钮 + 命名规范：toolButton_MainWindow_UpLoad + ``` + +## 2.2、 后台功能实现命名规范 + +- 变量、常量、函数、类、容器等 + +## 2.3、 软件包文件名命名规范 + +## 2.4、 文件命名规范 + +## 2.5、 标注 + +- 删除、移动、改名、权限设置 + +# 3、窗口主体控件名称、尺寸、用途 + +## 3.1、菜单功能大类 + +- PushButton控件用于菜单大类调用窗口 +- 控件尺寸： + - 固定尺寸 80*25 + +| 控件中文名 | 控件种类 | 控件名 | 用途 | +|-----------|-----------|-------------------------------------|----------------| +| 菜单 |PushButton| pushButton_MainWindow_Menu | 调出菜单窗口 | +| 帮助 |PushButton| pushButton_MainWindow_Help | 调出帮助窗口 | +| 工具 |PushButton| pushButton_MainWindow_Tool | 调出工具窗口 | +| 报错分析 |PushButton| pushButton_MainWindow_ErrorAnalysis | 调出报错分析窗口 | +| 监控 |PushButton| pushButton_MainWindow_Monitor | 调出监控窗口 | +| 运维日志 |PushButton| pushButton_MainWindow_OperationLog | 调出运维日志窗口 | + +### 3.1.1、菜单子类 + +- 设置 +- 软件主题 + +### 3.1.2、帮助类 + +- 社区 +- 版本更新 +- 使用手册 + +### 3.1.3、工具类 + +- 插件仓库 +- img镜像工具 +- MD5校验工具 +- OpenStack模块功能测试 +- 压力测试 + +### 3.1.4、报错分析类 + +- 系统报错（节点报错分析） +- OpenStack报错 +- K8S报错 + +### 3.1.5、监控类 + +- OPS监控状态与性能使用分析 +- K8S监控状态与性能使用分析 + +### 3.1.6、运维日志类 + +- 查看历史运维日志 +- 日志导出 + +## 3.2、数据可视化类 + +### 3.2.1、计算机硬件信息类 + +- ProgressBar控件显示计算机硬件性能占用比 +- 控件尺寸： + - 最小尺寸 116*27 + - 高度尺寸固定 + +| 控件中文名 | 控件种类 | 控件名 | 用途 | +|-----------|-----------|--------------------------------------|-----------------------| +| 本机CPU |ProgressBar| progressBar_MainWindow_LocalCPU | 显示本地CPU使用率 | +| 目标CPU |ProgressBar| progressBar_MainWindow_TargetCPU | 显示目标CPU使用率 | +| 本机RAM |ProgressBar| progressBar_MainWindow_LocalRAM | 显示本机RAM使用率 | +| 目标RAM |ProgressBar| progressBar_MainWindow_TargetRAM | 显示目标RAM使用率 | +| 本机网络 |ProgressBar| progressBar_MainWindow_LocalNetwork | 显示本机网络带宽使用率 | +| 目标网络 |ProgressBar| progressBar_MainWindow_TargetNetwork | 显示目标网络带宽使用率 | +| 本机磁盘 |ProgressBar| progressBar_MainWindow_LocalDisk | 显示本机磁盘IO使用率 | +| 目标磁盘 |ProgressBar| progressBar_MainWindow_TargetDisk | 显示目标磁盘IO使用率 | + +### 3.2.2、计算机软件信息类 + +- Label控件显示系统IP与DNS +- 控件尺寸： + - 固定尺寸 110*27 + +| 控件中文名 |控件种类| 控件名 | 用途 | +|-----------|-------|----------------------------|------------| +| 本机IP |Label | label_MainWindow_LocalIP | 显示本机IP | +| 目标IP |Label | label_MainWindow_TargetIP | 显示目标IP | +| 本机DNS |Label | label_MainWindow_LocalNDS | 显示本机DNS | +| 目标DNS |Label | label_MainWindow_TargetNDS | 显示目标DNS | + +- ListWidget控件显示系统必要信息项说明 +- 控件尺寸： + - 固定尺寸 200*111 + +| 控件中文名 | 控件种类 | 控件名 | 用途 | +|-------------|-------------|---------------------------------|----------------| +| 系统信息显示 | ListWidgets | listWidget_MainWidow_SystemShow | 显示系统必要信息 | + +- 系统必要信息显示所用变量的API接口 + +| 中文名 | 变量类型 | 变量名 | 用途 | +|---------|-------------|---------------------|---------------------| +| 发行版 | QStringList | systemNameShow | linux发行版名称 | +| 版本号 | QStringList | systemVersion | linux发行版版本号 | +| 内核号 | QStringList | systemKernel | linux发行版内核版本 | +| 管理权限 | QStringList | systemAdminPower | 当前账号操作权限 | +| 服务名称 | QStringList | systemServiceName | 当前运维软件服务名称 | +| 服务版本 | QStringList | systemServicVersion | 当前运维软件版本 | + +- Label与ProgressBar控件显示当前运行命令及进度 +- 控件尺寸： + - 当前运行命令控件尺寸： + - 最小尺寸：500*31 + - 高度尺寸固定 + - 当前命令进度控件尺寸： + - 最小尺寸：171*31 + - 高度尺寸固定 + +|中文名|控件种类|控件名|用途| +|------|-------|-----|----| +|当前运行命令|Label|label_MainWindow_ShowCurrentCommand|显示当前集群或节点正在运行的命令| +|当前命令进度|ProgressBar|progressBar_MainWindow_ShowCommandProgress|显示当前集群或节点正在运行的命令的进度| + +## 3.3、添加集群类 + +### 3.3.1、 集群添加类 + +- ToolButton控件添加集群节点信息 +- 控件尺寸： + - 固定尺寸：300*31 + +|中文名|控件类型|控件名|用途| +|------|-------|------|----| +|添加集群/节点|ToolButton|toolButton_MainWindow_AddNode|弹出窗口添加集群或节点| + +- 单节点添加 +- 批量节点添加 +- 集群添加 + +### 3.3.2、集群显示类 + +- TreeWidget控件显示集群信息 +- 控件尺寸： + - 最小尺寸：200*438 + - 宽度尺寸固定 + +| 中文名 |控件类型|控件名|用途| +|------|-------|------|---| +|节点信息|TreeWidget|treeWidget_MainWindow_ShowNode|用于显示集群与节点信息或点击信息后创建SSH远程窗口界面| + +- 集群名称 +- 节点名称 +- 节点IP地址 + +### 3.4、脚本与部署类 + +- TerrWidget控件弹窗 +- 控件尺寸： + - 上传、脚本按钮固定尺寸：63*31 + - 部署按钮固定尺寸：65*31 + +| 中文名 | 控件类型 | 控件名 | 用途 | +|--------|------------|------------------------------|-----------------------| +| 上传 | terrWidget | toolButton_MainWindow_UpLoad | 弹出上传窗体:load.ui | +| 脚本 | terrWidget | toolButton_MainWindow_Shell | 弹出脚本窗体:shell.ui | +| 部署 | terrWidget | toolButton_MainWindow_Deploy | 弹出部署窗体:deploy.ui | + +### 3.4.1、上传与下载功能类 + +- 脚本编译器 + - yaml编译器 + - 脚本编译器 +- 加载本地策略 + - 加载集群配置策略 + - 加载节点配置策略 +- 上传文件到目标计算机 + - 单节点 + - 多节点 +- 下载文件到本地计算机 + - 单节点 + - 多节点 +- 目标计算机文件互传 + - 点对点互传 + - 点对多互传 + +### 3.4.2、脚本类 + +- 编辑 + - 编辑子模块脚本 + - 编辑集群模块脚本 +- 查看 + - 查看子模块脚本 + - 查看集群模块脚本 +- 导出 + - 导出子模块脚本 + - 导出集群模块脚本 + - 导出所有脚本 + +### 3.4.3、部署类 + +- 部署 + - 可批量选择节点部署不同功能脚本 + - 可集群部署不同节点不同功能脚本 + - 可单节点部署不同功能脚本 +- 终止 + - 可批量多节点、单节点、集群终止当前部署 + +### 3.5、功能插件类 + +### 3.5.1、基础运维类 + +- 修改服务器计算机名 +- 修改服务器用户名 +- 修改服务器密码 +- 修改防火墙配置 +- 修改host +- 修改DNS +- 修改网关 +- 修改IP +- 部署时间服务 +- 部署DNS服务 + +### 3.5.2、其他功能插件类 + +- OpenStack插件类 +- K8S插件类 +- Ceph插件类 + +## 3.6、ssh远程显示类 + +- 可复制粘贴命令，中文显示综合端口 + +### 3.6.1、集群SSH远程显示类 + +- 综合端口显示，点对多ssh远程 + +### 3.6.2、单节点SSH远程显示类 + +- 点对点ssh远程 + +# 4、窗口主体功能插件添加方式、规范、API与功能注释 + +## 4.1、工具类 + +- 开发规范： +- API接口： +- 功能注释： +- 面板添加方式： +- 后台功能模块添加方式： +- 文件夹位置： + +## 4.2、功能插件类 + +- 开发规范： +- API接口： +- 功能注释： +- 面板添加方式： +- 后台功能模块添加方式： +- 文件夹位置： + +# 5、后台API调用、规范与使用说明 + +## 5.1、计算机硬件 + +### 5.1.1、CPU + +### 5.1.2、RAM + +## 5.2、计算机软件 + +### 5.2.1、本地软件包 + +### 5.2.2、源软件包 + +# 6、开发思路备注 + +- 在各种操作前进行判断本地网络与目标网络是否连同 +- 在目标网络无法连通时提示：目标IP网络不通 +- 在集群节点都无法联通时，集群节点字体灰色 +- 在集群操作或多节点操作时提示无法连接的目标信息，并提示确实是否继续，如继续则屏蔽无法连接的节点去进行批量部署 +- 界面信息刷新频率 + - 软硬件信息刷新频率 + - cpu、内存等占比显示信息的刷新频率为0.5s + - ssh界面刷屏频率为实时刷新 + - 集群显示信息为实时刷新 + - 系统必要信息显示区域为实时刷新 diff --git a/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/spec/openstack-sig-tool-requirement.md b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/spec/openstack-sig-tool-requirement.md new file mode 100644 index 0000000000000000000000000000000000000000..a0c09017a9bf0d142268e9d1d0ec772dd501cba6 --- /dev/null +++ b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/spec/openstack-sig-tool-requirement.md @@ -0,0 +1,157 @@ +# openEuler OpenStack开发平台需求说明书 + +## 背景 + +目前，随着SIG的不断发展，我们明显的遇到了以下几类问题： +1. OpenStack技术复杂，涉及云IAAS层的计算、网络、存储、镜像、鉴权等方方面面的技术，开发者很难全知全会，提交的**代码逻辑、质量堪忧**。 +2. OpenStack是由python编写的，python软件的依赖问题难以处理，以OpenStack Wallaby版本为例，涉及核心python软件包400+， 每个软件的依赖层级、依赖版本**错综复杂，选型困难**，难以形成闭环。 +3. OpenStack软件包众多，RPM Spec编写开发量巨大，并且随着openEuler、OpenStack本身版本的不断演进，N:N的适配关系会导致**工作量成倍增长，人力成本越来越大**。 +4. OpenStack测试门槛过高，不仅需要开发人员熟悉OpenStack，还要对虚拟化、虚拟网桥、块存储等Linux底层技术有一定了解与掌握，部署一套OpenStack环境耗时过长，功能测试难度巨大。并且测试场景多，比如X86、ARM64架构测试，裸机、虚机种类测试，OVS、OVN网桥测试，LVM、Ceph存储测试等等，更加加重了**人力成本以及技术门槛**。 + +针对以上问题需要在openEuler OpenStack提供一个开发平台，解决开发过程遇到的以上痛点问题。 + +## 目标 + +设计并开发一个OpenStack强相关的openEuler开源开发平台，通过规范化、工具化、自动化的方式，满足SIG开发者的日常开发需求，降低开发成本，减少人力投入成本，降低开发门槛，从而提高开发效率、提高SIG软件质量、发展SIG生态、吸引更多开发者加入SIG。 + +## 范围 + +**用户范围**：openEuler OpenStack SIG开发者 + +**业务范围**：openEuler OpenStack SIG日常开发活动 + +**编程语言**：Python、Ansible、Jinja、JavaScript + +**IT技术**：Web服务、RestFul规范、CLI规范、前端GUI、数据库使用 + +## 功能 + +OpenStack开发平台整体采用C/S架构，以SIG对外提供平台能力，client端面向指定用户白名单开放。 + +为方便白名单以外用户使用，本平台还提供CLI模式，在此模式下不需要额外服务端通信，在本地即可开箱即用。 + +1. 输出OpenStack服务类软件、依赖库软件的RPM SPEC开发规范，开发者及Reviewer需要严格遵守规范进行开发实施。 +2. 提供OpenStack python软件依赖分析功能，一键生成依赖拓扑与结果，保证依赖闭环，避免软件依赖风险。 +3. 提供OpenStack RPM spec生成功能，针对通用性软件，提供一键生成 RPM spec的功能，缩短开发时间，降低投入成本。 +4. 提供自动化部署、测试平台功能，实现一键在任何openEuler版本上部署指定OpenStack版本的能力，快速测试、快速迭代。 +5. 提供openEuler Gitee仓库自动化处理能力，满足批量修改软件的需求，比如创建代码分支、创建仓库、提交Pull Request等功能。 + +### SPEC开发规范制定 + +【功能点】 + + 1. 约束OpenStack服务级项目SPEC格式与内容规范 + 2. 规定OpenStack依赖库级别项目SPEC的框架。 + +【先决条件】：OpenStack SIG全体Maintainer达成一致，参与厂商没有分歧。 + +【参与方】：中国电信、中国联通、统信软件 + +【输入】：RPM SPEC编写标准 + +【输出】：服务级、依赖库级SPEC模板；软件分层规范。 + +【对其他功能的影响】：本功能是以下软件功能的前提，下述如`SPEC自动生成功能`需遵循本规范执行。 + +### 依赖分析需求 + +【功能点】 + + 1. 自动生成基于指定openEuler版本的OpenStack依赖表。 + 2. 能处理依赖成环、版本缺省、名称不一致等依赖常见问题。 + +【先决条件】：N/A + +【参与方】：OpenStack SIG核心开发者 + +【输入】：openEuler版本号、OpenStack版本号、目标依赖范围（核心/测试/文档） + +【输出】：指定OpenStack版本的全量依赖库信息，包括最小/最大依赖版本、所属openEuler SIG、RPM包名、依赖层级、子依赖树等内容，可以以Excel表格的方式输出。 + +【对其他功能的影响】：N/A + +### Spec自动生成需求 + +【功能点】 + + 1. 一键生成OpenStack依赖库类软件的RPM SPEC + 2. 支持各种Python软件构建系统，比如setuptools、pyproject等。 + +【先决条件】：需遵守`SPEC开发规范` + +【参与方】：OpenStack SIG核心开发者 + +【输入】：指定软件名及目标版本 + +【输出】：对应软件的RPM SPEC文件 + +【对其他功能的影响】：生成的SPEC可以通过下述`代码提交功能`一键push到openEuler社区。 + +### 自动化部署、测试需求 + +【功能点】 + + 1. 一键快速部署指定OpenStack版本、拓扑、功能的OpenStack单/多节点环境 + 2. 一键基于已部署OpenStack环境进行资源预配置与功能测试。 + 3. 支持多云、主机纳管功能，支持插件自定义功能。 + +【先决条件】：N/A + +【参与方】：OpenStack SIG核心开发者、各个云平台相关开发者 + +【输入】：目标OpenStack版本、计算/网络/存储的driver场景 + +【输出】：一个可以一键执行OpenStack Tempest测试的OpenStack环境；Tempest测试报告。 + +【对其他功能的影响】： N/A + +### 一键代码处理需求 + +【功能点】 + + 1. 一键针对openEuler OpenStack所属项目的Repo、Branch、PR执行各种操作。 + 2. 操作包括：建立/删除源码仓;建立/删除openEuler分支；提交软件Update PR；在PR中添加评审意见。 + +【先决条件】：提交PR功能依赖上述`SPEC生成`功能 + +【参与方】：OpenStack SIG核心开发者 + +【输入】：指定软件名、openEuler release名、目标Spec文件、评审意见内容。 + +【输出】：软件建仓PR；软件创建分支PR；软件升级PR；PR新增评审意见。 + +【对其他功能的影响】：N/A + +## 非功能需求 + +### 测试需求 + +1. 对应软件代码需包含单元测试，覆盖率不低于80%。 +2. 需提供端到端功能测试，覆盖上述所有接口，以及核心的场景测试。 +3. 基于openEuler社区CI，构建CI/CD流程，所有Pull Request要有CI保证代码质量，定期发布release版本，软件发布间隔不大于3个月。 + +### 安全 + +1. 数据安全：软件全程不联网，持久存储中不包含用户敏感信息。 +2. 网络安全：OOS在REST架构下使用http协议通信，但软件设计目标实在内网环境中使用，不建议暴露在公网IP中，如必须如此，建议增加访问IP白名单限制。 +3. 系统安全：基于openEuler安全机制，定期发布CVE修复或安全补丁。 +4. 应用层安全：不涉及，不提供应用级安全服务，例如密码策略、访问控制等。 +5. 管理安全：软件提供日志生成和周期性备份机制，方便用户定期审计。 + +### 可靠性 + +本软件面向openEuler社区OpenStack开发行为，不涉及服务上线或者商业生产落地，所有代码公开透明，不涉及私有功能及代码。因此不提供例如节点冗余、容灾备份能功能。 + +### 开源合规 + +本平台采用Apache2.0 License，不限制下游fork软件的闭源与商业行为，但下游软件需标注代码来源以及保留原有License。 + +## 实施计划 +| 时间 | 内容 | +|:-----------------:|:-----------:| +| 2021.06 | 完成软件整体框架编写，实现CLI Built-in机制，至少一个API可用 | +| 2021.12 | 完成CLI Built-in机制的全量功能可用 | +| 2022.06 | 完成质量加固，保证功能，在openEuler OpenStack社区开发流程中正式引入OOS | +| 2022.12 | 不断完成OOS，保证易用性、健壮性，自动化覆盖度超过80%，降低开发人力投入 | +| 2023.06 | 补齐REST框架、CI/CD流程，丰富Plugin机制，引入更多backend支持 | +| 2023.12 | 完成前端GUI功能 | diff --git a/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/spec/openstack-sig-tool.md b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/spec/openstack-sig-tool.md new file mode 100644 index 0000000000000000000000000000000000000000..88406e48ef2d685f5d63dd59494f61a163fc88ab --- /dev/null +++ b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/spec/openstack-sig-tool.md @@ -0,0 +1,932 @@ + +# openEuler OpenStack 开发平台 + +openEuler OpenStack SIG成立于2021年，是由中国联通、中国电信、华为、统信等公司的开发者共同投入并维护的SIG小组，旨在openEuler之上提供原生的OpenStack，构建开放可靠的云计算技术栈，是openEuler的标杆SIG。但OpenStack本身技术复杂、包含服务众多，开发门槛较高，对贡献者的技术能力要求也较高，人力成本高居不下，在实际开发与贡献中存在各种各样的问题。为了解决SIG面临的问题，亟需一个openEuler+OpenStack解决方案，从而降低开发者门槛，降低投入成本，提高开发效率，保证SIG的持续活跃与可持续发展。 + +## 1. 概述 + +### 1.1 当前现状 + +目前，随着SIG的不断发展，我们明显的遇到了以下几类问题： +1. OpenStack技术复杂，涉及云IAAS层的计算、网络、存储、镜像、鉴权等方方面面的技术，开发者很难全知全会，提交的代码逻辑、质量堪忧。 +2. OpenStack是由python编写的，python软件的依赖问题难以处理，以OpenStack Wallaby版本为例，涉及核心python软件包400+， 每个软件的依赖层级、依赖版本错综复杂，选型困难，难以形成闭环。 +3. OpenStack软件包众多，RPM Spec编写开发量巨大，并且随着openEuler、OpenStack本身版本的不断演进，N:N的适配关系会导致工作量成倍增长，人力成本越来越大。 +4. OpenStack测试门槛过高，不仅需要开发人员熟悉OpenStack，还要对虚拟化、虚拟网桥、块存储等Linux底层技术有一定了解与掌握，部署一套OpenStack环境耗时过长，功能测试难度巨大。并且测试场景多，比如X86、ARM64架构测试，裸机、虚机种类测试，OVS、OVN网桥测试，LVM、Ceph存储测试等等，更加加重了人力成本以及技术门槛。 + + +### 1.2 解决方案 + +针对以上目前SIG遇到的问题，规范化、工具化、自动化的目标势在必行。本篇设计文档旨在在openEuler OpenStack SIG中提供一个端到端可用的开发解决方案，从技术规范到技术实现，提出严格的标准要求与设计方案，满足SIG开发者的日常开发需求，降低开发成本，减少人力投入成本，降低开发门槛，从而提高开发效率、提高SIG软件质量、发展SIG生态、吸引更多开发者加入SIG。主要动作如下： +1. 输出OpenStack服务类软件、依赖库软件的RPM SPEC开发规范，开发者及Reviewer需要严格遵守规范进行开发实施。 +2. 提供OpenStack python软件依赖分析功能，一键生成依赖拓扑与结果，保证依赖闭环，避免软件依赖风险。 +3. 提供OpenStack RPM spec生成功能，针对通用性软件，提供一键生成 RPM spec的功能，缩短开发时间，降低投入成本。 +4. 提供自动化部署、测试平台功能，实现一键在任何openEuler版本上部署指定OpenStack版本的能力，快速测试、快速迭代。 +5. 提供openEuler Gitee仓库自动化处理能力，满足批量修改软件的需求，比如创建代码分支、创建仓库、提交Pull Request等功能。 + +以上解决方法可以统一到一个系统平台中，我们称作OpenStack SIG Tool（以下简称oos），即就是openEuler OpenStack开发平台，具体架构如下： +``` + ┌────────────────────┐ ┌─────────────────────┐ + │ CLI │ │ GUI │ + └─────┬─────────┬────┘ └──────────┬──────────┘ + │ │ │ + Built-in│ └───────────┬────────────┘ + │ │REST +┌─────────────────▼─────────────────────▼────────────────────────────────┐ +│ OpenStack Develop Platform │ +└───────────────────────────────────┬────────────────────────────────────┘ + │ + ┌────────────────────┬────┴─────────────┬────────────────┐ + │ │ │ │ +┌─────────▼─────────┐ ┌───────▼───────┐ ┌───────▼───────┐ ┌─────▼─────┐ +│Dependency Analysis│ │SPEC Generation│ │Deploy and Test│ │Code Action│ +└───────────────────┘ └───────────────┘ └───────────────┘ └───────────┘ +``` +该架构主要有以下两种模式： +1. Client/Server模式 + 在这种模式下，oos部署成Web Server形式，Client通过REST方式调用oos。 + - 优点：提供异步调用能力，支持并发处理，支持记录持久化。 + + - 缺点：有一定安装部署成本，使用方式较为死板。 + +2. Built-in模式 + 在这种模式下，oos无需部署，以内置CLI的方式对外提供服务，用户通过cli直接调用各种功能。 + - 优点：无需部署，随时随地可用。 + + - 缺点：没有持久化能力，不支持并发，单人单用。 + +## 2. 详细设计 + +### 2.1 OpenStack Spec规范 + +Spec规范是一个或多个spec模板，针对RPM spec的每个关键字及构建章节，严格规定相关内容，开发者在编写spec时，必须满足规范要求，否则代码不允许被合入。规范内容由SIG maintainer公开讨论后形成结论，并定期审视更新。任何人都有权利提出对规范的质疑和建议， maintainer负责解释与刷新。规范目前包括两类： +1. 服务类软件规范 + 此类软件以Nova、Neutron、Cinder等OpenStack核心服务为例，它们一般定制化要求高，内容区别大，必要人为手动编写。规范需清晰规定软件的分层方法、构建方法、软件包组成内容、测试方法、版本号规则等内容。 + +2. 通用依赖类软件规范 + 此类软件一般定制化低，内容结构区别小，适合自动化工具一键生成，我们只需要在规范中定义相关工具的生成规则即可。 + +#### 2.1.1 服务类软件规范 + +OpenStack每个服务通常包含若干子服务，针对这些子服务，我们在打包的时候也要做拆包处理，分成若干个子RPM包。本章节规定了openEuler SIG对OpenStack服务的RPM包拆分的原则。 + +##### 2.1.1.1 通用原则 + +采用分层架构，RPM包结构如下图所示，以openstack-nova为例： + +``` +Level | Package | Example + | | + ┌─┐ | ┌──────────────┐ ┌────────────────────────┐ | ┌────────────────────┐ ┌────────────────────────┐ + │1│ | │ Root Package │ │ Doc Package (Optional) │ | │ openstack-nova.rpm │ │ openstack-nova-doc.rpm │ + └─┘ | └────────┬─────┘ └────────────────────────┘ | └────────────────────┘ └────────────────────────┘ + | │ | + | ┌─────────────────────┼───────────────────────────┐ | + | │ │ | | + ┌─┐ | ┌────────▼─────────┐ ┌─────────▼────────┐ | | ┌────────────────────────────┐ ┌────────────────────────┐ + │2│ | │ Service1 Package │ │ Service2 Package │ | | │ openstack-nova-compute.rpm │ │ openstack-nova-api.rpm │ + └─┘ | └────────┬─────────┘ └────────┬─────────┘ | | └────────────────────────────┘ └────────────────────────┘ + | | | | | + | └──────────┬─────────┘ | | + | | | | + ┌─┐ | ┌───────▼────────┐ | | ┌───────────────────────────┐ + │3│ | │ Common Package │ | | │ openstack-nova-common.rpm │ + └─┘ | └───────┬────────┘ | | └───────────────────────────┘ + | │ | | + | │ | | + | │ | | + ┌─┐ | ┌────────▼────────┐ ┌────────────────▼────────────────┐ | ┌──────────────────┐ ┌────────────────────────┐ + │4│ | │ Library Package ◄------------| Library Test Package (Optional) │ | │ python2-nova.rpm │ │ python2-nova-tests.rpm │ + └─┘ | └─────────────────┘ └─────────────────────────────────┘ | └──────────────────┘ └────────────────────────┘ +``` + +如图所示，分为4级 + +1. Root Package为总RPM包，原则上不包含任何文件。只做服务集合用。用户可以使用该RPM一键安装所有子RPM包。 + 如果项目有doc相关的文件，也可以单独成包（可选） +2. Service Package为子服务RPM包，包含该服务的systemd服务启动文件、自己独有的配置文件等。 +3. Common Package是共用依赖的RPM包，包含各个子服务依赖的通用配置文件、系统配置文件等。 +4. Library Package为python源码包，包含了该项目的python代码。 + 如果项目有test相关的文件，也可以单独成包（可选） + +涉及本原则的项目有： + +* openstack-nova +* openstack-cinder +* openstack-glance +* openstack-placment +* openstack-ironic + +##### 2.1.1.2 特殊情况 + +有些openstack组件本身只包含一个服务，不存在子服务的概念,这种服务则只需要分为两级： + +``` + Level | Package | Example + | | + ┌─┐ | ┌──────────────┐ ┌────────────────────────┐ | ┌────────────────────────┐ ┌────────────────────────────┐ + │1│ | │ Root Package │ │ Doc Package (Optional) │ | │ openstack-keystone.rpm │ │ openstack-keystone-doc.rpm │ + └─┘ | └───────┬──────┘ └────────────────────────┘ | └────────────────────────┘ └────────────────────────────┘ + | | | + | ┌────────────┴───────────────────┐ | + ┌─┐ | ┌───────▼─────────┐ ┌────────────────▼────────────────┐ | ┌──────────────────────┐ ┌────────────────────────────┐ + │2│ | │ Library Package ◄-----| Library Test Package (Optional) │ | │ python2-keystone.rpm │ │ python2-keystone-tests.rpm │ + └─┘ | └─────────────────┘ └─────────────────────────────────┘ | └──────────────────────┘ └────────────────────────────┘ +``` + +1. Root Package RPM包包含了除python源码外的其他所有文件，包括服务启动文件、项目配置文件、系统配置文件等等。 + 如果项目有doc相关的文件，也可以单独成包（可选） +2. Library Package为python源码包，包含了该项目的python代码。 + 如果项目有test相关的文件，也可以单独成包（可选） + +涉及本原则的项目有： + +* openstack-keystone +* openstack-horizon + +还有些项目虽然有若干子RPM包，但这些子RPM包是互斥的，则这种服务的结构如下： + +``` +Level | Package | Example + | | + ┌─┐ | ┌──────────────┐ ┌────────────────────────┐ | ┌───────────────────────┐ ┌───────────────────────────┐ + │1│ | │ Root Package │ │ Doc Package (Optional) │ | │ openstack-neutron.rpm │ │ openstack-neutron-doc.rpm │ + └─┘ | └────────┬─────┘ └────────────────────────┘ | └───────────────────────┘ └───────────────────────────┘ + | │ | + | ┌─────────────────────┴───────────────────────────────┐ | + | │ | | + ┌─┐ | ┌────────▼─────────┐ ┌──────────────────┐ ┌──────────────────┐ | | ┌──────────────────────────────┐ ┌───────────────────────────────────┐ ┌───────────────────────────────────┐ + │2│ | │ Service1 Package │ │ Service2 Package │ │ Service3 Package │ | | │ openstack-neutron-server.rpm │ │ openstack-neutron-openvswitch.rpm │ │ openstack-neutron-linuxbridge.rpm │ + └─┘ | └────────┬─────────┘ └────────┬─────────┘ └────────┬─────────┘ | | └──────────────────────────────┘ └───────────────────────────────────┘ └───────────────────────────────────┘ + | | | | | | + | └────────────────────┼────────────────────┘ | | + | | | | + ┌─┐ | ┌───────▼────────┐ | | ┌──────────────────────────────┐ + │3│ | │ Common Package │ | | │ openstack-neutron-common.rpm │ + └─┘ | └───────┬────────┘ | | └──────────────────────────────┘ + | │ | | + | │ | | + | │ | | + ┌─┐ | ┌────────▼────────┐ ┌────────────────▼────────────────┐ | ┌─────────────────────┐ ┌───────────────────────────┐ + │4│ | │ Library Package ◄------| Library Test Package (Optional) │ | │ python2-neutron.rpm │ │ python2-neutron-tests.rpm │ + └─┘ | └─────────────────┘ └─────────────────────────────────┘ | └─────────────────────┘ └───────────────────────────┘ +``` + +如图所示，Service2和Service3互斥。 + +1. Root包只包含不互斥的子包，互斥的子包单独提供。 + 如果项目有doc相关的文件，也可以单独成包（可选） +2. Service Package为子服务RPM包，包含该服务的systemd服务启动文件、自己独有的配置文件等。 + 互斥的Service包不被Root包所包含，用户需要单独安装。 +3. Common Package是共用依赖的RPM包，包含各个子服务依赖的通用配置文件、系统配置文件等。 +4. Library Package为python源码包，包含了该项目的python代码。 + 如果项目有test相关的文件，也可以单独成包（可选） + +涉及本原则的项目有： + +* openstack-neutron + +#### 2.1.2 通用依赖类软件规范 + +一个依赖库一般只包含一个RPM包，不需要做拆分处理。 + +``` + Level | Package | Example + | | + ┌─┐ | ┌─────────────────┐ ┌────────────────────────┐ | ┌──────────────────────────┐ ┌───────────────────────────────┐ + │1│ | │ Library Package │ │ Help Package (Optional)│ | │ python2-oslo-service.rpm │ │ python2-oslo-service-help.rpm │ + └─┘ | └─────────────────┘ └────────────────────────┘ | └──────────────────────────┘ └───────────────────────────────┘ +``` + +**NOTE** + +openEuler社区对python2和python3 RPM包的命名有要求，python2的包前缀为*python2-*，python3的包前缀为*python3-*。因此，OpenStack要求开发者在打Library的RPM包时，也要遵守openEuler社区规范。 + +### 2.2 软件依赖功能 + +软件依赖分析功能为用户提供一键分析目标OpenStack版本包含的全量python软件依赖拓扑及对应软件版本的能力。并自动与目标openEuler版本进行比对，输出对应的软件包开发建议。本功能包含两个子功能： +- 依赖分析 + + 对OpenStack python包的依赖树进行解析，拆解依赖拓扑。依赖树本质上是对有向图的遍历，理论上，一个正常的python依赖树是一个有向无环图，有向无环图的解析方法很多，这里采用常用的广度优先搜索方法即可。但在某些特殊场景下，python依赖树会变成有向有环图，例如：Sphinx是一个文档生产项目，但它自己的文档生成也依赖Sphinx，这就导致了依赖环的形成。针对这种问题，我们只需要把环上的特定节点手动断开即可。类似的还有一些测试依赖库。另一种规避方法是跳过文档、测试这种非核心库，这样不仅避免了依赖环的形成，也会极大减少软件包的数量，降低开发工作量。以OpenStack Wallaby版本为例，全量依赖包大概在700+以上，去掉文档、测试后，依赖包大概是300+左右。因此我们引入`core`核心的概念，用户根据自己的需求，选择要分析的软件范围。另外虽然OpenStack包含服务几十个，但用户可能只需要其中的某些服务，因此我们另外引入`projects`过滤器，用户可以根据自己的需求，指定分析的软件依赖范围。 + +- 依赖比对 + 依赖分析完后，还要有对应的openEuler开发动作，因此我们还要提供基于目标openEuler版本的RPM软件包开发建议。openEuler与OpenStack版本之间有N:N的映射关系，一个openEuler版本可以支持多个OpenStack版本，一个OpenStack版本可以部署在多个openEuler版本上。用户在指定了目标openEuler版本和OpenStack版本后，本功能自动遍历openEuler软件库，分析并输出OpenStack涉及的全量软件包需要进行了操作，例如需要初始化仓库、创建openEuler分支、升级软件包等等。为开发者后续的开发提供指导。 + +#### 2.2.1 版本匹配规范 + +- 依赖分析 + + 输入：目标OpenStack版本、目标OpenStack服务列表、是否只分析核心软件 + + 输出：所有涉及的软件包及每个软件包的对应内容。格式如下： + + ``` + └──{OpenStack版本名}_cached_file + └──packageA.yaml + └──packageB.yaml + └──packageC.yaml + ...... + ``` + + 每个软件内容格式如下： + + ``` + { + "name": "packageA", + "version_dict": { + "version": "0.3.7", + "eq_version": "", + "ge_version": "0.3.5", + "lt_version": "", + "ne_version": [], + "upper_version": "0.3.7"}, + "deep": { + "count": 1, + "list": ["packageB", "packageC"]}, + "requires": {} + } + ``` + + 关键字说明 + | Key | Description | + |:-----------------:|:-----------:| + | name | 软件包名 | + | version_dict | 软件版本要求，包括等于、大于等于、小于、不等于，等等 | + | version_dict.deep | 表示该软件在全量依赖树的深度，以及深度遍历的路径 | + | requires | 包含本软件的依赖软件列表 | + + +- 依赖比对 + 输入：依赖分析结果、目标openEuler版本以及base比对基线 + + 输出：一个表格，包含每个软件的分析结果及处理建议，每一行表示一个软件，所有列名及定义规范如下： + + | Column | Description | + |:-----------------:|:-----------:| + | Project Name | 软件包名 | + | openEuler Repo | 软件在openEuler上的源码仓库名 | + | Repo version | openEuler上的源码版本 | + | Required (Min) Version | 要求的最小版本 | + | lt Version | 要求小于的版本| + | ne Version |要求的不等于版本| + | Upper Version |要求的最大版本| + | Status | 开发建议| + | Requires | 软件的依赖列表| + | Depth |软件的依赖树深度| + + 其中`Status`包含的建议有: + - “OK”：当前版本直接可用，不需要处理。 + - “Need Create Repo”：openEuler 系统中没有此软件包，需要在 Gitee 中的 src-openeuler repo 仓新建仓库。 + - “Need Create Branch”：仓库中没有所需分支，需要开发者创建并初始化。 + - “Need Init Branch”：表明分支存在，但是里面并没有任何版本的源码包，开发者需要对此分支进行初始化。 + - “Need Downgrade”：降级软件包。 + - “Need Upgrade”：升级软件包。 + + 开发者根据`Status`的建议进行后续开发动作。 + +#### 2.2.2 API和CLI定义 + +1. 创建依赖分析 + - CLI: `oos dependence analysis create` + + - endpoint: `/dependence/analysis` + + - type: POST + + - sync OR async: async + + - request body: + ``` + { + "release"[required]: Enum("OpenStack Relase"), + "runtime"[optional][Default: "3.10"]: Enum("Python version"), + "core"[optional][Default: False]: Boolean, + "projects"[optional][Default: None]: List("OpenStack service") + } + ``` + - response body: + ``` + { + "ID": UUID, + "status": Enum("Running", "Error") + } + ``` +2. 获取依赖分析 + - CLI: `oos dependence analysis show`、`oos dependence analysis list` + + - endpoint: `/dependence/analysis/{UUID}`、`/dependence/analysis` + + - type: GET + + - sync OR async: sync + + - request body: None + + - response body: + ``` + { + "ID": UUID, + "status": Enum("Running", "Error", "OK") + } + ``` + +3. 删除依赖分析 + - CLI: `oos dependence analysis delete` + + - endpoint: `/dependence/analysis/{UUID}` + + - type: DELETE + + - sync OR async: sync + + - request body: None + + - response body: + ``` + { + "ID": UUID, + "status": Enum("Error", "OK") + } + ``` + +4. 创建依赖比对 + - CLI: `oos dependence generate` + + - endpoint: `/dependence/generate` + + - type: POST + + - sync OR async: async + + - request body: + ``` + { + "analysis_id"[required]: UUID, + "compare"[optional][Default: None]: { + "token"[required]: GITEE_TOKEN_ID, + "compare-from"[optional][Default: master]: Enum("openEuler project branch"), + "compare-branch"[optional][Default: master]: Enum("openEuler project branch") + + } + } + ``` + - response body: + ``` + { + "ID": UUID, + "status": Enum("Running", "Error") + } + ``` + +5. 获取依赖比对 + - CLI: `oos dependence generate show`、`oos dependence generate list` + + - endpoint: `/dependence/generate/{UUID}`、`/dependence/generate` + + - type: GET + + - sync OR async: sync + + - request body: None + + - response body: + ``` + { + "ID": UUID, + "data" RAW(result data file) + } + ``` + +6. 删除依赖比对 + - CLI: `oos dependence generate delete` + + - endpoint: `/dependence/generate/{UUID}` + + - type: DELETE + + - sync OR async: sync + + - request body: None + + - response body: + ``` + { + "ID": UUID, + "status": Enum("Error", "OK") + } + ``` + +### 2.3 软件SPEC生成功能 +OpenStack依赖的大量python库是面向开发者的，这种库不对外提供用户服务，只提供代码级调用，其RPM内容构成单一、格式固定，适合使用工具化方式提高开发效率。 + +#### 2.3.1 SPEC生成规范 + +SPEC编写一般分为几个阶段，每个阶段有对应的规范要求： +1. 常规项填写，包括Name、Version、Release、Summary、License等内容，这些内容由目标软件的pypi信息提供 +2. 子软件包信息填写，包括软件包名、编译依赖、安装依赖、描述信息等。这些内容也由目标软件的pypi信息提供。其中软件包名需要有明显的python化显示，比如以`python3-`为前缀。 +3. 构建过程信息填写，包括%prep、%build %install %check内容，这些内容形式固定，生成对应rpm宏命令即可。 +4. RPM包文件封装阶段，本阶段通过文件搜索方式，把bin、lib、doc等内容分别放到对应目录即可。 + +**NOTE**：在通用规范外，也有一些例外情况，需要特殊说明： +1. 软件包名如果本身已包含`python`这样的字眼，不再需要添加`python-`或`python3-`前缀。 +2. 软件构建和安装阶段，根据软件本身的安装方式不同，宏命令包括`%py3_build`或`pyproject_build`，需要人工审视。 +3. 如果软件本身包含C语言等编译类代码，则需要移除`BuildArch: noarch`关键字,并且在%file阶段注意RPM宏`%{python3_sitelib}`和`%{python3_sitearch}`的区别。 + +#### 2.3.2 API和CLI定义 + +1. 创建SPEC + - CLI: `oos spec create` + + - endpoint: `/spec` + + - type: POST + + - sync OR async: async + + - request body: + ``` + { + "name"[required]: String, + "version"[optional][Default: "latest"]: String, + "arch"[optional][Default: False]: Boolean, + "check"[optional][Default: True]: Boolean, + "pyproject"[optional][Default: False]: Boolean, + } + ``` + - response body: + ``` + { + "ID": UUID, + "status": Enum("Running", "Error") + } + ``` + +2. 获取SPEC + - CLI: `oos spec show`、`oos spec list` + + - endpoint: `/spec/{UUID}`、 `/spec/` + + - type: GET + + - sync OR async: sync + + - request body: None + + - response body: + ``` + { + "ID": UUID, + "status": Enum("Running", "Error", "OK") + } + ``` + +3. 更新SPEC + - CLI: `oos spec update` + + - endpoint: `/spec/{UUID}` + + - type: POST + + - sync OR async: async + + - request body: + ``` + { + "name"[required]: String, + "version"[optional][Default: "latest"]: String, + } + ``` + + - response body: + ``` + { + "ID": UUID, + "status": Enum("Running", "Error") + } + ``` + +4. 删除SPEC + - CLI: `oos spec delete` + + - endpoint: `/spec/{UUID}` + + - type: DELETE + + - sync OR async: sync + + - request body: None + + - response body: + ``` + { + "ID": UUID, + "status": Enum("Error", "OK") + } + ``` + +### 2.4 自动化部署、测试功能 + +OpenStack的部署场景多样、部署流程复杂、部署技术门槛较高，为了解决门槛高、效率低、人力多的问题，openEuler OpenStack开发平台需要提供自动化部署、测试功能。 + +- 自动化部署 + + 提供基于openEuler的OpenStack的一键部署能力，包括支持不同架构、不同服务、不同场景的部署功能，提供基于不同环境快速发放、配置openEuler环境的能力。并提供`插件化`能力，方便用户扩展支持的部署后端和场景。 + +- 自动化测试 + + 提供基于openEuler的OpenStack的一键测试能力，包括支持不同场景的测试，提供用户自定义测试的能力，并规范测试报告，以及支持对测试结果上报和持久化的能力。 + +#### 2.4.1 自动化部署 + +自动化部署主要包括两部分：openEuler环境准备和OpenStack部署。 + +- openEuler环境准备 + + 提供快速发放openEuler环境的能力，支持的发放方式包括`创建公有云资源`和`纳管已有环境`，具体设计如下： + + ``` + **NOTE** + openEuler的OpenStack支持以RPM + systemd的方式为主，暂不支持容器方式。 + ``` + + - 创建公有云资源 + + 创建公有云资源以虚拟机支持为主（裸机在云上操作负责，生态满足度不足，暂不做支持）。采用插件化方式，提供多云支持的能力，以华为云为参考实现，优先实现。其他云的支持根据用户需求，持续推进。根据场景，支持all in one和三节点拓扑。 + 1. 创建环境 + - CLI: `oos env create` + + - endpoint: `/environment` + + - type: POST + + - sync OR async: async + + - request body: + ``` + { + "name"[required]: String, + "type"[required]: Enmu("all-in-one", "cluster"), + "release"[required]: Enmu("openEuler_Release"), + "flavor"[required]： Enmu("small", "medium", "large"), + "arch"[required]： Enmu("x86", "arm64"), + } + ``` + + - response body: + ``` + { + "ID": UUID, + "status": Enum("Running", "Error") + } + ``` + + 2. 查询环境 + - CLI: `oos env list` + + - endpoint: `/environment` + + - type: GET + + - sync OR async: async + + - request body: None + + - response body: + ``` + { + "ID": UUID, + "Provider": String, + "Name": String, + "IP": IP_ADDRESS, + "Flavor": Enmu("small", "medium", "large"), + "openEuler_release": String, + "OpenStack_release": String, + "create_time": TIME, + } + ``` + 3. 删除环境 + - CLI: `oos env delete` + + - endpoint: `/environment/{UUID}` + + - type: DELETE + + - sync OR async: sync + + - request body: None + + - response body: + ``` + { + "ID": UUID, + "status": Enum("Error", "OK") + } + ``` + + - 纳管已有环境 + + 用户还可以直接使用已有的openEuler环境进行OpenStack部署，需要把已有环境纳管到平台中。纳管后，环境与创建的项目，可以直接查询或删除。 + 1. 纳管环境 + - CLI: `oos env manage` + + - endpoint: `/environment/manage` + + - type: POST + + - sync OR async: sync + + - request body: + ``` + { + "name"[required]: String, + "ip"[required]: IP_ADDRESS, + "release"[required]: Enmu("openEuler_Release"), + "password"[required]： String, + } + ``` + + - response body: + ``` + { + "ID": UUID, + "status": Enum("Error", "OK") + } + ``` + +- OpenStack部署 + + 提供在已创建/纳管的openEuler环境上部署指定OpenStack版本的能力。 + 1. 部署OpenStack + - CLI: `oos env setup` + + - endpoint: `/environment/setup` + + - type: POST + + - sync OR async: async + + - request body: + ``` + { + "target"[required]: UUID(environment), + "release"[required]: Enmu("OpenStack_Release"), + } + ``` + + - response body: + ``` + { + "ID": UUID, + "status": Enum("Running", "Error") + } + ``` + + 2. 初始化OpenStack资源 + - CLI: `oos env init` + + - endpoint: `/environment/init` + + - type: POST + + - sync OR async: async + + - request body: + ``` + { + "target"[required]: UUID(environment), + } + ``` + + - response body: + ``` + { + "ID": UUID, + "status": Enum("Running", "Error") + } + ``` + + 3. 卸载已部署OpenStack + - CLI: `oos env clean` + + - endpoint: `/environment/clean` + + - type: POST + + - sync OR async: async + + - request body: + ``` + { + "target"[required]: UUID(environment), + } + ``` + + - response body: + ``` + { + "ID": UUID, + "status": Enum("Running", "Error") + } + ``` + +#### 自动化测试 + +环境部署成功后，SIG开发平台提供基于已部署OpenStack环境的自动化测试功能。主要包含以下几个重要内容： + +OpenStack本身提供一套完善的测试框架。包括`单元测试`和`功能测试`，其中`单元测试`在`2.3章节`中已经由RPM spec包含，spec的%check阶段可以定义每个项目的单元测试方式，一般情况下只需要添加`pytest`或`stestr`即可。`功能测试`由OpenStack Tempest服务提供，在上文所述的自动化部署`oos env init`阶段，oos会自动安装Tempest并生成默认的配置文件。 +- CLI: `oos env test` + +- endpoint: `/environment/test` + +- type: POST + +- sync OR async: async + +- request body: + ``` + { + "target"[required]: UUID(environment), + } + ``` + +- response body: + ``` + { + "ID": UUID, + "status": Enum("Running", "Error") + } + ``` + +测试执行完后，oos会输出测试报告，默认情况下，oos使用`subunit2html `工具，生成html格式的Tempest测试结果文件。 + +### 2.5 openEuler自动化开发功能 + +OpenStack涉及软件包众多，随着版本不断地演进、支持服务不断的完善，SIG维护的软件包列表会不断刷新，为了降低重复的开发动作，oos还封装了一些易用的代码开发平台自动化能力，比如基于Gitee的自动代码提交能力。功能如下： +``` + ┌───────────────────────────────────────────────────┐ + │ Code Action │ + └─────────────────────┬─────────────────────────────┘ + │ + ┌───────────────┼───────────────────┐ + │ │ │ + ┌─────▼─────┐ ┌──────▼──────┐ ┌─────────▼─────────┐ + │Repo Action│ │Branch Action│ │Pull Request Action│ + └───────────┘ └─────────────┘ └───────────────────┘ +``` + + +1. `Repo Action`提供与软件仓相关的自动化功能： + + 1. 自动建仓 + - CLI: `oos repo create` + + - endpoint: `/repo` + + - type: POST + + - sync OR async: async + + - request body: + ``` + { + "project"[required]: String, + "repo"[required]: String, + "push"[optional][Default: "False"]: Boolean, + } + ``` + + - response body: + ``` + { + "ID": UUID, + "status": Enum("Running", "Error") + } + ``` + + +2. `Branch Action`提供与软件分支相关的自动化功能： + + 1. 自动创建分支 + - CLI: `oos repo branch-create` + + - endpoint: `/repo/branch` + + - type: POST + + - sync OR async: async + + - request body: + ``` + { + "branches"[required]: { + "branch-name"[required]: String, + "branch-type"[optional][Default: "None"]: Enum("protected"), + "parent-branch"[required]: String + } + } + ``` + + - response body: + ``` + { + "ID": UUID, + "status": Enum("Running", "Error") + } + ``` + +3. `Pull Request Action`提供与代码PR相关的自动化功能： + + 1. 新增PR评论，方便用户执行类似`retest`、`/lgtm`等常规化评论。 + - CLI: `oos repo pr-comment` + + - endpoint: `/repo/pr/comment` + + - type: POST + + - sync OR async: sync + + - request body: + ``` + { + "repo"[required]: String, + "pr_number"[required]: Int, + "comment"[required]: String + } + ``` + + - response body: + ``` + { + "ID": UUID, + "status": Enum("OK", "Error") + } + ``` + + 2. 获取SIG所有PR，方便maintainer获取当前SIG的开发现状，提高评审效率。 + - CLI: `oos repo pr-fetch` + + - endpoint: `/repo/pr/fetch` + + - type: POST + + - sync OR async: async + + - request body: + ``` + { + "repo"[optional][Default: "None"]: List[String] + } + ``` + + - response body: + ``` + { + "ID": UUID, + "status": Enum("Running", "Error") + } + ``` + +## 3. 质量、安全与合规 +SIG开源软件需要符合openeEuler社区对其中软件的各种要求，并且也要符合OpenStack社区软件的出口标准。 + +### 3.1 质量与安全 + +- 软件质量（可服务性） + 1. 对应软件代码需包含单元测试，覆盖率不低于80%。 + 2. 需提供端到端功能测试，覆盖上述所有接口，以及核心的场景测试。 + 3. 基于openEuler社区CI，构建CI/CD流程，所有Pull Request要有CI保证代码质量，定期发布release版本，软件发布间隔不大于3个月。 + 4. 基于Gitee ISSUE系统处理用户发现并反馈的问题，闭环率大于80%，闭环周期不超过1周。 + +- 软件安全 + 1. 数据安全：软件全程不联网，持久存储中不包含用户敏感信息。 + 2. 网络安全：OOS在REST架构下使用http协议通信，但软件设计目标实在内网环境中使用，不建议暴露在公网IP中，如必须如此，建议增加访问IP白名单限制。 + 3. 系统安全：基于openEuler安全机制，定期发布CVE修复或安全补丁。 + 4. 应用层安全：不涉及，不提供应用级安全服务，例如密码策略、访问控制等。 + 5. 管理安全：软件提供日志生成和周期性备份机制，方便用户定期审计。 + +- 可靠性 + + 本软件面向openEuler社区OpenStack开发行为，不涉及服务上线或者商业生产落地，所有代码公开透明，不涉及私有功能及代码。因此不提供例如节点冗余、容灾备份能功能。 + +### 3.2 合规 +1. License合规 + + 本平台采用Apache2.0 License，不限制下游fork软件的闭源与商业行为，但下游软件需标注代码来源以及保留原有License。 + +2. 法务合规 + + 本平台由开源开发者共同开发维护，不涉及商业公司的秘密以及非公开代码。所有贡献者需遵守openEuler社区贡献准则，确保自身的贡献合规合法。SIG及社区本身不承担相应责任。 + + 如发现不合规的源码，SIG无需获取贡献者的允许，有权利及义务及时删除。并有权禁止不合规代码或开发者继续贡献。 + + 开发者如果有非公开代码需要贡献，则要先遵守本公司的开源流程与规定，并按照openEuler社区开源规范公开贡献代码。 + +## 4. 实施计划 + +| 时间 | 内容 | 状态| +|:-----------------:|:-----------:|:-----------:| +| 2021.06 | 完成软件整体框架编写，实现CLI Built-in机制，至少一个API可用 | Done | +| 2021.12 | 完成CLI Built-in机制的全量功能可用 | Done | +| 2022.06 | 完成质量加固，保证功能，在openEuler OpenStack社区开发流程中正式引入OOS | Done | +| 2022.12 | 不断完成OOS，保证易用性、健壮性，自动化覆盖度超过80%，降低开发人力投入 | Done | +| 2023.06 | 补齐REST框架、CI/CD流程，丰富Plugin机制，引入更多backend支持 | Working in progress | +| 2023.12 | 完成前端GUI功能 | Planning | diff --git a/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/spec/priority_vm.md b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/spec/priority_vm.md new file mode 100644 index 0000000000000000000000000000000000000000..3599799f01f21125eaaf64dce67f4ac86060ea2f --- /dev/null +++ b/docs/zh/Virtualization/VirtualizationPlatform/OpenStack/spec/priority_vm.md @@ -0,0 +1,129 @@ + +# 高低优先级虚拟机混部 + +虚拟机混合部署是指把对CPU、IO、Memory等资源有不同需求的虚拟机通过调度方式部署、迁移到同一个计算节点上，从而使得节点的资源得到充分利用。在单机的资源调度分配上，区分出高低优先级，即高优先级虚机和低优先级虚机发生资源竞争时，资源优先分配给前者，严格保障其QoS。 + +虚拟机混合部署的场景有多种，比如通过动态资源调度满足节点资源的动态调整；根据用户使用习惯动态调整节点虚拟机分布等等。而虚拟机高低优先级调度也是其中的一种实现方法。 + +在OpenStack Nova中引入虚拟机高低优先级技术，可以一定程度上满足虚拟机的混合部署要求。本文档主要针对OpenStack Nova虚拟机创建功能，介绍虚拟机高低优先级调度的设计与实现。 + +## 实现方案 + +在Nova的虚拟机创建、迁移流程中引入高低优先级概念，虚拟机对象新增高低优先级属性。高优先级虚拟机在调度的过程中，会尽可能的调度到资源充足的节点，这样的节点需要至少满足内存不超卖、高优先级虚拟机所用CPU不超卖的要求。 + +本特性的实现基于OpenStack Yoga版本，承载于openEuler 22.09创新版本中。同时引入openEuler 22.03 LTS SP1的Train版本。 + +### 总体架构 + +用户创建flavor或创建虚机时，可指定其优先级属性。但优先级属性不影响Nova现有的资源模型及节点调度策略，即Nova仍按正常流程选取计算节点及创建虚机。 + +虚机高低优先级特性主要影响虚机创建后单机层面的资源调度分配策略。高优先级虚机和低优先级虚机发生资源竞争时，资源优先分配给前者，严格保障其QoS。 + +Nova针对虚机高低优先级特性有以下改变： +1. VM对象和flavor新增高低优先级属性配置。同时结合业务场景，约束高优先级属性只能设置给绑核类型虚机，低优先级属性只能设置给非绑核类虚机。 +2. 对于具有优先级属性的虚机，需修改libvirt XML配置，让单机上的QoS管理组件（名为Skylark）感知，从而自动进行资源分配和QoS管理。 +3. 低优先级虚机的绑核范围有改变，以充分利用高优先级虚机空闲的资源。 + +### 资源模型 + +* VM对象新增可选属性`priority`，`priority`可被设置成`high`或`low`，分别表示高低优先级。 + +* flavor extra_specs新增`hw:cpu_priority`字段，标识为高低优先级虚拟机规格，值为`high`或`low`。 + +参数限制及规则： + +1. `priority=high`必须与`hw:cpu_policy=dedicated`配套使用，否则报错。 +2. `priority=low`必须与`hw:cpu_policy=shared`(默认值)配套使用，否则报错。 +3. VM对象的优先级配置和flavor的优先级配置都为可选，都不配置时代表是普通VM，都配置时以VM对象的优先级属性为准。 + +普通VM可与具有优先级属性的VM共存，因为优先级属性不影响Nova现有的资源模型及节点调度策略。当普通VM与高优先级VM发生资源竞争时，Skylark组件不会干预。当普通VM与低优先级VM发生资源竞争时，Skylark组件会优先保障普通VM的资源分配。 + +### API + +创建虚拟机API中可选参数`os:scheduler_hints.priority`可被设置成`high`或`low`，用于设置VM对象的优先级。 + +``` +POST v2/servers (v2.1默认版本) +{ + "OS-SCH-HNT:scheduler_hints": {"priority": "high"} +} +``` + +### Scheduler + +保持不变 + +### Compute + +#### 资源上报 + +保持不变 + +#### 资源分配绑定 + +高低优先级机器创建按照priority标志分配CPU： + +* 高优先级虚拟机只能是绑核类型虚机，一对一绑定`cpu_dedicated_set`中指定CPU +* 低优先级虚拟机只能是非绑核类型虚机，默认范围绑定`cpu_shared_set`中指定的CPU。 + +此外，`nova.conf`的`compute`块中新增配置项`cpu_priority_mix_enable`，默认值为False。设置为True后，低优先级虚拟机可使用高优先级的虚拟机绑定的CPU，即低优先级虚拟机可范围绑定`cpu_shared_set`与`cpu_dedicated_set`指定的CPU。 + +#### 虚拟机xml + +高低优先级机器创建按照priority标志，对虚拟机进行标识。 + +* Libvirt XML中新增属性``片段，包括 `/high_prio_machine`、`/low_prio_machine`两种值，分别表示高低优先级虚拟机。该片段本身在Nova中没有任何作用，只是为`Skylark`QoS服务指明VM的高低优先级属性。 + + +### 举例 + +假设一个compute节点拥有14个core，设置cpu_dedicated_set=0-11，一共12个核，cpu_shared_set=12-13，一共2个核心，cpu_allocation_ratio=8 则： + +1. 高优VM在scheduler视角可用core为12，compute视角可绑核core也是12，与Nova原有逻辑一致。 +2. 低优VM在scheduler视角可用core为2 \* 8 = 16，compute视角可绑核core为2(当cpu_priority_mix_enable=False)，与Nova原有逻辑一致。 +3. 低优VM在scheduler视角可用core为2 \* 8 = 16，compute视角可绑核core为2+12(当cpu_priority_mix_enable=True)，与Nova原有逻辑有差异。 + +### 参数配置建议 + +先确定全局超分比和极端超分比。 + + 全局超分比的定义：所有可分配vCPU数量（高和低总和）与所有可用物理core数量的比值，这是一个计算出来的理论值，比如上述举例中，全局超分比为 (12 + 2 \* 8) / 14 = 2。 + 全局超分比的意义：在高低优先级场景下，全局超分比主要影响低优先级虚机一般条件下（高优先级虚机vCPU没有同时冲高）的QoS。设置合理的全局超分比可以减少底层资源充足但调度失败的情况出现。 + + 极端超分比的定义：即cpu_allocation_ratio。只影响share核心的超分能力。 + 极端超分比的意义：在高低优先级场景下，极端超分比主要影响低优先级虚机极端条件下（所有高优先级虚机vCPU同时冲高）的QoS。 + +用户结合业务特征及QoS目标，选择合适的全局超分比和极端超分比后，然后按照下面的计算公式，配置合理的cpu_dedicated_set及cpu_shared_set。 + 计算公式： + + ``` + 用户期望的全局超分比 = (极端超分比 * shared核心数 + dedicated核心数) / compute所有核心数 + ``` + + 还是以上述compute节点为例，compute所有核心数为14，假设极端超分比为8，则计算可得： + + ``` + 当dedicated核心数为12时，shared核心数为2时，用户期望的全局超分 = (8*2+12)/14 = 2 + + 当dedicated核心数为4时，shared核心数为10时，用户期望的全局超分 = (8*10+4)/14 = 6 + ``` + + +## 开发节奏 + +开发者： + +* 王玺源 +* 郭雷 +* 马干林 +* 韩光宇 +* 张迎 +* 张帆 + +时间点： + +* 2022-04-01到2022-05-30 完成开发 +* 2022-06-01到2022-07-30 测试、联调、刷新代码 +* 2022-08-01到2022-08-30 完成RPM包构建 +* 2022-09-30引入openEuler 22.09 Yoga版本 +* 2022-12-30引入openEuler 22.03 LTS SP1 Train版本 diff --git a/docs/zh/Virtualization/_menu.md b/docs/zh/Virtualization/_menu.md index f9e318908042edc126f4bc9ed80877b2bd5ab41b..c68738cd8cbe479ba51d7079ec382c2080ae02b9 100644 --- a/docs/zh/Virtualization/_menu.md +++ b/docs/zh/Virtualization/_menu.md @@ -5,5 +5,5 @@ children: children: - reference: './VirtualizationPlatform/Virtualization/_menu.md' - reference: './VirtualizationPlatform/StratoVirt/_menu.md' - # - reference: 'https://gitee.com/openeuler/openstack-docs/blob/openEuler-25.03/docs/zh/_menu.md' + - reference: './VirtualizationPlatform/OpenStack/_menu.md' --- \ No newline at end of file