Export audit logs to your own storage

​

Overview

​

Before You Begin

• A bucket you own. AWS S3, Google Cloud Storage (via the S3 interop endpoint), MinIO, and SeaweedFS are all supported.
• Either:
  • An IAM role (AWS S3 only) whose trust policy permits Barndoor to assume it, or
  • An access key pair with s3:PutObject permission on your bucket

• An Azure storage account and a container that already exists. Barndoor writes into the container but doesn’t create it.
• Either:
  • The storage account’s access key, or
  • The ability to mint a container-scoped SAS (shared access signature) with Read, List, Write, and Create permissions

​

Authentication Methods

​

S3-compatible destinations

​

Azure Blob Storage destinations

​

Configure with IAM Role Authentication

​

Step 1: Start the configuration in Barndoor

1. Sign in to your Barndoor portal and navigate to Audit Log Export in the side nav.
2. For the destination provider, choose Amazon S3 / S3-compatible.
3. Fill in the connection details:
   • Endpoint URL — https://s3.<region>.amazonaws.com (e.g. https://s3.us-east-1.amazonaws.com)
   • Bucket Name — the bucket events will land in
   • Region — matching AWS region (e.g. us-east-1)
   • Path Prefix (optional) — key prefix for every object. Defaults to audit-events/.
4. Under Authentication, choose IAM role (AWS only).

• Barndoor principal — the IAM role ARN that Barndoor will use to assume your role
• External ID — a random 64-character string unique to your destination. This is a shared secret used as the sts:ExternalId to defend against the confused-deputy problem.

​

Step 2: Create the IAM role in your AWS account

1. Trusted entity type: Custom trust policy. Paste the snippet below, substituting <barndoor-principal> and <external-id> with the values from the Barndoor UI:
   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": { "AWS": "<barndoor-principal>" },
         "Action": "sts:AssumeRole",
         "Condition": {
           "StringEquals": { "sts:ExternalId": "<external-id>" }
         }
       }
     ]
   }
   
   The Barndoor UI provides a copy-pasteable version of this exact policy with the values filled in — click the copy button next to “Trust policy JSON”.
2. Permissions: skip the AWS managed-policies screen — we’ll add an inline policy after the role is created.
3. Name: any name you like, e.g. barndoor-audit-export. Copy the role ARN once it’s created.
4. On the role’s detail page, Add permissions → Create inline policy. Paste the snippet below, replacing <your-bucket-name>:
   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "s3:PutObject",
           "s3:ListBucket",
           "s3:GetBucketLocation"
         ],
         "Resource": [
           "arn:aws:s3:::<your-bucket-name>",
           "arn:aws:s3:::<your-bucket-name>/*"
         ]
       }
     ]
   }
   
   ListBucket and GetBucketLocation are used by Barndoor’s “Check connection” health check. PutObject is what audit-consumer uses at runtime to upload event files.

​

Step 3: Paste the role ARN back into Barndoor

1. Paste the role’s ARN into IAM Role ARN.
2. Pick the event types to include (see Selecting event types below) or leave the default (all types).
3. Click Save Configuration. The destination saves in a paused state so you can verify the connection before any events flow.
4. Click Check Connection. Barndoor assumes your role, performs a HeadBucket against your destination, and reports the result.

​

Step 4: Start the stream

​

Configure with Access Keys

​

Step 1: Create the IAM user / equivalent

1. IAM → Users → Create user, name it (e.g. barndoor-audit-export).
2. Skip the AWS Management Console access option — this user only needs programmatic access.
3. Once the user is created, Security credentials → Create access key → Application running outside AWS (or equivalent). Save the access key and secret.
4. Add inline policy with the same S3 permissions snippet from Step 2 of the IAM-role flow.

​

Step 2: Paste the keys into Barndoor

1. Navigate to Audit Log Export, choose Amazon S3 / S3-compatible as the destination provider, and fill in Endpoint URL, Bucket Name, Region, Path Prefix.
2. Under Authentication, choose Access keys.
3. Paste the Access Key ID and Secret Access Key.
4. Click Save Configuration, then Check Connection, then Start — same flow as the IAM-role path.

​

Configure with Azure Blob Storage

​

Step 1: Get a credential from Azure

1. In the Azure portal, open the storage account that holds your container.
2. Go to Security + networking → Access keys.
3. Click Show next to key1 (or key2) and copy the Key value. Barndoor wants that key on its own — not the full connection string.

1. In the Azure portal, open the storage account and go to Data storage → Containers.
2. Click the container you’re exporting to, then Shared access tokens in its menu.
3. Under Permissions, select at least Read, List, Write, and Create.
4. Set an expiry you’re comfortable rotating on, then click Generate SAS token and URL.
5. Copy the Blob SAS token — the query string, not the full blob URL.

az storage container generate-sas \
  --account-name <storage-account> \
  --name <container> \
  --permissions rlwc \
  --expiry 2027-01-01T00:00:00Z \
  --output tsv

​

Step 2: Fill in the destination in Barndoor

1. Sign in to your Barndoor portal and navigate to Audit Log Export in the side nav.
2. For the destination provider, choose Azure Blob Storage.
3. Fill in the connection details:
   • Blob Service URL — the blob service root for your account, https://<storage-account>.blob.core.windows.net. It must be https, and it must not include the container — that’s a separate field.
   • Container — the name of the existing container events will land in.
   • Path Prefix (optional) — blob-name prefix for every upload. Defaults to audit-events/.
4. Under Authentication, choose Account key or SAS token and paste the value you copied into the credential field.
5. Pick the event types to include (see Selecting event types below) or leave the default (all types).
6. Click Save Configuration. The destination saves in a paused state so you can verify the connection before any events flow.

​

Step 3: Verify and start the stream

1. Click Check Connection. Barndoor reads the container’s properties with the credential you supplied and reports the result. The credential needs at least Read, List, and Write on the container — the health check reads, and delivery writes.
2. If you see Connection Healthy, click Start in the Current Status card. The badge flips to Streaming Active and new audit events begin flowing to your container within ~30 seconds.

​

Rotating a SAS token

1. Mint a fresh token with the same permissions.
2. Open the destination, paste the new token into the SAS token field, and save.

​

Selecting Event Types

• Policy — AUTHORIZATION, POLICY_DECISION
• Identity — AUTHENTICATION, SESSION_CREATED, SESSION_TERMINATED, SESSION_UPDATED, TOKEN_EXCHANGE
• AI Agent & Data — AI_REQUEST, DATA_ACCESS, TOOL_CALL
• Platform & Activity — AUDIT, REQUEST_COMPLETED, REQUEST_FORWARDED, REQUEST_RECEIVED, SYSTEM, USER_ACTION

​

Object Format and Partitioning

<bucket-or-container>/<path-prefix>/dt=YYYY-MM-DD/hour=HH/archive_HHMMSS.<seq>.<batch-id>.json.gz

my-bucket/audit-events/dt=2026-05-15/hour=07/archive_073825.0000.96568337-7073-4ab6-b431-c7d3d7251877.json.gz

​

Pausing and Resuming

​

Troubleshooting

​

”Connection Unhealthy” after Check Connection (S3)

• AccessDenied on HeadBucket — the IAM role or user is missing s3:ListBucket and s3:GetBucketLocation on the bucket. Re-check the inline permissions policy.
• not authorized to perform: sts:AssumeRole — the trust policy’s Principal doesn’t match Barndoor’s principal ARN exactly. Re-copy from the Barndoor UI.
• Invalid ExternalId — the sts:ExternalId in your trust policy doesn’t match what Barndoor expects. Open the destination in the UI and re-copy the External ID; the value is stable per destination.
• NoSuchBucket — bucket name typo, or the bucket is in a different region than what you entered.

​

”Last delivery issue: … AccessDenied” but Check Connection passes

​

”Connection Unhealthy” or delivery errors on an Azure destination

• AuthorizationPermissionMismatch or AuthenticationFailed — the credential needs at least Read, List, and Write on the container (a container SAS also needs Create). Re-mint the signature with the missing permissions, or check that you pasted the account key rather than the connection string.
• AuthenticationFailed with a signature-expiry message — the SAS token has passed its expiry. Mint a new one and save it on the destination; see Rotating a SAS token.
• ContainerNotFound — container name typo, or the container doesn’t exist. Barndoor writes into an existing container and never creates one.
• ResourceNotFound or connection errors on the endpoint — the Blob Service URL must be the account root (https://<storage-account>.blob.core.windows.net) over https, with no container path appended. Move the container name into the Container field.

​

No objects appearing in the bucket or container even though the stream is “Active”

​

Switching between IAM-role and access-keys mode

​

Switching between S3 and Azure Blob Storage

​

Frequently Asked Questions