AWS · EKS (IRSA)

IRSA (IAM Roles for Service Accounts). Chain: ServiceAccount annotated with a role ARN → EKS projects an OIDC token → the SDK calls STS AssumeRoleWithWebIdentity → temporary credentials → S3. Requires the cluster’s OIDC provider registered in IAM (one-time).

Trust policy — scope :sub to the exact namespace and ServiceAccount Loki runs as: ServiceAccount loki (a deterministic fullnameOverride) in the release namespace (recommended monitoring). Scope it to Loki’s, not another workload’s. For several component ServiceAccounts, use StringLike with a * suffix.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Federated": "arn:aws:iam::<account-id>:oidc-provider/oidc.eks.<region>.amazonaws.com/id/<oidc-id>" },
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": { "StringEquals": {
      "oidc.eks.<region>.amazonaws.com/id/<oidc-id>:aud": "sts.amazonaws.com",
      "oidc.eks.<region>.amazonaws.com/id/<oidc-id>:sub": "system:serviceaccount:monitoring:loki"
    }}
  }]
}

The default assumes the release is installed into monitoring. Under split namespaces, the :sub is system:serviceaccount:loki:loki instead.

A trust policy scoped to the wrong namespace/ServiceAccount is what produces STS: AssumeRoleWithWebIdentity … 403 AccessDenied.

Permissions policy — least-privilege to the single bucket + /loki/*. DeleteObject is required (compactor retention/compaction and the delete-requests store).

{
  "Version": "2012-10-17",
  "Statement": [
    { "Effect": "Allow", "Action": ["s3:ListBucket"], "Resource": ["arn:aws:s3:::<bucket>"],
      "Condition": { "StringLike": { "s3:prefix": ["loki/*"] } } },
    { "Effect": "Allow", "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
      "Resource": ["arn:aws:s3:::<bucket>/loki/*"] }
  ]
}

ServiceAccount — annotate through chart values; the EKS webhook then injects AWS_ROLE_ARN / AWS_WEB_IDENTITY_TOKEN_FILE.

loki:
  serviceAccount:
    annotations:
      eks.amazonaws.com/role-arn: arn:aws:iam::<account-id>:role/<loki-role>

GCP · GKE (Workload Identity)

GKE Workload Identity. Chain: the Loki ServiceAccount is annotated with a Google service account (GSA) → GKE exchanges the pod’s token for that GSA’s credentials → GCS. Requires Workload Identity enabled on the cluster and node pool. Below, <gsa> is the GSA; [<namespace>/loki] is the Kubernetes ServiceAccount (KSA).

Grant the GSA object access on the bucket:

gcloud storage buckets add-iam-policy-binding gs://<bucket> \
  --member="serviceAccount:<gsa>@<project>.iam.gserviceaccount.com" \
  --role="roles/storage.objectAdmin"

Bind the GSA’s IAM policy so the Loki KSA may impersonate it — the KSA must match Loki’s namespace/ServiceAccount:
```
gcloud iam service-accounts add-iam-policy-binding <gsa>@<project>.iam.gserviceaccount.com \
  --role="roles/iam.workloadIdentityUser" \
  --member="serviceAccount:<project>.svc.id.goog[monitoring/loki]"
```
The default assumes the release is installed into monitoring. Under split namespaces, use --member="serviceAccount:<project>.svc.id.goog[loki/loki]" here.
Annotate the ServiceAccount — and set the GCS backend in all four places from Selecting the backend, which the annotation alone does not do:
```
loki:
  serviceAccount:
    annotations:
      iam.gke.io/gcp-service-account: <gsa>@<project>.iam.gserviceaccount.com
```

Azure · AKS (Workload ID)

Microsoft Entra Workload ID. Chain: ServiceAccount annotated with a managed-identity client ID → AKS projects a token → exchanged with Entra for the identity’s credentials → Azure Blob. Requires the OIDC issuer + workload identity enabled on the cluster.

Grant the user-assigned managed identity Storage Blob Data Contributor on the storage account (or container scope).
Create a federated identity credential on that identity — subject must match Loki’s namespace/ServiceAccount:
- issuer = the AKS cluster’s OIDC issuer URL
- subject = system:serviceaccount:monitoring:loki
- audience = api://AzureADTokenExchange
The default assumes the release is installed into monitoring. Under split namespaces, the subject is system:serviceaccount:loki:loki instead.

Annotate the ServiceAccount, label the pods so the webhook injects the token, and set the Azure backend in all four places from Selecting the backend:

loki:
  serviceAccount:
    annotations:
      azure.workload.identity/client-id: <client-id>
  # The workload-identity webhook only acts on pods carrying this label;
  # apply it via the chart's pod-label values for the Loki components.
  podLabels:
    azure.workload.identity/use: "true"