Learn how Cribl Lake authenticates to your Azure Blob Storage using a Cribl-managed Enterprise Application.

IT and security teams can use this topic when evaluating the Azure admin consent step in Configure an Azure Storage Location.

Summary ​

What Is the Cribl Lake Enterprise Application? ​

To read and write data in your Azure Blob Storage containers, Cribl Lake uses AWS IAM Outbound Identity Federation with Azure Entra ID Workload Identity Federation. This is a standard cross-cloud authentication pattern for organizations that run infrastructure on both AWS and Azure.

Cribl maintains a multi-tenant Azure App Registration in the Cribl Entra ID tenant. When your administrator approves the admin consent URL, Azure creates a Service Principal (a machine identity) in your tenant. That Service Principal:

• Acts as the local representation of the Cribl application in your directory.
• Does not sign in interactively.
• Does not appear as a user in your directory.
• Holds only the RBAC assignments you configure with the Cribl ARM template.

Microsoft recommends this pattern for SaaS applications and cross-cloud integrations that authenticate to Azure with federated credentials.

What Admin Consent Does ​

Admin consent creates a Service Principal in your tenant. It does not grant storage access. Storage access comes only from the RBAC roles you assign when you deploy the ARM template.

When an admin approves the consent URL:

• Azure creates a Service Principal in your tenant linked to the Cribl App Registration.
• The Service Principal is registered as a Workload Identity, not a user identity.
• No permissions are granted at this step. You configure RBAC separately with the ARM template.

Consent is a one-time action. You do not need administrator intervention again unless you remove and re-add the application.

Required Azure Roles ​

Creating the Service Principal in your tenant requires one of these roles:

• Global Administrator
• Privileged Role Administrator
• Cloud Application Administrator (if configured in your tenant’s consent policy)

What Admin Consent Does Not Grant ​

Approving the Cribl Lake Enterprise Application does not grant:

How Authentication Stays Scoped ​

Workload Identity Federation is a credential exchange mechanism, not an API access grant. Entra ID acts as a token broker, not as a resource that Cribl accesses.

Approving the Cribl Enterprise Application does not open new endpoints, network paths, or public API surfaces in your Azure environment. The token exchange endpoint (https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token) is a pre-existing, Microsoft-hosted public endpoint available for every Entra ID tenant. It is part of the Microsoft identity platform and OAuth 2.0 authorization code flow.

Adding the Cribl Enterprise Application:

• Does not create a new public endpoint.
• Does not enable inbound network connectivity to your tenant.
• Does not expose your Entra ID instance beyond Microsoft’s existing infrastructure.
• Does not grant Cribl access to Microsoft Graph or any Entra ID management surface.

In practice:

• The Cribl Service Principal authenticates with a federated credential (an AWS-signed JWT), not a client secret or certificate stored in your tenant.
• The only Entra ID interaction is the token exchange endpoint (/oauth2/v2.0/token), which validates the JWT and returns a scoped Bearer token. That endpoint is the standard OAuth 2.0 token endpoint, not a management API.
• The Bearer token grants access only to Azure Blob Storage on storage accounts where you assigned RBAC roles. It cannot call Microsoft Graph, Entra ID management APIs, or other Azure services.
• No client secret or certificate is stored in your Entra ID instance. The federated identity credential references an external AWS OIDC issuer with a case-sensitive subject and audience match.
• Before issuing a token, the federated credential validates three claims: issuer (AWS OIDC provider URL), subject (specific Cribl IAM role ARN), and audience (api://AzureADTokenExchange). All three must match.

Microsoft has documentation on federated identity credentials which describes this pattern as eliminating the maintenance burden of manually managing credentials and the risk of leaking secrets.

How Authentication Works ​

Cribl Lake runs on AWS infrastructure. When it needs to access your Azure Blob Storage:

1. Cribl obtains a short-lived identity token from AWS Security Token Service (STS). This signed JWT is valid for about 15 minutes.
2. Cribl exchanges the JWT with Azure Entra ID for a Bearer access token. Azure validates the token against the federated identity credentials on the Cribl App Registration. The Bearer token is valid for about 1 hour.
3. Cribl generates a scoped User Delegation SAS token with the Bearer token. The SAS token is limited to the configured storage account and containers.
4. Workers use the SAS token to read and write blobs directly to your storage. Cribl does not store long-term Azure credentials.

Permissions Granted via the ARM Template ​

After admin consent, deploying the BYOS Azure ARM Template assigns RBAC roles to the Service Principal:

These roles are scoped to the storage account created by the ARM template. They do not provide access to other resources in your Azure subscription.

Revoke Access ​

To remove Cribl access:

1. Remove the RBAC role assignments from the storage account. Data access ends immediately.
2. Delete the Enterprise Application from your Entra ID tenant to remove the Service Principal.

Both actions are under your control and take effect immediately. For related steps in Cribl Lake, see Detach an Azure Storage Location.