hashi_vault backend¶
Overview¶
hashi_vault backend connects directly to the Vault instance (works with both HashiCorp Vault and OpenBao). There are several authentication mechanisms available (token, userpass, jwt etc.).
With this backend certificates and keys are not stored on ansible controller. Instead, they are installed directly on target hosts.
Prerequisites¶
Fully configured Vault instance(either HashiCorp Vault or OpenBao)
PKI engine enabled for all used paths (
pki_root/andpki_int/by default)Vault’s role(
pki_hashi_vault_role) defined inpki_hashi_vault_engine_mount_point. This role defines the rules and constraints under which certificates can be issued. Example:bao write pki_int/roles/default allowed_domains=yourfqdn.com allow_subdomains=true ttl=90d
Limitations¶
hashi_vault backend issues certificates using a default issuer from
engine_mount_point. So there can be only one effective issuer in eachengine_mount_pointcommunity.hashi_vault.vault_pki_generate_certificatedoes not allow to passkey_usageorextended_key_usageparameter when generating a service certificate. These parameters need to be configured in Vault’s role configuration. Default Vault’s role configuration should work perfectly fine because it has both “TLS Web Server Authentication” and “TLS Web Client Authentication” in extended key usage).
PKI paths explained¶
Below diagram explains basic Vault architecture with two Vault paths. There are several important things to notice:
pki_root/path stores root certificate (it’s a default issuer in that path)pki_int/path stores intermediate certificate (it’s a default issuer in that path)services certs signed by intermediate certificate are also stored in
pki_int/pathintermediate certificate is signed by the default issuer from the path specified in
signed_by(root certificate is not directly specified, only the path where it resides)when issuing service cert,
engine_mount_pointparameter points to the path where certificate will be stored (default issuer from that path will sign the certificate)
Variables¶
pki_install_ca¶
Variable |
Required |
Description |
|---|---|---|
filename |
𐄂 |
Name for the file containing the authority on the target hosts |
name |
✔ |
Name of the authority to install |
pki_certificates¶
Variable |
Required |
Description |
|---|---|---|
backend |
𐄂 |
PKI backend that should be used for this certificate. |
cn |
✔ |
Common name of a certificate. |
engine_mount_point |
𐄂 |
Vault path where the certificate should be stored. |
exclude_cn_from_sans |
𐄂 |
If true, the given common_name will not be included in DNS or Email Subject Alternate Names (as appropriate). |
format |
𐄂 |
Specifies the format for returned data. |
key_format |
𐄂 |
Specifies the private key format. |
name |
✔ |
Name of the certificate (used mainly to find the right certificate when installing it on target hosts). |
role |
𐄂 |
Vault’s role that should be used for generating certificate. |
san |
𐄂 |
A dictionary containing dns, ip, uri and other SANs. |
ttl |
𐄂 |
Specifies the requested Time To Live (after which the certificate will be expired). |
pki_install_certificates¶
Variable |
Required |
Description |
|---|---|---|
name |
✔ |
Name of the certificate that should be installed on a target host. |
dest |
✔ |
Path where certificate should be stored on a target host. |
group |
𐄂 |
Name of the group that should own the filesystem object, as would be fed to chown. |
mode |
𐄂 |
The permissions the resulting filesystem object should have. |
owner |
𐄂 |
Name of the user that should own the filesystem object, as would be fed to chown. |
type |
✔ |
Specifies the content that should be placed in a destination file. Accepted values: certificate, certificate_chain, ca_bundle, private_key. |