Fixing docs links and adding redirects for new guides (#3939)
* updating links * updating links * updating links * updating links * updating links * adding redirects
This commit is contained in:
parent
4d674b978b
commit
d723479b32
|
@ -68,10 +68,11 @@
|
|||
/docs/http/sys-rotate.html /api/system/rotate.html
|
||||
/docs/http/sys-raw.html /api/system/raw.html
|
||||
/docs/http/sys-health.html /api/system/health.html
|
||||
/docs/guides/generate-root.html /guides/generate-root.html
|
||||
|
||||
/docs/guides/generate-root.html /guides/configuration/generate-root.html
|
||||
/docs/guides/index.html /guides/index.html
|
||||
/docs/guides/production.html /guides/production.html
|
||||
/docs/guides/replication.html /guides/replication.html
|
||||
/docs/guides/production.html /guides/operations/production.html
|
||||
/docs/guides/replication.html /guides/operations/replication.html
|
||||
/docs/guides/upgrading/index.html /guides/upgrading/index.html
|
||||
/docs/guides/upgrading/upgrade-to-0.5.0.html /guides/upgrading/upgrade-to-0.5.0.html
|
||||
/docs/guides/upgrading/upgrade-to-0.5.1.html /guides/upgrading/upgrade-to-0.5.1.html
|
||||
|
@ -81,6 +82,17 @@
|
|||
/docs/guides/upgrading/upgrade-to-0.6.3.html /guides/upgrading/upgrade-to-0.6.3.html
|
||||
/docs/guides/upgrading/upgrade-to-0.6.4.html /guides/upgrading/upgrade-to-0.6.4.html
|
||||
/docs/guides/upgrading/upgrade-to-0.7.0.html /guides/upgrading/upgrade-to-0.7.0.html
|
||||
/guides/production.html /guides/operations/production.html
|
||||
/guides/replication.html /guides/operations/replication.html
|
||||
/guides/policies.html /guides/configuration/policies.html
|
||||
/guides/authentication.html /guides/configuration/authentication.html
|
||||
/guides/lease.html /guides/configuration/lease.html
|
||||
/guides/generate-root.html /guides/configuration/generate-root.html
|
||||
/guides/rekeying-and-rotating.html /guides/configuration/rekeying-and-rotating.html
|
||||
/guides/plugin-backends.html /guides/configuration/plugin-backends.html
|
||||
/guides/static-secrets.html /guides/secret-mgmt/static-secrets.html
|
||||
/guides/dynamic-secret.html /guides/secret-mgmt/dynamic-secret.html
|
||||
/guides/cubbyhole.html /guides/secret-mgmt/cubbyhole.html
|
||||
/docs/secrets/custom.html /docs/plugin/index.html
|
||||
/docs/secrets/generic/index.html /docs/secrets/kv/index.html
|
||||
/intro/getting-started/acl.html /intro/getting-started/policies.html
|
||||
|
|
|
@ -26,7 +26,7 @@ An unseal key may be provided directly on the command line as an argument to the
|
|||
command. If key is specified as "-", the command will read from stdin. If a TTY
|
||||
is available, the command will prompt for text.
|
||||
|
||||
Please see the [generate root guide](/guides/generate-root.html) for
|
||||
Please see the [generate root guide](/guides/configuration/generate-root.html) for
|
||||
step-by-step instructions.
|
||||
|
||||
## Examples
|
||||
|
|
|
@ -22,7 +22,7 @@ An unseal key may be provided directly on the command line as an argument to the
|
|||
command. If key is specified as "-", the command will read from stdin. If a TTY
|
||||
is available, the command will prompt for text.
|
||||
|
||||
Please see the [rotating and rekeying](/guides/rekeying-and-rotating.html) for
|
||||
Please see the [rotating and rekeying](/guides/configuration/rekeying-and-rotating.html) for
|
||||
step-by-step instructions.
|
||||
|
||||
## Examples
|
||||
|
|
|
@ -437,8 +437,8 @@ $ curl \
|
|||
|
||||
For more information, please read:
|
||||
|
||||
- [Production Hardening](/guides/production.html)
|
||||
- [Generating a Root Token](/guides/generate-root.html)
|
||||
- [Production Hardening](/guides/operations/production.html)
|
||||
- [Generating a Root Token](/guides/configuration/generate-root.html)
|
||||
|
||||
## Managing Policies
|
||||
|
||||
|
|
|
@ -54,7 +54,7 @@ of version 0.6.1, there are only three ways to create root tokens:
|
|||
expiration
|
||||
2. By using another root token; a root token with an expiration cannot create a
|
||||
root token that never expires
|
||||
3. By using `vault generate-root` ([example](/guides/generate-root.html))
|
||||
3. By using `vault generate-root` ([example](/guides/configuration/generate-root.html))
|
||||
with the permission of a quorum of unseal key holders
|
||||
|
||||
Root tokens are useful in development but should be extremely carefully guarded
|
||||
|
|
|
@ -134,7 +134,7 @@ its encrypted barrier.
|
|||
|
||||
## Setup and Best Practices
|
||||
|
||||
A [setup guide](/guides/replication.html) is
|
||||
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.
|
||||
|
||||
|
|
|
@ -36,7 +36,7 @@ enabling the [**AppRole**](/docs/auth/approle.html) auth backend.
|
|||
## Reference Material
|
||||
|
||||
- [Getting Started](/intro/getting-started/authentication.html)
|
||||
- [Auth Backends](docs/auth/index.html)
|
||||
- [Auth Backends](/docs/auth/index.html)
|
||||
- [GitHub Auth APIs](/api/auth/github/index.html)
|
||||
|
||||
|
||||
|
@ -123,7 +123,7 @@ path "secret/mysql/*" {
|
|||
```
|
||||
|
||||
If you are not familiar with policies, complete the
|
||||
[policies](/guides/policies.html) guide.
|
||||
[policies](/guides/configuration/policies.html) guide.
|
||||
|
||||
|
||||
## Steps
|
||||
|
@ -133,7 +133,7 @@ to allow machines or apps to acquire a token to interact with Vault. It uses
|
|||
**Role ID** and **Secret ID** for login.
|
||||
|
||||
The basic workflow is:
|
||||
![AppRole auth backend workflow](assets/images/vault-approle-workflow.png)
|
||||
![AppRole auth backend workflow](/assets/images/vault-approle-workflow.png)
|
||||
|
||||
> For the purpose of introducing the basics of AppRole, this guide walks you
|
||||
> through a very simple scenario involving only two personas (admin and app).
|
||||
|
@ -235,7 +235,7 @@ $ vault write auth/approle/role/<ROLE_NAME> [parameters]
|
|||
> specify `token_num_uses` and `token_ttl`. You may never want the app token to
|
||||
> expire. In such a case, specify the `period` so that the token generated by
|
||||
> this AppRole is a periodic token. To learn more about periodic token, refer to
|
||||
> the [Tokens and Leases](/guifes/lease.html#step4) guide.
|
||||
> the [Tokens and Leases](/guides/configuration/lease.html#step4) guide.
|
||||
|
||||
**Example:**
|
||||
|
||||
|
@ -304,7 +304,7 @@ $ curl --header "X-Vault-Token: ..." --request POST \
|
|||
> specify `token_num_uses` and `token_ttl`. You may never want the app token to
|
||||
> expire. In such a case, specify the `period` so that the token generated by
|
||||
> this AppRole is a periodic token. To learn more about periodic token, refer to
|
||||
> the [Tokens and Leases](/guifes/lease.html#step4) guide.
|
||||
> the [Tokens and Leases](/guides/configuration/lease.html#step4) guide.
|
||||
|
||||
|
||||
**NOTE:** To attach multiple policies, pass the policy names as a comma
|
||||
|
@ -617,7 +617,7 @@ For example, Terraform as a trusted entity can deliver the Role ID onto the
|
|||
virtual machine. When the app runs on the virtual machine, the Role ID already
|
||||
exists on the virtual machine.
|
||||
|
||||
![AppRole auth backend workflow](assets/images/vault-approle-workflow2.png)
|
||||
![AppRole auth backend workflow](/assets/images/vault-approle-workflow2.png)
|
||||
|
||||
Secret ID is like a password. To keep the Secret ID confidential, use
|
||||
[**response wrapping**](/docs/concepts/response-wrapping.html) so that the only
|
||||
|
@ -668,4 +668,4 @@ b07d7a47-1d0d-741d-20b4-ae0de7c6d964
|
|||
## Next steps
|
||||
|
||||
To learn more about response wrapping, go to [Cubbyhole Response
|
||||
Wrapping](/guides/cubbyhole.html) guide.
|
||||
Wrapping](/guides/secret-mgmt/cubbyhole.html) guide.
|
||||
|
|
|
@ -41,8 +41,8 @@ two hours later, `b519c6aa...` will be revoked and takes its child
|
|||
|
||||
## Reference Material
|
||||
|
||||
- The [Validation](/guides/dynamic-secrets.html#validation) section of the
|
||||
[Secret as a Service](/guides/dynamic-secrets.html) guide demonstrated lease
|
||||
- The [Validation](/guides/secret-mgmt/dynamic-secrets.html#validation) section of the
|
||||
[Secret as a Service](/guides/secret-mgmt/dynamic-secrets.html) guide demonstrated lease
|
||||
renewal and revocation
|
||||
- [Tokens documentation](/docs/concepts/tokens.html)
|
||||
- [Token Auth Backend HTTP API](/api/auth/token/index.html)
|
||||
|
@ -131,7 +131,7 @@ path "sys/mounts/database/tune" {
|
|||
```
|
||||
|
||||
If you are not familiar with policies, complete the
|
||||
[policies](/guides/policies.html) guide.
|
||||
[policies](/guides/configuration/policies.html) guide.
|
||||
|
||||
|
||||
## Steps
|
||||
|
@ -625,7 +625,7 @@ are talking about long-running apps need to be able to renew its token
|
|||
indefinitely.
|
||||
|
||||
-> For more details about AppRole, read the [AppRole Pull
|
||||
-Authentication](/guides/authentication.html) guide.
|
||||
-Authentication](/guides/configuration/authentication.html) guide.
|
||||
|
||||
To create AppRole periodic tokens, create your AppRole role with
|
||||
`period` specified.
|
||||
|
@ -803,5 +803,5 @@ renewable true
|
|||
## Next steps
|
||||
|
||||
Now you have learned the lifecycle of tokens and leases, read [AppRole Pull
|
||||
Authentication](/guides/authentication.html) guide to learn how to generate
|
||||
Authentication](/guides/configuration/authentication.html) guide to learn how to generate
|
||||
tokens for apps or machines.
|
||||
|
|
|
@ -584,5 +584,5 @@ $ curl --request POST --header "X-Vault-Token: ..." --data '{"path":"sys/auth/ap
|
|||
## Next steps
|
||||
|
||||
In this guide, you learned how to write policies based on given policy
|
||||
requirements. Next, [AppRole Pull Authentication](/guides/authentication.html)
|
||||
requirements. Next, [AppRole Pull Authentication](/guides/configuration/authentication.html)
|
||||
guide demonstrates how to associate policies to a role.
|
||||
|
|
|
@ -13,11 +13,11 @@ Vault Operations guides address Vault infrastructure discussions. These
|
|||
guides are designed to help the operations team to plan and install a Vault
|
||||
cluster that meets your organization's needs.
|
||||
|
||||
- [Production Hardening](/guides/architecture/production.html) guide provides
|
||||
- [Production Hardening](/guides/operations/production.html) guide provides
|
||||
guidance on best practices for a production hardened deployment of Vault.
|
||||
The recommendations are based on the [security model](/docs/internals/security.html)
|
||||
and focus on defense in depth.
|
||||
- [Replication Setup & Guidance](/guides/architecture/replication.html)
|
||||
- [Replication Setup & Guidance](/guides/operations/replication.html)
|
||||
walks you through the commands to activate the Vault servers in replication mode.
|
||||
Please note that [Vault Replication](/docs/vault-enterprise/replication/index.html)
|
||||
is a Vault Enterprise feature.
|
||||
|
|
|
@ -81,7 +81,7 @@ and practical.
|
|||
code](https://www.hashicorp.com/blog/codifying-vault-policies-and-configuration/),
|
||||
and using version control to manage policies. Once setup, the root token
|
||||
should be revoked to eliminate the risk of exposure. Root tokens can be
|
||||
[generated when needed](/guides/generate-root.html), and should be
|
||||
[generated when needed](/guides/configuration/generate-root.html), and should be
|
||||
revoked as soon as possible.
|
||||
|
||||
* **Enable Auditing**. Vault supports several auditing backends. Enabling
|
||||
|
|
|
@ -111,7 +111,7 @@ uses cubbyhole response wrapping. In this guide, you perform the following:
|
|||
|
||||
**NOTE:** This guide demonstrates how the response wrapping works. To learn more
|
||||
about reading and writing secrets in Vault, refer to the [Static
|
||||
Secret](/guide/static-secrets.html) guide.
|
||||
Secret](/guides/secret-mgmt/static-secrets.html) guide.
|
||||
|
||||
### <a name="step1"></a>Step 1: Create and wrap a token
|
||||
(**Persona:** admin)
|
||||
|
@ -539,7 +539,7 @@ Also, refer to [Cubbyhole Secret Backend HTTP API](/api/secret/cubbyhole/index.h
|
|||
|
||||
## Next steps
|
||||
|
||||
The use of [AppRole Pull Authentication](/guides/authentication.html) is a good
|
||||
The use of [AppRole Pull Authentication](/guides/configuration/authentication.html) is a good
|
||||
use case to leverage the response wrapping. Go through the guide if you have not
|
||||
done so. To better understand the lifecycle of Vault tokens, proceed to [Tokens
|
||||
and Leases](/guides/lease.html) guide.
|
||||
and Leases](/guides/configuration/lease.html) guide.
|
||||
|
|
|
@ -50,7 +50,7 @@ environment variables. The administrator specifies the TTL of the database
|
|||
credentials to enforce its validity so that they are automatically revoked when
|
||||
they are no longer used.
|
||||
|
||||
![Dynamic Secret Workflow](assets/images/vault-dynamic-secrets.png)
|
||||
![Dynamic Secret Workflow](/assets/images/vault-dynamic-secrets.png)
|
||||
|
||||
Each app instance can get unique credentials that they don't have to share. By
|
||||
making those credentials to be short-lived, you reduced the change of the secret
|
||||
|
@ -124,7 +124,7 @@ path "auth/token/create" {
|
|||
```
|
||||
|
||||
If you are not familiar with policies, complete the
|
||||
[policies](/guides/policies.html) guide.
|
||||
[policies](/guides/configuration/policies.html) guide.
|
||||
|
||||
## Steps
|
||||
|
||||
|
@ -338,7 +338,7 @@ token_policies [apps default]
|
|||
|
||||
Use the returned token to perform the remaining.
|
||||
|
||||
**NOTE:** [AppRole Pull Authentication](/guides/authentication.html) guide
|
||||
**NOTE:** [AppRole Pull Authentication](/guides/configuration/authentication.html) guide
|
||||
demonstrates more sophisticated way of generating a token for your apps.
|
||||
|
||||
```shell
|
||||
|
@ -412,7 +412,7 @@ $ curl --header "X-Vault-Token: ..." --request POST \
|
|||
|
||||
Be sure to use the returned token to perform the remaining.
|
||||
|
||||
**NOTE:** [AppRole Pull Authentication](/guides/authentication.html) guide
|
||||
**NOTE:** [AppRole Pull Authentication](/guides/configuration/authentication.html) guide
|
||||
demonstrates more sophisticated way of generating a token for your apps.
|
||||
|
||||
```shell
|
||||
|
@ -498,5 +498,5 @@ user name exists.
|
|||
|
||||
This guide discussed how to generate credentials on--dataemand so that the access
|
||||
credentials no longer need to be written to disk. Next, learn about the
|
||||
[Tokens and Leases](/guides/lease.html) so that you can control the lifecycle of
|
||||
[Tokens and Leases](/guides/configuration/lease.html) so that you can control the lifecycle of
|
||||
those credentials.
|
||||
|
|
|
@ -20,8 +20,8 @@ Secret Storage.
|
|||
## Reference Material
|
||||
|
||||
- [Key/Value Secret Backend](/docs/secrets/kv/index.html)
|
||||
- [Key/Value Secret Backend API](/apikey/secret/kv/index.html)
|
||||
- [Client libraries](/apikey/libraries.html) for Vault API for commonly used languages
|
||||
- [Key/Value Secret Backend API](/api/secret/kv/index.html)
|
||||
- [Client libraries](/api/libraries.html) for Vault API for commonly used languages
|
||||
|
||||
## Estimated Time to Complete
|
||||
|
||||
|
@ -94,7 +94,7 @@ path "auth/token/create" {
|
|||
```
|
||||
|
||||
If you are not familiar with policies, complete the
|
||||
[policies](/guides/policies.html) guide.
|
||||
[policies](/guides/configuration/policies.html) guide.
|
||||
|
||||
|
||||
## Steps
|
||||
|
@ -545,5 +545,5 @@ $ cat mongodb.txt
|
|||
This guide introduced the CLI commands and API endpoints to read and write
|
||||
secrets in key/value backend. To keep it simple, the `devops` persona generated a
|
||||
token for `apps`. Read [AppRole Pull
|
||||
Authentication](/guides/authentication.html) guide to learn about
|
||||
Authentication](/guides/configuration/authentication.html) guide to learn about
|
||||
programmatically generate a token for apps.
|
||||
|
|
Loading…
Reference in a new issue