Skip to content

Identity, credentials and secrets

This page documents how Logstrm authenticates to destinations, how operators authenticate to Logstrm, and where credential material can and cannot persist.

Authenticating to Microsoft Sentinel

The Sentinel DCR emitter supports three authentication modes. Two of them require no stored secret.

Managed Identity (Azure VMs and other Azure compute)

emitters:
  - name: sentinel
    type: sentinel_dcr
    dcr:
      auth_mode: managed_identity
      # managed_identity_client_id: "<user-assigned-identity-client-id>"

Flow: the process requests a token from the platform identity endpoint of the host, receives an Entra access token scoped to Azure Monitor ingestion, and calls the Logs Ingestion API on the Data Collection Endpoint. No credential is stored in configuration, in the environment or on disk. Omitting managed_identity_client_id selects the system-assigned identity; setting it selects a user-assigned identity.

Workload Identity (AKS)

emitters:
  - name: sentinel
    type: sentinel_dcr
    dcr:
      auth_mode: workload_identity

Flow: AKS projects a short-lived Kubernetes service-account token into the pod and injects AZURE_CLIENT_ID, AZURE_TENANT_ID and AZURE_FEDERATED_TOKEN_FILE. The emitter exchanges the projected token with Entra through the federated credential bound to that service account, then calls the Logs Ingestion API. No client secret exists at any point.

The emitter uses Azure Identity's ManagedIdentityCredential and WorkloadIdentityCredential explicitly. It does not fall back to developer CLI credentials or a DefaultAzureCredential chain, so an unintended local identity cannot silently be used.

Client secret (legacy)

      auth_mode: client_secret
      tenant_id: "${ENV:AZURE_TENANT_ID}"
      client_id: "${ENV:AZURE_CLIENT_ID}"
      client_secret: "${ENV:AZURE_CLIENT_SECRET}"

This mode uses an Entra application registration and a long-lived secret. Omitting auth_mode preserves this legacy behaviour, so an unspecified mode is a client-secret deployment, not a secretless one. Prefer Managed Identity or Workload Identity; use client secret only where no platform identity is available, and then with explicit rotation ownership and an expiry alert.

Authorisation at the destination

Grant the identity the Monitoring Metrics Publisher role scoped to the specific Data Collection Rule. Do not grant it at subscription or resource-group scope. This permits ingestion into that rule only and grants no read access to the workspace.

Keeping secrets out of stored configuration

The Manager stores the complete configuration YAML of every version in its SQLite database, and retains previous versions to support rollback. Any literal secret written into configuration therefore persists in configuration history, in database backups and in exports, and removing it from the current version does not remove it from earlier ones.

The Data Plane interpolates ${ENV:NAME}, ${NAME} and $NAME when it loads configuration, so the stored document can contain only a placeholder:

  • Write ${ENV:AZURE_CLIENT_SECRET} in configuration; never the literal value.
  • Supply the value to the Data Plane process as an environment variable sourced from a Kubernetes Secret, a secret store CSI driver or an equivalent mechanism, not from a ConfigMap.
  • Keep configuration files out of version control if they contain any literal credential.
  • If a literal secret was ever committed to a configuration version, treat it as disclosed: rotate it, then purge or re-provision the affected history.

Choosing Managed Identity or Workload Identity removes this class of exposure entirely.

Authenticating to the Manager

The Manager supports OIDC authentication with bearer tokens and maps identity-provider claims to three roles.

Role Permitted operations
Viewer Read-only access
Operator Viewer operations, plus rollouts, rollback and DLQ replay
Admin All operations, including node and configuration-version changes

Configuration environment variables: SLIMSTREAM_OIDC_ISSUER, SLIMSTREAM_OIDC_CLIENT_ID, SLIMSTREAM_OIDC_REQUIRED, SLIMSTREAM_OIDC_ROLES_CLAIM, SLIMSTREAM_OIDC_GROUPS_CLAIM and SLIMSTREAM_OIDC_CLIENT_ROLES_CLAIM. See Keycloak authentication and RBAC for a worked example.

Authentication is not enforced by default

If no OIDC issuer is configured, the Manager accepts unauthenticated requests unless SLIMSTREAM_OIDC_REQUIRED=true is set. Any production or internet-reachable deployment must set SLIMSTREAM_OIDC_REQUIRED=true and configure an issuer, so that a missing or misapplied identity configuration fails closed instead of exposing the API.

Data Plane reload token

The Manager pushes configuration to registered Data Plane nodes over an authenticated reload endpoint using a bearer token supplied per node, with SLIMSTREAM_DATAPLANE_AUTH_TOKEN as the default source.

  • The token is stored in the Manager's node record and is therefore present in the Manager database and its backups.
  • The API returns only whether authentication is configured; the token value is write-only and is not returned in node responses.
  • Use a distinct token per node, rotate tokens on operator offboarding or suspected exposure, and keep the reload endpoint reachable only from the Manager.

This token authorises configuration reload. It is unrelated to Azure authentication, and a node using Managed Identity or Workload Identity still needs it.

Standalone Data Plane deployments

The Helm chart requires a reload token. When running the Data Plane directly (without Helm), an empty api.auth_token disables bearer authentication on the reload and configuration-validation endpoints. Set a non-empty token from a secret manager or protected environment source, and keep the API reachable only from trusted operators and the Manager. Do not expose these endpoints with an empty token.

Credential lifecycle checklist

  • Prefer platform identities; where a secret is unavoidable, record its owner, expiry and rotation procedure.
  • Restrict every destination permission to the narrowest scope the destination supports.
  • Rotate the Data Plane reload tokens and any client secrets on a defined schedule and on personnel change.
  • Protect Manager database backups at the same level as live secrets.
  • Keep the release-signing private key offline and backed up; its public counterpart is published for artifact verification.