Setup / Microsoft Azure

Microsoft Azure / Entra setup

Running Logline Enterprise in Azure requires an Azure runtime deployment, customer-managed identities and permissions, dedicated LE control-state PostgreSQL, Azure storage, and identity configuration for protected API callers. Configure Microsoft Entra for the LE API and then follow the sections that apply to the bundled Console, automated API clients, or both.

Use one versioned release bundle

Logline Enterprise for Azure is delivered as one versioned ZIP. The ZIP contains the reference infrastructure, one JSON configuration file, one deployment and verification entry point, the immutable image digest, a generic sample acceptance package, operational queries, and this guidance.

Download the approved Azure bundle

Copy config.example.json to config.json and complete that one file. Supply the PostgreSQL password and access token through the environment-variable names selected in the configuration. Do not place secrets in the configuration file.

./le-azure.mjs preflight --config ./config.json
./le-azure.mjs plan --config ./config.json
./le-azure.mjs deploy --config ./config.json
./le-azure.mjs verify --config ./config.json

The customer does not collect templates, scripts or acceptance files from separate locations. The bundle manifest verifies every included file and pins the released image by digest.

The verifier uses the configured source-storage path and the normal LE API. It does not create a helper service, grant itself roles, or change storage networking. The operator or automation identity must already have the approved network path and write permission required to place the generic sample artifacts.

Azure runtime compatibility baseline

Azure deployment starts from a released Logline Enterprise OCI image by immutable digest. Customers do not build LE from source and do not need Azure DevOps or access to the Logline source repository.

The validated topology uses a long-lived LE control plane in Azure Container Apps, disposable one-run workers in Azure Container Apps Jobs, dedicated LE-owned PostgreSQL control state, private Azure Blob storage for source/invocation/result data, customer-managed identity/RBAC, and the normal protected /api/v1 API. The LE scheduler remains authoritative for pending work and concurrency.

The worker has no PostgreSQL credentials. It reads its immutable invocation and source artifacts from Blob storage and writes result/recovery material back to the configured result container. The control plane reconciles that durable evidence into PostgreSQL.

The Engine execution report remains the canonical execution output. Delivery is optional downstream transport after the canonical report has committed; it is not a second kind of execution result.

Runtime storage should be private by default. If a customer chooses to stage source artifacts from a workstation outside the private network during initial validation, restrict any temporary public access to the exact required source and IP scope, then remove it after staging.

1. Identify the configuration you need

The Console and automation clients are callers of the same protected /api/v1 surface. They do not use separate LE authentication or authorization systems. An API-only deployment does not need to enable or register the Console.

2. Prerequisites

• An Azure subscription and permission to deploy the required Azure resources and role assignments.
• Access to the customer Microsoft Entra tenant.
• Permission to create app registrations and app-role assignments.
• The released Logline Enterprise OCI image digest to deploy.
• The public production URL planned for Logline Enterprise, for example https://logline.example.com/.
• A customer-approved network path for source artifact staging and runtime Blob access.
• Azure CLI for the repeatable command-line configuration and verification paths described below.
• Node.js 22 for the bundled cross-platform deployment and verification entry point.

3. Register the Logline Enterprise API

1. In Microsoft Entra admin center, open Entra ID → App registrations → New registration.
2. Name the application Logline Enterprise API.
3. Select the single-tenant option. Current portal wording may say Only this tenant; Microsoft documentation may describe the same choice as Accounts in this organizational directory only.
4. Leave the redirect URI empty for the API registration.
5. Register the application and record its Application (client) ID and the tenant Directory (tenant) ID.

4. Expose delegated API access when interactive users are required

If human users will access the API through the bundled Console or another delegated client, expose a delegated scope on the API registration:

1. Open the API registration and select Expose an API.
2. Accept the proposed Application ID URI api://<API-CLIENT-ID>.
3. Add a scope named access_as_user.
4. Allow Admins and users to consent, provide customer-appropriate display/description text, and enable the scope.

The resulting delegated permission is:

api://<API-CLIENT-ID>/access_as_user

A deployment that uses only non-interactive workload clients does not need this delegated scope until delegated human access is introduced.

5. Require v2 access tokens

LE validates Microsoft Entra v2 access tokens. The resource application must explicitly request token version 2; using a v2 authorization endpoint alone does not change the resource access-token format.

The portal Manifest entry is not visible in every current Entra UI. The Azure CLI path is reliable:

az login

az ad app update \
  --id "<API-CLIENT-ID>" \
  --requested-access-token-version 2

az ad app show \
  --id "<API-CLIENT-ID>" \
  --query "api.requestedAccessTokenVersion" \
  -o tsv

The verification command must print 2.

6. Create the LE application roles

On the Logline Enterprise API registration, create app roles that match the customer authorization policy. The shipped example policy uses:

Customers may use different role/group/scope vocabulary, but the LE authorization policy must map verified claims to exact LE operation identities.

7. Assign human users when interactive access is required

1. Open Entra ID → Enterprise applications → Logline Enterprise API.
2. Select Users and groups → Add user/group.
3. Select the user and the appropriate LE role, such as Logline Enterprise Reader.
4. Complete the assignment and confirm the user appears in the list.

Some Entra licensing levels restrict group-based assignment. Individual user assignment is sufficient for initial verification.

8. Register the Logline Enterprise Console when it will be used

1. Create a second single-tenant app registration named Logline Enterprise Console.
2. Configure redirect URIs using the Single-page application (SPA) platform type.
3. For each deployed Console, add the exact HTTPS URL ending in /console/, for example https://logline.example.com/console/.
4. For local verification, add http://localhost:8080/console/ if that is the local Console URL. Use the same host spelling in the browser; localhost and 127.0.0.1 are different redirect URIs.
5. Record the Console Application (client) ID.

9. Give the Console delegated permission to the LE API

1. Open the Logline Enterprise Console app registration.
2. Select API permissions → Add a permission.
3. Select the Logline Enterprise API. Depending on portal ownership/filtering, it may appear under My APIs or under the tenant-application list such as Applications allowed in this tenant.
4. Select Delegated permissions and add access_as_user.

The Microsoft Graph User.Read permission is not required by Logline Enterprise itself. If it exists because of another application need, it is independent of the LE API permission.

10. Configure automation and API clients when required

Non-interactive callers such as CI/CD systems and customer services use the same LE API but do not use the Console registration or browser sign-in flow.

• Use a separate customer-controlled workload application or service principal for each automation trust boundary.
• Assign an application role such as Customer.Logline.Automation, or a customer-defined equivalent mapped by the LE authorization policy.
• Use the organization's approved workload credential or federation mechanism to obtain an access token for the LE API audience.
• Do not reuse the Console client identity for service-to-service access.

The shipped authorization model supports application callers through verified role claims.

11. Configure Logline Enterprise authentication and authorization

Set the authenticated runtime configuration with values from the API registration and, when the Console is used, the Console registration:

LOGLINE_ENTERPRISE_AUTHENTICATION_MODE=authenticated
LOGLINE_ENTERPRISE_ENTRA_TENANT_ID=<TENANT-ID>
LOGLINE_ENTERPRISE_ENTRA_AUDIENCE=<API-CLIENT-ID>
LOGLINE_ENTERPRISE_ENTRA_CONSOLE_CLIENT_ID=<CONSOLE-CLIENT-ID>
LOGLINE_ENTERPRISE_ENTRA_CONSOLE_SCOPE=api://<API-CLIENT-ID>/access_as_user
LOGLINE_ENTERPRISE_AUTHORIZATION_POLICY_PATH=<POLICY-PATH>

The Console client ID and scope are required only when the bundled Console is enabled for interactive users.

The tenant ID, client IDs, role names and scope identifiers are not secrets. Passwords, bearer tokens, refresh tokens, private keys and client secrets must not be placed in the authorization policy or normal logs.

The reference allow-only policy is distributed as:

deploy/enterprise/security/customer-authorization-policy.example.json

Review it and provide a customer-owned deployment policy rather than treating the example role names as mandatory.

12. Enable or disable the bundled Console

The standard Logline Enterprise image contains the browser Console at:

/opt/logline/enterprise/console

To serve it from the same control plane that serves the API, set:

LOGLINE_ENTERPRISE_CONSOLE_ROOT=/opt/logline/enterprise/console

The Console is then available at /console/ on that deployment. For example, a local Docker deployment may use http://localhost:8080/console/ while an Azure deployment may use https://logline.example.com/console/. Both may authenticate the same Entra user through the same Console SPA registration when both redirect URIs are registered.

For an API-only deployment, omit LOGLINE_ENTERPRISE_CONSOLE_ROOT and omit the Console client ID/scope configuration. The protected /api/v1 API remains fully usable by authorized clients.

13. Configure the Azure-native runtime

The control plane selects the Azure Container Apps Jobs worker runtime and the configured Blob storage profiles through deployment environment values. A typical Azure deployment provides:

LOGLINE_ENTERPRISE_WORKER_RUNTIME=azure-container-apps-job
LOGLINE_ENTERPRISE_AZURE_SUBSCRIPTION_ID=<SUBSCRIPTION-ID>
LOGLINE_ENTERPRISE_AZURE_RESOURCE_GROUP_NAME=<RESOURCE-GROUP>
LOGLINE_ENTERPRISE_AZURE_WORKER_JOB_NAME=<WORKER-JOB-NAME>
LOGLINE_ENTERPRISE_AZURE_WORKER_CONTAINER_NAME=<WORKER-CONTAINER-NAME>
LOGLINE_ENTERPRISE_AZURE_INVOCATION_CONTAINER_URL=https://<ACCOUNT>.blob.core.windows.net/<INVOCATIONS>
LOGLINE_ENTERPRISE_AZURE_INPUT_STORAGE_PROFILES=[{"id":"azure-sources","containerUrl":"https://<ACCOUNT>.blob.core.windows.net/<SOURCES>"}]
LOGLINE_ENTERPRISE_AZURE_RESULT_STORAGE_PROFILE_ID=azure-results
LOGLINE_ENTERPRISE_AZURE_RESULT_CONTAINER_URL=https://<ACCOUNT>.blob.core.windows.net/<RESULTS>
LOGLINE_ENTERPRISE_AZURE_MANAGED_IDENTITY_CLIENT_ID=<CONTROL-PLANE-MANAGED-IDENTITY-CLIENT-ID>

Configure the LE-owned PostgreSQL connection separately using the standard LE database settings. The disposable Azure worker Job must not receive PostgreSQL credentials.

Pin both the control-plane Container App and the worker Job to the same released immutable LE image digest. This avoids a control-plane/worker version split during execution.

14. Configure Azure identities, storage and RBAC

The validated deployment uses separate customer-managed identities for control-plane runtime access, worker runtime access and image pull. Keep their permissions scoped to the resources each role actually needs.

Keep Blob storage private for normal operation. Source, invocation and result/recovery containers are distinct trust surfaces and should be scoped independently where the customer's security model requires it.

15. Verify authenticated API access

1. Open /api/v1 and confirm authenticationMode is authenticated.
2. Use an authenticated caller with an assigned LE role to invoke an operation that role is allowed to perform.
3. Confirm LE security-audit output records the caller's stable subject, principal kind, issuer and an allowed authorization decision. Verify tenant, client, role and scope configuration through the controlled Entra/token-validation workflow rather than copying full claims into operational logs.
4. Invoke an operation outside the caller's role and confirm LE returns HTTP 403 AUTHORIZATION_DENIED.

16. Verify Console sign-in when the Console is used

1. Open /api/v1 and confirm the browser authentication block contains the expected Console client ID and delegated scope.
2. Open /console/ using the exact host registered as an SPA redirect URI.
3. Select Sign in and authenticate through the customer Microsoft Entra tenant.
4. After redirect back to the Console, confirm the Console reports Authenticated and authorized data such as Runs and Delivery status loads.
5. If the same user also has a local Console open, confirm both deployments can authenticate against the same customer Entra tenant as expected.
6. Confirm LE security-audit output records the expected stable principal identity and authorization decision. Verify the tenant, client ID, delegated scope and assigned app role through the controlled Entra/token-validation workflow; LE does not copy full token-derived attributes into operational logs.

17. Verify Azure-native execution

1. Register or select the required Program Bundle and Run Profile through the normal LE API.
2. Submit the Source Package Manifest through POST /api/v1/runs. Azure storage is a deployment binding; admission still uses the normal LE contract.
3. Confirm Azure creates one execution of the configured Container Apps Job.
4. Confirm the Run reaches COMPLETED, SUCCEEDED and COMMITTED.
5. Retrieve /api/v1/runs/<RUN-ID>/report and verify the canonical Engine execution report.
6. Retrieve /api/v1/runs/<RUN-ID>/result and verify the Result Contract, provenance, entitlement decision and persisted report descriptor.

Successful Azure Job status alone is not sufficient acceptance. LE acceptance requires the Run to reconcile to terminal state and the canonical report/result to be retrievable through the protected API.

18. Configure and search operational logs

Logline Enterprise emits provider-neutral newline-delimited JSON to standard output/error. The Azure reference IaC configures the Container Apps environment with the Azure Monitor destination and routes ContainerAppConsoleLogs plus ContainerAppSystemLogs to a dedicated Log Analytics workspace. This Azure collection binding does not change the LE event schema and is not required by non-Azure deployments.

Set the workspace default interactive retention through the reference-IaC parameter:

operationalLogRetentionDays=30

The supported reference range is 30–730 days. Select the value through the customer's incident-response, privacy, regulatory and cost policy; do not treat the reference default as a universal retention policy.

Retained operator queries are supplied under:

deploy/enterprise/azure/queries/errors.kql
deploy/enterprise/azure/queries/worker-jobs.kql
deploy/enterprise/azure/queries/run-correlation.kql
deploy/enterprise/azure/queries/request-correlation.kql
deploy/enterprise/azure/queries/readiness.kql

Use run-correlation.kql with an exact Run ID to follow scheduler, worker, recovery and delivery activity. Use request-correlation.kql with the X-Request-Id returned by the LE API. Worker records expose stable BOOTSTRAP, EXECUTION and FINALIZATION stages plus worker/attempt identity and failure diagnostic codes.

A query may be run from the repository/release support tree with Azure CLI:

WORKSPACE_ID="$(az monitor log-analytics workspace show \
  --resource-group "<RESOURCE-GROUP>" \
  --workspace-name "<WORKSPACE-NAME>" \
  --query customerId \
  --output tsv)"

az monitor log-analytics query \
  --workspace "$WORKSPACE_ID" \
  --analytics-query "$(cat deploy/enterprise/azure/queries/errors.kql)" \
  --output table

Azure ingestion is asynchronous and may take several minutes. Use Container Apps log streaming for immediate transient inspection, then use retained queries for correlation and incident evidence.

19. Troubleshooting

20. Security rules

• Use HTTPS for production API and Console endpoints.
• Do not place client secrets in the browser Console.
• Do not log or persist bearer-token contents in operational evidence.
• Keep the customer authorization policy allow-only and default-deny.
• Use separate managed identities and least-privilege RBAC for control plane, worker runtime and image pull.
• Keep runtime Blob storage private by default.
• Restrict Log Analytics access because operational identities and sanitized error context may still be customer-sensitive.
• Keep identity-provider authentication, LE operation authorization, LE entitlement and infrastructure permissions as separate decisions.

Microsoft references

• Expose scopes in a protected web API
• OAuth 2.0 authorization code flow and SPA redirect URIs
• Add app roles and receive them in a token
• Assign users and groups to an application
• Microsoft Graph apiApplication and requestedAccessTokenVersion
• Azure Container Apps log storage and monitoring options
• Monitor Azure Container Apps logs with Log Analytics
• Configure Azure Monitor Logs retention