Added links to matching learn guide (#7636)

This commit is contained in:
Yoko 2019-10-14 10:31:03 -07:00 committed by GitHub
parent b3d53e4ef2
commit dbdf65e5bc
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
23 changed files with 192 additions and 74 deletions

View File

@ -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.

View File

@ -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.

View File

@ -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.

View File

@ -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

View File

@ -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)

View File

@ -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.

View File

@ -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.

View File

@ -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.

View File

@ -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.

View File

@ -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.

View File

@ -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.

View File

@ -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.

View File

@ -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

View File

@ -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.

View File

@ -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]

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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