SecretStore
The SecretStore
is namespaced and specifies how to access the external API.
The SecretStore maps to exactly one instance of an external API.
By design, SecretStores are bound to a namespace and can not reference resources across namespaces. If you want to design cross-namespace SecretStores you must use ClusterSecretStores which do not have this limitation.
Example
For a full list of supported fields see spec or dig into our guides.
apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
name: example
namespace: example-ns
spec:
# Used to select the correct ESO controller (think: ingress.ingressClassName)
# The ESO controller is instantiated with a specific controller name
# and filters ES based on this property
# Optional
controller: dev
# You can specify retry settings for the http connection
# these fields allow you to set a maxRetries before failure, and
# an interval between the retries.
# Current supported providers: AWS, IBM
retrySettings:
maxRetries: 5
retryInterval: "10s"
# provider field contains the configuration to access the provider
# which contains the secret exactly one provider must be configured.
provider:
# (1): AWS Secrets Manager
# aws configures this store to sync secrets using AWS Secret Manager provider
aws:
service: SecretsManager
# Role is a Role ARN which the SecretManager provider will assume
role: iam-role
# AWS Region to be used for the provider
region: eu-central-1
# Auth defines the information necessary to authenticate against AWS by
# getting the accessKeyID and secretAccessKey from an already created Kubernetes Secret
auth:
secretRef:
accessKeyID:
name: awssm-secret
key: access-key
secretAccessKey:
name: awssm-secret
key: secret-access-key
vault:
server: "https://vault.acme.org"
# Path is the mount path of the Vault KV backend endpoint
path: "secret"
# Version is the Vault KV secret engine version.
# This can be either "v1" or "v2", defaults to "v2"
version: "v2"
# vault enterprise namespace: https://www.vaultproject.io/docs/enterprise/namespaces
namespace: "a-team"
# base64 encoded string of certificate
caBundle: "..."
# Instead of caBundle you can also specify a caProvider
# this will retrieve the cert from a Secret or ConfigMap
caProvider:
# Can be Secret or ConfigMap
type: "Secret"
name: "my-cert-secret"
key: "cert-key"
auth:
# static token: https://www.vaultproject.io/docs/auth/token
tokenSecretRef:
name: "my-secret"
key: "vault-token"
# AppRole auth: https://www.vaultproject.io/docs/auth/approle
appRole:
path: "approle"
roleId: "db02de05-fa39-4855-059b-67221c5c2f63"
secretRef:
name: "my-secret"
key: "vault-token"
# Kubernetes auth: https://www.vaultproject.io/docs/auth/kubernetes
kubernetes:
mountPath: "kubernetes"
role: "demo"
# Optional service account reference
serviceAccountRef:
name: "my-sa"
# Optional secret field containing a Kubernetes ServiceAccount JWT
# used for authenticating with Vault
secretRef:
name: "my-secret"
key: "vault"
# (2): GCP Secret Manager
gcpsm:
# Auth defines the information necessary to authenticate against GCP by getting
# the credentials from an already created Kubernetes Secret.
auth:
secretRef:
secretAccessKeySecretRef:
name: gcpsm-secret
key: secret-access-credentials
projectID: myproject
# (TODO): add more provider examples here
status:
# Standard condition schema
conditions:
# SecretStore ready condition indicates the given store is in ready
# state and able to referenced by ExternalSecrets
# If the `status` of this condition is `False`, ExternalSecret controllers
# should prevent attempts to fetch secrets
- type: Ready
status: "False"
reason: "ConfigError"
message: "SecretStore validation failed"
lastTransitionTime: "2019-08-12T12:33:02Z"