如何定义 Azure 基于角色的访问控制 (RBAC)，第二部分

2020-10-26 08:00:00 · 飞浪

本指南介绍如何将角色分配和资源标记与 Powershell 控制流相结合，以在几行代码中做出数百处更改。

介绍

当您的云基础架构规模庞大，包含数十个应用和数百个用户时，以可重现和透明的方式管理所有这些权限将变得困难。上一篇指南《如何定义 Azure 基于角色的访问控制 (RBAC)》介绍了使用 Azure CLI 进行角色定义和分配的基本用法。

在本指南中，您将基于这些技能学习如何将角色分配和资源标记与 Powershell 控制流相结合，以在几行代码中进行数百处更改。

使用 ForEach 迭代身份

Azure 提供资源组来帮助您管理和保护您的应用和其他受保护的资源。这允许您将相关资源分组在一起。一种常见的模式是将所有资源放在一个微服务中。这可能包括 Azure 应用服务及其用于保存数据的存储帐户。

在此模式中，每个 Azure 应用服务应仅具有访问其资源组内的存储帐户的权限。要在 Powershell 中执行此操作，请使用ForEach-Object Cmdlet遍历所有资源组及其内部的应用。

      # get all resource groups
$groups = az group list -o json | ConvertFrom-Json

# iterate over all resource groups
$groups | foreach {
    $rg=$_.name
    $rgid = $_.id

    # get all apps inside a resource group and iterate over them
    $apps=az webapp list -g $rg -o tsv --query "[].name"
    $apps | foreach {
        $app=$_
        $id = az webapp identity assign -g $rg -n $app -o tsv --query "principalId"
        az role assignment create --role "Storage Blob Data Contributor" --assignee $id --scope $rgid
        # get the deployment slots if any
        $slots = az webapp deployment slot list -g $rg -n $app -o tsv --query "[].name"
        # make sure an managed identity is assigned
        $slots | foreach {
            $id = az webapp identity assign -g $rg -s $_ -n $app -o tsv --query "principalId"
            az role assignment create --role "Storage Blob Data Contributor" --assignee $id --scope $rgid
        }
    }
}
    

上面的代码片段演示了如何使用ForEach-Object cmdlet将存储 Blob 数据贡献者角色分配给每个应用服务。请注意，应用程序仅被授权访问其自身资源组中的存储帐户。该 cmdlet 有一个别名foreach，这使代码稍微简洁一些。此代码的优点是它是可重入的；当您第一次运行它时，它将创建系统分配的托管标识和角色。如果您重新运行代码并且这些对象已经创建，它不会抛出错误。

如果要将许多相同的角色分配应用于不同的应用，则可能需要创建将多个角色组合在一起的自定义角色定义。本指南的第一部分“如何定义 Azure 基于角色的访问控制 (RBAC)”演示了自定义角色定义。这可能是必需的，因为每个 Azure 订阅的角色分配有 2000 个硬性限制。

跳过某些资源的角色分配

Azure 的另一个有用的组织功能是标记资源组和资源的能力。这可以帮助您的安全基础架构，因为您可以建立约定和模式，使您的组织更容易进行广泛的更改。要利用标记进行 RBAC 角色分配，请编写 JMESQuery来过滤掉资源。这允许您跳过某些资源或组的角色分配。

以下代码片段演示了如何对资源组和 Azure 应用服务执行此操作。

      # filter out resource groups have the tag "sec:sensitive"
az group list -o json --query "[?tags.sec!='sensitive']" | ConvertFrom-Json

# filter out app services have that the tag "sec:sensitive"
az webapp list -g rg-pl-demo --query "[?tags.sec!='sensitive'].name"
    

通过正确标记资源，您可以设置具有不同安全要求的不同资源组。然后，您的自动化脚本可以读取这些标记，以一致地应用您组织的安全策略。

结论

命名和标记对于扩展云基础架构非常重要。您已使用标记来定义安全策略，但它们也可以用于其他用途，例如成本监控和资产组织。请阅读Microsoft 推荐的命名和标记最佳实践以了解更多信息。

_{免责声明：本内容来源于第三方作者授权、网友推荐或互联网整理，旨在为广大用户提供学习与参考之用。所有文本和图片版权归原创网站或作者本人所有，其观点并不代表本站立场。如有任何版权侵犯或转载不当之情况，请与我们取得联系，我们将尽快进行相关处理与修改。感谢您的理解与支持！}

_查看原文

技术指南

阅读全文

如何定义 Azure 基于角色的访问控制 (RBAC)，第二部分

杭州电子商务研究院

4年前 · 面向社会、服务行业、政产学研结合、整合资源、和谐发展

# get all resource groups $groups = az group list -o json | ConvertFrom-Json # iterate over all resource groups $groups | foreach { $rg=$_.name $rgid = $_.id # get all apps inside a resource group and iterate over them $apps=az webapp list -g $rg -o tsv --query "[].name" $apps | foreach { $app=$_ $id = az webapp identity assign -g $rg -n $app -o tsv --query "principalId" az role assignment create --role "Storage Blob Data Contributor" --assignee $id --scope $rgid # get the deployment slots if any $slots = az webapp deployment slot list -g $rg -n $app -o tsv --query "[].name" # make sure an managed identity is assigned $slots | foreach { $id = az webapp identity assign -g $rg -s $_ -n $app -o tsv --query "principalId" az role assignment create --role "Storage Blob Data Contributor" --assignee $id --scope $rgid } } }

# filter out resource groups have the tag "sec:sensitive" az group list -o json --query "[?tags.sec!='sensitive']" | ConvertFrom-Json # filter out app services have that the tag "sec:sensitive" az webapp list -g rg-pl-demo --query "[?tags.sec!='sensitive'].name"