Parameters

The parent key for all of the following parameters is vault.

`namespace`

type	string
default	`${_instance}`

The namespace in which to deploy this component.

Two intances of vault can be deployed in the same namespace, but the two instances will have access to each others unseal secrets.

`name`

type	string
default	`${_instance}`

The name of the deployed component.

`kubernetes_version`

type	string
default	`1.24`

The Kubernetes version of the cluster the component is deployed to. This parameter is passed to Helm when rendering the Helm chart. The default chart version used by the component requires Kubernetes 1.20 or newer.

We recommend setting this parameter based on the cluster’s kubernetesVersion dynamic fact.

`images`

type	dictionary

Dictionary containing the container images used by this component.

`charts`

type	dictionary

Dictionary containing the chart versions used by this component.

`ingress.enabled`

type	bool
default	`true`

Whether to create an ingess object.

On OpenShift, the Helm chart doesn’t support creating an Ingress.

However, on VSHN Managed OpenShift, we need an Ingress anyway to take advantage of cert-manager integration and similar. Because of that, the component itself generates an Ingress when deploying the component on OpenShift.

If you prefer using the Helm chart’s generated Route on OpenShift, set ingress.enabled=false and configure the Route via parameter helm_values.

`ingress.host`

type	string
default	`vault.todo.tld`

Defines the FQDN of the ingress, should be overwritten on the cluster level.

`ingress.annotations`

type	dict
default	{}

The annotations added to the created ingress Needs to be set according to the deployed ingress controller.

Example:

annotations:
  cert-manager.io/cluster-issuer: letsencrypt-production
  kubernetes.io/ingress.class: nginx

`storage.size`

type	string
default	`10G`

The requested storage size for secret storage.

`storage.class`

type	string
default	``

The kubernetes storage class to request.

`resources`

type	dict
default	`requests: memory: 256Mi cpu: 250m limits: memory: 512Mi cpu: 1000m`

The resource requests and limits.

`podManagementPolicy`

type	string
default	`OrderedReady`

The podManagementPolicy for the vault statefulset

Setting this to Parallel might cause a race condition during initial setup. This parameter can’t be changed after the initial deployment of the component.

`x_forwarded_for`

This section allows users to configure how Vault uses the information in the X-Forwarded-For header in client connections.

`authorized_addrs`

type	string
default	`127.0.0.1/32`

This parameter allows users to specify the list of source IP CIDRs for which an X-Forwarded-For header will be trusted. Since Vault doesn’t accept the empty string as a valid option, we set the parameter to only trust X-Forwarded-For headers from 127.0.0.1/32 by default.

To avoid issues with parameter interpolation, multiple entries should be specified as a comma-separated list.

If you want to use functionality in Vault which requires the real source IP of requests, you should set this parameter to a CIDR which includes the IPs of your ingress controller.

Also see the Vault documentation.

`hop_skips`

type	number
default	`"0"`

The number of entries in the X-Forwarded-For header to skip. You may have to set this parameter, if you’re deploying this component on a cluster which is behind multiple HTTP load balancers.

See the Vault documentation for more details.

`reject_not_authorized`

type	bool
default	`"false"`

By default, if there’s an X-Forwarded-For header in a connection from an address which isn’t in x_forwarded_for_authorized_addrs, the header will be ignored and the client address is used as-is.

If this is set to true, such client connections are rejected instead.

We default this parameter to false to provide an usable setup out of the box. If you expect that all valid client connections will have an X-Forwarded-For header, we strongly recommend setting it to true if you configure x_forwarded_for_authorized_addrs.

`reject_not_present`

type	bool
default	`"false"`

By default, if there is no X-Forwarded-For header in a connection from an address which isn’t in x_forwarded_For_authorized_addrs or if the header is empty, the client address will be used as-is.

If this parameter is set to true, such client connections are rejected instead.

`config`

type	dict
default	See `class/defaults.yml`

The configuration for Vault. The configuration is applied with bank-vaults.

The component takes the provided config and uses it as a bank-vaults configuration.

Additionally to passing through the configuration, the component also allows users to provide configuration in keys suffixed with _ for bank-vaults config keys which expect lists.

In contrast to the raw bank-vaults config, the component expects that the suffixed keys contain objects, and the component transforms the contents into a list. The suffixed keys themselves don’t appear in the resulting bank-vaults configuration.

If the object value is set to null, the entry isn’t emitted in the resulting list.

For each config section, the object keys are used as a particular field for the list entry:

Config section Object key field

Config section	Object key field
`audit`	`type`
`auth`	`path`
`plugins`	`plugin_name`
`policies`	`name`
`secrets`	`path`
`startupSecrets`	`path`

audit

type

auth

path

plugins

plugin_name

policies

name

secrets

path

startupSecrets

path

The object value can set the object key field, but the actual object key takes precedence.

For sections whose entries support field roles, the field roles of entries provided through the config key suffixed with _ is also expected to be an object and transformed to a list. For field roles, the object keys are used as field name in the resulting list entries.

The default configuration enables K8s authentication, adds a general key-value secret store with path clusters/kv and sets up a policy and a K8s authentication role for the K8up backup. If K8s authentication, or the backup role or policy are removed, the backups configured through parameter backup won’t work correctly.

This configuration may directly contain secret references (see example below) as it will be stored in a secret.

Example LDAP configuration

auth_:
  ldap:
    type: ldap
    description: LDAP auth
    options:
      listing_visibility: "unauth"
    config:
      url: ldaps://ldap.todo.com:636
      binddn: "uid=vault-service,ou=Users,dc=todo,dc=com"
      bindpass: ?{vaultkv:${cluster:tenant}/${cluster:name}/vault/ldap/password}
      userattr: uid
      userdn: "ou=vault,ou=Service Access,ou=Views,dc=todo,dc=com"
      groupdn: "ou=Groups,dc=todo,dc=com"
      groupattr: cn
    groups:
      Vault root:
        policies: vault-root

This snippet is transformed into the following bank-vaults snippet

auth:
  - path: ldap
    type: ldap
    description: LDAP auth
    options:
      listing_visibility: "unauth"
    config:
      url: ldaps://ldap.todo.com:636
      binddn: "uid=vault-service,ou=Users,dc=todo,dc=com"
      bindpass: ?{vaultkv:${cluster:tenant}/${cluster:name}/vault/ldap/password}
      userattr: uid
      userdn: "ou=vault,ou=Service Access,ou=Views,dc=todo,dc=com"
      groupdn: "ou=Groups,dc=todo,dc=com"
      groupattr: cn
    groups:
      Vault root:
        policies: vault-root

Example OIDC configuration

auth_:
  oidc:
    type: oidc
    description: OIDC authentication
    options:
      listing_visibility: unauth
    config:
      default_role: default
      namespace_in_state: true
      oidc_client_id: <CLIENT_ID>
      oidc_client_secret: ?{vaultkv:${cluster:tenant}/${cluster:name}/vault/${_instance}/oidc/client_secret}
      oidc_discovery_url: https://keycloak.example.com/auth/realms/example-realm
    roles:
      default:
        allowed_redirect_uris:
          - https://${vault:ingress:host}/ui/vault/auth/oidc/oidc/callback
          - https://${vault:ingress:host}/oidc/callback
          - http://localhost:8250/oidc/callback
        bound_claims_type: string
        groups_claim: groups
        policies: ["default"]
        role_type: oidc
        user_claim: sub

This snippet is transformed into the following bank-vaults snippet

auth:
  - path: oidc
    type: oidc
    description: OIDC authentication
    options:
      listing_visibility: unauth
    config:
      default_role: default
      namespace_in_state: true
      oidc_client_id: <CLIENT_ID>
      oidc_client_secret: ?{vaultkv:${cluster:tenant}/${cluster:name}/vault/${_instance}/oidc/client_secret}
      oidc_discovery_url: https://keycloak.example.com/auth/realms/example-realm
    roles:
      - name: default
        allowed_redirect_uris:
          - https://${vault:ingress:host}/ui/vault/auth/oidc/oidc/callback
          - https://${vault:ingress:host}/oidc/callback
          - http://localhost:8250/oidc/callback
        bound_claims_type: string
        groups_claim: groups
        policies: ["default"]
        role_type: oidc
        user_claim: sub

`backup.enabled`

type	bool
default	`true`

Whether to do backups using k8up.

Manual Setup Required

component-vault leverages k8up’s application specific backups to create Vault snapshots. Restoring such a snapshot is only possible by providing the Vault unseal key and root token. As these are sensitive secrets, they are not backed up as part of the component’s automated backup process.

When setting up Vault, you must store the Vault unseal key and root token in a safe location in order to be able to restore backups.

In a running Vault instance, both of these secrets can be found in the [instance name]-seal secret in the Vault instance’s namespace. In order to have a reliable Vault backup, this secret must be backed up separately to a safe location.

`backup.schedule`

type	string
default	`/13 * * *`

The schedule to perform backups in crontab format.

`backup.keepjobs`

type	string
default	`5`

`backup.password`

type	string
default	`?{vaultkv:${cluster:tenant}/${cluster:name}/vault/backup/password}`

The password for the backup.

`backup.bucket`

type

dict

default

name: '${_instance}-backup'
accesskey: '?{vaultkv:${cluster:tenant}/${cluster:name}/vault/${_instance}/backup/s3_access_key}'
secretkey: '?{vaultkv:${cluster:tenant}/${cluster:name}/vault/${_instance}/backup/s3_secret_key}'

The connection information for the S3 bucket to write to.