helm-external-secrets/docs/snippets/full-secret-store.yaml

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