mirror of
https://github.com/optim-enterprises-bv/vault.git
synced 2025-10-30 18:17:55 +00:00
Fix some typos (#12289)
This commit is contained in:
Rémi Lapeyre
@@ -11,7 +11,7 @@ import filesize from 'filesize';
|
||||
* <FileToArrayBuffer @onChange={{action (mut file)}} />
|
||||
* ```
|
||||
* @param onChange=null {Function} - The function to call when the file read is complete. This function
|
||||
* recieves the file as a JS ArrayBuffer
|
||||
* receives the file as a JS ArrayBuffer
|
||||
* @param [label=null {String}] - Text to use as the label for the file input
|
||||
* @param [fileHelpText=null {String} - Text to use as help under the file input
|
||||
*
|
||||
|
||||
@@ -15,7 +15,7 @@ import layout from '../templates/components/form-save-buttons';
|
||||
* @param [cancelButtonText="Cancel" {String}] - The text that will be rendered on the Cancel button.
|
||||
* @param [isSaving=false {Boolean}] - If the form is saving, this should be true. This will disable the save button and render a spinner on it;
|
||||
* @param [cancelLinkParams=[] {Array}] - An array of arguments used to construct a link to navigate back to when the Cancel button is clicked.
|
||||
* @param [onCancel=null {Fuction}] - If the form should call an action on cancel instead of route somewhere, the fucntion can be passed using onCancel instead of passing an array to cancelLinkParams.
|
||||
* @param [onCancel=null {Function}] - If the form should call an action on cancel instead of route somewhere, the function can be passed using onCancel instead of passing an array to cancelLinkParams.
|
||||
* @param [includeBox=true {Boolean}] - By default we include padding around the form with underlines. Passing this value as false will remove that padding.
|
||||
*
|
||||
*/
|
||||
|
||||
@@ -5,7 +5,7 @@ import layout from '../templates/components/list-view';
|
||||
|
||||
/**
|
||||
* @module ListView
|
||||
* `ListView` components are used in conjuction with `ListItem` for rendering a list.
|
||||
* `ListView` components are used in conjunction with `ListItem` for rendering a list.
|
||||
*
|
||||
* @example
|
||||
* ```js
|
||||
|
||||
@@ -10,7 +10,7 @@
|
||||
| [saveButtonText] | <code>String</code> | <code>"Save"</code> | The text that will be rendered on the Save button. |
|
||||
| [isSaving] | <code>Boolean</code> | <code>false</code> | If the form is saving, this should be true. This will disable the save button and render a spinner on it; |
|
||||
| [cancelLinkParams] | <code>Array</code> | <code>[]</code> | An array of arguments used to construct a link to navigate back to when the Cancel button is clicked. |
|
||||
| [onCancel] | <code>Fuction</code> | <code></code> | If the form should call an action on cancel instead of route somewhere, the fucntion can be passed using onCancel instead of passing an array to cancelLinkParams. |
|
||||
| [onCancel] | <code>Function</code> | <code></code> | If the form should call an action on cancel instead of route somewhere, the function can be passed using onCancel instead of passing an array to cancelLinkParams. |
|
||||
| [includeBox] | <code>Boolean</code> | <code>true</code> | By default we include padding around the form with underlines. Passing this value as false will remove that padding. |
|
||||
|
||||
**Example**
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
<!--THIS FILE IS AUTO GENERATED. This file is generated from JSDoc comments in lib/core/addon/components/list-view.js. To make changes, first edit that file and run "yarn gen-story-md list-view" to re-generate the content.-->
|
||||
|
||||
## ListView
|
||||
`ListView` components are used in conjuction with `ListItem` for rendering a list.
|
||||
`ListView` components are used in conjunction with `ListItem` for rendering a list.
|
||||
|
||||
|
||||
| Param | Type | Default | Description |
|
||||
|
||||
@@ -8,7 +8,7 @@ loaded, this file will be emitted as a JS ArrayBuffer to the passed `onChange` c
|
||||
|
||||
| Param | Type | Default | Description |
|
||||
| --- | --- | --- | --- |
|
||||
| onChange | <code>function</code> | <code></code> | The function to call when the file read is complete. This function recieves the file as a JS ArrayBuffer |
|
||||
| onChange | <code>function</code> | <code></code> | The function to call when the file read is complete. This function receives the file as a JS ArrayBuffer |
|
||||
| [label] | <code>String</code> | <code></code> | Text to use as the label for the file input |
|
||||
| fileHelpText | <code>String</code> | <code></code> | Text to use as help under the file input |
|
||||
|
||||
|
||||
@@ -100,7 +100,7 @@ There are several custom markdown plugins that are available by default that enh
|
||||
- If you see `# Headline ((#slug))`, this is an example of an [anchor link alias](https://github.com/hashicorp/remark-plugins/tree/je.anchor-link-adjustments/plugins/anchor-links#anchor-link-aliases). It adds an extra permalink to a headline for compatibility and is removed from the output.
|
||||
- Due to [automatically generated permalinks](https://github.com/hashicorp/remark-plugins/tree/je.anchor-link-adjustments/plugins/anchor-links#anchor-links), any text changes to _headlines_ or _list items that begin with inline code_ can and will break existing permalinks. Be very cautious when changing either of these two text items.
|
||||
|
||||
Headlines are fairly self-explanitory, but here's an example of how list items that begin with inline code look.
|
||||
Headlines are fairly self-explanatory, but here's an example of how list items that begin with inline code look.
|
||||
|
||||
```markdown
|
||||
- this is a normal list item
|
||||
@@ -126,7 +126,7 @@ The `Tabs` component creates tabbed content of any type, but is often used for c
|
||||
|
||||
|
||||
|
||||
> Please refer to the [Swingset](https://react-components.vercel.app/?component=Tabs) documention for the latest examples and API reference.
|
||||
> Please refer to the [Swingset](https://react-components.vercel.app/?component=Tabs) documentation for the latest examples and API reference.
|
||||
|
||||
It can be used as such within a markdown file:
|
||||
|
||||
@@ -150,7 +150,7 @@ $ curl ...
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
Contined normal markdown content
|
||||
Continued normal markdown content
|
||||
````
|
||||
|
||||
The intentionally skipped line is a limitation of the mdx parser which is being actively worked on. All tabs must have a heading, and there is no limit to the number of tabs, though it is recommended to go for a maximum of three or four.
|
||||
@@ -404,7 +404,7 @@ This configuration would display something like the following text on the websit
|
||||
A {{ release candidate }} for <Product> {{ v1.0.0 }} is available! The release can be <a href='https://releases.hashicorp.com/<product>/{{ 1.0.0-rc1 }}'>downloaded here</a>.
|
||||
```
|
||||
|
||||
You may customize the parameters in any way you'd like. To remove a prerelease from the website, simply delete the `prerelease` paremeter from the above component.
|
||||
You may customize the parameters in any way you'd like. To remove a prerelease from the website, simply delete the `prerelease` parameter from the above component.
|
||||
|
||||
<!-- END: releases -->
|
||||
|
||||
@@ -448,7 +448,7 @@ One more example - let's say that content is being moved to an external website.
|
||||
}
|
||||
```
|
||||
|
||||
If we no longer want the link to be in the side nav, we can simply remove it. If we do still want the link in the side nav, but pointing to an external destnation, we need to slightly change the structure as such:
|
||||
If we no longer want the link to be in the side nav, we can simply remove it. If we do still want the link in the side nav, but pointing to an external destination, we need to slightly change the structure as such:
|
||||
|
||||
```js
|
||||
{
|
||||
|
||||
@@ -344,9 +344,9 @@ against any bound claims, and if valid a Vault token will be returned.
|
||||
### Parameters
|
||||
|
||||
- `state` `(string: <required>)` - Opaque state ID that is part of the Authorization URL and will
|
||||
be included in the the redirect following successful authenication on the provider.
|
||||
be included in the the redirect following successful authentication on the provider.
|
||||
- `nonce` `(string: <required>)` - Opaque nonce that is part of the Authorization URL and will
|
||||
be included in the the redirect following successful authenication on the provider.
|
||||
be included in the the redirect following successful authentication on the provider.
|
||||
- `code` `(string: <required>)` - Provider-generated authorization code that Vault will exchange for
|
||||
an ID token.
|
||||
|
||||
|
||||
@@ -80,7 +80,7 @@ API](/api/secret/databases#create-role) in the database secrets engine docs.
|
||||
The following are the statements used by this plugin. If not mentioned in this
|
||||
list the plugin does not support that statement type.
|
||||
|
||||
- `creation_statements` `(llist: <required>)` – Specifies the database
|
||||
- `creation_statements` `(list: <required>)` – Specifies the database
|
||||
statements executed to create and configure a user. Must be a
|
||||
semicolon-separated string, a base64-encoded semicolon-separated string, a
|
||||
serialized JSON string array, or a base64-encoded serialized JSON string
|
||||
|
||||
@@ -27,7 +27,7 @@ This endpoint reloads mounted plugin backends.
|
||||
- `mounts` `(array: [])` – Array or comma-separated string mount paths
|
||||
of the plugin backends to reload.
|
||||
|
||||
- `scope` `(string: "")` - The scope of the reload. If ommitted, reloads the
|
||||
- `scope` `(string: "")` - The scope of the reload. If omitted, reloads the
|
||||
plugin or mounts on this Vault instance. If 'global', will begin reloading the
|
||||
plugin on all instances of a cluster.
|
||||
|
||||
|
||||
@@ -23,8 +23,8 @@ There can be many different types of clients that authenticate and communicate w
|
||||
1. **[Human users](https://learn.hashicorp.com/tutorials/vault/pattern-centralized-secrets?in=vault/recommended-patterns#human-authentication):** GitHub ID, username/password, LDAP, Active Directory, Kerberos, JWT/ OIDC claims, OKTA
|
||||
2. **Applications or Microservices:** 2-Factor Authentication methods such as AppRole, or by LDAP, Active Directory, or based on the platform’s identity, such as credentials from AWS, Azure, GCP, AliCloud, OCI, Kubernetes, Cloud Foundry, etc.
|
||||
3. **[Servers and Platforms](https://learn.hashicorp.com/tutorials/vault/pattern-centralized-secrets?in=vault/recommended-patterns#machine-programmatic-authentication):** VMs, Containers, Pods (Identified by LDAP, Active Directory service accounts, AWS, Azure, GCP, AliCloud, OCI, Kubernetes, TLS Certs
|
||||
4. **Orchestrators:** Nomad, Terraform, Ansible, or Continuous Integration Continuous Delivery (CI/CD) Pipelines where each pipeline usually identified by 2FA methods, App Role, or platform based identity
|
||||
5. **[Vault Agents](/docs/agent/autoauth):** acting on behalf of a app/microsevice, typically identified by App role, Cloud credentials, Kubernetes, TLS Certs
|
||||
4. **Orchestrators:** Nomad, Terraform, Ansible, or Continuous Integration Continuous Delivery (CI/CD) Pipelines where each pipeline usually identified by 2FA
|
||||
5. **[Vault Agents](/docs/agent/autoauth):** acting on behalf of a app/microservice, typically identified by App role, Cloud credentials, Kubernetes, TLS Certs
|
||||
6. **Tokens**: which are not tied to any identities at all. **_These should be used sparingly._**
|
||||
Hashicorp recommends always associating tokens to an entity alias and token role.
|
||||
|
||||
@@ -62,7 +62,7 @@ Below is a list of supported authentication methods within Vault. You can also s
|
||||
|
||||
Each authentication method has a unique identifier to determine unique identity, similar to a driver license number, that uniquely determines an identity with a driver’s license.
|
||||
|
||||
How does this relate to Vault clients? As outlined above, and as an example, if you chose to identify a microservice by AppRole auth method, then assign a role id for that microservice. A role id is the mircoservice’s username and identity. You should not have different microservices use the same role id. Different microservices should use different role ids. However if microservices (or multiple VMs, or containers), are exact copies using the same role id, they will all have the same identity. This is the appropriate security posture to mitigate any risk, and an operator can easily approve or deny access to secrets for that one role id, without affecting other services. It is important as you choose an identity for each human, app, service, platform, server and pipeline, that you pay attention to the name below that makes each method unique and be given an identity.
|
||||
How does this relate to Vault clients? As outlined above, and as an example, if you chose to identify a microservice by AppRole auth method, then assign a role id for that microservice. A role id is the microservice’s username and identity. You should not have different microservices use the same role id. Different microservices should use different role ids. However if microservices (or multiple VMs, or containers), are exact copies using the same role id, they will all have the same identity. This is the appropriate security posture to mitigate any risk, and an operator can easily approve or deny access to secrets for that one role id, without affecting other services. It is important as you choose an identity for each human, app, service, platform, server and pipeline, that you pay attention to the name below that makes each method unique and be given an identity.
|
||||
|
||||
| **Auth method** | **Name reported by auth method** |
|
||||
| ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------ |
|
||||
|
||||
@@ -48,7 +48,7 @@ operations to the `/sys` API (excluding the `/sys/leases`, `/sys/namespaces`,
|
||||
Some examples of workflows that write to the `/sys` API are upgrades and rekeys.
|
||||
In the future, this guidance may change for the Integrated Storage backend.
|
||||
|
||||
Backups _can_ also help with accidential data deletions or modifications. In
|
||||
Backups _can_ also help with accidental data deletions or modifications. In
|
||||
this case, the story can get a little tricky. If you simply recover a backup
|
||||
from 5AM with the correct data, but the current time is 10AM, you will lose data
|
||||
written between 5 and 10AM. Lucy Davinhart gave a HashiConf talk that serves as
|
||||
|
||||
@@ -76,7 +76,7 @@ default value in the `"/sys/config/ui"` [API endpoint](/api/system/config-ui).
|
||||
|
||||
- `http_write_timeout` `string: "0")` - Specifies the maximum duration before
|
||||
timing out writes of the response and is reset whenever a new request's header
|
||||
is read. The default value of `"0"` means inifinity. This is specified using a
|
||||
is read. The default value of `"0"` means infinity. This is specified using a
|
||||
label suffix like `"30s"` or `"1h"`.
|
||||
|
||||
- `max_request_size` `(int: 33554432)` – Specifies a hard maximum allowed
|
||||
|
||||
@@ -37,7 +37,7 @@ replication {
|
||||
is not specified, Vault will attempt to read the total amount of memory available on the host it's running on. If
|
||||
that succeeds, Vault will use 10% of the value found. If Vault is unable to read the amount of host memory, this
|
||||
defaults to 1GB.
|
||||
- `allow_forwarding_via_header` `(boolean: flase)` - Enable forwarding options for client controlled consistency,
|
||||
- `allow_forwarding_via_header` `(boolean: false)` - Enable forwarding options for client controlled consistency,
|
||||
i.e. `X-Vault-Inconsistent: forward-active-node` and `X-Vault-Forward: active-node`.
|
||||
- `best_effort_wal_wait_duration` `(duration: "2s")` - Legacy mitigation to try to prevent stale reads: when a
|
||||
write is made via RPC, i.e. the node handling the request didn't do the write itself, wait up to this much
|
||||
|
||||
@@ -33,7 +33,7 @@ field can differ per factor, so that different factors can be required for diffe
|
||||
operations.
|
||||
|
||||
Finally, the capabilities in the `controlled_capabilities` stanza must be a subset of the
|
||||
`capabilities` specifed in the policy itself. For example, a policy giving only `read` access to
|
||||
`capabilities` specified in the policy itself. For example, a policy giving only `read` access to
|
||||
the path `secret/foo` cannot specify a control group factor with `list` as a controlled capability.
|
||||
|
||||
Please see the following section for example ACL Policies.
|
||||
@@ -137,7 +137,7 @@ path "kv/*" {
|
||||
|
||||
Because the second path stanza has a control group factor with no `controlled_capabilities` field,
|
||||
any token with this policy will be required to get 2 approvals from the `superuser` group before executing
|
||||
any operation against `kv/*`. In addition, by virtue of the `controlled_capablities` field in the first
|
||||
any operation against `kv/*`. In addition, by virtue of the `controlled_capabilities` field in the first
|
||||
path stanza, `delete`,`list`, and `sudo` operations will require an additional approval from the `admin` group.
|
||||
|
||||
```
|
||||
|
||||
@@ -60,7 +60,7 @@ There are a few key terms to know when discussing Raft:
|
||||
The leader is responsible for ingesting new log entries, replicating to followers,
|
||||
and managing when an entry is considered committed. For Vault's purposes, the
|
||||
leader node is also the Active vault node and followers are standby nodes. See
|
||||
the [High Avaibility docs](/docs/internals/high-availability#design-overview)
|
||||
the [High Availability docs](/docs/internals/high-availability#design-overview)
|
||||
for more information.
|
||||
|
||||
Raft is a complex protocol and will not be covered here in detail (for those who
|
||||
|
||||
@@ -106,7 +106,7 @@ These metrics represent operational aspects of the running Vault instance.
|
||||
| `vault.core.unsealed` | Has value 1 when Vault is unsealed, and 0 when Vault is sealed. | bool | gauge |
|
||||
| `vault.metrics.collection` (cluster,gauge) | Time taken to collect usage gauges, labelled by gauge type. | summary |
|
||||
| `vault.metrics.collection.interval` (cluster,gauge) | Current value of usage gauge collection interval. | summary |
|
||||
| `vault.metrics.collection.error` (cluster,gauge) | Errors while collection usage guages, labeled by gauge type. | counter |
|
||||
| `vault.metrics.collection.error` (cluster,gauge) | Errors while collection usage gauges, labeled by gauge type. | counter |
|
||||
| `vault.rollback.attempt.<mountpoint>` | Time taken to perform a rollback operation on the given mount point. The mount point name has its forward slashes `/` replaced by `-`. For example, a rollback operation on the `auth/token` backend would be reportes as `vault.rollback.attempt.auth-token-`. | ms | summary |
|
||||
| `vault.route.create.<mountpoint>` | Time taken to dispatch a create operation to a backend, and for that backend to process it. The mount point name has its forward slashes `/` replaced by `-`. For example, a create operation to `ns1/secret/` would have corresponding metric `vault.route.create.ns1-secret-`. The number of samples of this metric, and the corresponding ones for other operations below, indicates how many operations were performed per mount point. | ms | summary |
|
||||
| `vault.route.delete.<mountpoint>` | Time taken to dispatch a delete operation to a backend, and for that backend to process it. | ms | summary |
|
||||
|
||||
@@ -48,7 +48,7 @@ The following parameters are supported by the Vault provider:
|
||||
- `vaultNamespace` `(string: "")` - The Vault [namespace](/docs/enterprise/namespaces) to use.
|
||||
|
||||
- `vaultSkipTLSVerify` `(string: "false")` - When set to true, skips verification of the Vault server
|
||||
certificiate. Setting this to true is not recommended for production.
|
||||
certificate. Setting this to true is not recommended for production.
|
||||
|
||||
- `vaultCACertPath` `(string: "")` - The path on disk where the Vault CA certificate can be found
|
||||
when verifying the Vault server certificate.
|
||||
|
||||
@@ -39,8 +39,8 @@ $ openssl req \
|
||||
|
||||
## Create Vault Agent Injector Certificate
|
||||
|
||||
Next we can create a certificate and key signed by the certificiate authority generated above. This
|
||||
certificiate and key will be used by the Vault Agent Injector for TLS communications with the Kuberenetes
|
||||
Next we can create a certificate and key signed by the certificate authority generated above. This
|
||||
certificate and key will be used by the Vault Agent Injector for TLS communications with the Kubernetes
|
||||
API.
|
||||
|
||||
First, create a private key for the certificate:
|
||||
@@ -83,7 +83,7 @@ DNS.4 = vault-agent-injector-svc.vault.svc.cluster.local
|
||||
EOF
|
||||
```
|
||||
|
||||
Finally, sign the certificiate:
|
||||
Finally, sign the certificate:
|
||||
|
||||
~> **Important Note:** Values such as days (how long the certificate is valid for) should be configured for your environment.
|
||||
|
||||
|
||||
@@ -58,4 +58,4 @@ There are several ways to try Vault with Kubernetes in different environments.
|
||||
|
||||
- [Vault on Kubernetes Reference Architecture](https://learn.hashicorp.com/tutorials/vault/kubernetes-reference-architecture?in=vault/kubernetes) provides recommended practices for running Vault on Kubernetes in production.
|
||||
|
||||
- [Vault on Kubernetes Security Considerations](https://learn.hashicorp.com/tutorials/vault/kubernetes-security-concerns?in=vault/kubernetes) provides recomendations specific to securely running Vault in a production Kubernetes environment.
|
||||
- [Vault on Kubernetes Security Considerations](https://learn.hashicorp.com/tutorials/vault/kubernetes-security-concerns?in=vault/kubernetes) provides recommendations specific to securely running Vault in a production Kubernetes environment.
|
||||
|
||||
@@ -43,7 +43,7 @@ steps are usually completed by an operator or configuration management tool.
|
||||
It is recommended to set an IP Network Access list when creating the key.
|
||||
|
||||
For more detailed instructions on how to create a Programmatic API Key in the Atlas UI, including
|
||||
available roles, visit the [Programmatic API Key documenation](https://docs.atlas.mongodb.com/configure-api-access/#programmatic-api-keys).
|
||||
available roles, visit the [Programmatic API Key documentation](https://docs.atlas.mongodb.com/configure-api-access/#programmatic-api-keys).
|
||||
|
||||
1. Once you have a MongoDB Atlas Programmatic Key pair, as created in the previous step, Vault can now
|
||||
be configured to use it with MongoDB Atlas:
|
||||
|
||||
@@ -42,7 +42,7 @@ This plugin currently supports LDAP v3.
|
||||
```
|
||||
|
||||
Note: it's not possible to retrieve the generated password once rotated by Vault.
|
||||
It's recommended a dedicated entry management account be created specfically for Vault.
|
||||
It's recommended a dedicated entry management account be created specifically for Vault.
|
||||
|
||||
### Password Generation
|
||||
|
||||
@@ -237,7 +237,7 @@ To create a user programmatically in AD, you first `add` a user object and then
|
||||
password and enable the account.
|
||||
|
||||
- Passwords in AD are set using the `unicodePwd` field. This must be proceeded by two (2) colons (`::`).
|
||||
- When setting a password programatically in AD, the following critera must be met:
|
||||
- When setting a password programmatically in AD, the following criteria must be met:
|
||||
|
||||
- The password must be enclosed in double quotes (`" "`)
|
||||
- The password must be in [`UTF16LE` format](https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/6e803168-f140-4d23-b2d3-c3a8ab5917d2)
|
||||
|
||||
@@ -21,7 +21,7 @@ version of that token to encrypted versions of the plaintext and metadata, as
|
||||
well as a fingerprint of the original plaintext which facilitates the `tokenized`
|
||||
endpoint that lets one query whether a plaintext exists in the system.
|
||||
|
||||
Depending on the mapping mode, the plaintext may be decoded only with posession
|
||||
Depending on the mapping mode, the plaintext may be decoded only with possession
|
||||
of the distributed token, or may be recoverable in the export operation. See
|
||||
[Security Considerations](#security-considerations) for more.
|
||||
|
||||
@@ -60,7 +60,7 @@ should be effective.
|
||||
|
||||
The goal of Tokenization is to let end users' devices store the token rather than
|
||||
their sensitive values (such as credit card numbers) and still participate in
|
||||
transations where the token is a standin for the sensitive value. For this reason
|
||||
transactions where the token is a stand-in for the sensitive value. For this reason
|
||||
the token Vault generates is completely unrelated (e.g. irreversible) to the
|
||||
sensitive value.
|
||||
|
||||
@@ -69,11 +69,11 @@ on the values produced during encode. In particular it is designed so that
|
||||
attackers cannot recover plaintext even if they steal the tokenization values
|
||||
from Vault itself. In the default mapping mode,
|
||||
even stealing the underlying transform key does not allow them to recover
|
||||
the plaintext without also posessing the encoded token. An attacker must have
|
||||
the plaintext without also possessing the encoded token. An attacker must have
|
||||
gotten access to all values in the construct.
|
||||
|
||||
In the `exportable` mapping mode however, the plaintext values are encrypted
|
||||
in a way that can be decrypted within Vault. If the attacker posesses the
|
||||
in a way that can be decrypted within Vault. If the attacker possesses the
|
||||
transform key and the tokenization mapping values, the plaintext can be
|
||||
recovered. This mode is available for the case where operators prioritize the
|
||||
ability to export all of the plaintext values in an emergency, via the
|
||||
@@ -90,7 +90,7 @@ its decoded value to enable workflows that operate just on the metadata.
|
||||
## TTLs and Tidying
|
||||
|
||||
By default, tokens are long lived, and the storage for them will be maintained
|
||||
indefinitely. Where there is a concept of time-to-live, it is strongely encouraged
|
||||
indefinitely. Where there is a concept of time-to-live, it is strongly encouraged
|
||||
that the tokens be generated with a TTL. For example, as credit cards
|
||||
have an expiration date, it is recommended that tokenizing a credit card
|
||||
primary account number (PAN) be done with a TTL that corresponds to the time
|
||||
@@ -121,7 +121,7 @@ Snapshot allows one to iteratively retrieve the tokenization state, for
|
||||
backup or migration purposes. The resulting data can be fed to the restore
|
||||
endpoint of the same or a different tokenization store. Note that the state
|
||||
is only useable by the tokenization transform that created it, as state is
|
||||
encrypted via keys in that configured trnasform.
|
||||
encrypted via keys in that configured transform.
|
||||
|
||||
### Export Decoded
|
||||
|
||||
|
||||
@@ -32,7 +32,7 @@ passwords) still intact, and with a warning to the user on write that anyone
|
||||
with read access could see the secret. This was mostly done to make it easy for
|
||||
tools like Terraform to judge whether state had drifted. However, it also feels
|
||||
quite un-Vault-y to do this and we've never felt very comfortable doing so. In
|
||||
0.10 we have gone through and removed this bevhavior from the various backends;
|
||||
0.10 we have gone through and removed this behavior from the various backends;
|
||||
fields which contained secret values are simply no longer returned on read. We
|
||||
are working with the Terraform team to make changes to their provider to
|
||||
accommodate this as best as possible, and users of other tools may have to make
|
||||
|
||||
@@ -407,7 +407,7 @@ $ curl --header "X-Vault-Token: ..." \
|
||||
--data @admin-payload.json \
|
||||
http://127.0.0.1:8200/v1/sys/policies/acl/admin
|
||||
|
||||
# Create the API requset payload for creating provisioner policy
|
||||
# Create the API request payload for creating provisioner policy
|
||||
$ tee provisioner-payload.json <<EOF
|
||||
{
|
||||
"policy": "# Manage auth methods broadly across Vault\npath \"auth/*\"\n{\n capabilities = [\"create\", \"read\", \"update\", \"delete\", \"list\", \"sudo\"]\n}\n\n# List, create, update, and delete auth methods\npath \"sys/auth/*\"\n{\n capabilities = [\"create\", \"read\", \"update\", \"delete\", \"sudo\"]\n}\n\n# List existing policies\npath \"sys/policy\"\n{\n capabilities = [\"read\"]\n}\n\n# Create and manage ACL policies\npath \"sys/policy/*\"\n{\n capabilities = [\"create\", \"read\", \"update\", \"delete\", \"list\"]\n}\n\n# List, create, update, and delete key/value secrets\npath \"secret/*\"\n{\n capabilities = [\"create\", \"read\", \"update\", \"delete\", \"list\"]\n}"
|
||||
|
||||
@@ -859,13 +859,13 @@ $ tee payload.json<<EOF
|
||||
}
|
||||
EOF
|
||||
|
||||
# Enable cas_requied on the secret engine mounted at secret/
|
||||
# Enable cas_required on the secret engine mounted at secret/
|
||||
$ curl --header "X-Vault-Token: ..." \
|
||||
--request POST \
|
||||
--data @payload.json
|
||||
http://127.0.0.1:8200/v1/secret/config
|
||||
|
||||
# Enable cas_requied only on the secret/partner path
|
||||
# Enable cas_required only on the secret/partner path
|
||||
$ curl --header "X-Vault-Token: ..." \
|
||||
--request POST \
|
||||
--data @payload.json
|
||||
|
||||
Reference in New Issue
Block a user