1.2. 应用程序架构
Microsoft Azure 上的 Red Hat Ansible Automation Platform 作为受管应用程序安装。红帽管理底层 Azure 资源以及其上运行的软件,同时基础架构在您的 Azure 租户中运行。
受管应用程序资源组与租户中的其他资源组完全分开。红帽只能访问受管应用程序资源组,对其他租户资源没有可见性。
有关如何操作以及如何将资源和访问与 Azure 资源的其余部分隔离的信息,请参阅 Microsoft Azure 受管应用程序指南中的 Azure 受管应用程序概述。
Microsoft Azure 上的 Ansible Automation Platform 使用以下资源组:
- 租户中的新或现有资源组 (RG)。此资源组包含引用 Microsoft Azure 托管应用程序部署上的 Ansible Automation Platform 的单个资源。红帽可以访问受管应用程序来执行支持、维护和升级,但资源组在红帽管理之外。
- 多租户管理资源组 (MRG),其中包含在 Microsoft Azure 上使用 Ansible Automation Platform 所需的大多数基础架构。此多租户资源组在红帽租户和您的租户之间共享。红帽拥有完全的管理控制,您有对资源组的只读访问权限。
- AKS 节点池资源组 (NPRG)。Microsoft 需要用于 AKS 部署的 NPRG。它包含 AKS 用来运行的资源。它在部署时创建,位于红帽管理之外。有关 NPRG 的更多信息,请参阅 Microsoft 的 AKS 文档。
不要与节点池资源组 (NPRG) 中的任何资源进行交互,除非 Red Hat Ansible Automation Platform on Microsoft Azure SRE 团队明确要求您这样做。对 NPRG 中的资源的更改不受红帽保护,这可能会对应用程序造成无法恢复的破坏。
红帽无法限制您在 NPRG 中更改或删除资源。
当您在 Microsoft Azure 上安装 Ansible Automation Platform 时,您可以选择部署是公共还是私有。这会影响用户如何访问 Ansible Automation Platform 用户界面。
无论您选择公共或私有部署,都必须配置网络 peer,以便从 Ansible Automation Platform 的出站通信到含有您要自动化的资源的专用网络。您可以将从 Microsoft Azure 上的 Ansible Automation Platform 的网络对等配置为私有 Azure VNets,并在内部或多云网络(使用 Azure 传输路由)中。
1.2.1. 公共部署 复制链接链接已复制到粘贴板!
公共部署允许通过公共互联网到 Microsoft Azure 用户界面中 Ansible Automation Platform 的入口流量。部署后,会向 Microsoft Azure 实例上的 Ansible Automation Platform 发出了一个域名。不需要进行配置就可以访问 Ansible Automation Platform。用户可以从公共互联网导航到域,并登录用户界面。
下图显示了在 Microsoft Azure 上公共部署 Ansible Automation Platform 的公共部署中部署到受管应用程序资源组中的应用程序资源和架构。IP 范围会根据您在部署上设置的网络地址范围而改变。
1.2.2. 私有部署 复制链接链接已复制到粘贴板!
Ansible Automation Platform 的专用部署位于隔离的 Azure VNet 中,无法访问外部来源:到公共互联网的流量和其他 Azure VNets 和子网。
要访问 Ansible Automation Platform 用户界面的 URL,您必须配置网络 peering。
配置了对等和路由后,用户可以通过连接的 Azure 子网上的虚拟机访问 Ansible Automation Platform,或者,如果您的机构已在 Azure 和本地网络间传输路由。
没有两个 Azure 网络配置是相同的。要允许用户访问 Ansible Automation Platform URL,您的机构需要与您的 Azure 管理员一起工作,以连接私有访问部署。
下图显示了在 Microsoft Azure 上部署 Ansible Automation Platform 的私有部署中部署到受管应用程序资源组中的应用程序资源和架构。IP 范围会根据您在部署上设置的网络地址范围而改变。
1.2.3. 安全性 复制链接链接已复制到粘贴板!
Microsoft Azure 上的 Ansible Automation Platform 遵循来自红帽和 Microsoft 的安全最佳实践。以下资源描述了应用和基础架构的安全形象。
flight 和 rest 中的数据加密
- 所有 Azure Storage Services 使用服务管理的密钥默认启用服务器端加密
- 所有 Azure 托管的服务都承诺通过 Rest 选项提供加密
- Azure 加密概述
- AKS 内服务间的所有通信(如 Ansible Automation Platform、Postgres、存储帐户)都使用 TLS v1.2 或更高版本。
- Azure Kubernetes Service (AKS)的 Azure 安全基准
密码存储
- 客户提供的 Ansible Automation Platform admin 密码在传输中加密。它可以被 kubernetes API 的 SREs 访问,并可在客户请求时被 SREs 重置。
使用行业标准生成的键
密钥安装,轮转
SSL/TLS 流量加密
- AKS 内服务间的所有通信(如 Ansible Automation Platform、Postgres、存储帐户)都使用 TLS v1.2 或更高版本。
- 所有与 Ansible Automation Platform UI 的通信(通过应用程序网关用于公共部署)或 nginx ingress 用于私有部署,都使用 TLS v1.2 或更高版本。
API 安全性
- Ansible Automation Platform API 的任何部分都可能会泄漏任何敏感信息,它们只能通过已知 Ansible Automation Platform 用户进行身份验证,并要求该用户具有正确级别的授权才能使用这些 API。在私有部署中,客户只能通过选择连接到私有部署的路由访问 Ansible Automation Platform API。
- Kubernetes API 是私有的,只能从私有端点访问
- 启用工作负载身份,它允许 Kubernetes 应用程序通过 Microsoft Entra ID 安全地访问 Azure 云资源。
更新和补丁
- Red Hat SREs 定期将 Kubernetes 版本、底层节点操作系统和 Ansible Automation Platform 版本更新至最新可用的稳定版本,以获取最新的功能、程序错误修正和安全修复。