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
- A
SecretProviderClassresource defines which secrets to fetch from AWS Secrets Manager - A
csi-syncerdeployment mounts the CSI volume to materialize Kubernetes Secrets - Workloads consume the standard
crewai-platform-secretsSecret (identical to inline or ESO modes)
- secrets-store-csi-driver installed with
syncSecret.enabled=true - secrets-store-csi-driver-provider-aws installed
- Secrets pre-populated in AWS Secrets Manager
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
- Fails if
externalSecret.enabledis alsotrue(mutually exclusive) - Fails if
csiSecret.provideris not"aws"(only AWS is currently supported) - Fails if
web.tls.autoGenerateistrue(auto-generated TLS not supported in CSI mode)
string
default:"aws"
Secret store provider type.Valid Values:
"aws"- AWS Secrets Manager (only supported provider)
"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 Separate Secret: Database credentials are kept in a separate secret for easier credential rotation without touching platform secrets.
csiSecret.enabled: true)Format: Secret name or full ARNSecret Structure: JSON object with a password property:string
default:""
AWS Secrets Manager secret name or ARN containing OAuth service secrets.Default Behavior: When empty, defaults to Example (separate OAuth secret):
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
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, Default Mappings (automatically applied):
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
- 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
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, Example (custom OAuth property names):Default OAuth Mappings (automatically applied when
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
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
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)
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
string
default:""
IAM role ARN for IRSA (IAM Roles for Service Accounts) authentication.When to Use:IAM Policy Example:
- EKS clusters using IRSA for pod-level IAM permissions
- Fine-grained secret access control per namespace
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
Additional Options
boolean
default:"false"
Pull AWS credentials from the platform secret for use by application workloads.When to Use:Alternative: For production environments, prefer IAM roles (node role, IRSA, or Pod Identity) over static credentials.
- Application needs AWS API access (S3, SQS, etc.)
- AWS credentials should be managed alongside other secrets
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 viapropertyMap)aws_secret_access_key(or override viapropertyMap)
Sync Behavior
Automatic Secret Synchronization:When CSI Secret Store mode is enabled, the chart automatically handles secret synchronization via a two-phase hook mechanism:
- CSI Syncer Deployment (hook weight: -40) - Starts a deployment that mounts the CSI volume to materialize the Kubernetes Secret
- Gate Pod (hook weight: -25) - A validation pod that waits for secrets to be available before Helm proceeds
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
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 fromcsiSecret.secretPath:
Database Secrets
Fetched fromcsiSecret.databaseSecretPath:
Optional Platform Secrets
Fetched fromcsiSecret.secretPath when conditions are met:
GitHub App Secrets
Fetched fromcsiSecret.secretPath when envVars.GITHUB_APP_ID is set:
OAuth Provider Secrets
Fetched fromcsiSecret.oauthSecretPath (or csiSecret.secretPath if not specified) when envVars.AUTH_PROVIDER is configured:
OAuth Service Secrets
Fetched fromcsiSecret.oauthSecretPath (or csiSecret.secretPath if not specified) when oauth.enabled: true:
OAuth Provider Credentials
Fetched fromcsiSecret.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):
Optional Service Secrets
Fetched fromcsiSecret.secretPath when services are enabled:
Example Configurations
Minimal Configuration
With IRSA Authentication
Separate OAuth Secrets
With OAuth Provider Credentials
With Custom Property Names
Multi-Region with Failover
Related Documentation
- CSI Secret Store Setup Guide - Step-by-step deployment instructions
- External Secrets Operator - Alternative secret management approach
- Secrets Configuration - Direct secret values (inline mode)
