Secrets import

Distributing sensitive information across multiple external systems creates several challenges, including:

• Increased operational overhead.
• Increased exposure risk from data sprawl.
• Increased risk of outdated and out-of-sync information.

Using Vault as a single source of truth (SSOT) for sensitive data increases security and reduces management overhead, but migrating preexisting data from multiple and/or varied sources can be complex and costly.

The secrets import process helps you automate and streamline your sensitive data migration with codified import plans as HCL files. Import plans tell Vault which KVv2 secrets engine instance to store the expected secret data in, the source system for which data will be read from, and how to filter this data. Three HCL blocks make this possible:

• The destination block defines target KVv2 mounts.
• The source block provides credentials for connecting to the external system.
• The mapping block defines how Vault should decide which data gets imported before writing the information to KVv2.

Destinations

Vault stores imported secrets in a Vault KVv2 secrets engine mount. Destination blocks start with destination_vault and define the desired KVv2 mount path and an optional namespace. The combination of these represent the exact location in your Vault instance you want the information stored.

HCL syntax

destination_vault {
  name      = "my-dest-1"
  namespace = "ns-1"
  mount     = "mount-1"
}

• name (string: <required>) - A unique name for the destination block that can be referenced in subsequent mapping blocks.

• mount (string: <required>) - The mount path for the target KVv2 instance.

• address (string) - Optional network address of the Vault server with the KVv2 secrets engine enabled. By default, the Vault client's address will be used.

• token (string) - Optional authentication token for the Vault server at the specified address. By default, the Vault client's token will be used.

• namespace (string) - Optional namespace path containing the specified KVv2 mount. By default, Vault looks for the KVv2 mount under the root namespace.

Sources

Vault can import secrets from the following sources:

• GCP Secret Manager

To pull data from a source during import, Vault needs read credentials for the external system. You can provide credentials directly as part of the import plan, or use Vault to automatically generate dynamic credentials if you already have the corresponding secrets engine configured.

HCL syntax

Source blocks start with source_<external_system> and include any connection information required by the target system or the secrets engine to leverage. For example:

source_gcp {
  name        = "my-gcp-source-1"
  credentials = "@/path/to/service-account-key.json"
}

• name (string: <required>) - A unique name for the source block that can be referenced in subsequent mapping blocks.

• credentials (string: <required>) - Path to a credential file or token with read permissions for the target system.

Depending on the source system, additional information may be required. Refer to the connection documentation for your source system to determine the full set of required fields for that system type.

Mappings

Mappings glue the source and destination together and filter the migrated data, to determine what is imported and what is ignored. Vault currently supports the following mapping methods:

• mapping_passthrough
• mapping_metadata
• mapping_regex

HCL syntax

Mapping blocks start with mapping_<filter_type> and require a source name, destination name, an execution priority, and any corresponding transformations or filters that apply for each mapping type. For example:

mapping_regex {
  name        = "my-map-1"
  source      = "my-gcp-source-1"
  destination = "my-dest-1"
  priority    = 1
  expression  = "^database/.*$"
}

• name (string: <required>) - A unique name for the mapping block.

• source (string: <required>) - The name of a previously-defined source block from which the data should be read.

• destination (string: <required>) - The name of a previously defined destination block to which the data should be written.

• priority (integer: <required>) - The order in which Vault should apply the mapping block during the import process. The lower the number, the higher the priority. For example, a mapping with priority 1 executes before a mapping with priority 2.

Depending on the filter type, additional fields may be required or possible. Refer to the import mappings documentation for the available supported options and for a list of each mapping's specific fields.