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.

Different Store Providers have different stability levels, maintenance status, and support. To check the full list, please see Stability Support.

Unmaintained Stores generate events

Admission webhooks and controllers will emit warning events for providers without a explicit maintainer. To disable controller warning events, you can add external-secrets.io/ignore-maintenance-checks: "true" annotation to the SecretStore. Admission webhook warning cannot be disabled.

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
  annotations:
    ## Add this annotation to disable controller warning events for unmaintained stores
    external-secrets.io/disable-maintenance-checks: "true"
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, Hashicorp Vault, 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:
          accessKeyIDSecretRef:
            name: awssm-secret
            key: access-key
          secretAccessKeySecretRef:
            name: awssm-secret
            key: secret-access-key

    # (2) Hashicorp Vault
    vault:
      server: "https://vault.acme.org"
      # Path is the mount path of the Vault KV backend endpoint
      # Used as a path prefix for the external secret key
      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"
      # client side related TLS communication, when the Vault server requires mutual authentication
      tls:
        certSecretRef:
          namespace: ...
          name: "my-cert-secret"
          key: "tls.crt"
        keySecretRef:
          namespace: ...
          name: "my-cert-secret"
          key: "tls.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"
          # Instead of referencing the AppRole's ID from the secret, you can also specify it directly
          # roleId: "db02de05-fa39-4855-059b-67221c5c2f63"
          roleRef:
            name: "my-secret"
            key: "vault-role-id"
          secretRef:
            name: "my-secret"
            key: "vault-role-secret"

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

        # TLS certificates auth method: https://developer.hashicorp.com/vault/docs/auth/cert
        cert:
          clientCert:
            namespace: ...
            name: "my-cert-secret"
            key: "tls.crt"
          secretRef:
            namespace: ...
            name: "my-cert-secret"
            key: "tls.key"

    # (3): 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"