Parameters :: Commodore Hub

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

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

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.

`config`

type

dict

default

policies:
  - name: backup
    rules: |
      path "sys/storage/raft/snapshot" {
        capabilities = ["read"]
      }
secrets:
  - type: kv
    path: clusters/kv
    description: General secrets for clusters
    options:
      version: 2
auth:
  - type: kubernetes
    roles:
      - name: backup
        bound_service_account_names: '${vault:name}-backup'
        bound_service_account_namespaces: ${vault:namespace}
        policies: backup
        ttl: 1h

The configuration for vault. The default configuration adds a general key-value secret store and a default backup user. If this backup user isn’t present, backups using k8up won’t succeed. This configuration may directly contain secret references (see example below) as it will be stored in a secret.

Example LDAP configuration:

auth:
  - type: kubernetes
    roles:
      - name: backup
        bound_service_account_names: vault-backup
        bound_service_account_namespaces: vault
        policies: backup
        ttl: 1h
  - 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

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