Cloudaware Azure Permissions And Roles

This document summarizes Azure RBAC roles, Microsoft Graph permissions, and example custom roles used by Cloudaware.

For implementation details, follow the provider-specific Microsoft Azure integration and Azure Billing guides.

note

Some examples below contain placeholders. Replace placeholders such as subscription IDs or scope paths with your own values.

Baseline Discovery Access (Required)

Baseline permissions are required for Cloudaware to discover Azure subscriptions, resource groups, and other resources.

• Identity model:
  • Use a dedicated app registration, or service principal, for Cloudaware (for example, cloudaware-api-access).
  • Prefer a single app per Azure AD/Microsoft Entra ID tenant instead of one app per subscription.

Built‑in Reader Role

• Scope:
  • Tenant-wide: Assign the role at the Tenant Root Management Group to onboard subscriptions automatically.
  • Selected subscriptions: Assign the role to each subscription you want Cloudaware to monitor.
• Role:
  • Reader at the selected scope.
• Effect:
  • Enables read-only access to Azure Resource Manager for compute, storage, networking, databases, security, and management resources.
  • Does not allow changes to resources.

Custom Cloudaware Reader Role

For environments that prefer a custom role, use a minimal read‑only role and assign it to the Cloudaware app’s service principal at management group or subscription scope.

Example custom role (subscription scope):

{
  "Name": "Cloudaware Reader",
  "IsCustom": true,
  "Description": "Read access for Cloudaware discovery",
  "Actions": [
    "*/read"
  ],
  "NotActions": [],
  "AssignableScopes": [
    "/subscriptions/<SUBSCRIPTION_ID>"
  ]
}

Adjust Actions as needed to align with your security policies and add or remove scopes under AssignableScopes.

App Registration and Directory Permissions

The app registration used by Cloudaware must have API permissions configured in the Azure portal.

Azure Service Management (Azure Resource Manager)

• API: Azure Service Management
• Permission type: Delegated
• Permission:
  • user_impersonation

This allows the Cloudaware app to access Azure Resource Manager on behalf of an organization user as required for the integration workflow.

Microsoft Graph Directory Permissions

Baseline directory permissions:

• API: Microsoft Graph
• Application permissions:
  • Directory.Read.All
• Delegated permissions:
  • Directory.Read.All

These permissions allow Cloudaware to read users, groups, devices, applications, and service principals from Microsoft Entra ID/Azure AD.

If you want to collect only specific directory objects, you can replace Directory.Read.All with more granular application permissions such as:

• User.Read.All
• Device.Read.All

After adding permissions, always click Grant admin consent so they become effective.

Optional Feature‑Specific Permissions

Enable the following only if you plan to use the corresponding Cloudaware features. Keep scopes as narrow as practical (management group, subscription, or resource group) and avoid assigning broad write roles such as Contributor unless explicitly required.

Storage Account Keys and VM Extensions

Required for collecting VHD metadata and for installing or managing Breeze Agent via VM extensions from Cloudaware.

• Create a custom role that includes at minimum:
  • Microsoft.Storage/storageAccounts/listKeys/action
  • Microsoft.Compute/virtualMachines/extensions/write (only if you use Breeze Agent deployment from Cloudaware)

Example custom role JSON:

{
  "IsCustom": true,
  "Name": "Cloudaware Collector Extended",
  "Description": "Adds access to storage account keys and VM extensions for Cloudaware to collect data about Blob Containers and VHDs",
  "Actions": [
    "Microsoft.Storage/storageAccounts/listKeys/action",
    "Microsoft.Compute/virtualMachines/extensions/write"
  ],
  "notActions": [],
  "assignableScopes": [
    "/subscriptions/{subscription_id}"
  ]
}

Replace {subscription_id} with your Azure subscription ID and assign this role to the Cloudaware app at the appropriate scope.

Azure Key Vault Metadata

Cloudaware can inventory Key Vault keys, secrets, and certificates, including expiration metadata. It does not require access to secret values.

• RBAC:
  • Keep Reader at the subscription or resource group level.
• Key Vault access policy for the Cloudaware app:
  • Key permissions: List
  • Secret permissions: List
  • Certificate permissions: List

note

Cloudaware retrieves metadata only (Azure Key Vault Key and Azure Key Vault Secret objects). No secret values are read.

Azure Reservations

To inventory Azure Reservations:

• Role: Reservations Reader
• Scope: Reservations/billing scope where reservations are managed.
• Principal: Cloudaware app (service principal, for example, cloudaware-api-access).

Allow up to 24 hours for new reservations data to appear in Cloudaware after enabling access.

Azure Kubernetes Service (AKS)

Cloudaware discovers AKS clusters by default. To enrich cluster data with user credentials and Kubernetes objects:

• At each onboarded subscription, assign one of:
  • Built‑in role: Azure Kubernetes Service Cluster User Role, or
  • A custom role that includes:
    • Microsoft.ContainerService/managedClusters/listClusterUserCredential/action
• Scope: Subscription or resource group that contains the AKS clusters.

tip

For Active Directory–managed clusters, configure Kubernetes cluster role bindings as described in the AKS Cluster Access guide.

Microsoft Intune–Managed Devices

To collect Azure AD devices managed by Intune:

• API: Microsoft Graph
• Application permissions:
  • DeviceManagementManagedDevices.Read.All
  • DeviceManagementConfiguration.Read.All

After granting admin consent, Cloudaware can inventory Intune‑managed Azure AD devices and related configuration objects.

App Service Configuration Settings

Cloudaware automatically discovers Azure App Services with baseline Reader access. To collect App Service configuration settings (for example, the Config: App Settings field in CMDB):

• Preferred approach:
  • Create a custom role that includes:
    • Microsoft.Web/sites/config/list/action
    • Microsoft.Web/sites/Read
• Alternative (broader) approach:
  • Assign built‑in role: Website Contributor

Example custom role JSON (subscription scope):

{
  "properties": {
    "roleName": "Cloudaware App Service Config Reader",
    "description": "{custom-role-description}",
    "assignableScopes": [
      "/subscriptions/{subscription-id}"
    ],
    "permissions": [
      {
        "actions": [
          "Microsoft.Web/sites/config/list/Action",
          "Microsoft.Web/sites/Read"
        ],
        "notActions": [],
        "dataActions": [],
        "notDataActions": []
      }
    ]
  }
}

Replace {custom-role-description} and {subscription-id} with appropriate values and assign the role to the Cloudaware app.

Tagging from Cloudaware

To allow Cloudaware Tag Analyzer and automation workflows to add or update tags on Azure resources:

• Built‑in role (recommended):
  • Tag Contributor at the scope where tag changes are expected (subscription or resource group).
• Custom role alternative:
  • Grant Microsoft.Resources/tags/* and related tag name operations at the required scope.

Example custom role JSON (subscription scope):

"properties": {
  "roleName": "Cloudaware Tagging Role",
  "description": "{custom-role-description}",
  "assignableScopes": [
    "/subscriptions/{subscription-id}"
  ],
  "permissions": [
    {
      "actions": [
        "Microsoft.Resources/subscriptions/tagNames/read",
        "Microsoft.Resources/subscriptions/tagNames/write",
        "Microsoft.Resources/subscriptions/tagNames/delete",
        "Microsoft.Resources/subscriptions/tagNames/tagValues/read",
        "Microsoft.Resources/subscriptions/tagNames/tagValues/write",
        "Microsoft.Resources/subscriptions/tagNames/tagValues/delete",
        "Microsoft.Resources/subscriptions/resourceGroups/read",
        "Microsoft.Resources/tags/write",
        "Microsoft.Resources/tags/delete",
        "Microsoft.Resources/tags/read"
      ],
      "notActions": [],
      "dataActions": [],
      "notDataActions": []
    }
  ]
}

tip

Limit tagging permissions to subscriptions or resource groups where tag changes from Cloudaware are required.

To learn how to work with tags in Cloudaware, see Cloudaware Tag Analyzer.

Azure Billing Exports

Cloudaware ingests Azure billing data from Cost Management exports stored in Azure Storage. Required roles are:

• Billing scope:
  • At billing account level (MCA/MPA/EA):
    • Role: Billing account reader (or equivalent EA enrollment reader role).
    • Scope: Billing account.
  • At subscription level:
    • Role: billing reader role appropriate to the subscription (for example, built‑in reader roles in Cost Management + Billing).
• Storage accounts that receive Cost Management exports:
  • Role: Storage Blob Data Reader
  • Scope: Storage account (or narrower, such as specific containers if your policies require it).
  • Principal: Cloudaware app (service principal).

For detailed export configuration, see Azure Billing.

Conflux (Log Management)

For Cloudaware Conflux to collect Azure logs:

• Enable diagnostic settings and flow logs on the services you want to monitor.
• Ensure Cloudaware has one of:
  • Baseline Reader or custom Cloudaware Reader role at the relevant scopes, and
  • Additional storage access where logs are written (for example, the Cloudaware Collector Extended role for account keys, or Storage Blob Data Reader for Blob data where logs reside).
• Confirm that storage accounts or other log destinations used for exports are reachable and sized appropriately.

See Log Management Requirements for a high‑level overview of log source prerequisites.

Scoping and Governance Recommendations

• Prefer management‑group assignments for large organizations; use subscription‑level assignments for tighter boundaries.
• Keep scopes as narrow as possible for optional roles (Key Vault, AKS, tagging, billing, log storage).
• Review role assignments regularly and remove unused permissions to minimize the privilege footprint.
• Avoid using broad write roles such as Contributor for the Cloudaware app except where absolutely necessary and explicitly documented.

Related

• Microsoft Azure