创建一个azure策略来阻止角色分配给某些主体类型，除非是由指定的用户创建的

Question

我有一个需求，订阅所有者只能为应用程序创建角色分配，不能为用户和组创建角色分配。对于允许为用户和组创建角色分配的某些身份，应该有一个例外。

下面的策略适用于现有的角色分配。由指定id创建的组/用户的现有角色分配符合要求。对其他主体创建的用户/组的现有角色分配不兼容。太棒了!

但是当其中一个指定的id创建一个新的角色分配时，它被拒绝。

{
"properties": {
"displayName": "eslz-restrict role assigments",
"description": "Restrict role assignments to SPNs only, except when granted by specified ids",
"mode": "All",
"metadata": {
"version": "1.0.0",
"category": "RoleAssignments"
},
"parameters": {},
"policyRule": {
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Authorization/roleAssignments"
},
{
"anyOf": [
{
"field": "Microsoft.Authorization/roleAssignments/principalType",
"equals": "User"
},
{
"field": "Microsoft.Authorization/roleAssignments/principalType",
"equals": "Group"
}
]
},
{
"anyOf": [
{
"not": {
"field": "Microsoft.Authorization/roleAssignments/createdBy",
"in": [
"bcd054a8-7cbf-4317-a673-93d32b7e296a",
"13f29b01-7105-4f63-bd56-259ce07df96d"
]
}
},
{
"not": {
"field": "Microsoft.Authorization/roleAssignments/updatedBy",
"in": [
"bcd054a8-7cbf-4317-a673-93d32b7e296a",
"13f29b01-7105-4f63-bd56-259ce07df96d"
]
}
}
]
}
]
},
"then": {
"effect": "deny"
}
}
}
}

Answer 1

不幸的是，在这种情况下Microsoft.Authorization/roleAssignments/createdBy和Microsoft.Authorization/roleAssignments/updatedBy不可用，查找尚未创建的对象的这些值还为时过早。您可以通过调用az role assignment create --assignee objectName --role Contributor --scope /subscriptions/000-0030303-0303/resourceGroups/30303030亲自查看。这将产生一个PolicyViolation响应，其中包含详细的evaluationDetails，其中部分内容如下(如果您尝试通过门户，则不会看到此详细内容):

{
"result": "False",
"expressionKind": "Field",
"expression": "Microsoft.Authorization/roleAssignments/createdBy",
"path": "properties.createdBy",
"targetValue": [
"5000-0-0-0-0-0--0000"
],
"operator": "In"
}

你可以看到，它缺少一个expressionValue。这仅仅意味着它无法获取表达式的值。

找到一个值的求值看起来像这样:

{
"result": "True",
"expressionKind": "Field",
"expression": "type",
"path": "type",
"expressionValue": "Microsoft.Authorization/roleAssignments",
"targetValue": "Microsoft.Authorization/roleAssignments",
"operator": "Equals"
},

createdBy,updatedBy以及像createdOn和updatedOn这样的属性都有这个问题(我只检查了roleAssignments的别名，其他对象也有类似的别名，但我没有测试这些)。这些有用的唯一场景是当您想要审计现有的分配时。您将注意到，这将工作得很好，因为当实际编写赋值时，它显然具有所有值。

我认为微软处理的逻辑是:只有当createdOn属性是已知的，然后我们可以假设createdBy属性将是什么。而createdOn在政策评估中永远不可能被知道，因为它永远不知道评估是在什么时候完成的。也许它是有缺陷的，但这就是你得到的。