Custom Storage

Custom Storage lets you connect your own object storage to Sysdig Secure and use it as the destination for the data that Secure produces. Instead of a single, shared bucket, you can configure multiple storages and pick which one each feature uses:

• Captures
• Response Actions (File Acquire, Kubernetes logs, Cloud logs)
• Rapid Response session logs

Each storage is a bucket on AWS S3 or an S3-compatible provider (such as MinIO or Google Cloud Storage). Sysdig validates the connection when you add a storage and tracks the outcome of every operation, so you can see at a glance whether a bucket is healthy and review a history of failures.

Prerequisites

• Administrator permissions in Sysdig Secure. Only administrators can add, modify, or delete a storage.
• An existing S3 or S3-compatible bucket that Sysdig can write to, read from, and list.
• Credentials or a role that grant Sysdig access to the bucket (see the connection methods below).

Add a Storage

1. In Sysdig Secure, go to Integrations > Data Sources > Storage.

2. Click Add Storage and choose a connection method:

   • AWS S3 with AssumeRole — connect an AWS S3 bucket using role delegation (recommended).
   • AWS S3 with Access Key — connect an AWS S3 bucket using an access key and secret.
   • S3 Compatible — connect an S3-compatible provider (MinIO, Google Cloud Storage, and others) using an endpoint, region, and credentials.

3. Fill in the fields for the selected method (see below). The following fields are common to every method:

   • Bucket Name (required): the exact name of your bucket.
   • Root Path (optional): a path within the bucket used as the root for stored objects. Defaults to /.

4. Click Test integration. Sysdig verifies that the bucket exists and that the provided credentials can list, read, and write objects.

   When the test succeeds, you see Your integration was tested successfully. If it fails, review the credentials and permissions and test again.

5. Click Save.

The new storage appears in the Storage table and becomes selectable in the features that use it.

AWS S3 with AssumeRole

Sysdig accesses your bucket by assuming an IAM role in your AWS account. This is the recommended method because it does not require you to create or share long-lived access keys.

Provide:

• Principal (required): the ARN of the IAM role Sysdig should assume, for example arn:aws:iam::<AWS-account-ID>:role/<role-name>.

When you select this method, Sysdig displays a trust relationship policy that you must attach to your role. It authorizes the Sysdig trusted identity to assume the role and includes your account’s External ID. Copy the values shown in the UI — they are specific to your Sysdig account.

The role must also grant permissions to operate on the bucket. Attach the policy provided in the UI.

AWS S3 with Access Key

Sysdig accesses your bucket using an AWS access key and secret.

Provide the following credentials:

• Access Key (required): the AWS access key ID.
• Access Secret (required): the AWS secret access key.

The associated IAM user must also have permissions to operate on the bucket. Attach the policy provided in the UI.

S3 Compatible

Use this method for S3-compatible providers such as MinIO and Google Cloud Storage. The fields are:

• Access Key and Access Secret (required): the credentials Sysdig uses to authenticate with the provider.
• Endpoint (required): the HTTPS URL of the provider’s S3 API. TLS is required, so it must start with https://.
• Region (required): used only to sign requests (AWS Signature Version 4), not to locate the bucket. Provide a value even when the provider has no meaningful region.
• Request Style (required): how Sysdig addresses the bucket — virtual-hosted-style (https://bucket.endpoint), used by default, or path-style (https://endpoint/bucket). Read more about this in the AWS documentation.

Ensure the credentials can list, read, and write the objects in the bucket.

Configure MinIO

• Access Key / Access Secret: an access key created for the target MinIO user or service account.
• Endpoint: your MinIO server URL, for example https://minio.example.com.
• Region: the region configured on the server (MINIO_SITE_REGION, or MINIO_REGION on older versions). Use us-east-1 if none is set.
• Request Style: use path-style, which MinIO supports out of the box. Use virtual-hosted-style only if your MinIO server resolves bucket subdomains — that is, a server domain is set (MINIO_DOMAIN, for example MINIO_DOMAIN=minio.example.com) with a matching wildcard DNS record (for example *.minio.example.com). See the MinIO documentation.

Configure Google Cloud Storage

• Access Key / Access Secret: the access ID and secret of an HMAC key.
• Endpoint: https://storage.googleapis.com.
• Region: auto. Google’s S3-compatible (XML API) layer serves any bucket regardless of location, so a fixed signing region is used. See Cloud Storage interoperability.
• Request Style: use virtual-hosted-style.

Review the Configured Storages

The Storage tab lists every configured storage. For each one, the table shows:

From this table you can modify or delete a storage, and — when a storage is in the Error state — open its failure history.

Modify a Storage

1. Go to the Storage tab and open the storage you want to change.
2. Update the fields as needed.
3. Click Test integration to re-validate the connection, then Save.

Delete a Storage

1. Go to the Storage tab.
2. Select the trash icon for the storage you want to remove and confirm.

Deleting a storage in use by a feature might result in errors. Update the affected features to use a different storage first.

Monitor Storage Health

A storage moves to the Error state when Sysdig cannot complete an operation against the bucket. When this happens, a Failure History icon appears next to the storage; select it to open the Failure History dialog.

The dialog lists the most recent failed operations against the bucket. Each entry shows time and status.

Failures are recorded automatically whenever Sysdig cannot write to, read from, or list the bucket — for example when uploading a capture or a log, or when listing existing objects. Use the timestamps to correlate a failure with a recent change (such as a credential rotation) and narrow down the cause. Common causes include:

• Expired, rotated, or revoked credentials.
• Insufficient permissions on the bucket, or on the assumed role for AssumeRole configurations.
• A bucket that was deleted, renamed, or moved to a different region.
• An unreachable or misconfigured endpoint (S3-compatible providers).
• A region or addressing-style mismatch (S3-compatible providers).

After correcting the underlying issue, modify the storage and run Test integration again to confirm the connection is healthy. The storage returns to Active once operations succeed.