> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oleria.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Azure

Oleria provides identity security and access management teams with visibility and intelligence into who has access to what, where they got that access, how they use it, and whether they should even have it. As part of that promise, we integrate your Azure environment into the Oleria platform, giving you visibility into Azure role-based access control (RBAC) across your management groups, subscriptions, and resources. This document provides step-by-step guidance for integrating Azure with your Oleria workspace.

<Note>This integration covers Azure Resource Manager - RBAC roles, resources, and Azure Activity Log - plus your Microsoft Entra ID user and group directory. For sign-in and audit activity, and for user or group lifecycle actions, see the separate [Microsoft Entra ID](/integrations/microsoft-entra-id) integration.</Note>

## What Oleria discovers

| Area                           | Detail                                                                                                                                                                                                                                                                                                                                                   |
| :----------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Accounts**                   | The full Microsoft Entra ID user and group directory, synced directly through this integration via Microsoft Graph - a separate [Microsoft Entra ID](/integrations/microsoft-entra-id) connection isn't required for that. Also service principals and managed identities, prioritizing ones the tenant owns or that hold a role assignment.             |
| **Roles and role assignments** | Azure RBAC roles and who or what holds them, at every scope Oleria can see - management group, subscription, resource group, or resource - including deny assignments scoped at the subscription level or above, shown as denied rather than granted access. See [Known limitations](#known-limitations) for deny assignments scoped narrower than that. |
| **Resources**                  | Storage accounts, storage blob containers, and virtual machines, plus the containment hierarchy from management groups down to individual resources.                                                                                                                                                                                                     |
| **Key Vault**                  | Vault inventory with secret metadata (name, expiry, and similar properties, never values) and each vault's own access policies or RBAC role assignments. Oleria also flags secrets that are expired, expiring within 30 days, or have no expiration set.                                                                                                 |
| **External access**            | Azure Lighthouse delegated access from other tenants (for example, a managed service provider), which doesn't show up in a normal Azure RBAC read.                                                                                                                                                                                                       |
| **Activity**                   | Azure Activity Log - administrative and policy-change operations across each subscription. Not Microsoft Entra sign-in or audit activity; that comes from the Microsoft Entra ID integration.                                                                                                                                                            |
| **Risk signals**               | Microsoft Defender for Cloud findings, plus Oleria's own checks for over-privileged roles, public storage access, exposed secrets, and Azure Policy compliance. Requires Defender for Cloud to be enabled - see [Enable Microsoft Defender for Cloud](#enable-microsoft-defender-for-cloud-for-risk-signals-optional) below.                             |

## Prerequisites

* A **Microsoft Entra ID** tenant where you can register an application.
* A user who can grant **Azure RBAC roles** at your chosen scope (management group or subscription) - a **User Access Administrator**, **Owner**, or your tenant's **Global Administrator**.
* A **Global Administrator** or **Privileged Role Administrator** to grant admin consent for the Microsoft Graph API permissions below.
* Optional: **Microsoft Defender for Cloud** enabled on the subscription, if you want Azure security findings in Risk Monitoring.

<Note>This integration connects to the Azure Public Cloud only. Azure Government and Azure China aren't supported.</Note>

## Set up the integration

Azure authentication uses a Microsoft Entra ID **service principal**, either a client secret or a client certificate. You register an application in Microsoft Entra ID, grant it Azure RBAC roles and Microsoft Graph permissions, and provide the credentials to Oleria.

<Steps>
  <Step title="Register an application">
    1. Log in to the [Azure Portal](https://portal.azure.com) and go to **Microsoft Entra ID** -> **App registrations**.

    2. Select **New registration**, give the app a name (for example, `Oleria`), and select **Register**.

    3. On the app's **Overview** page, copy the **Application (client) ID** and **Directory (tenant) ID** - you'll enter both in Oleria.
  </Step>

  <Step title="Create a credential">
    <Tabs>
      <Tab title="Client secret (default)">
        1. In the app, select **Certificates & secrets** -> **Client secrets** -> **New client secret**.

        2. Provide a description and expiration, then select **Add**.

        3. Copy the secret's **Value** immediately - Azure shows it only once.
      </Tab>

      <Tab title="Client certificate">
        1. Generate a certificate and an unencrypted (no passphrase) private key.

        2. In the app, select **Certificates & secrets** -> **Certificates** -> **Upload certificate**, and upload the public certificate file. Azure only ever receives this public half.

        3. Combine the certificate and its private key into a single PEM file (the certificate block followed by the private key block), then base64-encode the whole file. Paste that base64 string into Oleria's **Private Key** field - not the raw PEM, and not the certificate alone.
      </Tab>
    </Tabs>

    <Warning>If you lose a client secret or the certificate's private key, generate a new one and update the credential in Oleria by editing the integration. Azure doesn't let you retrieve a previously generated secret. The private key must not be passphrase-protected - Oleria can't prompt for one.</Warning>
  </Step>

  <Step title="Grant Microsoft Graph API permissions">
    1. In the app, select **API permissions** -> **Add a permission** -> **Microsoft Graph** -> **Application permissions**.

    2. Search for and add:

    ```
    User.Read.All
    Group.Read.All
    Application.Read.All
    ```

    3. Select **Add permissions**, then select **Grant admin consent for \[your tenant]** and confirm.

    <Note>`Directory.Read.All` is optional. It enriches visibility into OAuth2 application permission grants in your tenant - which apps have been consented to and by whom. Skipping it doesn't block setup or any of the permissions above.</Note>
  </Step>

  <Step title="Grant Azure RBAC roles">
    Oleria's read access is entirely determined by the Azure RBAC roles you grant here - the connection form has no separate scope selector.

    1. In the Azure Portal, navigate to your chosen scope and select **Access control (IAM)** -> **Add** -> **Add role assignment**.

    * **Management group (recommended)** - grants visibility across every subscription under it. Requires a Global Administrator or User Access Administrator at the tenant root.
    * **Subscription** - scopes Oleria to a single subscription. Self-service by that subscription's Owner or User Access Administrator.

    2. Select the **Reader** role, then under **Members**, search for and select the application you registered in Step 1.

    3. Select **Review + assign** twice to confirm.

    <Note>To also inventory Key Vault secret metadata, grant the same application the **Key Vault Reader** role on each Key Vault (or a broader scope covering them) - this applies to vaults using Azure's RBAC permission model. Vaults still on the legacy access policy model need an access policy instead, granting **Get** and **List** secret permissions. If Key Vault secrets don't appear in Oleria after your first sync, the vault's role may need to be widened to **Key Vault Secrets User** instead.</Note>
  </Step>

  <Step title="Enable Microsoft Defender for Cloud for risk signals (Optional)">
    Oleria's Azure risk signals include Microsoft Defender for Cloud findings.

    <Warning>
      Skipping this step doesn't break setup - the connection still completes and syncs your RBAC and resource data normally - but Defender for Cloud findings won't appear in Risk Monitoring until it's enabled. No additional Azure RBAC role is needed beyond the Reader role granted above.
    </Warning>

    In the Azure Portal, go to **Microsoft Defender for Cloud** -> **Environment settings**, select your subscription, and either toggle on the plans you want or select **Enable all**, then select **Save**.
  </Step>
</Steps>

## Connect Azure to Oleria

<Steps>
  <Step title="Open the integration">
    Log in to your Oleria workspace and navigate to **Integrations** -> **Azure** -> **Connect**.
  </Step>

  <Step title="Complete the connection form">
    Provide the following and select **Authenticate**:

    | Field                     | Notes                                                                                                                                                                                    |
    | :------------------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
    | **Authentication Method** | Required. **Client Secret Authentication** or **Client Certificate Authentication**, matching the credential you created in Step 2.                                                      |
    | **Tenant Id**             | Required. The Directory (tenant) ID from Step 1.                                                                                                                                         |
    | **Client Id**             | Required. The Application (client) ID from Step 1.                                                                                                                                       |
    | **Client Secret**         | Required if Authentication Method is Client Secret. The secret value from Step 2.                                                                                                        |
    | **Private Key**           | Required if Authentication Method is Client Certificate. The base64-encoded, combined certificate-and-private-key PEM file from Step 2 - not the certificate file you uploaded to Azure. |
  </Step>

  <Step title="Complete the connection">
    Oleria validates the connection, discovers your Azure roles, resources, and accounts, and begins the first sync.
  </Step>
</Steps>

## Verify the integration

Confirm Azure appears in your Oleria workspace's connected integrations. After the first sync completes, you can review the discovered accounts, roles, resources, and activity in your Oleria workspace.

## Remediation actions

All remediation actions require approval before Oleria runs them, and each needs an Azure RBAC role beyond the base Reader role granted during setup:

* **Assign Azure role** and **Remove Azure role assignment** need **Role Based Access Control Administrator** (or **User Access Administrator**) at the same scope as the Reader role.
* **Disable managed identity** needs **Role Based Access Control Administrator** (or **User Access Administrator**) scoped to the managed identity's own resource - not necessarily at the broader scope where Reader was granted.
* **Revoke public access to storage container** needs **Storage Account Contributor** on the relevant storage account.

| Action                                        | Notes                                                                                                                                                                                                                                                                                                     |
| :-------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Assign Azure role**                         | Grants an Azure RBAC role to a principal at a scope. Reverting removes the assignment it created.                                                                                                                                                                                                         |
| **Remove Azure role assignment**              | Removes an Azure RBAC role from a principal at a scope. Can't be reverted - re-granting requires running Assign Azure role again, since the removed assignment's ID can't be reused.                                                                                                                      |
| **Disable managed identity**                  | Revokes every Azure role assignment held by a system-assigned managed identity on a supported virtual machine. Only system-assigned managed identities on virtual machines are eligible - other principal types are rejected outright. Fully reversible: re-grants the exact roles and scopes it removed. |
| **Revoke public access to storage container** | Removes anonymous access from a Storage blob container and its parent storage account - every other public container in that account becomes private too. See the warning below for revert behavior.                                                                                                      |

<Warning>Reverting **Revoke public access to storage container** restores only the original container's setting - Oleria won't re-expose the account or its other containers.</Warning>

## Known limitations

* **Role inheritance:** Azure RBAC roles don't nest. Oleria reflects direct role assignments and scope inheritance (management group down to resource), not role-to-role membership.
* **Deny assignment scope:** Oleria only sees deny assignments scoped at the subscription level or inherited from a management group. A deny assignment scoped to a specific resource group or individual resource isn't visible - Azure has no bulk way to discover those below subscription level.
* **PIM-eligible roles:** Oleria only sees roles a principal actively holds right now. Azure Privileged Identity Management (PIM) eligible, just-in-time role assignments aren't modeled - a principal that can activate a role but hasn't isn't reflected as having it.
* **Human account lifecycle:** Azure Resource Manager has no user or group provisioning API. To disable, offboard, or manage group membership for human users, connect [Microsoft Entra ID](/integrations/microsoft-entra-id).
* **Activity actor:** Oleria records the raw caller identifier (UPN or GUID) from the Azure Activity Log rather than resolving it to a specific Account node. Only Administrative and Policy category events are captured; the Activity Log's other categories (for example Security and Alert) aren't processed.
* **Resource coverage:** Only Storage accounts, storage blob containers, virtual machines, and Key Vaults are curated as resources with full access data. Other Azure resource types aren't inventoried at this level of detail, and Storage SAS tokens and SQL logins aren't covered.
* **Transient Resource Graph outages:** if Azure Resource Graph fails during a sync cycle, affected Key Vaults' secret data is skipped for that cycle rather than published incomplete. It resumes automatically on the next sync - no action needed.

## Contact us

For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).