-
Notifications
You must be signed in to change notification settings - Fork 436
Description
Is your feature request related to a problem? Please describe.
Currently, the existingSecret configuration only supports password values. In cloud environments like AWS RDS, Google Cloud SQL, and Azure Database, connection details such as host, port, username, and database name are typically stored in Kubernetes Secrets for security and operational flexibility. Users are forced to hardcode these connection parameters directly in values.yaml, which defeats the purpose of using Secrets for sensitive infrastructure data and makes it difficult to manage credentials across different environments.
Describe the solution you'd like
Extend the existingSecret feature to support sourcing all database connection details from a Kubernetes Secret. This should include:
- Host - Database server hostname/endpoint
- Port - Database server port
- Username - Database user account
- Database - Database name
- Password - Database password (already supported)
The implementation should allow users to reference an existing Kubernetes Secret and specify key mappings for each connection parameter, similar to:
existingSecret: "my-rds-secret"
existingSecretKeys:
password: "password"
host: "host"
port: "port"
user: "username"
database: "dbname"This would eliminate the need to hardcode connection details in values.yaml.
Additional context
- Common use case: RDS endpoints that differ per environment but credentials stored in a shared Secret
- Aligns with Kubernetes best practices of storing all sensitive data in Secrets
- Reduces security risk by keeping infrastructure details out of version control
- Improves operational flexibility for multi-environment deployments