community.hashi_vault.vault_write lookup – Perform a write operation against HashiCorp Vault
Note
This lookup plugin is part of the community.hashi_vault collection (version 6.3.0-dev0).
It is not included in ansible-core.
To check whether it is installed, run ansible-galaxy collection list.
To install it, use: ansible-galaxy collection install community.hashi_vault.
You need further requirements to be able to use this lookup plugin,
see Requirements for details.
To use it in a playbook, specify: community.hashi_vault.vault_write.
New in community.hashi_vault 2.4.0
Synopsis
Performs a generic write operation against a given path in HashiCorp Vault, returning any output.
Requirements
The below requirements are needed on the local controller node that executes this lookup.
hvac(Python library)For detailed requirements, see the collection requirements page.
Terms
Parameter |
Comments |
|---|---|
Vault path(s) to be written to. |
Keyword parameters
This describes keyword parameters of the lookup. These are the values key1=value1, key2=value2 and so on in the following
examples: lookup('community.hashi_vault.vault_write', key1=value1, key2=value2, ...) and query('community.hashi_vault.vault_write', key1=value1, key2=value2, ...)
Parameter |
Comments |
|---|---|
Authentication method to be used.
Choices:
Configuration:
|
|
The AWS access key to use. Configuration:
|
|
If specified, sets the value to use for the Configuration:
|
|
The AWS profile Configuration:
|
|
The AWS secret key that corresponds to the access key. Configuration:
|
|
The AWS security token if using temporary access and secret keys. Configuration:
|
|
The client ID (also known as application ID) of the Azure AD service principal or managed identity. Should be a UUID. If not specified, will use the system assigned managed identity. Configuration:
|
|
The client secret of the Azure AD service principal. Configuration:
|
|
The resource URL for the application registered in Azure Active Directory. Usually should not be changed from the default. Default: Configuration:
|
|
The Azure Active Directory Tenant ID (also known as the Directory ID) of the service principal. Should be a UUID. Required when using a service principal to authenticate to Vault, e.g. required when both azure_client_id and azure_client_secret are specified. Optional when using managed identity to authenticate to Vault. Configuration:
|
|
Path to certificate to use for authentication. If not specified by any other means, the Configuration:
|
|
For Configuration:
|
|
For Configuration:
|
|
A dictionary to be serialized to JSON and then sent as the request body. If the dictionary contains keys named Default: |
|
The JSON Web Token (JWT) to use for JWT authentication to Vault. Configuration:
|
|
Vault mount point. If not specified, the default mount point for a given auth method is used. Does not apply to token authentication. Configuration:
|
|
Vault namespace where secrets reside. This option requires HVAC 0.7.0+ and Vault 0.11+. Optionally, this may be achieved by prefixing the authentication mount point and/or secret path with the namespace (e.g If environment variable Configuration:
|
|
Authentication password. Configuration:
|
|
URL(s) to the proxies used to access the Vault service. It can be a string or a dict. If it’s a dict, provide the scheme (eg. If it’s a string, provide a single URL that will be used as the proxy for both A string that can be interpreted as a dictionary will be converted to one (see examples). You can specify a different proxy for HTTP and HTTPS resources. If not specified, environment variables from the Requests library are used. Configuration:
|
|
The AWS region for which to create the connection. Configuration:
|
|
Allows for retrying on errors, based on the Retry class in the urllib3 library. This collection defines recommended defaults for retrying connections to Vault. This option can be specified as a positive number (integer) or dictionary. If this option is not specified or the number is A number sets the total number of retries, and uses collection defaults for the other settings. A dictionary value is used directly to initialize the For detailed information on retries, see the collection User Guide. Configuration:
|
|
Controls whether and how to show messages on retries. This has no effect if a request is not retried. Choices:
Configuration:
|
|
Vault Role ID or name. Used in For For Configuration:
|
|
Secret ID to be used for Vault AppRole authentication. Configuration:
|
|
Sets the connection timeout in seconds. If not set, then the Configuration:
|
|
Vault token. Token may be specified explicitly, through the listed [env] vars, and also through the If no token is supplied, explicitly or through env, then the plugin will check for a token file, as determined by token_path and token_file. The order of token loading (first found wins) is Configuration:
|
|
If no token is specified, will try to read the token from this file in token_path. Default: Configuration:
|
|
If no token is specified, will try to read the token_file from this path. Configuration:
|
|
For token auth, will perform a Disable if your token does not have the Choices:
Configuration:
|
|
URL to the Vault service. If not specified by any other means, the value of the If Configuration:
|
|
Authentication user name. Configuration:
|
|
Controls verification and validation of SSL certificates, mostly you only want to turn off with self signed ones. Will be populated with the inverse of Will default to Choices:
Configuration:
|
|
Specifies response wrapping token creation with duration. For example Configuration:
|
Notes
Note
When keyword and positional parameters are used together, positional parameters must be listed before keyword parameters:
lookup('community.hashi_vault.vault_write', term1, term2, key1=value1, key2=value2)andquery('community.hashi_vault.vault_write', term1, term2, key1=value1, key2=value2)vault_writeis a generic plugin to do operations that do not yet have a dedicated plugin. Where a specific plugin exists, that should be used instead.In the vast majority of cases, it will be better to do writes as a task, with the community.hashi_vault.vault_write module.
The lookup can be used in cases where you need a value directly in templating, but there is risk of executing the write many times unintentionally.
The lookup is best used for endpoints that directly manipulate the input data and return a value, while not changing state in Vault.
See the Lookup Guide for more information.
See Also
See also
- community.hashi_vault.vault_write
Perform a write operation against HashiCorp Vault.
- community.hashi_vault.vault_kv2_write
Perform a write operation against a KVv2 secret in HashiCorp Vault.
- community.hashi_vault.vault_read lookup
The official documentation for the
community.hashi_vault.vault_readlookup plugin.- community.hashi_vault.vault_read
Perform a read operation against HashiCorp Vault.
- community.hashi_vault Lookup Guide
Guidance on using lookups in
community.hashi_vault.
Examples
# These examples show some uses that might work well as a lookup.
# For most uses, the vault_write module should be used.
- name: Retrieve and display random data
vars:
data:
format: hex
num_bytes: 64
ansible.builtin.debug:
msg: "{{ lookup('community.hashi_vault.vault_write', 'sys/tools/random/' ~ num_bytes, data=data) }}"
- name: Hash some data and display the hash
vars:
input: |
Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Pellentesque posuere dui a ipsum dapibus, et placerat nibh bibendum.
data:
input: '{{ input | b64encode }}'
hash_algo: sha2-256
ansible.builtin.debug:
msg: "The hash is {{ lookup('community.hashi_vault.vault_write', 'sys/tools/hash/' ~ hash_algo, data=data) }}"
# In this next example, the Ansible controller's token does not have permission to read the secrets we need.
# It does have permission to generate new secret IDs for an approle which has permission to read the secrets,
# however the approle is configured to:
# 1) allow a maximum of 1 use per secret ID
# 2) restrict the IPs allowed to use login using the approle to those of the remote hosts
#
# Normally, the fact that a new secret ID would be generated on every loop iteration would not be desirable,
# but here it's quite convenient.
- name: Retrieve secrets from the remote host with one-time-use approle creds
vars:
role_id: "{{ lookup('community.hashi_vault.vault_read', 'auth/approle/role/role-name/role-id') }}"
secret_id: "{{ lookup('community.hashi_vault.vault_write', 'auth/approle/role/role-name/secret-id') }}"
community.hashi_vault.vault_read:
auth_method: approle
role_id: '{{ role_id }}'
secret_id: '{{ secret_id }}'
path: '{{ item }}'
register: secret_data
loop:
- secret/data/secret1
- secret/data/app/deploy-key
- secret/data/access-codes/self-destruct
# This time we have a secret values on the controller, and we need to run a command the remote host,
# that is expecting to a use single-use token as input, so we need to use wrapping to send the data.
- name: Run a command that needs wrapped secrets
vars:
secrets:
secret1: '{{ my_secret_1 }}'
secret2: '{{ second_secret }}'
wrapped: "{{ lookup('community.hashi_vault.vault_write', 'sys/wrapping/wrap', data=secrets) }}"
ansible.builtin.command: 'vault unwrap {{ wrapped }}'
Return Value
Key |
Description |
|---|---|
The raw result of the write against the given path. Returned: success |