Cloud Storage for Snapshots

Kubeshark can upload and download Traffic Snapshots to cloud object storage, enabling cross-cluster sharing, backup/restore, and long-term retention.

Supported providers: Amazon S3 (s3) and Azure Blob Storage (azblob).

Helm Values

tap:
  snapshots:
    cloud:
      provider: ""      # "s3" or "azblob" (empty = disabled)
      prefix: ""        # key prefix in the bucket/container (e.g. "snapshots/")
      configMaps: []    # names of pre-existing ConfigMaps with cloud config env vars
      secrets: []       # names of pre-existing Secrets with cloud credentials
      s3:
        bucket: ""
        region: ""
        accessKey: ""
        secretKey: ""
        roleArn: ""
        externalId: ""
      azblob:
        storageAccount: ""
        container: ""
        storageKey: ""

• provider selects which cloud backend to use. Leave empty to disable cloud storage.
• configMaps and secrets are lists of names of existing ConfigMap/Secret resources. They are mounted as envFrom on the hub pod, injecting all their keys as environment variables.

Inline Values (Alternative to External ConfigMaps/Secrets)

Instead of creating ConfigMap and Secret resources manually, you can set cloud storage configuration directly in values.yaml or via --set flags. The Helm chart will automatically create the necessary ConfigMap and Secret resources.

Both approaches can be used together — inline values are additive to external configMaps/secrets references.

Inline Helm value → Environment variable mapping:

Amazon S3

Environment Variables

Authentication Methods

Credentials are resolved in this order:

1. Static credentials — If SNAPSHOT_AWS_ACCESS_KEY is set, static credentials are used directly.
2. STS AssumeRole — If SNAPSHOT_AWS_ROLE_ARN is also set, the static (or default) credentials are used to assume the given IAM role. This is useful for cross-account S3 access.
3. AWS default credential chain — When no static credentials are provided, the SDK default chain is used:
   • IRSA (EKS service account token) — recommended for production on EKS
   • EC2 instance profile
   • Standard AWS environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, etc.)
   • Shared credentials file (~/.aws/credentials)

The provider validates bucket access on startup via HeadBucket. If the bucket is inaccessible, the hub will fail to start.

Examples Using Inline Values

Basic S3 (IRSA / default credentials)

When running on EKS with IRSA or another default credential method, only bucket and region are needed:

tap:
  snapshots:
    cloud:
      provider: "s3"
      s3:
        bucket: my-kubeshark-snapshots
        region: us-east-1

The hub pod’s service account must be annotated for IRSA with an IAM role that has S3 access to the bucket.

S3 with Static Credentials

tap:
  snapshots:
    cloud:
      provider: "s3"
      s3:
        bucket: my-kubeshark-snapshots
        region: us-east-1
        accessKey: AKIA...
        secretKey: wJal...

Or equivalently via --set:

helm install kubeshark kubeshark/kubeshark \
  --set tap.snapshots.cloud.provider=s3 \
  --set tap.snapshots.cloud.s3.bucket=my-kubeshark-snapshots \
  --set tap.snapshots.cloud.s3.region=us-east-1 \
  --set tap.snapshots.cloud.s3.accessKey=AKIA... \
  --set tap.snapshots.cloud.s3.secretKey=wJal...

S3 Cross-Account Access via AssumeRole

tap:
  snapshots:
    cloud:
      provider: "s3"
      s3:
        bucket: other-account-bucket
        region: eu-west-1
        roleArn: arn:aws:iam::123456789012:role/KubesharkCrossAccountRole
        externalId: my-external-id   # optional, if required by the trust policy

The hub will first authenticate using its own credentials (IRSA, static, or default chain), then assume the specified role to access the bucket.

S3 with Prefix

Use prefix to namespace snapshot keys within a bucket:

tap:
  snapshots:
    cloud:
      provider: "s3"
      prefix: "production/snapshots"
      s3:
        bucket: my-kubeshark-snapshots
        region: us-east-1

Examples Using External ConfigMaps/Secrets

If you prefer to manage credentials as separate Kubernetes resources (e.g. managed by an external secrets operator), use the configMaps and secrets fields instead of inline values.

IRSA (recommended for EKS)

Create a ConfigMap with bucket configuration:

apiVersion: v1
kind: ConfigMap
metadata:
  name: kubeshark-s3-config
data:
  SNAPSHOT_AWS_BUCKET: my-kubeshark-snapshots
  SNAPSHOT_AWS_REGION: us-east-1

Set Helm values:

tap:
  snapshots:
    cloud:
      provider: "s3"
      configMaps:
        - kubeshark-s3-config

The hub pod’s service account must be annotated for IRSA with an IAM role that has S3 access to the bucket.

Static Credentials

Create a Secret with credentials:

apiVersion: v1
kind: Secret
metadata:
  name: kubeshark-s3-creds
type: Opaque
stringData:
  SNAPSHOT_AWS_ACCESS_KEY: AKIA...
  SNAPSHOT_AWS_SECRET_KEY: wJal...

Create a ConfigMap with bucket configuration:

apiVersion: v1
kind: ConfigMap
metadata:
  name: kubeshark-s3-config
data:
  SNAPSHOT_AWS_BUCKET: my-kubeshark-snapshots
  SNAPSHOT_AWS_REGION: us-east-1

Set Helm values:

tap:
  snapshots:
    cloud:
      provider: "s3"
      configMaps:
        - kubeshark-s3-config
      secrets:
        - kubeshark-s3-creds

Cross-Account Access via AssumeRole

Add the role ARN to your ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: kubeshark-s3-config
data:
  SNAPSHOT_AWS_BUCKET: other-account-bucket
  SNAPSHOT_AWS_REGION: eu-west-1
  SNAPSHOT_AWS_ROLE_ARN: arn:aws:iam::123456789012:role/KubesharkCrossAccountRole
  SNAPSHOT_AWS_EXTERNAL_ID: my-external-id   # optional, if required by the trust policy

The hub will first authenticate using its own credentials (IRSA, static, or default chain), then assume the specified role to access the bucket.

Azure Blob Storage

Environment Variables

Authentication Methods

Credentials are resolved in this order:

1. Shared Key — If SNAPSHOT_AZBLOB_STORAGE_KEY is set, the storage account key is used directly.
2. DefaultAzureCredential — When no storage key is provided, the Azure SDK default credential chain is used:
   • Workload Identity (AKS pod identity) — recommended for production on AKS
   • Managed Identity (system or user-assigned)
   • Azure CLI credentials
   • Environment variables (AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_CLIENT_SECRET)

The provider validates container access on startup via GetProperties. If the container is inaccessible, the hub will fail to start.

Examples Using Inline Values

Workload Identity (recommended for AKS)

When using AKS Workload Identity or another default credential method, only the storage account and container are needed:

tap:
  snapshots:
    cloud:
      provider: "azblob"
      azblob:
        storageAccount: mykubesharksa
        container: snapshots

The hub pod’s service account must be configured for AKS Workload Identity with a managed identity that has the Storage Blob Data Contributor role on the container.

Storage Account Key

tap:
  snapshots:
    cloud:
      provider: "azblob"
      azblob:
        storageAccount: mykubesharksa
        container: snapshots
        storageKey: "base64-encoded-storage-key..."

Examples Using External ConfigMaps/Secrets

Workload Identity (recommended for AKS)

Create a ConfigMap with storage configuration:

apiVersion: v1
kind: ConfigMap
metadata:
  name: kubeshark-azblob-config
data:
  SNAPSHOT_AZBLOB_STORAGE_ACCOUNT: mykubesharksa
  SNAPSHOT_AZBLOB_CONTAINER: snapshots

Set Helm values:

tap:
  snapshots:
    cloud:
      provider: "azblob"
      configMaps:
        - kubeshark-azblob-config

The hub pod’s service account must be configured for AKS Workload Identity with a managed identity that has the Storage Blob Data Contributor role on the container.

Storage Account Key

Create a Secret with the storage key:

apiVersion: v1
kind: Secret
metadata:
  name: kubeshark-azblob-creds
type: Opaque
stringData:
  SNAPSHOT_AZBLOB_STORAGE_KEY: "base64-encoded-storage-key..."

Create a ConfigMap with storage configuration:

apiVersion: v1
kind: ConfigMap
metadata:
  name: kubeshark-azblob-config
data:
  SNAPSHOT_AZBLOB_STORAGE_ACCOUNT: mykubesharksa
  SNAPSHOT_AZBLOB_CONTAINER: snapshots

Set Helm values:

tap:
  snapshots:
    cloud:
      provider: "azblob"
      configMaps:
        - kubeshark-azblob-config
      secrets:
        - kubeshark-azblob-creds

Related Documentation

• Traffic Snapshots — Overview of snapshot capabilities
• Snapshots Dashboard — Creating and managing snapshots
• Dashboard Cloud Storage — Connection status and location filtering
• Helm Configuration Reference — All snapshot Helm values
• Raw Capture Configuration — Local storage and capture settings
• MCP Cloud Storage Tools — Upload/download snapshots via AI assistants