Blob Providers

Connect your organization's bucket once, and Archestra features that write files send them there. A scheduled cost export picks the provider by name and never sees its credentials, so nobody pastes cloud keys into each feature. On AWS, Google Cloud, and Azure, Archestra can sign in as its own pod identity, so there is no key to store or rotate.

A blob provider writes to one of three stores:

Add a Blob Provider

Add one provider per bucket or container, and every feature that writes files can pick it. Viewing blob providers requires organizationSettings:read. Adding, changing, testing, or deleting one requires organizationSettings:update.

1. Grant access to the identity Archestra signs in as. See Amazon S3, Google Cloud Storage, or Azure Blob Storage.
2. Go to Settings → Blob Providers and click Add blob provider.
3. Pick the Provider and enter a Name, such as finops-bucket. Features list the provider by this name, so it is unique in the organization.
4. Enter where files go:
   • Amazon S3: the Bucket, without s3://, and its Region, such as eu-west-1.
   • Google Cloud Storage: the Bucket, without gs://.
   • Azure Blob Storage: the Storage account and the Container.
5. Pick the Authentication method and fill in its fields.
6. Optionally, open Advanced and set a Key prefix: a folder that every object Archestra writes goes under. The custom endpoint, path-style addressing, external ID, and session token are there too.
7. Click Test and add.

Archestra writes and deletes a small test object under the key prefix before it saves. When the test works, the dialog closes and the provider shows in the table. When it fails:

• The dialog shows the store's error. Fix the setting, or click Save anyway to keep the provider as it is. See Fix a Failed Connection Test.
• Through the API, the request fails with a 400 and the internal_code blob_provider_connection_failed. Send skipConnectionTest: true to save anyway.

What to know:

• Secrets go to Archestra's secret storage and are never shown again. When you edit a provider, leave a secret field empty to keep the stored value.
• A provider's type cannot change after it is created. Add a new provider instead.
• A provider that a cost export uses cannot be deleted. Delete the export, or move it to another provider, first.

Test a Provider

Test a provider again after you rotate a key, change an access policy, or see an export fail. The test writes and deletes the same small object as a save.

• One provider: click Test connection on its row.
• Several: select their rows and click Test connection above the table.

A check next to the name means the write worked. A cross means it failed: hover over it to read the error. The Signs in as column shows the identity each provider uses, and flags a provider whose stored secret is missing.

Set Up Amazon S3

Archestra signs in to S3 in one of three ways. On AWS, prefer the pod's own identity: there is no key to store or rotate.

Use the Pod's IAM Role

With the default chain, Archestra uses the same AWS identity as the rest of the process: environment variables, an IRSA or EKS Pod Identity role, an ECS task role, an EC2 instance profile, or shared config files. On EKS with IRSA, annotate the Archestra service account with the role:

archestra:
  orchestrator:
    kubernetes:
      serviceAccount:
        annotations:
          eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/archestra-blob-writer

The web and worker pods share this service account. The connection test runs on a web pod and scheduled exports run on a worker pod, so both get the role.

Assume a Role in Another Account

Archestra assumes the role through STS, signing in as the default chain's identity, or as the stored access key when you add one. Allow that identity in the role's trust policy, and require the external ID you enter under Advanced:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:role/archestra-platform" },
      "Action": "sts:AssumeRole",
      "Condition": { "StringEquals": { "sts:ExternalId": "archestra-cost-exports" } }
    }
  ]
}

The source identity also needs sts:AssumeRole on the role ARN in its own permissions. Attach the bucket policy to the assumed role, not to the source.

Grant Bucket Access

The identity needs to write objects under the provider's key prefix, and nothing else. Scheduled exports use s3:PutObject. The connection test also deletes its test object, so it needs s3:DeleteObject:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:PutObject", "s3:DeleteObject"],
      "Resource": "arn:aws:s3:::example-finops-bucket/archestra/*"
    }
  ]
}

Replace example-finops-bucket with your bucket and archestra with the provider's key prefix. With no key prefix, use arn:aws:s3:::example-finops-bucket/*.

Use an S3-Compatible Store

Under Advanced, set Custom endpoint to the store's S3 API URL and turn on Path-style addressing, which most S3-compatible stores require. Sign in with an access key from the store.

Region is still required. Use the value the store documents for S3 clients. The endpoint must start with http:// or https://, and Archestra's pods must reach it over the network.

Set Up Google Cloud Storage

Archestra writes through the Cloud Storage JSON API, so it needs no HMAC key or interoperability setting. It signs in one of two ways:

• Application Default Credentials: the server's own Google identity, from GKE Workload Identity, an attached service account, or GOOGLE_APPLICATION_CREDENTIALS. Nothing is stored. Prefer it on Google Cloud.
• Service account key: a service account's JSON key, pasted into the provider. Use it when Archestra runs outside Google Cloud.

On GKE, annotate the Archestra service account with the Google service account to sign in as. GKE with Workload Identity covers the binding between the two accounts.

archestra:
  orchestrator:
    kubernetes:
      serviceAccount:
        annotations:
          iam.gke.io/gcp-service-account: archestra-exports@example-project.iam.gserviceaccount.com

Then grant that service account object access on the bucket:

gcloud storage buckets add-iam-policy-binding gs://example-finops-bucket \
  --member="serviceAccount:archestra-exports@example-project.iam.gserviceaccount.com" \
  --role="roles/storage.objectUser"

What to know:

• The identity needs storage.objects.create and storage.objects.delete. roles/storage.objectUser holds both. For less access, grant a custom role with only those two.
• Cloud Storage also checks storage.objects.delete when a write replaces a file, so an export that rewrites a period fails without it.

Set Up Azure Blob Storage

Archestra writes into one container of a storage account. It signs in one of four ways:

For a sovereign cloud or Azurite, set Custom endpoint under Advanced, such as https://finopsexports.blob.core.usgovcloudapi.net.

Grant Container Access

The Azure default credential and a service principal need the Storage Blob Data Contributor role on the container or the storage account:

az role assignment create \
  --assignee "<client-id>" \
  --role "Storage Blob Data Contributor" \
  --scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/finopsexports/blobServices/default/containers/cost-exports"

Use the client ID of the managed identity or the app registration. On AKS, set up Workload Identity as in On AKS: the service account annotation and the pod label are all a blob provider needs.

A new role assignment can take a few minutes to apply. A test right after it can fail with AuthorizationPermissionMismatch.

Create a SAS Token

A SAS token limits Archestra to one container until the token expires. Issue it with create, write, and delete permissions (cwd):

az storage container generate-sas \
  --account-name finopsexports \
  --name cost-exports \
  --permissions cwd \
  --expiry 2027-11-10T00:00Z \
  --https-only \
  --output tsv

Paste the output into SAS token, with or without the leading ?. When the token expires, tests and exports fail with AuthenticationFailed, so edit the provider and paste a new token before then.

Fix a Failed Connection Test

A failed test names what went wrong and, where the error makes it clear, what to change. Find the message below.

could not reach the storage endpoint, with any provider, means the network failed: check the endpoint, DNS, and egress rules.

What to know:

• A failed scheduled export shows the same message on its row in Costs > Exports.
• A test runs on a web pod and exports run on a worker pod. When tests pass and exports fail, check that the worker pods sign in as the same identity.