mirror of
https://github.com/optim-enterprises-bv/vault.git
synced 2025-11-01 11:08:10 +00:00
This reverts commit 9c0f2fbfe5.
This commit is contained in:
@@ -59,43 +59,23 @@ general, refer to the [Secrets Import documentation](/vault/docs/import).
|
|||||||
|
|
||||||
```hcl
|
```hcl
|
||||||
source_gcp {
|
source_gcp {
|
||||||
name = "my-src-1"
|
name = "my-gcp-source-1"
|
||||||
credentials_file = "/path/to/service-account-key.json"
|
credentials = "@/path/to/service-account-key.json"
|
||||||
}
|
|
||||||
|
|
||||||
source_aws {
|
|
||||||
name = "my-src-2"
|
|
||||||
credentials_profile = "my-profile-name"
|
|
||||||
}
|
|
||||||
|
|
||||||
source_azure {
|
|
||||||
name = "my-src-3"
|
|
||||||
# Use default credentials from doing an az login
|
|
||||||
}
|
}
|
||||||
|
|
||||||
destination_vault {
|
destination_vault {
|
||||||
name = "my-dest-1"
|
name = "my-dest-1"
|
||||||
address = "http://127.0.0.1:8200/"
|
address = "http://127.0.0.1:8200/"
|
||||||
|
token = "root"
|
||||||
namespace = "ns-1"
|
namespace = "ns-1"
|
||||||
mount = "mount-1"
|
mount = "mount-1"
|
||||||
}
|
}
|
||||||
|
|
||||||
mapping {
|
mapping_passthrough {
|
||||||
name = "my-map-1"
|
name = "my-map-1"
|
||||||
source = "my-src-1"
|
source = "my-gcp-1"
|
||||||
destination = "my-dest-1"
|
|
||||||
}
|
|
||||||
|
|
||||||
mapping {
|
|
||||||
name = "my-map-2"
|
|
||||||
source = "my-src-2"
|
|
||||||
destination = "my-dest-1"
|
|
||||||
}
|
|
||||||
|
|
||||||
mapping {
|
|
||||||
name = "my-map-3"
|
|
||||||
source = "my-src-3"
|
|
||||||
destination = "my-dest-1"
|
destination = "my-dest-1"
|
||||||
|
priority = 1
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
|
|||||||
@@ -1,39 +0,0 @@
|
|||||||
---
|
|
||||||
layout: docs
|
|
||||||
page_title: AWS secret import source
|
|
||||||
description: The AWS Secret Manager source imports secrets from AWS to Vault.
|
|
||||||
---
|
|
||||||
|
|
||||||
# AWS secret import source
|
|
||||||
|
|
||||||
Use the AWS source to import secret data from AWS Secret Manager into your Vault instance.
|
|
||||||
|
|
||||||
## Argument reference
|
|
||||||
|
|
||||||
Refer to the [HCL syntax](/vault/docs/import#hcl-syntax-1) for arguments common to all source types.
|
|
||||||
|
|
||||||
## Additional arguments
|
|
||||||
|
|
||||||
- `credentials_profile` `(string: "")` - The name of the profile in your credentials file to authenticate with.
|
|
||||||
If not set, Vault uses the default credential provider mechanisms.
|
|
||||||
|
|
||||||
## Example
|
|
||||||
|
|
||||||
Define and configure the `my-aws-source-1` AWS source:
|
|
||||||
|
|
||||||
```hcl
|
|
||||||
source_aws {
|
|
||||||
name = "my-aws-source-1"
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
## Permissions
|
|
||||||
|
|
||||||
To use AWS import, you must grant the associated AWS identity permissions to read secrets:
|
|
||||||
|
|
||||||
```shell-session
|
|
||||||
"secretsmanager:DescribeSecret",
|
|
||||||
"secretsmanager:GetSecretValue",
|
|
||||||
"secretsmanager:BatchGetSecretValue",
|
|
||||||
"secretsmanager:ListSecrets",
|
|
||||||
```
|
|
||||||
@@ -1,49 +0,0 @@
|
|||||||
---
|
|
||||||
layout: docs
|
|
||||||
page_title: Azure secret import source
|
|
||||||
description: The Azure KeyVault source imports secrets from Azure to Vault.
|
|
||||||
---
|
|
||||||
|
|
||||||
# Azure secret import source
|
|
||||||
|
|
||||||
Use the Azure source to import secret data from Azure KeyVault into your Vault instance.
|
|
||||||
|
|
||||||
## Argument reference
|
|
||||||
|
|
||||||
Refer to the [HCL syntax](/vault/docs/import#hcl-syntax-1) for arguments common to all source types.
|
|
||||||
|
|
||||||
## Additional arguments
|
|
||||||
|
|
||||||
Required:
|
|
||||||
|
|
||||||
- `key_vault_uri` `(string)` - The URI of the Azure KeyVault you want to import from.
|
|
||||||
|
|
||||||
The following parameters are optional. If you leave these parameters unset,
|
|
||||||
Vault uses the default credential provider mechanisms, e.g. the credentials persisted to disk
|
|
||||||
by a preceding `az login`.
|
|
||||||
|
|
||||||
- `cloud_name` `(string: "AzureCloud")` - Azure cloud to connect to
|
|
||||||
- `tenant_id` `(string: "")` - Tenant ID to use
|
|
||||||
- `client_id` `(string: "")` - Client ID to use
|
|
||||||
- `credentials_file` `(string: "")` - Path to a file with the client secret
|
|
||||||
|
|
||||||
## Example
|
|
||||||
|
|
||||||
Define and configure the `my-azure-source-1` Azure source:
|
|
||||||
|
|
||||||
```hcl
|
|
||||||
source_aws {
|
|
||||||
name = "my-azure-source-1"
|
|
||||||
key_vault_uri = "https://keyvault-1234abcd.vault.azure.net"
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
## Permissions
|
|
||||||
|
|
||||||
To use Azure import, you must grant the associated Azure identity permission to read secrets
|
|
||||||
from the specified KeyVault:
|
|
||||||
|
|
||||||
```shell-session
|
|
||||||
"Get",
|
|
||||||
"List",
|
|
||||||
```
|
|
||||||
@@ -7,7 +7,8 @@ description: The Google Cloud Platform Secret Manager source imports secrets fro
|
|||||||
# GCP secret import source
|
# GCP secret import source
|
||||||
|
|
||||||
Use the GCP source to import secret data from GCP Secret Manager into your Vault instance. To use dynamic
|
Use the GCP source to import secret data from GCP Secret Manager into your Vault instance. To use dynamic
|
||||||
credentials with GCP import, ensure the [GCP secrets engine](/vault/docs/secrets/gcp) is already configured.
|
credentials with GCP import, ensure the [GCP secrets engine](/vault/docs/secrets/gcp) is
|
||||||
|
already configured.
|
||||||
|
|
||||||
## Argument reference
|
## Argument reference
|
||||||
|
|
||||||
@@ -15,8 +16,9 @@ Refer to the [HCL syntax](/vault/docs/import#hcl-syntax-1) for arguments common
|
|||||||
|
|
||||||
## Additional arguments
|
## Additional arguments
|
||||||
|
|
||||||
- `credentials_file` `(string: "")` - The path to the service account key credentials file to authenticate with.
|
- `credentials` `(string: "")` - The path to the service account key credentials file for the service account
|
||||||
If `credentials_file` is set, then `vault_mount_path` and `vault_role_name` must be unset.
|
with the [necessary permissions](#permissions). If `credentials` is set, then `vault_mount_path` and
|
||||||
|
`vault_role_name` must be unset.
|
||||||
|
|
||||||
- `vault_mount_path` `(string: "")` - The Vault mount path to a pre-configured GCP
|
- `vault_mount_path` `(string: "")` - The Vault mount path to a pre-configured GCP
|
||||||
secrets engine used to generate dynamic credentials for the importer. If one of
|
secrets engine used to generate dynamic credentials for the importer. If one of
|
||||||
|
|||||||
@@ -18,7 +18,7 @@ several challenges, including:
|
|||||||
- Increased exposure risk from data sprawl.
|
- Increased exposure risk from data sprawl.
|
||||||
- Increased risk of outdated and out-of-sync information.
|
- Increased risk of outdated and out-of-sync information.
|
||||||
|
|
||||||
Using Vault as a single source of truth for sensitive data increases
|
Using Vault as a single source of truth (SSOT) for sensitive data increases
|
||||||
security and reduces management overhead, but migrating preexisting data from multiple
|
security and reduces management overhead, but migrating preexisting data from multiple
|
||||||
and/or varied sources can be complex and costly.
|
and/or varied sources can be complex and costly.
|
||||||
|
|
||||||
@@ -29,8 +29,8 @@ read from, and how to filter this data. Three HCL blocks make this possible:
|
|||||||
|
|
||||||
- The `destination` block defines target KVv2 mounts.
|
- The `destination` block defines target KVv2 mounts.
|
||||||
- The `source` block provides credentials for connecting to the external system.
|
- The `source` block provides credentials for connecting to the external system.
|
||||||
- The `mapping` block defines how Vault should decide which data gets imported (and possibly
|
- The `mapping` block defines how Vault should decide which data gets imported before
|
||||||
transformed) before writing the information to KVv2.
|
writing the information to KVv2.
|
||||||
|
|
||||||
## Destinations
|
## Destinations
|
||||||
|
|
||||||
@@ -41,6 +41,7 @@ Vault instance you want the information stored.
|
|||||||
|
|
||||||
### HCL syntax
|
### HCL syntax
|
||||||
|
|
||||||
|
|
||||||
```hcl
|
```hcl
|
||||||
destination_vault {
|
destination_vault {
|
||||||
name = "my-dest-1"
|
name = "my-dest-1"
|
||||||
@@ -57,25 +58,23 @@ destination_vault {
|
|||||||
- `address` `(string)` - Optional network address of the Vault server with the
|
- `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.
|
KVv2 secrets engine enabled. By default, the Vault client's address will be used.
|
||||||
|
|
||||||
- `credentials_file` `(string)` - Optional path to authentication token for the Vault
|
- `token` `(string)` - Optional authentication token for the Vault server at the
|
||||||
server at the specified address. By default, the Vault client's token will be used.
|
specified address. By default, the Vault client's token will be used.
|
||||||
|
|
||||||
- `namespace` `(string)` - Optional namespace path containing the specified KVv2
|
- `namespace` `(string)` - Optional namespace path containing the specified KVv2
|
||||||
mount. By default, Vault looks for the KVv2 mount under the root namespace.
|
mount. By default, Vault looks for the KVv2 mount under the root namespace.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
## Sources
|
## Sources
|
||||||
|
|
||||||
Vault can import secrets from the following sources:
|
Vault can import secrets from the following sources:
|
||||||
- [GCP Secret Manager](/vault/docs/import/gcpsm)
|
- [GCP Secret Manager](/vault/docs/import/gcpsm)
|
||||||
- [AWS Secret Manager](/vault/docs/import/awssm)
|
|
||||||
- [Azure KeyVault](/vault/docs/import/azurekv)
|
|
||||||
- [HashiCorp Vault](/vault/docs/import/vault)
|
|
||||||
|
|
||||||
To pull data from a source during import, Vault needs credentials for the
|
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
|
external system. You can provide credentials directly as part of the import
|
||||||
plan, or use Vault to automatically generate dynamic credentials if you already
|
plan, or use Vault to automatically generate dynamic credentials if you already
|
||||||
have the corresponding secrets engine configured. Otherwise credentials will be
|
have the corresponding secrets engine configured.
|
||||||
fetched from the default locations appropriate to the external system.
|
|
||||||
|
|
||||||
### HCL syntax
|
### HCL syntax
|
||||||
|
|
||||||
@@ -85,44 +84,45 @@ information required by the target system or the secrets engine to leverage. For
|
|||||||
```hcl
|
```hcl
|
||||||
source_gcp {
|
source_gcp {
|
||||||
name = "my-gcp-source-1"
|
name = "my-gcp-source-1"
|
||||||
credentials_file = "/path/to/service-account-key.json"
|
credentials = "@/path/to/service-account-key.json"
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
- `name` `(string: <required>)` - A unique name for the source block that can be
|
- `name` `(string: <required>)` - A unique name for the source block that can be
|
||||||
referenced in subsequent mapping blocks.
|
referenced in subsequent mapping blocks.
|
||||||
|
|
||||||
- `credentials_file` `(string: <required>)` - Path to a credential file with
|
- `credentials` `(string: <required>)` - Path to a credential file or token with
|
||||||
read permissions for the target system.
|
read permissions for the target system.
|
||||||
|
|
||||||
Depending on the source system, additional information may be required. Refer to
|
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
|
the connection documentation for your source system to determine the full set of
|
||||||
required fields for that system type.
|
required fields for that system type.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
## Mappings
|
## Mappings
|
||||||
|
|
||||||
Mappings glue the source and destination together and filter the migrated data,
|
Mappings glue the source and destination together and filter the migrated data,
|
||||||
to determine what is imported and what is ignored.
|
to determine what is imported and what is ignored. Vault currently supports the
|
||||||
|
following mapping methods:
|
||||||
|
|
||||||
|
- [mapping_passthrough](/vault/docs/import/mappings#passthrough)
|
||||||
|
- [mapping_metadata](/vault/docs/import/mappings#metadata)
|
||||||
|
- [mapping_regex](/vault/docs/import/mappings#regex)
|
||||||
|
|
||||||
### HCL syntax
|
### HCL syntax
|
||||||
|
|
||||||
Mapping blocks require a name, a source name, a destination name, and any corresponding
|
Mapping blocks start with `mapping_<filter_type>` and require a source name,
|
||||||
transformations or filters that apply for each mapping type. Example:
|
destination name, an execution priority, and any corresponding transformations
|
||||||
|
or filters that apply for each mapping type. For example:
|
||||||
|
|
||||||
```hcl
|
```hcl
|
||||||
mapping {
|
mapping_regex {
|
||||||
name = "my-map-1"
|
name = "my-map-1"
|
||||||
source = "my-gcp-source-1"
|
source = "my-gcp-source-1"
|
||||||
destination = "my-dest-1"
|
destination = "my-dest-1"
|
||||||
filter = "Secret.Name matches `(foo|bar)`"
|
priority = 1
|
||||||
transform "exact" {
|
expression = "^database/.*$"
|
||||||
from = "foo"
|
|
||||||
to = "foosball"
|
|
||||||
}
|
|
||||||
transform "regexp" {
|
|
||||||
from = "foo(.*)"
|
|
||||||
to = "bar$1"
|
|
||||||
}
|
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
@@ -134,58 +134,20 @@ mapping {
|
|||||||
- `destination` `(string: <required>)` - The name of a previously defined
|
- `destination` `(string: <required>)` - The name of a previously defined
|
||||||
destination block **to** which the data should be written.
|
destination block **to** which the data should be written.
|
||||||
|
|
||||||
- `filter` `(string: "")` - Optional string containing a (`bexpr` style boolean expression)[https://github.com/hashicorp/go-bexpr]
|
- `priority` `(integer: <required>)` - The order in which Vault should apply the
|
||||||
that limits which secrets Vault imports from the source.
|
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.
|
||||||
|
|
||||||
#### Filters
|
Depending on the filter type, additional fields may be required or possible. Refer
|
||||||
|
to the [import mappings documentation](/vault/docs/import/mappings) for the available
|
||||||
|
supported options and for a list of each mapping's specific fields.
|
||||||
|
|
||||||
Filters describes conditions for secret fields that a source secret must meet to be imported. You can filter against the following secret fields:
|
<Tip title="Priority matters">
|
||||||
|
|
||||||
- `Secret.Name` - The name of the source secret
|
Vault applies mapping definitions in priority order and a given secret only
|
||||||
- `Secret.Tags` - A map of key-value user-defined metadata associated with the source secret
|
matches to the first mapping that applies. Once Vault imports a secret with a
|
||||||
|
particular mapping, subsequent reads from the same source will ignore that
|
||||||
|
secret. See the [priority section](/vault/docs/import/mappings#priority) for an example.
|
||||||
|
|
||||||
You can also apply simple binary conditions to input values:
|
</Tip>
|
||||||
|
|
||||||
- `Secret.Name != "foo"`
|
|
||||||
- `Secret.Tags.Team matches "my-dept.*"`
|
|
||||||
- `Secret.Tags contains "my-required-tag-name"`
|
|
||||||
|
|
||||||
These can be combined using `and`, `or`, and `not`:
|
|
||||||
|
|
||||||
- `(Secret.Name == "foo" or Secret.Tags.Team == "my-team") and Secret.Tags.Category = "my-cat"`
|
|
||||||
|
|
||||||
#### Transformers
|
|
||||||
|
|
||||||
Transform stanzas come in two forms: `exact` and `regexp`.
|
|
||||||
|
|
||||||
An exact transform allows renaming a secret during import, so that the `from` secret name
|
|
||||||
is imported into Vault as a secret named `to`. In the following example it, takes a source secret
|
|
||||||
named `foo` and transforms it to `foosball` during import.
|
|
||||||
|
|
||||||
```hcl
|
|
||||||
transform "exact" {
|
|
||||||
from = "foo"
|
|
||||||
to = "foosball"
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
`regexp` transforms rename secrets during import using
|
|
||||||
[Go regular expression syntax](https://github.com/google/re2/wiki/Syntax). For
|
|
||||||
example, the transform below imports any secret in the source whose name starts
|
|
||||||
with `foo` and replaces the `foo` prefix with `bar`.
|
|
||||||
|
|
||||||
```hcl
|
|
||||||
transform "regexp" {
|
|
||||||
from = "foo(.*)"
|
|
||||||
to = "bar$1"
|
|
||||||
}
|
|
||||||
transform "regexp" {
|
|
||||||
from = "foo(?P<suffix>.*)"
|
|
||||||
to = "bar$suffix"
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
The `from` value supports parentheses to bookend capture groups and named
|
|
||||||
capture groups using the syntax `(?P<name>re)`. When you use named capture
|
|
||||||
groups, you can reference the named group in the `to` value. For example,
|
|
||||||
`$name` instead of `$1`.
|
|
||||||
|
|||||||
132
website/content/docs/import/mappings.mdx
Normal file
132
website/content/docs/import/mappings.mdx
Normal file
@@ -0,0 +1,132 @@
|
|||||||
|
---
|
||||||
|
layout: docs
|
||||||
|
page_title: Secrets import mappings
|
||||||
|
description: Mappings lets users apply various filtering methods to secrets being imported in to Vault.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Secrets import mappings
|
||||||
|
|
||||||
|
Vault supports multiple filter types for mapping blocks. Each of the types provides a different mechanism
|
||||||
|
used to filter the scanned secrets and determine which will be imported in to Vault.
|
||||||
|
|
||||||
|
|
||||||
|
## Argument reference
|
||||||
|
|
||||||
|
Refer to the [HCL syntax](/vault/docs/import#hcl-syntax-2) for arguments common to all mapping types.
|
||||||
|
|
||||||
|
## Passthrough mapping filters
|
||||||
|
|
||||||
|
The passthrough mapping block `mapping_passthrough` allows all secrets through from the specified source to the
|
||||||
|
specified destination. For example, one use case is setting it as a base-case for imported secrets. By assigning
|
||||||
|
it the lowest priority in the import plan, all other mapping blocks will be applied first. Secrets that fail
|
||||||
|
to match any of the previous mappings will fall through to the passthrough block and be collected in a single
|
||||||
|
KVv2 location.
|
||||||
|
|
||||||
|
### Additional arguments
|
||||||
|
|
||||||
|
There are no extra arguments to specify in a `mapping_passthrough` block.
|
||||||
|
|
||||||
|
### Example
|
||||||
|
|
||||||
|
In this example, every single secret that `my-gcp-source-1` scans from GCP Secret Manager will be imported
|
||||||
|
to the KVv2 secrets engine mount defined in `my-dest-1`.
|
||||||
|
|
||||||
|
```hcl
|
||||||
|
mapping_passthrough {
|
||||||
|
name = "my-map-1"
|
||||||
|
source = "my-gcp-source-1"
|
||||||
|
destination = "my-dest-1"
|
||||||
|
priority = 1
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## Metadata
|
||||||
|
|
||||||
|
The metadata mapping block `mapping_metadata` allows secrets through from the specified source to the specified
|
||||||
|
destination if they contain matching metadata key-value pairs. Metadata is not supported in all external secret
|
||||||
|
management systems, and ones that do may use different terminology for metadata. For example, AWS allows tags
|
||||||
|
on secrets while [GCP](/vault/docs/import/gcpsm) allows labels.
|
||||||
|
|
||||||
|
### Additional arguments
|
||||||
|
|
||||||
|
* `tags` `(string: <required>)` - A set of key-value pairs to match on secrets from the external system. All of the specified
|
||||||
|
keys must be found on a secret and all of the values must be exact matches. Specifying a key in this mapping with
|
||||||
|
an empty value, i.e. `""`, acts as a wildcard match to the external system's key's value.
|
||||||
|
|
||||||
|
### Example
|
||||||
|
|
||||||
|
In this example, `my-map-1` will only import the secrets into the destination `my-dest-1` that contain a tag with
|
||||||
|
a key named `importable` and its value set to `true`.
|
||||||
|
|
||||||
|
```hcl
|
||||||
|
mapping_metadata {
|
||||||
|
name = "my-map-1"
|
||||||
|
source = "my-gcp-source-1"
|
||||||
|
destination = "my-dest-1"
|
||||||
|
priority = 1
|
||||||
|
|
||||||
|
tags = {
|
||||||
|
"importable" = "true"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## Regex
|
||||||
|
|
||||||
|
The regex mapping block `mapping_regex` allows secrets through from the specified source to the specified
|
||||||
|
destination if their secret name passes a regular expression check.
|
||||||
|
|
||||||
|
### Additional arguments
|
||||||
|
|
||||||
|
* `expression` `(string: <required>)` - The regular expression used to match secrets' names from the external system.
|
||||||
|
|
||||||
|
### Example
|
||||||
|
|
||||||
|
In this example, any secret in the GCP source whose name begins with `database/` will be imported into Vault.
|
||||||
|
|
||||||
|
```hcl
|
||||||
|
mapping_regex {
|
||||||
|
name = "my-map-1"
|
||||||
|
source = "my-gcp-source-1"
|
||||||
|
destination = "my-dest-1"
|
||||||
|
priority = 1
|
||||||
|
expression = "^database/.*$"
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## Priority
|
||||||
|
|
||||||
|
Priority works in a "first match" fashion where lower values are higher priority. To explain in more detail,
|
||||||
|
consider the above metadata example with a second additional mapping.
|
||||||
|
|
||||||
|
Below are two metadata mappings. The first, `my-map-1`, has a priority of 1. This will only import the secrets
|
||||||
|
into the destination `my-dest-1` that contain both tag keys `database` and `importable`. Each of these keys' values
|
||||||
|
must also match to `users` and `true` respectively. The second, `my-map-2`, has a priority of 2. Even though all
|
||||||
|
the secrets in the first mapping would also qualify for the second mapping's filtering rule, those secrets will only
|
||||||
|
be imported into `my-dest-1` because of `my-map-2`'s lower priority. All remaining secrets that have the tag
|
||||||
|
`importable` with a value of `true` will be imported into `my-dest-2`.
|
||||||
|
|
||||||
|
```hcl
|
||||||
|
mapping_metadata {
|
||||||
|
name = "my-map-1"
|
||||||
|
source = "my-gcp-source-1"
|
||||||
|
destination = "my-dest-1"
|
||||||
|
priority = 1
|
||||||
|
|
||||||
|
tags = {
|
||||||
|
"database" = "users"
|
||||||
|
"importable" = "true"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
mapping_metadata {
|
||||||
|
name = "my-map-2"
|
||||||
|
source = "my-gcp-source-1"
|
||||||
|
destination = "my-dest-2"
|
||||||
|
priority = 2
|
||||||
|
|
||||||
|
tags = {
|
||||||
|
"importable" = "true"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
@@ -1,38 +0,0 @@
|
|||||||
---
|
|
||||||
layout: docs
|
|
||||||
page_title: Vault secret import source
|
|
||||||
description: The Vault source imports secrets from Vault to Vault.
|
|
||||||
---
|
|
||||||
|
|
||||||
# Vault secret import source
|
|
||||||
|
|
||||||
Use the Vault source to import secret data from a Vault cluster into your Vault instance.
|
|
||||||
|
|
||||||
## Argument reference
|
|
||||||
|
|
||||||
Refer to the [HCL syntax](/vault/docs/import#hcl-syntax-1) for arguments common to all source types.
|
|
||||||
|
|
||||||
## Additional arguments
|
|
||||||
|
|
||||||
- `address` `(string: required)` - API address of source vault cluster.
|
|
||||||
- `namespace` `(string: "")` - Optional namespace to read from.
|
|
||||||
- `mount` `(string: required)` - KV-v2 mount to read from.
|
|
||||||
- `credentials_file` `(string: "")` - Path to a file containing a vault token. If absent, the CLI uses the
|
|
||||||
environment variable VAULT_TOKEN. However, VAULT_TOKEN will be used for the Vault destination as well, so
|
|
||||||
unless you're using the same cluster as both source and destination (e.g. from one mount to another), the source
|
|
||||||
`credentials_file` should be populated with the source-specific token.
|
|
||||||
|
|
||||||
## Example
|
|
||||||
|
|
||||||
Define and configure the `my-vault-source-1` Vault source:
|
|
||||||
|
|
||||||
```hcl
|
|
||||||
source_vault {
|
|
||||||
name = "my-vault-source-1"
|
|
||||||
address = "https://source-vault-address:8200"
|
|
||||||
namespace = "ns1"
|
|
||||||
mount = "my-kvv2"
|
|
||||||
credentials_file = "/path/to/vault/token"
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
@@ -1882,21 +1882,13 @@
|
|||||||
"color": "highlight"
|
"color": "highlight"
|
||||||
}
|
}
|
||||||
},
|
},
|
||||||
{
|
|
||||||
"title": "AWS Secret Manager",
|
|
||||||
"path": "import/awssm"
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"title": "Azure KeyVault",
|
|
||||||
"path": "import/azurekv"
|
|
||||||
},
|
|
||||||
{
|
{
|
||||||
"title": "GCP Secret Manager",
|
"title": "GCP Secret Manager",
|
||||||
"path": "import/gcpsm"
|
"path": "import/gcpsm"
|
||||||
},
|
},
|
||||||
{
|
{
|
||||||
"title": "HashiCorp Vault",
|
"title": "Mappings",
|
||||||
"path": "import/vault"
|
"path": "import/mappings"
|
||||||
}
|
}
|
||||||
]
|
]
|
||||||
},
|
},
|
||||||
|
|||||||
Reference in New Issue
Block a user