Azure-Arc-Kubernetes-和服务器教程-全-
Azure Arc Kubernetes 和服务器教程（全）
一、作为 Azure 控制平面的扩展的 Azure Arc
欢迎阅读本 Azure Arc 支持的 Kubernetes 和服务器书的第一章。总的来说，这本书将带你进入支持 Azure Arc 的 Kubernetes 和支持 Azure Arc 的服务器的世界。Azure Arc 有许多产品，我们希望在本书中重点介绍 Azure Arc 的 Kubernetes 和服务器产品，以便在两个重点主题上为您提供最大的价值。
在我们深入 Azure Arc 产品本身之前，理解 Azure Arc 如何适合作为 Azure 控制平面的扩展是很重要的。这就是我们在本章要探讨的内容。这将有助于建立本书剩余章节的基础知识。
混合、多云和边缘
混合云、多云和边缘云计算都是快速增长的领域。让我们简要地定义一下它们是什么:
混合云
混合云将内部数据中心(私有云)与公共云相结合，为组织创建单一的云环境。混合云为您提供公共云和内部部署(也称为私有云)之间的工作负载可移植性。混合云允许企业根据需要为每个工作负载选择最佳计算位置。
多层
多云是指企业结合使用来自不同云提供商的两个或更多公共云。多云不是由单个云提供商提供的。多云通常是几个或更多主要云提供商的组合:亚马逊网络服务(Amazon Web Services)、谷歌云平台(Google Cloud Platform)、微软(Microsoft)、阿里巴巴(Alibaba)和 IBM。
边缘云计算
边缘云计算是将云服务、计算和数据存储扩展到数据源或其附近。边缘云计算节省带宽，非常适合有延迟问题的工作负载。物联网和数据密集型工作负载是边缘云计算的常见用例。
查看这些领域的一些统计数据以了解增长情况非常重要。每年发布的一个重要资源是《Flexera 云状态报告》。这份报告对所有与云相关的内容进行了细分，并给出了一些关于企业在云领域所发生的事情的硬性统计数据。让我们来看看 Flexera 2021 年云状态报告中的一些统计数据。
-
企业正在采用混合云
87%对 Flexera 2021 云状态报告做出回应的企业报告采用了混合云战略。
-
企业正在拥抱多云
93%对《Flexera 2021 年云状态报告》做出回应的企业表示拥有多云战略。他们还报告说，在他们的战略中结合了公共云和私有云。
-
企业正在拥抱边缘云计算
49%对 Flexera 2021 云状态报告做出回应的企业正在试验或计划使用边缘服务。
综上所述，大多数企业都采用混合云作为他们的云模型，其中包括多云。下图来自 Flexera 2021 年云状态报告，显示了这一点。
图 1-1
Flexera 2021 年云状态报告中使用的云类型图表
这证明了云计算的增长是在混合、多云和边缘云计算领域。
Azure Arc 概述
正如我们在上一节中看到的，在当今的技术世界中，对混合云、多云和边缘云计算的需求日益增长。随着工作负载在混合云、多云和边缘云计算环境中运行，管理它们的复杂性也在增加。
2019 年，在微软的大型技术大会上，微软 Ignite 公布了 Azure Arc。Azure Arc 将 Azure 功能扩展到 Azure 之外的环境，如内部数据中心和其他私有云和公共云。Azure Arc 通过将 Azure Resource Manager (ARM)及其管理工具带到各种环境中来简化复杂的分布式环境，而不管它们在什么云上。Azure Arc 为技术团队提供了部署工作负载和管理资源的能力，无论它们位于何处。
Arc 是对企业内部和多云管理需求日益增加的复杂性的回应。Azure Arc 使您能够在上创建和管理资源以及工作负载
-
内部
-
非 Azure 云(即 GCP、AWS、阿里巴巴等。)
-
私有云
-
微软混合(Azure Stack Hub、Azure Stack HCI、Azure Stack Edge)
Arc all up 由多种产品组成，有助于满足组织的各种多环境需求。以下是 Azure Arc 提供价值的三个关键领域:
一致性
Arc 为您提供一致的资源和工作负载治理、库存和管理。
零接触合规性和配置
借助 Arc，您可以获得跨资源和工作负载(如服务器、Kubernetes 等)的零接触合规性和配置。
统一体验
Azure Arc 为您提供了跨环境和资源/工作负载的单一面板和单一控制平面的统一体验。通过 Azure 门户、Azure CLI、Azure PowerShell 或 Azure REST API 的管理，无论工作负载和资源在哪里运行，都使用相同的工具。
现在，Azure Arc 将 Azure 服务扩展到运行在 Azure 之外的资源和工作负载。基于 Azure Arc 产品，扩展的服务会有所不同。这里列出了许多可以通过 Azure Arc 扩展的 Azure 服务:
-
管理组
-
捐款
-
资源组
-
基于角色的访问控制
-
磨尖
-
安全中心/Azure Defender
-
蔚蓝哨兵报
-
Azure 密钥库
-
Azure 策略/Azure 策略来宾配置
-
Azure 备份
-
更新管理、变更跟踪和清单
-
Azure 监视器
-
Azure 自动化
-
在 Azure 门户中查看和访问
-
Azure SDK
-
ARM 模板
-
更多
目前，在管理支持 Azure Arc 的服务器和支持 Azure Arc 的 Kubernetes 时，Azure Arc 是免费提供的。Azure Arc 控制面板功能免费提供。被视为 Azure Arc 控制平面一部分的服务有
-
将服务器和 Kubernetes 集群附加到 Azure
-
通过 Azure 管理组和标记进行资源组织
-
通过资源图进行搜索和索引
-
通过 Azure RBAC 和 Azure 订阅的访问和安全性
-
通过修补程序管理进行补丁管理
-
通过 ARM 模板和 Azure 扩展的环境和自动化
Azure Arc 产品
当 Azure Arc 推出时，它提供了一些产品，第一个是支持 Azure Arc 的服务器。自发布以来，微软一直在快速向 Arc 添加额外的产品，并扩展当前产品的功能。Azure Arc 产品分为两类。基础设施是您运行工作负载的基础设施。服务是通过 Arc 从 Azure 扩展出来的 Azure 服务。第一类是基础设施，第二类是服务。Azure Arc 产品及其能够管理的资源类型包括:
基础设施
-
服务器:支持 Linux 和 Windows，支持裸机服务器、本地服务器、AWS EC2 虚拟机、GCP 计算机引擎虚拟机、VMWare 虚拟机和 Hyper-V 虚拟机
-
支持 Azure Arc 的 SQL Server: 从 Azure 管理 SQL Server 的实例，将 Azure 服务扩展到 Azure 外部托管的 SQL Server 实例
-
Kubernetes: 内部 Kubernetes 集群、Rancher K3s、AWS EKS 集群、GCP GKE 集群
-
Azure Arc 物联网:通过支持 Azure Arc 的 Kubernetes，在边缘集中管理和部署物联网工作负载
服务
图 1-2
Azure Arc 产品
-
数据服务:在 Azure 之外运行 Azure 数据服务，包括 SQL 托管实例和 PostgreSQL。
-
Azure Arc with light house:Azure Arc 和 Azure Lighthouse 的组合，用于将灯塔管理功能扩展到非 Azure 环境。
-
带有 Azure Arc 的 Azure 应用服务: Azure 应用 PaaS 服务(App service，Functions，Logic Apps，Event Grid，API Management)和其他 PaaS 服务可以通过 Arc 在任何 Kubernetes 集群上运行。
我为什么要为我的组织使用 Azure Arc？
多云架构通常更加复杂，管理起来也更加困难。根据 Flexera 2021 年云状态报告，68%的受访企业目前没有使用多云管理工具。只有 32%的企业在利用多云管理工具。该报告还涵盖了多云治理、安全性和成本管理工具统计数据。这些其他领域的比例也很低。这意味着多云管理工具有巨大的增长机会。微软开始用 Azure Arc 来填补这一空白。
用例
以下是一些对使用 Azure Arc 有意义的用例:
法定管辖权
法律要求某些工作负载在特定地区、国家等地处理和保留数据。，需要跨多个数据中心和云提供商的基础架构。
等待时间
一些工作负载具有延迟要求，必须通过将工作负载定位在特定地理位置来满足这些要求。
传统基础设施
一些传统基础设施陈旧且具有挑战性，有时无法迁移到云中。Arc 可以将云扩展到本地传统基础设施。
可用性
能够跨多个云提供商甚至内部运行相同的服务，以便在云提供商或内部停机时实现更高的可用性。
开发者选项
能够让开发人员选择在最适合他们需求的环境中运行工作负载。
边缘计算需求(本地)
随着组织不断扩大其优势和本地工作负载运行范围，如商店、仓库、工厂、现场等。，扩展云和集中化管理可以降低跨边缘位置管理的复杂性。
混合云场景
当提到利用 Azure Arc 时，组织有许多场景。让我们来看一下其中的一个场景。在本例中，该组织正在运行一个基于容器的 web 应用，该应用的组件分布在 Azure 云和他们的内部数据中心。
在这个特定场景中，组织需要为将从内部使用 web 应用的用户提供低延迟，并且他们希望公共流量进入 web 应用；作为云运行在 Azure 上可以更好地处理外部流量负载。
该组织利用 Azure Arc 来管理内部 Kubernetes 集群和基于云的 Azure Kubernetes 服务(AKS)集群。他们还利用 GitOps 来确保内部 Kubernetes 集群和基于云的 AKS 集群配置和应用部署始终匹配。此外，他们还利用 Azure Container Instance (ACI)在 AKS 集群上按需提供非常快速的突发容量。下图显示了这个基于混合的应用的架构。
图 1-3
在混合云模式下运行的基于容器的 web 应用
摘要
这使我们结束了第一章。在本章中，我们花时间了解了混合、多云和边缘区域，以及管理它们所带来的挑战。我们对 Azure Arc 进行了概述。我们深入 Azure Arc 的产品，让大家了解 Azure Arc 是由什么组成的。我们最后探究了为什么您的组织可能会采用 Azure Arc。这一切都是为了给你一个 Azure Arc 知识的坚实基础，以帮助你进一步开始本书的剩余章节，更深入地进入混合、多云、edge 和 Azure Arc 的世界。
二、Azure 资源管理器洞察
介绍
在这一部分，我们将研究微软 Azure 中的 Azure 资源管理器或“ARM”平台管理层。我们将讨论它是什么，它是如何工作的，你可以用它做什么，以及如何在你的 Azure ARC 部署和 Azure 中的其他实现项目中有效使用它的技巧和诀窍。
什么是 Azure 资源管理器？
ARM 的核心是 Azure 的部署和管理服务。它允许创建、配置和管理资源，如虚拟机或虚拟网络，以及平台即服务或“PaaS”，如 Azure App Service、ARC 和 Azure SQL 等产品。
在 Azure 的初期，一个被称为 Azure 服务管理器或“ASM”的管理和结构系统被实现来管理平台。这个不成熟的系统很快暴露了它在治理、安全控制、资源组织、结构和环境管理方面的局限性。
ASM 最终被称为 Azure 资源管理器或“ARM”的更灵活、更强大的管理层所取代。然而，ASM 仍然存在于 Azure 环境中，基于 ASM 的资源被称为“经典”
ARM 管理层本质上执行一些任务，如创建资源并使用身份和访问控制(IAM)来管理它们，使用标记进行组织和分组，或者添加锁来防止未经授权的更改。
把 ARM 想象成你和 Azure 之间的解释器。你告诉它你想做什么，它就知道怎么做。
ARM 使你能够在 Azure 平台内部执行许多任务。它允许通过声明方式而不是静态脚本或其他动作来管理基础设施。这意味着您可以作为一个组来部署、管理、配置和监控资源，而不是试图单独管理它们。例如，您可以将定义的访问控制设计应用于一组资源，而不必单独配置每个资源，从而节省时间并减少潜在的人为错误。
这种方法不仅允许对资源范围进行更简单的管理，还允许您轻松地将同一组资源重新部署为另一个单独部署的一部分。当您需要使用生命周期方法为解决方案部署资源时，这非常方便，在生命周期方法中，您可能首先从开发环境开始，然后在最终进入生产环境之前转移到测试或 QA 环境。
在决定你的 Azure 部署策略时，你需要考虑很多不同的因素。
首先，一旦你开始走上一条路，有时很难改变方向。例如，如果您决定使用 PowerShell 脚本部署资源，但后来又决定改用其他部署方法，如 Terraform，那么这种改变可能会非常困难，并且可能需要付出大量的努力。花些时间回顾这些选择，并决定最适合你的道路。
考虑技术投资。走这条路你需要买什么？您需要构建和托管服务器吗？您需要购买软件许可吗？您是否需要第三方服务？你需要培训你的团队吗？成本是什么，价值是什么？
此外，组织未来的云采用计划是什么？Azure 的计划是什么？你有路线图可循吗？有哪些外部环境可能会推动 Azure 的采用或消费？公司是否需要在近期规划一个数据中心出口或关闭一个关键位置？
你的员工也是你项目成功的关键。您的团队中谁拥有使用工具、服务或应用所需的知识？是否存在技能差距？你将如何关闭它？将来，您将如何管理知识文档并将其转移给新的或初级的资源？
请记住，您在这里的选择不仅会影响使用 ARM 部署基础架构资源的团队，还会潜在地影响您的应用开发或数据和分析团队在将解决方案部署到 Azure 环境时的工作方式。一定要让每个人都尽早参与进来，这样每个观点都会得到考虑，并做出最佳选择。
这些都是关键领域，在规划你的路线之前，需要整个组织的思考、讨论和集体决策。
其次，预先计划好你真正想用 Azure 做什么是成功的关键。在你至少定义了基本需求、资源列表和路线图之前，你不应该在 Azure 中构建任何东西。
你会把 Azure 只用于网络应用，还是只用于数据分析？你会将数据中心扩展到环境中，并使用 Azure 来操作和管理整个组织的核心基础设施吗？
每一个不同的场景都会让你走上一条不同的道路，并且需要非常不同的资源来完成。
理解手臂
ARM 采用标准层次结构，具有五个级别的作用域，每一级都继承上一级的设置。
图 2-1
Azure 管理范围
层次结构的顶端是 Azure 租户。这通常也称为“注册”或“目录”从我们组织讨论的角度来看，名字其实并不重要。它只是层次结构的最高级别。
通常用于结构、管理、策略或其他更广泛的管理的第一个范围级别是管理组。该层级通常包含订阅，但在不同地理政治区域(如北美与欧洲或亚太地区)可能有不同策略的情况下，也可以有多层管理组。
设置可以应用于层次结构中的任何级别，但是用于治理和/或安全性的访问控制、权限和策略通常会在管理组中创建，以便它们由订阅和结构中低于它们的所有内容继承。
图 2-2
Azure 层次结构
这种具有继承性的分层方法支持在多个级别上配置和管理 Azure 环境，持续的限制性策略从全局或公司范围的配置向下移动到应用于非常特定的资源集的高度特定的策略集。
Key Definitions
租户/目录/注册:这是 Azure 的顶层组织。它将组织作为一个整体来表示，所有其他结构(如管理组和订阅)都属于租户。
管理组:位于结构顶部的组织对象，包含订阅和层次结构中低于订阅的所有内容。
订阅:Azure 中的一个逻辑构造，包含资源组，代表许多不同方面或管理和组织的边界。
Policy:Azure 中的一个构造，它允许创建需求规范，这些规范可以审计正确的配置，防止错误配置，或者改变资源的配置。
Geography :代表不同的地理区域，可能有不同的主权要求/政策，例如欧洲。
在设计组织结构时，需要考虑管理团队的一些限制。
表 2-1
管理组限制
|资源
|
限制
|
| --- | --- |
| 每个租户的管理组 | Ten thousand |
| 每毫克订阅量 | 无限的 |
| 等级制度的层次 | 根+6 级 |
| 直接母公司管理组 | 一个 |
| 每个地点的 MG 级部署 | eight hundred |
| MG 级部署的位置 | Ten |
关于管理组限制，要考虑的重要事项是层级限制和最大部署位置。
如果您正在为一家在多个国家运营的国际组织开始大规模 Azure 云转型之旅，则应该考虑这些限制，并将其纳入您的管理团队设计中:
-
你将需要十个以上 Azure 区域的资源。
-
您需要根据地理政治区域、业务单位和责任划分等因素来隔离不同的订阅。
-
您需要减少延迟的区域部署来满足业务需求。
在管理组级别下面，您会发现 Azure 订阅。
订阅级别包含资源组，通常是职责开始分离和收缩的范围。
虽然通常会对管理组实施广泛的 RBAC 控制，但经常需要允许对一个订阅和另一个订阅进行不同级别的访问。例如，如果您的组织使用生产和非生产订阅模式。生产中的权限可能需要比非生产中的权限更加严格。
Key Definitions
订阅:Azure 中的一个逻辑构造，包含资源组，代表许多不同方面或管理和组织的边界。
资源组:保存资源的容器对象。通常，这些资源作为应用或解决方案的一部分彼此相关，或者是类似的资源，如路由表或虚拟网络，它们可以组合在一起，通过基于角色的访问控制或 RBAC 进行管理。
RBAC :指基于角色的访问控制，这是 ARM 的一个特性，允许向用户或用户组分配预定义或自定义的角色。
Location : Azure Locations 代表 Azure geography 中部署资源的整体区域，例如“EastUS2”、“SouthCentralUS”和“WestUS”。
标签:标签用于将 Azure 资源组织成一个逻辑分类。标签由一个键/值对组成，这意味着有一个“键”和一个“值”。例如，您可能有一个标签，其键名为“Environment”，值名为“Prod”。
订阅经常被用作一个管理边界，在这里用户可以被授权访问订阅中的每个资源。在较小的程度上，它被用作规模的逻辑单位，通过它可以在每个 Azure 区域的基础上限制特定类型的 Azure 资源的数量。
以下是使用订阅级别管理边界的两个示例:
-
向高级管理员授予订阅的所有者级别权限，以便此人可以管理访问控制。
-
将“网络贡献者”角色授予组织中的网络管理员，以便他们可以访问各种网络资源和工具来测试性能和排除故障。
与管理组和订阅一样，在设计订阅策略时，需要考虑一些与 ARM 框架相关的限制。
表 2-2
订阅限制
|资源
|
限制
|
| --- | --- |
| 每个租户的订阅量 | 无限的 |
| 每个订阅的联合管理员 | 无限的 |
| 每个订阅的资源组 | Nine hundred and eighty |
| ARM API 请求大小 | 4，194，304 字节 |
| 每个订阅的标签 | Fifty |
| 每个订阅的唯一标签计算 | Eighty thousand |
| 每个位置的订购级部署 | eight hundred |
| 订阅级别部署的位置 | Ten |
这里要考虑的最重要的事项是每个订阅的资源组数量和每个订阅的位置。如果您的资源组策略将需要大量的 rg，请考虑将它们跨多个订阅，如果您正在计划多区域部署，请计划每个订阅 10 个位置的限制。在某些情况下，使用嵌套模板跨多个位置进行部署可能会超出位置限制。
资源组或“RG”级别用于进一步细化权限，并开始组织内的职责分离。例如，如果您将所有网络资源放在一个“网络”资源组中，您可以将订阅的读者访问权限授予您的网络团队，但将贡献者访问权限授予该网络 RG。
在设计和实现资源组结构时，有许多事情需要记住。这项任务初看起来可能很简单，但是随着环境复杂性的增加，它将变得越来越令人望而生畏。
资源组中的资源应该共享生命周期，并且应该一起部署、更新和最终删除。例如，创建包含虚拟网络、虚拟网络网关、VPN 连接和路由表的“网络资源组”。这些资源在逻辑上被组合在一起，可能具有相同的 RBAC 结构，并且应该在组织内保持相同的生命周期。
资源只能存在于单个资源组中，不能属于多个组，因此 RBAC 结构应该考虑资源组的内容以及相应设计的配置。
大多数资源可以随时移动到不同的 RG。随着环境复杂性的增加，当有必要重新组织层次结构时，这通常是有帮助的。
更改资源组时，每个资源有不同的限制。在尝试移动之前，请确保阅读了有关更改资源上的资源组的文档。
资源可以位于不同 Azure 区域的资源组中，但建议将资源与 RG 保持在同一区域，因为如果 RG 位于故障区域，一个区域中的任何控制平面问题都可能影响另一个区域中的资源。这限制了单个区域故障的潜在影响。
此外，资源组为其中包含的资源提供必要的元数据。如果元数据变得不可用，资源可能会失败。
资源组是一种逻辑结构，用于对用户进行组织和访问控制，而不是限制对其他资源的访问。
资源组不充当资源之间的屏障！一个资源组中的资源可以自由地与另一个资源组中的资源交互。
标签可以应用于资源组，但是资源不会自动继承标签；然而，Azure Policy 或 PowerShell 可以在这方面提供帮助。
可以应用开箱即用或“OOB”策略，该策略可以将缺失的标签从资源组复制到该组中的资源。这极大地简化了确保所需标签出现在资源上的过程。
删除资源组将删除该组中的所有资源。删除 RG 时要小心！三重检查每个资源都可以被删除而没有影响。
关于资源组和层次结构中的其他级别，需要记住一些其他限制。
表 2-3
资源组限制
|项目
|
限制
|
| --- | --- |
| 每个 RG 的资源 | 资源受资源组内资源类型的限制 |
| 每类资源 | 每个 RG 有 800 个资源类型实例 |
| 历史上每个 RG 的部署 | eight hundred |
| 每次部署的资源 | eight hundred |
| 每个作用域的管理锁 | Twenty |
| 每个资源或 RG 的标签数量 | Fifty |
| 标签密钥长度 | Five hundred and twelve |
| 标签值长度 | Two hundred and fifty-six |
对于资源组限制，设计中要考虑的主要问题是历史上每个资源组中相似资源的数量和每个 RG 的部署。如果您正在部署资源的多个迭代，如订阅中的存储帐户，或者它是一个特别动态的环境，您预计将超过 800 个部署历史限制，您需要考虑减轻这些限制的方法。
可以通过多种方式创建资源组，包括 Azure 门户、Azure CLI、PowerShell 和 ARM 或其他部署模板。
除了 ARM 中的层次限制之外，在您的环境的整体实施策略中，还应该考虑一些部署模板的限制。
表 2-4
ARM 模板限制
|价值
|
限制
|
| --- | --- |
| 因素 | Two hundred and fifty-six |
| 变量 | Two hundred and fifty-six |
| 资源(包括副本数量) | eight hundred |
| 输出 | Sixty-four |
| 模板表达式 | 24，576 个字符 |
| 导出模板中的资源 | Two hundred |
| 模板尺寸 | 4 MB |
| 参数文件大小 | 4 MB |
Key Definitions
Azure Resource Manager (ARM)模板:通常被称为“ARM 模板”，这是一种 JavaScript 对象符号，或 JSON 格式的文件，用于通过 ARM 部署资源。这个文件是以声明性语法结构编写的，这意味着您是在声明您想要创建的对象，而不是必须编写大量的代码序列来创建对象。
当通过 ARM 或任何其他方式部署资源时，在 ARM 执行请求之前，总是需要两条信息。您必须为资源提供一个资源组和一个将部署资源的 Azure 位置。
我们已经深入讨论了资源组，所以让我们从地理角度来谈谈 ARM 的组织。
从地理角度来说，Azure 中的资源有两种交付方式。它们要么是“非区域性服务”，这意味着它们不位于特定的数据中心，服务基本上来自任何地方，要么它们是从特定的 Azure 区域交付的，要使用该服务，您必须使用该服务可用的区域。
Azure 区域是一组位置非常接近的 Azure 数据中心。Azure 区域内的资源通常会有 1-2 毫秒的跨区域延迟。每个区域都连接到 Azure edge 网络，区域之间至少有 5 毫秒的延迟，但这取决于源和目的地。如果你在美国东部和悉尼之间移动数据，这个数字会高得多。
图 2-3
蓝色区域资源
Key Definitions
Azure Region :部署在延迟定义的地理区域内的数据中心集合，通过高带宽、低延迟的网络连接进行连接。
在每个 Azure 区域中，有两个或更多的数据中心或“可用性区域”
这些可用性区域代表一个区域内完全独立的 Azure 数据中心，拥有自己的电力、冷却和互联网连接。
如果某个地区的任何一个数据中心出现故障，该数据中心的工作负载将转移到其他两个数据中心，前提是您的地区战略设计中已经考虑到了这一点。
Azure 平台提供多种类别的服务。
基础服务:一个核心的 Azure 服务，在所有 Azure 区域都可用。这将是虚拟网络、虚拟机和存储帐户等基本服务。
主流服务:Azure 服务，在推荐地区可用，但在其他地区可能不支持。
专业服务:非常具体的服务，由需求驱动，通常需要专业的硬件来交付。Azure 上的 SAP HANA 大型实例是专业化服务的一个很好的例子，因为它需要 Azure 数据中心中的专用服务器，这些服务器可以支持所需的特殊操作系统以及 HANA 数据库。
当考虑您的区域策略时，验证您想要在 Azure 中使用的所有服务在您选择的区域中都可用是非常重要的。
虽然某一特定类型的资源可能在某一特定地区可用，但这并不意味着它在所有地区都可用。根据您期望使用的资源来规划您的区域！
您可以在网站上按地区查看 Azure 产品的可用性
https://azure.microsoft.com/en-us/global-infrastructure/services/
除了选择主要区域之外，还应该为灾难恢复和跨区域操作确定一个辅助区域。微软将特定的 Azure 区域与通常相距超过 300 英里的类似服务配对，并在它们之间不断复制。
这可以保护工作负载免受自然灾害、停电或连接问题的潜在影响，这些问题可能会导致某个区域离线。
利用配对区域使您能够更快地克服主区域内的灾难或环境内的灾难。
虽然您必须从一个地区到另一个地区复制计算工作负载，但地理冗余存储或“GRS”和具有地理复制功能的 Azure SQL 会在配对的地区之间自动复制，管理服务如 ARM 资源元数据、IAM 和活动日志也会自动复制。
此外，平台更新在成对的区域中按顺序安排，以防止两个区域都受到更新窗口或更新问题的影响。
图 2-4
蓝色成对区域
微软使用“爆炸半径”方法为应用弹性的设计建议提供信息。
这实际上意味着，您需要根据爆炸半径和对运营的潜在影响来设计您的应用的弹性。
Key Definitions
爆炸半径:这代表一个事件对你周围环境的影响。这可以在许多层面上表现出来:
-
失去资源:由于硬件故障而离线的服务器。
-
资源收集丢失:这可能表示数据中心中的一个机架由于配电故障而离线。
-
数据中心区域丢失:这表示 Azure 数据中心区域丢失，导致存储、网络或计算实例等服务出现重大故障。
-
区域丢失:这表示某个地理区域发生了灾难性故障，迫使 Azure 区域中的所有数据中心离线。这可能是飓风或地震等自然灾害、电网灾难性故障或其他重大事件。
Azure Region:Azure 数据中心的集合，这些数据中心非常接近，具有低延迟连接以及独立的电源、冷却和互联网连接。
可用性区域:标识 Azure 区域的特定子集，该子集允许资源的分布，并且能够防止单个 Azure 数据中心的丢失。
弹性:应用根据服务级别协议(SLA)适应或调整故障并继续运行和交付服务的能力
在考虑如何以及在哪里使用 ARM 部署资源时，您需要考虑如何为您的部署规划弹性。
对于任何工作负载，您应该问的第一个问题是，“我需要此部署的弹性吗？”通常，非生产工作负载不需要高可用性或灾难恢复，但对生产系统会有不同的要求。
如果您确实需要工作负载的弹性，那么您的下一个问题是，“需要多少？”这通常由您的应用的服务级别协议来回答。如果您有一个业务关键型应用，它可能具有非常高的 SLA，例如 99.99%的正常运行时间，每次事件的停机时间不超过 2 小时，数据丢失时间不超过 1 小时。
图 2-5
天蓝色爆炸半径
一旦确定了需求，就可以基于爆炸半径方法构建应用。一旦确定了方法，就可以使用 ARM 将工作负载部署到 Azure。
武器发展和管理
在我们深入使用 ARM 之前，让我们快速讨论一下微软是如何持续维护和更新 Azure 的。
Azure 是一个不断经历转型的平台(有时每周一次)，因此，由于 Azure 基础设施在整个地区或平台上的更新，每个 Azure 资源的特性或行为每天都可能不同或功能不同，因此经常会非常混乱。
这种看似混乱的服务模式初看起来可能如此，但在幕后，服务更改、更新和功能扩展都经过了多个客户的严格审查和测试，这些客户愿意投入时间来测试和审查这些更改/更新，并与微软合作完善它们以实现全面可用性(GA)。
Azure 服务和功能在正式发布之前，会在一个包含来自 MSTeam、客户和合作伙伴的反馈和改进的周期中发布。
图 2-6
Azure 开发生命周期阶段
在开发阶段，只有 Microsoft 资源参与开发特定服务的特性和功能。一旦微软确定他们已经为下一阶段做好准备，他们将邀请表示有兴趣或请求访问该服务的客户来开发围绕该产品的解决方案。这被称为“私人预览”
一旦服务已经过测试和更新，并且已经达到可以在正常使用下开始运行的状态，这个阶段就变成了“公共预览”在此阶段，任何选择实施该服务的客户都可以使用该服务，但是该服务存在一些限制，例如降低或取消服务级别协议和“尽力而为”支持，并且某些功能可能不可用或不可配置。
一旦产品管理团队认为该服务已经过全面审查并准备好投入运营，它将被视为“普遍可用”或简单的“正式发布”
强烈建议您不要使用未正式发布的服务来部署生产工作负载。功能、特性、功能和部署模型在预览版和正式发布版之间都会发生变化。在部署利用某项服务的生产工作负载之前，请始终等待该服务在您所在的地区普遍可用。
一旦产品普遍可用，所有 Azure SLAs 和支持保证都适用，服务可以在生产中实现。
您可以通过访问 Azure Products by Region 网站来查看任何地区的任何 Azure 服务的状态和可用性:
https://status.azure.com/en-us/status
图 2-7
Azure 状态网站
使用 Azure 资源管理器
让我们来看看您可以与 ARM 交互的一些机制，它们是如何工作的，以及在通过 ARM 部署工作负载时应该遵循哪些建议和最佳实践。
ARM 比以前的 ASM 系统灵活得多，有多种方式可以与之交互。您可以简单地登录 Azure web 门户并使用基于 web 的图形界面，可以使用 PowerShell 或 Azure CLI 等命令行工具，甚至可以通过 REST 或第三方系统(如 HashiCorp 的 Terraform)或其他部署工具(如 Chef 或 Octopus)通过 Azure API 直接连接。
Azure 门户和 Azure API 直接与 ARM 接口，而 PowerShell 和 Azure CLI 与 Azure SDK 交互，后者管理翻译并移交给 ARM 进行请求处理。
一旦请求直接或通过 SDK 提交给 ARM，ARM 将验证发出请求的用户或服务主体的身份，并通过 RBAC 验证权限，如果流程获得授权，则执行该流程。
图 2-8
Azure 资源管理器操作
这个过程将“创建虚拟机”这样简单的事情变成了构建 Azure 数据中心所需的所有复杂命令和子命令，如分配存储、创建网络接口、锁定处理器/RAM 资源、将它们连接在一起，以及配置它们以基于您的请求返回功能虚拟机。
ARM via Azure 门户
与 ARM 最常见也是最不成熟的交互是通过 Azure 门户。使用 Azure portal 可能会出现大量人为错误，以及由于人为错误和配置选项验证有限或没有验证而导致的应用或解决方案的架构故障。
Azure 门户由四个主要区域组成，它们将始终用于与 ARM 平台进行交互，以创建、修改或管理资源。
图 2-9
蔚蓝门户
-
主导航:这个区域包含最常用的 Azure 资源和对象的快速链接。菜单是可定制的，可以添加、删除或重新组织项目以满足用户的需求。
-
搜索框:搜索框是一个非常有用的工具，可以快速找到特定的资源类型或资源。
-
实用程序菜单:实用程序菜单包含常用门户实用程序的快捷方式，例如用于通过门户执行 Azure CLI 命令的 Azure Cloud Shell，以及用于更改门户主题或布局的设置选项。
-
交互面板:这是门户的主要交互区域。这是可以在门户中查看或修改资源的地方。
Azure 门户中与资源的大部分交互将发生在交互窗格中。一旦选择了资源类型，基于任何适当的筛选器的所有资源都将显示在窗格中。
图 2-10
门户交互窗格 1
从这个视图中，您可以创建一个当前类型的新资源；您可以通过添加、删除或重新排序列来修改视图。还可以对视图应用多种不同类型的筛选器，并且可以将视图导出为逗号分隔值文件，以便在应用(如 Microsoft Excel)中查看和操作。
此外，您可以创建 Microsoft Graph 查询来获取基于图形查询结构的附加信息，并且可以创建标记并将其分配给资源。
如果您选择了单个资源，视图将会发生变化以显示该资源的特定详细信息。在这里，您可以管理资源并执行大多数配置任务。
您可以为资源分配 RBAC 角色，查看活动或诊断日志，或者修改资源的配置选项。
图 2-11
门户交互窗格 2
通过命令行启动
Azure Cloud Shell 是一个基于浏览器的交互式命令行工具，用于管理资源。Cloud Shell 可以使用 PowerShell 风格的 CLI 呈现，也可以使用 BASH 来处理命令。
可以通过两种方式访问云外壳:
-
直接链接:打开浏览器，导航至
https://shell.azure.com -
Azure portal: Select the Cloud Shell icon in the Azure portal Utility Menu.
图 2-12
天蓝色的云壳
Azure 云壳可以处理多种语言来执行命令。
PowerShell 经常在云 Shell 中用来执行特定的命令或脚本。在清单 2-1 中，执行了一个 PowerShell 命令来显示特定资源组中的所有网络安全组。
代码片段 1。Get-AzResource
Get-AzResource -ResourceType "Microsoft.Network/NetworkSecurityGroups" -ResourceGroupName "nsg-rg-msdn-ent"
这将返回以下信息。
Name : app-nsg-msdn-ent
ResourceGroupName : nsg-rg-msdn-ent
ResourceType : Microsoft.Network/networkSecurityGroups
Location : eastus2
ResourceId : /subscriptions/c7abfg3-c4c1-436f-b9a7-d5230a145a6b/resourceGroups/nsg-rg-msdn-ent/providers/Microsoft.Network/networkSecurityGroups/app-nsg-msdn-ent
Tags :
Listing 2-1PowerShell Command in Cloud Shell
除了 PowerShell，在云壳中也可以使用 Azure CLI。在清单 2-2 的示例中，已经执行了一个 Azure CLI 命令来显示特定资源组中的所有网络安全组。
代码片段 2。Az 资源列表
az resource list -g nsg-rg-msdn-ent --resource-type "Microsoft.Network/NetworkSecurityGroups"
在 AzCLI 中运行本质上相同的命令会以不同的格式返回不同的信息。
{
"changedTime": "2021-08-01T22:37:30.018120+00:00",
"createdTime": "2021-08-01T22:27:12.392913+00:00",
"extendedLocation": null,
"id": "/subscriptions/c7adec53-c4c1-436f-b9a7-d5230a145a6b/resourceGroups/nsg-rg-msdn-ent/providers/Microsoft.Network/networkSecurityGroups/app-nsg-msdn-ent",
"identity": null,
"kind": null,
"location": "eastus2",
"managedBy": null,
"name": "app-nsg-msdn-ent",
"plan": null,
"properties": null,
"provisioningState": "Succeeded",
"resourceGroup": "nsg-rg-msdn-ent",
"sku": null,
"tags": {},
"type": "Microsoft.Network/networkSecurityGroups"
}
Listing 2-2Azure CLI Command in Cloud Shell
Azure PowerShell 和 AzCLI 也可以从 Windows 命令提示符、PowerShell 提示符或 PowerShell ISE 实例中使用。
当运行命令或脚本时，使用 PoweShell ISE 通常是一个好主意，这样您可以更容易地检查代码、执行代码片段和解决问题。
通常，您可以使用 ARM 模板部署资源。ARM 模板使用基于 JSON 的声明性结构来标识要部署到 Azure 的一组资源的资源、属性和配置。
ARM 模板使用三个组件来构成部署的定义。
参数:提供部署过程中使用的值。参数文件可以重用，因为它们通常用于标识标准数据，并且在订阅、资源组和 Azure 环境中保持一致。
变量:特定于模板的参数，通常不会被重用。
Resources: 标识在部署期间要创建的资源。资源的配置信息通常从参数或变量中获取，并在资源创建期间应用。
当您部署 ARM 模板时，ARM 会将模板中的声明性代码转换为 REST API 操作，并按顺序执行它们。
让我们看看基本 ARM 模板中的结构组件。
| 声明此部分用于资源创建标识资源提供程序正在部署的资源的类型声明要使用的 Azure API 版本标识资源名称设置将部署资源的位置为资源选择 SKU 如果需要，标识子 SKU 指定资源的任何特定属性 | `"resources": [``{``"type": "Microsoft.Storage/storageAccounts",``"apiVersion": "2019-04-01",``"name": "storageaccount1",``"location": "centralus",``"sku": {``"name": "Standard_LRS"``},``"kind": "StorageV2",``"properties": {}``}``]` |一旦你部署了你的 ARM 模板，它就被转换成一个 PUT API 操作并针对 Azure API 执行，你的资源就基于你的请求被创建。
PUT
https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Storage/storageAccounts/mystorageaccount?api-version=2019-04-01
REQUEST BODY
{
"location": " centralus ",
"sku": {
"name": "Standard_LRS"
},
"kind": "StorageV2",
"properties": {}
}
ARM via DevOps
通过 ARM 在 Azure 中部署的典型代码创建>存储>执行过程相对简单。
代码通常是使用支持 ARM、Terraform、Chef 和大量编码语言和插件的工具(如 VS Code)开发的。
两种最常见的代码格式是 ARM 模板和 Terraform 模板。两者都可以用 VS 代码开发，部署到 Azure。Terraform 的好处在于，它在 Azure 中维护一个状态文件，在执行代码管道时会引用它，只修改需要的内容。
ARM 模板不跟踪当前的 Azure 环境，在部署和维护 Azure IaC 环境时灵活性稍差。
图 2-13
Azure 开发周期(简单)
一旦模板被创建，它们就被存储在某种代码库中。目前最常用的回购协议是 GIT，但代码也可以存储在 Azure 回购协议或许多其他第三方回购协议中。
一旦您创建了代码并准备好进行部署，您可以通过 PowerShell 命令或者更好的 Azure DevOps 管道进行部署。一旦你执行你的命令，或者运行管道，ARM 将接收你的请求，翻译它，并把它传递给 Azure API 进行服务。
摘要
在本章中，我们讨论了 Azure Resource Manager，它是什么，如何使用它，以及在规划 ARM 部署时需要考虑的事项。
虽然 Azure 资源管理器一开始看起来有点让人不知所措，但是如果你把它分成几部分，一次只关注一件事，就不难理解了。
通过本章，您应该对 ARM 有了基本的了解，对使用它规划部署有了深入的了解，并找到了如何将它融入您的云之旅的一些想法。
三、Azure 管理洞察
在 IT 界，管理被定义为监督所有与运营和资源相关的事务的过程。Azure Arc 存在的理由是通过将 Azure 云中的监控和控制服务扩展到 Azure 外部的计算机和服务来执行管理，例如在内部网络或其他云中。Azure Arc 本身并没有提供多少管理价值。相反，它是基于 Azure 的管理功能的丰富混合集，扩展到 Azure Arc 连接的计算机和服务，商业价值由此产生。
虽然本书中的许多章节都集中在 Azure Arc 的规划和部署方面，但本章的目的是让你具备想象什么是可能的知识。通过学习 Azure Arc 提供的监控和控制功能，您将发现您可以使用 Azure Arc 做什么。您将使用这些有价值的构建模块，有时称为微服务，来交付我们将在第六章“混合服务器监控解决方案”和第七章“Azure Arc 服务器的监管和安全合规性”中涉及的解决方案
Azure 策略
Azure 策略支撑着 Azure Arc 的所有功能。换句话说，你需要分配一个或多个策略给 Azure Arc 对象来完成工作。将 Azure Arc 视为一个 Azure 策略分发和执行框架并不是不准确的。
图 3-1 展示了 Azure Arc 服务器和 Azure Arc Kubernetes 实例(在底部)如何被分配 Azure 策略(左下和右下)以强制执行 Microsoft Defender for Cloud 和 Azure Monitor 配置。这些设置反过来支持微软 Sentinel、Azure 日志分析和 Azure 自动化解决方案。
图 3-1
Azure Arc 对象的 Azure 策略分配支持对 Azure 管理服务的访问
真理的单一来源
Azure Policy 强制执行组织标准并大规模评估合规性。对于各种规模的组织来说，使用基于法规遵从性的模型来实现安全敏感型治理、资源一致性和法规遵从性是最佳实践。本质上，你管理的是政策的例外。如果您实现了 100%的策略遵从性，并且您持续地监控该遵从性，那么您已经做了最好的工作。有什么比在任何地方用同样的工具执行同样的政策更好的方法来获得这种信心呢？
拥有安全合规性的“单一事实来源”对于确保安全态势的完整性至关重要。图 3-2 展示了 Azure Policy 和 Azure Arc 协同工作的威力。在右上角，可以看到 Azure Policy 正在将 Azure Monitor 和 Microsoft Defender for Cloud 的计划一致地推广到位于 Azure 和内部或任何云中的 Windows 和 Linux 计算机。其他云当然包括 AWS 和私有云服务提供商。
图 3-2
Azure 策略为云计划分配 Azure Monitor 和 Azure Defender
与活动目录的比较
熟悉 Microsoft Windows Active Directory(AD)的人可以将 Azure 策略等同于 Active Directory 组策略。如果您不熟悉 AD，可以考虑一个用户名和计算机名的目录服务，它为网络上发生的所有事情分配和实施统一的策略。
正如 AD 中的组策略对象(GPO)应用于指定的范围，如 OU(组织单位)或安全组，Azure 策略被分配给范围，如 Azure 订阅或资源组。在这两种情况下，许多位置的大量计算机共享一个策略的单个实例，从而提高了效率和一致性。表 3-1 通过将 Azure 策略概念与熟悉的 Active Directory 组策略组件进行比较，帮助理解它们。
表 3-1
比较 Azure 策略和 Active Directory 组策略
|Azure 策略
|
Active Directory 组策略
|
| --- | --- |
| Azure 策略在分配范围内的计算机上强制实施设置。多个策略可以捆绑在一个计划中。计算机可以应用多个方案。 | GPO 可以包含许多不同设置的设置。计算机可以应用多个 GPO。 |
| 策略分配的范围在 Azure 订阅和资源组级别。例外可以应用于范围内的特定计算机。 | GPO 通常应用于域和 OU 级别。它们也可以应用于安全组，并且支持特定的豁免。 |
| 以下是导致策略被评估的时间或事件:在具有策略分配的范围内创建、更新或删除资源。一个策略或计划被新分配给一个范围。更新已经分配给某个范围的策略或计划。在每 24 小时一次的标准合规性评估周期中。 | 计算机运行时，GPO 在启动时和每 90 分钟应用和处理一次。 |
| Azure 策略示例:"审核最短密码期限不超过 1 天的 Windows 计算机" | GPO 设置示例:默认域策略➤计算机配置➤策略➤ Windows 设置➤安全设置➤帐户策略➤密码策略➤“最短密码期限”策略设置“1 天” |
Tip
Azure 策略也可以分配给 Azure 管理组，这些逻辑容器允许 Azure 管理员一次管理多个 Azure 订阅的访问、策略和合规性。
图 3-3 是 Azure 门户中策略刀片的概览窗格。已经分配给资源的五个计划的名称可以在左栏中看到。第四列和第五列显示分配的计划中不符合的资源数量和不符合的策略数量。通过逐一修正相关的不符合策略，可以减少不符合资源的数量。
图 3-3
Azure 策略定义对 Azure 内部和内部资产统一实施规则
总之，Azure 策略在 Azure Arc 中用于向 Azure Arc 服务器交付策略分配。在此模型中，Azure 策略的常见用途是启用对 Azure Monitor 和 Microsoft Sentinel 的监控，并实施相关合规性计划中包含的安全策略。
微软云卫士
Microsoft Defender for Cloud 是一项可选服务，可在您的 Azure 订阅中启用。作为最佳实践，打开 Microsoft Defender for Cloud 以增强您的云安全状况。Microsoft Defender for Cloud 的独特功能包括安全评分，用于衡量您的订阅的安全状况，以及法规遵从性，这是一个强大的治理和基准测试解决方案。
使用 Microsoft Defender for Cloud 保护您的混合云工作负载。当 Microsoft Defender for Cloud(以前的 Azure Security Center)最初发布时，唯一支持的计算机是 Azure 虚拟机(VM)。现在有了 Azure Arc，Microsoft Defender for Cloud 支持扩展到任何云中的本地计算机或虚拟机。面向 Azure Arc 场景的 Microsoft Defender for Cloud 的主要优势包括:
-
建立一个数据驱动的指标，使用 Azure Secure Score 评估您在 Azure、内部部署和其他云中的资源的安全状态。
-
简化企业合规性，并对照法规要求查看您的合规性。
-
Microsoft Defender for Server 针对易受攻击的工作负载(如服务器、SQL 数据库和 Kubernetes)提供深度安全检查。
这些关键优势映射到图 3-4 中所示的 Microsoft Defender for Cloud 中的顶级仪表盘图块。通过 Azure Arc，Windows 和 Linux 服务器以及 Azure 之外的 Kubernetes 完全参与了 Microsoft Defender for Cloud coverage，就像它们在 Azure 中的同行一样。
图 3-4
Microsoft Defender for Cloud(以前的 Azure Defender)是 Azure Arc 机器和 Kubernetes 安全的关键
Microsoft Defender for Cloud 的每个 Azure Arc 服务器的月成本为 15 美元，机器上的 SQL server 的月成本为 15 美元。Azure Arc Kubernetes 的成本是 2 美元/虚拟机核心/月，容器注册表是 0.29 美元/映像。具体价格因地区而异；点击此链接获取最新价格:
https://azure.microsoft.com/en-us/pricing/details/azure-defender
关注安全性的仪表板
为了在每个技术孤岛中监控企业的所有安全敏感方面，需要监视许多控制台和门户。你真的可以说，你宁愿看你的反恶意软件应用门户，而不是看你的防火墙健康门户？当然，你需要关注这两个门户网站以及其他许多网站。虽然 Azure 中的安全设置几乎无处不在，但 Microsoft Defender for Cloud 通过其安全评分方法获得了一个战略制高点，您可以从这个制高点评估您的企业安全状况。
正当运行 Microsoft Sentinel 的客户可以将 Microsoft Sentinel 视为他们的顶级安全操作控制台。然而，与 Microsoft Sentinel 中的实时事件处理和调查不同，Microsoft Defender for Cloud 提供了相关的控制面板视图，以及对“最普遍的建议(按资源)”和“潜在增长最高的控制”的洞察
在没有 Microsoft Sentinel 集成的情况下，Microsoft Defender for Cloud 具有内置的警报和通知工作流功能，可以在配置时向您发出信号。像微软 Sentinel 一样，工作流自动化采用 Azure Logic 应用的形式。例如，您可以编写一个逻辑应用，该应用获取 Microsoft Defender for Cloud alerts 的输出，并发送一封 O365 电子邮件，其中包含详细信息。
Tip
您可以为 Microsoft Defender for Cloud 发出的安全警报启用粒度抑制规则。在 Microsoft Defender 中查找云➤常规➤安全警报➤抑制规则的设置。基于 IP、DNS、主机和 Azure 资源实体创建覆盖
Microsoft Defender for Cloud for server
对于许多客户来说，这可能是激活 Microsoft Defender for Cloud 的首要原因。Microsoft Defender for Cloud for servers 包括 Microsoft Defender for Endpoint，无需额外费用。它们共同提供全面的终端检测和响应(EDR)功能。使用 Microsoft Defender for Cloud 的 Windows 服务器会自动启用 Microsoft Defender for Endpoint 传感器。
Azure 虚拟机和 Azure Arc 服务器之间有许多功能相似之处，其中之一是如何使用来自 Microsoft Defender for Cloud 的数据填充安全刀片。图 3-5 与您看到的启用了 Microsoft Defender for Cloud coverage 的 Azure 虚拟机几乎相同，但这个 Azure Arc 服务器是一个运行在内部私有云上的虚拟机。提供了安全建议的优先列表以及计算机的安全事件和警报的历史列表。
图 3-5
Microsoft Defender for Cloud 的覆盖范围通过 Azure Arc 扩展到了本地服务器
符合监管要求
对于一些组织，如必须遵守 PCI DSS 的金融机构或必须遵守 HIPAA 的医疗保健组织，合规性是部署 Azure Arc 和 Microsoft Defender for Cloud 的关键原因。符合性分配的安全分数基于范围内的资源符合所需安全策略的程度。拥有一个定义良好的、行业认可的安全模型可以让您的团队朝着一个有意义的目标努力。
各种行业和地区监管标准可通过策略分配给范围。这些监管标准已预先部署(开箱即用)到每个 Microsoft Defender for Cloud 实例中:
-
PCI DSS 3.2.1(支付卡行业数据安全标准，适用于处理主要卡组织品牌信用卡的组织)
-
ISO 27001(关于如何管理信息安全的国际标准)
-
SOC TSP(关于服务组织提供的服务的内部控制报告)
在 Microsoft Defender for Cloud 门户网站中轻松添加其他法规遵从性标准:
-
NIST SP 800-53 R4(联邦信息系统和组织的安全和隐私控制)
-
NIST SP 800 171 R2(保护非联邦系统和组织中的受控非机密信息)
-
英国官方和英国国民健康保险制度
-
加拿大联邦 PBMM
-
Azure CIS 1.1.0(新)(Microsoft Azure Foundations 基准法规遵从性)
-
Azure 安全基准
-
HIPAA HITRUST(医疗保健组织健康保险可携带性和责任法案)
-
SWIFT CSP CSCF v2020(客户安全控制框架包括针对 SWIFT 用户的强制性和咨询性安全控制)
推荐的安全生命周期方法
考虑使用 Microsoft Defender for Cloud with Azure Arc resources 的法规遵从性功能的这些高级步骤:
-
将 Azure Arc 服务器和 Azure Arc Kubernetes 放在适合作为策略范围的 Azure 资源组中。
-
将一个或多个 Azure 策略方案分配给包含 Azure Arc 服务器和/或 Kubernetes 的资源组。
-
在初始分配后，观察计划中所有策略的遵从状态。
-
为那些在您的环境中被判定为缓解或放弃的策略创建一个豁免。
-
从未解决的不合规资源的短列表开始，执行必要的补救以实现 100%的合规性。
-
监控持续的完全合规性，在出现异常时发出警报。
-
警报会导致手动或自动修复和补救任务，从而恢复完全合规性。
图 3-6 显示了完全符合计划的情况。您将获得 100%的安全分数，并且计划中列出的每个控件都将被标记为已完成。
图 3-6
当你获得 100%的安全分数时，成功是什么样的
天蓝色监视器
Azure Monitor 是一项 Azure 服务，它收集、分析和处理来自 Azure 和内部环境的遥测数据。将“Azure Monitor”视为一个包含各种解决方案的品牌，就像“Microsoft Office”一样，它包括 Word、Excel、Outlook 和一系列帮助各个应用和组件协同工作的公共基础。
Azure Monitor 有很多优点；参考图 3-7 了解使用了哪些工具和微服务。如果你在 Azure 中有任何资源或者你正在使用 Azure Arc，你已经在使用 Azure Monitor 了。每个 Azure 和 Azure Arc 资源都生成日志，许多资源还提供关于利用率和性能的指标。
图 3-7
Azure Monitor 收集、分析和处理遥测数据
Tip
了解 Azure Monitor 产品名称
Azure Monitor、日志分析和应用洞察是提供监控的单一服务。日志分析和应用洞察中的一些功能已经更名为 Azure Monitor，但其功能没有改变。日志分析的日志数据引擎和查询语言被称为 Azure Monitor Logs 。
Azure Monitor 数据源和解决方案
在图 3-7 的左边是输入到 Azure Monitor 的数据源，比如 Windows 计算机操作系统、类似 Key Vault 的 Azure 服务，或者来自 Azure 订阅的活动。中间度量和日志的数据库图标代表遥测数据流动和存储的数据存储库。数据的消费者和用户(“解决方案”)位于右侧，包括 Azure 仪表盘和工作簿，用于可视化和日志分析，以运行在可用性、性能、配置或安全问题发生时发出警报的预定查询。
Azure Monitor 将来自多个来源的数据存储在一起，以便可以使用一组通用工具关联和分析数据。您完全从数据存储库中抽象出来(您可以把它想象成一个无限容量的数据湖)。存储库中的数据是只读的，受您的工作区的保留策略的约束。微软通过正常的 Azure 基于角色的访问控制来处理安全访问，并在数据保留期结束时自动清除数据，默认情况下保留期为 30 天，但可延长至 2 年。
Azure Monitor 的不同数据源将写入日志分析工作区(Logs)或 Azure Monitor 指标数据库(metrics)或两者。数据存储在表中，每个工作空间或数据库都有不同的表，这取决于向它们写入了什么数据源。
Azure Monitor 范围定位
Azure Monitor 在您创建新的 Azure 订阅时启用，活动日志和平台指标会自动收集。当涉及到日志查询时，生成日志的资源被视为“作用域”。
图 3-8 展示了 Azure Monitor 日志需要一个范围来执行查询的概念。通过将 Azure Monitor 日志限定到任何生成日志的特定 Azure 资源，您可以针对该资源的日志数据运行集中查询。或者，通过将范围设置为日志分析工作区，您可以从向该工作区报告日志的所有数据源的数据库表中进行搜索。
图 3-8
Azure Monitor 日志需要选择一个范围来定位查询
例如，图 3-9 显示了 Azure Arc 服务器的日志刀片。由于该服务器运行的是 Windows Defender 反恶意软件防御，并且部署了安全和审计或安全无中心解决方案，因此保护状态表出现在日志视图中，您可以直接查询该表。
图 3-9
使用 Azure Monitor 日志检查 Azure Arc 服务器上 Windows Defender 的状态和上次扫描日期
不用说，一个相同的 ProtectionStatus 表也存在于运行 Windows Defender 的 Azure VM 的日志视图中。考虑一下，您可以对所有计算机的 ProtectionStatus 表运行相同的查询，包括 in-Azure 和非 Azure，以了解是否有任何计算机检测到威胁或扫描过期。这是一个有力的例子，说明了 Azure Arc 如何将本地计算机提升到与 in-Azure 虚拟机相同的管理范式，从而使您在混合管理任务方面的生活更加轻松。
Tip
当查询范围设置为特定资源时，查询浏览器、保存和新警报规则按钮在 Azure Monitor 日志视图中不可用。要创建警报、保存或加载查询，日志分析的范围必须是工作区。
日志分析和微软哨兵
部署这些 Azure 服务中的一个或两个来支持基础设施监控(日志分析)和/或安全监控(Microsoft Sentinel)是 Azure Arc 的一个优秀和常见的场景。通过这样做，您将实现“单一控制台”,将您的 in-Azure 和非 Azure 资源集中在相同的警报基础架构和门户视图中。两种解决方案使用相同的代理，并具有相同的推广计划。
如果您的企业有任何数量的服务器在 Azure 之外运行，并且您计划从 Azure 监控它们，您希望
-
使用天蓝色弧线来…
-
分配 Azure 策略…
-
安装 Microsoft 监控代理(MMA)和依赖项
对于 Azure Log Analytics 和 Microsoft Sentinel 场景，这就是全部内容。本章描述的所有其他监控解决方案只需要安装 MMA(和依赖项)。
日志分析工作区
像用于 AKS 部署的 VM Insights (包括 Azure Arc 服务器)和 Container Insights 这样的监控解决方案安装到日志分析工作区中。 Microsoft Sentinel 作为超集解决方案( Security Insights )安装到现有的日志分析工作区中。(Azure Log Analytics 工作区和 Microsoft Sentinel 实例之间存在 1:1 的关系。)无论您的最终目标是使用日志分析监控服务器，还是使用 Microsoft Sentinel 管理服务器的安全性(或者两者兼有)，您都需要在 Windows 和 Linux 服务器上安装 MMA。
以下是您将在日志分析工作区中执行的三项常见操作:
-
部署监控和管理特定服务的解决方案。
-
运行计划查询规则以发出警报。
-
创建可视化效果，如工作簿和仪表板。
接下来，我们将逐一了解这些内容。
Tip
避免工作空间蔓延。考虑在新的生产 Azure 订阅中创建一个日志分析工作区，作为您创建的第一个资源。这样做可以使您创建的其他日志生成资源(如虚拟机和密钥库)有一个共同的目标。
-
–启用应用洞察、容器洞察和虚拟机洞察并安装 Azure Sentinel 时，选择预先存在的工作空间。
-
–在 Azure Security Center 的定价和设置➤订阅➤设置➤自动配置中配置您的中央日志分析工作区的自动分配。
日志分析解决方案
日志分析中的监控解决方案提供了对特定 Azure 应用或服务操作的分析。部署日志分析工作区后，将自动添加适合您环境的监控解决方案，以提供特定功能。例如，当您启用 Microsoft Defender for Cloud 时，安全解决方案会安装在您选择的日志分析工作区中。
使用 Azure Monitor 日志的基本功能不需要安装解决方案；然而，几乎所有生产日志分析工作区都会安装几个解决方案。
对 Azure Arc 服务器特别有用的解决方案包括由 Azure Automation 安装的变更跟踪和更新，以及微软 Sentinel 的解决方案名称安全观察。图 3-10 显示了安装在日志分析工作空间中的这些解决方案。如果您需要从工作区中删除一个解决方案，您可以在这里完成。
图 3-10
日志分析工作区的解决方案刀片列出了工作区中安装的解决方案
日志分析成本
Azure Monitor 的日志接收成本以每天千兆字节(GB/天)为单位。这是使用日志分析的主要成本。监控服务器每月贡献 1 到 3 GB 的日志和度量数据；运行 DNS 服务器的域控制器每月将高达 10 GB。根据经验，每个 Azure Arc 服务器每月预算 5 美元用于日志分析处理。(此处未估算 Microsoft Sentinel 摄取成本，该成本也以 GB/天为单位进行测量，并计入日志分析费用。)
为 Azure Logic App 和 Azure Functions executions 之类的东西运行预定查询规则和微成本会产生较小的成本。最贵的监视器每 5 分钟运行一次，每月大约 1.5 美元。每小时或每天运行一次的监视器成本要低得多，低至每天 0.05 美元。一般组织每月在这些小额费用上的花费远低于 50 美元。
要获得 Azure Monitor 度量查询和警报费用的精确估计，请在以下链接的 Azure 定价计算器中输入您的规模数据:
azure。微软。com/ en-us/ pricing/ calculator/？服务=监视器
微收费的贡献者包括指标查询(每 1000 个 API 调用 0.01 美元，前 100 万个免费)、ITSM 连接(每创建 1000 个票证 5.00 美元，前 1000 个免费)和电子邮件通知(每 100，000 个电子邮件 2.00 美元，前 1000 个免费)。
日志警报规则
日志警报允许您使用日志分析查询来定期评估日志，并根据结果发出警报。规则可以使用操作组触发一个或多个操作。操作组可以包括通知任务，如发送电子邮件或创建 ITSM 票证，以及自动化任务，如启动 Azure Automation Runbook 或 Logic 应用。
传统的基于状态的监控与基于分析的监控
这是真正的监控工作发生的地方。传统的网络监控工具，如微软系统中心操作管理器(SCOM)或网络安全管理软件产品公司的 Orion ，由一个代表被监控服务器健康状态的数据库组成。代理或探测器使用专有工作流来检查特定的属性或指标，并将其写入数据库。例如，监视器可能“ping”一个服务器，并将 ping 应答状态记录到数据库中。当您想知道服务器是否在线时，您可以检查数据库中的 state 值，以了解最后一次成功的 ping 是什么时候。
一种更现代、更可扩展的方法是使用基于日志的分析。这种方法的流行实现包括来自 Splunk 、 Sumo Logic 和 ELK (Elasticsearch、Logstash 和 Kibana) 的产品。企业通常选择 Splunk 的功能和特性集，云原生 Sumo 逻辑的简单性，或 ELK 的开源设计。
在该模型中，轻量级代理进程将日志数据从服务器传输到存储库。想法是，如果我们记录服务器正在做的一切，我们可以通过搜索日志的副本来了解我们想要的任何东西。有关服务器状态的问题通过两步过程来回答:(1)首先运行一个搜索存储库的查询，然后(2)查找搜索查询条件的匹配(或不匹配)。
基于查询的警报规则如何工作
例如，考虑一个您希望发出警报的常见场景；这是与受监控服务器失去联系。对失去联系发出警报的查询包括从计算机中搜索最近的“心跳”日志条目。运行查询时没有找到最近的心跳日志条目构成了失去联系。每 5 分钟运行一次该查询(一个预定警报规则)可以在与服务器失去联系时产生近乎实时的警报。
参见图 3-11 中 Azure 日志分析工作区的规则刀片。第一列显示警报生成规则的名称，第二列显示对感兴趣的条件进行检查的实际查询语言。
图 3-11
预设规则检查您想要发出警报的条件
许多适用于 Azure 虚拟机的查询也适用于 Azure Arc 服务器。例如，考虑这个简单的查询，它返回一个受监控计算机的列表，以及它们最近的心跳:
Heartbeat
| summarize arg_max(TimeGenerated, *) by Computer
由于 Azure VMs 和 Azure Arc 服务器每分钟都产生心跳消息，并且这两种服务器都属于 Azure 对象的“计算机”类，因此实现了同构列表。
如果将来迁移到 Azure VMs，您在为 Azure Arc 服务器构建有用的监控规则库方面所做的投资将在很少或没有修改的情况下继续工作。基于预定查询的规则在 Microsoft Sentinel 中的工作方式相同，它们被称为分析活动规则。
工作簿和仪表板
当不利或异常事件发生时，一旦您收到警报，请考虑有效监控的另一面是可视化。特别是，要评估计算机性能指标的状态，一个警报列表(甚至是没有警报)是不够的。在许多情况下，您需要某种基于图表或图形的可视化显示来执行管理。
Azure Monitor(以及 Azure Log Analytics 和 Microsoft Sentinel)使用与警报生成规则相同的核心功能解决了可视化需求:查询。Azure Monitor 中使用的查询语言 Kusto Query Language 或 KQL 的一个特性是，查询可以以图形和列表格式返回数据。请这样想:虽然预定的警报规则包含要运行的查询和要根据查询结果执行的操作，但 Azure Monitor 可视化如工作簿和仪表板包含多个查询。当您打开工作簿或仪表板时，每个查询都会立即执行并实时呈现图形输出供您查看。
Azure 工作簿
图 3-12 中的工作簿展示了混合环境中跨平台查询分析的强大功能。带有条形图和彩色阴影的分类图表评估服务器性能。该视图显示了 Windows 和 Linux 服务器的 CPU 利用率，这些服务器既是 Azure 中的虚拟机，也是本地物理和虚拟计算机。借助 Azure Arc 和 Microsoft Monitoring Agent (MMA ),您可以使用 Azure 管理工具实现服务器性能的“单一平台”,这些工具可扩展到您的整个资产。
图 3-12
查询在 Azure 工作簿中以图表形式返回数据
工作簿保存在您的 Azure 订阅中，可以通过各种方式与团队成员共享。Microsoft Sentinel 环境只有共享工作簿，而 Azure Monitor 和日志分析环境只有私有工作簿。在所有环境中，通过向接收者发送唯一的 URL，私有工作簿是可共享的。
工作簿支持启用参数的交互式报告——也就是说，选择表格中的一个元素将动态更新相关的图表和可视化效果(参见图 3-12 中的下拉选择框，如计数器和表格趋势)。这使您可以旋转和聚焦可视化，以便在数据中“飞来飞去”。
Azure 仪表盘
Azure Monitor 中的另一个可视化产品是 Dashboard。就像 Azure 工作簿一样，Azure 仪表板是 KQL 查询的集合，配置为以图表和图形格式返回数据。仪表板可以是您的用户帐户专用的，也可以与队友共享。
图 3-13 是一个仪表板，基础设施洞察显示所有受监控服务器的网络流量指标，包括内部 Azure 虚拟机和内部 Azure Arc 服务器。这种可视化有助于您快速识别您的资产中的“主要参与者”—,无论他们在哪里，也无论他们运行什么操作系统。
图 3-13
Azure 仪表盘具有自动刷新和全屏模式
使用仪表板的主要原因包括，像工作簿一样，仪表板有一个自动刷新设置，可以从每 5 分钟到每天一次进行自定义。仪表板也有一个有用的“全屏”模式。通过组合这些功能，您可以创建无限数量的实时 kiosk 风格的仪表板，这些仪表板可以在任何装有 web 浏览器的计算机上运行。
Azure 自动化解决方案
Azure Automation 帐户链接到给定的 Azure 日志分析工作区，以支持各种解决方案。在 Azure Automation 中，您可以为您的 Azure Arc 服务器和 Azure 内虚拟机启用更新管理、更改跟踪和清单功能。这些功能依赖于日志分析工作区，因此需要将工作区与自动化帐户相链接。
最佳实践是在创建 Azure Log Analytics 工作空间后立即创建一个自动化帐户，然后继续执行链接它们的过程。但是，仅支持某些区域将它们链接在一起。表 3-2 列出了成功启用和使用这些功能的支持映射。确保了解此表，并为您的 Azure Log Analytics 工作区选择区域。
表 3-2
支持的映射 Azure 日志分析 Azure 自动化
|日志分析工作区区域
|
Azure 自动化区域
|
| --- | --- |
| 澳大利亚东南部 | 澳大利亚东南部 |
| 加拿大中央 | 加拿大中央 |
| 印度中部 | 印度中部 |
| 中国东方 2 号 | 中国东方 2 号 |
| 艾西乌斯 | 伊斯特斯 2 号 |
| 伊斯特斯 2 号 | 艾西乌斯 |
| 法国腹侧 | 法国腹侧 |
| 日本料理 | 日本料理 |
| 北欧 | 北欧 |
| 中南半岛 | 中南半岛 |
| 东南亚 | 东南亚 |
| 瑞士北部 | 瑞士北部 |
| 英国南部 | 英国南部 |
| 美国亚利桑那州 | 美国亚利桑那州 |
| 美国弗吉尼亚州 | 美国弗吉尼亚州 |
| 威斯特中心 | 威斯特中心 |
| 西欧国家 | 西欧国家 |
| 威斯乌斯 2 号 | 威斯乌斯 2 号 |
您会很高兴创建了一个自动化帐户，这不仅是为了我们将在本章中描述的更新和配置管理功能，也是为了您将获得的通用流程自动化:
-
Runbooks :可以自动启动的 PowerShell 或 Python 脚本
-
混合工人小组:在本地执行从基于云的 Azure 流程启动的操作手册的自动化工具
-
观察者任务:启动观察事件的成对操作手册，然后在事件发生时执行选定的自动操作
有了自动化框架，您可以将 runbooks 指定为对 Azure Monitor 警报的自动响应。此外，您可以准备基于 PowerShell 和 Python 脚本的 runbooks，以响应由 Microsoft Sentinel 行动手册(Azure Logic Apps)激活的 webhooks。
Tip
要将 Azure Automation 帐户与 Azure Log Analytics 工作区链接，请导航到其中一个配置管理解决方案或自动化帐户中的更新管理解决方案。在右侧的详细信息窗格中，您将能够选择配对的日志分析工作区，并按下启用按钮。
Azure 自动化成本
Azure Automation 在 Azure Arc 场景中有两个优秀的特性:更新管理和配置管理。一个是处处自由；另一个成本在 Azure 之外:
-
更新管理:免费(所有 Azure 虚拟机和 Azure Arc 服务器)
-
配置管理:Azure 虚拟机免费，Azure Arc 服务器每月 6 美元的“非 Azure 节点配置管理”
除了这些功能之外，Azure Automation 还具有流程自动化功能，例如微收费的作业运行时间(0.002 美元/分钟，每月 500 美元)和观察器节点(002 美元/小时，每月 744 美元)。
要获得流程自动化和配置管理的 Azure Automation 费用估算，请在 Azure Automation 定价页面选择您的地区和货币:
https://azure.microsoft.com/en-us/pricing/details/automation/
更新管理
Azure automation 的更新管理功能是一个巨大的价值，因为对 Azure 虚拟机或 Azure Arc 服务器使用该解决方案没有许可成本。除了日志分析数据处理的微收费，这是一个完全免费的解决方案，用于监控和管理 Windows 和 Linux 操作系统(OS)更新。行业内真的没有类似的。
如果您正在购买第三方服务器更新解决方案，或使用 Microsoft Endpoint Manager(以前的 System Center Configuration Manager)进行操作系统更新，或使用 WSUS(Windows Server Updating Server)，请考虑迁移到这款免费的全功能解决方案来处理您的服务器操作系统更新。它简单而优雅，并与 Azure Arc 和 Microsoft Defender for Cloud 完全集成。
在您启用更新管理解决方案后，您的每个 Azure Arc 服务器都将在 Azure 门户中的 Azure Arc 服务器刀片内拥有一个实时更新仪表板，如图 3-14 所示。您不仅可以准确地实时查看所选计算机的更新状态，还可以针对本地服务器轻松创建和启动基于云的更新任务。
图 3-14
Azure Arc 服务器的更新管理刀片
除了添加到每个 Azure Arc 服务器的更新管理视图，还有一个视图管理 Azure Automation account blade 中的多台机器上的更新，如图 3-15 所示。从该页面，您可以在 Azure VM 和 Azure Arc 服务器设置中针对多台 Windows 和 Linux 计算机启动即时或计划更新作业。
图 3-15
Azure Automation 帐户的更新管理刀片
结构管理
Azure automation 的配置管理功能对 Azure 虚拟机是免费的，Azure Arc 服务器每月有 6 美元的 Azure 消费成本(被称为“非 Azure 节点的配置管理”)。该特性捆绑了三个微服务:状态配置(DSC)、清单和变更跟踪。
状态配置(DSC)
Azure Automation State Configuration 是一个 Azure 配置管理服务，允许您为任何云或内部数据中心中的节点编写、管理和编译 PowerShell 所需的状态配置(DSC)配置。
如果您还没有准备好从云中管理机器配置，您可以使用 Azure Automation State Configuration 作为仅报告端点。此功能允许您通过 DSC 设置(推送)配置，并在 Azure Automation 中查看报告详细信息。
如果您的环境已经在 Azure 之外使用 DSC，请考虑 Azure 自动化状态配置提供了几个优势。该服务能够从一个安全的中心位置快速轻松地跨数千台机器进行扩展。
Azure Automation State Configuration service 之于 DSC，就像 Azure Automation runbooks 之于 PowerShell 脚本一样。换句话说，就像 Azure Automation 帮助你管理 PowerShell 脚本一样，它也帮助你管理 DSC 配置。
库存
Azure 自动化清单功能会发现您的环境中安装了什么软件。您可以收集和查看计算机上的软件、文件、Linux 守护程序、Windows 服务和 Windows 注册表项的清单。跟踪计算机的配置可以帮助您查明环境中的操作问题，并更好地了解计算机的状态。
清单解决方案提供了类似传统 CMDB(配置管理数据库)的功能，可以跟踪所有受监控的 Windows 和 Linux 服务器上安装的软件和运行的服务，包括 Azure 虚拟机和本地 Azure Arc 服务器。实时和历史库存状态同样被跟踪。
39 台服务器(主要是 Azure Arc Windows 服务器和一些 Linux)的清单视图如图 3-16 所示。在之前的 24 小时内，Azure Automation 跟踪了超过 12，000 项软件更改、近 800 项 Windows 服务和 200 项 Linux 守护程序状态更改。
图 3-16
Azure Automation Inventory:安装在您环境中的软件的实时配置管理数据库
更改跟踪
Azure Automation 中的更改跟踪可监控 Azure、内部和其他云环境中托管的虚拟机的更改，以帮助您查明操作和环境问题。例如，如果 Azure Arc 服务器开始出现问题，您可以咨询计算机的服务器-Azure Arc 更改跟踪刀片，查看在过去几个小时或几天内是否发生了任何意外的软件或注册表更改。更改跟踪所跟踪的项目包括
-
Windows 软件
-
Linux 软件(软件包)
-
Windows 和 Linux 文件
-
Windows 注册表项
-
微软服务
-
linux 守护进程
变更跟踪建立在 Azure Automation 的库存特性之上。捕获受监控清单发生的更改，以便在调查过程中重现这些更改，并提供环境中名义更改率的指标。图 3-17 是 Azure Automation 帐户设置为 30 天视图的变更跟踪刀片。
图 3-17
Azure 自动化变更跟踪:检测跨平台和应用的变更
聚焦和过滤变更跟踪摘要，以深入到图中反映的单个变更，这是很简单的。变更跟踪在某种程度上是 Azure 自动化配置管理解决方案的“皇冠上的宝石”,因为它在取证和安全角色中的价值。
当您的环境中出现无法解释的问题时，一个早期且有效的问题是，什么发生了变化？有了 Azure Automation 变更跟踪，你就有了一个有价值的工具来回答这个问题。当检查变更事件的变更细节时，变更的“之前和之后”值被保存并显示，如图 3-18 所示。
图 3-18
在 Linux 计算机上检测到的软件版本更改的详细视图
虽然更改跟踪对于重建单个计算机上发生的更改非常有用，但它的另一个作用是监视和评估在整个资产的正常情况下更改的总体速度和范围。然后，当异常数量的更改发生时，Azure Automation 的聚合监控功能可以检测到它们。
在单个计算机中检测到的更改被写入 Azure Log Analytics 中的 ConfigurationChange 表。如果查询检测到与正常更改量有较大差异，则表明环境中发生了值得调查的事情。
事实上，异常变化检测是一种非常有价值的安全监控技术。图 3-19 是这种情况下可能出现的 Microsoft Sentinel 概览页面的一个片段。如果你看到了这个，你就会知道在过去的 24 小时内经历了两次异常巨大的变化。调查意外的变化可能是不需要的过程正在发生并需要补救的第一个提示。
图 3-19
来自 Azure Sentinel overview blade 的数据源异常检测
摘要
在这一章中，你学习了 Azure Arc 的所有功能。您已经熟悉了 Azure Arc 中的监视和控制特性，并对它们的功能有了基本的了解。既然你受到了启发，让我们进入下一章，我们将深入如何规划、部署和支持 Azure Arc 服务器。
四、Azure Arc 服务器：入门
Azure Arc 代表了一个全新的概念，它有机地从云中出现。这一秘密成分标志着 Azure Arc 对云本质特征的自然倾向，如广泛的网络接入和快速的弹性。“云”系统自然会战胜不能持续适应的遗留和传统系统。考虑一下 Azure Arc 给你的组织带来的超大规模资源池的好处——将你的非 Azure 资源投射到 Azure Resource Manager (ARM)控制平面，在那里它们加入数十亿个管理良好的对象。
创建这个被投影的对象，一个 Azure Arc 服务器，并从中获取价值是本章的内容。本章介绍并深入探究 Azure Arc 服务器对象在 Azure 中的样子，以及它在 Windows 和 Linux 计算机上的代理足迹。在这一章中，我们集中在一次安装一个 Azure Arc 代理来进行测试和评估，在第 5“Azure Arc 服务器:大规模使用”一章中，将会有关于在生产中部署 Azure Arc 代理的细节。
管理平台即服务
Azure Arc 是服务器管理功能的目标架构，因为它将管理任务移动到了一个成熟的超大规模云中。这些任务是什么——服务器可用性、配置、性能和安全性——自早期联网以来就没有改变过。发生变化的是管理任务的最佳交付位置。
在有云之前，有内部，大多数人把它叫做 LAN 和/或 WAN(局域网/广域网)。还有一个 VPN(虚拟专用网络)，这些以网络为中心的结构定义了管理和监控发生的画布。要监控的每个对象都在 LAN/WAN/VPN 边界内，因此管理工具也在那里。
快进到现代混合时代，物理位置通常与服务交付或消费无关。服务器管理任务的出现是很自然的，也是意料之中的，这些任务可以从云服务中“剥离”并交付，比留在内部更有效。可以将灾难恢复即服务(DRaaS)产品想象为受异地公共云保护的本地服务器。灾难恢复传统上需要大量昂贵的基础设施来构建热点站点，因此将灾难恢复剥离到云是经济驱动的早期行业趋势。
图 4-1 图片服务器管理功能如同冰山，大部分服务器管理负担转移到 Azure。庞大的全球 Azure 资源管理器是您使用 Azure Arc 的后端服务提供商。Azure Arc 代表了云经济学产生的新范式:无成本管理即服务(MaaS)。换句话说，Azure Arc 是微软作为免费平台服务提供的一个无限可扩展的管理工具框架。
图 4-1
Azure Arc 将许多服务器管理功能移至 Azure 资源管理器
云服务管理可以从业务支持、供应和配置的角度以及可移植性和互操作性的角度进行描述。Azure Arc 允许您的服务器体验这些规模经济，通常只保留给云服务，即使它们不存在于云中！扪心自问:为什么不为您的服务器“植入”一套行之有效的管理、监控和安全最佳实践呢？当您可以减轻成本和维护负担时，为什么还要购买和维护任何遗留管理工具呢？
这是对投资 Azure Arc 进行服务器管理是否明智的最后一次“检验”:作为一种基于云的管理技术，Azure Arc 通过了托管服务的“相互协调”测试。该产品最根本的基础是消费者和服务提供商的“双赢”。微软赢了，因为通过使用 Azure Arc，你更有可能消费收费的微软服务，你赢了，因为 Azure Arc 降低了你的服务器的总拥有成本(TCO)。
什么是 Azure Arc 服务器？
在前端，Azure Arc 服务器是一台由 Azure 管理但在 Azure 外部运行的计算机。在后端，Azure Arc 服务器是 Azure 资源管理器(ARM)资源“类型”Microsoft.HybridCompute/machines的一个机器实例。
Azure 资源管理器(ARM)资源类型
Azure Arc 服务器的混合本质是由独立的物理和逻辑实体组成的:
-
物理位置:运行在除 Azure cloud 之外的世界任何地方的物理或虚拟计算机
-
虚拟位置:“类型”的 Azure 资源Microsoft.HybridCompute/machines存在于特定的 Azure 订阅、资源组和位置中
相比之下，完全存在于 Azure 中的 Azure VM 具有以下分类:
- Azure VM: 【类型】微软的 Azure 资源。特定 Azure 订阅、资源组和位置中存在的计算/虚拟机器
像 Azure 中的其他所有对象一样，Azure 虚拟机和 Azure Arc 服务器都是由资源类型、订阅、资源组和位置定义的 Azure 资源。分配给 Azure 虚拟机和 Azure Arc 计算机的标签在治理和计费方面的工作方式相同。
图 4-2 是正在运行的 Azure Arc 服务器(左边)和 Azure VM(右边)的 Azure 资源管理器(ARM)定义的并列 JSON 视图。这些常见的基础软件结构解释了为什么使用基于 Azure 的工具管理本地服务器是合理且高效的。
图 4-2
Visual Studio 代码中的并排 JSON 视图突出了 Azure Arc 服务器和 Azure VMs 的 ARM 通用性
Tip
使用 Azure PowerShell 通过 ARM 资源类型名称查询 Azure Arc 服务器或 Azure VMs 的列表:
get-AzResource -ResourceType Microsoft.HybridCompute/machines
get-AzResource -ResourceType Microsoft.Compute/virtualMachines
Azure 门户中的 Azure Arc 服务器
Azure 门户( https://portal.azure.com )是 JSON 模板元素的图形化视图，这些模板元素定义了 Azure 订阅中的资源组。如图 4-3 所示，你可以在你的 Azure 资源组中的导出模板刀片检查你的 Azure 门户中资源组的内容。您的 Azure Arc 服务器将与所有其他 Azure 资源类型一起包含在您的资源组中。
图 4-3
将整个资源组导出到 JSON 文档
当然，Azure 门户有一整套专用的 Azure Arc 视图，这些视图显示了 Azure Arc 基础设施资源，如服务器、Kubernetes 集群、SQL 服务器和 Azure Stack HCI 部署。图 4-4 显示了 Azure Arc 服务器页面，在这里可以找到您有权访问的所有订阅中的所有 Azure Arc 服务器。
图 4-4
Azure 门户中的 Azure Arc 服务器
如图 4-4 中视图的列所示，您可以根据状态(连接或离线)、位置(创建 Azure Arc 服务器资源的 Azure 区域)、操作系统(Linux 或 Windows)以及您可能在创建时或之后选择性分配的标签等参数进行排序和过滤。
此时你应该明白的是，Azure Arc 服务器是 Azure 控制平面中的一个逻辑构造。部署 Azure Arc 服务器的实际技术过程是创建一个“类型”Microsoft.HybridCompute/machines的 Azure 资源记录。要使用交互方法装载 Azure Arc 服务器，您需要以下这些东西:
-
有权创建 Azure Arc 资源的 Azure 订阅的登录凭据
-
适合您的组织的 Azure 订阅中的资源组，用于包含 Azure Arc 服务器资源
-
承载 Azure Arc 服务器对象的 Azure 区域(位置),该区域不必与资源组位于同一区域
Azure Arc 服务器位置选择
在大多数情况下，当您装载 Azure Arc 服务器时，您选择的位置应该是地理上离您的机器位置最近的 Azure 区域。以下是选择要使用的区域时的一些注意事项:
-
静态数据存储在包含您指定的区域的 Azure geography 中，如果您有数据驻留需求，这也可能会影响您对区域的选择。
-
如果您的计算机连接的 Azure 区域受到中断的影响，连接的计算机不会受到影响，但是使用 Azure 的管理操作可能无法完成。
在发生区域性中断的情况下，如果您有多个支持地理冗余服务的位置，最好将每个位置的 Azure Arc 服务器连接到不同的 Azure 区域。
Tip
Azure Arc 支持的服务器在一个资源组中支持多达 5，000 个机器实例。对于非常大的部署，规划多个资源组。
注册 Azure 资源提供者
启用 Azure Arc 的服务器依赖于订阅中的以下 Azure 资源提供者来使用服务:
-
微软。混合计算
-
微软。猜测配置
如果它们尚未注册，您可以使用以下命令注册它们:
Azure PowerShell
Login-AzAccount
Set-AzContext -SubscriptionId [subscription you want to onboard]
Register-AzResourceProvider -ProviderNamespace Microsoft.HybridCompute
Register-AzResourceProvider -ProviderNamespace Microsoft.GuestConfiguration
蓝色 CLI
az account set --subscription "{Your Subscription Name}"
az provider register --namespace 'Microsoft.HybridCompute'
az provider register --namespace 'Microsoft.GuestConfiguration'
您也可以在 Azure 门户中注册资源提供者，方法是按照 Azure 资源提供者和类型链接上的注册资源提供者 Azure 门户部分中的步骤:
https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/resource-providers-and-types#azure-portal
在你注册了两个指定的提供者之后，你的 Azure 订阅的资源提供者刀片应该如图 4-5 所示。
图 4-5
要在您的 Azure 订阅中注册的资源提供者，以创建支持 Azure Arc 的服务器
将 Azure Arc 连接到 Windows 和 Linux 服务器
安装 Azure Arc 代理可能是您需要安装的最后一个代理，因为通过 Azure Policy 和 Azure Arc，您可以管理您的混合计算机可能需要的所有当前和未来的管理和安全代理。“天蓝弧代理”被称为天蓝连机 代理。
在安装时，Azure Connected Machine Agent 需要使用 Azure AD 进行身份验证，以验证新的 Azure Arc 服务器已被授权与您的 Azure 订阅相关联。有两种方法可以做到这一点:
-
使用交互式脚本手动添加服务器。这适用于小型部署和测试。每次安装时，您都可以使用您的个人用户凭据登录 Azure。本章逐步介绍这种方法。
-
大规模添加服务器。此方法使用您在 Azure AD 中创建的 Azure 应用注册的身份和客户端密码(应用密码)。通过您喜欢的任何脚本或管理工具运行带开关的代理安装。在第 5 章“Azure Arc 服务器:大规模使用”中介绍
先决条件:使用交互式脚本添加 Azure Arc 服务器(Windows 和 Linux 计算机)
在尝试装载 Azure Arc 服务器之前，请注意以下参数:
-
需要服务器的本地管理员或 root 权限。
-
搭载 Azure Arc 服务器所需的最低内置 Azure 订阅安全角色是Azure Connected Machine on boarding。
-
请确保您已经对所有涉及的 Azure 订阅执行了本章“注册 Azure 资源提供者”一节中涵盖的过程。
-
确认要加入的服务器可以通过 TCP 443 端口访问互联网的以下 URL:
-
management.azure.com
-
login.windows.net
-
login.microsoftonline.com
-
dc.services.visualstudio.com
-
agentserviceapi.azure-automation.net
-
*-agent service-prod-1 . azure-automation . net
-
*.guestconfiguration.azure.com
-
*.his.arc.azure.com
-
*.blob.core.windows.net
-
azgn*.servicebus.windows.net
-
pas.windows.net
-
逐步:使用交互式脚本添加 Azure Arc Windows 服务器
图 4-6
将内部和其他云中的服务器连接到 Azure 有两种主要方式
-
在你的 Azure 门户中，点击新建并选择 Azure Arc for servers ，然后点击创建。
-
在图 4-6 中的选择方法页，点击生成脚本。
图 4-7
Azure 门户将自动生成一个自定义脚本，将计算机装载到 Azure Arc 上
- 输入适合您环境的资源详细信息和标签，然后点击下载并运行脚本以到达如图 4-7 所示的刀片。
图 4-8
使用 onboarding 脚本手动安装 Azure Arc 代理的三个步骤
- 下载脚本(OnboardingScript.ps1)并将其复制到要添加到 Azure Arc 的服务器。
-
在提升的 PowerShell 会话中运行脚本。注意脚本输出的代码。
-
打开网页浏览器进入
https://microsoft.com/devicelogin。 -
在您的租户中使用 Azure AD 凭据登录，并输入如图 4-8 所示的代码。
-
请注意图 4-8 中的脚本会将AzureConnectedMachineAgentWindows Installer 包下载到您执行脚本的文件夹中。日志文件 installationlog 也在同一位置创建。(在给定代码过期之前，您有有限的时间使用该代码完成登录。)
图 4-9
Azure Connected Machine Agent 文件夹和服务的拆卸
-
安装代理后，您会发现Azure Connected Machine Agent列在添加/删除程序中，如图 4-9 所示。
-
代理文件位于 C:\ Program Files \ AzureConnectedMachineAgent。
-
创建了两个 Windows 服务:
-
客户配置 Arc 服务 (GCArcService):该服务监控机器的期望状态。
-
客户配置扩展服务 (ExtensionService):该服务安装请求的扩展。
-
-
-
安装 Azure Arc 代理后，您可以打开您的 Azure 门户来查看新的混合计算机对象:
https://portal.azure.com/#blade/HubsExtension/BrowseResource/resourceType/Microsoft.HybridCompute%2Fmachines
图 4-10 显示了添加 Azure Arc 服务器后你可能很快会看到什么。如果您在创建时为 Azure Arc 服务器指定了标签，您会在 Overview blade 上看到它们。您也可以通过点击更改链接手动添加标签，或者在 Azure Arc 服务器生命周期中的任何时候以编程方式添加标签。我们将在第六章的“混合服务器监控解决方案”中讨论标签的高级使用
图 4-10
Windows Azure Arc 服务器的概述
逐步:使用交互式脚本添加 Azure Arc Linux 服务器
使用手动方法连接 Linux 服务器的过程与连接 Windows 服务器的过程非常相似。您必须遵守本章前面的“先决条件:使用交互式脚本添加 Azure Arc 服务器(Windows 和 Linux 计算机)”一节。
图 4-11
自动生成的定制 Bash 脚本将 Linux 计算机装载到 Azure Arc 上
-
在你的 Azure 门户中，点击新建并选择 Azure Arc for servers ，然后点击创建。
-
在选择方法页(之前参见图 4-6 ，点击生成脚本。
-
输入适合您环境的资源详细信息和标签，然后点击下载并运行脚本以到达如图 4-11 所示的刀片。
图 4-12
手动将 Linux 计算机加入 Azure Arc
-
下载脚本(OnboardingScript.sh)并将其复制到要添加到 Azure Arc 的 Linux 计算机上。(使用 WinSCP 等任何方便的工具；在
https://winscp.net下载。)sudo chmod 700 OnboardingScript.shsudo ./OnboardingScript.sh-
通过运行以下命令启用要执行的脚本:
-
使用提升的权限运行脚本，如下所示:
-
在脚本运行接近完成时，注意脚本打印出一个设备登录代码，如图 4-12 所示。
-
图 4-13
Azure Connected Machine 代理的设备登录
-
打开网页浏览器进入
https://microsoft.com/devicelogin。web 浏览器会话可以发生在任何计算机上；它不需要从板载的 Linux 计算机上运行。 -
在您的租户中使用 Azure AD 凭据登录，如图 4-13 的上部所示。
将出现一个类似图 4-8 中 Windows 代理启动时看到的输入代码页。输入密码后，您会收到一条确认信息，如图 4-13 的下部所示。当您看到这个消息时，脚本将会提示您查看您的板载服务器；导航到
图 4-14
确认所有 Azure Arc 守护程序正在运行
-
安装代理后，将应用以下配置更改:
-
代理文件位于
-
/var/opt/azcmagent(支持文件)
-
/var/lib/GuestConfig。(来自 Azure 的应用策略)
-
/opt/azcmagent(hima dsd . service files)
-
/opt/GC_Ext，(来宾配置代理文件和下载的扩展文件)
-
/opt/DSC(常见的 DSC 工件)
-
-
创建了三个 Linux 守护进程:
-
Azure Connected Machine Agent 服务 (himdsd.service):该服务实现了 Azure 实例元数据服务(IMDS)来管理与 Azure 的连接以及连接机器的 Azure Arc 身份。
-
GC Arc 服务 (gcad.service):监控机器的期望状态配置。
-
扩展服务 (extd.service):针对机器安装所需的扩展。
-
-
-
您可以使用该命令检查服务守护程序是否正在运行，如图 4-14 :
systemctl -list-units | grep <service name>所示
图 4-15
刚加入后的 Linux Azure Arc 服务器概述
- 安装 Azure Arc 代理后，您可以在 Azure 门户中查看新的混合计算机对象，如图 4-15 所示。
管理和使用 Azure VM 扩展
Azure 虚拟机(VM)扩展是在 Azure VMs 上提供部署后配置和自动化任务的小型应用。例如，如果虚拟机需要安装软件或在其中运行脚本，可以使用 VM 扩展来代替传统的配置管理工具。
扩展本质上是一个“带外”(OOB)管理通信通道，使用期望状态配置(DSC)技术创建，可与 Azure 虚拟机和 Azure Arc 服务器同等工作。一个诞生于超大规模 Azure 云中的通信通道，现在通过 Azure Arc 扩展到 Azure 之外的服务器。
在您的计算机管理任务中尽可能使用扩展是一种力量倍增器。传统上，在云和内部环境中跨 Linux 和 Windows 服务器部署和审核软件需要多种管理工具。现在，有了支持 Azure Arc 的服务器和 Azure 虚拟机，混合机器生命周期的管理得到了简化。
每当在 Azure VM 或 Azure Arc 服务器中安装一个扩展时，就会在 Azure 资源组中创建一个隐藏资源类型—，它是计算机对象—的子对象，如下所示:
- Azure Arc 服务器扩展资源类型:
Microsoft.HybridCompute/machines/extensions
- Azure VM 扩展资源类型:
微软。计算/虚拟机器/扩展
扩展对象表示该计算机上该扩展的所需状态配置。在选择了 Show hidden types 选项的情况下查看资源组中的所有资源将会显示您已经部署的扩展。扩展补充和扩展了 Azure 资源管理器框架，基础设施运行在该框架上，这实际上是服务管理功能向平台服务的教科书式迁移。
在图 4-16 中，您可以看到微软的新方法——即跨平台配置扩展—如何实现跨您的资产的同质管理。
图 4-16
扩展是资源组中隐藏的资源类型
就业务价值而言，该模型意味着您可以通过一致的控制点和可重复的流程来加速计算机管理中固有的添加/删除/更改流程。有几种方法可以自动地大规模利用扩展；我们将在接下来讨论这些。
Azure VM 扩展的用例
以下是一些可用的 Azure VM 扩展的具体用例，它们为支持 Azure Arc 的服务器提供了关键优势:
-
DSC VM 扩展:使用 Azure Automation 状态配置集中存储配置，维护 Azure Arc 服务器的期望状态。例如，在计算机上实施标准功能部署，如 IIS 或 DNS 服务。
-
日志分析代理 VM 扩展:使用 Azure Monitor 和 Microsoft Sentinel 中的日志收集日志数据进行分析。这有助于对不同来源的数据进行复杂的分析。
-
Azure Monitor for VMs: 分析您的 Windows 和 Linux 虚拟机的性能，并监控它们的进程以及对其他资源和外部进程的依赖。这是通过启用日志分析代理和依赖关系代理虚拟机扩展来实现的。
-
自定义脚本扩展:在混合连接的机器上下载并执行脚本。该扩展对于部署后配置、软件安装或任何其他配置或管理任务非常有用。考虑在所有服务器创建后立即安装反恶意软件或其他安全代理。
您可以通过以下链接了解每个扩展的详细信息，并找到当前可用扩展的完整列表:
-
发现 Windows 虚拟机扩展
-
发现 Linux 的虚拟机扩展
https://docs.microsoft.com/en-us/azure/virtual-machines/extensions/features-windows
https://docs.microsoft.com/en-us/azure/virtual-machines/extensions/features-linux
管理 Azure VM 扩展的方法
即使它们影响许多地方的机器，扩展只存在于 Azure 控制平面中，所以它们很容易使用，并且可以在任何可以访问 Azure 的地方执行。有五种方法可用于部署和管理 Azure VM 扩展，所有方法都适用于所有 Azure VM 和 Azure Arc 服务器，包括 Windows 和 Linux。这些方法是 Azure 门户、Azure PowerShell、Azure CLI、ARM 模板和 Azure 策略。
方法 Azure 门户中的扩展
在单个 Azure Arc 服务器上使用扩展的一个简单快捷的方法是在 Azure 门户中 Azure Arc 服务器页面的扩展刀片上。图 4-17 显示了一个使用 VM 扩展连接到 Azure Log Analytics 的典型 Azure Arc 服务器。
图 4-17
添加到 Azure Arc 服务器的 Azure VM 扩展
为了帮助你理解 Azure Arc 和 Azure VM 扩展在 Azure Arc 服务器上的净效果，请看图 4-18 ，图 4-17 中 Azure Arc 服务器“Luther”内部的控制面板➤程序和功能小程序。
图 4-18
扩展是资源组中隐藏的资源类型
图 4-18 展示了 Azure VM 扩展(添加在 Azure 资源管理器控制平面中)如何影响存在于 Azure 之外的 Azure Arc 服务器。这台服务器的所有者需要安装的唯一软件是 Azure Arc 代理( Azure Connected Machine 代理)。随后，微软管理代理(MMA)及其依赖代理的扩展也安装了这些软件——安装工作由 Azure 资源管理器支持的 Azure Arc 自动完成。
导航到 Azure Arc 服务器的扩展页面的原因包括仔细检查特定的扩展是否按预期安装，或者手动安装或卸载扩展。如果点击计算机扩展页面上的添加按钮(如图 4-17 ，会提供一个可供手动安装的扩展列表，如图 4-19 。
图 4-19
从 Azure 门户在 Azure Arc 服务器上手动安装新的 Azure VM 扩展
Tip
Azure 门户只公开了可用 Azure VM 扩展的子集，这些扩展也可以与 Azure Arc 服务器一起工作。其他还有 Azure Key Vault VM 扩展、基于扩展的用户混合 Runbook Worker、和 Azure Defender 集成扫描器可以通过 ARM 模板安装。
或者，点击一个已安装扩展的名称(同样在图 4-17 中)将打开该扩展的详细信息页面，带有一个卸载按钮，如图 4-20 所示。如果您在正确安装特定扩展时遇到问题，您可以从这里卸载失败的扩展，并让 Azure Arc 再次尝试添加该扩展。
图 4-20
每个已安装的 Azure VM 扩展在其详细信息页面上都有一个卸载按钮
方法 2:使用 Azure PowerShell 的扩展
Azure PowerShell 命令可以从任何安装了 Azure PowerShell 的计算机上运行，也可以从 Azure 门户中的 Azure Cloud Shell 上运行。无论哪种情况，都需要添加 Az。使用以下 cmdlet 将 Machine 模块连接到 PowerShell 实例:
Install-Module -Name Az.ConnectedMachine
将该模块一次性安装到 PowerShell 或 Cloud Shell 实例后，您可以运行以下 PowerShell 命令来列出、添加和删除扩展:
Get-AzConnectedMachineExtension -ResourceGroupName <rgname> -MachineName <machineName>
New-AzConnectedMachineExtension -Name <extensionName> -ResourceGroupName <rgname> -MachineName <machineName> -Location <location> -Publisher <publisher> -ExtensionType <extensionType> -Settings <settings>
Remove-AzConnectedMachineExtension -MachineName <machineName> -ResourceGroupName <rgname> -Name <extensionName>
图 4-21 演示了在 Azure 云 Shell 中使用 PowerShell 来列出 Azure Arc 服务器上已安装的 Azure VM 扩展。请注意，这与图 4-17 中 Azure 门户中看到的数据相同。
图 4-21
列出安装在带有 Azure PowerShell 的 Windows Azure Arc 服务器中的 Azure VM 扩展
方法 3:使用 Azure CLI 的扩展
Azure CLI 可安装在 Windows、macOS 和 Linux 环境中。也可以在 Docker 容器和 Azure 云壳中运行。在所有场景中，就像 PowerShell 的情况一样，在 Azure Arc 服务器上使用 Azure CLI 之前，需要安装一个模块。命令是
az extension add --name connectedmachine
将该模块一次性安装到您的 Azure CLI 或云外壳实例后，您可以运行如下命令来列出、添加和删除扩展:
az connectedmachine extension list --machine-name "myMachineName" --resource-group "myResourceGroup"
az connectedmachine extension create --machine-name "myMachineName" --name "OmsAgentForLinux or MicrosoftMonitoringAgent" --location "eastus" --settings '{\"workspaceId\":\"myWorkspaceId\"}' --protected-settings '{\"workspaceKey\":\"myWorkspaceKey\"}' --resource-group "myResourceGroup" --type-handler-version "1.13" --type "OmsAgentForLinux or MicrosoftMonitoringAgent" --publisher "Microsoft.EnterpriseCloud.Monitoring"
az connectedmachine extension delete --machine-name "myMachineName" --name "OmsAgentForLinux" --resource-group "myResourceGroup"
如果你没有 Azure CLI 的本地安装，在 Azure Cloud Shell Bash 环境中运行这些命令的快捷方式如图 4-22 所示。
图 4-22
使用 Azure CLI 列出安装在 Linux Azure Arc 服务器上的 Azure VM 扩展
方法 4:作为 ARM 模板的扩展
当您为新的 Azure Arc 服务器使用基于模板的部署和供应工具时，这是一个值得考虑的好方法。Microsoft 已在此链接中发布了模板文件和参数文件，并提供了扩展的示例值，如下所示:
https://docs.microsoft.com/en-us/azure/azure-arc/servers/manage-vm-extensions
适用于 Windows 和 Linux Azure Arc 计算机的 ARM 模板可用于以下扩展:
-
日志分析虚拟机扩展
-
自定义脚本扩展
-
PowerShell DSC 扩展
-
依赖代理扩展
-
Azure Key Vault 虚拟机扩展
-
Microsoft Defender for Cloud 集成漏洞扫描器
-
Azure Automation 混合 Runbook Worker 扩展
方法 5:使用 Azure 策略部署扩展
虽然列在最后，但这是管理扩展的最佳方法，因为使用 Azure Policy 可以在一个管理操作中实现部署、合规性和云规模。Azure 策略适用于新的和现有的计算机。尽管之前使用扩展的任何方法都有其用例，但 Azure Policy 是最有可能将 Azure VM 扩展部署到 Azure Arc 服务器的方法。
得益于 Azure Arc，Azure 策略和捆绑策略集的计划可以应用于全球范围的异构计算机。Azure Policy 的内置合规性和补救功能是实现任何给定扩展的技术目标的路线图和工具集。
例如，使用这种方法，您可以将内置的 Azure PolicyDeploy Log Analytics agent 分配给 Linux 或 Windows Azure Arc machines (见图 4-23 )来审计启用 Arc 的服务器是否安装了日志分析代理。如果代理未安装，该策略可以创建预定义的补救任务，以通过 Azure 资源部署作业自动安装代理。
图 4-23
将日志分析代理部署到 Windows Azure Arc 计算机的内置 Azure 策略
值得注意的是，Azure Policy 通过查看适当的 Azure VM 扩展是否成功安装在 Azure Arc 服务器对象上来间接进行检查，而不是通过与计算机本身进行交互。考虑在 Azure Arc 的架构中，所需配置的成功状态的证明被委托给一个较低且高度分布式的级别——混合计算机本身上的 DSC 代理。这有效地让 Azure Resource Manager 在评估策略合规性时只承担检查状态值的轻量级任务。
Microsoft 建议使用 Azure 策略安装用于 Windows 或 Linux 的日志分析代理。我们将在第六章“混合服务器监控解决方案”中详细介绍这种方法
摘要
在这一章中，你深入地学习了什么是 Azure Arc 服务器，并了解了手动部署和扩展管理的概念。您还了解了 Azure Arc 服务器如何通过 Azure Resource Manager 与 Azure 控制平面进行交互。现在你已经理解了使用 Azure Arc 服务器的基础，在下一章，你将学习如何大规模部署和管理 Azure Arc 服务器。我们还将介绍更高级的 Azure Arc 特性，如标签和仪表板，以及在所有场景中对 Azure Arc 服务器进行故障排除。
五、Azure Arc 服务器：大规模使用
当您使用 Azure Arc 来管理可能不存在于云中的本地服务器时，您可以有效地将云服务管理的基本特征扩展到非云资源。这意味着，从业务支持、供应/配置和可移植性/互操作性的角度来看，您的所有服务器都可以分享云消费者享受的规模经济优势。本章将帮助你在生产中使用 Azure Arc，从这些角度实现最大的好处。
第四章“Azure Arc 服务器:入门”介绍了一次安装一个 Azure Arc 代理，以便用交互方法进行测试和评估，而本章继续使用服务主体大规模部署 Azure Arc 服务器。第四章还包括了 Azure VM 扩展如何与 Azure Arc 服务器协同工作来执行部署后配置和自动化任务的细节，所有这些都同样适用于大规模使用 Azure Arc 服务器的扩展。
本章通过讲述如何在 Azure Arc 服务器上使用标签以及如何创作 Azure Monitor 工作簿来增加你的 Azure Arc 技能，这些工作簿可以作为你的混合资产中所有服务器的仪表板。最后，我们总结了在 Windows 和 Linux 服务器上使用 Azure Arc 的一般故障排除技巧。
为入职创建服务主体
要将非 Azure 计算机作为启用 Azure Arc 的服务器连接到 Azure，您可以使用 Azure Active Directory 服务主体，而不是使用特权用户身份来交互连接计算机，就像我们在第四章“Azure Arc 服务器:入门”中所做的那样使用这种方法，具有提升权限的管理员或用户需要登录(或使用 PowerShell remoting)每台要管理的计算机，并以交互方式连接到服务器。
回想一下，安装 Azure Arc 代理需要安装程序对 Azure 订阅具有写访问权限，以便创建特定 Azure 订阅、资源组和位置中存在的“类型”Microsoft.HybridCompute/machines的 Azure 资源管理器(ARM)资源。安装程序可以是人，也可以是安全主体而不是人。在大规模应用中，您需要一个不需要人工参与的流程，您需要一个可以通过自动化或脚本化轻松无限重复的流程。
一个服务主体是一个特殊的有限管理身份(一个“Azure 服务帐户”)，它被授予使用 azcmagent 命令将机器连接到 Azure 所需的最低权限。这比使用像全局管理员这样的特权更高的帐户更安全，并且符合微软访问控制安全最佳实践。服务主体在入职和离职期间使用；它不用于任何其他目的。Azure Connected Machine on boarding是一个预定义的 Azure 访问角色，足以搭载 Azure Arc 服务器。
安装和配置 Connected Machine (Azure Arc)代理的安装方法确实要求您使用的自动化方法(如通过编写脚本)在要注册的目标计算机上具有提升的权限。在 Linux 上，使用 root 帐户；在 Windows 上，作为本地管理员组的成员。
使用 PowerShell 创建服务主体
使用 Azure PowerShell 创建您的服务主体非常简单；以下是要输入的命令:
$sp = New-AzADServicePrincipal -DisplayName "Arc-for-servers" -Role "Azure Connected Machine Onboarding"
$sp
$credential = New-Object pscredential -ArgumentList "temp", $sp.Secret
$credential.GetNetworkCredential().password
图 5-1 展示了它在 Azure Cloud Shell 中运行的样子。您正在使用这些命令执行三个操作:
图 5-1
使用 PowerShell 创建 Azure Arc onboarding 服务主体
-
创建名为 Arc-for-servers 的企业应用
-
在你的 Azure 订阅中为应用分配 Azure Connecting Machine on boarding 角色
-
创建仅可见一次的秘密密码
运行完这些命令后，将结果复制并粘贴到要保存的文件中，这一点非常重要。稍后您将需要应用 Id 和密码来编辑用于大规模入职的脚本。
使用 Azure 门户创建服务主体
如果您愿意，可以使用 Azure 门户创建您的服务主体；在此链接的向 Azure AD 注册应用并创建服务主体和向应用分配角色部分中有详细步骤:
使用与 PowerShell 演示相同的设置，将应用命名为“Arc-for-servers”，创建一个新的客户端密码，并在您的 Azure 订阅中为应用分配角色Azure Connected Machine on boarding。记下如图 5-2 所示的应用(客户端)ID，并保留为我们接下来将创建的入职脚本创建的密码。
图 5-2
使用 Azure 门户创建 Azure Arc onboarding 服务主体
将 Azure Arc 大规模连接到 Windows 服务器
创建了 Azure AD 服务主体，分配了 Azure 订阅权限，并且有了服务主体密码，您就可以使用脚本向 Azure 添加多个服务器了。当然，第 4“Azure Arc 服务器:入门”一章中关于交互式入职的先决条件的所有内容也适用于大规模入职。特别要确保微软。HybridCompute 和微软。GuestConfiguration Azure 资源提供商已在您的 Azure 订阅中注册。
循序渐进:大规模添加 Azure Arc Windows 服务器
图 5-3
开始体验大规模板载服务器
-
在你的 Azure 门户中，点击新建并选择 Azure Arc for servers ，然后点击创建。
-
在图 5-3 中的选择方法页，在添加多个服务器下，点击生成脚本。
图 5-4
具有 Azure Connected Machine on boarding 角色的应用注册已列出，以供选择进行身份验证
-
阅读先决条件页面，然后单击下一步:资源详细信息。
-
输入适合您的环境的资源详细信息，然后单击 Next: Authentication 。
-
如图 5-4 所示，您之前创建的服务主体可供选择；然后点击下一步:标签。
如图 5-5 所示，资源标签可以选择性地与该脚本上的 Azure Arc 服务器相关联。
图 5-5
可选地为 Azure Arc 服务器分配标签。以后可以随时添加或更改标签
图 5-6
大规模入职脚本可供下载、编辑以添加密码，并在测试服务器上运行
- 输入需要的标签后，点击下一步:下载并运行脚本，进入如图 5-6 所示的下载脚本页面。
您也可以选择使用以下脚本格式手动创作入职脚本:
# OnboardingScript.ps1
# --------------------
# Download the package
function download() {$ProgressPreference="SilentlyContinue"; Invoke-WebRequest -Uri https://aka.ms/AzureConnectedMachineAgent -OutFile AzureConnectedMachineAgent.msi}
download
# Install the package
msiexec /i AzureConnectedMachineAgent.msi /l*v installationlog.txt /qn | Out-String
# Run connect command
& "$env:ProgramFiles\AzureConnectedMachineAgent\azcmagent.exe" connect `
--service-principal-id "{serviceprincipalAppID}" `
--service-principal-secret "{serviceprincipalPassword}" `
--resource-group "{ResourceGroupName}" `
--tenant-id "{tenantID}" `
--location "{resourceLocation}" `
--subscription-id "{subscriptionID}"
Tips on running OnboardingScript.ps1: (applies to Windows and Linux)
-
该脚本可以装载在多台服务器上。Azure Arc 服务器将被分配到相同的订阅、资源组和 Azure 区域。
-
从门户下载的脚本将不包含
$servicePrincipalSecret值；在运行下载的脚本之前，您需要手动添加服务主体密码。 -
该脚本必须以本地管理员(或 root)权限运行。
-
您可以使用模式
--tags "tag1name=tagvalue,'tag 2 name'='tag value'"修改标签来制作脚本的多个版本
图 5-7
在服务器上手动运行大规模入职脚本进行验证
- 虽然脚本可能在数百台服务器上运行，但谨慎的做法是至少在一台计算机上手动验证脚本。将脚本(OnboardingScript.ps1)复制到预期的 Azure Arc 服务器，并在提升的 PowerShell 会话中运行该脚本。图 5-7 显示了手动运行时规模入职脚本的输出。
安装 Azure Arc 代理后，您可以打开您的 Azure 门户来查看新的混合计算机对象:
https://portal.azure.com/#blade/HubsExtension/BrowseResource/resourceType/Microsoft.HybridCompute%2Fmachines
大规模运行 Azure Arc Windows Onboarding 脚本
当然，制作大规模入职脚本的主要原因是允许在大量计算机上远程自动运行脚本，而无需进一步的人工干预。网络管理员工具包中任何使用提升权限运行 PowerShell 脚本的方法都可以使用。考虑这些选项:
-
使用
Invoke-Commandcmdlet 进行一对多远程处理的 PowerShell 远程处理。 -
使用 Microsoft Endpoint Manager (MEM)，以前的 System Center Configuration Manager(SCCM)，将 PowerShell 脚本部署为应用或程序。
-
使用 Active Directory 组策略对象(GPO)将 PowerShell 脚本作为即时计划任务运行。
建议使用第三个选项，因为 GPO 计划任务方法允许您以管理员权限立即运行该脚本，并且该脚本只运行一次，因为每次组策略刷新时，它都会删除该任务。按照以下步骤将 Azure Arc Windows onboarding 脚本部署到您的 Active Directory (AD)域中的许多或所有服务器。
图 5-8
使用组策略创建立即计划任务
-
将 OnboardingScipt.ps1 文件复制到网络共享位置；在我们的例子中，我们将使用域“sysvol”脚本文件夹:
%LOGONSERVER%\sysvol\%USERDNSDOMAIN%\scripts\OnboardingScript.ps1 -
打开组策略管理控制台(GPMC)并导航到 AD 林中包含要加载到 Azure Arc server 的系统的位置。右键单击并选择“在此域中创建一个 GPO，并在此链接它。”出现提示时，指定名称 Install Azure Arc Agent 。
-
右键单击新 GPO 并选择编辑。导航到计算机配置➤首选项➤控制面板设置➤计划任务，然后右键单击并选择新➤即时任务(至少 Windows 7)，如图 5-8 所示。
图 5-9
配置新任务的常规选项卡
-
在新任务的“常规”选项卡上，将操作设置为“创建”,输入名称“立即任务”以安装 Azure Arc 代理，将用户帐户更改为“系统”,选择“无论用户是否登录都运行”,以最高权限运行，并配置为 Windows 7、Windows Server 2008 R2，如图 5-9 所示。
-
转到新任务的“操作”选项卡，输入以下信息:
-
Action = "启动程序"
-
程序/脚本=
C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe -
添加参数(可选)=
-ExecutionPolicy Bypass -command "& \\SERVER\SHARE\OnboardingScript.ps1"(用您在环境中使用的名称替换 SERVER 和 SHARE)
-
-
最后，转到通用选项卡，选择应用一次，不要再次应用选项。
-
保存新任务，Azure Arc 代理将在下一个组策略刷新间隔(每 90 分钟一次，随机偏移量最长为 30 分钟)安装在 GPO 应用的计算机上。
将 Azure Arc 大规模连接到 Linux 服务器
为了大规模部署 Linux 服务器，您将使用为大规模部署 Windows 服务器而开发的相同 Azure 广告服务主体和加密密码。大规模连接 Linux 服务器的过程与大规模连接 Windows 服务器的过程非常相似。
循序渐进:大规模添加 Azure Arc Linux 服务器
您必须遵守第 4“Azure Arc 服务器:入门”一章中的“先决条件:使用交互式脚本添加 Azure Arc 服务器(Windows 和 Linux 计算机)”一节
图 5-10
自动生成的定制 bash 脚本使用服务主体将 Linux 计算机装载到 Azure Arc
-
在你的 Azure 门户中，点击新建并选择 Azure Arc for servers ，然后点击创建。
-
在前面图 5-3 中看到的选择一种方法刀片，在添加多个服务器下，点击生成脚本。
-
阅读先决条件页面，然后单击下一步:资源详细信息。
-
输入适合您的环境的资源详细信息，将操作系统设置为 Linux ，然后单击下一步:认证。
-
如前图 5-4 所示，您之前创建的服务主体可供选择；然后点击下一步:标签。
-
输入需要的标签后，点击下一步:下载并运行脚本，进入如图 5-10 所示的下载脚本页面。
以下是手动创作 Linux 大规模入职脚本的格式:
- 此时，您的 bash 脚本已经准备好在一台试验计算机上进行测试，然后使用各种 Linux 软件管理技术进行大规模部署。
# OnboardingScript.sh
# --------------------
# Download the installation package
wget https://aka.ms/azcmagent -O ~/install_linux_azcmagent.sh
# Install the hybrid agent
bash ~/install_linux_azcmagent.sh
# Run connect command
azcmagent connect \
--service-principal-id "{serviceprincipalAppID}" \
--service-principal-secret "{serviceprincipalPassword}" \
--resource-group "{ResourceGroupName}" \
--tenant-id "{tenantID}" \
--location "{resourceLocation}" \
--subscription-id "{subscriptionID}"
大规模运行 Azure Arc Linux Onboarding 脚本
流行的开源配置管理软件可能正在您的 Linux 环境中使用，如 Chef 或 Puppet ，这些工具非常适合部署您的 Azure Arc at-scale onboarding 脚本。作为远程部署 onboarding 脚本的简化演练，考虑使用 Linux 内置 ssh 命令的这些步骤:
图 5-11
生成用于远程运行脚本的 ssh 密钥对
-
将 onboarding 脚本复制到您的 Linux 管理计算机上，并通过运行以下命令来执行该脚本:
sudo chmod 700 OnboardingScript.sh -
使用 ssh-keygen 实用程序生成一个公钥-私钥对(参见图 5-11 作为示例)。每次出现提示时，按回车键即可。
ssh-keygen -t rsa -
接下来，将公钥添加到您想要在 Azure Arc 中注册的远程主机上的
~/.ssh/authorized_keys文件:ssh-copy-id -i ~/.ssh/id_rsa.pub <username>@<host> -
现在，您可以从管理计算机上执行远程主机上的 SSH 命令，而无需输入密码。以下单个命令行将(1)将脚本从管理计算机复制到目标计算机，(2)运行 onboarding 脚本，以及(3)删除脚本的远程副本。
scp OnboardingScript.sh <host>:/tmp/ && ssh -t <user>@<host> "sudo -s bash /tmp/OnboardingScript.sh" && ssh -t <user>@<host> "rm /tmp/OnboardingScript.sh"
在脚本运行完成时，注意脚本打印出一个信息通知，表明入职已完成，如图 5-12 所示。
图 5-12
将 Linux 计算机远程部署到 Azure Arc
从 Windows 管理中心将计算机连接到 Azure Arc
微软提供了一种使用 Windows 管理中心装载 Azure Arc 服务器的方法。Windows 管理中心是一款本地部署的基于浏览器的应用，用于管理 Windows 服务器、集群、超融合基础设施以及 Windows 10 电脑。这是一款自 2019 年起正式上市(GA)的免费产品，已经被许多组织用于生产。您可以在环境中的计算机上安装该产品，然后登录该计算机上的 web 门户，与 Windows 管理中心进行交互。门户为服务器管理的几乎每个方面提供控制。对于使用 PowerShell 和/或单独的基于 GUI 的管理工具进行服务器管理来说，这是一种可行的、甚至是聪明的替代方法。表 5-1 列出了 Windows 管理中心整合的 27 个具体管理工具。
表 5-1
Windows 管理中心中包含的服务器管理功能
|Azure 混合服务
|
防火墙
|
角色和功能
|
| --- | --- | --- |
| Azure 备份 | 安装的应用 | 计划任务 |
| Azure 文件同步 | 本地用户和组 | 服务 |
| 天蓝色监视器 | 网络 | 仓库 |
| Azure 安全中心 | 性能监控器 | 存储迁移服务 |
| 证书 | 管理员 | 存储副本 |
| 设备 | 处理 | 系统洞察 |
| 事件 | 登记处 | 设置:环境变量 |
| 文件和文件共享 | 远程桌面 | 设置:电源配置 |
微软继续投资 Windows 管理中心，并指导 Windows Server 2022 的客户将 Windows 管理中心视为服务器管理的主要方法。如果您已经在使用 Windows 管理中心，或者正在等待在您的环境中部署它的用例，请考虑您可以将其用于 Azure Arc server onboarding。在某些方面，Windows 管理中心是大规模加入 Azure Arc server 的简化方法。以下是这种方法的“利弊”考虑因素的简短列表:
Azure Arc 优点:Windows 管理中心
-
它不需要也不使用服务主体。
-
它不需要使用脚本来进行入职培训。
-
Windows 管理中心本身易于安装和使用。
Azure Arc 缺点:Windows 管理中心
-
一次装载一台服务器。
-
被授权将服务器装载到您的 Azure 订阅的用户必须登录。
-
您不能在创建服务器时将标签分配给 Azure Arc 服务器。
该解决方案以与第四章“Azure Arc 服务器:入门”中详述的交互式脚本方法相同的方式使用已登录用户的 Azure 凭据不同之处在于，用户不需要复制设备代码并单独登录来验证他们的 Azure 用户身份(在交互式脚本方法中会发生这种情况)。
使用 Windows 管理中心将服务器装载到 Azure Arc 的其他注意事项包括:
-
搭载 Azure Arc 服务器所需的最低内置 Azure 订阅安全角色是Azure Connected Machine on boarding。登录到 Windows 管理中心控制台的用户必须在您的 Azure 订阅中拥有此权限。(要删除机器，用户需要Azure Connected Machine Resource Administrator角色。)
-
虽然将 Windows 管理中心实例连接到 Azure 订阅确实会创建 Azure AD 应用注册(服务主体)，通常命名为Windows Admin Center-https://
， 该服务主体不会用于 Azure Arc onboarding 操作。 -
您不能选择使用预先创建的 Azure Arc 服务主体来启动服务器，如本章的“为启动创建服务主体”一节中所述。
-
确保微软。HybridCompute 和微软。GuestConfiguration 在尝试使用 Windows 管理中心加载 Azure Arc 服务器之前，Azure 资源提供程序已在您的 Azure 订阅中注册。
逐步:使用 Windows 管理中心添加 Azure Arc 服务器
此过程假设您已经在环境中的服务器上安装了 Windows 管理中心，并且至少连接了一个您希望加载到 Azure Arc 的服务器。
图 5-13
Windows 管理中心连接的服务器的设置页面
-
登录 Windows 管理中心。
-
在概览页面的所有连接列表中，在已连接的 Windows 服务器列表中，从列表中选择一台服务器进行连接。
-
从左侧窗格中，选择设置。
-
在设置页面中，选择Azure Arc for servers；点击开始。
-
在 Windows 管理中心 blade 的 Azure 入门中，点击复制按钮，如图 5-13 所示。
图 5-14
在 Windows 管理中心控制台中部署 Azure Arc 服务器之前的最后一步
-
点击输入代码链接，在打开的网页中粘贴代码。
-
出现提示时，选择有权限将 Azure Arc 服务器添加到您的订阅的 Azure 登录身份。
-
关闭登录 Azure 页面，您会发现连接到 Azure Active Directory 步骤填充了一个或多个 Azure Active Directory 租户 id。从下拉列表中选择您的租户，选中 Create new 单选按钮，点击 Connect 。
-
点击按钮中的标志。当请求权限对话框出现时，点击接受按钮。
-
返回到服务器刀片的 Azure Arc，再次点击开始按钮。
-
在Connect server to Azureblade，选择想要创建 Azure Arc 服务器的 Azure 订阅、资源组和 Azure 区域，点击设置按钮，如图 5-14 所示。
-
您将看到一个 Windows 管理中心任务“为服务器设置 Azure Arc ”,该任务将运行几分钟。
-
When Azure Arc for server is set up for a connected server in Windows Admin Center, you will see a view like Figure 5-14 with shortcuts to these items:
图 5-15
Azure Arc 用于与 Windows 管理中心集成的服务器
-
在 Azure 中查看此服务器在 Azure 门户中为连接的服务器打开 Azure Arc 服务器页面。
-
此服务器连接到链接打开 Azure 门户中的资源组页面，Azure Arc 服务器是该页面的成员。
-
从 Azure 订阅中删除 Azure Arc 服务器对象的 Disconnect 服务器按钮。
-
到 Azure Policy 和 Azure Monitor 搜索日志的链接。
-
要板载后续服务器，不需要重复步骤 1 到 9；事实上，你可以从步骤 10 开始:从一个连接的服务器的设置刀片，打开 Azure Arc for servers 项，点击开始按钮。对所有要装载到 Azure Arc 的服务器重复步骤 10 和 11。
在 Azure Arc 服务器上使用标签
当混合机器连接到 Azure 时，它就变成了一台连接的机器，并受益于标准的 Azure 构造，如 Azure 策略和应用标签。使用 Azure 作为管理引擎来轻松组织和管理服务器库存的能力大大降低了管理复杂性，并为混合和多云环境提供了一致的策略。在 Azure Arc 服务器上应用和使用标签是你的组织的力量倍增器。图 5-16 提示了标签如何出现在任何给定 Azure Arc 服务器的 Azure portal 概览页面中。
图 5-16
应用于 Azure Arc 服务器的 Azure 资源标签
用标签增加商业价值
最好的标记方案包括与业务一致的焦点，例如会计、业务所有权和业务关键程度，它们反映了业务利益并随着时间的推移保持这些标准。投资于标记系统可为整体业务提供更好的 IT 资产成本和价值核算。资产的业务价值与其运营成本之间的这种关联，是在更广泛的组织内改变成本中心对 IT 的看法的一项关键活动。
组织基于云的资源对 IT 来说是一项至关重要的任务，除非您只有简单的部署。这里有一些标签标准，可以考虑用来组织你的资源，有标签对的例子，因为它们可能应用于 Azure Arc 服务器的管理:
-
资源管理:
City/Bellevue, Datacenter/West-Campus -
成本管理和优化:
Department/Marketing, Promotion/Spring2020 -
运营管理:
Vendor/Dell, Network/HQ-LAN-A -
安全性:
Owner/Jill.Smith@company.com, JIT enabled/Yes -
治理和法规遵从性:
HIPAA HITRUST/Yes, ISO 27001/Yes -
自动化:
Backup Policy/DailyFull-LRS-Retain365days, Patching Group/Wave2-West -
工作负载优化:
Shutdown allowed/Weekend-Holiday, Shutdown allowed/Weeknight-Weekend-Holiday
图 5-17 提供了开始使用标签的建议，这是你的 Azure 门户中可用的标签页面。请注意，左栏列出了在 Azure 订阅的资源上找到的所有标记名称/值对。点击左边的任何标签对，就会在右边调出具有相同标签名/值对的所有 Azure 资源的详细视图。
图 5-17
使用 Azure 门户中的标签窗格来探索标签关联
关于 Azure 资源标签的一切
-
标签是一种半随机的管理元数据，由人类和流程使用，以发出信号并相互交互。您或流程会留下一个标签，供其他人或流程读取，以帮助做出未来决策或选择自动操作。把它们想象成旗帜或标记。
-
Azure 资源标签有两个元素:标签名和标签值，就像
City/Bellevue。 -
每个 Azure Arc 服务器的每个名称都可以有一个标记(如“City”)，因此您只能将标记类型的一个值(如“Bellevue”)与每个服务器关联。换句话说，一台服务器上不能有两个城市标签，每个标签只能有一个值字段(比如城市名)。
-
Azure 记住了标签名称和标签值的范围。您可以预先创建标记名和值，以供用户在创建新资源时选择。Azure 还会记住订阅中已经存在的所有标签和值。为了避免标签泛滥，在头脑中有一个标签名称和值对计划，并帮助用户坚持它。
-
您可以构建管理产品和解决方案，如警报、查询、策略、报告和仪表板，这些产品和解决方案可以对标签进行排序和输入。首先，您为资源分配标签和值；然后，您制作寻找您已经部署的标签的管理工件。想想这个简单的例子:您的服务器管理员或配置过程向服务器添加了一个关于特定备份策略的标记。备份自动化扫描带有该标签的计算机，并自动应用正确的备份策略
—备份刚刚开始。只需添加一个标签。 -
使用 Azure 策略，你可以让 Azure 资源自动从它们的资源组继承标签。同样使用 Azure 策略，您可以强制特定标签的存在来执行操作任务。大型 Azure 地产通过政策和标签得到了良好的管理。Azure Arc 是您在整个资产中利用这种高级管理模式的机会，无论是在 Azure 中还是在非 Azure 中。
对启用 Azure Arc 的服务器应用清单标记
以下步骤将创建一个有用的服务器库存管理功能，演示如何在 Azure Arc 服务器上使用标签。请注意，我们正在创建有意义的标记值，这些值与我们的环境相匹配，并且我们打算用于我们的管理目的。(只创建将被使用的标签值，而不仅仅是“有就好。”)用您环境中存在的值替换供应商名称和虚拟化类型。
-
在您的 Azure 门户中打开 Azure CLI，并运行以下命令来创建基本分类，该分类允许您查询和报告您的 Azure Arc 服务器与哪种硬件或虚拟化平台相关联:
-
现在，您需要将标记名称/值对添加到订阅中的 Azure Arc 服务器。此 Azure PowerShell 为本地物理计算机增加了“服务器平台/戴尔主机”的价值:
az tag create --name "Server Platform"
az tag add-value --name "Server Platform" --value "HP Host"
az tag add-value --name "Server Platform" --value "Dell Host"
az tag add-value --name "Server Platform" --value "HV Guest"
az tag add-value --name "Server Platform" --value "ESX Guest"
$tag = @{"Server Platform"="Dell Host"}
$VM = Get-AzResource -ResourceGroupName RG-DEV-EUS -Name Venus
Set-AzResource -ResourceId $vm.Id -Tag $tag -Force
为每个 Azure Arc 服务器重新运行这组 PowerShell，适当地更改服务器平台标记。
- 在您将服务器平台标签应用到所有 Azure Arc 服务器之后，使用资源图浏览器来查询它们并深入了解您的云计算环境。在“查询”窗口中，输入以下查询:
Resources
| where type =~ 'Microsoft.HybridCompute/machines'
| where isnotempty(tags['Server Platform'])
| project name, location, resourceGroup, tags
Azure 资源图浏览器是 Azure 门户的一部分，支持直接在 Azure 门户中运行资源图查询。
图 5-18
Azure 资源图浏览器显示格式化的结果
- 点击运行查询，然后选择格式的结果切换。如图 5-18 所示，列出了所有支持 Azure Arc 的服务器及其分配的服务器平台标签值。您可以轻松地查询和报告服务器资源是如何托管的。例如，您可以将结果固定为一个图表，为您的门户工作流提供 Azure Arc 服务器的实时动态信息。
使用 Azure Monitor 工作簿的仪表板混合服务器数据
图表和图形等可视化工具可以帮助您分析监控数据，从而深入了解问题并识别模式。Azure Monitor 工作簿和仪表板允许您利用来自 Azure 的多个数据源，并将它们组合成单一控制台体验。
在 Azure Arc 服务器的情况下，我们可以利用这种能力来创建所有云中所有服务器的融合显示。按照以下步骤创建 Azure Monitor 工作簿，该工作簿具有真正的“所有服务器”视图:
-
从你的 Azure Log Analytics 工作区的工作簿刀片中，点击新建按钮。
-
点击新工作簿文本项下的编辑，可以选择更改标题和文本，例如“Azure Arc workbook”，然后点击完成编辑。
-
在编辑查询项:query -2 部分，将查询数据源更改为 Azure Resource Graph ，将可视化和大小更改为“Grid”和“Full”，粘贴该查询，如图 5-19 所示。点击 Run Query，观察 Azure 虚拟机和 Azure Arc 服务器都在网格中列出。
图 5-19
在 Azure Monitor 工作簿中嵌入 Azure 资源图表网格
resources
| where type == "microsoft.hybridcompute/machines" or type == "microsoft.compute/virtualmachines"
| mvexpand prop=properties.provisioningState
| project ComputerName = id, Status = properties.status, State=prop, location, resourceGroup, type, tags
图 5-20
混合资产可视化:Azure 虚拟机和 Azure Arc 服务器在一个列表中
-
单击高级设置选项卡，输入“所有服务器”作为图表标题，然后单击完成编辑。
-
单击工作簿顶部的完成编辑，然后单击保存图标。为工作簿命名，如“Azure Arc ”,然后单击保存按钮。
-
图 5-20 显示了到目前为止的工作簿，清晰地列出了 Azure 和其他云中的所有 Windows 和 Linux 服务器，包括它们的标签。单击“图钉”图标会将此工作簿保存到您所选的仪表板，在该仪表板上，您所有服务器资产的准确实时数据将始终可用。
-
让我们再增加一个可视化来演示 Azure 资源图和 Azure Monitor 工作簿的映射功能。单击工作簿最底部的添加查询按钮
-
在编辑查询项部分，将查询数据源更改为 Azure Resource Graph，将可视化和大小更改为“Map”和“Medium”，然后粘贴该查询。
图 5-21
混合资产映射:Azure 虚拟机和 Azure Arc 服务器的组合位置
- 点击运行查询并观察显示位于每个 Azure 区域的 Azure 虚拟机和 Azure Arc 服务器数量的世界地图(图 5-21 )。使用默认的“热图”拓扑，具有较高计数的站点具有较大的圆圈和较暖的颜色。
resources
| where type == "microsoft.hybridcompute/machines" or type == "microsoft.compute/virtualmachines"
| extend location
| summarize VMCount=count() by location
| order by VMCount desc
- 点击高级设置选项卡，输入“按地区服务器数”作为图表标题，然后点击完成编辑两次，然后点击保存图标。
Azure Arc 服务器状态疑难解答
Azure Arc 代理安装问题
Azure Arc 代理的维护成本非常低，安装和卸载都非常快速简单。代理安装问题可能涉及 Azure 订阅端和/或 Azure Arc 服务器端。如果运行 azcmagent 工具的 Azure Arc 安装脚本可以到达微软，但在安装过程中失败，请查看 Azure 订阅中的活动日志以了解云端失败的线索。
例如，图 5-22 显示 Azure Arc machine onboarding 失败的原因是微软。HybridCompute 资源提供者未注册 Azure 订阅。在搜索过滤器中键入“Azure Arc machines”以仅显示涉及 Azure Arc 服务器的 Azure 活动日志条目。
图 5-22
Azure 活动日志是排除代理入职故障的关键
如果您的安装过程被 Azure communications 或本地访问问题阻塞，那么设置为“详细”操作的 azcmagent 工具的日志将是最相关的。要收集详细日志，请尝试使用 azcmagent.exe 工具和开关“--verbose”安装 Azure Connected Machine Agent，然后查看这些位置的日志，寻找代理端故障的线索:
代理日志位置
-
Windows Azure Arc 代理安装日志位置
-
Linux Azure Arc 代理安装日志位置
%ProgramData%\AzureConnectedMachineAgent\Log\azcmagent.log
/var/opt/azcmagent/log/azcmagent.log
代理安装命令行
以下是在使用服务主体执行大规模安装时，使用 Windows 和 Linux 的已连接计算机代理启用详细日志记录的命令示例:
-
Windows Azure Arc 代理安装
-
Linux Azure Arc 代理安装
& "$env:ProgramFiles\AzureConnectedMachineAgent\azcmagent.exe" connect --resource-group "resourceGroupName" --tenant-id "tenantID" --location "regionName" --subscription-id "subscriptionID" –verbose
azcmagent connect --resource-group "resourceGroupName" --tenant-id "tenantID" --location "regionName" --subscription-id "subscriptionID" --verbose
代理卸载过程
-
从控制面板卸载 Windows 代理➤程序和功能➤ Azure Connected Machine 代理➤通过双击azureconnectedmachineagent . MSI安装程序包卸载或运行代理安装向导。
-
根据您的 Linux 操作系统，使用以下命令之一卸载 Linux 代理:
-
Ubuntu:
sudo apt purge azcmagent -
RHEL、CentOS、Amazon Linux:
sudo yum remove azcmagent -
SLES:
sudo zypper remove azcmagent
-
Azure Arc 代理操作问题
在操作中，代理通信很简单:大约每 5 分钟就有一次到 Azure Arc 服务器所在区域的微软云中的 HTTPS 端点的出站心跳通信。图 5-23 显示了发送心跳消息的 Windows 和 Linux 代理的正常状态。(HTTP 状态代码 204 表示“成功，没有要发送的附加内容。”)
图 5-23
Windows 和 Linux Azure Arc 代理发送心跳消息
如果出站通信中断，在客户端，您会在 Azure Arc 服务器的 himds.log 文件中看到错误消息。也就是说，在“通过 HTTP 向服务发送心跳”消息之后，将不会有 HTTP 状态代码 204；可能会有其他的东西帮助你理解问题所在。
识别断开连接的 Azure Arc 服务器
在 Azure cloud 端，代理心跳丢失将导致 Azure Arc 服务器状态在 15 分钟内从连接更改为断开连接。以下 Azure 资源图查询将仅在一个或多个 Azure Arc 服务器未处于连接状态时返回数据:
resources
| where type == "microsoft.hybridcompute/machines"
| project ComputerName = id, Status = properties.status, location, resourceGroup, type, tags
| where Status != "Connected"
考虑将前面的 Azure 资源图查询保存到我们在本章前面创作的 Azure Arc 工作簿(将其命名为“Azure Arc 代理未连接”)。如果任何 Azure Arc 服务器名称出现在网格中，您需要调查相关服务器的 Azure Connected Machine Agent 状态。图 5-24 显示了几个处于断开状态的 Azure Arc 服务器。
图 5-24
Azure 资源图查询生成断开连接的 Azure Arc 服务器列表
Windows 和 Linux 计算机上的 Azure Arc 服务
Azure Arc 服务器处于断开状态的一个常见原因是计算机上的一个或多个 Azure Arc 服务(或守护程序)被停止。这里有一些关于识别和重启 Azure Arc 使用的服务和守护进程的提示。
视窗服务
-
Azure 混合实例元数据服务(himds)
-
来宾配置 Arc 服务(GCArcService)
-
来宾配置扩展服务(Extension service)
在 Windows 计算机上重新启动所有 Azure Arc 服务的命令(需要在提升的 PowerShell 会话中运行):
Restart-Service -Name himds
Restart-Service -Name GCArcService
Restart-Service -Name ExtensionService
Linux 守护进程
-
Azure 连接的计算机代理服务(himdsd.service)
-
GC Arc 服务(gcad.service)
-
扩展服务(extd.service)
在 Linux 计算机上重启所有 Azure Arc 守护进程的命令:
sudo systemctl restart himdsd.service
sudo systemctl restart gcad.service
sudo systemctl restart extd.service
Tip
如果您已经将 Azure Automation 更改跟踪解决方案部署到您的 Azure Arc 服务器，您可以运行以下计划查询警报规则，以确定 Azure Arc 相关服务何时在 Windows 和 Linux 计算机上停止:
ConfigurationChange | where ConfigChangeType contains "WindowsServices" or ConfigChangeType contains "Daemons"
| where SvcState contains "Stopped" | where SvcPreviousState contains "Running"
| where SvcName in ("himds", "GCArcService", "ExtensionService", "himdsd.service", "gcad.service", "extd.service")
摘要
在本章中，你学习了如何大规模部署和管理 Azure Arc 服务器，包括创建和使用 Azure 广告服务主体。我们还讨论了更高级的 Azure Arc 特性，如标签和仪表板，以及在所有场景中对 Azure Arc 服务器进行故障排除。您现在已经掌握了专业部署和支持 Azure Arc 连接机器的所有知识。在接下来的两章中，我们将使用 Azure Arc 构建两个企业解决方案。第六章“混合服务器监控解决方案”部署了一个监控和警报解决方案，第七章“Azure Arc 服务器的法规和安全合规性”部署了一个安全解决方案。
六、混合服务器监控解决方案
本章描述了基于 Azure Monitor 平台服务的独立端到端服务器监控解决方案。前几章帮助你构建了基于 Azure 的管理框架；现在我们用它做一些有价值的、划算的事情。该解决方案为 Azure 订阅中的 Azure 虚拟机和 Azure Arc 服务器提供服务器基础架构监控。当受监控的服务器停机或出现严重问题时，该解决方案会通知您的团队。
该解决方案包含一组 Azure 微服务，用于探测和评估服务器操作系统的可用性、配置和性能。它在监控核心服务器功能(可用性、配置和性能)方面与现有的行业标准工具不相上下。作为一个云原生解决方案，通过新颖的 Azure Connected Machine Agent(Azure Arc)将云框架扩展到非云端点，这是无与伦比的。
该解决方案代表了一种新的行业范式:通过免费的云服务管理平台提供合适的低成本服务器监控。该解决方案提供无限的规模和全球可用性。成功地从更昂贵的遗留应用中迁移服务器监控工具的组织将获得竞争优势。
解决方案高级功能
将解决方案架构视为具有三个主要特性:管理控制平面、规则集和通知工作流。下面将描述这些功能，以及解决方案中构成该功能的 Azure 服务。
-
提供监控、安全、访问和治理的管理控制平面
-
蔚蓝灯塔和蔚蓝商业市场
-
Azure Arc 和 Azure 资源管理器(ARM)
-
Azure 策略
-
Azure 虚拟机扩展
-
微软管理代理(MMA)/Azure 管理代理(AMA)
-
-
一组从托管计算机收集和分析数据的监视器和规则
-
Azure 日志分析
-
Azure VM Insights 来宾运行状况
-
Azure 自动化(更新和配置管理)
-
Azure 计划查询警报规则
-
-
响应警报的方法，例如执行自动化工作流和向票务系统发送警报通知
-
Azure 警报操作组
-
Azure 警报操作规则
-
Azure 逻辑应用
-
监视什么:部署在此解决方案中的一组经过管理的监视器和规则—可从 Azure Monitor 实现有效的服务器操作系统监视—包括检测来自 Windows Server OS 的 System Center Operations Center(SCOM)管理包中包含的规则和警报生成监视器的最常见警报。
成本:交付特定监控服务的 Azure 消耗成本可以估计为每台服务器每月 5 美元。这一估计符合 Azure pricing calculator 的建议，即大多数服务器每月产生 1 GB 到 3 GB 的日志摄取量(在较便宜的地区 1.30 美元= 1 GB，在较贵的地区 5.10 美元= 3 GB)。根据您所在的市场和货币，每台服务器 5 美元是一个保守且有效的整数。
解决方案图
图 6-1 展示了交付解决方案特性的 Azure 服务。以下是图表的可视化指南:
图 6-1
由 Azure Arc 和 Azure Policy 支持的 Azure 监控解决方案
-
从右下方开始， Azure AD 用户或 Azure Lighthouse 服务提供商安全组是将访问 Azure 订阅的身份。
-
Azure RBAC (基于角色的访问控制)用于将 Azure AD 用户与 Azure 订阅中的安全角色相关联。在 Azure Lighthouse 场景中，客户接受了将服务提供商员工与客户 Azure 订阅中的委托安全权限相关联的提议。
-
授权用户或服务主体使用他们的 RBAC 或委托访问权将 Azure 策略分配给 Azure 虚拟机和 Azure Arc 服务器。
-
该策略使计算机受到使用 MMA 的 Azure Monitor (中间)的监控，并将它们连接到日志分析工作区(中间右侧)。
-
Azure VM Extensions 安装 AMA，并将虚拟机连接到虚拟机来宾运行状况监视器(中间左侧)。
-
继续向左，虚拟机客户健康 警告和紧急状态变化触发逻辑应用的启动，其有条件地创建警报通知(红色三角形)。
-
警报规则(左上)按计划运行，寻找指示问题的日志或度量数据。
-
Azure Monitor 警报操作规则选择性地抑制由预定警报规则(左上角)产生的警报；这就是您如何解决计算机特定的预设警报规则覆盖问题。
-
从中间向右侧移动，安装在日志分析工作区的日志分析解决方案包括与 Azure Automation 账户的链接。
-
自动化帐户中的解决方案包括更新管理(右上)和配置管理解决方案(上中)。
特定监控功能
回答问题该解决方案监控什么？，提供以下具体列表。监视器和警报选项以及警报阈值源自 Windows Server SCOM 管理包的默认监视配置文件。
规则和监控列表
-
Azure Monitor 心跳失败(最近 5 分钟内两次或更少的心跳)。
-
逻辑磁盘传输(读取和写入)延迟太高。
-
每秒内存页数太高。
-
逻辑磁盘可用空间不足。
-
可用内存太低。
-
总 CPU 利用率百分比太高。
-
逻辑磁盘当前队列长度太长。
-
服务进入不可预测的状态。
-
检测到重复的 IP 地址。
-
NTFS
—文件系统损坏。 -
在计算机上检测到恶意软件威胁。
-
检测到意外关机。
-
一项核心 Windows 服务已停止(监视 12 项特定服务)。
-
以前运行的 Windows 服务已经停止。
除了向规则和监控列表中的产品发出警报之外，该解决方案还部署了以下高价值产品:
-
Azure Automation 更新解决方案在所有位置的所有 Windows 和 Linux 服务器上提供特定于服务器和整个组织的已安装和缺失/需要的更新视图。
-
Azure Automation 配置管理解决方案对软件、文件系统、Windows 注册表、Windows 服务器和 Linux 守护进程执行检查。记录更改，自动显示更改检测前后的读数。
-
安装 Azure Monitor 工作簿是为了在当前、趋势和历史可用性和性能数据中提供基于图表的可视化帮助。工作簿可以部署为 Azure 仪表板，用于管理显示。
蔚蓝灯塔
Azure Lighthouse 是专门为服务提供商创建的，但它也适用于拥有多个 Azure AD 租户的大型组织。在企业和学术场景中，“共享服务”或“教师”所在的租户可以使用“服务提供商”灯塔委托来无缝管理其他 Azure AD 租户(如“客户”下属、“学生”或合作伙伴公司)拥有的 Azure 订阅。
Azure Lighthouse 允许一对多的方法，服务提供商员工和 Azure 工件，如监控规则和 ARM 模板，在许多客户租户之间共享。也就是说，一个 Azure AD 租户(服务提供商)获得对属于不同租户(客户)的 Azure 订阅的委托权限。当服务提供商向客户提供“优惠”时，就会发生这种情况。然后，客户接受该提议，并将他们的订阅和/或资源组委托给服务提供商租户中存在的并且在提议中指定的特定 Azure AD 安全组。
Azure Lighthouse 提供了一种可撤销的、单向的、可验证的、细粒度的信任，它消除了每个服务提供商员工在客户域中存在重复帐户(或者更糟，共享帐户)的需要。客户审计日志显示在客户订阅中有活动的服务提供商员工的实际姓名。如果服务提供商对所有员工登录强制实施多因素身份验证(MFA ),该解决方案允许服务提供商保证只有 MFA 访问发生在客户资源上。
在本章描述的解决方案中，任何 Azure Lighthouse 的参与都是可选的。然而，如果使用 Azure Lighthouse，该解决方案对于所有多租户监控场景都完全有效。
弧蓝
在最初的 Microsoft Azure“经典”或原始 Azure 数据中心结构控制器取得成功后，发现了扩展和其他限制。微软必须发明一种方法来管理和协调超大规模的全球 Azure 云。由此产生的“V2”技术被称为 Azure 资源管理器(ARM)，有时也被称为 Azure 控制平面，它为今天的所有 Azure 提供动力。把 ARM 想象成 Azure 自己的操作系统，即“主控制器”。我们使用以 JSON 格式编写的文档与 ARM 进行基本通信，也称为 ARM 模板。
ARM 在管理 IT 对象和服务方面被证明是超可扩展和高度可靠的。Azure Arc 是一个新概念的名称，它将 ARM 的规模经济和优势扩展到 Azure 之外的对象。在这个解决方案中，Azure Arc 服务器对象是在 Azure 订阅中创建的，对于 ARM 来说，它类似于 Azure 虚拟机。对于 ARM，两个对象都是计算机，并且计算机管理范例可以跨环境应用。由于 Azure Arc，ARM 可以将 Azure 监控计算机的策略应用于 Azure 虚拟机和非 Azure 服务器。
从管理的角度来看，Azure Arc 使非云服务器变得模糊。经济意义在于，使用 Azure Arc 管理非云服务器将产生成本效益。这些好处来自免费使用 Azure 管理功能，如策略、标签和资源组—，以及消费(或交付)其他云服务，如监控、安全和备份，几乎没有附带或中间“管理工具”成本。
Azure Arc 服务器
正如我们在第四章第四章“Azure Arc 服务器:入门”中所介绍的，Azure Arc 在非 Azure 计算机—上安装了一个应用，即用于非 Azure 计算机—的Azure Connected Machine Agent，它与默认情况下在每个 Azure 虚拟机上运行的 in-AzureWindows Azure Guest Agent执行相同的功能。Windows Azure Guest Agent 本质上是一个用于管理 Azure VM 的带外管理通道。Windows Azure 访客代理为 Azure VM 做的主要事情是安装和维护 Azure VM 扩展，这些扩展是实际执行监控工作的小程序和服务。Azure Arc 的 Azure Connected Machine 代理为非 Azure 计算机做同样的事情。Azure Arc 代理将非 Azure 服务器作为混合机器对象连接到 Azure 控制平面。
在此解决方案中，您不需要在服务器上安装监控代理。相反，你可以在非 Azure 服务器上安装 Azure Arc 代理。然后配置 Azure 策略，通过 Azure Arc 在计算机上安装监控代理。Azure 策略补救任务实际上使用 Azure AD 中的服务主体安装监控代理，该服务主体是在分配策略时创建的。在图 6-2 中，此 Windows 服务器上列出的所有管理应用都是由第一个列出的代理 Azure Arc 代理(Azure Connected Machine Agent)安装或验证的。
图 6-2
此 Azure Arc 服务器上的 Azure Connected Machine 代理使用 Azure VM 扩展安装了其他程序
Azure Arc 服务器是使用运行在被装载的服务器上的脚本注册的。脚本登录到运行 onboarding 脚本的个人或服务主体的 Azure AD 租户。然后，如果个人或服务具有适当的安全访问权限，则会在指定的 Azure 订阅、资源组和 Azure 区域中创建 Azure Arc 服务器的 ARM 资源记录(ARM 对象)。Azure Arc 服务器被静默地颁发一个数字证书，该证书充当计算机对 Azure 的唯一身份提供者。
Azure 策略
Azure 策略在 Azure 虚拟机和 Azure Arc 服务器之间一致地应用监控和管理设置。具体来说，在该解决方案中，所有位置的所有 Windows 和 Linux 服务器—和云—都通过同一个策略计划来评估其对核心监控目标的合规性。当服务器准备好开始被监控时，部署一个 Azure Policy initiative，将服务器连接到订阅中的 Azure Monitor 实例(图 6-3 )。
核心监控目标是通过在每台计算机上安装两个软件，将每台计算机连接到选定的 Azure Log Analytics 工作区:(1)微软监控代理(MMA)和(2)依赖代理。依赖代理补充了 MMA，并为 VM Insights 中的服务地图集成提供了网络级信息。
图 6-3
Azure Policy 向所有位置的所有服务器推出启用 Azure 虚拟机监控策略计划
有一个内置的 azure policy initiativeenable azure monitor for****VM(策略➤创作➤定义)捆绑了十个策略。八项政策能够部署不存在的补救任务:
-
将日志分析代理部署到 Windows Azure Arc 计算机。
-
部署
—将日志分析代理配置为在 Windows 虚拟机上启用。 -
将日志分析代理部署到 Linux Azure Arc 机器。
-
为 Linux 虚拟机部署日志分析代理。
-
将依赖关系代理部署到 Windows Azure Arc 计算机。
-
部署
-配置要在 Windows 虚拟机上启用的依赖关系代理。 -
将依赖代理部署到混合 Linux Azure Arc 机器上。
-
为 Linux 虚拟机部署依赖关系代理。
-
两个策略属于 AuditifNotExist 类型，用于在发现非标准 Azure VM 映像类型时进行标记，否则会阻止自动补救。
-
应为列出的虚拟机映像启用日志分析代理。
-
应为列出的虚拟机映像启用依赖关系代理。
Azure 策略分配
Enable Azure Monitor for VMs 计划分配给订阅和/或资源组，是在所有计算机上推送安装和集中配置 MMA 和依赖代理的主要工具。如果计算机不符合核心监控目标，这样做还可以检测配置漂移。
在分配计划时，会创建一个托管身份，这是一个 Azure AD Enterprise 应用注册(服务主体)。服务主体被自动授予 Azure 订阅或资源组中的日志分析贡献者角色。服务主体将有一个随机显示名称，如“27c1377f005d47578cecc397”。
您可以通过返回编辑方案分配来定位服务主体名称；在补救选项卡上是主体 ID 框，带有 GUID，如“75943696-0879-432d-98e 6-AE 0aa 439 ed 05”。该 GUID 与企业应用的对象 ID(服务主体)相匹配。您可以使用 Azure PowerShell 命令 Get-AzADServicePrincipal 将该对象 ID 交叉引用回 Azure AD 服务主体的名称(通过输出进行了演示):
PS /home> Get-AzADServicePrincipal -ObjectId 75943696-0879-432d-98e6-ae0aa439ed05
ServicePrincipalNames : {57aa357a-8f37-44c5-8fb5-ade220354465, https://identity.azure.net/TzdI8YgzhpY339TyesufBsnmeXGgqUM56HhUnrT8S2k=}
ApplicationId : e0ba357a-8f37-44c5-8fb5-ade220354564
ObjectType : ServicePrincipal
DisplayName : 27c1377f005d47578cecc397
Id : 75943696-0879-432d-98e6-ae0aa439ed05
要使修复任务正常工作，服务主体的显示名称应位于订阅或资源组➤访问控制(IAM) ➤角色分配中的日志分析贡献者下。
Azure 策略实施间隔
以下是将导致策略资源被评估的时间或事件:
-
在具有策略分配的范围内创建、更新或删除资源。
-
策略或计划被新分配给一个范围。
-
更新已经分配给范围的策略或计划。
-
在每 24 小时一次的标准符合性评估周期中。
Tip
您可以使用以下 Azure PowerShell 命令在资源组中触发按需 Azure 策略实施:
Start-AzPolicyComplianceScan -ResourceGroupName '<rgname>' -AsJob
Azure 策略合规性
Azure 策略分配的目标是通过补救任务和可选豁免的组合实现 100%的合规状态(图 6-4 )。当低于 100%合规状态时，不合规的特定计算机和策略的列表可在策略➤合规➤倡议➤不合规资源中找到。
不符合的资源列表是解决方案部署期间的工作列表，用于识别需要补救的计算机。部署解决方案后，监控合规性保持在 100%,当计算机和策略不合规时，采取必要措施恢复 100%合规性。
图 6-4
在资源组中 100%合规的情况下启用 Azure Monitor for VMs 策略计划
Azure 策略:补救任务
将 Enable Azure Monitor for VMs 计划分配给订阅或资源组后，新创建的资源(Azure VMs 和 Azure Arc 服务器)如果不符合，将自动进行补救。为现有资源创建修复任务，将必要的代理推送到各自的目标。大多数服务器不会为目标日志分析工作区安装和配置 Microsoft 管理代理(MMA)或依赖关系代理。事实上，Azure Policy 对于预先存在的资源是一个两步过程:分配策略来识别不符合的资源，然后启动补救任务来修复问题。
遵循此协议使用 Azure 策略部署解决方案:
-
在策略➤合规性方面，选择为虚拟机启用 azure monitor】计划。
-
点击创建修复任务。
-
对于要修复的策略，选择为 Windows 虚拟机部署日志分析代理。
-
请确保范围正确(一台计算机、一个资源组或一个订阅)。
-
请在补救前检查重新评估资源符合性。
-
推补救。
-
从步骤 2 开始重复，并选择为 Windows 虚拟机部署依赖代理。
-
重复步骤 4、5 和 6。
-
如果合适，再次从步骤 2 开始重复为 Linux 虚拟机部署日志分析代理，然后为 Linux 虚拟机部署依赖代理。
-
在第一波修复任务之后，对故障进行分类和修复，根据需要重复修复任务，直到所有计算机都符合要求。视情况创建例外(下一章介绍)以提高合规百分比。
未列出的图像
当 ARM 不知道虚拟机操作系统磁盘的确切来源时，默认策略对不符合的进行“故障保护”。如果某些计算机标记了未列出的的虚拟机映像(OS)的审计策略，则有必要克隆内置方案，并为日志分析代理和依赖关系代理策略创建带有自定义策略的自定义方案。自定义策略将添加您组织的自定义 osDisk.creationOption 值，以便策略接受并继续修复。
例如，以下 JSON 代码在拼接到的"policyRule":部分时，将允许使用附加和上传的磁盘映像:
{
"allOf": [
{
"field": "Microsoft.Compute/virtualMachines/storageProfile.osDisk.createOption",
"equals": "Attach"
}
]
},
{
"allOf": [
{
"field": "Microsoft.Compute/virtualMachines/storageProfile.osDisk.createOption",
"equals": "FromImage"
}
]
},
多个管理组
如果 MMA 代理在修复任务期间由于多个管理组而出现故障，您可以使用 Azure PowerShell/Cloud Shell 手动安装 MMA 的 VM 扩展。以下示例自定义脚本添加了" " stoponmultipleconconnections " = $ false "标志。
Connect-AzAccount
$PublicSettings = @{"workspaceId" = " fd75fd75-f70c-4fe5-bd39-afa5f70cafa5";"stopOnMultipleConnections" = $false}
$ProtectedSettings =@{'workspaceKey' = 1234abcdxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx1234abcd=='}
Set-AzVMExtension -ResourceGroupName "MyResourceGroup" `
-VMName "MyAzureVM" `
-Publisher Microsoft.EnterpriseCloud.Monitoring `
-ExtensionType MicrosoftMonitoringAgent `
-TypeHandlerVersion 1.0 `
-Settings $PublicSettings `
-ProtectedSettings $ProtectedSettings `
-Location "eastus2 `
-Name MicrosoftMonitoringAgent
对于 Azure Arc 服务器，如果有大量计算机需要修改的 VM 扩展安装策略，请克隆内置策略，并为日志分析代理创建一个带有自定义策略的自定义方案。用以下代码替换策略的内置“资源”部分:
"resources": [
{
"name": "[concat(parameters('vmName'), '/', variables('vmExtensionName'))]",
"type": "Microsoft.HybridCompute/machines/extensions",
"location": "[parameters('location')]",
"apiVersion": "2019-12-12",
"properties": {
"publisher": "[variables('vmExtensionPublisher')]",
"type": "[variables('vmExtensionType')]",
"settings": {
"workspaceId": "[reference(parameters('logAnalytics'), '2015-03-20').customerId]",
"stopOnMultipleConnections": "false"
},
"protectedSettings": {
"workspaceKey": "[listKeys(parameters('logAnalytics'), '2015-03-20').primarySharedKey]"
}
}
}
],
Azure 策略:豁免
可以将策略分配给将始终报告不符合的计算机，但是在计算整体策略符合性时，给定细节不应减少不符合的计算机计数。换句话说，放弃政策。
遵循此协议从分配的 Azure 策略中豁免计算机:
-
在“策略➤合规”中，选择“为虚拟机启用 Azure Monitor”计划。
-
点击不合规资源。
-
找到要豁免的计算机并点击创建豁免按钮。
-
确保豁免范围(一台计算机)正确。
-
视情况选择弃权或减轻。
-
输入票号等备注，点击审核+创建，然后点击创建。
Azure 日志分析
单一日志分析工作区是该解决方案的重点。所有的监控工件都指向指定的工作区。许多 Azure 日志分析解决方案被安装在工作空间中，为解决方案做出贡献(图 6-5 ):
-
评价
-
复制
-
代理健康评估
-
ChangeTracking(由 Azure Automation 更改跟踪自动安装)
-
脱氧核糖核酸分析
-
逻辑管理
-
安全
-
服务地图
-
SQL 脆弱性评估
-
更新(由 Azure 自动化更新解决方案自动安装)
-
VMInsights(通过将日志分析工作区与 VM Insights 链接来自动安装)
需要手动安装的解决方案如下所示。按照以下步骤添加解决方案:
图 6-5
安装了推荐解决方案的 Azure 日志分析工作区的概述页面
-
在日志分析工作区➤➤综合工作区概要，点击添加按钮。
-
在 Marketplace，在搜索栏中粘贴解决方案的确切名称:
-
Active Directory 运行状况检查
-
AD 复制状态
-
Azure 日志分析代理运行状况
-
DNS 分析
-
逻辑应用管理
-
安全和审计
-
服务地图
-
SQL 漏洞评估
-
-
找到解决方案，然后单击“创建”按钮。
-
选择日志分析工作区，然后再次单击创建。
日志分析工作区附加配置
在 Azure Log Analytics 工作区中安装解决方案后，还有对 Azure Log Analytics 代理配置的额外定制。为了进行有效的监控，有必要收集常见的事件日志(系统和应用)以及选定的附加磁盘和内存性能计数器。此外，您将确认工作区数据的保留期。
Windows 事件日志
在日志分析工作区➤设置➤代理配置➤窗口事件日志中，添加包含所有优先级事件的应用和系统日志(图 6-6 )。
图 6-6
要收集的 Windows 事件日志
Windows 性能计数器
在日志分析工作区➤设置➤代理配置➤ Windows 性能计数器，添加如图 6-7 所示的设置。
图 6-7
收集这些额外的 Windows 性能计数器
或者，以下 Azure PowerShell 示例脚本(Add-PerfCounters.ps1)将创建 Windows 性能计数器:
Add-PerfCounters.ps1
$ResourceGroup = "MyResourceGroup"
$WorkspaceName = "MyWorkspace"
New-AzOperationalInsightsWindowsPerformanceCounterDataSource -ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName -ObjectName "LogicalDisk" -InstanceName "*" -CounterName "Avg. Disk sec/Transfer" -IntervalSeconds 60 -Name "LogicalDisk(*)\Avg. Disk sec/Transfer"
New-AzOperationalInsightsWindowsPerformanceCounterDataSource-ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName -ObjectName "LogicalDisk" -InstanceName "*" -CounterName "Current Disk Queue Length" -IntervalSeconds 60 -Name "LogicalDisk(*)\Current Disk Queue Length"
New-AzOperationalInsightsWindowsPerformanceCounterDataSource-ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName -ObjectName "Memory" -InstanceName "*" -CounterName "Pages/sec" -IntervalSeconds 60 -Name "Memory(*)\Pages/sec"
数据保持
确认 Azure Log Analytics 数据的保留期符合您的预期。在默认服务中，日志将免费保留 31 天。如果选择更长的保留时间，请在日志分析工作区➤常规➤使用和估计成本➤数据保留中进行设置。(Microsoft Sentinel 包括 90 天的免费保留期。)保留数据的时间超过包含/免费保留期将产生额外的每月 Azure 订阅费用。
Tip
下面是一些估算长期保留额外成本的经验法则:
Azure 日志分析:
每月增加 50%以保留 1 年，而不是 31 天。例如:每月 100 美元保留 31 天，每月 150 美元保留 1 年
微软哨兵:
与 90 天相比，保留 1 年每月增加 20%的成本。例如:每月 1000 美元保留 90 天，每月 1200 美元保留 1 年
日志分析工作区中数据的最长保留期为 730 天(2 年)。虽然您的数据保留在工作区存储库中，但它会像当前数据一样在报告中被查询和使用。如果您的数据保留需求超过 2 年，支持的解决方案是启用从日志分析到 Azure 存储帐户或 Azure 事件中心的连续数据导出。有关其工作原理的详细信息，请访问以下 URL:
https://docs.microsoft.com/en-us/azure/azure-monitor/logs/logs-data-export
Azure 自动化
创建 Azure Automation 帐户时，会创建一个“Azure 运行方式帐户”作为 Azure AD 中的服务主体，并授予订阅的参与者角色。在自动化帐户➤帐户设置➤运行方式帐户中检查 Azure 运行方式帐户的状态。服务主体应该在 Azure 订阅中分配有 Contributor 角色。
作为一次性活动，将 Azure Automation 帐户链接到日志分析工作区➤相关资源➤自动化帐户的 Azure 日志分析工作区。
将 Azure Automation 帐户链接到 Azure Log Analytics 工作区后，为所有可用和未来的机器启用更新管理和库存解决方案，如图 6-8 所示。
图 6-8
为所有可用和未来的计算机启用 Azure Automation 更新管理解决方案
当一台计算机注册 Azure 自动化解决方案时，会为每台计算机悄悄地创建一个系统混合工作组。系统混合工作者组的名称类似于my computer . my domain . com _ 4 fcd 9932-4206-4 fcd-8842-4 fcd 63874 fcd。该混合工作器被授权在受监控的计算机上运行，以便收集清单、更改和更新数据，并在该选项打开的情况下安装更新。
Azure 监视器
在这个解决方案中，Azure Monitor 的两个方面用于监控服务器。这些是计划的警报规则和 Azure VM 来宾运行状况监视器。规则和监视器一起是解决方案中的主动传感器。
Azure Monitor 操作组
在导入选择的预定警报规则之前，会创建一个 Azure Monitor 操作组来接收警报并对其执行通知。导入警报规则时，会指定此操作组的名称，因此它必须在导入警报规则之前存在。
操作组:默认-预警-操作
操作组创建如下:
-
日志分析工作区➤监控➤警报➤管理操作➤添加操作组。
-
对于名称，输入默认警报操作。
-
对于简称，输入默认名称。
-
创建电子邮件类型的通知操作。
-
添加通知端点的电子邮件地址。
-
选择“是”以启用通用警报模式。
-
单击确定。
-
点击保存更改。
图 6-9 摘自 Azure Monitor 电子邮件提醒产品；这是一个计算机心跳停止的例子。
图 6-9
Azure Monitor 发送的电子邮件警报通知的主题和正文摘要
操作组:VM Insights 运行状况警报
创建第二个操作组 VM Insights Health Alert 来启动一个逻辑应用，该应用对 Azure VM Health monitor 警报进行后处理。在创建了逻辑应用Azure-Monitor-Guest-Health-Alerting之后，将在解决方案部署的后期创建该组。动作组只有一个动作:触发逻辑应用。
Azure Monitor 计划的警报规则
计划的监控警报规则定期运行(从每 5 分钟一次到每天一次),并在日志数据中查看是否存在警告或严重警报指示器，或者是否存在正常数据指示。该解决方案包括 12 个定时预警规则(表 6-1 )。图 6-10 和 6-11 展示了实际应用中的解决方案，显示了活跃环境中一天的警报流量。
图 6-11
所有警报列表包括平台指标和日志分析日志警报
图 6-10
Azure 门户中的 Azure Monitor 警报控制台
表 6-1
Azure Monitor 计划的警报规则
|名字
|
类型/频率
|
情况
|
| --- | --- | --- |
| Azure Monitor Heartbeat Failure | Metric``5m @ 1m | Whenever the total heartbeat is less than or equal to 2 [in 5 minutes] |
| Logical Disk Current Queue Length is too High | Metric``15m @ 1m | Whenever the average average_current disk queue length is greater than 32 |
| Logical Disk Transfer (reads and writes) Latency is too High | Metric``15m @ 1m | Whenever the average average_avg. disk sec/transfer is greater than 0.04 |
| Memory Pages Per Second is too High | Metric``1h @ 5m | Whenever the average average_pages/sec is greater than 5000 |
| (Core Windows Services Rollup) A service has stopped | Log``5m @ 5m | ConfigurationData | where SvcState == "Stopped" | where SvcName == "Browser" or SvcName == "DHCP" or SvcName =="DNSCache" or SvcName == "PlugPlay" or SvcName == "RpcSs" or SvcName == "lanmanserver" or SvcName == "LmHosts" or SvcName == "Eventlog" or SvcName == "MpsSvc" or SvcName == "WinRM" or SvcName == "Lanmanworkstation" | where SvcStartupType != "Disabled" |
| A previously running Windows service has stopped | Log``5m @ 5m | ConfigurationChange | where ConfigChangeType contains "WindowsServices" | where SvcStartupType contains "Auto" | where SvcState contains "Stopped" | where SvcPreviousState contains "Running" | where SvcName !in ("IaasVmProvider","edgeupdate","RemoteRegistry","sppsvc","TrustedInstaller","wuauserv") |
| A Service has Entered into an Unpredictable State | Log``5m @ 5m | Event | where (EventLog == "System" and Source == "Service Control Manager") and (EventID == 7030 or EventID == 7037) | project Computer, TimeGenerated, AlertType_s = "A Service has Entered into an Unpredictable State", Severity = 4, SeverityName_s = "WARNING", AffectedCI_s = Computer, AlertTitle_s = strcat(Computer, ": A Service has Entered into an Unpredictable State"), AlertDetails_s = strcat("Event Description:", RenderedDescription) |
| Duplicate IP Address has been Detected | Log``5m @ 5m | Event | where ( EventLog == "System" and Source == "Tcpip" ) and ( EventID == 4198 or EventID == 4199 ) | project Computer, TimeGenerated, AlertType_s = "Duplicate IP Address has been Detected", Severity = 4, SeverityName_s = "WARNING", AffectedCI_s = Computer, AlertTitle_s = strcat(Computer, ": Duplicate IP Address has been Detected"), AlertDetails_s = strcat("Event Description:", RenderedDescription) |
| Malware threat detected on computer (Defender) | Log``10m @ 10m | ProtectionStatus | summarize ThreatStatusRank=max(ThreatStatusRank) by Computer, Time=bin(todatetime(DateCollected), 10m) | summarize(Time, ThreatStatusRank) = argmax(Time, ThreatStatusRank) by Computer | where ThreatStatusRank !in (150, 470) | project Computer, Rank = ThreatStatusRank |
| NTFS - File System Corrupt | Log``30m @ 30m | Event | where EventLog == "System" and Source == "DISK" or Source == "Ntfs" and EventID == 55 | project Computer, TimeGenerated, AlertType_s = "NTFS - File System Corrupt", Severity = 4, SeverityName_s = "WARNING", AffectedCI_s = Computer, AlertTitle_s = strcat(Computer, ": NTFS - File System Corrupt"), AlertDetails_s = strcat("Event Description:", RenderedDescription) |
| One or more previously seen agents is unresponsive | Log``2h @ 2h | Heartbeat | summarize LastCall = max(TimeGenerated) by Computer | where LastCall < ago(24h) |
| Unexpected shutdown | Log``1d @ 1d | Event | where EventLog == "System" and EventID == 6008 | project Computer, TimeGenerated, AlertType_s = "Unexpected shutdown", Severity = 4, SeverityName_s = "WARNING", AffectedCI_s = strcat(Computer), AlertTitle_s = strcat(Computer, ": Unexpected Shutdown"), AlertDetails_s = strcat("Multiple shutdowns detected in the past 24 hours EventID: 6008 Event Description: ", RenderedDescription) |
Azure Monitor 计划警报规则可以使用表 6-1 中的信息手动创建为 KQL 查询，或者使用 ARM 模板导入到 Azure 订阅中。在以下 URL 查找示例 KQL 查询，以粘贴到您可能创建的预定警报规则中:
https://github.com/microsoft/AzureMonitorCommunity
图 6-12 显示了导入后在 Azure Log Analytics 工作区中运行的解决方案规则。
图 6-12
Azure Monitor 计划警报规则在环境中执行监控
使用 ARM 模板进行规则管理
您可能会发现创建一个预定警报规则库来导入 Azure Log Analytics 非常方便。Azure Monitor 可以使用 ARM 模板进行大规模部署和配置。每个警报规则都可以作为 ARM 模板/参数文件对导入。以下 URL 提供了不同 Azure Monitor 功能的示例模板，可以根据您的特定需求进行修改:
https://docs.microsoft.com/en-us/azure/azure-monitor/resource-manager-samples
创建可重复使用的警报规则模板库
GitHub Management toolkit URL 包含导入许多常见警报规则定义的指令，其中许多都包含在这个 Azure 监控解决方案中。点击链接，从以下网址下载用于传统日志警报 API 的警报工具包:
https://github.com/microsoft/manageability-toolkits
考虑使用这种方法来开发您的 ARM 模板库:
-
将可管理性工具包中的所有可用规则导入 Azure Log Analytics。
-
禁用开发不需要运行的规则。
-
评估您将在生产中使用的规则，并将其内容导出到 ARM 模板。
-
删除由可管理性工具包导入 Azure Monitor 的规则。
-
使用 ARM 模板为基于代码的管理重新导入生产规则。
-
使用 ARM 模板将相同的规则集部署到其他 Azure Log Analytics 工作区，或者将它们用作监控基础架构的备份/文档。
创作预设警报规则模板
日志预警规则和度量预警规则具有不同的结构。对于规则的完整部署，您需要准备以下文件:
-
日志警报的模板文件
-
度量预警的模板文件
-
日志预警的模板参数文件
-
度量预警的模板参数文件
以下网址提供了详细说明和示例模板:
- 使用资源管理器模板创建日志警报
https://docs.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-log-create-templates
- 使用资源管理器模板创建度量预警
https://docs.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-metric-create-templates
Tip
确保在通过 ARM 模板导入规则之前，预先创建将为警报执行默认通知的 Azure Monitor 操作组。(这是本章的 Azure Monitor 操作组一节中介绍的默认-警报-操作组。)如何:在模板参数文件中指定动作组的资源组 ID，在导入预警规则时自动启用您的默认通知渠道。在参数文件中，您的操作组资源组 ID 将如下所示:
"actionGroupId": {
"value": "/subscriptions/12341234-1234-1234-1234-123412341234/resourceGroups/RG-DEV-EUS/providers/microsoft.insights/actiongroups/Default-Alert-Action"
}
部署 ARM 模板以实现监控
您可以使用任何部署资源管理器模板的标准方法来部署您的 ARM 模板(从而启用监控)。以下部分描述了使用 Azure 门户和 Azure PowerShell 将计划日志和度量警报规则的标准化版本导入 Azure Log Analytics 的方法。
使用 Azure 门户导入规则模板
-
导航到首页➤新➤搜索市场。
-
键入“template”并从下拉列表中选择模板部署(使用自定义模板部署)。点击创建。
-
在选择模板处，点击在编辑器中构建您自己的模板。
-
在编辑模板，用模板文件内容替换代码视图的全部内容，点击保存。
-
单击编辑参数；然后在编辑参数，用模板参数文件内容替换整个代码段，点击保存。
-
在自定义部署界面，选择资源组，点击查看+创建，然后点击创建。
使用 Azure PowerShell 导入规则模板
为要导入的规则准备输入模板和模板参数文件；然后使用New-AzResourceGroupDeploymentcmdlet 创建部署。此示例从文件“MonitorLogAlert-template-Core service has stopped . JSON”和“MonitorLogAlert-parameters . JSON”中导入日志规则“Core service has stopped”:
New-AzResourceGroupDeployment -Name "LogAlertDeployment" -ResourceGroupName MyResourceGroup -TemplateFile "MonitorLogAlert-template-Core service has stopped.json" -TemplateParameterFile "MonitorLogAlert-parameters.json"
此示例从文件“MonitorLogAlert-template-Azure Monitor heartbeat failure-metric . JSON”和“monitormetricslalert-parameters . JSON”中导入度量规则“Azure Monitor heart beat failure”:
New-AzResourceGroupDeployment -Name "MetricAlertDeployment" -ResourceGroupName MyResourceGroup -TemplateFile "MonitorLogAlert-template-Azure Monitor heartbeat failure-metric.json" -TemplateParameterFile "MonitorMetricsAlert-parameters.json"
将您的所有部署捆绑到一个 PowerShell 脚本中，该脚本为您正在导入的每个规则运行一次 New-AzResourceGroupDeployment。将脚本与模板和模板参数 JSON 文件一起分发。通过执行 PowerShell .PS1 脚本来部署整套警报规则。
Tip
您可以对部署到相同环境的所有规则重用相同的参数文件。准备两个模板参数文件，日志规则和度量规则版本各一个；然后将这些模板文件用于所有规则部署。示例:要部署包括日志和度量类型的 12 x 规则，您需要准备 14 x 文件，其中两个是模板参数文件。
关于 ARM 模板文件中的转义字符
使用预定规则查询 ARM 模板时，注意需要用反斜杠字符()对模板文件描述和查询字段中的受保护字符("、\、和/)进行“转义”。表 6-2 列出了您需要遵循的转义符指导:
表 6-2
用反斜杠转义特殊字符
|特殊字符
|
逸出输出
|
| --- | --- |
| 引号(") | " |
| 反斜杠() | \ |
| 斜线(/) | / |
| 换行 | \n |
| 回车 | \r |
以下是 ARM 模板查询和描述字段的前(未转义)和后(转义)示例:
"query": "Event | where EventLevelName == "Error""
(转义“引号”字符)变成
"query": "Event | where EventLevelName == \"Error\""
"description": "Sample https://site.com link"
(转义“反斜杠”字符)变成
"description": "Sample https:\/\/site.com link"
Azure 监控来宾虚拟机运行状况
除了本章到目前为止描述的 12 个 Azure Monitor 计划警报规则之外，在名为 Guest VM Health 的解决方案中还部署了第二个单独的监控堆栈。此功能为解决方案添加了一个针对 CPU、内存和逻辑磁盘空间的分层健康监视器，有三个警报规则，每个资源类型一个，使解决方案中产生警报的规则总数达到 15 个。
来宾虚拟机运行状况监控器补充了计划指标和日志警报规则，从而提供了一个高效的核心操作系统监控解决方案。与使用调度查询指标警报规则相比，来宾虚拟机运行状况是一种更灵活的监控这些性能指标的方式。
来宾 VM 健康特性也适用于 Linux 计算机，但是在第一版中只适用于 Ubuntu。
Tip
如果您只有 Azure Arc 服务器，则不需要安装来宾 VM 健康解决方案。然而，如果您是一个全 Azure 或混合组织，您将并行部署来宾 VM 健康到 Azure Monitor 计划警报规则。本节末尾列出了要部署的 Azure Monitor 计划警报规则，以代替来宾虚拟机运行状况数据收集规则。
Azure Monitor 代理介绍(AMA)
来宾虚拟机健康解决方案使用新的 Azure 管理代理 (AMA)，而不是系统中心运营管理器(SCOM)和 Azure 日志分析使用的经典 MMA。AMA 和 MMA 能够并且确实并行存在。在该解决方案中，所有代理组件都由各自的机器代理使用 Azure VM Extensions 进行安装。这种技术利用内置的 Windows Azure 访客代理服务在 Azure 虚拟机上执行其他代理的软件安装，并利用 Azure Connected Machine 代理在 Azure Arc 服务器上执行其他代理的软件安装。
正如经典 Azure Log Analytics 和 VM Insights 解决方案需要在 Windows VM 中安装两个软件组件(MMA 和依赖关系代理)一样，在部署来宾 VM 健康解决方案时，Windows VM 中也部署了两个不同的软件组件:
-
第一个是 Azure Monitoring Agent (AMA)。AMA 作为独立于 MMA 的 Windows 进程运行。AMA(代理版本 1.x)和 MMA(代理版本 10.x)都将心跳发送到同一个日志分析工作区。
-
另一个是来宾虚拟机健康代理。部署该代理将 Azure VM Insights 体验与新的健康监控功能相结合。这个解决方案需要 AMA；它不能单独在 MMA 上运行。
所有四个代理都由 Azure VM Extensions 安装在解决方案中，并且都创建 Windows 服务。但是，与作为应用安装并出现在控制面板➤添加/删除程序中的 MMA 和依赖关系代理不同，AMA 和来宾健康代理由 VM 扩展安装。它们的存在通过检查已安装 Azure VM 扩展的列表来指示(图 6-13 )。
图 6-13
Azure VM 扩展是代理的主要部署工具
在 Azure VM 的 Windows 文件系统中，将在 C:\WindowsAzure 和 C:\Packages\Plugins 文件夹中记录 AMA 和来宾健康代理的存在。图 6-14 和 6-15 从所有服务器视图和一个经历高 CPU 利用率警告状态的服务器的详细视图显示了来宾 VM 健康解决方案。
图 6-15
CPU 利用率处于警告状态的来宾虚拟机运行状况监视器
图 6-14
在资源组中的所有服务器上运行的来宾虚拟机运行状况监视器
Azure Monitor 数据收集规则
来宾 VM 健康监视器使用数据收集规则(DCR)和数据收集规则关联的组合来收集计算机上的数据。DCR 协会将 DCR 分配给一台或多台计算机。DCR 定义了收集哪些数据，而关联定义了哪些计算机将使用 DCR。图 6-16 展示了添加数据源的步骤，在该步骤中，您可以定义要收集的数据。
图 6-16
创建自定义数据收集规则时的添加数据源步骤
如果您在使用 Azure 门户网站的计算机上启用来宾 VM Insights(在家中➤监视器➤ Insights ➤虚拟机)，将应用通用 DCR，这是具有默认设置的标准 DCR。默认设置启用严重警报，但不启用警告警报。要提供更主动的警报，请部署一个自定义 DCR，其中包括用于警报目的的警告阈值和严重阈值。要部署自定义 DCR，请使用以下 URL 上的“使用数据收集规则在 VM insights guest 虚拟机运行状况中配置大规模监控”过程:
https://docs.microsoft.com/en-us/azure/azure-monitor/vm/vminsights-health-configure-dcr
创建自定义 DCR 时，表 6-3 中列出了推荐的设置。
表 6-3
建议的虚拟机来宾运行状况性能监视器警报阈值
|班长
|
临界阈值
|
警告阈值
|
| --- | --- | --- |
| CPU 利用率 | >90% | >80% |
| 逻辑磁盘可用空间 | <5% | <10% |
| 记忆 | < 100 MB | < 200 MB |
Azure Arc 服务器的计划警报规则(直到支持来宾虚拟机运行状况)
由于 VM 来宾健康解决方案不支持 Azure Arc 服务器，为了向非 Azure 服务器提供等效的监控，有必要增加表 6-1 中先前详述的计划警报规则。表 6-4 定义了三个额外的规则，这些规则取代了来宾 VM 健康解决方案所提供的监控，而这些监控对于 Azure Arc 服务器是不可用的。
表 6-4
Azure Arc 服务器的其他计划警报规则
| `Alert Name` | `Monitor Configuration and Threshold` | `Performance Counters to Collect` | | `Alert - High CPU Usage` | `AveCpu >85% at 30-minute intervals over a 4-hour period` | `Process(*)\% Processor Time``Sample rate: 60 seconds` | | `Low Disk Space Windows - Critical` | `Min % Free Space <10% in last 30 minutes, drives C:, E:, F:, and G:.` | `LogicalDisk(*)\% Free Space``Sample rate: 300 seconds` | | `Alert - Low Memory` | `minAvailableMB <1024 MB at 30-minute intervals over a 4-hour period` | `Memory(*)\Available Mbytes``Sample rate: 1800 seconds` |要部署这些附加规则
-
按照本章前面“使用 ARM 模板进行规则管理”一节中的描述，从 GitHub 可管理性工具包中提取规则查询定义。
-
将列出的性能计数器添加到日志分析代理配置中，如前面图 6-7 所示。
-
为了避免来自 Azure VM 来宾健康中注册的计算机的双重监控和警报，请将附加规则的范围限制为仅 Azure Arc 服务器。作为一种解决方法，在警报规则的 KQL 中添加一行，排除名称模式指示它们是 Azure 虚拟机的计算机；例如，
"| where Computer notcontains "AZ""不会对名称中带有字母“AZ”的计算机发出警报。 -
根据您的环境修改阈值，并为无法参与 Azure VM 来宾健康解决方案的计算机的生产监控部署附加规则。
Azure Monitor 数据收集规则关联
DCR 关联将计算机链接到集合规则集。关联的计算机出现在数据收集规则➤配置➤资源面板中，如图 6-17 所示。
图 6-17
与此 DCR 关联的计算机(资源)列表。所有这些服务器将共享相同的虚拟机来宾运行状况设置
Azure 监视器操作规则
可在监控➤预警➤管理操作➤操作规则中访问，创建这些规则是为了抑制预警通知并大规模启用预警操作。在 Azure Monitor 解决方案中，两种模式中都使用了动作规则。
为操作组创建操作规则
创建了一个操作规则，在警报触发时通知管理员，以捕捉 Azure 来宾 VM 健康监视器中的状态变化。按照以下步骤创建“操作组”操作规则:
-
导航至日志分析➤预警➤管理行动➤行动规则，然后单击新行动规则。
-
范围:选择订阅。
-
过滤器:
-
监控条件等于触发
-
监控服务等于虚拟机洞察-运行状况
-
-
在此范围内定义:行动组。
-
行动组:VM Insights 健康警报。
-
名称:警报触发时通知管理员。
-
单击保存。
Azure 监视器操作规则(禁止):覆盖
这是 Azure Monitor 解决方案的重要组成部分；这就是为什么“覆盖”被引入来减少误报，从而减少警报疲劳。在监控➤预警➤管理活动➤活动规则中访问，这些是为禁止预警通知而创建的特定改写规则。覆盖创建起来很简单，人们可以从 Azure 门户网站上阅读。
图 6-18 显示了每日备份窗口期间性能监视器的三种覆盖，以及在上一步中创建的“警报触发时通知管理员”操作规则。
图 6-18
部署为操作规则的特定于服务器、特定于规则的覆盖
创建禁止显示的操作规则
按照下列步骤创建禁止显示的操作规则:
图 6-19
选择作为覆盖目标的规则
-
导航到日志分析工作区➤警报➤管理操作➤操作规则，然后单击新操作规则。
-
范围是日志分析工作区。
-
请注意，与此范围匹配的规则将显示一个数字，比如 123 条警报规则。
-
点击过滤添加按钮(图 6-19 )。
图 6-20
使用警报规则名称和服务器名称创建覆盖以抑制警报
- 在添加过滤器，添加该信息(图 6-20 ):
-
警报规则 Id 包含要覆盖的警报的名称(该名称必须存在于警报规则列表中)。
-
警报上下文(有效负载)包含覆盖的计算机名称。
-
将动作规则命名为“覆盖
- - ”。 -
在日志分析工作区的资源组中保存操作规则，然后单击创建。
-
Azure 逻辑应用
Azure Logic 应用是一种云微服务，可用于调度、自动化和编排任务、业务流程和工作流。除了 Azure 自动化和 Azure 功能，Azure 逻辑应用是 Azure 监控解决方案中的主要工具。值得注意的是，Azure Logic 应用是针对 Microsoft Sentinel 事件和警报的唯一内嵌自动响应选项。
该方案中部署的一个逻辑 app 是Azure-Monitor-Guest-Health-Alerting(图 6-21 )。这个逻辑应用从 Azure VM 来宾运行状况警报中提取可操作的数据，并使结果易于人类阅读。逻辑应用对警报操作规则的输出进行后处理。
图 6-21
Azure Logic 应用:Azure-Monitor-Guest-Health-Alerting 格式化警报并通过电子邮件发送
作者逻辑应用
逻辑应用被指定为在 Azure VM 来宾健康警报触发时运行的 Azure Monitor 操作规则。逻辑应用由以下步骤组成:
-
当新警报到达时，延迟 1 分钟让警报出现在 Azure Log Analytics 数据库中。
-
运行 Azure Log Analytics 查询，查看在之前的 5 分钟内触发了哪些虚拟机来宾运行状况更改事件。
-
从报告警报的 Azure 资源的查询响应中解析 JSON。
HealthStateChangeEvent
| where ( MonitorName contains "logical-disks" and MonitorType contains "free-space" ) or ( MonitorName contains "memory" and MonitorType contains "available" ) or ( MonitorName contains "cpu" and MonitorType contains "utilization" )
| where CurrentMonitorState == "critical" or CurrentMonitorState == "warning"
| where EvaluationTimestamp > ago(5m)
- 运行另一个 Azure Log Analytics 查询，查看 Azure 资源的名称是什么(计算机名称)。
@{body('Run_query_and_list_results_-_HealthStateChangeEvent_')}
- 从计算机名的查询响应中解析出 JSON。
Heartbeat
| where ResourceId contains "@{items('For_each_-_value_in_HealthStateChangeEvent')?['_ResourceId']}"
| distinct Computer
图 6-22
逻辑应用末尾的发送电子邮件步骤
- 发送电子邮件通知(图 6-22 )，告知服务器名称、性能计数器的最后三个值以及超出的阈值。
@{body('Run_query_and_list_results_-_Find_Computer_name')}
来宾虚拟机运行状况警报:端到端
当警报触发时， Azure Monitor Acton 规则 通知管理员——当虚拟机来宾运行状况监控器出现警告或关键状态变化时运行——调用 Azure Monitor 操作组 虚拟机洞察运行状况警报，这将启动执行通知的逻辑应用Azure-Monitor-Guest-Health-Alerting。图 6-23 显示了最终电子邮件通知产品的外观。在生产中，您的解决方案可能会使用 API 连接而不是电子邮件向 ITSM 产品发出通知。
图 6-23
来自 Azure Logic 应用的警报通知
Azure 工作簿
作为解决方案部署的点睛之笔，一组 Azure Monitor 工作簿被部署、配置并保存到订阅中。工作簿集中部署到日志分析工作区，而不是通用 Azure Monitor 或其他范围控制台。参见图 6-24 ( CPU 热图)中的样本工作簿。
图 6-24
Azure Monitor 工作簿:CPU 热图具有“蜂巢”可视化功能
建议安装八个工作簿(图 6-25 ):
图 6-25
要安装到日志分析工作区的工作簿
-
虚拟机性能
-
虚拟机更新摘要
-
服务器可用性
-
虚拟机安全和审计
-
CPU Heatmap
-
虚拟机连接记录
-
虚拟机网络依赖关系
-
虚拟机网络连接失败
从以下 URL 下载工作簿:
https://github.com/microsoft/Application-Insights-Workbooks/tree/master/Workbooks/Virtual%20Machines
工作簿从日志分析工作区安装➤通用➤工作簿➤新➤编辑➤代码视图。将工作簿模板的全部内容粘贴到代码编辑器中，然后单击保存。点击完成编辑，再点击保存。将工作簿命名为与其工作簿标题相同的名称，并作为共享工作簿保存到 Azure 订阅中。
摘要
使用 Azure 中的原生工具和服务，可以实现对服务器核心操作系统功能的经济、可靠和有效的监控。本章涵盖了以下共同创建 Azure 监控解决方案的操作。
-
定义服务器的核心监控要求。
-
使用 Azure 策略将 Azure Arc 服务器连接到 Azure 日志分析。
-
为监控配置 Azure 日志分析工作区。
-
参与并利用 Azure Automation 进行服务器操作系统更新。
-
使用 Azure Monitor 部署相关且可操作的警报。
-
创建操作组以执行预警通知。
-
部署预设警报规则。
-
配置来宾虚拟机运行状况解决方案。
-
-
创建 Azure Monitor 操作组操作规则，以针对 VM Insights 运行状况警报状态更改发出警报。
-
创建 Azure Monitor 抑制操作规则以覆盖特定服务器上的特定规则。
-
为原始警报的后处理创作 Azure Logic 应用，以呈现更可读的警报通知。
-
导入 Azure 工作簿以展示服务器监控数据。
下一章“Azure Arc 服务器的法规和安全合规性”扩展了 Azure 监控解决方案，以包括 Microsoft Sentinel、Microsoft Defender for Cloud 和 Azure Arc SQL Server 集成。
七、Azure Arc 服务器的法规和安全合规性
在前一章“混合服务器监控解决方案”中，您构建了基于 Azure 的服务器管理功能。现在，您可以使用 Azure Monitor 对 Azure 虚拟机和 Azure Arc 服务器执行经济高效的服务器基础架构监控。利用 Azure 管理投资的一个平行且重要的机会是存在的:实现对监管和安全框架的遵从。本书中详细介绍的 Azure Arc 和微软监控代理以及 Azure 策略操作也是采用最佳实践微软企业安全解决方案的基础。
在这一章中，我们将展示 Azure Arc 代理如何与 Microsoft Defender for Cloud 进行通信，以提供可靠的实质性安全覆盖，包括集成的漏洞扫描。然后，您将了解 Microsoft Sentinel 如何作为一个解决方案安装在 Azure Log Analytics 中，以便为混合资产创建最佳的现代安全事故和事件管理(SIEM)。
我们将通过查看 Azure Arc SQL Server 的安全方面来结束本章。您将了解 Azure Arc server 和 Azure Arc SQL Server 如何融入更大的 Microsoft Azure Arc 路线图，以统一管理混合资源，甚至包括 Azure Stack HCI(超融合基础架构)
Microsoft Defender for Cloud for Azure Arc 服务器
微软使用 Azure 门户特性打包并交付其推荐的最佳实践和全面的企业安全解决方案:Microsoft Defender for Cloud。
-
在 Azure Arc 场景中，Microsoft Defender for Cloud是启用服务器工作负载保护的地方。
-
在这一章中，我们将重点介绍 Microsoft Defender for Cloud 的法规遵从性和Microsoft Defender for Cloud for servers组件。
微软云卫士
Microsoft Defender for Cloud是一个统一的基础设施安全管理系统，可为云中的混合工作负载—提供高级威胁保护，无论它们是否在 Azure 中—以及在本地。微软云卫士是 Azure 门户中的顶级控制台，如图 7-1 所示。
图 7-1
Microsoft Defender for Cloud 管理 Azure Arc 服务器上的工作负载保护
在了解 Microsoft Defender for Cloud 的作用时，与 Microsoft Defender for Cloud 类似的替代产品和竞争产品包括 Qualys Cloud Platform、AlienVault USM、Tripwire Enterprise、Nessus 和 Tenable.io。这些平台管理、协调和报告企业安全状况。这些产品包括或支持云工作负载保护平台(cwps)，用于保护公共云基础设施中的服务器工作负载。众所周知的 CWPPs 包括 Microsoft Defender for Cloud、Trend Micro Deep Security 和 Cloud One、VMware Carbon Black、Sophos Central 和 Palo Alto Networks Prisma Cloud。
实际上，Microsoft Defender for Cloud 是您的工具和朋友。使用它并依靠它来指导、关注和理解所有位置的所有平台的安全问题。如果你想在你的安全职责中进行尽职调查，你不能在微软 Defender for Cloud 的可用资源上投入太多。
Microsoft Defender for Cloud 将使用 Azure 策略与 Azure Arc 服务器进行交互。所应用的策略将与企业需要遵守的监管框架的适当控制相对应。这被称为覆盖或保护。Microsoft Defender for Cloud 覆盖适用于 Azure 订阅，然后 Microsoft Defender for Cloud 计划可以针对在覆盖的订阅中找到的“可保护的”资源类型启用。
面向云工作负载保护的 Microsoft Defender
Microsoft Defender for Cloud 的集成云工作负载保护平台(CWPP)，Microsoft Defender for Cloud，为 Azure 和混合资源及工作负载提供高级、智能的保护。注意图 7-1 中门户下部的微软云面卫士控件。
Microsoft Defender for Cloud 为特定的 Azure 资源类型提供安全警报和高级威胁保护，混合计算机是一种包含的资源类型。当谈到微软 Defender for Cloud 提供的基于 ARM 的安全保护时，Azure Arc 服务器是一等公民(与 Azure 虚拟机一起)。假设您正在将微软已经证明对其超大规模云安全有效的同一安全保护伞扩展到您自己的本地服务器。
图 7-2 是 Microsoft Defender for Cloud 的概述页面，并阐明了如何将各种各样的安全敏感资源(前三分之一)管理在一起，以生成跨平台安全警报的整合集合(中间三分之一)。下方三分之一的表面控制与 Microsoft Defender for Cloud 捆绑的高级保护附加功能。
图 7-2
Microsoft Defender for Cloud 是一个交付系统，用于向任何地方的服务器、应用和服务交付安全策略和实施
Microsoft Defender for Cloud 将您环境中的计算、数据和服务层抽象化，以便谨慎的Microsoft Defender for Cloud技术目标(合规性策略)可以跨这些异构资源类型应用:
-
面向服务器的云工作负载保护的 Microsoft Defender
-
Microsoft Defender for Cloud workload protection for App Service
-
面向存储的云工作负载保护 Microsoft Defender
-
Microsoft Defender for Cloud workload protection for SQL
-
用于 Kubernetes 的云工作负载保护的 Microsoft Defender
-
Microsoft Defender 为容器注册表提供云工作负载保护
-
Microsoft Defender for Cloud workload protection for Key Vault
-
用于资源管理器的云工作负载保护的 Microsoft Defender
-
Microsoft Defender for Cloud workload protection for DNS
面向服务器的微软云卫士
Microsoft Defender for Cloud for servers为 Windows 和 Linux 计算机增加了威胁检测和高级防御功能。作为一款产品，Microsoft Defender for Cloud workload protection for Servers 以前被称为 Azure Security Center(ASC)Standard，您可以将术语 Azure Defender for Servers 和 ASC Standard 与 Microsoft Defender for Cloud workload protection for Servers 互换使用。
使用 Microsoft Defender for Cloud 的成本很低，主要是每台服务器每月 15 美元。这是微软云工作负载保护平台的成本，在当今的网络安全市场中，这是一个巨大的价值。in-Azure 服务器和 Azure Arc 服务器的成本是一样的。Microsoft Defender for Cloud 集成了这些 Azure 服务来监控和保护 Azure Arc 服务器:
-
Microsoft Defender for Endpoint的集成许可证(仅限 Windows):Microsoft Defender for Cloud for servers 包括 Microsoft Defender for Endpoint。它们共同提供全面的终端检测和响应(EDR)功能。
-
虚拟机漏洞评估扫描:微软 Defender for Cloud 附带的漏洞扫描器由 Qualys 提供支持。(我们将在本章的下一节“Microsoft Defender for Cloud 的集成漏洞评估解决方案”中详细介绍这一点)
-
即时(JIT)虚拟机(VM)访问:当您为服务器启用 Microsoft Defender for Cloud 时，您可以使用即时虚拟机访问来锁定虚拟机的入站流量，从而减少受攻击的风险，同时在需要时提供连接虚拟机的便捷访问。
-
文件完整性监控(FIM) :当您启用 Microsoft Defender for Cloud for servers 时，您可以使用 FIM 来验证 Windows 文件、Windows 注册表和 Linux 文件的完整性。
-
对于 Linux，Microsoft Defender for Cloud 通过使用通用 Linux 审计框架 auditd 从台 Linux 机器收集审计记录。Microsoft Defender for Cloud 将 auditd 包中的功能集成到日志分析代理中。Microsoft Defender for Cloud 还通过识别 IaaS Linux 虚拟机上托管的非托管容器或运行 Docker 容器的其他 Linux 机器来执行 Docker 主机加固。
-
自适应应用控制(AAC)和自适应网络加固(ANH) : AAC 是一种智能的自动化解决方案，用于为您的机器定义已知安全应用的“允许列表”。ANH 通过根据实际流量模式强化 NSG 规则，进一步提高了安全性。
为服务器部署 Microsoft Defender 云工作负载保护
若要在您的 Azure 订阅上启用 Microsoft Defender for Cloud:
图 7-3
打开Microsoft Defender for Cloud以在 Azure 订阅上启用服务器工作负载保护
-
从微软云卫士的侧边栏中，选择入门(见图 7-3 )。
-
升级选项卡列出了符合入职条件的订阅。
-
从选择订阅以启用列表上的 Microsoft Defender for Cloud，选择要升级的订阅，然后单击升级按钮以启用 Microsoft Defender for Cloud。
角色和权限
让您的内部团队做好组织准备，开始使用 Microsoft Defender for Cloud 和 Azure 策略功能。要在生产中使用 Microsoft Defender for Cloud，您需要指定一个团队，负责从安全角度监控和治理 Azure 和非 Azure 环境。
-
为团队成员分配适合其工作的安全管理员、贡献者或读者角色。
-
就访问和使用解决方案对主要利益相关者和运营商进行培训。涵盖使用 Azure 门户、ARM 模板、Azure PowerShell、Azure CLI(命令行界面)和/或 REST API(视您的组织将如何操作 Microsoft Defender for Cloud 而定)。
Tip
只有两个 Azure RBAC 安全角色有权在订阅上启用 Microsoft Defender for Cloud:所有者和安全管理员。此外，所有者是唯一可以添加和分配法规遵从性标准的角色。
分配和自定义 Microsoft Defender for Cloud 默认策略
激活 Microsoft Defender for Cloud 向 Microsoft Defender for Cloud 资源提供商 Microsoft 注册订阅。安全。如果 Azure Security Benchmark policy initiative 既没有分配给订阅本身，也没有分配给层次结构中更高的管理组，此操作还会触发对订阅的 Azure Security Benchmark policy initiative 的分配。
Azure 安全基准
该默认策略将具有类似于“ASC Default(subscription:2cb 51234-d53f-48 F3-1234-2 CFD 189 e 1234)的名称 Microsoft 建议您检查此默认方案中的每个安全建议，以确定它们是否适用于您组织中的各种订阅和资源组。该政策将指派 Azure 安全基准倡议。
Azure Security Benchmark initiative 代表实现 Azure Security Benchmark v2 中定义的安全建议的策略和控件； https://aka.ms/azsecbm见。它是微软云默认策略倡议的捍卫者。该计划中有大约 200 个或更多的策略，包括检测没有安装日志分析代理的 Azure Arc 计算机的策略(图 7-4 )。
图 7-4
Azure 安全基准中的策略包括 Azure Arc 服务器
将 Azure 安全基准分配给包含您的 Azure Arc 服务器的订阅或资源组后，每个 Azure Arc 服务器将开始报告其合规状态。在 Azure 门户➤ Azure Arc 服务器➤运营➤策略刀片上显示了对该计划的总体遵从性和对该计划中每个特定策略的单独遵从性。
评估政策合规性
如果你遵循了本书中的步骤，你的 Azure Arc 服务器已经被 Enable Azure Monitor for VMs 策略计划覆盖(参见第 6 “混合服务器监控解决方案”一章的“Azure 策略”部分)。在这种情况下，Azure Arc 服务器策略刀片可能看起来如图 7-5 所示。
图 7-5
分配给 Azure Arc 服务器的 Azure 安全基准
图 7-5 中的 Azure Arc 服务器符合启用虚拟机 Azure 监控策略，但不完全符合 ASC 默认订阅策略。点击 ASC Default subscription 计划，进入该计划中所有政策的列表。服务器不符合的策略排列在顶部(图 7-6 )。
图 7-6
分配给 Azure Arc 服务器的 Azure 安全基准
请注意图 7-6 的顶部，服务器仅不符合计划中 199 个策略中的一个。列表顶部是一个不合规的策略:执行软件漏洞评估。Azure Arc 服务器已经符合我们在图 7-4 中看到的日志分析代理策略，因为为虚拟机启用 Azure Monitor 计划包含相同的单独策略！您需要做的唯一额外的事情是部署一个漏洞评估，我们将在本章中讨论如何做，在“集成的漏洞评估”一节中。
Tip
使用合规性标准时，需要验证或设置一些参数，甚至包括 ASC 默认值。例如，CMMC 要求您声明哪些帐户应该属于本地管理组；然后，它进行审计，以确保只有这些帐户在本地管理组中。
选择行业标准并实现合规性
Azure 拥有业内最广泛、最深入的合规产品组合。Azure 合规产品是全球性的，有 60 多种产品特定于 20 多个地区和国家。Azure 也是为关键行业的特定需求而构建的，并符合 50 多种特定于保健、政府、金融、教育、制造和媒体行业的法规遵从性产品。超过 100 个 Azure 合规产品的完整列表可在以下网址找到:
https://docs.microsoft.com/en-us/azure/compliance/
这些合规产品的子集默认包含在 Microsoft Defender for Cloud 中，或者可以轻松导入到法规遵从性控制面板中，然后分配给订阅。使用 Microsoft Defender for Cloud 中的法规遵从性仪表板，您可以将您的资源配置与行业标准、法规和基准的要求进行比较。
将特定行业和地区要求转化为可操作和可审计的安全控制的能力是 Microsoft Defender for Cloud platform 的一项战略性增值。表 7-1 列出了每个类别的产品。
表 7-1
可出现在 Microsoft Defender for Cloud Compliance 控制面板上的监管框架
|现成的产品
|
可以添加预构建的产品
|
| --- | --- |
| Azure 安全基准 | NIST SP 800-53 R4 和 171 R2 |
| PCI DSS 3.2.1 | 中国移动三级 |
| 国际标准化组织 27001 | UKO 和英国国民健康保险制度 |
| SOC TSP (SOC 2 类型 2) | 蓝色 CIS 1.1.0 和 1.3.0 |
| | 加拿大联邦 PBMM |
| | HIPAA HITRUST |
| 定制产品 | SWIFT CSP CSCF v2020 |
| 任何作为产品的定制方案 | ISO 27001:2013 |
| | 新西兰 ISM 受限 |
要添加一个预构建的产品，禁用一个现成的产品，或者添加一个自定义计划，请导航到 Microsoft Defender for Cloud ➤云安全➤法规遵从性，然后单击管理遵从性策略按钮，如图 7-7 所示。
图 7-7
访问管理遵从性策略功能
您可以使用预构建的产品作为指南来构建自己的定制产品。自定义产品是一种自定义策略方案，包含构成合规性标准的所有单个策略。您的定制服务可能包括许多预构建的单独策略，以及您可能添加的一些额外的定制策略，以创建一个定制的策略组合，包括一些内置策略和一些定制策略。
Tip
在本书范围之外，但网络安全专业人士感兴趣的是另一个主要的微软安全解决方案:微软合规管理器，这是微软 365 合规中心内的一个端到端合规管理解决方案。通过以下网址了解更多信息:
https://docs.microsoft.com/en-us/microsoft-365/compliance/compliance-manager
评估法规遵从性
如果您想要咨询您的组织对其中一个“现成”标准的合规性，或者在您添加了预构建或自定义标准之后，请导航到 Microsoft Defender for Cloud ➤法规合规性，然后单击与您想要查看的产品对应的选项卡。图 7-8 显示，在分配 HIPAA HITRUST 标准后，27 台虚拟机和 Azure Arc 服务器中有 11 台缺少变更单，无法在生产部署前进行补丁测试和验证。
图 7-8
评估组织对特定法规标准控制的遵从性
一个单独的 Azure Arc 服务器将在 Azure Arc 服务器➤设置➤安全刀片上显示 Microsoft defender for cloud integration，如图 7-9 所示。列出了基于从启用的监管标准应用的策略的建议。如果此服务器在过去 21 天内涉及任何安全事件或警报，这将反映在此页面上。
图 7-9
Microsoft Defender for Cloudfor servers，活跃在 Azure Arc 服务器上
Microsoft Defender for Cloud 看似简单的界面隐藏了一些非常强大的安全工具。点击建议部分下的查看安全中心中其他资源的其他建议链接，将打开一个新窗口，其中包含您不遵守的所有策略的交互式视图(图 7-10 )。
图 7-10
Microsoft Defender for Cloud适用于 Azure Arc 服务器上的活动服务器
这一观点的强大之处在于，每一项具体建议对安全性的贡献将会得到评分。影响越严重，乘以需要补救的实例数量，就会得出一个数值，帮助您确定安全工作的优先级。通过这种方式，在分布式混合环境中实施企业安全的巨大任务变得更加容易实现。抓住每一个机会补救下一个影响最大的未减轻的安全风险，直到不存在为止。
创建合规例外
当您通过执行建议的操作来补救安全风险时，您会看到合规性仪表板报告—中的结果，因为您的合规性得分提高了(评估大约每 12 小时运行一次)。但是有些政策根本不适用于您的环境，或者在尽职调查后，被视为已知风险。在这些情况下，您可以创建特定策略的例外。
-
For policies that are built into Microsoft Defender for Cloud and included in the secure score, you can create exemptions for one or more resources directly in the portal as follows:
图 7-11
从特定建议中免除 Azure Arc 服务器
-
打开特定建议的“建议详细信息”页面，例如“日志分析代理应该安装在基于 Windows 的 Azure Arc 计算机上。”
-
从页面顶部的工具栏中选择免税(图 7-11 )。
-
单击刀片底部的豁免按钮；然后选择要豁免的资源。
-
选择减轻或放弃并点击创建按钮。
-
对于其他策略，您可以按照 Azure 策略豁免的说明，直接在策略本身中创建豁免。我们在第六章“混合服务器监控解决方案”的“Azure 策略:豁免”一节中介绍了这个过程
Tip
没有明确的方法来审查 Microsoft Defender for Cloud 的现有豁免。要复查您已创建的免税，请咨询➤保单拟定➤免税。请注意，将为资源和策略的每个适用合规标准创建一个豁免。
综合脆弱性评估
概观
Microsoft Defender for Cloud 中的集成漏洞扫描器具有巨大的价值，应该包含在您组织的网络防御计划中。一般来说，漏洞扫描器是一种发现其他实体(如网络和计算机)弱点的软件。在通常的实践中，它们用于识别和检测由基于网络的资产(如防火墙、web 服务器或应用服务器)中的错误配置或有缺陷的编程引起的漏洞。
内部和外部漏洞扫描
想象一下在没有正确更新相关安全性的情况下，未能应用安全补丁或进行系统修改。这些罕见但可预测的情况为剥削创造了媒介。如果更多组织使用漏洞扫描器测试他们的环境，许多恶意入侵和勒索事件本来是可以避免的。因此，PCI DSS 11.2 以及其他法规遵从性框架要求以电子方式存储、处理和/或传输持卡人数据的组织运行内部和外部漏洞扫描。
PCI DSS 需要两种独立的漏洞扫描方法:内部和外部。外部漏洞扫描在您的网络外部执行(例如，在您的网络外围)，它可以识别网络结构中的已知弱点。内部漏洞扫描在您的网络中执行，它会查看同一网络中的其他主机以识别内部漏洞。
Microsoft Defender for 云和内部扫描
部署和使用与Microsoft Defender for Cloud for servers捆绑的集成漏洞扫描器，可以帮助您的组织在 Windows 和 Linux 服务器上实现内部扫描目标。这是通过将漏洞扫描卸载到 Qualys 云服务来实现的，如图 7-12 所示。
图 7-12
集成漏洞扫描器的工作原理。(来源:微软)
ASC 附带的漏洞扫描器由第三方服务提供商 Qualys 提供支持。Qualys 的扫描仪是业界领先的实时识别漏洞的工具。它仅适用于 Microsoft Defender 的服务器云工作负载保护。你不需要 Qualys 许可证，甚至不需要 Qualys 帐户—一切都在 Microsoft Defender for Cloud 中无缝处理。请注意，扫描仅针对运行代理的设备，没有“设备发现”或“无代理扫描”组件。
漏洞扫描器扩展工作流程如下(图 7-12 中编号的步骤):
-
从 Microsoft Defender for Cloud 部署 Azure 策略以执行漏洞评估。
-
Azure VMs 和 Azure Arc 服务器将遥测数据转发给定义区域中的 Qualys 云服务进行分析。
-
Qualys 的云服务进行漏洞评估，并将其结果发送给微软云卫士。
-
调查结果在 Microsoft Defender for Cloud 中报告，并将指导您的补救优先级和行动。
将集成扫描仪部署到您的 Azure Arc 服务器上
按照以下步骤开始使用 Qualys 漏洞扫描程序来扫描受 Microsoft Defender for Cloud 保护的服务器:
图 7-15
部署由 Qualys 支持的集成漏洞扫描器
- 如图 7-15 所示，确认正在补救的资源数量以及您正在部署由 Qualys 提供支持的 Microsoft Defender for Cloud 集成漏洞扫描器(包含在 Microsoft Defender for Cloud workload protection for servers 中),然后单击继续。
图 7-14
选择接收漏洞检查解决方案的计算机
-
在您的 Azure 门户中导航到➤微软云卫士主页。
-
从 Microsoft Defender for Cloud 菜单中，打开建议页面。
-
Type “vulnerability” in the Search recommendations box as shown in Figure 7-13. Locate and click on the recommendation “A vulnerability assessment solution should be enabled on your virtual machines.”
-
请注意，对于建议，您的部分或全部计算机将被归类为不健康资源。此列表中的“不健康”表示可以将漏洞扫描程序部署到该计算机。
-
您可能会看到一些被归类为不适用资源的计算机。此处列出的计算机不能部署漏洞扫描程序扩展。原因可能是它是 AKS 群集中的映像，它是虚拟机规模集(VMSS)的一部分，或者它没有运行集成漏洞扫描程序支持的操作系统之一。
图 7-13
找到将启用漏洞扫描的控件
-
-
一个刀片将打开，列出不健康的资源，如图 7-14 所示。请注意，您的混合资产中的所有计算机将被统一列出——Windows 和 Linux、in-Azure 和 Azure Arc。从不健康的机器列表中，选择要接收漏洞评估解决方案的机器，然后单击修复按钮。
图 7-16
将 Windows 和 Linux Azure Arc 服务器纳入内置漏洞评估解决方案
-
在修复资源页面，确认选择的资源是您想要加载到解决方案的服务器，点击修复资源按钮，如图 7-16 所示。
-
fix resources 命令为每台机器启动提供者类型Write servervulnerability assessment的 Azure Resource Manager (ARM)部署。
-
Windows 机器将安装 WindowsAgent。ARM 部署安装的 AzureSecurityCenter 扩展。对于 Linux 机器，这个扩展被命名为 LinuxAgent。AzureSecurityCenter 。
-
你会在 Azure Arc 服务器的设置➤扩展页面上看到正在创建的扩展。你也可以在 Azure 订阅的活动日志(主页➤活动日志)中跟踪 ARM 部署的进度。
-
Windows 计算机将在控制面板➤程序和功能中显示由 Qualys，Inc .发布的应用 Qualys 云安全代理。当你运行 apt list - installed 命令时，Linux 电脑会列出 qualys-cloud-agent 。
-
-
成功部署扩展后，扫描会自动开始。扫描将每隔 4 小时运行一次。这个时间间隔是不可配置的。
Tip
目标机器必须能够与 Qualys 的云服务通信。如果您控制要扫描的服务器的 Internet 访问，请将以下 IP 添加到允许列表(HTTPS 协议，TCP 端口 443):
64 . 39 . 104 . 113-哪些美国数据中心
154.59.121.74—Qualys 的欧洲数据中心
如果机器在欧洲 Azure 地区，它的工件将在 Qualys 的欧洲数据中心处理。位于其他地方的机器的工件被发送到美国数据中心。
自动化大规模部署
上一节中的步骤“将集成扫描器部署到您的 Azure Arc 服务器”，可以根据需要随时手动重复，以保持所有生产服务器注册到解决方案中。对于较大的环境，有多种大规模自动化工具可用于部署解决方案。
Azure 资源管理器(ARM)
该方法可从微软 Defender for Cloud 推荐的 blade 获得。返回图 7-14 中的视图，在页面的受影响资源部分的正上方，在修复步骤部分，点击查看修复逻辑按钮。将显示自动修复脚本内容。内容是部署解决方案的 ARM 模板；将内容复制出来，用“.”保存为文本文件。JSON”扩展。对于您的组织喜欢的任何自动化解决方案，使用 JSON 格式的模板。
Azure 策略
将自定义策略在此 GitHub URL 的虚拟机上部署 Qualys 漏洞评估解决方案导入您的 Azure 订阅:
您可以在 Azure 订阅、资源组或管理组级别分配此策略(如图 7-17 所示)。
图 7-17
分配此自定义 DeployIfNotExists 策略以启用将解决方案部署到计算机的修正任务
Azure PowerShell
使用qualys-remediate-unhealthy-VMs . PS1脚本为所有运行不正常的虚拟机部署扩展。要在新资源上安装，考虑用 Azure Automation 自动化脚本。该脚本查找 ASC 建议发现的所有不健康的机器，并执行 ARM 调用来部署解决方案。从以下 GitHub URL 下载脚本:
Azure Logic 应用
使用 Microsoft Defender for Cloud 的工作流自动化工具来触发如图 7-18 所示的逻辑应用，以便在为资源生成漏洞评估解决方案时部署扫描器。
图 7-18
Azure Logic 应用由微软云卫士推荐触发
基于您可以从以下 GitHub 位置部署的Install-vulnasesmentagent示例应用构建一个逻辑应用:
在导入逻辑应用之后，您确实需要编辑逻辑应用，并使用 API 连接凭证定制创建或更新模板部署步骤，该凭证有权写入您的 Azure VM 或 Azure Arc 服务器资源。定制完成后，在 Microsoft Defender for Cloud 控制台中呈现建议的任何位置，您都可以单击触发器按钮来部署解决方案，如图 7-19 所示。
图 7-19
手动触发逻辑应用以在机器上安装扩展
Azure REST API
要使用 REST API 部署集成漏洞评估解决方案，请对以下 URL 发出 PUT 请求，并添加相关的资源 ID: https://management.azure.com/<resourceId>/providers/Microsoft.Security/serverVulnerabilityAssessments/default?api-Version=2015-06-01-preview
触发按需扫描
您可以使用本地或远程脚本或组策略对象(GPO)从计算机本身触发按需扫描。或者，您可以在修补程序部署作业结束时将按需扫描集成到您的软件分发工具中。以下命令会触发按需扫描:
窗户
REG ADD HKLM\SOFTWARE\Qualys\QualysAgent\ScanOnDemand\Vulnerability /v "ScanOnDemand" /t REG_DWORD /d "1" /f
Linux
sudo /usr/local/qualys/cloud-agent/bin/cloudagentctl.sh action=demand type=vm
查看和补救调查结果
当漏洞评估工具报告漏洞时，Microsoft Defender for Cloud 会将调查结果和相关信息作为建议呈现。此外，调查结果还包括相关信息，如补救步骤、相关简历、CVSS 分数等。按照以下步骤查看和修复计算机上漏洞评估扫描的结果:
图 7-20
Microsoft Defender for Cloud将为发现的漏洞提供补救说明
-
在您的 Azure 门户中导航到➤微软云卫士主页。
-
从安全中心菜单中，打开建议页面。
-
在搜索建议框中键入“漏洞”。找到并单击建议“应修复虚拟机中的漏洞”
-
展开安全检查，在调查结果选项卡中看到您的漏洞，如图 7-20 所示。
图 7-20 还展示了 Microsoft Defender for Cloud 如何帮助您更快地实现合规性。在这个例子中，Qualys 扫描器已经识别出流行的 SSH 工具 PuTTY 的一个易受攻击的版本。扩展补救特别列出了要升级到哪个安全版本的 PuTTY，甚至还有一个下载网站的超链接。
禁用特定调查结果
如果您的组织需要忽略某个调查结果，而不是修复它，您可以选择禁用它。禁用的搜索结果不会影响您的安全分数或产生不必要的噪音。
一个示例场景可能是一个组织需要继续使用 Adobe Flash Player ，因为一个关键的业务线应用仍在使用它。在执行尽职调查以接受风险并可能实施其他缓解或保护措施后，继续禁用调查结果:
-
在虚拟机中的漏洞应修复的建议详细信息页面中，选择禁用规则。
-
选择相关范围，例如您的订阅。
-
定义你的标准。您可以使用以下任何标准:
-
查找 ID
-
种类
-
安全检查
-
CVSS 分数(v2，v3)
-
严重
-
可修补状态
-
对于本例，我们使用“105943”查找与该 PuTTY 漏洞对应的 ID 。
-
可选地，在提供的区域输入一个调整，并点击应用规则按钮。应用于订阅的新禁用规则可能需要 30 分钟才能生效。禁用规则生效后，该项目将从调查结果列表中删除。
-
A list of all Disabled findings is available as seen in Figure 7-21. Notice your justification comments are preserved in the Reason column.
图 7-21
禁用的调查结果是跟踪您选择忽略的建议的一种方式
微软哨兵和 Azure Arc 服务器
每个拥有两个或更多安全数据源的组织都需要一个 SIEM(安全信息和事件管理)工具，这意味着每个组织。SIEM 是不同但安全敏感的平台发送其实时安全数据的地方，用于集中收集和分析。如果您没有实际的 SIEM 解决方案，您的 ITSM 票务系统或电子邮件收件箱可能会充当您的 SIEM。在某种程度上，所有组织都成熟到可以并且必须部署专用安全工具来执行安全事件和事故关联和调查的程度。
Microsoft Sentinel 是基于云的 SIEM，也是唯一的原生云 SIEM。竞争对手的云 SIEMs 包括 Splunk 安全云、美国电话电报公司 AlienVault USM Anywhere 和 IBM QRadar on Cloud。如果您的组织没有投资这些或类似的 SIEMs，而您已经部署了本书中描述的解决方案，如 Azure Arc、Azure Monitor、Azure Log Analytics 和 Microsoft Defender for Cloud，那么将 Microsoft Sentinel 添加到您的安全堆栈中应该是一个容易的决定。您可能会获得当今世界上最好的 SIEM，而成本只是添加第三方企业 SIEM 的一小部分。
如果您有 Azure 之外的服务器，采用 Azure Arc 的一个主要原因可能是将 Microsoft Sentinel 部署为您的企业 SIEM。如果您正在执行最佳实践 Microsoft Sentinel 部署—,并且您的 IT 资产包括本地服务器、私有云和托管服务器，或者 AWS 和/或 Google cloud 中的服务器，您应该从 Azure Arc 部署开始您的 Microsoft Sentinel 部署。推广 Microsoft Sentinel 作为 SIEM 的高级步骤如下:
-
在非 Azure 服务器上安装 Azure Arc 代理，使用 Azure 虚拟机拥有的虚拟机扩展为它们提供相同的带外控制。
-
将 Azure 策略分配给所有云中的所有服务器，这些服务器使用 VM 扩展将它们连接到特定的 Azure Log Analytics 工作区。
-
在你的 Azure 订阅中，在所有服务器连接的日志分析工作区中安装一个 Microsoft Sentinel 实例。
事实上就是这么简单:微软 Sentinel 是 Azure Monitor 和 Azure Log Analytics 的超集，两者都(1)将来自服务器的安全数据与来自其他平台(如防火墙和云服务登录，如 Office 365)的安全数据相关联，以及(2)处理服务器安全数据本身以发现异常和威胁指标。
将 Microsoft Sentinel 添加到日志分析实例中，对于给定的一组服务器，Azure 每月服务的成本将增加一倍。Microsoft Sentinel 是您的服务器可能已经消耗的日志量之外的附加成本。表 7-2 给你一个思路；在更高的利用率(>50gb/月)下，预承诺层提供批量折扣。(您可以从 50 GB 的利用率开始获得 100 GB 的价格折扣。)
表 7-2
Azure Monitor 与 Microsoft Sentinel 摄取成本的比较
|(美国东部，90 天保留期)
|
天蓝色监视器
|
蔚蓝哨兵报
|
| --- | --- | --- |
| 50gb/月 | $3,438.50 | 3，000.00 美元(增加 87%) |
| 100 GB/月 | $5,880.00 | 3，000.00 美元(增加 51%) |
| 200 GB/月 | $11,040.00 | 5，400.00 美元(增加 48%) |
将 Microsoft Defender for Cloud 数据导出到 Microsoft Sentinel
Microsoft Defender for Cloud 可以非常轻松地连接到 Microsoft Sentinel。有一种全功能的无成本连接模式和一种可选模式，这种模式会对日志接收产生微费用。
针对云集成的补充性 Microsoft Defender
在 Microsoft Sentinel 控制台中，导航至配置➤数据连接器。找到 Microsoft Defender for Cloud 并单击打开连接器页面按钮。在订阅列表中，移动滑块到连接位置，如图 7-22 所示。
图 7-22
一键连接 Microsoft Defender for Cloud 和 Microsoft Sentinel
图 7-22 中显示的集成将导致来自 Microsoft Defender for Cloud 的安全警报出现在安装了 Microsoft Sentinel 的 Azure Log Analytics 实例中。根据最佳实践启用的 Microsoft Sentinel 分析规则(基于 Azure 安全中心警报创建事件)将在 Microsoft Defender for Cloud 警报触发时创建 Microsoft Sentinel 事件。
实现这种集成是没有成本的；也就是说，没有 Microsoft Sentinel 数据接收费用。这种模式对于许多环境来说已经足够，当 Microsoft Defender for Cloud 发出警报时，将实时创建 Microsoft Sentinel 事件。
图 7-23 是来自 Azure Arc 服务器的微软 Defender for Cloud sourced Microsoft Sentinel 事件。可疑认证活动事件经调查发现来自 Exchange 服务器，在 IIS 日志中，有一个字典攻击试图通过 SMTP 认证来转发垃圾邮件。
图 7-23
Azure Defender 在 Azure Arc 服务器上发现安全事件
Tip
使用 Microsoft Sentinel 接收和管理由 Microsoft 安全服务引发的事件不会产生任何数据处理成本。即使您的组织不打算将 Microsoft Sentinel 用于其他目的，连接这些服务也将为这十个异构数据源提供基本上免费的单一管理平台:
Azure 活动日志
Office 365 审核日志(SharePoint 和 Exchange 活动)
微软 365 卫士
Microsoft Defender for Office 365
微软身份卫士
Microsoft Defender for Endpoint
微软云卫士
面向云应用的 Microsoft Defender
Azure 信息保护(AIP)
用于云数据导出的附加 Microsoft Defender
除了 Microsoft Sentinel 与 Microsoft Defender for Cloud alerts 的集成之外，您还可以选择将其他 Microsoft Defender for Cloud 产品(如漏洞评估结果、安全评分和法规遵从性消息)导出到 Azure Log Analytics。如果您在同一个工作区安装了 Microsoft Sentinel，Microsoft Sentinel 也会接收额外的数据，但不会像 Microsoft Defender for Cloud alerts 那样自动支持事件创建。
启用这种日志记录模式确实会产生 Azure Log Analytics，并且可能会产生 Microsoft Sentinel 基于每 GB 容量的处理费用。虽然这些类型的消息的预期数量会产生非常小的微费用，但是对于大多数环境来说，这种成本是微不足道的(但非零)。
要启用从 Microsoft Defender for Cloud 到 Azure Log Analytics 的额外数据导出:
图 7-24
支持将其他Microsoft Defender for Cloud数据导出到 Azure Log Analytics 工作区
-
导航至主页➤ Microsoft Defender for Cloud ➤管理➤环境设置➤
➤连续导出。 -
选择 Log Analytics workspace 选项卡，打开Export enabled。
*** 根据需要选择导出的数据类型；示例如图 7-24 所示。如果您已经启用了默认的 Microsoft Sentinel 集成，请避免导出安全警报类型，以避免对这些事件发出双重警报。
* 选择资源组和目标工作区，点击**保存**按钮。
**
**可选地基于日志分析查询创建 Azure Monitor 日志警报，以查看 Azure Monitor 中的导出类型并触发警报规则，例如当漏洞评估包含高优先级发现时。
使用内置向导抢先创建 Azure Monitor 警报规则:
-
启用连续导出后，一直滚动到连续导出设置页面的底部，并点击链接继续与 Azure Monitor 集成。
-
选择日志警报为导出的建议创建警报规则并点击创建按钮。
-
导航到主页➤日志分析工作区➤警报规则并找到规则【azure 安全中心】新安全建议。单击以编辑规则。
-
在条件部分中，每当平均自定义日志搜索大于 0 时，单击连接名称。
-
在基于部分评估的中，将周期和频率从 5 分钟更改为 60 分钟。(这将把监控规则本身的成本从每月 1.50 美元降低到每月 0.15 美元以下。)
-
在操作部分，单击添加操作组，然后选择并添加您的首选通知操作组。如果你还没有动作组，你可以创建一个动作组
—页面顶部有一个创建动作组控件。 -
点击保存按钮。
Microsoft Defender for Cloud vulnerability 在报告扫描结果时会扫描 SecurityRecommendation 类型的日志数据。在每小时检查期间，如果在日志分析数据库中发现 SecurityRecomendation 类型的未来数据，您将会收到通知。
Tip
如果您只想在发现高严重性时接收警报，请按如下方式编辑警报规则中的查询:
SecurityRecommendation
| where RecommendationSeverity contains "High"
Azure Arc 服务器的 Microsoft Sentinel 分析规则
微软 Sentinel 内置了 120 多种服务和云应用的连接器。要启用的连接器的选择基于组织中的安全数据源。与 Azure Arc 服务器特别相关的微软 Sentinel 数据连接器有
-
微软云卫士
-
域名服务器(Domain Name Server)
-
安全事件
-
Windows 防火墙
这些是应用于运行 Windows 和 Linux 并执行 IaaS 角色的 Azure 虚拟机的相同连接器。当 Azure 虚拟机和 Azure Arc 服务器中的一个或两个被监控时，建议启用这些连接器。
Tip
启用安全事件数据连接器时，建议从通用事件设置开始。所有事件设置可能相当昂贵，而最小设置不提供完整的审计跟踪。
每个数据连接器在其打开的连接器页面➤后续步骤选项卡上显示一个相关分析模板的列表。以下是建议启用的分析活动规则，从相关连接器的模板列表中收集。
分析活动规则
这些 Microsoft Sentinel Analytics 警报规则与 Azure Arc 服务器尤其相关:
-
所有镓、铱、锌、磷、铊、铈、锶、钡和锕规则
-
基于 Azure Defender 警报创建事件
-
检测到潜在的 DGA
-
观察到具有高反向 DNS 查找计数的罕见客户端
-
Solorigate 网络信标
-
TI 将电子邮件实体映射到安全警报
-
TI 将 URL 实体映射到安全警报数据
-
TI 将域实体映射到安全警报
异常规则
异常规则必须在生成异常之前激活。一旦异常规则被激活，检测到的异常将被存储在 Microsoft Sentinel 工作区的日志部分的异常表中。
图 7-25
异常表中关于 Azure Arc 服务器的条目
-
每个异常规则都有一个训练期，在训练期结束之前，异常不会出现在表中。你可以在每个异常规则的描述中找到训练周期(一般是 7 天或 14 天)。
-
一旦异常规则开始产生异常检测，如图 7-25 所示，您可以选择创建适合您环境的警报规则。
有关使用异常规则的更多信息，请参考以下参考 URL:
https://docs.microsoft.com/en-us/azure/sentinel/work-with-anomaly-rules
这些 Microsoft Sentinel 异常规则与 Azure Arc 服务器尤其相关:
-
尝试用户帐户和计算机暴力
-
用户帐户和计算机的可疑登录量
-
使用提升的令牌登录用户帐户的可疑数量
-
按登录类型划分的用户帐户可疑登录量
-
每种登录类型尝试的用户帐户暴力
-
使用提升的令牌登录计算机的可疑数量
-
检测机器生成的网络信标行为
-
异常网络容量异常
-
过度数据传输异常
-
异常 web 请求活动
-
每个失败原因的用户帐户暴力尝试
准备和部署逻辑应用
作为微软 Sentinel 的用户，你将需要部署一个或多个作为 Azure 逻辑应用的剧本来与微软 Sentinel 事件进行交互。Azure Logic 应用是 Microsoft Sentinel 中唯一可用于高级通知、自动化和事件工作流的机制。
定位和部署行动手册
随着时间的推移，每个生产 Microsoft Sentinel 环境都将收集和采用行动手册，以提高安全团队的效率和效力。大多数从执行基本通知操作的单一剧本开始。随着事件处理需求和自动化机会的出现，引入了更多更复杂的行动手册。
幸运的是，在创建您的自定义逻辑应用集合时，有大量的社区资源可供利用。GitHub URL 上有数百个行动手册可供导入:
https://github.com/Azure/Azure-Sentinel/tree/master/Playbooks
剧本使用示例
作为向 Microsoft Sentinel 报告的 Azure Arc 服务器如何从行动手册中获得价值的示例，请考虑前面 URL 中的Get-GeoFromIpAndTagIncident行动手册。本行动手册将从事件中提取 IP 地址实体，并查询 Geo-IP API 以地理定位 IP 地址。它会将城市和国家写在事件标签上。在调查事件时，本行动手册将为您节省对潜在威胁的来源 IP 进行地理查找的时间。
将行动手册导入 Microsoft Sentinel 实例后，您需要编辑行动手册并为行动手册任务提供必要的安全凭证，以便行动手册有权向 Microsoft Sentinel 事件添加标记。此外，为每个任务(最低任务)编辑的设置，如下所示:
-
右键点击椭圆“…”控件，点击设置。
-
将并发控制设置为上的，将并行度设置为 1 。
-
点击完成。
然后保存行动手册，并准备好针对现有事件运行。
使用 Get-GeoFromIpAndTagIncident
- 要用地址对应的城市和国家代码标记包含 IP 地址的现有事件，请执行以下操作:
-
选择事件并点击查看全部细节按钮。
-
单击“Alerts”选项卡并一直滚动到左侧，以显示查看行动手册链接；然后点击链接。
-
找到Get-GeoFromIpAndTagIncident剧本并点击 Run 按钮。
-
使用 Get-GeoFromIpAndTagIncident-Auto
图 7-26
两个版本的逻辑应用，一个用于手动运行，一个用于自动雇佣
- 要自动标记包含 IP 地址的未来事件:
-
在 Microsoft Sentinel ➤配置➤自动化➤行动手册中，找到get-geofromipandtagincident行动手册，并单击它打开 logic 应用。
-
点击克隆按钮，将克隆命名为Get-GeoFromIpAndTagIncident-Auto。点击创建。
-
现在打开克隆剧本GeoFromIpAndTagIncident-Auto并点击编辑按钮。
-
当对 Azure Sentinel 警报的响应被触发时，删除顶层任务。(右击椭圆“…”控件并选择删除。)
-
当 Azure Sentinel 事件创建规则被触发时，添加触发器作为顶层任务。
-
用新任务替换第二级任务，获取事件并使用事件臂 ID: 事件臂 ID 。
-
用新的任务实体替换第三级任务——获取 IPs 并使用实体列表:实体。
-
对于每 2 个，用新的替换最低级别的任务(对于每个)。
-
选择前面步骤的输出:
@body('Entities_- _Get_IPs')?['IPs'] -
使用 URI
http://ip-api.com/json/@{items('For_each_2')?['Address']}将 HTTP GET 复制到 HTTP2 GET 步骤 -
使用内容:
@{body('HTTP_2')}将解析 JSON 复制到解析 JSON 2 步骤。还要将模式从 Parse JSON 复制并粘贴到 Parse JSON 2。 -
创建新的最低阶步骤更新事件。
-
事故臂 id: 事故臂 ID
-
要添加标签的标签–1:
@body('Parse_JSON_2')?['city'] -
要添加标签的标签–2:
@body('Parse_JSON_2')?['country']
-
-
-
从逻辑应用画布中删除原始逻辑应用中剩余的任何步骤，并点击保存。图 7-26 左边显示的是原始的逻辑应用，右边显示的是编辑后的克隆。
-
-
在微软➤哨兵配置➤自动化，选择创建 ➤ 添加新规则。
-
将自动化规则命名为，使用 IP 地址对所有事件进行地理标记。
-
在操作中，选择运行行动手册。选择剧本Get-GeoFromIpAndTagIncident-Auto。(只有当 Azure Sentinel 事件创建规则触发触发器时，带有的剧本可供选择。)
-
键入一个不是最高编号订单的订单编号(这不应该是运行的最后一个自动化规则)，并点击应用按钮。
现在，当您手动运行剧本Get-GeoFromIpAndTagIncident或使自动化规则地理标记所有具有 IP 地址的事件以编程方式运行剧本Get-GeoFromIpAndTagIncident-Auto时，事件将被标记城市和国家，如图 7-27 所示。
图 7-27
剧本为事件添加了城市和国家标签
Tip
Get-GeoFromIpAndTagIncident 行动手册将按配置工作，但当一个或多个 IP 在私有 IP 范围内时，如 10.x 或 192.168.x，将抛出错误。为了避免错误消息，在解析 JSON (或解析 JSON 2 )之后添加一个新的条件步骤。条件步骤如下:@body('Parse_JSON')?['status']或@body('Parse_JSON_2')?['status']不包含失败。将最底层任务(添加事件标签或更新事件)移入真结果任务，并将假结果任务留空。
工作簿和仪表板
像 Azure Monitor 一样，Microsoft Sentinel 利用 Azure 工作簿进行交互式可视化。特别是对于 Azure Arc 服务器，有一些特定的工作簿模板您应该考虑保存到您的订阅中，并在您的日常安全管理职责中使用。
-
在 Microsoft Sentinel 控制台的威胁管理➤工作簿➤模板中找到工作簿模板。
-
选择您想要开始使用的每个工作簿，然后单击保存按钮。
-
保存的工作簿可在威胁管理➤工作簿➤我的工作簿中找到。
-
点击查看保存的工作簿按钮，使用您保存的工作簿。
表 7-3 列出了与 Azure Arc 服务器的每个最佳实践数据连接器相关的推荐工作簿。
图 7-28
Windows 防火墙工作簿结合了 Azure VM 和 Azure Arc 服务器防火墙日志
表 7-3
对 Azure Arc 服务器特别有用的工作簿
|数据连接器
|
推荐练习册
|
| --- | --- |
| 微软云卫士 | 网络安全成熟度模型认证(CMMC)零信任(TIC 3.0) |
| 域名服务器(Domain Name Server) | DNS《网络安全管理软件产品邮报》妥协狩猎 |
| 安全事件 | 身份和访问不安全的协议 |
| Windows 防火墙 | Windows 防火墙(如图 7-28 所示) |
Tip
即使您的组织没有在 Windows 服务器上使用 Windows 防火墙组件，您也可以利用防火墙日志的收集来获得高价值的安全指示。图 7-29 显示了一个建议的组策略对象(GPO ),当您在 Microsoft Sentinel 中启用 Windows 防火墙数据连接器时，该对象将启用防火墙日志记录。关键设置包括:
-
大小限制(KB): 1，024
-
日志丢弃和成功连接:是
重要的是，大小限制要小(1 KB ),因为日志只有在达到选定的大小时才会上传到 Microsoft Sentinel。日志越小，Microsoft Sentinel 接收的速度越快。
图 7-29
使用 GPO 配置 Windows 防火墙日志记录
Azure Arc SQL Server
回想一下，Azure Arc 的顶级 Azure 门户页面(图 7-30 )包括服务器和 Kubernetes 集群的菜单项，这两个 Azure Arc 特性是本书的重点。我们将通过仔细观察 Azure Arc 家族的另一个成员:Azure Arc SQL Server 来结束这一章。
图 7-30
向您的 Azure 订阅添加 Azure Arc SQL Server
概观
一旦你开始将多种 Azure Arc 资源类型添加到你的 Azure 订阅中，微软对 Azure Arc 的愿景就能得到认可。正如 Azure Arc server 在功能上等同于 Azure VM ，本地 SQL Server 就像运行 SQL Server 的 in-Azure IaaS VM。 Azure Arc SQL Server 是在 in- Azure SQL 虚拟机和本地 SQL 服务器之间实现管理对等的一个步骤。
Azure SQL 虚拟机
与 Azure Arc server 的比较特指 Azure 提供的“Azure SQL 虚拟机”。这是基于 Windows Server 和 SQL Server IaaS 配置的高级 Microsoft Azure 服务产品。该产品的主要特征是 Azure 资源类型:
Microsoft.SqlVirtualMachine/sqlVirtualMachines
该资源类型允许从 Azure 门户或其他受支持的 Azure 管理工具(如 PowerShell 和 REST API)管理 SQL Server 应用。用于高可用性的高级 SQL 功能(如始终开启)和实用功能(如备份和修补)是从 Azure 控制平面管理的，而不是从服务器操作系统管理的。Azure 使用由 Windows Azure 访客代理安装的 VM 扩展Microsoft.SqlServer.Management.SqlIaaSAgent与 SQL 应用通信，该代理运行在所有 Azure VMs 上。
Azure Arc SQL 服务器
Azure Arc 支持的 SQL Server 允许您管理 SQL Server 的全球库存，使用 Microsoft Defender for Cloud workload protection for servers 保护 SQL Server 实例，并定期评估和调整 SQL Server 配置的运行状况。Azure Arc SQL Server 解决方案基于以下 Azure 资源类型:
Microsoft.AzureArcData/sqlServerInstances
就像 in-Azure 原始版本一样，这种资源类型允许从 Azure 门户或其他受支持的 Azure 管理工具管理 SQL Server 应用——即使 IaaS VM 或物理 SQL Server 在您的本地数据中心运行！Azure Arc SQL Server 的第一个版本使用CustomScriptExtension VM 扩展在 SQL Server 的操作系统中运行脚本。回想一下，在每个 Azure Arc 服务器上运行的是访客配置扩展服务，它在安装、修改和删除 VM 扩展时执行与 Windows Azure 访客代理相同的功能。
关注 SQL Server 评估
正如 Azure 虚拟机和 Azure Arc 服务器对统一的操作系统管理和安全性有着相同的需求一样，in-Azure 和非 Azure SQL 服务器也需要相同的应用和数据库配置评估。微软已经选择了 SQL Server 管理的按需评估方面来领导他们的 Azure Arc SQL Server 计划。如果您遵循了本书的建议，并为服务器部署了 Microsoft Defender for Cloud workload protection，那么将 Azure Arc SQL Server 的工作负载保护添加到您的安全计划中是一种自然的发展。
在本书中，我们展示了非 Azure Windows 和 Linux 服务器以及 Kubernetes 集群的管理特性中的奇偶校验是如何增加安全性并提高效率的。现在考虑一下，将统一的评估覆盖面引向所有位置的所有类型的 SQL 资源—,将会显著提高贵组织的数据库就绪性和安全性。
Azure Arc SQL Server:Azure Arc Server 的超集
图 7-31 在一个视图中显示了 Windows 和 Linux Azure Arc 服务器—以及 Windows 和 Linux Azure Arc SQL Server 资源—。
图 7-31
Azure Arc 服务器和 Azure Arc SQL Server 资源
在 Azure Arc server 中注册的非 Azure 服务器也运行 SQL Server，也可以选择在 Azure Arc SQL Server 中注册。这创建了两个 Azure Arc 资源:一个代表服务器本身，另一个代表 SQL Server 应用。同样，这也是微软对 in-Azure SQL 虚拟机的做法。图 7-32 是微软为了解释 Azure Arc SQL Server 如何工作而制作的。
图 7-32
SQL Arc 扩展的工作原理。(来源:微软)
图 7-32 (混合服务器)的左边部分应该是熟悉的 Azure Arc 服务器组件，在本书第四章“Azure Arc 服务器:入门”中有描述正确的部分(日志分析、安全中心、Microsoft Sentinel)在第 6 “混合服务器监控解决方案”和本章前面的章节【Azure Arc 服务器的法规和安全合规性中有所涉及。Azure Arc SQL Server 特有的是中间的 Azure 数据服务部分。
*### 将您的 SQL Server 连接到 Azure Arc
按照以下步骤开始使用 Azure Arc SQL Server:
- 通过注册 Microsoft 来准备您的 Azure 订阅。使用以下方法之一的 AzureArcData 资源提供程序:
-
蓝色门户网站
-
在 Azure 门户中导航到主页➤订阅➤设置➤资源提供商。
-
搜索
Microsoft.AzureArcData并选择寄存器。
-
-
Azure PowerShell
Login-AzAccount Set-AzContext -SubscriptionId <SubscriptionId> Register-AzResourceProvider -ProviderNamespace Microsoft.AzureArcData -
蓝色 CLI
-
- 在你的 Azure 门户中导航到➤ Azure Arc ➤ SQL 服务器，然后点击创建。
Tip
第一次为 Azure Arc SQL Server 创建 onboarding 脚本时，在您生成脚本以“激活”Azure Arc SQL Server 的第四个页面的顶部会出现一个确认提示。你按下接受键，就再也不用想它了。它很容易被忽略。
-
选择要装载的 Azure Arc SQL Server 的资源组、区域和操作系统，然后单击下一步的和运行脚本。
-
将脚本复制到剪贴板，并在要加载的 SQL Server 上将内容保存为onboardazurearcsql Server script . PS1。
-
按如下方式准备 SQL Server:
-
SQL Server 需要。NET Framework 4.7.2 或更高版本来运行 Az PowerShell cmdlets。
-
下载。NET Framework 4.8 在此链接:
go . Microsoft . com/fwlink/？linkid = 2088631 -
需要重新启动系统。
-
-
在提升的会话中运行这些 PowerShell 命令，然后重新启动 PowerShell 会话:
Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force Install-Module -Name Az -AllowClobber -Force Import-Module -Name Az.Accounts
-
-
在提升的 PowerShell 会话中运行 onboardazurearcsql server script . PS1 脚本。
-
该脚本将安装和配置文件，并在某个时候会提示您在浏览器中输入 URL 并输入代码。
-
出现提示时，使用在您的 Azure 订阅中拥有权限的凭据登录 Azure，以在您创建脚本时选择的 Azure 资源组中创建 Azure Arc 和 Azure Arc SQL Server 资源。
-
您不必在运行脚本的计算机上使用浏览器；任何能上网的浏览器都可以。
-
-
该脚本执行以下操作:
-
使用 PowerShell 检查从您的环境到 Azure 和指定计算机的连接
-
通过部署 Azure Connected Machine 代理，将主机作为 Azure Arc 服务器启动(如果尚未启动)
-
启动 SQL Server 实例发现
-
将目标计算机上的 SQL Server 实例添加到 Azure
-
当脚本成功完成时，您将看到以下消息:
SQL Server - Azure Arc resource: <servername> created
在将 SQL Server 实例注册到支持 Azure Arc 的 SQL Server (preview)后，转到 Azure 门户并查看新创建的 Azure Arc 资源。您将看到一个新的机器(Azure Arc 用于每个连接的机器)和一个新的 SQL Server (Azure Arc 资源用于每个注册的 SQL Server 实例)。
图 7-33 显示了您可以在 Azure Arc SQL Server 资源的概览页面上看到的内容。箭头指向两个位置，您将在那里找到有关 SQL server 的清单信息。
图 7-33
Azure Arc SQL Server 帮助您跨云跟踪 SQL 库存
此时，修改 Azure Arc 服务器和/或 Azure Arc SQL Server 对象上的标签，以适应贵组织中任何现有的标签管理方案。
连接 Azure Arc SQL Server for Linux
RegisterSqlServerArc 脚本将 Linux 计算机连接到 Azure Arc 服务器和 Azure Arc SQL 服务器。
-
复制 RegisterSqlServer。Arc.sh 到 Linux 服务器，并使该文件可执行:
-
运行脚本:
chmod 700 RegisterSqlServerArc.sh
- 出现提示时，选择 Y 安装 Azure CLI。
sudo ./RegisterSqlServerArc.sh
Tip
Azure Arc SQL Server 对 SQL Server Linux 版本的支持在当前预览版中是最低限度的。Azure Arc SQL Server 的环境健康和安全中心特性对于 Linux 是灰色的。Linux SQL Servers 的增值仅限于清单和标记功能。
Azure 资源图中的 SQL Server 清单
Azure Arc 的一个引人注目的特性是将您的混合资产的配置投影到 Azure Resource Manager (ARM)中。这意味着你可以使用 Azure 中所有你认为合适的管理工具来完成你的工作。Azure 门户中的 Azure Resource Graph Explorer 允许您浏览您的 Azure 资源，并可选择导出数据以用于其他记录和报告系统。
要使用 Azure 资源图浏览器查看您的 Azure Arc SQL Server 清单数据，请导航到此页面: https://portal.azure.com/#blade/HubsExtension/ArgQueryBlade
在搜索框中，过滤资源类型 Microsoft.azurearcdata/sqlserverinstances(SQL Server-Azure Arc)，点击资源类型填充查询窗口，点击运行查询。如图 7-34 所示的结果包括有关 SQL server 版本、版本、实例名称、TCP 端口和排序规则类型的信息。
图 7-34
Azure 资源图浏览器中的 Azure Arc SQL Server 属性
在结果区域点击下载为 CSV ，获得如图 7-35 所示的 SQL 清单的离线记录副本。
图 7-35
从 Azure 资源图转储的 Azure Arc SQL Server 清单
将 SQL Server 实例大规模连接到 Azure Arc
您可以使用 Azure Arc SQL Server 安装脚本在多台机器上注册 SQL Server 实例。请通过以下网址查看大规模注册方法的详细信息:
该过程与本书第五章“Azure Arc 服务器:大规模使用”中描述的过程相同，因为您将在 Azure AD 中创建一个服务主体，向服务主体授予权限，并修改大规模安装脚本以使用服务主体的凭据。
运行按需 SQL 评估
Azure Arc SQL Server 的核心是它与 SQL Server 评估的集成。Azure Arc SQL Server 提供了一种大规模部署 SQL Server 评估解决方案的机制。有两种方式将 SQL Server 评估部署到您的 Azure Arc SQL Servers:自动使用 Azure VM 扩展或通过在每个 SQL Server 上运行脚本。在图 7-36 中看到的 Azure Arc SQL Server 的环境健康页面是您开始使用这两种方法的地方。
图 7-36
从 Azure Arc SQL Server 环境运行状况页面配置 SQL 评估
无论您使用哪种方法，自动还是手动，该解决方案都会创建一个计划任务，每周运行一次 SQL Server 评估，并将报告数据上传到 Azure Log Analytics 工作区。
服务集线器连接
在尝试运行 SQL Server 评估之前，请参考此 URL 上的先决条件部分:
https://docs.microsoft.com/en-us/sql/sql-server/azure-arc/assess
特别是，您必须确保您已经将 Azure 订阅链接到微软服务中心并添加了 SQL Server 评估。您必须在 services hub 上注册，并且拥有通过同一启用电子邮件的帐户注册的 Azure 订阅的所有者或参与者权限。
使用托管服务帐户自动部署
当您可以使用托管服务帐户(MSA)方法时，请按照以下步骤在 Azure Arc SQL Server 上生成和查看评估:
图 7-37
在 Azure 门户中查看 SQL Server 评估结果
-
指定托管服务帐户以激活“配置 SQL 评估”按钮。
-
这将通过部署 CustomScriptExtension 从门户启动评估。因为一次只能部署一个 CustomScriptExtension，所以 SQL 评估的脚本扩展将在执行后自动删除。
-
如果您已经将另一个 CustomScriptExtension 部署到宿主计算机，则不会激活“配置 SQL 评估”按钮。
-
-
以 DOMAIN\MSAname$格式输入托管服务帐户，并确认工作目录，默认情况下，该目录为 C:\sql_assessment\work_dir。
-
点击配置 SQL 评估按钮。
-
然后在 Azure Arc 服务器中安装一个名为 CustomScriptExtension 的 VM 扩展。CustomScriptExtension 在 Azure Arc SQL Server 上运行 PowerShell onboarding 脚本。
-
大约 1 到 2 小时后，查看 SQL 评估结果按钮将变为非灰色。点击按钮将在新的刀片中打开评估结果，如图 7-37 所示。
使用配置脚本手动部署
使用下载配置脚本方法时，按照以下步骤在 Azure Arc SQL Server 上生成和查看评估:
图 7-38
确认 SQL 评估计划任务的每周成功运行
-
从 Azure Arc 服务器环境健康页面点击下载配置脚本按钮。
-
保存addsqlassession . PS1文件，并将其复制到 Azure Arc SQL Server。这个脚本看起来会像这样:
Add-SQLAssessmentTask -SQLServerName "WS19ArcDemo.odyssey.com" -WorkingDirectory "C:\sql_assessment\work_dir" -RunWithManagedServiceAccount $True -ScheduledTaskUsername "ODYSSEY\momActGMSA$" -ScheduledTaskPassword (new-object System.Security.SecureString) -
观察如图 7-38 所示的计划任务在服务器上的路径任务计划程序➤任务计划程序库➤微软➤运营管理套件➤ AOI- < GUID > ➤评估➤ SQL 评估中创建。
-
在 Azure Arc SQL Server 上完成预定任务后不久，如果您返回到 Azure Arc SQL Server 的 Azure portal 页面并再次单击环境健康菜单项，您将看到如图 7-37 所示的相同报告视图。
为 SQL Server 启用 Microsoft Defender for Cloud
除了 Azure Arc SQL Server 的清单、标记和 SQL 评估优势，该解决方案还有一个额外的高价值功能。这是 Microsoft Defender for Cloud workload protection for SQL Server 在 Azure 门户中的建议和来自 Microsoft Defender for Cloud on Azure Arc SQL Server blades 的安全警报。
如图 7-39 所示，Azure Arc SQL Server 将确认 Microsoft Defender for Cloud for SQL 在处于状态，并且来自 Microsoft Defender for Cloud 的任何建议或警报都很容易找到并采取行动。
图 7-39
Microsoft Defender for Cloud workload protectionfor SQL Server 为 Azure Arc SQL Server 添加了有价值的内容
正如本章前面的“Microsoft Defender for Cloud”部分所建议的，作为最佳实践，您将为所有涵盖的资源类型启用 Microsoft Defender for Cloud protection，包括 Azure Defender for SQL Server。
-
Microsoft Defender for Cloud workload protection for SQL Server 检测异常活动，这些异常活动表示对访问或利用数据库的异常和潜在的有害尝试。
-
当存在可疑的数据库活动、潜在的漏洞或 SQL 注入攻击以及异常的数据库访问和查询模式时，会触发安全警报。
摘要
本章重点介绍了 Azure Arc 如何成为组织安全服务的主要提供者。我们首先解释了 Azure Arc 如何将 Microsoft Defender for Cloud workload protection for server 的所有安全优势扩展到您的非 Azure 服务器。然后，我们详细介绍了如何使用 Qualys 的集成漏洞评估来提供内部扫描覆盖范围、查看扫描结果和补救发现。
接下来，我们介绍了如何优化配置 Microsoft Sentinel 来保护 Azure Arc 服务器。解释了选择分析和异常规则的最佳实践方法，我们深入研究了如何将 Azure Logic 应用定制为 Microsoft Sentinel 行动手册。最后，我们看了 Azure Arc 家族的另一个成员 Azure Arc SQL Server，并对微软如何在混合领域提供新的管理体验有了进一步的了解。
下一章“GitOps Insights”是关于代码形式的基础设施。将向您介绍 GitHub 平台和 GitOps 的概念。您将了解如何使用 GitOps 部署 CI/CD 解决方案，以便使用 Git 存储库在支持 Azure Arc 的 Kubernetes 集群上创建配置。***
八、GitOps 洞察
部署和管理 Kubernetes 集群只是运行 Kubernetes 集群的生命周期的一部分，即使是在跨多个云的情况下。您还需要在 Kubernetes 上部署和运行您的应用。这是 Kubernetes 生命周期的一个关键方面，这是因为 Kubernetes 给业务带来的真正价值是通过在其上运行的应用。
为了理解团队如何在 Kubernetes 上部署和运行应用，理解一些现有的 DevOps 工具是很重要的。理解这个工具将有助于您理解 GitOps。
在这一章中，我们将深入探讨三个主题，包括 Git、GitHub，最后是 GitOps。我们将更详细地探索这些主题和工具，将所有这些联系起来，以获得对 GitOps 的理解。
Git 概述
如果你正在读这本书，很可能你不是一个开发者。你可能是云工程师或者 DevOps 类型的。Git 对您来说可能是新东西，也可能不是。如果对您来说并不陌生，那么这一节将是对 Git 主题的一个很好的回顾。如果这对您来说是新的，请花些时间深入了解 Git 主题，因为它是当今技术世界的核心，从开发软件到基础设施即代码(IaC ),再到现在的 GitOps。Git 是一项核心技能，将在您的云之旅中很好地为您服务。
Git 是一个开源版本控制系统。它创建于 2005 年。它是当今最流行的版本控制系统。它是一个分布式版本控制系统，这意味着开发人员在一个成熟的存储库中拥有代码的本地快照。开发人员可以在本地处理代码，然后与服务器上的存储库同步。Git 工具在几乎所有主流操作系统(OS)上都得到支持和运行。Git 的总体目标如下:
速度
Git 应该帮助团队更快地发布他们开发的软件。这使得公司能够更快地向客户推出软件，更快地进行创新，从而在市场中获得竞争优势。
分布式
Git 应该是分布式的，而不是过去的集中式版本控制系统。这使得由多个开发人员组成的远程分布式团队更容易并行工作，允许开发人员即使在移动时(例如在飞机上飞行)也能继续工作，从而在开发软件时实现最大程度的灵活性。
完整性
Git 应该维护其存储库中的数据完整性。g it 在存储和引用所有数据之前对其进行校验和检查，这样就不可能在 Git 不知道更改的情况下修改文件或目录。
使用 Git 有多种方式，比如图形用户界面、其他工具的插件(比如 Microsoft VS Code)以及其他开发人员工具，最常见的是 Git 命令行。Git 命令行是包含所有 Git 命令的最健壮的命令行。因此，建议您在深入学习 Git 时熟悉 Git 命令。您最常使用的五个关键 Git 命令如下:
git clone
此命令将从远程存储库创建存储库的本地副本。
git add
此命令将执行一个阶段的更改，这些更改是更改跟踪过程的第一部分。这些分阶段的变更将成为下一次提交的一部分和存储库历史的一部分。
git commit
该命令创建变更的快照，也称为提交到存储库以完成变更跟踪过程。
git push
该命令将使用在本地对分支进行的提交来更新远程存储库。
git pull
该命令将使用来自远程存储库副本的更新来更新分支的本地提交行。
Git 命令的最新完整参考列表可以在这里找到: https://git-scm.com/docs/git#_git_commands 。
Git 的两个关键特性是分支和提交。分支是指向主分支中持续提交的指针。这是这看起来的样子(图 8-1 )。
图 8-1
Git 分支的可视化表示
这是分支图像的分解。开始时，开发人员在主分支中执行了提交 1 和提交 2。在提交 2 之后，从主分支创建了一个名为 dev 的新分支。提交 3 和提交 4 是在 Dev 分支中进行的。请注意，我们的开发分支现在位于主分支的前面。为了将代码从 Dev 分支带回主分支，我们需要执行一个合并。
合并是指 Git 将来自两个分支的多个提交序列合并成一个统一的历史，通常在一个主分支中。合并从不同的分支中提取独立的开发路径，并将它们放入单个分支中。
因此，在我们使用 git 命令行的例子中，我们将运行以下命令将 Dev 合并到主分支中:
git checkout main
那就跑
git merge test
这是 Git 中分支和合并工作方式的一个非常基本的例子。现在让我们学习什么是提交。有不同类型的合并超出了本书的范围。
提交是您记录对存储库的更改的方式。它记录了开发人员自上次提交以来所做的更改。在 Git 中，当开发人员修改代码时，Git 会看到变化；这些变更将准备好被登台，这是由开发人员控制的，一旦登台，就使用git commit命令提交到存储库中。
这就结束了对 Git 的概述。Git 和使用 Git 还有很多工作要做。本节旨在为您提供 Git 的初步概述，以激发您的兴趣，并为您提供足够的基础知识，以便更好地理解 GitOps。有关 Git 的完整端到端细分，请参考 Git 官方网站上的文档: https://git-scm.com/book/en/v2 。
GitHub 概述
您刚刚学习了什么是 Git，以及它是如何工作的。Git 是一个由工具和命令组成的版本控制系统，它本身只能带着软件开发/DevOps/cloud 团队到目前为止。使用 Git 的下一步是拥有一个平台来托管您的代码。一些使用 Git 的平台有 Azure DevOps、Bitbucket、AWS CodeCommit、GitLab 等等。在这一章中，我们将专门介绍 GitHub。
GitHub 是一个由 Git 支持的在线托管 Git 仓库的平台。GitHub 创建于 2007 年，微软于 2018 年 10 月收购了 GitHub。GitHub 托管远程存储库，并附带团队用于项目协作的附加功能。作为远程存储库的 GitHub 成为团队的统一事实来源。GitHub 被广泛使用，拥有 4000 多万用户和 1.9 亿多个存储库。GitHub 有通常用于开源项目的免费账户，也有供组织用于项目的付费账户。GitHub 的核心是 GitHub.com。有一个 GitHub 企业，它的功能类似于 GitHub.com，但它是自托管的，因此组织可以在自己的硬件上内部运行它。GitHub 比 GitHub Enterprise 更常用。图 8-2 展示了 GitHub.com 上的 Git 库是什么样子的。
图 8-2
GitHub.com 网站
有了 GitHub.com，就有了核心功能，比如访问控制、错误跟踪、特性请求、任务管理、持续集成等等。可以使用 Git 命令行访问 GitHub.com 存储库。还有许多桌面客户端、开发人员工具(如 VS Code)和 Git 插件可以与 GitHub.com 一起使用。所以总的来说，许多团队使用 GitHub 在 Git 存储库中托管他们的代码，并在项目上进行合作。自从微软收购 GitHub 后，他们一直致力于扩展 GitHub 的功能，并增加了更多的功能和产品。以下是 GitHub 的其他特性和产品:
github pages
托管静态网页的服务。
github 动作
一种在 GitHub 上托管的存储库中自动化和执行开发工作流的服务。
github 讨论
围绕开源项目的项目社区交流论坛。
GitHub 包
公共或私有软件包托管和管理服务。
GitHub 洞察
GitHub Enterprise 上软件交付过程的度量和分析报告服务。
github 桌面
用于与 GitHub 交互的桌面应用，使用 GUI 而不是 Git 命令行或通过 web 浏览器。
github CLI
用于与 GitHub 交互的命令行界面。
此外，GitHub 有一个 GitHub Marketplace，提供免费和付费的应用来扩展 GitHub 的功能。
这就结束了 GitHub 的概述。关于 GitHub 肯定还有更多需要学习的。学习 Git 和 GitHub 的最好方法是投入其中并开始使用它。使用 GitOps 的团队通常会使用 GitHub 在 Git 中托管他们的代码，所以在考虑采用 GitOps 之前，对 Git 和 GitHub 有一个坚实的理解是很重要的。
GitOps 概述
在这一节中，我们将深入了解这一章中关于 GitOps 的核心内容！在我们真正深入 GitOps 之前，让我们先来探索 GitOps 解决的几个问题，帮助理解对 GitOps 的需求。
问题:在这个 DevOps 云原生时代，Ops 和 dev 之间的界限越来越模糊，导致 ops 相关活动转移到 dev。开发人员需要被说服、支持并接受如何执行 ops 相关活动的培训。这并不总是很顺利，因为让开发人员使用 ops 工具、理解 ops 实践并从事这些活动可能是一项艰巨的任务。
解决方案: GitOps 作为 Ops 工具的抽象，自动化 ops 实践，并通过抽象层使开发人员更容易承担 ops 活动，并使 Git 成为事实的来源并保持其作为核心工具。
问题:当部署到 Kubernetes 时，开发团队将构建一个应用，将其打包，然后交给运营团队进行部署。然后，运营团队将更新他们的 IaC 配置脚本，并使用它们将应用部署到 Kubernetes 集群。这种方法导致 Git 存储库中的代码与实际环境断开。例如，当需要更新应用或环境配置时，运营团队将对 IaC 配置脚本进行更新，并将它们手动应用到实际环境中。这是一个风险，因为可能无法始终正确跟踪变更，并且可能会发生配置漂移。
解决方案:应用和配置部署通过 GitOps 执行，使 Git 成为事实的来源，确保实时环境中的应用和环境配置与 Git 存储库中代码中指定的期望状态相匹配。
这只是 GitOps 解决问题的两个例子。GitOps 有许多额外的好处和使用案例。GitOps 的更多使用案例包括
-
服务推广
-
基础设施管理，即 K8s 集群、机队和微服务
-
云原生 App 管理，即 CI/CD 中的“CD”
现在让我们来看看 GitOps 是什么。GitOps 是由一家名为 Weaveworks 的公司创建的。在 2017 年公开发表博客之前，Weaveworks 已经在他们的 Kubernetes 环境中使用 GitOps 运营模型模式有一段时间了。GitOps 可以描述如下:
GitOps 是云原生应用的一种运营模式模式& Kubernetes 在 Git 中存储应用&声明性基础设施代码，作为用于自动化持续交付的真理源。
GitOps 是 DevOps 的逻辑扩展，采用 DevOps 的最佳实践，如版本控制、协作和持续部署，并将这些应用于环境自动化，包括应用部署、配置和基础架构。GitOps 让 Git 成为描述整个系统理想状态的真实来源。GitOps 原则和实践并不新鲜，但它的名称和一些工具却很新鲜。例如，GitOps 原则是在代码中以声明性的方式描述环境的期望状态。这并不新鲜，因为我们一直在使用它，并通过诸如 Chef 和 Puppet 之类的工具将其应用到我们的环境中。主要的区别是 GitOps 将 Git 视为真理的来源，而其他工具则不是。以下是 GitOps 的原则和实践:
GitOps 原理:
-
声明式配置
- 以声明方式描述的系统状态
-
版本控制，不可变存储
-
Git 是真理的源泉。
-
git 中对所需的系统状态进行了版本控制。
-
-
自动交付
- Git 作为自治代理执行操作(创建、更改、删除)的单一位置
-
软件代理
- 被称为操作员的软件强制执行期望的状态并对漂移发出警报。
-
闭环
- 经批准的系统状态变更的自动交付
GitOps 做法:
-
靠边推。
-
每个应用有 2 个回复。一个用于应用源代码，一个用于配置(清单)。
-
无论是在 Kubernetes secrets 还是其他秘密管理解决方案中，都要有一个秘密管理计划。
-
确保测试包含在您的 GitOps 流程中。
GitOps 的工作方式是，在 Git 中，有描述系统状态的代码，比如应用和配置。在 Kubernetes 的上下文中，Git 存储库中的代码将是 YAML 格式的 Kubernetes 清单文件，用于应用 pods 和 Kubernetes 集群中的任何其他配置，如机密、配置映射、部署、服务、入口等。
从那里，一个被称为 GitOps operator 的软件代理将监视 Git 存储库的任何更改，执行一个 pull，并通过 Kubectl 或 Helm 将更改应用到 Kubernetes 集群。这确保了真实环境的状态与 Git 中描述的期望状态相匹配。让我们来看看 GitOps 工作流的可视化表示(图 8-3 )。
图 8-3
GitOps 工作流程示例
有许多 GitOps 操作符，但两个主要的是 Flux 和 Argo CD。Flux 和 Argo CD GitOps 运算符旨在与 Kubernetes 一起使用
一个经常出现的问题是，“我的组织没有使用 Kubernetes。GitOps 还适用于我们吗？”是的，GitOps 确实适用于你。GitOps 运营模式不仅限于 Kubernetes。实际上，您可以将 GitOps 用于任何可以以声明方式观察和描述的系统。
目前，大多数 GitOps 操作符都是为 Kubernetes 构建的，但也有一些操作符是为 Terraform 构建的。Kubestack 和 Atlantis 是两个直接使用 Terraform 的 GitOps 运营商。Kubestack 是一个用于在任何平台上构建 Kubernetes 的 Terraform GitOps 框架。Atlantis 是一家通过 Terraform Pull Request Automation 实现云的 GitOps 运营商。
现在让我们来看看 gitop 的主要优势，这对于理解 gitop 如何让您的团队和组织受益非常重要。GitOps 的主要优势如下:
-
Git 作为事实的来源增强了开发人员的体验并易于采用。
-
持续同步为您的环境带来更高的可靠性。
-
Git中跟踪的所有内容都会产生完整的审计跟踪，满足合规性，并具有更好的稳定性。
-
持续安全将访问权转移给 GitOps 运营商；安全变成代码；证件和国家隔离成为现实。
-
一切都用一个代码导致更容易回滚，更一致，&标准化。
现在让我们探索 GitOps 和 Azure Arc 支持的 Kubernetes。支持 Azure Arc 的 Kubernetes (Arc K8s)确实利用了 GitOps。Arc K8s 以两种方式使用 GitOps:第一种方式用于配置 Kubernetes，第二种方式用于将应用部署到 Kubernetes 集群。Arc K8s 使用助焊剂。Flux 是一个开源的 GitOps 操作器。Weaveworks 构建了 Flux 并对其进行了开源。Flux 是云原生计算沙盒项目的一部分。
Flux 操作符作为一个 pod 在 Kubernetes 集群上运行。Flux 操作符采用基于拉的方法将 Git 存储库与 Kubernetes 集群同步。Flux 操作员可以在您授予权限的 Kubernetes 集群上执行创建、更改和删除操作。Flux 操作者还可以不断地轮询容器注册中心或 Helm 存储库，以获得 Kubernetes 集群中需要的添加或更改。
这个 Flux 操作符用于同步 Kubernetes 集群配置和 Git 存储库中所需状态的配置，目标是通过创建、更改和删除操作来匹配这两者。
Arc K8s 集群和 Git 存储库的连接位于 Azure 资源管理器中。这个连接是一个名为 Microsoft 的扩展资源。kubernetisconfiguration/sourcecontrolconfiguration s。这个连接资源存储在 Azure Cosmos DB 数据库中。此连接在静态时是加密的。可以使用 Azure 门户或通过 Azure 命令行界面(CLI)建立连接。源控制配置具有以下属性:
-
配置名称
-
操作员实例名称
-
操作员名称空间
-
存储库 URL
-
操作员范围(名称空间/集群)
-
操作员类型
-
运算符参数
-
舵(启用/禁用)
在每个 Arc K8s 集群中可以有多个source control configuration。这些配置可以局限于名称空间或集群级别。当组织有多环境或多租户需求时，这很有用。
摘要
这使我们结束了这一章。在这一章中，我们进入了 Git 的世界，探索了它是什么以及它是如何工作的。然后我们进入 GitHub 的概述，它的历史，它是如何工作的，它的各种特性和产品。
然后，我们结束了这一章，转到 GitOps，分解了为什么需要它，它是什么，它的好处，原则和实践，以及它如何与 Azure Arc 一起发挥作用。本章的目标是给你 Git 和 GitHub 所需的背景知识，让它与 GitOps 完美结合，以便你在探索 Azure Arc 支持的 Kubernetes 和学习它如何利用 GitOps 时做好准备。
九、支持 Azure Arc 的 Kubernetes：入门
欢迎阅读“支持 Azure Arc 的 Kubernetes:入门”一章。Azure Arc 支持的 Kubernetes 是 Azure 中的一个较新的服务，正在获得巨大的吸引力。在这一章中，我们将深入研究使用 Azure Arc 和 Kubernetes 集群的工作。
在这一章中，我们将从什么是 Azure Arc-enabled Kubernetes 及其用例的概述开始，我们将探索它的架构。然后，我们将继续讨论如何设置支持 Azure Arc 的 Kubernetes，以及如何将其连接到外部 Kubernetes 集群。您还将了解如何利用 Azure Arc 跨内部或多云管理您的外部 Kubernetes 集群。我们将阐述如何扩展监控、安全扫描/保护、Azure Active Directory RBAC 控制以及 Kubernetes 集群的合规性策略。
我们将在本章结束时介绍如何利用 GitOps 和支持 Azure Arc 的 Kubernetes 将配置和应用部署到外部 Kubernetes 集群。
让我们开始吧，因为我们有一章是关于支持 Azure Arc 的 Kubernetes 的重要信息。
什么是支持 Azure Arc 的 Kubernetes
Azure Arc 是一个云解决方案，可满足组织的内部和多云管理需求。Azure Arc 将 Azure 功能扩展到 Azure 之外的环境。Azure Arc 使您能够在以下平台上创建和管理资源以及工作负载:
-
内部
-
非 Azure 云(即 GCP、AWS、阿里巴巴等。)
-
微软混合(Azure Stack Hub、Azure Stack HCI、Azure Stack Edge)
支持 Azure Arc 的 Kubernetes (Arc K8s)允许您将 Kubernetes 集群连接到运行在内部或非 Azure 云上的 Azure。Arc K8s 为在任何地方运行的工作负载带来了统一的 Azure 管理体验。
Azure Arc 有几个产品，一些处于 GA 状态，一些处于私有预览，一些处于公共预览。支持 Azure Arc 的 Kubernetes 已正式上市。启用 Azure Arc 的 Kubernetes 产品的定价是独一无二的，因为在管理启用 Azure Arc 的服务器和启用 Azure Arc 的 Kubernetes 集群时，它目前是免费提供的。面向服务器和 Kubernetes 的 Azure Arc 控制平面功能是免费提供的。被视为 Azure Arc 控制平面一部分的服务包括
-
将服务器和 Kubernetes 集群附加到 Azure
-
通过 Azure 管理组和标记进行资源组织
-
通过资源图进行搜索和索引
-
通过 Azure RBAC 和 Azure 订阅的访问和安全性
-
通过 ARM 模板和 Azure 扩展的环境和自动化
截至目前，支持 Azure Arc 的 Kubernetes 在以下特定地区可用:
-
美国东部
-
西欧
-
美国中西部
-
美国中南部
-
东南亚
-
英国南部
-
美国西部 2
-
澳大利亚东部
-
美国东部 2
-
北欧
-
美国中部
-
美国州长弗吉尼亚
-
法国中部
-
韩国中央电视台
-
日本东部
-
东亚
随着时间的推移，微软将为支持 Azure Arc 的 Kubernetes 添加越来越多的支持区域。建议在此处查看微软官方文档: https://docs.microsoft.com/en-us/azure/azure-arc/kubernetes/overview#supported-regions 了解有关支持 Azure Arc 的 Kubernetes 的地区列表的最新信息。
支持 Azure Arc 的 Kubernetes 支持任何经过云本地计算基金会(CNCF)认证的 Kubernetes 发行版。以下是支持 Azure Arc 的 Kubernetes 支持的本地和基于云的 Kubernetes 的示例列表:
-
种类
-
MicroK8s
-
牧场主 K3s
-
AK(蓝色库柏服务)
-
Azure 堆栈 HCI 上的 AK
-
EKS(亚马逊弹性库柏服务)
-
gke(Google kuble engine)
-
ACK(面向 Kubernetes 的阿里云容器服务)
-
蓝色 Red Hat OpenShift
支持 Azure Arc 的 Kubernetes 通过扩展和 GitOps 将许多 Azure 的原生功能带到了计划中的 Kubernetes 集群。其中包括
-
利用 Azure Monitor 和 Microsoft Defender for Cloud with Arc 来监控和保护预计的 Kubernetes 集群
-
使用 Azure Arc 和 Azure 策略管理计划的 Kubernetes 集群
-
利用 Azure Active Directory RBAC 对计划的 Kubernetes 集群进行授权和访问
-
与 GitOps (Flux GitOps operator)和 projected Kubernetes 集群集成
-
通过 GitOps 将应用和配置部署到预计的 Kubernetes 集群
-
通过 GitOps 将舵图部署到预计的 Kubernetes 集群
-
将物联网工作负载部署到边缘
-
在任何支持 Arc 的 Kubernetes 集群上运行 Azure 应用服务、功能、事件网格、Azure API 管理和逻辑应用
-
基于投影 Kubernetes 集群的服务网格，具有 mTLS 安全性、细粒度访问控制、流量转移、通过微软开放服务网格使用 Jaeger 功能进行跟踪
Note
微软一直在为 Azure Arc 添加更多的功能和能力，所以随着 Azure Arc 支持的 Kubernetes 的生命周期不断成熟，前面的列表将会随着时间的推移而增长。
我们想要讨论的关于 Azure Arc 启用的 Kubernetes 的最后一个主题是 Azure Arc 启用的 Kubernetes 和其他产品的比较。在讨论支持 Azure Arc 的 Kubernetes 时，这些问题总是会出现。
天蓝色 Arc K8s vs 牧场主
支持 Azure Arc 的 Kubernetes 集中管理内部或公共云上的 Kubernetes 集群，包括 Azure、GCP、AWS、edge、IoT 和 Hybrid (Azure Stack ),并将 Azure 原生工具和 GitOps 扩展到外部 Kubernetes 集群。
Rancher 集中管理和调配内部或公共云(包括 Azure、GCP 和 AWS)上的 Kubernetes 集群。将 Rancher 接口、应用目录、GitOps 和开源工具扩展到外部 Kubernetes 集群。
Azure Arc K8s 与 Azure Stack Hub/AWS 前哨
Azure Arc 将 Azure 功能扩展到 Azure 之外的环境，比如你的数据中心和其他云，如 AWS 和 GCP。
Azure Stack Hub/AWS outpost 和 Azure Arc 都支持混合云场景。Azure Stack 是一个混合云平台，可以让你在自己的数据中心运行 Azure。AWS Outposts 对在数据中心外运行 AWS 提出了同样的要求。
天蓝色 Arc K8s vs. Anthos
Google 提供 Anthos 作为一个托管应用平台，将 GCP 容器服务扩展到任何环境。GCP 的方法是将工作负载转移到运行在 GKE 上的容器中。
与 Anthos 相比，Azure Arc 允许客户运行虚拟机或容器。Arc 将 Azure 控制平面扩展到两者，并充当资源的总体管理层。Azure Arc 方法提供了灵活性，允许您在内部运行资源或在其他云上运行资源。
支持 Azure Arc 的 Kubernetes 用例
根据 New Stack 的“Kubernetes 生态系统第二版状况”报告，拥有 5000 名或更多员工的组织中有 61%的 Kubernetes 用户拥有五个以上的集群，拥有五个以上集群的 Kubernetes 用户的比例从 2017 年的 34%上升到 2019 年的 39%。
这是关于支持 Azure Arc 的 Kubernetes 的重要信息，因为今天许多组织都选择采用多云策略，包括跨多个云运行 Kubernetes。跨内部和多个云管理 Kubernetes 集群可能会脱节且过于复杂。支持 Azure Arc 的 Kubernetes 着手解决这一问题，并减少管理跨内部和多个云的多个 Kubernetes 集群带来的难题。
支持 Azure Arc 的 Kubernetes 帮助的几个用例如下:
-
Azure、谷歌云平台和亚马逊网络服务云之间的应用一致性
-
物联网应用的集中管理，用于管理采矿公司多个边缘位置的设备
-
在内部部署 Azure PaaS 服务以满足额外的合规性要求
请注意，这并不是 Azure Arc 支持的 Kubernetes 帮助的用例的详尽列表。
azure arc-enabled kubers 体系结构
Azure Arc 支持的 Kubernetes 是运行在 Azure 中的 PaaS 服务，用于管理多个 Kubernetes 集群，而不管它们在哪里。支持 Azure Arc 的 Kubernetes 架构由 Azure 服务、资源、工具、代理以及在一个计划的 Kubernetes 集群上运行的大量部署和 pods 组成。现在让我们来看看支持 Azure Arc 的 Kubernetes 架构和代理。
在 Azure 中，在 Azure 订阅中需要以下资源提供者，以便您在其中运行启用 Azure Arc 的 Kubernetes 来支持启用 Azure Arc 的 Kubernetes:
-
Microsoft.Kubernetes -
Microsoft.KubernetesConfiguration -
Microsoft.ExtendedLocation
一个计划中的 Kubernetes 集群将运行一个支持 Azure Arc 的 Kubernetes 代理。为了使代理工作，需要在计划的 Kubernetes 集群网络上允许以下网络端口和协议/端点出站 URL:
端口:
- 端口 443 和端口 9418 上的 TCP
允许从计划的 Kubernetes 群集出站的端点(DNS):
-
https://eastus.dp.kubernetesconfiguration.azure.comhttps://westeurope.dp.kubernetesconfiguration.azure.com
在计划的 Kubernetes 集群上线后，计划的 Kubernetes 集群上将运行一个名为“azure-arc”的名称空间。
此外，在 azure-arc 名称空间中的 Kubernetes 集群上将运行一些操作符作为部署:
- 配置代理
当 sourceControlConfiguration 资源应用于项目集群时，它监视项目 Kubernetes 集群以更新符合性状态。
- 控制者-管理者
它编排 Azure Arc 组件之间的交互。一种用来操作其它操作符的操作符。
- 指标-代理
它从其他 Arc 代理收集指标来衡量性能并确保其处于最佳状态。
- 聚类-元数据-运算符
它收集集群和 Azure Arc 代理的版本、集群元数据和节点计数。
- 资源同步代理
它将 cluster-metadata-operator 收集的元数据与 Azure Arc 同步。
- clusteridentityoperator
该操作员持有托管服务身份(MSI)证书，其他操作员使用该证书与 Azure 通信。
- 通量记录剂
作为 sourceControlConfiguration 的一部分，Flux 操作符被部署到计划的 Kubernetes 集群，这个代理从它们那里收集日志。
azure-arc 名称空间中的 Kubernetes 集群上将运行一些 pods，包括
-
聚类-元数据-运算符 -b88f6695d-rf998
-
cluster identity operator-6459 FD 778 c-4wx 66
-
配置代理 -6cc967f5-kd8b8
-
控制器-管理器 -557d758b9f-f69vw
-
flux-logs-agent-5 db 8 BFF 9d 4-gktl 4
-
度量-代理 -997cf95d5-h96gd
-
资源同步代理 -587b999567-4kz64
这就是构成支持 Azure Arc 的 Kubernetes 的组件。该架构包括 Azure 服务、资源、工具、代理以及大量部署和 pod。
将 Kubernetes 集群连接到 Azure Arc
在开始将支持 Azure Arc 的 Kubernetes 与您的外部 Kubernetes 集群一起使用之前，您需要首先将其连接到 Azure Arc。将外部 Kubernetes 集群连接到 Azure Arc 的过程相当简单。在连接它之前，您确实需要具备一些先决条件。将 K8s 连接到 Azure Arc 的先决条件如下:
-
创建 Azure 服务主体(SP)。
-
启用 Azure Arc 的 Kubernetes 资源提供程序已启用。
-
需要安装 kubectl (Kubernetes 命令行)工具。
-
kubeconfig 文件(kubectl 上下文)配置为与您的 K8s 集群连接。
-
安装/更新头盔 3 或以上。
-
将 Azure CLI 安装/更新到版本 2.15.0 或更高版本。
-
Azure CLI 扩展连接了 k8s 和 k8s-已安装配置。
让我们来了解一下在将 Arc 连接到 Kubernetes 之前如何安装和设置先决条件:
首先，您需要在 Azure 订阅中创建一个服务主体(SP)。此 SP 将需要对订阅中的Microsoft.Kubernetes/connectedClusters资源类型的读写权限。
您还将使用此 SP 进行 az 登录和 az connectedk8s 连接。您可以通过在 Azure Cloud Shell 中运行一行语法来创建这个 SP。创建 SP 时，您需要将输出复制到安全的地方，因为稍后您将需要使用它。您可以使用以下语法创建带名称的 SP，并将其分配给特定订阅:
az ad sp create-for-rbac --name <SPNNAME> --role contributor --scope /subscriptions/<SUBSCRIPTIONID>
输出示例:
{
"appId": "138r8633-v9g3-4f90-80d9-hg7924c823f9",
"displayName": " SPNNAME ",
"name": "http:// SPNNAME",
"password": "5g2c85va-43ds-31f0-o6c6-rbg2c5av472g",
"tenant": "9uh4qq35-q432-4j2v-h20r-6o24b11p53TW"
}
同样，确保复制输出，以便在需要时准备好。
接下来，你需要在我们的 Azure 订阅中注册一些支持 Azure Arc 的 Kubernetes 的资源提供者。
az provider register --namespace Microsoft.Kubernetes
az provider register --namespace Microsoft.KubernetesConfiguration
az provider register --namespace Microsoft.ExtendedLocation
然后你需要安装头盔。根据您安装 Helm 的平台，有多种安装方式。因为安装会根据您的平台而有所不同，所以最好参考 Helm install 链接来了解此过程的最新更新。这是舵安装的官方链接: https://helm.sh/docs/intro/install 。
接下来，将 Azure CLI 安装/更新到 2.15.0 或更高版本。可以在 Windows、macOS、Linux 环境下的 Azure CLI 中安装，也可以作为 Docker 容器运行。它还预装在 Azure Cloud Shell 中:
https://docs.microsoft.com/en-us/cli/azure/install-azure-cli
安装 Azure Arc K8s CLI 扩展来管理外部 Kubernetes 集群。
az extension add --name connectedk8s
az extension add --name k8s-configuration
这总结了我们在 Azure Arc 支持的 Kubernetes 先决条件方面需要做的事情。
将 Azure Arc 连接到 Azure Kubernetes 服务群集
现在让我们继续将 Kubernetes 集群连接到 Azure Arc。使用 SP 登录您的 Azure 订阅。从外部 Kubernetes 集群所在的 shell 中运行这个，也就是 GCP cloudshell。
az login --service-principal --username SPID --password SPPWD --tenant SPTENANTID
为计划的 Kubernetes 集群创建一个资源组。
az group create –location LOCATIONHERE --name RGNAME --subscription SUBSCRIPTIONID
我们现在可以将外部 Kubernetes 集群连接到 Azure Arc K8s。
az connectedk8s connect --name ARCK8SCLUSTERNAME --resource-group RGNAME --location LOCATIONHERE --tags ’Environment=dev-arc-cluster1’
连接后，它就变成了一个投影 K8s 集群，显示在 Azure 门户中。
预计的 Kubernetes 集群将以下列方式显示在 Azure 门户中:
-
它作为资源出现在 Azure 门户中。
-
它和其他 Azure 资源一样有标签。
-
它显示在您的 Azure 订阅和资源组中。
-
在门户中，它有一个 Azure 资源管理器 ID 和一个托管身份。
使用 Azure Arc 和 Azure Monitor 监控 Kubernetes 集群
监控您计划的 Kubernetes 集群和在其上运行的容器对于确保您的环境健康至关重要。Azure Monitor Container Insights 能够提供对连接到启用 Azure Arc 的 Kubernetes 的预计 Kubernetes 集群的监控。
Azure Monitor for Containers 为您提供了性能可见性，并将从您计划的 Kubernetes 节点和容器中收集内存和 CPU 利用率指标。在撰写本文时，Azure Monitor for Containers 不支持动态数据。
Azure Monitor 容器洞察可以
-
监控 Kubernetes 集群及其节点的性能。
-
确定在节点上运行的容器及其平均处理器和内存利用率。
-
确定容器在控制器或 pod 中的位置。
-
了解集群在平均负载和最大负载下的行为。
-
与 Prometheus 集成，查看它使用查询从节点和 Kubernetes 收集的应用和工作负载指标。
在入职前，将 Kubernetes 集群投影到 Azure Monitor Container Insights 中。
图 9-1
入职前 Azure Monitor 容器洞察
在您能够启用 Azure Monitor Container Insights 监控之前，您需要具备一些先决条件:
-
使用 Azure Monitor for containers 配置的日志分析工作区。
-
至少，您需要是 Azure 订阅中 Azure Contributor 角色的成员。
-
使用 Azure Monitor for containers 配置的日志分析工作区的日志分析参与者角色的成员。
-
Azure Arc 群集资源上参与者角色的成员。
-
日志分析读取器角色权限的成员。
-
HELM 客户端加载指定 Kubernetes 集群的 Azure Monitor for containers 图表。
-
需要允许以下 Microsoft 监控端点通过任何防火墙:
*.ods.opinsights.azure.com *.oms.opinsights.azure.com dc.services.visualstudio.com *.monitoring.azure.com login.microsoftonline.com port 443 for all of them
让我们通过三种方式来实现针对 Azure Monitor Container Insights 的 Kubernetes 集群:
#1 来自 Azure Monitor blade
-
在 Azure 门户中，导航到“Monitor”刀片，并选择“Insights”菜单下的“Containers”选项。
-
选择“未监控的集群”选项卡以查看您可以对其启用监控的启用 Azure Arc 的 Kubernetes 集群。
-
单击要启用监视的集群旁边的“Enable”链接。
-
选择日志分析工作区，然后选择“配置”按钮继续。
#2 来自预计的 K8s 集群资源刀片
-
在 Azure 门户中，选择您想要监控的投影 Kubernetes 集群。
-
选择 resource blade 的“Monitoring”部分下的“Insights (preview)”项。
-
在 onboarding 页面上，选择“配置 Azure Monitor”按钮。
-
现在，您可以选择日志分析工作区来发送您的指标和日志数据。
-
选择“配置”按钮以部署 Azure Monitor Container Insights 群集扩展。
#3 来自计划的 K8s 集群资源
使用以下语法下载名为 enable-monitoring.sh 的“启用监控，又名 OMS”脚本:
curl -o enable-monitoring.sh -L https://aka.ms/enable-monitoring-bash-script
接下来，使用以下语法检索 Azure Arc 连接的集群 Azure 资源 ID:
export azureArcClusterResourceId=$(az resource show --resource-group PROJECTEDK8SRESOURCEGROUP --name PROJECTEDK8SCLUSTERNAME --resource-type "Microsoft.Kubernetes/connectedClusters" --query id -o tsv)
使用以下语法从当前 KubeContext 中检索计划的 Kubernetes 集群凭据:
export kubeContext="$(kubectl config current-context)"
使用以下语法运行 enable-monitoring.sh 脚本:
bash enable-monitoring.sh --resource-id $azureArcClusterResourceId --client-id SPNID --client-secret SPNPASSWORD --tenant-id TENANTID --kube-context $kubeContext
入职后，将 Kubernetes 集群纳入 Azure Monitor Container Insights。
图 9-2
入职后的 Azure Monitor 容器洞察
使用 Azure Arc 和 Azure AD RBAC 在 Kubernetes 集群上配置 RBAC
启用 Azure Arc 的 Kubernetes 的众多好处之一是能够利用身份提供者的 Azure Active Directory (AAD)来授权和访问您计划的 Kubernetes 集群。借助支持 RBAC 和 Azure Arc 的 Kubernetes，您可以使用 Azure AD 和角色分配来控制谁可以读取、写入和删除 Kubernetes 对象，如部署、pod 和服务。与 Kubernetes 自带的内置 RoleBinding 和 ClusterRoleBinding 相比，您可以使用 AAD RBAC 和角色分配来定义和控制对计划的 Kubernetes 集群的授权。本来，在 Kubernetes 中，RoleBinding 和 ClusterRoleBinding 通常用于定义和控制授权。
Note
Azure AD RBAC 与 Kubernetes 的集成不适用于非 Azure 管理的 Kubernetes 服务，如 AKE 和 GKE。这是因为对于 GKE 和 AKE 这样的服务，您无法访问 Kubernetes 集群 API 服务器。
Azure AD 和 Azure Arc Projected K8s 集成的先决条件:
-
Azure CLI 已安装。
-
已安装 Connectedk8s 扩展。
-
连接到您现有的 Azure Arc projected Kubernetes 集群。
设置 Azure AD 和 Azure Arc Projected K8s 集成有两个步骤
#1 设置 Azure 广告应用
-
创建服务器应用。
-
创建客户端应用。
-
为服务器应用创建角色分配。
#2 在 K8s 集群上启用 Azure AD RBAC
在您的项目 K8s 集群上运行以下命令以启用 Azure AD RBAC 功能:az connected K8s enable-features-n arc k8 sname-g rg name-features Azure-RBAC-app-id SPAPPID-app-secret sp pwd
Azure AD RBAC 集成具有角色分配，可以分配给计划的 Kubernetes 集群，并且可以使用 Azure 门户> Azure Arc 上的计划集群资源的访问控制(IAM)刀片来完成。角色分配如下:
-
蓝色弧形立体检视器
- 允许只读访问以查看命名空间中的大多数对象。此角色不允许查看机密。
-
蓝弧立方作家
- 允许对命名空间中的大多数对象进行读/写访问。此角色不允许查看或修改角色或角色绑定。
-
蓝色弧库管理员
- 允许管理员访问。它旨在通过 RoleBinding 在名称空间内被授予。
-
蓝弧立方簇管理员
- 允许超级用户对任何资源执行任何操作。
您可以创建自定义角色定义以在 Azure AD 角色分配中使用。这是一个分三步走的过程:
步骤#1 创建一个 customrole.json 文件，语法如下:
{
"Name": "Arc Deployment Viewer",
"Description": "Lets you view all deployments in cluster/namespace.",
"Actions": [],
"NotActions": [],
"DataActions": [
"Microsoft.Kubernetes/connectedClusters/apps/deployments/read"
],
"NotDataActions": [],
"assignableScopes": [
"/subscriptions/<subscription-id>"
]
}
步骤#2 是使用以下命令从 customrole.json 文件创建角色定义:
az 角色定义创建-角色定义 mycustomrole.json
步骤#3 是使用您在步骤#1 中创建的自定义角色定义来创建角色分配。您将使用以下命令来创建角色分配:
az role assignment create --role "Arc Deployment Viewer" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID/namespaces/<namespace-name>
有两种方法可以连接到投影 K8s 集群:
#1:集群连接功能(az connectedk8s 代理)
az connectedk8s proxy -n ARCK8sNAME -g RGNAME
可以在前面的命令运行后运行 kubectl 命令。
#2:使用 kubeconfig 文件
为用户设置凭据:
kubectl config set-credentials user@domain.com \
--auth-provider=azure \
--auth-provider-arg=environment=AzurePublicCloud \
--auth-provider-arg=client-id=SPCLIENTID \
--auth-provider-arg=tenant-id=TENANTID \
--auth-provider-arg=apiserver-id=SPAPPID
#2 Add the config-mode setting under user > config –
name: user@domain.com
user:
auth-provider:
config:
apiserver-id: $SERVER_APP_ID
client-id: $CLIENT_APP_ID
environment: AzurePublicCloud
tenant-id: $TENANT_ID
config-mode: "1"
name: azure
现在可以运行 kubectl 命令了。
使用 Microsoft Defender for Cloud 和 Azure Arc 保护 Kubernetes 群集
Microsoft Defender for Cloud for Kubernetes clusters 扩展能够保护您计划在内部甚至在其他云中运行的 Kubernetes 集群。Defender 提供与 Azure Kubernetes 服务(AKS)群集相同的威胁检测和功能。
安全中心接收和分析的项目包括
-
来自 API 服务器的审计日志
-
来自日志分析代理的原始安全事件
-
来自计划的 Kubernetes 集群的集群配置信息
-
来自 Azure Policy 的工作负载配置(通过 Azure Arc projected Kubernetes 的 Azure Policy 插件)
让我们看看 Microsoft Defender for Cloud for Azure Arc-enabled Kubernetes 的先决条件:
-
您的订阅已启用 Microsoft Defender for Cloud for Kubernetes。
-
您的外部 Kubernetes 集群连接到 Azure Arc。
-
已经满足通用集群扩展的先决条件(Azure CLI、connectedk8s 和 k8s-扩展扩展、连接到 Arc 的投影 K8s 集群)。
为 Arc K8s 部署 Microsoft Defender for Cloud extension。
我们需要在 Azure Arc projected Kubernetes 集群上运行以下代码，以便为 Defender 启用它。
Note
在运行这段代码之前，您应该运行“az 登录”和“az 帐套”。
az k8s-extension create --name microsoft.azuredefender.kubernetes--cluster-type connectedClusters --cluster-name ARCK8sCLUSTERNAME--resource-group RGNAME --extension-type microsoft.azuredefender.kubernetes
使用 Azure Policy、Azure Arc 和 GitOps 强制执行 Kubernetes 集群的合规性
Azure 策略可用于在 Kubernetes 集群上强制合规。它最初用于 Azure Kubernetes 服务集群。随着支持 Azure Arc 的 Kubernetes 的引入，针对 Kubernetes 的 Azure 策略扩展到了外部 Kubernetes 集群。Azure Policy 也可以和 GitOps 一起使用。这是通过利用一个 GitOps Azure 策略定义来完成的，该策略定义将在您计划的 Kubernetes 集群上设置 GitOps 配置。
针对 Kubernetes 集群的 Azure 策略可以做两件事:
-
应用策略以集中、一致的方式实施和保护您计划的 Kubernetes 集群。
-
在 Azure Arc projected Kubernetes 集群上大规模应用 GitOps 配置。
目前，用于 Kubernetes 的 Azure 策略仅支持 Linux 节点池和内置策略定义。
Kubernetes 的 Azure 策略示例:
-
Kubernetes 集群容器应该只使用允许的图像。
-
应启用 Azure Kubernetes 服务专用群集。
-
Kubernetes 集群不应该使用默认的名称空间。
-
应在 Kubernetes 服务上定义授权的 IP 范围。
在部署和使用 Kubernetes 的 Azure Policy 之前，需要满足一些先决条件。这些先决条件如下:
-
已安装 Azure CLI 版本 2.12.0 或更高版本。
-
在您的订阅中注册的 Azure 策略提供程序:
- az 提供程序注册命名空间' Microsoft。“政策洞察”
-
Kubernetes 集群版本 1.14 或更高版本。
-
舵 3 或更高。
-
您的外部 Kubernetes 集群连接到 Azure Arc。
-
需要启用 Azure Arc 的 Kubernetes 集群的 Azure 资源 ID。
-
将“Policy Insights Data Writer(Preview)”角色分配给支持 Azure Arc 的 Kubernetes 集群。
让我们来探索一下 Azure 策略是如何为 Kubernetes 服务的。K8s 的 Azure Policy 基于开放策略代理实现，称为 Gatekeeper。K8s 的 Azure 策略由两部分组成:
-
看门人组件
-
azure-策略组件
当添加 Kubernetes 的 Azure Policy 扩展时，创建了一个名为 gatekeeper-system 的名称空间，其中部署了两个 pod:
-
把关者-审核窗格
-
网关守护设备控制器盒
Gatekeeper 组件安装在 gatekeeper-system 名称空间中，而 azure-policy 组件安装在 kube-system 名称空间中。
Kubernetes 的 Azure 策略有两种效果:审计和拒绝。这些细分如下:
-
默认情况下，网关守护设备-审核窗格将检查群集是否违规。
-
当操作设置为“拒绝”时，网关守护设备-控制器单元执行强制执行。
当部署满足 Kubernetes 策略条件的所有 Azure 策略时，它就被允许部署。当部署不满足所有策略条件时，它会拒绝部署。为了为 Arc Projected Kubernetes 集群安装 Azure Policy 附加组件，您需要将 Azure Policy 附加组件 repo 添加到 Helm，然后安装 Azure Policy 附加组件 Helm chart。您应该运行代码，将附加组件添加到 Helm repo，并从 Azure Arc projected Kubernetes 集群安装 helm chart。运行以下语法将 Azure Policy 附加组件回购到 Helm:
helm repo add azure-policy https://raw.githubusercontent.com/Azure/azure-policy/master/extensions/policy-addon-kubernetes/helm-charts
为了安装 Azure Policy 附加组件 Helm chart，请运行以下语法:
helm install azure-policy-addon azure-policy/azure-policy-addon-arc-clusters \
--set azurepolicy.env.resourceid=<AzureArcClusterResourceId> \
--set azurepolicy.env.clientid=<ServicePrincipalAppId> \
--set azurepolicy.env.clientsecret=<ServicePrincipalPassword> \
--set azurepolicy.env.tenantid=<ServicePrincipalTenantId>
为 Kubernetes 附加组件安装 Azure 策略后，下一步是为一个计划的 Kubernetes 集群分配一个 Azure 策略。您可以使用以下步骤来完成此操作:
-
在 Azure 门户中，单击左侧窗格中的所有服务，然后搜索策略。
-
在左侧窗格中的创作下，单击定义。
-
在“类别”下拉列表框中，单击“全选”以清除过滤器，然后在“过滤器”框中键入 Kubernetes 以将范围扩大到 Kubernetes。点击 Kubernetes。
-
选择策略定义；然后选择分配按钮。
-
Kubernetes 所在的范围(即管理组、订阅、资源组)来应用策略分配。
-
为您的策略分配提供名称和描述。
-
将策略强制设置为“启用”或“禁用”，然后单击“下一步”。
Note
如果强制模式设置为禁用，则不会强制实施策略效果(即，拒绝策略不会拒绝资源)。但是，合规性评估结果仍然可用。
-
设置您的参数(如果需要)。
- 默认情况下，kube-system、gatekeeper-system 和 azure-arc 名称空间被设置为排除在外。这将从策略评估中排除这些命名空间。建议将它保留在原位。
-
点击查看+创建。
Kubernetes 附加组件的 Azure 策略的另一个用途是使用 Kubernetes 的 Azure 策略来应用 GitOps。通过针对 Kubernetes 的 Azure Policy，您可以将 GitOps 配置分配给计划的 Kubernetes 集群。还可以使用 Azure Policy 在 Azure Arc projected K8s 集群(Microsoft.Kubernetes/connectedclusters)上大规模应用 GitOps 配置(Microsoft.KubernetesConfiguration/sourceControlConfigurations资源类型)。
要为 Kubernetes 使用带有 Azure 策略的 GitOps，您可以使用内置的 GitOps 策略定义，并在您的 Kubernetes 集群上创建一个策略分配。您需要设置所需的参数，例如
Operator instance name
Operator namespace
Operator scope
Operator type
Operator parameters
Repository URL
...
了解 GitOps 和 Azure Arc 支持的 Kubernetes 架构和工作流
重申 GitOps 是什么很重要。“GitOps 是云原生应用和 Kubernetes 的一种操作模型模式，它将应用和声明性基础架构代码存储在 Git 中，作为用于自动化连续交付的事实来源。”支持 Azure Arc 的 Kubernetes 使用 Flux，这是一个由 Weaveworks 构建的开源 GitOps 操作符。支持 Azure Arc 的 Kubernetes 中的 GitOps 是一个计划的 Kubernetes 集群和 Git 存储库之间的连接，它通过一个 Flux 操作符作为一个 pod 在 Kubernetes 集群上运行。这个 Flux 操作符用于同步 Kubernetes 集群配置和 Git 存储库中所需状态的配置，目标是通过创建、更改和删除操作来匹配这两者。
这种同步是由 Flux 操作符通过一种基于拉的方法来完成的，在这种方法中，Flux 将不断地轮询 Git 存储库中的任何新的或变化，并将对 Kubernetes 集群进行任何创建或更新。支持 Azure Arc 的 Kubernetes 利用 GitOps 做两件事:
Kubernetes 配置的 #1
- 配置可以包括诸如名称空间、配置映射、机密、入口控制器、入口等对象。
#2 用于将应用部署到 Kubernetes
- 一个应用可以是部署、pod、服务、导航图等等。
支持 Azure Arc 的 Kubernetes 集群和 Git 存储库连接作为名为Microsoft.KubernetesConfiguration/sourceControlConfigurations的扩展资源存在于 ARM 中。这存储在一个静态加密的 Azure Cosmos DB 数据库中。对于每个支持 Azure Arc 的 Kubernetes 集群，可以有多个sourceControlConfigurations。这些可以限定在名称空间的范围内。这有助于多环境和多租户场景。
源控制配置属性包括
-
配置名称
-
操作员实例名称
-
操作员名称空间
-
存储库 URL
-
操作员范围(名称空间/集群)
-
操作员类型
-
运算符参数
-
舵(启用/禁用)
GitOps 还可以与支持 Azure Arc 的 Kubernetes 一起使用，以大规模管理大量 Kubernetes 集群的配置。这是通过使用 Azure 策略来实现的，只要 Kubernetes 集群一加入 Azure Arc，就在其上应用所需的 sourceControlConfigurations。如果您想在多个 Kubernetes 集群上应用相同的配置，比如监控代理、入口控制器、服务网格等等，那么可以使用这种方法。我们可以通过 Azure 门户或者 Azure CLI 来设置这个配置。下图是支持 Azure Arc 的 Kubernetes 的 GitOps 工作流/架构。
图 9-3
azure arc-enabled kubers gitops 工作流
在 Azure Arc 中设置 GitOps 配置
启用 Azure Arc 的 Kubernetes 中的 GitOps 设置非常简单。它只需要一些关于您的配置的核心信息，比如您的 GIT 存储库的 URL、私有的登录信息、命名空间或集群级别的范围等等。您有两个选项来设置它。您可以通过 GUI 或命令行来设置它。该设置使用以下选项工作:
选项#1 是在计划的 Kubernetes 集群上运行代码。例如，如果您正在运行 GKE，您可以将以下代码保存到一个名为“az_k8sconfig_gke.sh”的文件中，并通过 Google Cloud Shell 运行它:
az k8s-configuration create \
--name hello-arc \
--cluster-name $arcClusterName --resource-group $resourceGroup \
--operator-instance-name hello-arc --operator-namespace prod \
--enable-helm-operator \
--helm-operator-params='--set helm.versions=v3' \
--repository-url $appClonedRepo \
--scope namespace --cluster-type connectedClusters \
--operator-params="--git-poll-interval 3s --git-readonly --git-path=releases/prod"
选项#2 是通过 Azure 门户启用 GitOps 配置。
去蓝色方舟...。
单击“Add Configurations ”,并填写必需的属性和可选属性(如果需要):
-
配置名称
-
操作员实例名称
-
操作员名称空间
-
存储库 URL
-
操作员范围(名称空间/集群)
-
操作员类型
-
运算符参数
-
舵(启用/禁用)
单击添加。
Note
GitOps 配置状态将显示为挂起，最多需要 10 分钟才能变为已安装状态。
使用 GitOps 和 Azure Arc 将应用部署到计划的 Kubernetes 集群
您可以利用支持 Azure Arc 的 Kubernetes 的 GitOps 将应用部署到您的 Kubernetes 集群。一旦您在计划的 Kubernetes 集群上用支持 Azure Arc 的 Kubernetes 设置了 GitOps，这个过程就很简单了。以下步骤分解了在您计划的 Kubernetes 集群上部署应用的步骤:
-
开发人员编写应用，或者 DevOps 工程师编写用于配置 Kubernetes 集群的代码。
-
开发人员将代码推送到应用存储库的一个远程分支，并打开一个 pull 请求进行审查。
-
对拉取请求进行审查，以批准或拒绝合并。
-
根据需要验证更改。
-
领导或团队签署拉请求，变更被合并到主 Git 存储库中。
-
在很短的时间内(时间间隔由您设定)，Flux 将会注意到连接到 Flux GitOps 操作符的 Git 存储库中的新变化。
-
Flux GitOps 操作员将提取更改，并将其应用到计划的 Kubernetes 集群，从而部署应用和配置。
了解 Azure Arc 和 GitOps 如何与 Helm 一起工作
通过 GitOps 和支持 Azure Arc 的 Kubernetes 将基于 Helm 的应用部署到计划的 Kubernetes 集群类似于使用 Kubernetes 清单文件部署应用。从什么是头盔开始就有一些不同。让我们来看看理解掌舵图和 Azure Arc 支持的 Kubernetes 的一些要点:
-
Helm 是 Kubernetes 的包装经理。
-
Helm 用于管理 Kubernetes 上应用的生命周期。
-
支持 Azure Arc 的 Kubernetes 中的 Helm operator 为 Flux 提供了一个扩展，可以自动发布 Helm chart。
-
在 Arc K8s GitOps 配置中，舵被设置为禁用或启用。
-
操作员利用“HelmRelease”自定义资源定义(CRD)。
-
HelmRelease 可以将特定的值输入到一个 helm 图表中，这使得为不同的环境赋值变得很容易，比如 dev、stage、prod 等。
了解 Azure Arc 和 GitOps 如何处理物联网边缘工作负载
Azure 提供了一个将云分析和定制业务逻辑转移到设备上的产品。该产品被称为 Azure IoT Edge。物联网边缘将服务打包在边缘设备上运行的容器中。这些容器可以运行 Azure 服务、第三方服务或您自己的自定义代码。IoT Edge 与 IoT Hub 和 Azure 中的其他服务协同工作。物联网边缘运行 Kubernetes 作为物联网边缘应用可以运行的操作环境。支持 Azure Arc 的 Kubernetes 可以管理物联网边缘上的 Kubernetes 集群。GitOps 可用于通过支持 Azure Arc 的 Kubernetes 将物联网边缘工作负载部署到物联网边缘。支持 Azure Arc 的 Kubernetes 和 IoT Edge 的要点包括:
-
借助物联网边缘，您可以自带 K8s 集群，并在其中注册物联网边缘自定义资源定义(CRD)控制器。
-
Arc K8s 可用于操作运行物联网边缘的 K8s 集群，包括通过 GitOps 远程部署/管理大规模工作负载，以及执行与云服务(即物联网中心)的双向接收。
-
所有物联网边缘组件都限定在特定的 Kubernetes 名称空间范围内，允许您将单个集群用于多个边缘设备。
摘要
这使我们结束了这本书的最后一章。这本书介绍了 Azure Arc 的世界和它的两个主要产品:服务器和 Kubernetes。在这一章中，我们首先了解了支持 Azure Arc 的 Kubernetes 及其各种用例，并探讨了支持 Azure Arc 的 Kubernetes 架构，将 Arc 连接到 Kubernetes 集群，监控它们，保护它们，并在计划的 Kubernetes 集群上实施合规性。我们还学习了 GitOps 和支持 Azure Arc 的 Kubernetes，包括 GitOps 是什么，它如何与支持 Azure Arc 的 Kubernetes 一起工作，以及如何使用 GitOps 将配置和应用部署到计划的 Kubernetes 集群。感谢你在这本书里带领我们穿越 Azure Arc。
