SecretManagerFactory
is a utility class used to create instances of different types of secret managers. It leverages the Factory design pattern to abstract the creation logic based on the type of secret manager required. The factory supports creating instances of File, GCP, Kubernetes, and Vault Secret Managers.
The SECRET_MANAGER_TYPE
environment variable plays a crucial role in the SecretManagerFactory for determining the default type of secret manager to be instantiated when no specific type is provided in the method call.
Functionality:
Default Secret Manager: If the SECRET_MANAGER_TYPE
environment variable is set, its value dictates the default type of secret manager that the factory will create.
The value of this variable should correspond to one of the types defined in SecretManagerTypes enum (FILE
, AWS
, GCP
, K8S
, VAULT
).
Example Configuration:
Setting SECRET_MANAGER_TYPE=GCP
in the environment will make the factory create instances of GcpSecretManager by default.
If SECRET_MANAGER_TYPE
is not set or is set to FILE
, the factory defaults to creating instances of FileSecretManager.
This environment variable provides flexibility and ease of configuration, allowing different secret managers to be used in different environments or scenarios without code changes.
FileSecretManager
is a concrete implementation of the BaseSecretManager for managing secrets stored in the file system. It uses a specified directory (defaulting to ./) to read, write, and delete secret files.
Configuration:
Set the environment variable SECRET_MANAGER_DIRECTORY
to specify the directory where secrets are stored. If not set, defaults to the current directory (./).
Usage:
AwsSecretManager
integrates with Amazon Web Services’ Secrets Manager service for secure secret management. It provides a robust solution for storing and managing secrets in AWS environments.
Configuration:
Required environment variables:
AWS_REGION
: The AWS region where your secrets are storedAWS_ACCESS_KEY_ID
: Your AWS access keyAWS_SECRET_ACCESS_KEY
: Your AWS secret access key
Optional:AWS_KMS_KEY_ID
: The KMS key ID to use for encrypting secretsAWS_SECRET_MANAGER_TAGS
: Comma-separated list of tags to add to the secret in AWS Secrets Manager, e.g. key=value,key2=value2
AWS_SECRET_ROTATION_ENABLED
: Set to true
to enable automatic rotation of secrets (default: false
)AWS_SECRET_ROTATION_DAYS
: Number of days between automatic rotations (default: 30
)AWS_SECRET_ROTATION_LAMBDA_ARN
: ARN of the Lambda function to use for secret rotation, required if rotation is enabledAWS_SECRET_ROTATION_ENABLED=true
in your environmentAWS_SECRET_ROTATION_LAMBDA_ARN
to the ARN of your rotation Lambda functionAWS_SECRET_ROTATION_DAYS
to customize the rotation intervalarn:aws:lambda:region:account-id:function:function-name
Note: Different secret types (database credentials, API keys, etc.) require different rotation logic. Make sure your Lambda function is appropriate for the type of secrets you’re storing.
KubernetesSecretManager
interfaces with Kubernetes’ native secrets system.
It manages secrets within a specified Kubernetes namespace and is designed to operate within a Kubernetes cluster.
SECRET_MANAGER_TYPE=k8s
K8S_NAMESPACE=keep
- environment variable to specify the Kubernetes namespace. Defaults to .metadata.namespace
if not set. Assumes Kubernetes configurations (like service account tokens) are properly set up when running within a cluster.K8S_VERIFY_SSL_CERT=true
- environment variable to specify whether to verify the SSL certificate of the Kubernetes API. Defaults to true
.DATABASE_CONNECTION_STRING
, it is recommended to store as a secret:
values.yaml
so the helm chart will inject the secret as env var:
GcpSecretManager
utilizes Google Cloud’s Secret Manager service for secret management. It requires setting up with Google Cloud credentials and a project ID.
Configuration:
Ensure the environment variable GOOGLE_CLOUD_PROJECT
is set with your Google Cloud project ID.
Usage:
VaultSecretManager
is tailored for Hashicorp Vault, a tool for managing sensitive data. It supports token-based authentication as well as Kubernetes-based authentication for Vault.
Configuration:
HASHICORP_VAULT_ADDR
to the Vault server address. Defaults to http://localhost:8200.HASHICORP_VAULT_TOKEN
for token-based authentication.HASHICORP_VAULT_USE_K8S
to True and provide HASHICORP_VAULT_K8S_ROLE
for Kubernetes-based authentication.