Improvement: support for the friendly names of the builtin roles

[t3mi]

Describe the current behavior Currently, RoleAssignment resource requires full armId value for the role which is big and unfriendly and requires subscriptionId to be present.

Describe the improvement Please add in addition support for a friendly name of the builtin role so that instead of this

apiVersion: authorization.azure.com/v1api20200801preview
kind: RoleAssignment
metadata:
  name: aso-sample-contributor
  namespace: default
spec:
  ...
  roleDefinitionReference:
    # This ARM ID represents "Contributor" - you can read about other built in roles here: https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles
    armId: /subscriptions/00000000-0000-0000-0000-000000000000/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c

user could use name of the role like this

apiVersion: authorization.azure.com/v1api20200801preview
kind: RoleAssignment
metadata:
  name: aso-sample-contributor
  namespace: default
spec:
  ...
  roleDefinitionReference:
    armName: Contributor

[theunrepentantgeek]

Good suggestion.

(Leaving needs-triage so that we discuss this when we resume our weekly sync in the new year.)

[matthchr]

We're still interested in doing this. We would be open to contributions. I would be curious how BICEP/ARM templates or something like the CLI does this.

Is it just a magical list of well-known names hardcoded, or is there some API to call?

[theunrepentantgeek]

There's a REST API to call - https://management.azure.com/providers/Microsoft.Authorization/roleDefinitions?api-version=2022-04-01, which returns a list of roles like this:

    {
      "id": "/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c",
      "name": "b24988ac-6180-42a0-ab88-20f7382dd24c",
      "properties": {
        "assignableScopes": [
          "/"
        ],
        "createdBy": null,
        "createdOn": "2015-02-02T21:55:09.8806423Z",
        "description": "Grants full access to manage all resources, but does not allow you to assign roles in Azure RBAC, manage assignments in Azure Blueprints, or share image galleries.",
        "permissions": [
          {
            "actions": [
              "*"
            ],
            "dataActions": [],
            "notActions": [
              "Microsoft.Authorization/*/Delete",
              "Microsoft.Authorization/*/Write",
              "Microsoft.Authorization/elevateAccess/Action",
              "Microsoft.Blueprint/blueprintAssignments/write",
              "Microsoft.Blueprint/blueprintAssignments/delete",
              "Microsoft.Compute/galleries/share/action",
              "Microsoft.Purview/consents/write",
              "Microsoft.Purview/consents/delete",
              "Microsoft.Resources/deploymentStacks/manageDenySetting/action"
            ],
            "notDataActions": []
          }
        ],
        "roleName": "Contributor",
        "type": "BuiltInRole",
        "updatedBy": null,
        "updatedOn": "2024-05-15T21:41:09.7999413Z"
      },
      "type": "Microsoft.Authorization/roleDefinitions"
    },

Note how it's flagged as BuiltInRole. There are 703 built in roles 😮

I'm wondering if we could use the new operatorSpec support to enable lookup of these "on the fly", giving a result like this:

apiVersion: authorization.azure.com/v1api20200801preview
kind: RoleAssignment
metadata:
  name: aso-sample-contributor
  namespace: default
spec:
  ...
  operatorSpec:
    builtInRole: Contributor

[matthchr]

@theunrepentantgeek is looking at an issue related to this that was brought up in Slack.

The difference between what was talked about there and this is that in Slack the service actually understands the "well known" mappings, whereas for RoleAssignment we would need to do the mapping locally. The underlying infrastructure required is very similar though.

We will look at working on this for 2.16.