Added links to matching learn guide (#7636)
This commit is contained in:
parent
b3d53e4ef2
commit
dbdf65e5bc
|
@ -7,7 +7,7 @@ description: |-
|
|||
AWS Method for Vault Agent Auto-Auth
|
||||
---
|
||||
|
||||
# Vault Agent Auto-Auth AWS Method
|
||||
# Vault Agent Auto-Auth AWS Method
|
||||
|
||||
The `aws` method performs authentication against the [AWS Auth
|
||||
method](https://www.vaultproject.io/docs/auth/aws.html). Both `ec2` and `iam`
|
||||
|
@ -27,14 +27,14 @@ will use the first valid credentials it finds in the following order:
|
|||
2. Environment variables
|
||||
3. A file containing credentials
|
||||
4. From any identity services available in its physical environment like container environment variables or role-based instance metadata
|
||||
|
||||
Wherever possible, we recommend using identity services (method 4) for credentials.
|
||||
These rotate regularly and require no effort on your part to provision, making
|
||||
identity services the most secure of the four methods. If using identity services _and_ a custom
|
||||
|
||||
Wherever possible, we recommend using identity services (method 4) for credentials.
|
||||
These rotate regularly and require no effort on your part to provision, making
|
||||
identity services the most secure of the four methods. If using identity services _and_ a custom
|
||||
`credential_poll_interval`, be sure the frequency is set low enough to pick up new credentials
|
||||
from the physical environment as they become available.
|
||||
|
||||
To use identity services, choose the `iam` type and leave the `access_key`, `secret_key`, and `session_token`
|
||||
To use identity services, choose the `iam` type and leave the `access_key`, `secret_key`, and `session_token`
|
||||
parameters unset in your configuration.
|
||||
|
||||
## Configuration
|
||||
|
@ -53,3 +53,9 @@ parameters unset in your configuration.
|
|||
|
||||
- `header_value` `(string: optional)` - If configured in Vault, the value to use for
|
||||
[`iam_server_id_header_value`](https://www.vaultproject.io/api/auth/aws/index.html#iam_server_id_header_value).
|
||||
|
||||
## Learn
|
||||
|
||||
Refer to the [Vault Agent with
|
||||
AWS](https://learn.hashicorp.com/vault/identity-access-management/vault-agent-aws)
|
||||
guide for a step-by-step tutorial.
|
||||
|
|
|
@ -7,7 +7,7 @@ description: |-
|
|||
Kubernetes Method for Vault Agent Auto-Auth
|
||||
---
|
||||
|
||||
# Vault Agent Auto-Auth Kubernetes Method
|
||||
# Vault Agent Auto-Auth Kubernetes Method
|
||||
|
||||
The `kubernetes` method reads in a Kubernetes service account token from the
|
||||
running pod (via `/var/run/secrets/kubernetes.io/serviceaccount/token`) and
|
||||
|
@ -19,3 +19,9 @@ method](https://www.vaultproject.io/docs/auth/kubernetes.html).
|
|||
- `role` `(string: required)` - The role to authenticate against on Vault
|
||||
- `token_path` `(string: optional)` - The file path to a custom JWT token to use
|
||||
for authentication. If omitted, the default service account token path is used.
|
||||
|
||||
## Learn
|
||||
|
||||
Refer to the [Vault Agent with
|
||||
Kubernetes](https://learn.hashicorp.com/vault/identity-access-management/vault-agent-k8s)
|
||||
guide for a step-by-step tutorial.
|
||||
|
|
|
@ -232,3 +232,9 @@ vault {
|
|||
address = "http://127.0.0.1:8200"
|
||||
}
|
||||
```
|
||||
|
||||
## Learn
|
||||
|
||||
Refer to the [Vault Agent
|
||||
Caching](https://learn.hashicorp.com/vault/identity-access-management/agent-caching)
|
||||
guide for a step-by-step tutorial.
|
||||
|
|
|
@ -230,6 +230,12 @@ not require a credential, but still enforce constraints for login. For
|
|||
example, `secret_id_bound_cidrs` will only allow logins coming from IP addresses
|
||||
belonging to configured CIDR blocks on the AppRole.
|
||||
|
||||
## Learn
|
||||
|
||||
Refer to the [AppRole Pull
|
||||
Authentication](https://learn.hashicorp.com/vault/identity-access-management/iam-authentication)
|
||||
guide for a step-by-step tutorial.
|
||||
|
||||
## API
|
||||
|
||||
The AppRole auth method has a full HTTP API. Please see the
|
||||
|
|
|
@ -280,7 +280,7 @@ If you wanted to create a shared section of KV that is associated with entities
|
|||
group.
|
||||
|
||||
```ruby
|
||||
# In the example below, the group ID maps a group and the path
|
||||
# In the example below, the group ID maps a group and the path
|
||||
path "secret/data/groups/{{identity.groups.ids.fb036ebc-2f62-4124-9503-42aa7A869741.name}}/*" {
|
||||
capabilities = ["create", "update", "read", "delete"]
|
||||
}
|
||||
|
@ -455,7 +455,7 @@ wrapping mandatory for a particular path.
|
|||
wrapped response.
|
||||
|
||||
```ruby
|
||||
# This effectively makes response wrapping mandatory for this path by setting min_wrapping_ttl to 1 second.
|
||||
# This effectively makes response wrapping mandatory for this path by setting min_wrapping_ttl to 1 second.
|
||||
# This also sets this path's wrapped response maximum allowed TTL to 90 seconds.
|
||||
path "auth/approle/role/my-role/secret-id" {
|
||||
capabilities = ["create", "update"]
|
||||
|
@ -682,3 +682,11 @@ new set of policies.
|
|||
However, the _contents_ of policies are parsed in real-time whenever the token is used.
|
||||
As a result, if a policy is modified, the modified rules will be in force the
|
||||
next time a token, with that policy attached, is used to make a call to Vault.
|
||||
|
||||
|
||||
## Learn
|
||||
|
||||
Refer to the following tutorials for further learning:
|
||||
|
||||
- [Vault Policies](https://learn.hashicorp.com/vault/identity-access-management/iam-policies)
|
||||
- [ACL Policy Path Templating](https://learn.hashicorp.com/vault/identity-access-management/policy-templating)
|
||||
|
|
|
@ -40,7 +40,7 @@ seal "awskms" {
|
|||
These parameters apply to the `seal` stanza in the Vault configuration file:
|
||||
|
||||
- `region` `(string: "us-east-1")`: The AWS region where the encryption key
|
||||
lives. If not provided, may be populated from the `AWS_REGION` or
|
||||
lives. If not provided, may be populated from the `AWS_REGION` or
|
||||
`AWS_DEFAULT_REGION` environment variables, from your `~/.aws/config` file,
|
||||
or from instance metadata.
|
||||
|
||||
|
@ -74,13 +74,12 @@ variables or as configuration parameters.
|
|||
`AWS_ACCESS_KEY_ID` and `AWS_ACCESS_KEY_ID` as part of the seal's parameters, it
|
||||
is *strongly* recommended to set these values via environment variables.
|
||||
|
||||
```text
|
||||
AWS authentication values:
|
||||
|
||||
* `AWS_REGION` or `AWS_DEFAULT_REGION`
|
||||
* `AWS_ACCESS_KEY_ID`
|
||||
* `AWS_SECRET_ACCESS_KEY`
|
||||
```
|
||||
|
||||
|
||||
Note: The client uses the official AWS SDK and will use the specified
|
||||
credentials, environment credentials, shared file credentials, or IAM role/ECS
|
||||
|
@ -99,20 +98,25 @@ the KMS key policy for the KMS key, or via KMS Grants on the key.
|
|||
## `awskms` Environment Variables
|
||||
|
||||
Alternatively, the AWS KMS seal can be activated by providing the following
|
||||
environment variables:
|
||||
environment variables.
|
||||
|
||||
```text
|
||||
Vault Seal specific values:
|
||||
|
||||
* `VAULT_SEAL_TYPE`
|
||||
* `VAULT_AWSKMS_SEAL_KEY_ID`
|
||||
```
|
||||
|
||||
|
||||
## Key Rotation
|
||||
|
||||
This seal supports rotating the master keys defined in AWS KMS
|
||||
[doc](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html). Both automatic
|
||||
rotation and manual rotation is supported for KMS since the key information is stored with the
|
||||
encrypted data. Old keys must not be disabled or deleted and are used to decrypt older data.
|
||||
This seal supports rotating the master keys defined in AWS KMS
|
||||
[doc](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html). Both automatic
|
||||
rotation and manual rotation is supported for KMS since the key information is stored with the
|
||||
encrypted data. Old keys must not be disabled or deleted and are used to decrypt older data.
|
||||
Any new or updated data will be encrypted with the current key defined in the seal configuration
|
||||
or set to current under a key alias.
|
||||
|
||||
|
||||
## Learn
|
||||
|
||||
Refer to the [Auto-unseal using AWS KMS](https://learn.hashicorp.com/vault/operations/ops-autounseal-aws-kms)
|
||||
guide for a step-by-step tutorial.
|
||||
|
|
|
@ -62,14 +62,13 @@ These parameters apply to the `seal` stanza in the Vault configuration file:
|
|||
Authentication-related values must be provided, either as environment
|
||||
variables or as configuration parameters.
|
||||
|
||||
```text
|
||||
Azure authentication values:
|
||||
|
||||
* `AZURE_TENANT_ID`
|
||||
* `AZURE_CLIENT_ID`
|
||||
* `AZURE_CLIENT_SECRET`
|
||||
* `AZURE_ENVIRONMENT`
|
||||
```
|
||||
|
||||
|
||||
~> **Note:** If Vault is hosted on Azure, Vault can use Managed Service
|
||||
Identities (MSI) to access Azure instead of an environment and shared client id
|
||||
|
@ -87,12 +86,15 @@ for more best practices.
|
|||
Alternatively, the Azure Key Vault seal can be activated by providing the following
|
||||
environment variables:
|
||||
|
||||
```text
|
||||
* `VAULT_AZUREKEYVAULT_VAULT_NAME`
|
||||
* `VAULT_AZUREKEYVAULT_KEY_NAME`
|
||||
```
|
||||
|
||||
## Key Rotation
|
||||
|
||||
This seal supports rotating keys defined in Azure Key Vault. Key metadata is stored with the
|
||||
encrypted data to ensure the correct key is used during decryption operations.
|
||||
|
||||
## Learn
|
||||
|
||||
Refer to the [Auto-unseal using Azure Key Vault](https://learn.hashicorp.com/vault/operations/autounseal-azure-keyvault)
|
||||
guide for a step-by-step tutorial.
|
||||
|
|
|
@ -63,13 +63,12 @@ These parameters apply to the `seal` stanza in the Vault configuration file:
|
|||
Authentication-related values must be provided, either as environment
|
||||
variables or as configuration parameters.
|
||||
|
||||
```text
|
||||
GCP authentication values:
|
||||
|
||||
* `GOOGLE_CREDENTIALS` or `GOOGLE_APPLICATION_CREDENTIALS`
|
||||
* `GOOGLE_PROJECT`
|
||||
* `GOOGLE_REGION`
|
||||
```
|
||||
|
||||
|
||||
Note: The client uses the official Google SDK and will use the specified
|
||||
credentials, environment credentials, or [application default
|
||||
|
@ -98,11 +97,10 @@ cloudkms.cryptoKeys.get
|
|||
Alternatively, the GCP Cloud KMS seal can be activated by providing the following
|
||||
environment variables:
|
||||
|
||||
```text
|
||||
* `VAULT_SEAL_TYPE`
|
||||
* `VAULT_GCPCKMS_SEAL_KEY_RING`
|
||||
* `VAULT_GCPCKMS_SEAL_CRYPTO_KEY`
|
||||
```
|
||||
|
||||
|
||||
## Key Rotation
|
||||
|
||||
|
@ -111,3 +109,8 @@ This seal supports rotating keys defined in Google Cloud KMS
|
|||
rotation is supported for CKMS since the key information. Old keys version must not be
|
||||
disabled or deleted and are used to decrypt older data. Any new or updated data will be
|
||||
encrypted with the primary key version.
|
||||
|
||||
## Learn
|
||||
|
||||
Refer to the [Auto-unseal using GCP Cloud KMS](https://learn.hashicorp.com/vault/operations/autounseal-gcp-kms)
|
||||
guide for a step-by-step tutorial.
|
||||
|
|
|
@ -63,11 +63,11 @@ These parameters apply to the `seal` stanza in the Vault configuration file:
|
|||
Vault binary is currently running on (e.g.: a Linux system may require other
|
||||
libraries to interpret Windows .dll files).
|
||||
|
||||
- `slot` `(string: <slot or token label required>)`: The slot number to use,
|
||||
- `slot` `(string: <slot or token label required>)`: The slot number to use,
|
||||
specified as a string (e.g. `"0"`). May also be specified by the `VAULT_HSM_SLOT`
|
||||
environment variable.
|
||||
|
||||
- `token_label` `(string: <slot or token label required>)`: The slot token label to
|
||||
- `token_label` `(string: <slot or token label required>)`: The slot token label to
|
||||
use. May also be specified by the `VAULT_HSM_TOKEN_LABEL` environment variable.
|
||||
|
||||
- `pin` `(string: <required>)`: The PIN for login. May also be specified by the
|
||||
|
@ -83,8 +83,8 @@ These parameters apply to the `seal` stanza in the Vault configuration file:
|
|||
- `default_key_label` `(string: "")`: This is the default key label for decryption
|
||||
operations. Prior to 0.10.1, key labels were not stored with the ciphertext.
|
||||
Seal entries now track the label used in encryption operations. The default value
|
||||
for this field is the `key_label`. If `key_label` is rotated and this value is not
|
||||
set, decryption may fail. May also be specified by the `VAULT_HSM_DEFAULT_KEY_LABEL`
|
||||
for this field is the `key_label`. If `key_label` is rotated and this value is not
|
||||
set, decryption may fail. May also be specified by the `VAULT_HSM_DEFAULT_KEY_LABEL`
|
||||
environment variable. This value is ignored in new installations.
|
||||
|
||||
- `hmac_key_label` `(string: <required>)`: The label of the key to use for
|
||||
|
@ -97,13 +97,13 @@ These parameters apply to the `seal` stanza in the Vault configuration file:
|
|||
- `default_hmac_key_label` `(string: "")`: This is the default HMAC key label for signing
|
||||
operations. Prior to 0.10.1, HMAC key labels were not stored with the signature.
|
||||
Seal entries now track the label used in signing operations. The default value
|
||||
for this field is the `hmac_key_label`. If `hmac_key_label` is rotated and this
|
||||
value is not set, signature verification may fail. May also be specified by the
|
||||
`VAULT_HSM_HMAC_DEFAULT_KEY_LABEL` environment variable. This value is ignored in
|
||||
for this field is the `hmac_key_label`. If `hmac_key_label` is rotated and this
|
||||
value is not set, signature verification may fail. May also be specified by the
|
||||
`VAULT_HSM_HMAC_DEFAULT_KEY_LABEL` environment variable. This value is ignored in
|
||||
new installations.
|
||||
|
||||
|
||||
- `mechanism` `(string: <best available>)`: The encryption/decryption mechanism to use,
|
||||
specified as a decimal or hexadecimal (prefixed by `0x`) string. May also be
|
||||
specified as a decimal or hexadecimal (prefixed by `0x`) string. May also be
|
||||
specified by the `VAULT_HSM_MECHANISM` environment variable.
|
||||
Currently supported mechanisms (in order of precedence):
|
||||
|
||||
|
@ -132,12 +132,12 @@ These parameters apply to the `seal` stanza in the Vault configuration file:
|
|||
|
||||
- `rsa_encrypt_local` `(string: "false")`: For HSMs that do not support encryption
|
||||
for RSA keys, perform encryption locally. Available for mechanisms
|
||||
`CKM_RSA_PKCS_OAEP` and `CKM_RSA_PKCS`. May also be specified by the
|
||||
`CKM_RSA_PKCS_OAEP` and `CKM_RSA_PKCS`. May also be specified by the
|
||||
`VAULT_HSM_RSA_ENCRYPT_LOCAL` environment variable.
|
||||
|
||||
- `rsa_oaep_hash` `(string: "sha256")`: Specify the hash algorithm to use for RSA
|
||||
with OAEP padding. Valid values are sha1, sha224, sha256, sha384, and sha512.
|
||||
Available for mechanism `CKM_RSA_PKCS_OAEP`. May also be specified by the
|
||||
with OAEP padding. Valid values are sha1, sha224, sha256, sha384, and sha512.
|
||||
Available for mechanism `CKM_RSA_PKCS_OAEP`. May also be specified by the
|
||||
`VAULT_HSM_RSA_OAEP_HASH` environment variable.
|
||||
|
||||
~> **Note:** Although the configuration file allows you to pass in
|
||||
|
@ -235,9 +235,15 @@ _Private Key_
|
|||
This seal supports rotating keys by using different key labels to track key versions. To rotate
|
||||
the key value, generate a new key in a different key label in the HSM and update Vault's
|
||||
configuration with the new key label value. Restart your vault instance to pick up the new key
|
||||
label and all new encryption operations will use the updated key label. Old keys must not be disabled
|
||||
label and all new encryption operations will use the updated key label. Old keys must not be disabled
|
||||
or deleted and are used to decrypt older data.
|
||||
|
||||
**NOTE**: Prior to version 0.10.1, key information was not tracked with the ciphertext. If
|
||||
rotation is desired for data that was seal wrapped prior to this version must also set
|
||||
**NOTE**: Prior to version 0.10.1, key information was not tracked with the ciphertext. If
|
||||
rotation is desired for data that was seal wrapped prior to this version must also set
|
||||
`default_key_label` and `hmac_default_key_label` to allow for decryption of older values.
|
||||
|
||||
|
||||
## Learn
|
||||
|
||||
Refer to the [HSM Integration - Seal Wrap](https://learn.hashicorp.com/vault/operations/ops-seal-wrap)
|
||||
guide for a step-by-step tutorial.
|
||||
|
|
|
@ -116,3 +116,8 @@ path "<mount path>/decrypt/<key name>" {
|
|||
This seal supports key rotation using the Transit Secret Engine's key rotation endpoints. See
|
||||
[doc](/api/secret/transit/index.html#rotate-key). Old keys must not be disabled or deleted and are
|
||||
used to decrypt older data.
|
||||
|
||||
## Learn
|
||||
|
||||
Refer to the [Auto-unseal using Transit Secrets Engine](https://learn.hashicorp.com/vault/operations/autounseal-transit)
|
||||
guide for a step-by-step tutorial.
|
||||
|
|
|
@ -15,20 +15,20 @@ add additional authorization factors to be required before satisfying a request.
|
|||
|
||||
When a Control Group is required for a request, a limited duration response
|
||||
wrapping token is returned to the user instead of the requested data. The
|
||||
accessor of the response wrapping token can be passed to the authorizers
|
||||
accessor of the response wrapping token can be passed to the authorizers
|
||||
required by the control group policy. Once all authorizations are satisfied,
|
||||
the wrapping token can be used to unwrap and process the original request.
|
||||
|
||||
## Control Group Factors
|
||||
|
||||
Control Groups can verify the following factors:
|
||||
|
||||
|
||||
- `Identity Groups` - Require an authorizer to be in a specific set of identity
|
||||
groups.
|
||||
|
||||
## Control Groups In ACL Policies
|
||||
|
||||
Control Group requirements on paths are specified as `control_group` along
|
||||
Control Group requirements on paths are specified as `control_group` along
|
||||
with other ACL parameters.
|
||||
|
||||
### Sample ACL Policies
|
||||
|
@ -71,10 +71,10 @@ path "secret/foo" {
|
|||
}
|
||||
```
|
||||
|
||||
The above policy grants `create` and `update` access to `secret/foo` only after
|
||||
The above policy grants `create` and `update` access to `secret/foo` only after
|
||||
two member of the "managers" or "leads" group and one member of the "superusers"
|
||||
group authorizes the request. If an authorizer is a member of both the
|
||||
"managers" and "superusers" group, one authorization for both factors will be
|
||||
group authorizes the request. If an authorizer is a member of both the
|
||||
"managers" and "superusers" group, one authorization for both factors will be
|
||||
satisfied.
|
||||
|
||||
## Control Groups in Sentinel
|
||||
|
@ -113,7 +113,12 @@ The above policy will reject the request unless two members of the `managers`
|
|||
group have authorized the request. Additionally it verifies the authorizations
|
||||
happened in the last hour.
|
||||
|
||||
### API
|
||||
## Learn
|
||||
|
||||
Control Groups can be managed over the HTTP API. Please see
|
||||
Refer to the [Control Groups](https://learn.hashicorp.com/vault/identity-access-management/iam-control-groups)
|
||||
guide for a step-by-step tutorial.
|
||||
|
||||
## API
|
||||
|
||||
Control Groups can be managed over the HTTP API. Please see
|
||||
[Control Groups API](/api/system/control-group.html) for more details.
|
||||
|
|
|
@ -4,7 +4,7 @@ page_title: "Namespaces - Vault Enterprise"
|
|||
sidebar_title: "Namespaces"
|
||||
sidebar_current: "docs-vault-enterprise-namespaces"
|
||||
description: |-
|
||||
Vault Enterprise has support for Namespaces, a feature to enable Secure Multi-tenancy (SMT) and self-management.
|
||||
Vault Enterprise has support for Namespaces, a feature to enable Secure Multi-tenancy (SMT) and self-management.
|
||||
|
||||
---
|
||||
|
||||
|
@ -12,22 +12,22 @@ description: |-
|
|||
|
||||
## Overview
|
||||
|
||||
Many organizations implement Vault as a "service", providing centralized
|
||||
Many organizations implement Vault as a "service", providing centralized
|
||||
management for teams within an organization while ensuring that those teams
|
||||
operate within isolated environments known as *tenants*.
|
||||
operate within isolated environments known as *tenants*.
|
||||
|
||||
There are two common challenges when implementing this architecture in Vault:
|
||||
|
||||
**Tenant Isolation**
|
||||
|
||||
Frequently teams within a VaaS environment require strong isolation from other
|
||||
users in their policies, secrets, and identities. Tenant isolation is typically a
|
||||
result of compliance regulations such as [GDPR](https://www.eugdpr.org/), though it may
|
||||
users in their policies, secrets, and identities. Tenant isolation is typically a
|
||||
result of compliance regulations such as [GDPR](https://www.eugdpr.org/), though it may
|
||||
be necessitated by corporate or organizational infosec requirements.
|
||||
|
||||
**Self-Management**
|
||||
|
||||
As new tenants are added, there is an additional human cost in the management
|
||||
As new tenants are added, there is an additional human cost in the management
|
||||
overhead for teams. Given that tenants will likely have different policies and
|
||||
request changes at a different rate, managing a multi-tenant environment can
|
||||
become very difficult for a single team as the number of tenants within that
|
||||
|
@ -62,7 +62,7 @@ For example, these three requests are equivalent:
|
|||
|
||||
Namespaces are isolated environments that functionally exist as "Vaults within a Vault."
|
||||
They have separate login paths and support creating and managing data isolated to their
|
||||
namespace. This data includes the following:
|
||||
namespace. This data includes the following:
|
||||
|
||||
- Secret Engines
|
||||
- Auth Methods
|
||||
|
@ -72,17 +72,15 @@ namespace. This data includes the following:
|
|||
|
||||
Rather than rely on Vault system admins, namespaces can be managed by delegated admins who
|
||||
can be prescribed administration rights for their namespace. These delegated admins can also
|
||||
create their own child namespaces, thereby prescribing admin rights on a subordinate group
|
||||
of delegate admins.
|
||||
create their own child namespaces, thereby prescribing admin rights on a subordinate group
|
||||
of delegate admins.
|
||||
|
||||
Child namespaces can share policies from their parent namespaces. For example, a child namespace
|
||||
may refer to parent identities (entities and groups) when writing policies that function only
|
||||
within that child namespace. Similarly, a parent namespace can have policies asserted on child
|
||||
identities.
|
||||
identities.
|
||||
|
||||
## Setup and Best Practices
|
||||
|
||||
A [deployment guide](/guides/operations/multi-tenant.html) is available to help guide you
|
||||
through the deployment and administration of namespaces, and contains examples on architecture
|
||||
for using namespaces to implement SMT across your organization.
|
||||
## Learn
|
||||
|
||||
Refer to the [Secure Multi-Tenancy with Namespaces](https://learn.hashicorp.com/vault/operations/namespaces)
|
||||
guide for a step-by-step tutorial.
|
||||
|
|
|
@ -135,11 +135,15 @@ generation until it is used.
|
|||
Once a secondary is activated, its cluster information is stored safely behind
|
||||
its encrypted barrier.
|
||||
|
||||
## Setup and Best Practices
|
||||
|
||||
A [setup guide](/guides/operations/replication.html) is
|
||||
available to help you get started; this guide also contains best practices
|
||||
around operationalizing the replication feature.
|
||||
## Learn
|
||||
|
||||
Refer to the following tutorials replication setup and best practices:
|
||||
|
||||
- [Setting up Performance Replication](https://learn.hashicorp.com/vault/operations/ops-replication)
|
||||
- [Disaster Recovery Replication Setup](https://learn.hashicorp.com/vault/operations/ops-disaster-recovery)
|
||||
- [Performance Replication with Mount Filters](https://learn.hashicorp.com/vault/operations/mount-filter)
|
||||
- [Monitoring Vault Replication](https://learn.hashicorp.com/vault/operations/monitor-replication)
|
||||
|
||||
## API
|
||||
|
||||
|
|
|
@ -111,3 +111,8 @@ See the [Examples](/docs/enterprise/sentinel/examples.html) page for examples
|
|||
of Sentinel in action, and the
|
||||
[Properties](/docs/enterprise/sentinel/properties.html) page for detailed
|
||||
property documentation.
|
||||
|
||||
## Learn
|
||||
|
||||
Refer to the [Sentinel Policies](https://learn.hashicorp.com/vault/identity-access-management/iam-sentinel)
|
||||
guide for a step-by-step tutorial.
|
||||
|
|
|
@ -229,6 +229,11 @@ Vault releases, but the code is managed separately.
|
|||
Please report issues, add feature requests, and submit contributions to the
|
||||
[vault-plugin-secrets-azure repo][repo] on GitHub.
|
||||
|
||||
## Learn
|
||||
|
||||
Refer to the [Azure Secrets
|
||||
Engine](https://learn.hashicorp.com/vault/secrets-management/azure-creds) guide
|
||||
for a step-by-step tutorial.
|
||||
|
||||
## API
|
||||
The Azure secrets engine has a full HTTP API. Please see the [Azure secrets engine API docs][api]
|
||||
|
|
|
@ -52,6 +52,11 @@ engine allows for writing keys with arbitrary values.
|
|||
my-value s3cr3t
|
||||
```
|
||||
|
||||
## Learn
|
||||
|
||||
Refer to the [Cubbyhole Response Wrapping](https://learn.hashicorp.com/vault/secrets-management/sm-cubbyhole)
|
||||
guide for a step-by-step tutorial.
|
||||
|
||||
## API
|
||||
|
||||
The Cubbyhole secrets engine has a full HTTP API. Please see the
|
||||
|
|
|
@ -107,6 +107,7 @@ of the role:
|
|||
password 8cab931c-d62e-a73d-60d3-5ee85139cd66
|
||||
username v-root-e2978cd0-
|
||||
```
|
||||
|
||||
## Custom Plugins
|
||||
|
||||
This secrets engine allows custom database types to be run through the exposed
|
||||
|
@ -119,6 +120,14 @@ Password generation for both static and dynamic database credentials occurs via
|
|||
|
||||
Please see the [DB plugin credentials source code](https://github.com/hashicorp/vault/blob/master/sdk/database/dbplugin/database.pb.go) for more information.
|
||||
|
||||
## Learn
|
||||
|
||||
Refer to the following step-by-step tutorials for more information:
|
||||
|
||||
- [Secrets as a Service: Dynamic Secrets](https://learn.hashicorp.com/vault/secrets-management/sm-dynamic-secrets)
|
||||
- [Database Root Credential Rotation](https://learn.hashicorp.com/vault/secrets-management/db-root-rotation)
|
||||
- [Database Static Roles and Credential Rotation](https://learn.hashicorp.com/vault/secrets-management/db-creds-rotation)
|
||||
|
||||
## API
|
||||
|
||||
The database secrets engine has a full HTTP API. Please see the [Database secret
|
||||
|
|
|
@ -20,7 +20,7 @@ its storage and lifecycle to a key management server.
|
|||
## Setup
|
||||
|
||||
The KMIP secrets engine must be configured before it can start accepting KMIP
|
||||
requests.
|
||||
requests.
|
||||
|
||||
1. Enable the KMIP secrets engine
|
||||
|
||||
|
@ -33,7 +33,7 @@ requests.
|
|||
TLS parameters, or leave unwritten to use default values
|
||||
|
||||
```text
|
||||
$ vault write kmip/config listen_addrs=0.0.0.0:5696
|
||||
$ vault write kmip/config listen_addrs=0.0.0.0:5696
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
@ -56,15 +56,15 @@ allowed operations for it.
|
|||
$ vault write -f kmip/scope/my-service
|
||||
Success! Data written to: kmip/scope/my-service
|
||||
```
|
||||
|
||||
|
||||
1. Create a role within the scope, specifying the set of operations to allow or
|
||||
deny.
|
||||
|
||||
```text
|
||||
$ vault write kmip/scope/my-service/role/admin operation_all=true
|
||||
$ vault write kmip/scope/my-service/role/admin operation_all=true
|
||||
Success! Data written to: kmip/scope/my-service/role/admin
|
||||
```
|
||||
|
||||
|
||||
### Client Certificate Generation
|
||||
|
||||
Once a scope and role has been created, client certificates can be generated for
|
||||
|
@ -165,5 +165,11 @@ operation_all
|
|||
operation_none
|
||||
```
|
||||
|
||||
## Learn
|
||||
|
||||
Refer to the [KMIP Secrets Engine](https://learn.hashicorp.com/vault/secrets-management/kmip-engine)
|
||||
guide for a step-by-step tutorial.
|
||||
|
||||
|
||||
[kmip-spec]: http://docs.oasis-open.org/kmip/spec/v1.4/kmip-spec-v1.4.html
|
||||
[kmip-ops]: http://docs.oasis-open.org/kmip/spec/v1.4/os/kmip-spec-v1.4-os.html#_Toc490660840
|
||||
|
|
|
@ -101,6 +101,12 @@ my-value s3cr3t
|
|||
ttl 30m
|
||||
```
|
||||
|
||||
## Learn
|
||||
|
||||
Refer to the [Static Secrets: Key/Value Secrets
|
||||
Engine](https://learn.hashicorp.com/vault/secrets-management/sm-static-secrets)
|
||||
guide for a step-by-step tutorial.
|
||||
|
||||
## API
|
||||
|
||||
The KV secrets engine has a full HTTP API. Please see the
|
||||
|
|
|
@ -394,6 +394,12 @@ See the commands below for more information:
|
|||
Success! Data deleted (if it existed) at: secret/metadata/my-secret
|
||||
```
|
||||
|
||||
## Learn
|
||||
|
||||
Refer to the [Versioned Key/Value Secrets
|
||||
Engine](https://learn.hashicorp.com/vault/secrets-management/sm-versioned-kv)
|
||||
guide for a step-by-step tutorial.
|
||||
|
||||
## API
|
||||
|
||||
The KV secrets engine has a full HTTP API. Please see the
|
||||
|
|
|
@ -674,6 +674,11 @@ The CA Chain returns all the intermediate authorities in the trust chain. The ro
|
|||
authority is not included since that will usually be trusted by the underlying
|
||||
OS.
|
||||
|
||||
## Learn
|
||||
|
||||
Refer to the [Build Your Own Certificate Authority (CA)](https://learn.hashicorp.com/vault/secrets-management/sm-pki-engine)
|
||||
guide for a step-by-step tutorial.
|
||||
|
||||
## API
|
||||
|
||||
The PKI secrets engine has a full HTTP API. Please see the
|
||||
|
|
|
@ -109,6 +109,12 @@ username@<IP of remote host>:~$
|
|||
Note: `sshpass` cannot handle host key checking. Host key checking can be
|
||||
disabled by setting `-strict-host-key-checking=no`.
|
||||
|
||||
## Learn
|
||||
|
||||
Refer to the [SSH Secrets Engine: One-Time SSH
|
||||
Password](https://learn.hashicorp.com/vault/secrets-management/sm-ssh-otp) guide
|
||||
for a step-by-step tutorial.
|
||||
|
||||
## API
|
||||
|
||||
The SSH secrets engine has a full HTTP API. Please see the
|
||||
|
|
|
@ -208,6 +208,12 @@ plaintext with the newest key in the keyring.
|
|||
data, since the process would not be able to get access to the plaintext
|
||||
data.
|
||||
|
||||
## Learn
|
||||
|
||||
Refer to the [Encryption as a Service: Transit Secrets
|
||||
Engine](https://learn.hashicorp.com/vault/encryption-as-a-service/eaas-transit)
|
||||
guide for a step-by-step tutorial.
|
||||
|
||||
## API
|
||||
|
||||
The Transit secrets engine has a full HTTP API. Please see the
|
||||
|
|
Loading…
Reference in New Issue