Skip to main content
The csiSecret configuration enables secret management via the Secrets Store CSI Driver for clusters where External Secrets Operator cannot be installed.
Mutually Exclusive with External Secrets: The CSI Secret Store mode (csiSecret.enabled: true) and External Secrets Operator mode (externalSecret.enabled: true) cannot be enabled simultaneously. Choose one secret management strategy for your deployment.

Overview

The CSI Secret Store mode provides an alternative to External Secrets Operator for clusters with the following requirements:
  • Secrets Store CSI Driver is already installed
  • External Secrets Operator cannot be installed due to cluster policies
  • AWS Secrets Manager is used as the secret backend
How It Works:
  1. A SecretProviderClass resource defines which secrets to fetch from AWS Secrets Manager
  2. A csi-syncer deployment mounts the CSI volume to materialize Kubernetes Secrets
  3. Workloads consume the standard crewai-platform-secrets Secret (identical to inline or ESO modes)
Prerequisites:

Basic Configuration

boolean
default:"false"
Enable Secrets Store CSI Driver mode for secret management.When to Use:
  • External Secrets Operator cannot be installed in your cluster
  • Secrets Store CSI Driver is already available
  • AWS Secrets Manager is your secret backend
Validation:
  • Fails if externalSecret.enabled is also true (mutually exclusive)
  • Fails if csiSecret.provider is not "aws" (only AWS is currently supported)
  • Fails if web.tls.autoGenerate is true (auto-generated TLS not supported in CSI mode)
Example:
string
default:"aws"
Secret store provider type.Valid Values:
  • "aws" - AWS Secrets Manager (only supported provider)
Note: The chart validates this value and fails template rendering if set to anything other than "aws". Support for additional providers may be added in future releases.

Secret Paths

string
required
AWS Secrets Manager secret name or ARN containing platform secrets.Required: Yes (when csiSecret.enabled: true)Format: Secret name (e.g., "crewai/platform/prod") or full ARNSecret Structure: The secret must be a JSON object with flat string key-value pairs. Required keys depend on your configuration (see Backend Key Reference).Example Secret Content:
string
required
AWS Secrets Manager secret name or ARN containing the database password.Required: Yes (when csiSecret.enabled: true)Format: Secret name or full ARNSecret Structure: JSON object with a password property:
Separate Secret: Database credentials are kept in a separate secret for easier credential rotation without touching platform secrets.
string
default:""
AWS Secrets Manager secret name or ARN containing OAuth service secrets.Default Behavior: When empty, defaults to csiSecret.secretPath (OAuth secrets stored in the same secret as platform secrets).When to Use a Separate Secret:
  • Different rotation schedules for OAuth vs platform secrets
  • Different IAM permission boundaries
  • Organizational secret separation requirements
Secret Structure: JSON object with OAuth-specific keys:
Example (separate OAuth secret):

Property Mapping

object
default:"{}"
Override JSON property names for specific secrets in AWS Secrets Manager.Default Behavior: When not specified, the chart uses lowercase versions of Kubernetes Secret keys. For example, SECRET_KEY_BASE maps to the secret_key_base JSON property.When to Use:
  • Your AWS Secrets Manager secret uses non-standard property names
  • Migrating from a different secret structure
  • Adding custom secrets not in the chart’s default set
Behavior:
  • Listed keys override the default property name
  • Listing a key that isn’t in the chart’s default set adds it to the SecretProviderClass request
Example (custom property names):
Default Mappings (automatically applied):See the Backend Key Reference for the complete list.
object
default:"{}"
Override JSON property names for OAuth service secrets in AWS Secrets Manager.Default Behavior: When not specified, the chart uses lowercase versions of Kubernetes Secret keys for OAuth secrets. For example, OAUTH_COOKIE_SECRET maps to the oauth_cookie_secret JSON property.When to Use:
  • Your OAuth secret uses non-standard property names
  • A single product integration uses a different client than its provider default
  • Migrating from External Secrets Operator with existing property mappings
You do not need it to add provider credentials. Every provider configured under oauth.secrets is requested automatically, and its base client ID and secret fan out across that provider’s product integrations.Behavior:
  • Listed keys override the default property name for OAuth secrets
  • An entry wins over the fan-out for that one key; every other key keeps inheriting the provider default
Example (product-specific credential):
Example (custom OAuth property names):
Default OAuth Mappings (automatically applied when oauth.enabled: true):Common OAuth Provider Keys:Requested automatically when the matching oauth.secrets.* block is set:
  • Google: GOOGLE_CLIENT_ID, GOOGLE_CLIENT_SECRET, GOOGLE_DRIVE_PICKER_KEY, GOOGLE_GMAIL_SERVICE_ACCOUNT_JSON
  • Microsoft: MICROSOFT_CLIENT_ID, MICROSOFT_CLIENT_SECRET, MICROSOFT_TENANT_ID
  • HubSpot: HUBSPOT_CLIENT_ID, HUBSPOT_CLIENT_SECRET
  • Notion: NOTION_CLIENT_ID, NOTION_CLIENT_SECRET
  • Salesforce: SALESFORCE_CLIENT_ID, SALESFORCE_CLIENT_SECRET
Credential Fanout: When you configure base provider credentials (e.g., GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET), the chart automatically expands them to all product integrations without requiring separate backend properties:
  • Google → Fans out to: Calendar, Gmail, Drive, Contacts, Sheets, Slides, Docs (16 total Secret keys from 2 backend properties)
  • Microsoft → Fans out to: Outlook, OneDrive, SharePoint, Teams, Word, Excel (21 total Secret keys from 3 backend properties)
This means you only need to store 2-3 properties per provider in AWS Secrets Manager instead of storing credentials for each product separately. The chart handles the expansion automatically when you configure oauth.secrets.google or oauth.secrets.microsoft with clientId and clientSecret.Override Individual Products: If you need different credentials for a specific product (e.g., separate Google Calendar credentials), add that specific key to oauthPropertyMap (e.g., GOOGLE_CAL_CLIENT_ID: "google_calendar_client_id") and it will use its own backend property instead of the shared fanout.
Separation from propertyMap: The oauthPropertyMap field was introduced to handle OAuth-specific secrets separately from platform secrets. This matches the External Secrets Operator pattern and ensures provider credentials route to the correct secret when migrating between secret management modes.

AWS Configuration

string
required
AWS region where secrets are stored.Required: Yes (when csiSecret.enabled: true)Example: "us-west-2"IAM Permissions: The pod’s IAM role must have secretsmanager:GetSecretValue permission for secrets in this region.
string
default:""
Optional second AWS region for the CSI provider’s failover lookup.When to Use:
  • Multi-region disaster recovery setup
  • AWS Secrets Manager replication is configured
  • High availability requirements
Behavior: If the primary region lookup fails, the CSI provider attempts to fetch secrets from this region.Example:
string
default:""
IAM role ARN for IRSA (IAM Roles for Service Accounts) authentication.When to Use:
  • EKS clusters using IRSA for pod-level IAM permissions
  • Fine-grained secret access control per namespace
Behavior: When set, this role ARN is annotated onto the csi-syncer ServiceAccount with the eks.amazonaws.com/role-arn annotation.Leave Empty When:
  • Node IAM role already grants secretsmanager:GetSecretValue
  • Using EKS Pod Identity (newer AWS authentication method)
  • Using static credentials
Example:
IAM Policy Example:

Additional Options

boolean
default:"false"
Pull AWS credentials from the platform secret for use by application workloads.When to Use:
  • Application needs AWS API access (S3, SQS, etc.)
  • AWS credentials should be managed alongside other secrets
Behavior: When true, adds AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY to the list of secrets fetched from csiSecret.secretPath.JSON Properties Expected:
  • aws_access_key_id (or override via propertyMap)
  • aws_secret_access_key (or override via propertyMap)
Example:
Alternative: For production environments, prefer IAM roles (node role, IRSA, or Pod Identity) over static credentials.

Sync Behavior

Automatic Secret Synchronization:When CSI Secret Store mode is enabled, the chart automatically handles secret synchronization via a two-phase hook mechanism:
  1. CSI Syncer Deployment (hook weight: -40) - Starts a deployment that mounts the CSI volume to materialize the Kubernetes Secret
  2. Gate Pod (hook weight: -25) - A validation pod that waits for secrets to be available before Helm proceeds
This synchronization is always enabled and ensures all required secrets are available before workloads start. Unlike External Secrets Operator mode (which has a configurable externalSecret.waitForSync), the CSI sync mechanism is built into the deployment pattern and cannot be disabled.Why This Matters:
  • Prevents pod CrashLoops due to missing secrets during deployment
  • Helm waits for the gate Pod to succeed before proceeding with migration jobs and workloads
  • Failed secret mounts are detected early with clear error messages from AWS
If secret mounting fails, the gate Pod will fail with the AWS error message, and Helm will halt the deployment before any workloads are affected.

Backend Key Reference

The following table lists all secrets that may be required in your AWS Secrets Manager backend, depending on your configuration. Each secret is fetched from the appropriate path (secretPath, databaseSecretPath, or oauthSecretPath).

Core Platform Secrets

Fetched from csiSecret.secretPath:

Database Secrets

Fetched from csiSecret.databaseSecretPath:

Optional Platform Secrets

Fetched from csiSecret.secretPath when conditions are met:

GitHub App Secrets

Fetched from csiSecret.secretPath when envVars.GITHUB_APP_ID is set:

OAuth Provider Secrets

Fetched from csiSecret.oauthSecretPath (or csiSecret.secretPath if not specified) when envVars.AUTH_PROVIDER is configured:

OAuth Service Secrets

Fetched from csiSecret.oauthSecretPath (or csiSecret.secretPath if not specified) when oauth.enabled: true:

OAuth Provider Credentials

Fetched from csiSecret.oauthSecretPath (or csiSecret.secretPath if not specified) when explicitly added via csiSecret.oauthPropertyMap:
Not Requested by Default: OAuth provider credentials for end-user integrations must be explicitly added to csiSecret.oauthPropertyMap. The chart does not request these by default.
Example (adding Google OAuth credentials):
See the OAuth Provider Credentials configuration example for detailed setup instructions.

Optional Service Secrets

Fetched from csiSecret.secretPath when services are enabled:
TLS Auto-Generation Not Supported: The chart’s web.tls.autoGenerate feature is not compatible with CSI Secret Store mode. If you need application-level TLS, you must either:
  1. Store SSL certificates in AWS Secrets Manager at csiSecret.secretPath (properties: platform_ssl_key, platform_ssl_cert, crew_ssl_cert, crew_ssl_key)
  2. Disable application-level TLS and terminate TLS externally (load balancer or ingress controller)

Example Configurations

Minimal Configuration

With IRSA Authentication

Separate OAuth Secrets

With OAuth Provider Credentials

With Custom Property Names

Multi-Region with Failover