BYOS Azure ARM Template Reference
This topic is a reference guide for the Azure ARM template generated during Azure BYOS setup.
Overview
When you create an Azure Storage Location in Cribl Lake, the system generates a customized Azure Resource Manager (ARM) template for your environment. This template provisions the Azure infrastructure required for Cribl Lake BYOS, including the storage account, inventory reporting, lifecycle management, and role assignments for the Cribl service principal.
Deploying this template is a required step in the Azure BYOS onboarding flow. It ensures your Azure environment is configured correctly before Cribl Lake begins writing or reading data.
Prerequisites
Before deploying the ARM template, ensure you have:
- An active Azure subscription.
- A resource group in the Azure region where you want to store data.
- Permissions to create storage accounts, custom role definitions, and role assignments within the target resource group (typically Owner, or User Access Administrator plus Contributor).
- The ARM template JSON file downloaded from the Cribl Lake UI. See Authenticate the Storage Account Access.
The resource group location determines where the storage account is created. Choose a region that aligns with your data residency requirements. See Supported Azure Regions.
Resources Created
The template creates the following resources in your Azure subscription:
| Resource | Type | Purpose |
|---|---|---|
| Storage account | Microsoft.Storage/storageAccounts | Primary storage for Cribl Lake Datasets |
| Blob service | Microsoft.Storage/storageAccounts/blobServices | Configures blob storage settings |
| Inventory container | Microsoft.Storage/storageAccounts/blobServices/containers | Stores daily inventory reports used for billing |
| Inventory policy | Microsoft.Storage/storageAccounts/inventoryPolicies | Generates daily Parquet reports of all blobs |
| Lifecycle policy | Microsoft.Storage/storageAccounts/managementPolicies | Auto-deletes inventory reports after 7 days |
| Custom role (data) | Microsoft.Authorization/roleDefinitions | Defines the Cribl Lake Data Access role |
| Custom role (management) | Microsoft.Authorization/roleDefinitions | Defines the Cribl Lake Storage Management role |
| Role assignment (data) | Microsoft.Authorization/roleAssignments | Grants Cribl read/write access to blob data |
| Role assignment (management) | Microsoft.Authorization/roleAssignments | Grants Cribl management access to the storage account |
Storage Account Configuration
The storage account is created with the following security settings:
- SKU: Standard_LRS (locally redundant storage)
- Kind: StorageV2
- Minimum TLS version: 1.2
- Public blob access: Disabled
- HTTPS only: Enabled
- Access tier: Hot
- Encryption: Enabled (Microsoft-managed keys)
The template does not create a data container for your Datasets. Cribl Lake creates Dataset containers automatically when you configure Datasets against this storage location.
Role Assignments
The template creates two least-privilege custom roles, scoped to the storage account, and assigns them to the Cribl
service principal. In Azure, each role name ends with the storage account name in parentheses, for example
Cribl Lake Data Access (<storage-account-name>).
| Role | Scope | Permissions |
|---|---|---|
| Cribl Lake Data Access | Storage account | Read, write, and add blob data (Dataset operations). Can’t write to the inventoryreports container. Excludes blob delete and user delegation key generation. |
| Cribl Lake Storage Management | Storage account | Read the storage account and blob service. Read, create, update, and delete containers. Read, write, and delete lifecycle policies. Read and delete inventory policies. Excludes access keys, network rules, encryption, and private endpoint management. |
The service principal ID is unique to your Cribl Workspace and is embedded in the template when you download it. This principal is authorized in your tenant when you visit the consent URL during onboarding.
Do not modify the
servicePrincipalObjectIdvalue. This is the Cribl-managed identity that your Workspace uses to access your storage.
Inventory Policy
The inventory policy generates a daily Parquet report containing metadata for all block blobs in the storage account:
- Schedule: Daily
- Format: Parquet
- Fields captured:
Name,Content-Length,Creation-Time - Destination:
inventoryreportscontainer - Exclusions: Blobs within the
inventoryreports/prefix (avoids self-referencing)
Cribl uses these inventory reports to meter storage usage for billing. The reports are stored in your storage account – the billing pipeline reads them from there.
The first inventory report may take 24-48 hours to appear after deployment. Azure may skip a daily run if the previous report is still being generated.
Inventory Cleanup
A lifecycle management policy automatically deletes inventory reports older than 7 days.
Outputs
The template returns the following values after successful deployment:
| Output | Description | Used For |
|---|---|---|
| storageAccountName | Name of the created storage account | Cribl Lake storage location configuration |
| subscriptionId | Azure subscription ID | Azure SDK authentication |
| resourceGroupName | Resource group name | Azure SDK authentication |
| tenantId | Azure AD tenant ID | Reference and validation |
These values are used by Cribl Lake to connect to your storage account. If you deploy via the Azure Portal, you can find them in the deployment Outputs tab.
Safe to Customize
- Resource group and region: Deploy to any resource group in a supported Azure region.
Do Not Modify
- Service principal object ID: Must match your Cribl Workspace identity.
- Custom roles and role assignments: Required for Cribl Lake to operate. Removing or narrowing these will cause connectivity failures.
- Inventory policy: Required for billing - disabling this will prevent Cribl from metering usage.
- Storage account name: Generated by Cribl to match your storage location configuration.
Security Considerations
The template follows Azure security best practices:
- No public blob access: All blob access requires authentication.
- TLS 1.2 enforced: Connections using older TLS versions are rejected.
- HTTPS only: Unencrypted HTTP traffic is not accepted.
- Encryption at rest: All blob data is encrypted with Microsoft-managed keys.
- Scoped permissions: Role assignments are scoped to the storage account, not the subscription or resource group.
- No shared keys or SAS tokens: Access is controlled entirely through Entra ID and RBAC.