Virtual HSM
Home
  • Virtual HSM
  • Documentation
    • What is Virtual HSM?
    • Use Case: Attested Secret Provisioning in the Cloud
    • Setup
      • Install
      • vHSM Server Configuration
        • Parameters
        • vHSM Telemetry Parameters
      • vHSM Agent
        • Agent Configuration
      • vHSM Proxy
        • Proxy Configuration
    • Get Started
      • Start the Vault server
      • MariaDB root admin password provisioning on Azure DCXas_v5 VM
    • Supported Cloud Configurations
  • Tutorials
    • Deploying the vhsm Container on an EC2 Instance
    • CLI quickstart
    • vHSM Agent quickstart
    • vHSM Proxy quickstart
    • Passing vHSM secrets using ConfigMaps
    • Provisioning MariaDB Password on Azure DCXas_v5 VM
    • Registering a buckypaper plugin
    • Monitoring vHSM with Grafana
  • Integration with Utimaco SecurityServer
    • Integrate enclaive vHSM with Utimaco HSM
  • API
    • Auth
    • Default
    • Secrets
    • System
    • Identity
    • Models
  • vHSM CLI
    • Server and Infrastructure Management
      • vhsm server
      • vhsm proxy
      • vhsm monitor
      • vhsm status
      • vhsm agent
    • Secret Management
      • vhsm read
      • vhsm write
      • vhsm delete
      • vhsm list
      • vhsm secrets
        • vhsm secrets enable
        • vhsm secrets disable
        • vhsm secrets list
        • vhsm secrets move
        • vhsm secrets tune
      • vhsm unwrap
    • Configuration and Management
      • vhsm plugin
        • vhsm plugin info
        • vhsm plugin deregister
        • vhsm plugin list
        • vhsm plugin register
        • vhsm plugin reload
        • vhsm plugin reload-status
      • vhsm namespace
      • vhsm operator
      • vhsm print
      • vhsm path-help
      • vhsm lease
    • Auditing and Debugging
      • vhsm audit
      • vhsm debug
    • Attestation
    • Security and Encryption
      • vhsm pki
        • vhsm pki health-check
        • vhsm pki issue
        • vhsm pki list-intermediates
        • vhsm pki reissue
        • vhsm pki verify-sign
      • vhsm transit
      • vhsm ssh
      • vhsm transform
    • Authentication and Authorization
      • vhsm login
      • vhsm auth
      • vhsm token
      • vhsm policy
    • Storage and Data Mangement
      • vhsm kv
      • vhsm patch
    • vhsm version
      • vhsm version-history
  • Troubleshooting
    • CA Validity Period
    • CRL Validity Period
    • Root Certificate Issued Non-CA Leaves
    • Role Allows Implicit Localhost Issuance
    • Role Allows Glob-Based Wildcard Issuance
    • Performance Impact
    • Accessibility of Audit Information
    • Allow If-Modified-Since Requests
    • Auto-Tidy Disabled
    • Tidy Hasn't Run
    • Too Many Certificates
    • Enable ACME Issuance
    • ACME Response Headers Configuration
  • Resources
    • Community
    • GitHub
    • Youtube
    • CCx101 wiki
Powered by GitBook
On this page
  • Parameters
  • High availability parameters

Was this helpful?

  1. Documentation
  2. Setup
  3. vHSM Server Configuration

Parameters

Learn more about the parameters that you can configure to run the vHSM server.

Parameters

This table outlines essential configuration parameters for Vault. These parameters control various aspects of Vault's behavior, including storage, authentication, logging, security, and high availability. Each parameter is described in detail, providing guidance on how to configure Vault for optimal performance and security based on your deployment needs.

Parameter
Type
Default
Description

storage

[StorageBackend]

<required>

Configures the storage backend where Vault data is stored. Please see the storage backends documentation for the full list of available storage backends. Running Vault in HA mode would require coordination semantics to be supported by the backend. If the storage backend supports HA coordination, HA backend options can also be specified in this parameter block. If not, a separate ha_storage parameter should be configured with a backend that supports HA, along with corresponding HA options.

ha_storage

[StorageBackend]

nil

Configures the storage backend where Vault HA coordination will take place. This must be an HA-supporting backend. If not set, HA will be attempted on the backend given in the storage parameter. This parameter is not required if the storage backend supports HA coordination and if HA specific options are already specified with storage parameter. (Refer to Use Integrated Storage for HA Coordination for a usage example.)

listener

[Listener]

<required>

Configures how Vault is listening for API requests.

user_lockout

[UserLockout]

nil

Configures the user-lockout behaviour for failed logins. For more information, please see the user lockout configuration documentation.

seal

[Seal]

nil

Configures the seal type to use for auto-unsealing, as well as for seal wrapping as an additional layer of data protection.

cluster_name

string

<generated>

Specifies the identifier for the Vault cluster. If omitted, Vault will generate a value. When connecting to Vault Enterprise, this value will be used in the interface.

cache_size

string

"131072"

Specifies the size of the read cache used by the physical storage subsystem. The value is in number of entries, so the total cache size depends on the size of stored entries.

disable_cache

bool

false

Disables all caches within Vault, including the read cache used by the physical storage subsystem. This will very significantly impact performance.

disable_mlock

bool

false

Disables the server from executing the mlock syscall. mlock prevents memory from being swapped to disk. Disabling mlock is not recommended unless using integrated storage. Follow the additional security precautions outlined below when disabling mlock. This can also be provided via the environment variable VAULT_DISABLE_MLOCK.

plugin_directory

string

""

A directory from which plugins are allowed to be loaded. Vault must have permission to read files in this directory to successfully load plugins, and the value cannot be a symbolic link.

plugin_tmpdir

string

""

A directory that Vault can create temporary files in to support Unix socket communication with containerized plugins. If not set, Vault will use the system's default directory for temporary files. Generally not necessary unless you are using containerized plugins and Vault does not share a temporary folder with other processes, such as if using systemd's PrivateTmp setting. This can also be specified via the VAULT_PLUGIN_TMPDIR environment variable.

plugin_file_uid

integer

0

Uid of the plugin directories and plugin binaries if they are owned by an user other than the user running Vault. This only needs to be set if the file permissions check is enabled via the environment variable VAULT_ENABLE_FILE_PERMISSIONS_CHECK.

plugin_file_permissions

string

""

Octal permission string of the plugin directories and plugin binaries if they have write or execute permissions for group or others. This only needs to be set if the file permissions check is enabled via the environment variable VAULT_ENABLE_FILE_PERMISSIONS_CHECK.

[Telemetry]

<none>

Specifies the telemetry reporting system.

default_lease_ttl

string

"768h"

Specifies the default lease duration for tokens and secrets. This is specified using a label suffix like "30s" or "1h". This value cannot be larger than max_lease_ttl.

max_lease_ttl

string

"768h"

Specifies the maximum possible lease duration for tokens and secrets. This is specified using a label suffix like "30s" or "1h". Individual mounts can override this value by tuning the mount with the max-lease-ttl flag of the auth or secret commands.

default_max_request_duration

string

"90s"

Specifies the default maximum request duration allowed before Vault cancels the request. This can be overridden per listener via the max_request_duration value.

detect_deadlocks

string

""

A comma separated string that specifies the internal mutex locks that should be monitored for potential deadlocks. Currently supported values include statelock, quotas and expiration which will cause "POTENTIAL DEADLOCK:" to be logged when an attempt at a core state lock appears to be deadlocked. Enabling this can have a negative effect on performance due to the tracking of each lock attempt.

raw_storage_endpoint

bool

false

Enables the sys/raw endpoint which allows the decryption/encryption of raw data into and out of the security barrier. This is a highly privileged endpoint.

introspection_endpoint

bool

false

Enables the sys/internal/inspect endpoint which allows users with a root token or sudo privileges to inspect certain subsystems inside Vault.

ui

bool

false

Enables the built-in web UI, which is available on all listeners (address + port) at the /ui path. Browsers accessing the standard Vault API address will automatically redirect there. This can also be provided via the environment variable VAULT_UI. For more information, please see the ui configuration documentation.

pid_file

string

""

Path to the file in which the Vault server's Process ID (PID) should be stored.

enable_response_header_hostname

bool

false

Enables the addition of an HTTP header in all of Vault's HTTP responses: X-Vault-Hostname. This will contain the host name of the Vault node that serviced the HTTP request. This information is best effort and is not guaranteed to be present. If this configuration option is enabled and the X-Vault-Hostname header is not present in a response, it means there was some kind of error retrieving the host name from the operating system.

enable_response_header_raft_node_id

bool

false

Enables the addition of an HTTP header in all of Vault's HTTP responses: X-Vault-Raft-Node-ID. If Vault is participating in a Raft cluster (i.e. using integrated storage), this header will contain the Raft node ID of the Vault node that serviced the HTTP request. If Vault is not participating in a Raft cluster, this header will be omitted, whether this configuration option is enabled or not.

log_level

string

"info"

Log verbosity level. Supported values (in order of descending detail) are trace, debug, info, warn, and error. This can also be specified via the VAULT_LOG_LEVEL environment variable.

experiments

string array

[]

The list of experiments to enable for this node. Experiments should NOT be used in production, and the associated APIs may have backwards incompatible changes between releases. Additional experiments can also be specified via the VAULT_EXPERIMENTS environment variable as a comma-separated list, or via the -experiment flag.

imprecise_lease_role_tracking

bool

"false"

Skip lease counting by role if there are no role-based quotas enabled. When imprecise_lease_role_tracking is set to true and a new role-based quota is enabled, subsequent lease counts start from 0. imprecise_lease_role_tracking affects role-based lease count quotas, but reduces latencies when not using role based quotas.

High availability parameters

When configuring Vault in a high-availability (HA) setup, certain parameters help optimize communication and coordination between cluster members. These parameters define how Vault nodes interact, advertise themselves, and handle request forwarding. Proper configuration ensures seamless failover, efficient request routing, and enhanced reliability. Some of the key parameters used for backends that support high availability are as follows:

Parameter
Type
Default
Description

api_addr

string

""

Specifies the address (full URL) to advertise to other Vault servers in the cluster for client redirection. This value is also used for plugin backends. This can also be provided via the environment variable VAULT_API_ADDR. In general, this should be set as a full URL that points to the value of the listener address. This can be dynamically defined with a go-sockaddr template that is resolved at runtime.

cluster_addr

string

""

Specifies the address to advertise to other Vault servers in the cluster for request forwarding. This can also be provided via the environment variable VAULT_CLUSTER_ADDR. This is a full URL, like api_addr, but Vault will ignore the scheme (all cluster members always use TLS with a private key/certificate). This can be dynamically defined with a go-sockaddr template that is resolved at runtime.

disable_clustering

bool

false

Specifies whether clustering features such as request forwarding are enabled. Setting this to true on one Vault node will disable these features only when that node is the active node. This parameter cannot be set to true if raft is the storage type.

PreviousvHSM Server ConfigurationNextvHSM Telemetry Parameters

Last updated 1 month ago

Was this helpful?

telemetry