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.
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"