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.

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 integration.

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 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 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 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.

This integration connects to the Azure Public Cloud only. Azure Government and Azure China aren’t supported.

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.

Log in to the Azure Portal and go to Microsoft Entra ID -> App registrations.
Select New registration, give the app a name (for example, Oleria), and select Register.
On the app’s Overview page, copy the Application (client) ID and Directory (tenant) ID - you’ll enter both in Oleria.

Create a credential

Client secret (default)
Client certificate

In the app, select Certificates & secrets -> Client secrets -> New client secret.
Provide a description and expiration, then select Add.
Copy the secret’s Value immediately - Azure shows it only once.

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.

Grant Microsoft Graph API permissions

In the app, select API permissions -> Add a permission -> Microsoft Graph -> Application permissions.
Search for and add:

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

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

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.

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.

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.

Select the Reader role, then under Members, search for and select the application you registered in Step 1.
Select Review + assign twice to confirm.

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.

Enable Microsoft Defender for Cloud for risk signals (Optional)

Oleria’s Azure risk signals include Microsoft Defender for Cloud findings.

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.

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.

Connect Azure to Oleria

Open the integration

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.

Complete the connection

Oleria validates the connection, discovers your Azure roles, resources, and accounts, and begins the first sync.

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.

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.

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.
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.

Overview

Integration Studio

Applications

Ticketing

Messaging

What Oleria discovers

Prerequisites

Set up the integration

Connect Azure to Oleria

Verify the integration

Remediation actions

Known limitations

Contact us

​What Oleria discovers

​Prerequisites

​Set up the integration

​Connect Azure to Oleria

​Verify the integration

​Remediation actions

​Known limitations

​Contact us

What Oleria discovers

Prerequisites

Set up the integration

Connect Azure to Oleria

Verify the integration

Remediation actions

Known limitations

Contact us