diff --git a/website/content/api-docs/auth/alicloud.mdx b/website/content/api-docs/auth/alicloud.mdx index 124f91cce15f..9dd68096767d 100644 --- a/website/content/api-docs/auth/alicloud.mdx +++ b/website/content/api-docs/auth/alicloud.mdx @@ -4,7 +4,7 @@ page_title: AliCloud - Auth Methods - HTTP API description: This is the API documentation for the Vault AliCloud auth method. --- -# AliCloud Auth Method (API) +# AliCloud auth method (API) This is the API documentation for the Vault AliCloud auth method. For general information about the usage and operation of the AliCloud method, please @@ -14,7 +14,7 @@ This documentation assumes the AliCloud auth method is mounted at the `/auth/ali path in Vault. Since it is possible to enable auth methods at any location, please update your API calls accordingly. -## Create/Update Role +## Create/Update role Registers a role. Only entities using the role registered using this endpoint will be able to perform the login operation. @@ -30,7 +30,7 @@ will be able to perform the login operation. @include 'tokenfields.mdx' -### Sample Payload +### Sample payload ```json { @@ -39,7 +39,7 @@ will be able to perform the login operation. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -49,7 +49,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/alicloud/role/dev-role ``` -## Read Role +## Read role Returns the previously registered role configuration. @@ -61,7 +61,7 @@ Returns the previously registered role configuration. - `role` `(string: )` - Name of the role. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -69,7 +69,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/alicloud/role/dev-role ``` -### Sample Response +### Sample response ```json { @@ -83,7 +83,7 @@ $ curl \ } ``` -## List Roles +## List roles Lists all the roles that are registered with the method. @@ -91,7 +91,7 @@ Lists all the roles that are registered with the method. | :----- | :--------------------- | | `LIST` | `/auth/alicloud/roles` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -100,7 +100,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/alicloud/roles ``` -### Sample Response +### Sample response ```json { @@ -110,7 +110,7 @@ $ curl \ } ``` -## Delete Role +## Delete role Deletes the previously registered role. @@ -122,7 +122,7 @@ Deletes the previously registered role. - `role` `(string: )` - Name of the role. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -151,7 +151,7 @@ GetCallerIdentity request. string value or an array of string values (though the length of that array will probably only be one). -### Sample Payload +### Sample payload ```json { @@ -161,7 +161,7 @@ GetCallerIdentity request. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -170,7 +170,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/alicloud/login ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/auth/approle.mdx b/website/content/api-docs/auth/approle.mdx index 24363a85965e..5aba078661a3 100644 --- a/website/content/api-docs/auth/approle.mdx +++ b/website/content/api-docs/auth/approle.mdx @@ -4,7 +4,7 @@ page_title: AppRole - Auth Methods - HTTP API description: This is the API documentation for the Vault AppRole auth method. --- -# AppRole Auth Method (API) +# AppRole auth method (API) This is the API documentation for the Vault AppRole auth method. For general information about the usage and operation of the AppRole method, please @@ -14,7 +14,7 @@ This documentation assumes the AppRole method is mounted at the `/auth/approle` path in Vault. Since it is possible to enable auth methods at any location, please update your API calls accordingly. -## List Roles +## List roles This endpoint returns a list the existing AppRoles in the method. @@ -22,7 +22,7 @@ This endpoint returns a list the existing AppRoles in the method. | :----- | :------------------- | | `LIST` | `/auth/approle/role` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -31,7 +31,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/approle/role ``` -### Sample Response +### Sample response ```json { @@ -81,7 +81,7 @@ include a-Z, 0-9, space, hyphen, underscore and periods. @include 'tokenfields.mdx' -### Sample Payload +### Sample payload ```json { @@ -93,7 +93,7 @@ include a-Z, 0-9, space, hyphen, underscore and periods. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -115,7 +115,7 @@ Reads the properties of an existing AppRole. - `role_name` `(string: )` - Name of the AppRole. Must be less than 4096 bytes. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -123,7 +123,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/approle/role/application1 ``` -### Sample Response +### Sample response ```json { @@ -158,7 +158,7 @@ Deletes an existing AppRole from the method. - `role_name` `(string: )` - Name of the AppRole. Must be less than 4096 bytes. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -167,7 +167,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/approle/role/application1 ``` -## Read AppRole Role ID +## Read AppRole role ID Reads the RoleID of an existing AppRole. @@ -179,7 +179,7 @@ Reads the RoleID of an existing AppRole. - `role_name` `(string: )` - Name of the AppRole. Must be less than 4096 bytes. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -187,7 +187,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/approle/role/application1/role-id ``` -### Sample Response +### Sample response ```json { @@ -203,7 +203,7 @@ $ curl \ } ``` -## Update AppRole Role ID +## Update AppRole role ID Updates the RoleID of an existing AppRole to a custom value. @@ -216,7 +216,7 @@ Updates the RoleID of an existing AppRole to a custom value. - `role_name` `(string: )` - Name of the AppRole. Must be less than 4096 bytes. - `role_id` `(string: )` - Value to be set as RoleID. -### Sample Payload +### Sample payload ```json { @@ -224,7 +224,7 @@ Updates the RoleID of an existing AppRole to a custom value. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -234,7 +234,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/approle/role/application1/role-id ``` -### Sample Response +### Sample response ```json { @@ -250,7 +250,7 @@ $ curl \ } ``` -## Generate New Secret ID +## Generate new secret ID Generates and issues a new SecretID on an existing AppRole. Similar to tokens, the response will also contain a `secret_id_accessor` value which can @@ -284,7 +284,7 @@ itself, and also to delete the SecretID from the AppRole. Overrides secret_id_ttl role option when supplied. May not be longer than role's secret_id_ttl. -### Sample Payload +### Sample payload ```json { @@ -294,7 +294,7 @@ itself, and also to delete the SecretID from the AppRole. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -304,7 +304,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/approle/role/application1/secret-id ``` -### Sample Response +### Sample response ```json { @@ -323,7 +323,7 @@ $ curl \ } ``` -## List Secret ID Accessors +## List secret ID accessors Lists the accessors of all the SecretIDs issued against the AppRole. This includes the accessors for "custom" SecretIDs as well. @@ -336,7 +336,7 @@ This includes the accessors for "custom" SecretIDs as well. - `role_name` `(string: )` - Name of the AppRole. Must be less than 4096 bytes. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -345,7 +345,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/approle/role/application1/secret-id ``` -### Sample Response +### Sample response ```json { @@ -367,7 +367,7 @@ $ curl \ } ``` -## Read AppRole Secret ID +## Read AppRole secret ID Reads out the properties of a SecretID. @@ -380,7 +380,7 @@ Reads out the properties of a SecretID. - `role_name` `(string: )` - Name of the AppRole. Must be less than 4096 bytes. - `secret_id` `(string: )` - Secret ID attached to the role. -### Sample Payload +### Sample payload ```json { @@ -388,7 +388,7 @@ Reads out the properties of a SecretID. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -398,7 +398,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/approle/role/application1/secret-id/lookup ``` -## Destroy AppRole Secret ID +## Destroy AppRole secret ID Destroy an AppRole secret ID. @@ -411,7 +411,7 @@ Destroy an AppRole secret ID. - `role_name` `(string: )` - Name of the AppRole. Must be less than 4096 bytes. - `secret_id` `(string: )` - Secret ID attached to the role. -### Sample Payload +### Sample payload ```json { @@ -419,7 +419,7 @@ Destroy an AppRole secret ID. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -429,7 +429,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/approle/role/application1/secret-id/destroy ``` -## Read AppRole Secret ID Accessor +## Read AppRole secret ID accessor Reads out the properties of a SecretID. @@ -442,7 +442,7 @@ Reads out the properties of a SecretID. - `role_name` `(string: )` - Name of the AppRole. Must be less than 4096 bytes. - `secret_id_accessor` `(string: )` - Secret ID accessor attached to the role. -### Sample Payload +### Sample payload ```json { @@ -450,7 +450,7 @@ Reads out the properties of a SecretID. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -460,7 +460,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/approle/role/application1/secret-id-accessor/lookup ``` -## Destroy AppRole Secret ID Accessor +## Destroy AppRole secret ID accessor Destroy an AppRole secret ID by its accessor. @@ -473,7 +473,7 @@ Destroy an AppRole secret ID by its accessor. - `role_name` `(string: )` - Name of the AppRole. Must be less than 4096 bytes. - `secret_id_accessor` `(string: )` - Secret ID accessor attached to the role. -### Sample Payload +### Sample payload ```json { @@ -481,7 +481,7 @@ Destroy an AppRole secret ID by its accessor. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -491,7 +491,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/approle/role/application1/secret-id-accessor/destroy ``` -## Create Custom AppRole Secret ID +## Create custom AppRole secret ID Assigns a "custom" SecretID against an existing AppRole. This is used in the "Push" model of operation. @@ -524,7 +524,7 @@ Assigns a "custom" SecretID against an existing AppRole. This is used in the Overrides secret_id_ttl role option when supplied. May not be longer than role's secret_id_ttl. -### Sample Payload +### Sample payload ```json { @@ -534,7 +534,7 @@ Assigns a "custom" SecretID against an existing AppRole. This is used in the } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -544,7 +544,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/approle/role/application1/custom-secret-id ``` -### Sample Response +### Sample response ```json { @@ -563,7 +563,7 @@ $ curl \ } ``` -## Login With AppRole +## Login with AppRole Issues a Vault token based on the presented credentials. `role_id` is always required; if `bind_secret_id` is enabled (the default) on the AppRole, @@ -579,7 +579,7 @@ AppRole (such as client IP CIDR) are also evaluated. - `role_id` `(string: )` - RoleID of the AppRole. - `secret_id` `(string: )` - SecretID belonging to AppRole. -### Sample Payload +### Sample payload ```json { @@ -588,7 +588,7 @@ AppRole (such as client IP CIDR) are also evaluated. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -597,7 +597,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/approle/login ``` -### Sample Response +### Sample response ```json { @@ -618,7 +618,7 @@ $ curl \ } ``` -## Read, Update, or Delete AppRole Properties +## Read, update, or delete AppRole properties Updates the respective property in the existing AppRole. All of these parameters of the AppRole can be updated using the `/auth/approle/role/:role_name` @@ -639,7 +639,7 @@ to be able to delegate specific endpoints using Vault's ACL system. Refer to `/auth/approle/role/:role_name` endpoint. -## Tidy Tokens +## Tidy tokens Performs some maintenance tasks to clean up invalid entries that may remain in the token store. Generally, running this is not needed unless upgrade @@ -650,7 +650,7 @@ storage method so should be used sparingly. | :----- | :----------------------------- | | `POST` | `/auth/approle/tidy/secret-id` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -659,7 +659,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/approle/tidy/secret-id ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/auth/aws.mdx b/website/content/api-docs/auth/aws.mdx index d7290d12fc32..b7d45b506cb5 100644 --- a/website/content/api-docs/auth/aws.mdx +++ b/website/content/api-docs/auth/aws.mdx @@ -4,7 +4,7 @@ page_title: AWS - Auth Methods - HTTP API description: This is the API documentation for the Vault AWS auth method. --- -# AWS Auth Method (API) +# AWS auth method (API) @include 'x509-sha1-deprecation.mdx' @@ -22,7 +22,7 @@ please update your API calls accordingly. [list of affected endpoints](#deprecations-effective-in-vault-1-7) and their replacements is provided at the end of this document. -## Configure Client +## Configure client Configures the credentials required to perform API calls to AWS as well as custom endpoints to talk to AWS APIs. The instance identity document @@ -78,7 +78,7 @@ capabilities, the credentials are fetched automatically. an IAM based login call. In any case, a default list of headers AWS STS expects for a GetCallerIdentity are allowed. -### Sample Payload +### Sample payload ```json { @@ -87,7 +87,7 @@ capabilities, the credentials are fetched automatically. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -97,7 +97,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/aws/config/client ``` -## Read Config +## Read config Returns the previously configured AWS access credentials. @@ -105,7 +105,7 @@ Returns the previously configured AWS access credentials. | :----- | :------------------------ | | `GET` | `/auth/aws/config/client` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -113,7 +113,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/aws/config/client ``` -### Sample Response +### Sample response ```json { @@ -128,7 +128,7 @@ $ curl \ } ``` -## Delete Config +## Delete config Deletes the previously configured AWS access credentials. @@ -136,7 +136,7 @@ Deletes the previously configured AWS access credentials. | :------- | :------------------------ | | `DELETE` | `/auth/aws/config/client` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -145,7 +145,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/aws/config/client ``` -## Rotate Root Credentials +## Rotate root credentials When you have configured Vault with static credentials, you can use this endpoint to have Vault rotate the access key it used. Note that, due to AWS @@ -165,7 +165,7 @@ secret key is used to access AWS. There are no parameters to this operation. -### Sample Request +### Sample request ```$ curl \ --header "X-Vault-Token: ..." \ @@ -173,7 +173,7 @@ There are no parameters to this operation. http://127.0.0.1:8200/v1/auth/aws/config/rotate-root ``` -### Sample Response +### Sample response ```json { @@ -185,7 +185,7 @@ There are no parameters to this operation. The new access key Vault uses is returned by this operation. -## Configure Identity Integration +## Configure identity integration This configures the way that Vault interacts with the [Identity](/vault/docs/secrets/identity) store. The default (as of Vault @@ -237,7 +237,7 @@ This configures the way that Vault interacts with the **Only select fields that will have a low rate of change** for your `ec2_alias` because each change triggers a storage write and can have a performance impact at scale. -### Sample Payload +### Sample payload ```json { @@ -245,7 +245,7 @@ This configures the way that Vault interacts with the } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -255,7 +255,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/aws/config/identity ``` -## Read Identity Integration Configuration +## Read identity integration configuration Returns the previously configured Identity integration configuration @@ -263,7 +263,7 @@ Returns the previously configured Identity integration configuration | :----- | :-------------------------- | | `GET` | `/auth/aws/config/identity` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -271,7 +271,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/aws/config/identity ``` -### Sample Response +### Sample response ```json { @@ -281,7 +281,7 @@ $ curl \ } ``` -## Create Certificate Configuration +## Create certificate configuration Registers an AWS public key to be used to verify the instance identity documents. Indicate the type of the public key using the `type` parameter. @@ -320,7 +320,7 @@ for more information on the signature types and the corresponding certificates. [/signature](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/verify-signature.html) endpoint. Defaults to "pkcs7". -### Sample Payload +### Sample payload ```json { @@ -328,7 +328,7 @@ for more information on the signature types and the corresponding certificates. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -338,7 +338,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/aws/config/certificate/test-cert ``` -## Read Certificate Configuration +## Read certificate configuration Returns the previously configured AWS public key. @@ -350,7 +350,7 @@ Returns the previously configured AWS public key. - `cert_name` `(string: )` - Name of the certificate. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -358,7 +358,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/aws/config/certificate/test-cert ``` -### Sample Response +### Sample response ```json { @@ -369,7 +369,7 @@ $ curl \ } ``` -## Delete Certificate Configuration +## Delete certificate configuration Removes the previously configured AWS public key. @@ -377,7 +377,7 @@ Removes the previously configured AWS public key. | :------- | :---------------------------------------- | | `DELETE` | `/auth/aws/config/certificate/:cert_name` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -386,7 +386,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/aws/config/certificate/test-cert ``` -## List Certificate Configurations +## List certificate configurations Lists all the AWS public certificates that are registered with the method. @@ -394,7 +394,7 @@ Lists all the AWS public certificates that are registered with the method. | :----- | :------------------------------ | | `LIST` | `/auth/aws/config/certificates` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -403,7 +403,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/aws/config/certificates ``` -### Sample Response +### Sample response ```json { @@ -413,7 +413,7 @@ $ curl \ } ``` -## Create STS Role +## Create STS role Allows the explicit association of STS roles to satellite AWS accounts (i.e. those which are not the account in which the Vault server is @@ -433,7 +433,7 @@ when validating IAM principals or EC2 instances in the particular AWS account. interacting with the account specified. The Vault server must have permissions to assume this role. -### Sample Payload +### Sample payload ```json { @@ -441,7 +441,7 @@ when validating IAM principals or EC2 instances in the particular AWS account. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -451,7 +451,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/aws/config/sts/111122223333 ``` -## Read STS Role +## Read STS role Returns the previously configured STS role. @@ -464,7 +464,7 @@ Returns the previously configured STS role. - `account_id` `(string: )` - AWS account ID that has been previously associated with STS role. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -472,7 +472,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/aws/config/sts/111122223333 ``` -### Sample Response +### Sample response ```json { @@ -482,7 +482,7 @@ $ curl \ } ``` -## List STS Roles +## List STS roles Lists all the AWS Account IDs for which an STS role is registered. @@ -490,7 +490,7 @@ Lists all the AWS Account IDs for which an STS role is registered. | :----- | :--------------------- | | `LIST` | `/auth/aws/config/sts` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -499,7 +499,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/aws/config/sts ``` -### Sample Response +### Sample response ```json { @@ -509,7 +509,7 @@ $ curl \ } ``` -## Delete STS Role +## Delete STS role Deletes a previously configured AWS account/STS role association. @@ -522,7 +522,7 @@ Deletes a previously configured AWS account/STS role association. - `account_id` `(string: )` - AWS account ID that has been previously associated with STS role. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -531,7 +531,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/aws/config/sts/111122223333 ``` -## Configure Identity Access List Tidy Operation +## Configure identity access list tidy operation Configures the periodic tidying operation of the access listed identity entries. @@ -547,7 +547,7 @@ Configures the periodic tidying operation of the access listed identity entries. - `disable_periodic_tidy` `(bool: false)` - If set to 'true', disables the periodic tidying of the `identity-accesslist/` entries. -### Sample Payload +### Sample payload ```json { @@ -555,7 +555,7 @@ Configures the periodic tidying operation of the access listed identity entries. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -565,7 +565,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/aws/config/tidy/identity-accesslist ``` -## Read Identity Access List Tidy Settings +## Read identity access list tidy settings Returns the previously configured periodic access list tidying settings. @@ -573,7 +573,7 @@ Returns the previously configured periodic access list tidying settings. | :----- | :------------------------------------------ | | `GET` | `/auth/aws/config/tidy/identity-accesslist` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -581,7 +581,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/aws/config/tidy/identity-accesslist ``` -### Sample Response +### Sample response ```json { @@ -592,7 +592,7 @@ $ curl \ } ``` -## Delete Identity Access List Tidy Settings +## Delete identity access list tidy settings Deletes the previously configured periodic access list tidying settings. @@ -600,7 +600,7 @@ Deletes the previously configured periodic access list tidying settings. | :------- | :------------------------------------------ | | `DELETE` | `/auth/aws/config/tidy/identity-accesslist` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -609,7 +609,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/aws/config/tidy/identity-accesslist ``` -## Configure Role Tag Deny List Tidy Operation +## Configure role tag deny list tidy operation Configures the periodic tidying operation of the deny listed role tag entries. @@ -625,7 +625,7 @@ Configures the periodic tidying operation of the deny listed role tag entries. - `disable_periodic_tidy` `(bool: false)` - If set to 'true', disables the periodic tidying of the `roletag-denylist/` entries. -### Sample Payload +### Sample payload ```json { @@ -633,7 +633,7 @@ Configures the periodic tidying operation of the deny listed role tag entries. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -643,7 +643,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/aws/config/tidy/roletag-denylist ``` -## Read Role Tag Deny List Tidy Settings +## Read role tag deny list tidy settings Returns the previously configured periodic deny list tidying settings. @@ -651,7 +651,7 @@ Returns the previously configured periodic deny list tidying settings. | :----- | :--------------------------------------- | | `GET` | `/auth/aws/config/tidy/roletag-denylist` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -659,7 +659,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/aws/config/tidy/roletag-denylist ``` -### Sample Response +### Sample response ```json { @@ -670,7 +670,7 @@ $ curl \ } ``` -## Delete Role Tag Deny List Tidy Settings +## Delete role tag deny list tidy settings Deletes the previously configured periodic deny list tidying settings. @@ -678,7 +678,7 @@ Deletes the previously configured periodic deny list tidying settings. | :------- | :--------------------------------------- | | `DELETE` | `/auth/aws/config/tidy/roletag-denylist` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -687,7 +687,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/aws/config/tidy/roletag-denylist ``` -## Create/Update Role +## Create/Update role Registers a role in the method. Only those instances or principals which are using the role registered using this endpoint, will be able to perform @@ -840,7 +840,7 @@ list in order to satisfy that constraint. @include 'tokenfields.mdx' -### Sample Payload +### Sample payload ```json { @@ -854,7 +854,7 @@ list in order to satisfy that constraint. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -864,7 +864,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/aws/role/dev-role ``` -## Read Role +## Read role Returns the previously registered role configuration. @@ -876,7 +876,7 @@ Returns the previously registered role configuration. - `role` `(string: )` - Name of the role. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -884,7 +884,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/aws/role/dev-role ``` -### Sample Response +### Sample response ```json { @@ -899,7 +899,7 @@ $ curl \ } ``` -## List Roles +## List roles Lists all the roles that are registered with the method. @@ -907,7 +907,7 @@ Lists all the roles that are registered with the method. | :----- | :---------------- | | `LIST` | `/auth/aws/roles` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -916,7 +916,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/aws/roles ``` -### Sample Response +### Sample response ```json { @@ -926,7 +926,7 @@ $ curl \ } ``` -## Delete Role +## Delete role Deletes the previously registered role. @@ -938,7 +938,7 @@ Deletes the previously registered role. - `role` `(string: )` - Name of the role. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -947,7 +947,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/aws/role/dev-role ``` -## Create Role Tags +## Create role tags Creates a role tag on the role, which help in restricting the capabilities that are set on the role. Role tags are not tied to any specific ec2 @@ -989,7 +989,7 @@ given instance can be allowed to gain in a worst-case scenario. auth/aws/identity-accesslist endpoint. Defaults to 'false'. Mutually exclusive with `allow_instance_migration`. -### Sample Payload +### Sample payload ```json { @@ -997,7 +997,7 @@ given instance can be allowed to gain in a worst-case scenario. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1007,7 +1007,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/aws/role/dev-api-and-web-role/tag ``` -### Sample Response +### Sample response ```json { @@ -1095,13 +1095,13 @@ for more information on the signature types. its value must match the value configured, and the header must be included in the signed headers. This is required when using the iam auth method. -### Sample Payload +### Sample payload ```json {} ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1110,7 +1110,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/aws/login ``` -### Sample Response +### Sample response ```json { @@ -1131,7 +1131,7 @@ $ curl \ } ``` -## Place Role Tags in Deny List +## Place role tags in deny list Places a valid role tag in a deny list. This ensures that the role tag cannot be used by any instance to perform a login operation again. Note @@ -1149,7 +1149,7 @@ token. created. The tag can be supplied as-is. In order to avoid any encoding problems, it can be base64 encoded. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1158,7 +1158,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/aws/roletag-denylist/djE6MDlWcDBxR3V5Qjg9OmE9YW1pLWZjZTNjNjk2OnA9ZGVmYXVsdCxwcm9kOmQ9ZmFsc2U6dD0zMDBoMG0wczp1UExLQ1F4cXNlZlJocnAxcW1WYTF3c1FWVVhYSkc4VVpQLwo= ``` -### Read Role Tag Deny List Information +### Read role tag deny list information Returns the deny list entry of a previously deny listed role tag. @@ -1172,7 +1172,7 @@ Returns the deny list entry of a previously deny listed role tag. supplied as-is. In order to avoid any encoding problems, it can be base64 encoded. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1180,7 +1180,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/aws/roletag-denylist/djE6MDlWcDBxR3V5Qjg9OmE9YW1pLWZjZTNjNjk2OnA9ZGVmYXVsdCxwcm9kOmQ9ZmFsc2U6dD0zMDBoMG0wczp1UExLQ1F4cXNlZlJocnAxcW1WYTF3c1FWVVhYSkc4VVpQLwo= ``` -### Sample Response +### Sample response ```json { @@ -1191,7 +1191,7 @@ $ curl \ } ``` -## List Deny List Tags +## List deny list tags Lists all the role tags that are deny listed. @@ -1199,7 +1199,7 @@ Lists all the role tags that are deny listed. | :----- | :--------------------------- | | `LIST` | `/auth/aws/roletag-denylist` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1208,7 +1208,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/aws/roletag-denylist ``` -### Sample Response +### Sample response ```json { @@ -1220,7 +1220,7 @@ $ curl \ } ``` -## Delete Deny List Tags +## Delete deny list tags Deletes a deny listed role tag. @@ -1234,7 +1234,7 @@ Deletes a deny listed role tag. supplied as-is. In order to avoid any encoding problems, it can be base64 encoded. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1243,7 +1243,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/aws/roletag-denylist/djE6MDlWcDBxR3V5Qjg9OmE9YW1pLWZjZTNjNjk2OnA9ZGVmYXVsdCxwcm9kOmQ9ZmFsc2U6dD0zMDBoMG0wczp1UExLQ1F4cXNlZlJocnAxcW1WYTF3c1FWVVhYSkc4VVpQLwo= ``` -## Tidy Deny List Tags +## Tidy deny list tags Cleans up the entries in the deny listed based on expiration time on the entry and `safety_buffer`. @@ -1258,7 +1258,7 @@ Cleans up the entries in the deny listed based on expiration time on the entry a passed beyond the `roletag` expiration, before it is removed from the method storage. Defaults to 72h. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1267,7 +1267,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/aws/tidy/roletag-denylist ``` -### Read Identity Access List Information +### Read identity access list information Returns an entry in the identity access list. An entry will be created/updated by every successful login. @@ -1282,7 +1282,7 @@ successful login. operation from an EC2 instance gets cached in th access list, keyed off of instance ID. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1290,7 +1290,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/aws/identity-accesslist/i-aab47d37 ``` -### Sample Response +### Sample response ```json { @@ -1304,7 +1304,7 @@ $ curl \ } ``` -## List Identity Access List Entries +## List identity access list entries Lists all the instance IDs that are in the access list of successful logins. @@ -1312,7 +1312,7 @@ Lists all the instance IDs that are in the access list of successful logins. | :----- | :------------------------------ | | `LIST` | `/auth/aws/identity-accesslist` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1321,7 +1321,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/aws/identity-accesslist ``` -### Sample Response +### Sample response ```json { @@ -1331,7 +1331,7 @@ $ curl \ } ``` -## Delete Identity Access List Entries +## Delete identity access list entries Deletes a cache of the successful login from an instance. @@ -1345,7 +1345,7 @@ Deletes a cache of the successful login from an instance. operation from an EC2 instance gets cached in this access list, keyed off of instance ID. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1354,7 +1354,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/aws/identity-accesslist/i-aab47d37 ``` -## Tidy Identity Access List Entries +## Tidy identity access list entries Cleans up the entries in the access list based on expiration time and `safety_buffer`. @@ -1369,7 +1369,7 @@ Cleans up the entries in the access list based on expiration time and passed beyond the `roletag` expiration, before it is removed from the method storage. Defaults to 72h. -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/auth/azure.mdx b/website/content/api-docs/auth/azure.mdx index 3b8caa836a8e..949d933bd3ee 100644 --- a/website/content/api-docs/auth/azure.mdx +++ b/website/content/api-docs/auth/azure.mdx @@ -6,7 +6,7 @@ description: |- method plugin. --- -# Azure Auth Method (API) +# Azure auth method (API) This is the API documentation for the Vault Azure auth method plugin. To learn more about the usage and operation, see the @@ -42,7 +42,7 @@ virtual machine. - `client_secret` `(string: '')` - The client secret for credentials to query the Azure APIs. This value can also be provided with the `AZURE_CLIENT_SECRET` environment variable. -### Sample Payload +### Sample payload ```json { @@ -53,7 +53,7 @@ virtual machine. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -63,7 +63,7 @@ $ curl \ https://127.0.0.1:8200/v1/auth/azure/config ``` -# Read Config +# Read config Returns the previously configured config, including credentials. @@ -71,7 +71,7 @@ Returns the previously configured config, including credentials. | :----- | :------------------- | | `GET` | `/auth/azure/config` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -79,7 +79,7 @@ $ curl \ https://127.0.0.1:8200/v1/auth/azure/config ``` -### Sample Response +### Sample response ```json { @@ -94,7 +94,7 @@ $ curl \ ``` -## Delete Config +## Delete config Deletes the previously configured Azure config and credentials. @@ -102,7 +102,7 @@ Deletes the previously configured Azure config and credentials. | :------- | :------------------- | | `DELETE` | `/auth/azure/config` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -111,7 +111,7 @@ $ curl \ https://127.0.0.1:8200/v1/auth/azure/config ``` -## Rotate Root +## Rotate root This endpoint generates a new client secret for the root account defined in the config. The value generated will only be known by Vault. @@ -124,7 +124,7 @@ value generated will only be known by Vault. There are no parameters to this operation. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -133,7 +133,7 @@ $ curl \ https://127.0.0.1:8200/v1/auth/azure/rotate-root ``` -## Create/Update Role +## Create/Update role Registers a role in the method. Role types have specific entities that can perform login operations against this endpoint. Constraints specific @@ -161,7 +161,7 @@ entities attempting to login. @include 'tokenfields.mdx' -### Sample Payload +### Sample payload ```json { @@ -172,7 +172,7 @@ entities attempting to login. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -182,7 +182,7 @@ $ curl \ https://127.0.0.1:8200/v1/auth/azure/role/dev-role ``` -## Read Role +## Read role Returns the previously registered role configuration. @@ -194,7 +194,7 @@ Returns the previously registered role configuration. - `name` `(string: )` - Name of the role. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -202,7 +202,7 @@ $ curl \ https://127.0.0.1:8200/v1/auth/azure/role/dev-role ``` -### Sample Response +### Sample response ```json { @@ -225,7 +225,7 @@ $ curl \ ``` -## List Roles +## List roles Lists all the roles that are registered with the plugin. @@ -233,7 +233,7 @@ Lists all the roles that are registered with the plugin. | :----- | :----------------- | | `LIST` | `/auth/azure/role` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -242,7 +242,7 @@ $ curl \ https://127.0.0.1:8200/v1/auth/azure/role ``` -### Sample Response +### Sample response ```json { @@ -256,7 +256,7 @@ $ curl \ } ``` -## Delete Role +## Delete role Deletes the previously registered role. @@ -268,7 +268,7 @@ Deletes the previously registered role. - `name` `(string: )` - Name of the role. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -287,7 +287,7 @@ entity and then authorizes the entity for the given role. | :----- | :------------------ | | `POST` | `/auth/azure/login` | -### Sample Payload +### Sample payload - `role` `(string: )` - Name of the role against which the login is being attempted. @@ -311,7 +311,7 @@ entity and then authorizes the entity for the given role. the format /subscriptions/{guid}/resourceGroups/{resource-group-name}/{resource-provider-namespace}/{resource-type}/{resource-name}. If `vm_name` or `vmss_name` is provided, this value is ignored. -### Sample Payload +### Sample payload ```json { @@ -320,7 +320,7 @@ entity and then authorizes the entity for the given role. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -329,7 +329,7 @@ $ curl \ https://127.0.0.1:8200/v1/auth/azure/login ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/auth/cert.mdx b/website/content/api-docs/auth/cert.mdx index 82a72596cc3e..0604b161edb8 100644 --- a/website/content/api-docs/auth/cert.mdx +++ b/website/content/api-docs/auth/cert.mdx @@ -6,7 +6,7 @@ description: |- method. --- -# TLS Certificate Auth Method (API) +# TLS certificate auth method (API) @include 'x509-sha1-deprecation.mdx' @@ -18,7 +18,7 @@ This documentation assumes the TLS Certificate method is mounted at the `/auth/cert` path in Vault. Since it is possible to enable auth methods at any location, please update your API calls accordingly. -## Create CA Certificate Role +## Create CA certificate role Sets a CA cert and associated parameters in a role name. @@ -90,7 +90,7 @@ Sets a CA cert and associated parameters in a role name. @include 'tokenfields.mdx' -### Sample Payload +### Sample payload ```json { @@ -100,7 +100,7 @@ Sets a CA cert and associated parameters in a role name. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -111,7 +111,7 @@ $ curl \ https://127.0.0.1:8200/v1/auth/cert/certs/test-ca ``` -## Read CA Certificate Role +## Read CA certificate role Gets information associated with the named role. @@ -123,7 +123,7 @@ Gets information associated with the named role. - `name` `(string: )` - The name of the certificate role. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -132,7 +132,7 @@ $ curl \ https://127.0.0.1:8200/v1/auth/cert/certs/test-ca ``` -### Sample Response +### Sample response ```json { @@ -154,7 +154,7 @@ $ curl \ } ``` -## List Certificate Roles +## List certificate roles Lists configured certificate names. @@ -162,7 +162,7 @@ Lists configured certificate names. | :----- | :----------------- | | `LIST` | `/auth/cert/certs` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -172,7 +172,7 @@ $ curl \ https://127.0.0.1:8200/v1/auth/cert/certs ``` -### Sample Response +### Sample response ```json { @@ -188,7 +188,7 @@ $ curl \ } ``` -## Delete Certificate Role +## Delete certificate role Deletes the named role and CA cert from the method mount. @@ -200,7 +200,7 @@ Deletes the named role and CA cert from the method mount. - `name` `(string: )` - The name of the certificate role. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -218,7 +218,7 @@ Lists configured certificate revocation lists. | :----- | :---------------- | | `LIST` | `/auth/cert/crls` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -228,7 +228,7 @@ $ curl \ https://127.0.0.1:8200/v1/auth/cert/crls ``` -### Sample Response +### Sample response ```json { @@ -257,7 +257,7 @@ Sets a named CRL. - `name` `(string: )` - The name of the CRL. - `crl` `(string: )` - The PEM format CRL. -### Sample Payload +### Sample payload ```json { @@ -265,7 +265,7 @@ Sets a named CRL. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -290,7 +290,7 @@ arbitrary size, these are returned as strings. - `name` `(string: )` - The name of the CRL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -299,7 +299,7 @@ $ curl \ https://127.0.0.1:8200/v1/auth/cert/crls/custom-crl ``` -### Sample Response +### Sample response ```json { @@ -328,7 +328,7 @@ Deletes the named CRL from the auth method mount. - `name` `(string: )` - The name of the CRL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -338,7 +338,7 @@ $ curl \ https://127.0.0.1:8200/v1/auth/cert/crls/cert1 ``` -## Configure TLS Certificate Method +## Configure TLS certificate method Configuration options for the method. @@ -357,7 +357,7 @@ Configuration options for the method. - `ocsp_cache_size` `(int: 100)` - The size of the OCSP response LRU cache. Note that this cache is used for all configured certificates. -### Sample Payload +### Sample payload ```json { @@ -365,7 +365,7 @@ Configuration options for the method. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -376,7 +376,7 @@ $ curl \ https://127.0.0.1:8200/v1/auth/cert/certs/cert1 ``` -## Login with TLS Certificate Method +## Login with TLS certificate method Log in and fetch a token. If there is a valid chain to a CA configured in the method and all role constraints are matched, a token will be issued. If the @@ -395,7 +395,7 @@ https://tools.ietf.org/html/rfc6125#section-2.3) returning its policy list if successful. If not set, defaults to trying all certificate roles and returning any one that matches. -### Sample Payload +### Sample payload ```json { @@ -403,7 +403,7 @@ https://tools.ietf.org/html/rfc6125#section-2.3) } ``` -### Sample Request +### Sample request ~> **NOTE** The `--cacert` value used here is for the Vault TLS Listener CA certificate, not the CA that issued the client authentication certificate. This @@ -420,7 +420,7 @@ $ curl \ https://127.0.0.1:8200/v1/auth/cert/login ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/auth/cf.mdx b/website/content/api-docs/auth/cf.mdx index 4edfd0cfddb1..c5b9d95cc29e 100644 --- a/website/content/api-docs/auth/cf.mdx +++ b/website/content/api-docs/auth/cf.mdx @@ -4,7 +4,7 @@ page_title: Cloud Foundry - Auth Methods - HTTP API description: This is the API documentation for the Vault Cloud Foundry auth method. --- -# Pivotal Cloud Foundry (CF) Auth Method (API) +# Pivotal Cloud Foundry (CF) auth method (API) @include 'x509-sha1-deprecation.mdx' @@ -16,7 +16,7 @@ This documentation assumes the CF method is mounted at the `/auth/cf` path in Vault. Since it is possible to enable auth methods at any location, please update your API calls accordingly. -## Create Configuration +## Create configuration Configure the root CA certificate to be used for verifying instance identity certificates, and configure access to the CF API. For detailed instructions @@ -47,7 +47,7 @@ documentation](/vault/docs/auth/cf). seconds in the future when a signature could have been created. The lower the value, the lower the risk of replay attacks. -### Sample Payload +### Sample payload ```json { @@ -65,7 +65,7 @@ documentation](/vault/docs/auth/cf). } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -75,7 +75,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/cf/config ``` -## Read Config +## Read config Returns the present CF configuration. @@ -83,7 +83,7 @@ Returns the present CF configuration. | :----- | ----------------- | | `GET` | `/auth/cf/config` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -91,7 +91,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/cf/config ``` -### Sample Response +### Sample response ```json { @@ -108,7 +108,7 @@ $ curl \ } ``` -## Delete Config +## Delete config Deletes the present CF configuration. @@ -116,7 +116,7 @@ Deletes the present CF configuration. | :------- | ----------------- | | `DELETE` | `/auth/cf/config` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -125,7 +125,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/cf/config ``` -## Create/Update Role +## Create/Update role Create a role in Vault granting a particular level of access to a particular group of CF instances. We recommend using the CF API or the CF CLI to gain the IDs you @@ -160,7 +160,7 @@ will be able to authenticate against this role. @include 'tokenfields.mdx' -### Sample Payload +### Sample payload ```json { @@ -176,7 +176,7 @@ will be able to authenticate against this role. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -186,7 +186,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/cf/roles/:role ``` -## Read Role +## Read role Returns a CF role. @@ -194,7 +194,7 @@ Returns a CF role. | :----- | ---------------------- | | `GET` | `/auth/cf/roles/:role` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -202,7 +202,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/cf/roles/:role ``` -### Sample Response +### Sample response ```json { @@ -218,7 +218,7 @@ $ curl \ } ``` -## Delete Role +## Delete role Deletes a CF role. @@ -226,7 +226,7 @@ Deletes a CF role. | :------- | ---------------------- | | `DELETE` | `/auth/cf/roles/:role` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -235,7 +235,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/cf/roles/:role ``` -## List Roles +## List roles Returns a CF role. @@ -243,7 +243,7 @@ Returns a CF role. | :----- | ---------------- | | `LIST` | `/auth/cf/roles` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -252,7 +252,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/cf/roles ``` -### Sample Response +### Sample response ```json { @@ -302,7 +302,7 @@ rsa.SignPSS(rand.Reader, rsaPrivateKey, crypto.SHA256, checksum, nil) - `signature` `(string: required)` - The signature generated by the algorithm described above using the `CF_INSTANCE_KEY`. -### Sample Payload +### Sample payload ```json { @@ -313,7 +313,7 @@ rsa.SignPSS(rand.Reader, rsaPrivateKey, crypto.SHA256, checksum, nil) } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -323,7 +323,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/cf/login ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/auth/gcp.mdx b/website/content/api-docs/auth/gcp.mdx index 9c4d23c1b5f6..dddeb9594e03 100644 --- a/website/content/api-docs/auth/gcp.mdx +++ b/website/content/api-docs/auth/gcp.mdx @@ -6,7 +6,7 @@ description: |- method. --- -# Google Cloud Auth Method (API) +# Google Cloud auth method (API) This is the API documentation for the Vault Google Cloud auth method. To learn more about the usage and operation, see the @@ -81,7 +81,7 @@ to confirm signed JWTs passed in during login. The endpoint value provided for a given key has the form of `scheme://host:port`. The `scheme://` and `:port` portions of the endpoint value are optional. -### Sample Payload +### Sample payload ```json { @@ -89,7 +89,7 @@ to confirm signed JWTs passed in during login. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -99,7 +99,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/gcp/config ``` -## Read Config +## Read config Returns the configuration, if any, including credentials. @@ -107,7 +107,7 @@ Returns the configuration, if any, including credentials. | :----- | :----------------- | | `GET` | `/auth/gcp/config` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -115,7 +115,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/gcp/config ``` -### Sample Response +### Sample response ```json { @@ -128,7 +128,7 @@ $ curl \ } ``` -## Create/Update Role +## Create/Update role Registers a role in the method. Role types have specific entities that can perform login operations against this endpoint. Constraints specific @@ -164,7 +164,7 @@ entities attempting to login. @include 'tokenfields.mdx' -#### `iam`-only Parameters +#### `iam`-only parameters The following parameters are only valid when the role is of type `"iam"`: @@ -179,7 +179,7 @@ The following parameters are only valid when the role is of type `"iam"`: allow GCE instances to authenticate by inferring service accounts from the GCE identity metadata token. -#### `gce`-only Parameters +#### `gce`-only parameters The following parameters are only valid when the role is of type `"gce"`: @@ -201,7 +201,7 @@ The following parameters are only valid when the role is of type `"gce"`: GCP labels are not currently ACL'd, we recommend that this be used in conjunction with other restrictions. -### Sample Payload +### Sample payload Example `iam` role: @@ -231,7 +231,7 @@ Example `gce` role: } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -241,7 +241,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/gcp/role/my-role ``` -## Edit Service Accounts on IAM Role +## Edit service accounts on IAM role Edit service accounts for an existing IAM role in the method. This allows you to add or remove service accounts from the list of @@ -262,7 +262,7 @@ service accounts on the role. - `remove` `(array: [])` - The list of service accounts to remove from the role's service accounts. -### Sample Payload +### Sample payload ```json { @@ -271,7 +271,7 @@ service accounts on the role. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -281,7 +281,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/gcp/role/my-role ``` -## Edit Labels on GCE Role +## Edit labels on GCE role Edit labels for an existing GCE role in the backend. This allows you to add or remove labels (keys, values, or both) from the list of keys on the role. @@ -302,7 +302,7 @@ remove labels (keys, values, or both) from the list of keys on the role. bound labels. If any of the specified keys do not exist, no error is returned (idempotent). -### Sample Payload +### Sample payload ```json { @@ -311,7 +311,7 @@ remove labels (keys, values, or both) from the list of keys on the role. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -321,7 +321,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/gcp/role/my-role ``` -## Read Role +## Read role Returns the previously registered role configuration. @@ -333,7 +333,7 @@ Returns the previously registered role configuration. - `name` `(string: )` - The name of the role to read. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -341,7 +341,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/gcp/role/my-role ``` -### Sample Response +### Sample response ```json { @@ -364,7 +364,7 @@ $ curl \ } ``` -## List Roles +## List roles Lists all the roles that are registered with the plugin. @@ -372,7 +372,7 @@ Lists all the roles that are registered with the plugin. | :----- | :---------------- | | `LIST` | `/auth/gcp/roles` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -381,7 +381,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/gcp/roles ``` -### Sample Response +### Sample response ```json { @@ -391,7 +391,7 @@ $ curl \ } ``` -## Delete Role +## Delete role Deletes the previously registered role. @@ -403,7 +403,7 @@ Deletes the previously registered role. - `role` `(string: )` - The name of the role to delete. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -423,7 +423,7 @@ role. | :----- | :---------------- | | `POST` | `/auth/gcp/login` | -### Sample Payload +### Sample payload - `role` `(string: )` - The name of the role against which the login is being attempted. @@ -435,7 +435,7 @@ role. - For `gce` type roles, this is an [identity metadata token][instance-token]. -### Sample Payload +### Sample payload ```json { @@ -444,7 +444,7 @@ role. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -453,7 +453,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/gcp/login ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/auth/github.mdx b/website/content/api-docs/auth/github.mdx index 6a83123e0258..d8e12c8c556a 100644 --- a/website/content/api-docs/auth/github.mdx +++ b/website/content/api-docs/auth/github.mdx @@ -4,7 +4,7 @@ page_title: GitHub - Auth Methods - HTTP API description: This is the API documentation for the Vault GitHub auth method. --- -# GitHub Auth Method (API) +# GitHub auth method (API) This is the API documentation for the Vault GitHub auth method. For general information about the usage and operation of the GitHub method, please @@ -14,7 +14,7 @@ This documentation assumes the GitHub method is enabled at the `/auth/github` path in Vault. Since it is possible to enable auth methods at any location, please update your API calls accordingly. -## Configure Method +## Configure method Configures the connection parameters for GitHub. This path honors the distinction between the `create` and `update` capabilities inside ACL policies. @@ -40,7 +40,7 @@ distinction between the `create` and `update` capabilities inside ACL policies. @include 'tokenfields.mdx' -### Sample Payload +### Sample payload ```json { @@ -48,7 +48,7 @@ distinction between the `create` and `update` capabilities inside ACL policies. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -58,7 +58,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/github/config ``` -## Read Configuration +## Read configuration Reads the GitHub configuration. @@ -66,7 +66,7 @@ Reads the GitHub configuration. | :----- | :-------------------- | | `GET` | `/auth/github/config` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -74,7 +74,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/github/config ``` -### Sample Response +### Sample response ```json { @@ -92,7 +92,7 @@ $ curl \ } ``` -## Map GitHub Teams +## Map GitHub teams Map a list of policies to a team that exists in the configured GitHub organization. @@ -105,7 +105,7 @@ Map a list of policies to a team that exists in the configured GitHub organizati - `team_name` `(string)` - GitHub team name in "slugified" format - `value` `(string)` - Comma separated list of policies to assign -### Sample Payload +### Sample payload ```json { @@ -113,7 +113,7 @@ Map a list of policies to a team that exists in the configured GitHub organizati } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -123,7 +123,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/github/map/teams/dev ``` -## Read Team Mapping +## Read team mapping Reads the GitHub team policy mapping. @@ -131,7 +131,7 @@ Reads the GitHub team policy mapping. | :----- | :---------------------------------- | | `GET` | `/auth/github/map/teams/:team_name` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -139,7 +139,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/github/map/teams/dev ``` -### Sample Response +### Sample response ```json { @@ -157,7 +157,7 @@ $ curl \ } ``` -## Map GitHub Users +## Map GitHub users Map a list of policies to a specific GitHub user exists in the configured organization. @@ -171,7 +171,7 @@ organization. - `user_name` `(string)` - GitHub user name - `value` `(string)` - Comma separated list of policies to assign -### Sample Payload +### Sample payload ```json { @@ -179,7 +179,7 @@ organization. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -192,7 +192,7 @@ $ curl \ The user with username `sethvargo` will be assigned the `sethvargo-policy` policy **in addition to** any team policies. -## Read User Mapping +## Read user mapping Reads the GitHub user policy mapping. @@ -200,7 +200,7 @@ Reads the GitHub user policy mapping. | :----- | :---------------------------------- | | `GET` | `/auth/github/map/users/:user_name` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -208,7 +208,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/github/map/users/sethvargo ``` -### Sample Response +### Sample response ```json { @@ -238,7 +238,7 @@ Login using GitHub access token. - `token` `(string: )` - GitHub personal API token. -### Sample Payload +### Sample payload ```json { @@ -246,7 +246,7 @@ Login using GitHub access token. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -254,7 +254,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/github/login ``` -### Sample Response +### Sample response ```javascript { diff --git a/website/content/api-docs/auth/index.mdx b/website/content/api-docs/auth/index.mdx index 26d548453348..2cc48c1d9214 100644 --- a/website/content/api-docs/auth/index.mdx +++ b/website/content/api-docs/auth/index.mdx @@ -6,7 +6,7 @@ description: |- These endpoints are documented in this section. --- -# Auth Methods +# Auth methods Each auth method publishes its own set of API paths and methods. These endpoints are documented in this section. Auth methods are enabled at a path, but the diff --git a/website/content/api-docs/auth/jwt.mdx b/website/content/api-docs/auth/jwt.mdx index 42b6c5a4ce5a..1b68a5f8d517 100644 --- a/website/content/api-docs/auth/jwt.mdx +++ b/website/content/api-docs/auth/jwt.mdx @@ -6,7 +6,7 @@ description: |- method plugin. --- -# JWT/OIDC Auth Method (API) +# JWT/OIDC auth method (API) @include 'x509-sha1-deprecation.mdx' @@ -46,7 +46,7 @@ set. - `provider_config` `(map: )` - Configuration options for provider-specific handling. Providers with specific handling include: Azure, Google, SecureAuth, IBM ISAM. The options are described in each provider's section in [OIDC Provider Setup](/vault/docs/auth/jwt/oidc-providers). - `namespace_in_state` `(bool: true)` - Pass namespace in the OIDC state parameter instead of as a separate query parameter. With this setting, the allowed redirect URL(s) in Vault and on the provider side should not contain a namespace query parameter. This means only one redirect URL entry needs to be maintained on the provider side for all vault namespaces that will be authenticating against it. Defaults to true for new configs. -### Sample Payload +### Sample payload ```json { @@ -55,7 +55,7 @@ set. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -65,7 +65,7 @@ $ curl \ https://127.0.0.1:8200/v1/auth/jwt/config ``` -# Read Config +# Read config Returns the previously configured config. @@ -73,7 +73,7 @@ Returns the previously configured config. | :----- | :----------------- | | `GET` | `/auth/jwt/config` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -81,7 +81,7 @@ $ curl \ https://127.0.0.1:8200/v1/auth/jwt/config ``` -### Sample Response +### Sample response ```json { @@ -95,7 +95,7 @@ $ curl \ } ``` -## Create/Update Role +## Create/Update role Registers a role in the method. Role types have specific entities that can perform login operations against this endpoint. Constraints specific @@ -163,7 +163,7 @@ entities attempting to login. At least one of the bound values must be set. @include 'tokenfields.mdx' -### Sample Payload +### Sample payload ```json { @@ -183,7 +183,7 @@ entities attempting to login. At least one of the bound values must be set. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -193,7 +193,7 @@ $ curl \ https://127.0.0.1:8200/v1/auth/jwt/role/dev-role ``` -## Read Role +## Read role Returns the previously registered role configuration. @@ -205,7 +205,7 @@ Returns the previously registered role configuration. - `name` `(string: )` - Name of the role. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -213,7 +213,7 @@ $ curl \ https://127.0.0.1:8200/v1/auth/jwt/role/dev-role ``` -### Sample Response +### Sample response ```json { @@ -239,7 +239,7 @@ $ curl \ ``` -## List Roles +## List roles Lists all the roles that are registered with the plugin. @@ -247,7 +247,7 @@ Lists all the roles that are registered with the plugin. | :----- | :--------------- | | `LIST` | `/auth/jwt/role` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -256,7 +256,7 @@ $ curl \ https://127.0.0.1:8200/v1/auth/jwt/role ``` -### Sample Response +### Sample response ```json { @@ -270,7 +270,7 @@ $ curl \ } ``` -## Delete Role +## Delete role Deletes the previously registered role. @@ -282,7 +282,7 @@ Deletes the previously registered role. - `name` `(string: )` - Name of the role. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -291,7 +291,7 @@ $ curl \ https://127.0.0.1:8200/v1/auth/jwt/role/dev-role ``` -## OIDC Authorization URL Request +## OIDC authorization URL request Obtain an authorization URL from Vault to start an OIDC login flow. @@ -311,7 +311,7 @@ Obtain an authorization URL from Vault to start an OIDC login flow. must match the `client_nonce` value provided during a subsequent request to the [callback](/vault/api-docs/auth/jwt#oidc-callback) API. -### Sample Payload +### Sample payload ```json { @@ -320,7 +320,7 @@ Obtain an authorization URL from Vault to start an OIDC login flow. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -329,7 +329,7 @@ $ curl \ https://127.0.0.1:8200/v1/auth/jwt/oidc/auth_url ``` -### Sample Response +### Sample response ```json { @@ -341,7 +341,7 @@ $ curl \ } ``` -## OIDC Callback +## OIDC callback Exchange an authorization code for an OIDC ID Token. The ID token will be further validated against any bound claims, and if valid a Vault token will be returned. @@ -362,14 +362,14 @@ against any bound claims, and if valid a Vault token will be returned. match the `client_nonce` value provided during the prior request to the [auth_url](/vault/api-docs/auth/jwt#oidc-authorization-url-request) API. -### Sample Request +### Sample request ```shell-session $ curl \ https://127.0.0.1:8200/v1/auth/jwt/oidc/callback?state=n2kfh3nsl&code=mn2ldl2nv98h2jl&nonce=ni42i2idj2jj ``` -### Sample Response +### Sample response ```json { @@ -388,7 +388,7 @@ $ curl \ } ``` -## JWT Login +## JWT login Fetch a token. This endpoint takes a signed JSON Web Token (JWT) and a role name for some entity. It verifies the JWT signature to authenticate that @@ -404,7 +404,7 @@ entity and then authorizes the entity for the given role. attempted. Defaults to configured `default_role` if not provided. - `jwt` `(string: )` - Signed [JSON Web Token](https://tools.ietf.org/html/rfc7519) (JWT). -### Sample Payload +### Sample payload ```json { @@ -413,7 +413,7 @@ entity and then authorizes the entity for the given role. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -422,7 +422,7 @@ $ curl \ https://127.0.0.1:8200/v1/auth/jwt/login ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/auth/kerberos.mdx b/website/content/api-docs/auth/kerberos.mdx index 52468eb0c8f9..d4eba3baf2d0 100644 --- a/website/content/api-docs/auth/kerberos.mdx +++ b/website/content/api-docs/auth/kerberos.mdx @@ -4,7 +4,7 @@ page_title: Kerberos - Auth Methods - HTTP API description: This is the API documentation for the Vault Kerberos auth method plugin. --- -# Kerberos Auth Method (API) +# Kerberos auth method (API) @include 'x509-sha1-deprecation.mdx' @@ -42,7 +42,7 @@ for verifying inbound SPNEGO tokens. - `add_group_aliases` - When set to true, Vault will add any LDAP groups found for the user as group aliases. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -52,7 +52,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/kerberos/config ``` -### Sample Payload +### Sample payload ```json { @@ -72,7 +72,7 @@ The keytab is not returned because it is sensitive information. | :----- | :---------------------- | | `GET` | `/auth/kerberos/config` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -80,7 +80,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/kerberos/config ``` -### Sample Response +### Sample response ```json { @@ -160,7 +160,7 @@ This endpoint configures LDAP in the Kerberos auth method. @include 'tokenfields.mdx' -### Sample Request +### Sample request ```shell-session $ curl \ @@ -170,7 +170,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/kerberos/config/ldap ``` -### Sample Payload +### Sample payload ```json { @@ -190,7 +190,7 @@ $ curl \ } ``` -## Read Kerberos LDAP Configuration +## Read Kerberos LDAP configuration This endpoint retrieves the LDAP configuration for the Kerberos auth method. @@ -198,7 +198,7 @@ This endpoint retrieves the LDAP configuration for the Kerberos auth method. | :----- | :--------------------------- | | `GET` | `/auth/kerberos/config/ldap` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -206,7 +206,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/kerberos/config/ldap ``` -### Sample Response +### Sample response ```json { @@ -237,7 +237,7 @@ $ curl \ } ``` -## List Kerberos LDAP Groups +## List Kerberos LDAP groups This endpoint returns a list of existing LDAP groups in the Kerberos auth method. @@ -245,7 +245,7 @@ This endpoint returns a list of existing LDAP groups in the Kerberos auth method | :----- | :---------------------- | | `LIST` | `/auth/kerberos/groups` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -254,7 +254,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/kerberos/groups ``` -### Sample Response +### Sample response ```json { @@ -270,7 +270,7 @@ $ curl \ } ``` -## Read Kerberos LDAP Group +## Read Kerberos LDAP group This endpoint returns the policies associated with a Kerberos LDAP group. @@ -282,7 +282,7 @@ This endpoint returns the policies associated with a Kerberos LDAP group. - `name` `(string: )` – The name of the LDAP group. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -290,7 +290,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/kerberos/groups/admins ``` -### Sample Response +### Sample response ```json { @@ -304,7 +304,7 @@ $ curl \ } ``` -## Create/Update Kerberos LDAP Group +## Create/Update Kerberos LDAP group This endpoint creates or updates LDAP group policies. @@ -318,7 +318,7 @@ This endpoint creates or updates LDAP group policies. - `policies` `(string: "")` – Comma-separated list of policies associated to the group. -### Sample Payload +### Sample payload ```json { @@ -326,7 +326,7 @@ This endpoint creates or updates LDAP group policies. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -336,7 +336,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/kerberos/groups/admins ``` -## Delete Kerberos LDAP Group +## Delete Kerberos LDAP group This endpoint deletes the LDAP group and policy association. @@ -348,7 +348,7 @@ This endpoint deletes the LDAP group and policy association. - `name` `(string: )` – The name of the LDAP group. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -400,7 +400,7 @@ sWw | :----- | :--------------------- | | `POST` | `/auth/kerberos/login` | -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/auth/kubernetes.mdx b/website/content/api-docs/auth/kubernetes.mdx index 930540176bdf..f8327b604c34 100644 --- a/website/content/api-docs/auth/kubernetes.mdx +++ b/website/content/api-docs/auth/kubernetes.mdx @@ -4,7 +4,7 @@ page_title: Kubernetes - Auth Methods - HTTP API description: This is the API documentation for the Vault Kubernetes auth method plugin. --- -# Kubernetes Auth Method (API) +# Kubernetes auth method (API) @include 'x509-sha1-deprecation.mdx' @@ -16,7 +16,7 @@ This documentation assumes the Kubernetes method is mounted at the `/auth/kubernetes` path in Vault. Since it is possible to enable auth methods at any location, please update your API calls accordingly. -## Configure Method +## Configure method The Kubernetes auth method validates service account JWTs and verifies their existence with the Kubernetes TokenReview API. This endpoint configures the @@ -43,7 +43,7 @@ access the Kubernetes API. keys. - `disable_local_ca_jwt` `(bool: false)` - Disable defaulting to the local CA cert and service account JWT when running in a Kubernetes pod. -### Deprecated Parameters +### Deprecated parameters -> The following fields have been deprecated and will be removed in a future release: @@ -63,7 +63,7 @@ behavior may be disabled by setting `disable_local_ca_jwt` to `true`. When Vault is running in a non-Kubernetes environment, either `kubernetes_ca_cert` or `pem_keys` must be set by the user. -### Sample Payload +### Sample payload ```json { @@ -73,7 +73,7 @@ When Vault is running in a non-Kubernetes environment, either } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -83,7 +83,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/kubernetes/config ``` -## Read Config +## Read config Returns the previously configured config, excluding credentials. @@ -91,7 +91,7 @@ Returns the previously configured config, excluding credentials. | :----- | :------------------------ | | `GET` | `/auth/kubernetes/config` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -99,7 +99,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/kubernetes/config ``` -### Sample Response +### Sample response ```json { @@ -112,7 +112,7 @@ $ curl \ } ``` -## Create/Update Role +## Create/Update role Registers a role in the auth method. Role types have specific entities that can perform login operations against this endpoint. Constraints specific @@ -143,7 +143,7 @@ entities attempting to login. @include 'tokenfields.mdx' -### Sample Payload +### Sample payload ```json { @@ -154,7 +154,7 @@ entities attempting to login. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -164,7 +164,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/kubernetes/role/dev-role ``` -## Read Role +## Read role Returns the previously registered role configuration. @@ -176,7 +176,7 @@ Returns the previously registered role configuration. - `name` `(string: )` - Name of the role. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -184,7 +184,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/kubernetes/role/dev-role ``` -### Sample Response +### Sample response ```json { @@ -199,7 +199,7 @@ $ curl \ } ``` -## List Roles +## List roles Lists all the roles that are registered with the auth method. @@ -208,7 +208,7 @@ Lists all the roles that are registered with the auth method. | `LIST` | `/auth/kubernetes/role` | | `GET` | `/auth/kubernetes/role?list=true` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -217,7 +217,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/kubernetes/role ``` -### Sample Response +### Sample response ```json { @@ -227,7 +227,7 @@ $ curl \ } ``` -## Delete Role +## Delete role Deletes the previously registered role. @@ -239,7 +239,7 @@ Deletes the previously registered role. - `role` `(string: )` - Name of the role. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -266,7 +266,7 @@ entity and then authorizes the entity for the given role. Token](https://tools.ietf.org/html/rfc7519) (JWT) for authenticating a service account. -### Sample Payload +### Sample payload ```json { @@ -275,7 +275,7 @@ entity and then authorizes the entity for the given role. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -284,7 +284,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/kubernetes/login ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/auth/ldap.mdx b/website/content/api-docs/auth/ldap.mdx index ba514d2f3e5f..ee0bd4c62d64 100644 --- a/website/content/api-docs/auth/ldap.mdx +++ b/website/content/api-docs/auth/ldap.mdx @@ -4,7 +4,7 @@ page_title: LDAP - Auth Methods - HTTP API description: This is the API documentation for the Vault LDAP auth method. --- -# LDAP Auth Method (API) +# LDAP auth method (API) @include 'x509-sha1-deprecation.mdx' @@ -107,7 +107,7 @@ This endpoint configures the LDAP auth method. @include 'ldap-auth-userfilter-warning.mdx' -### Sample Request +### Sample request ```shell-session $ curl \ @@ -117,7 +117,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/ldap/config ``` -### Sample Payload +### Sample payload ```json { @@ -139,7 +139,7 @@ $ curl \ } ``` -## Read LDAP Configuration +## Read LDAP configuration This endpoint retrieves the LDAP configuration for the auth method. @@ -147,7 +147,7 @@ This endpoint retrieves the LDAP configuration for the auth method. | :----- | :------------------ | | `GET` | `/auth/ldap/config` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -155,7 +155,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/ldap/config ``` -### Sample Response +### Sample response ```json { @@ -187,7 +187,7 @@ $ curl \ } ``` -## List LDAP Groups +## List LDAP groups This endpoint returns a list of existing groups in the method. @@ -195,7 +195,7 @@ This endpoint returns a list of existing groups in the method. | :----- | :------------------ | | `LIST` | `/auth/ldap/groups` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -204,7 +204,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/ldap/groups ``` -### Sample Response +### Sample response ```json { @@ -220,7 +220,7 @@ $ curl \ } ``` -## Read LDAP Group +## Read LDAP group This endpoint returns the policies associated with a LDAP group. @@ -232,7 +232,7 @@ This endpoint returns the policies associated with a LDAP group. - `name` `(string: )` – The name of the LDAP group -### Sample Request +### Sample request ```shell-session $ curl \ @@ -240,7 +240,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/ldap/groups/admins ``` -### Sample Response +### Sample response ```json { @@ -257,7 +257,7 @@ $ curl \ } ``` -## Create/Update LDAP Group +## Create/Update LDAP group This endpoint creates or updates LDAP group policies. @@ -271,7 +271,7 @@ This endpoint creates or updates LDAP group policies. - `policies` `(string: "")` – Comma-separated list of policies associated to the group. -### Sample Payload +### Sample payload ```json { @@ -279,7 +279,7 @@ This endpoint creates or updates LDAP group policies. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -289,7 +289,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/ldap/groups/admins ``` -## Delete LDAP Group +## Delete LDAP group This endpoint deletes the LDAP group and policy association. @@ -301,7 +301,7 @@ This endpoint deletes the LDAP group and policy association. - `name` `(string: )` – The name of the LDAP group -### Sample Request +### Sample request ```shell-session $ curl \ @@ -310,7 +310,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/ldap/groups/admins ``` -## List LDAP Users +## List LDAP users This endpoint returns a list of existing users in the method. @@ -318,7 +318,7 @@ This endpoint returns a list of existing users in the method. | :----- | :----------------- | | `LIST` | `/auth/ldap/users` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -327,7 +327,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/ldap/users ``` -### Sample Response +### Sample response ```json { @@ -343,7 +343,7 @@ $ curl \ } ``` -## Read LDAP User +## Read LDAP user This endpoint returns the policies associated with a LDAP user. @@ -355,7 +355,7 @@ This endpoint returns the policies associated with a LDAP user. - `username` `(string: )` – The username of the LDAP user -### Sample Request +### Sample request ```shell-session $ curl \ @@ -363,7 +363,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/ldap/users/mitchellh ``` -### Sample Response +### Sample response ```json { @@ -381,7 +381,7 @@ $ curl \ } ``` -## Create/Update LDAP User +## Create/Update LDAP user This endpoint creates or updates LDAP users policies and group associations. @@ -397,7 +397,7 @@ This endpoint creates or updates LDAP users policies and group associations. - `groups` `(string: "")` – Comma-separated list of groups associated to the user. -### Sample Payload +### Sample payload ```json { @@ -405,7 +405,7 @@ This endpoint creates or updates LDAP users policies and group associations. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -415,7 +415,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/ldap/users/mitchellh ``` -## Delete LDAP User +## Delete LDAP user This endpoint deletes the LDAP user and policy association. @@ -427,7 +427,7 @@ This endpoint deletes the LDAP user and policy association. - `username` `(string: )` – The username of the LDAP user -### Sample Request +### Sample request ```shell-session $ curl \ @@ -436,7 +436,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/ldap/users/mitchellh ``` -## Login with LDAP User +## Login with LDAP user This endpoint allows you to log in with LDAP credentials @@ -449,7 +449,7 @@ This endpoint allows you to log in with LDAP credentials - `username` `(string: )` – The username of the LDAP user - `password` `(string: )` – The password for the LDAP user -### Sample Payload +### Sample payload ```json { @@ -457,7 +457,7 @@ This endpoint allows you to log in with LDAP credentials } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -466,7 +466,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/ldap/login/mitchellh ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/auth/oci.mdx b/website/content/api-docs/auth/oci.mdx index 64ddc1ec7cf4..ed3886ebd2c2 100644 --- a/website/content/api-docs/auth/oci.mdx +++ b/website/content/api-docs/auth/oci.mdx @@ -4,7 +4,7 @@ page_title: OCI - Auth Methods - HTTP API description: This is the API documentation for the Vault OCI auth method plugin. --- -# OCI Auth Method (API) +# OCI auth method (API) This is the API documentation for the Vault OCI auth method plugin. To learn more about the usage and operation, see the @@ -14,7 +14,7 @@ This documentation assumes the OCI method is mounted at the `/auth/oci` path in Vault. Since it is possible to enable auth methods at any location, please update your API calls accordingly. -## Configure Home Tenancy Method +## Configure home tenancy method Configure your home tenancy in the Vault, so that only users or instances from your tenancy will be allowed to log into Vault, through the OCI Auth method. @@ -26,7 +26,7 @@ Configure your home tenancy in the Vault, so that only users or instances from y - `home_tenancy_id` `(string: )` - The Tenancy OCID of your OCI account. -### Sample Payload +### Sample payload ```json { @@ -34,7 +34,7 @@ Configure your home tenancy in the Vault, so that only users or instances from y } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -44,7 +44,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/oci/config ``` -## Read Config +## Read config Returns the previously configured config. @@ -52,7 +52,7 @@ Returns the previously configured config. | :----- | :----------------- | | `GET` | `/auth/oci/config` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -60,7 +60,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/oci/config ``` -### Sample Response +### Sample response ```json { @@ -70,7 +70,7 @@ $ curl \ } ``` -## Create/Update Role +## Create/Update role Create a Vault administrator role in the OCI Auth method. @@ -85,7 +85,7 @@ Create a Vault administrator role in the OCI Auth method. @include 'tokenfields.mdx' -### Sample Payload +### Sample payload ```json { @@ -95,7 +95,7 @@ Create a Vault administrator role in the OCI Auth method. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -105,7 +105,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/oci/role/devrole ``` -## Read Role +## Read role Returns the previously registered role configuration. @@ -117,7 +117,7 @@ Returns the previously registered role configuration. - `name` `(string: )` - Name of the role. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -125,7 +125,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/oci/role/devrole ``` -### Sample Response +### Sample response ```json { @@ -140,7 +140,7 @@ $ curl \ } ``` -## List Roles +## List roles Lists all the roles that are registered with the auth method. @@ -149,7 +149,7 @@ Lists all the roles that are registered with the auth method. | `LIST` | `/auth/oci/role` | | `GET` | `/auth/oci/role?list=true` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -158,7 +158,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/oci/role ``` -### Sample Response +### Sample response ```json { @@ -168,7 +168,7 @@ $ curl \ } ``` -## Delete Role +## Delete role Deletes the previously registered role. @@ -180,7 +180,7 @@ Deletes the previously registered role. - `role` `(string: )` - Name of the role. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -204,7 +204,7 @@ entity and then authorizes the entity for the given role. - `role` `(string: )` - Name of the role against which the login is being attempted. - `request_headers` `(list: [])` - Signed request headers for authenticating. For details on signing, see [signing the request](https://docs.cloud.oracle.com/iaas/Content/API/Concepts/signingrequests.htm) -### Sample Payload +### Sample payload ```json { @@ -220,7 +220,7 @@ entity and then authorizes the entity for the given role. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -229,7 +229,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/oci/login/devrole ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/auth/okta.mdx b/website/content/api-docs/auth/okta.mdx index b3dda440fd6e..5a6ad1eed72a 100644 --- a/website/content/api-docs/auth/okta.mdx +++ b/website/content/api-docs/auth/okta.mdx @@ -4,7 +4,7 @@ page_title: Okta - Auth Methods - HTTP API description: This is the API documentation for the Vault Okta auth method. --- -# Okta Auth Method (API) +# Okta auth method (API) This is the API documentation for the Vault Okta auth method. For general information about the usage and operation of the Okta method, please @@ -14,7 +14,7 @@ This documentation assumes the Okta method is mounted at the `/auth/okta` path in Vault. Since it is possible to enable auth methods at any location, please update your API calls accordingly. -## Create Configuration +## Create configuration Configures the connection parameters for Okta. This path honors the distinction between the `create` and `update` capabilities inside ACL policies. @@ -40,7 +40,7 @@ distinction between the `create` and `update` capabilities inside ACL policies. @include 'tokenfields.mdx' -### Sample Payload +### Sample payload ```json { @@ -49,7 +49,7 @@ distinction between the `create` and `update` capabilities inside ACL policies. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -59,7 +59,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/okta/config ``` -## Read Configuration +## Read configuration Reads the Okta configuration. @@ -67,7 +67,7 @@ Reads the Okta configuration. | :----- | :------------------ | | `GET` | `/auth/okta/config` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -75,7 +75,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/okta/config ``` -### Sample Response +### Sample response ```json { @@ -101,7 +101,7 @@ $ curl \ } ``` -## List Users +## List users List the users configured in the Okta method. @@ -109,7 +109,7 @@ List the users configured in the Okta method. | :----- | :----------------- | | `LIST` | `/auth/okta/users` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -118,7 +118,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/okta/users ``` -### Sample Response +### Sample response ```json { @@ -134,7 +134,7 @@ $ curl \ } ``` -## Register User +## Register user Registers a new user and maps a set of policies to it. @@ -154,7 +154,7 @@ Registers a new user and maps a set of policies to it. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -164,7 +164,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/okta/users/fred ``` -## Read User +## Read user Reads the properties of an existing username. @@ -176,7 +176,7 @@ Reads the properties of an existing username. - `username` `(string: )` - Username for this user. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -184,7 +184,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/okta/users/test-user ``` -### Sample Response +### Sample response ```json { @@ -200,7 +200,7 @@ $ curl \ } ``` -## Delete User +## Delete user Deletes an existing username from the method. @@ -212,7 +212,7 @@ Deletes an existing username from the method. - `username` `(string: )` - Username for this user. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -221,7 +221,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/okta/users/test-user ``` -## List Groups +## List groups List the groups configured in the Okta method. @@ -229,7 +229,7 @@ List the groups configured in the Okta method. | :----- | :------------------ | | `LIST` | `/auth/okta/groups` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -238,7 +238,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/okta/groups ``` -### Sample Response +### Sample response ```json { @@ -254,7 +254,7 @@ $ curl \ } ``` -## Register Group +## Register group Registers a new group and maps a set of policies to it. @@ -273,7 +273,7 @@ Registers a new group and maps a set of policies to it. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -283,7 +283,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/okta/groups/admins ``` -## Read Group +## Read group Reads the properties of an existing group. @@ -295,7 +295,7 @@ Reads the properties of an existing group. - `name` `(string: )` - The name for the group. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -303,7 +303,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/okta/groups/admins ``` -### Sample Response +### Sample response ```json { @@ -318,7 +318,7 @@ $ curl \ } ``` -## Delete Group +## Delete group Deletes an existing group from the method. @@ -330,7 +330,7 @@ Deletes an existing group from the method. - `name` `(string: )` - The name for the group. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -356,7 +356,7 @@ Login with the username and password. - `nonce` `(string: )` - Nonce provided during a login request to retrieve the number verification challenge for the matching request. -### Sample Payload +### Sample payload ```json { @@ -364,7 +364,7 @@ Login with the username and password. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -373,7 +373,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/okta/login/fred ``` -### Sample Response +### Sample response ```json { @@ -410,14 +410,14 @@ Verify a number challenge that may result from an Okta Verify Push challenge. requires number verification challenge. Logins through the vault login CLI command will automatically generate a nonce. -### Sample Request +### Sample request ```shell-session $ curl \ http://127.0.0.1:8200/v1/auth/okta/verify/nonce/BCR66Ru6oJKPtC00PxJJ ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/auth/radius.mdx b/website/content/api-docs/auth/radius.mdx index ec139ceac4c7..ba71ec2ceb5a 100644 --- a/website/content/api-docs/auth/radius.mdx +++ b/website/content/api-docs/auth/radius.mdx @@ -4,7 +4,7 @@ page_title: RADIUS - Auth Methods - HTTP API description: This is the API documentation for the Vault RADIUS auth method. --- -# RADIUS Auth Method (API) +# RADIUS auth method (API) This is the API documentation for the Vault RADIUS auth method. For general information about the usage and operation of the RADIUS method, please @@ -39,7 +39,7 @@ RADIUS. @include 'tokenfields.mdx' -### Sample Payload +### Sample payload ```json { @@ -49,7 +49,7 @@ RADIUS. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -59,7 +59,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/radius/config ``` -## Register User +## Register user Registers a new user and maps a set of policies to it. This path honors the distinction between the `create` and `update` capabilities inside ACL policies. @@ -80,7 +80,7 @@ distinction between the `create` and `update` capabilities inside ACL policies. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -90,7 +90,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/radius/users/test-user ``` -## Read User +## Read user Reads the properties of an existing username. @@ -102,7 +102,7 @@ Reads the properties of an existing username. - `username` `(string: )` - Username for this user. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -110,7 +110,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/radius/users/test-user ``` -### Sample Response +### Sample response ```json { @@ -125,7 +125,7 @@ $ curl \ } ``` -## Delete User +## Delete user Deletes an existing username from the method. @@ -137,7 +137,7 @@ Deletes an existing username from the method. - `username` `(string: )` - Username for this user. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -146,7 +146,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/radius/users/test-user ``` -## List Users +## List users List the users registered with the method. @@ -154,7 +154,7 @@ List the users registered with the method. | :----- | :------------------- | | `LIST` | `/auth/radius/users` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -163,7 +163,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/radius/users ``` -### Sample Response +### Sample response ```json { @@ -193,7 +193,7 @@ Login with the username and password. - `username` `(string: )` - Username for this user. - `password` `(string: )` - Password for the authenticating user. -### Sample Payload +### Sample payload ```json { @@ -201,7 +201,7 @@ Login with the username and password. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -210,7 +210,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/radius/login/test-user ``` -### Sample Response +### Sample response ```javascript { diff --git a/website/content/api-docs/auth/token.mdx b/website/content/api-docs/auth/token.mdx index 7b876f055ab6..5301b17702ab 100644 --- a/website/content/api-docs/auth/token.mdx +++ b/website/content/api-docs/auth/token.mdx @@ -4,13 +4,13 @@ page_title: Token - Auth Methods - HTTP API description: This is the API documentation for the Vault token auth method. --- -# Token Auth Method (API) +# Token auth method (API) This is the API documentation for the Vault token auth method. For general information about the usage and operation of the token method, please see the [Vault Token method documentation](/vault/docs/auth/token). -## List Accessors +## List accessors This endpoint lists token accessor. This requires `sudo` capability, and access to it should be tightly controlled as the accessors can be used to revoke very @@ -20,7 +20,7 @@ large numbers of tokens and their associated leases at once. | :----- | :---------------------- | | `LIST` | `/auth/token/accessors` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -29,7 +29,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/token/accessors ``` -### Sample Response +### Sample response ```json { @@ -48,7 +48,7 @@ $ curl \ } ``` -## Create Token +## Create token Creates a new token. Certain options are only available when called by a root token. If used via the `/auth/token/create-orphan` endpoint, a root @@ -109,7 +109,7 @@ during this call. and used entity alias must be listed in `allowed_entity_aliases`. If this has been specified, the entity will not be inherited from the parent. -### Sample Payload +### Sample payload ```json { @@ -122,7 +122,7 @@ during this call. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -132,7 +132,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/token/create ``` -### Sample Response +### Sample response ```json { @@ -164,7 +164,7 @@ $ curl \ } ``` -## Lookup a Token +## Lookup a token Returns information about the client token. @@ -176,7 +176,7 @@ Returns information about the client token. - `token` `(string: )` - Token to lookup. -### Sample Payload +### Sample payload ```json { @@ -184,7 +184,7 @@ Returns information about the client token. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -194,7 +194,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/token/lookup ``` -### Sample Response +### Sample response ```json { @@ -222,7 +222,7 @@ $ curl \ } ``` -## Lookup a Token (Self) +## Lookup a token (Self) Returns information about the current client token. @@ -230,7 +230,7 @@ Returns information about the current client token. | :----- | :------------------------ | | `GET` | `/auth/token/lookup-self` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -238,7 +238,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/token/lookup-self ``` -### Sample Response +### Sample response ```json { @@ -266,7 +266,7 @@ $ curl \ } ``` -## Lookup a Token (Accessor) +## Lookup a token (Accessor) Returns information about the client token from the accessor. @@ -278,7 +278,7 @@ Returns information about the client token from the accessor. - `accessor` `(string: )` - Token accessor to lookup. -### Sample Payload +### Sample payload ```json { @@ -286,7 +286,7 @@ Returns information about the client token from the accessor. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -296,7 +296,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/token/lookup-accessor ``` -### Sample Response +### Sample response ```json { @@ -324,7 +324,7 @@ $ curl \ } ``` -## Renew a Token +## Renew a token Renews a lease associated with a token. This is used to prevent the expiration of a token, and the automatic revocation of it. Token renewal is possible only @@ -343,7 +343,7 @@ if there is a lease associated with it. If not supplied, Vault will use the default TTL. This is specified as a numeric string with suffix like "30s" or "5m". -### Sample Payload +### Sample payload ```json { @@ -351,7 +351,7 @@ if there is a lease associated with it. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -361,7 +361,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/token/renew ``` -### Sample Response +### Sample response ```json { @@ -377,7 +377,7 @@ $ curl \ } ``` -## Renew a Token (Self) +## Renew a token (Self) Renews a lease associated with the calling token. This is used to prevent the expiration of a token, and the automatic revocation of it. Token renewal is @@ -394,7 +394,7 @@ possible only if there is a lease associated with it. If not supplied, Vault will use the default TTL. This is specified as a numeric string with suffix like "30s" or "5m". -### Sample Payload +### Sample payload ```json { @@ -402,7 +402,7 @@ possible only if there is a lease associated with it. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -412,7 +412,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/token/renew-self ``` -### Sample Response +### Sample response ```json { @@ -428,7 +428,7 @@ $ curl \ } ``` -## Renew a Token (Accessor) +## Renew a token (Accessor) Renews a lease associated with a token using its accessor. This is used to prevent the expiration of a token, and the automatic revocation of it. Token @@ -445,7 +445,7 @@ renewal is possible only if there is a lease associated with it. - `increment` `(string: "")` - An optional requested lease increment can be provided. This increment may be ignored. -### Sample Payload +### Sample payload ```json { @@ -453,7 +453,7 @@ renewal is possible only if there is a lease associated with it. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -463,7 +463,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/token/renew-accessor ``` -### Sample Response +### Sample response ```json { @@ -479,7 +479,7 @@ $ curl \ } ``` -## Revoke a Token +## Revoke a token Revokes a token and all child tokens. When the token is revoked, all dynamic secrets generated with it are also revoked. @@ -492,7 +492,7 @@ generated with it are also revoked. - `token` `(string: )` - Token to revoke. -### Sample Payload +### Sample payload ```json { @@ -500,7 +500,7 @@ generated with it are also revoked. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -510,7 +510,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/token/revoke ``` -## Revoke a Token (Self) +## Revoke a token (Self) Revokes the token used to call it and all child tokens. When the token is revoked, all dynamic secrets generated with it are also revoked. @@ -519,7 +519,7 @@ revoked, all dynamic secrets generated with it are also revoked. | :----- | :------------------------ | | `POST` | `/auth/token/revoke-self` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -528,7 +528,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/token/revoke-self ``` -## Revoke a Token Accessor +## Revoke a token accessor Revoke the token associated with the accessor and all the child tokens. This is meant for purposes where there is no access to token ID but there is need to @@ -542,7 +542,7 @@ revoke a token and its children. - `accessor` `(string: )` - Accessor of the token. -### Sample Payload +### Sample payload ```json { @@ -550,7 +550,7 @@ revoke a token and its children. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -560,7 +560,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/token/revoke-accessor ``` -## Revoke Token and Orphan Children +## Revoke token and orphan children Revokes a token but not its child tokens. When the token is revoked, all secrets generated with it are also revoked. All child tokens are orphaned, but can be @@ -576,7 +576,7 @@ endpoint. - `token` `(string: )` - Token to revoke. This can be part of the URL or the body. -### Sample Payload +### Sample payload ```json { @@ -584,7 +584,7 @@ endpoint. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -594,7 +594,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/token/revoke-orphan ``` -## Read Token Role +## Read token role Fetches the named role configuration. @@ -606,7 +606,7 @@ Fetches the named role configuration. - `role_name` `(string: )` - The name of the token role. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -614,7 +614,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/token/roles/nomad ``` -### Sample Response +### Sample response ```javascript { @@ -645,7 +645,7 @@ $ curl \ } ``` -## List Token Roles +## List token roles List available token roles. @@ -653,7 +653,7 @@ List available token roles. | :----- | :------------------ | | `LIST` | `/auth/token/roles` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -662,7 +662,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/token/roles ``` -### Sample Response +### Sample response ```json { @@ -672,7 +672,7 @@ $ curl \ } ``` -## Create/Update Token Role +## Create/Update token role Creates (or replaces) the named role. Roles enforce specific behavior when creating tokens that allow token functionality that is otherwise not @@ -739,7 +739,7 @@ tokens created against a role to be revoked using the @include 'tokenstorefields.mdx' -### Sample Payload +### Sample payload ```json "allowed_policies": [ @@ -752,7 +752,7 @@ tokens created against a role to be revoked using the "allowed_entity_aliases": ["web-entity-alias", "app-entity-*"] ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -762,7 +762,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/token/roles/nomad ``` -## Delete Token Role +## Delete token role This endpoint deletes the named token role. @@ -774,7 +774,7 @@ This endpoint deletes the named token role. - `role_name` `(string: )` - The name of the token role. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -783,7 +783,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/token/roles/admins ``` -## Tidy Tokens +## Tidy tokens Performs some maintenance tasks to clean up invalid entries that may remain in the token store. On Enterprise, Tidy will only impact the tokens in the @@ -824,7 +824,7 @@ valid in the above steps will be deleted. | :----- | :----------------- | | `POST` | `/auth/token/tidy` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -833,7 +833,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/token/tidy ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/auth/userpass.mdx b/website/content/api-docs/auth/userpass.mdx index 737c121c7ad9..940176b1cc26 100644 --- a/website/content/api-docs/auth/userpass.mdx +++ b/website/content/api-docs/auth/userpass.mdx @@ -6,7 +6,7 @@ description: |- auth method. --- -# Userpass Auth Method (HTTP API) +# Userpass auth method (HTTP API) This is the API documentation for the Vault Username & Password auth method. For general information about the usage and operation of the Username and Password method, please @@ -16,7 +16,7 @@ This documentation assumes the Username & Password method is mounted at the `/au path in Vault. Since it is possible to enable auth methods at any location, please update your API calls accordingly. -## Create/Update User +## Create/Update user Create a new user or update an existing user. This path honors the distinction between the `create` and `update` capabilities inside ACL policies. @@ -32,7 +32,7 @@ Create a new user or update an existing user. This path honors the distinction b @include 'tokenfields.mdx' -### Sample Payload +### Sample payload ```json { @@ -42,7 +42,7 @@ Create a new user or update an existing user. This path honors the distinction b } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -52,7 +52,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/userpass/users/mitchellh ``` -## Read User +## Read user Reads the properties of an existing username. @@ -60,7 +60,7 @@ Reads the properties of an existing username. | :----- | :------------------------------- | | `GET` | `/auth/userpass/users/:username` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -68,7 +68,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/userpass/users/mitchellh ``` -### Sample Response +### Sample response ```json { @@ -99,7 +99,7 @@ $ curl \ } ``` -## Delete User +## Delete user This endpoint deletes the user from the method. @@ -111,7 +111,7 @@ This endpoint deletes the user from the method. - `username` `(string: )` - The username for the user. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -120,7 +120,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/userpass/users/mitchellh ``` -## Update Password on User +## Update password on user Update password for an existing user. @@ -133,7 +133,7 @@ Update password for an existing user. - `username` `(string: )` – The username for the user. - `password` `(string: )` - The password for the user. -### Sample Payload +### Sample payload ```json { @@ -141,7 +141,7 @@ Update password for an existing user. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -151,7 +151,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/userpass/users/mitchellh/password ``` -## Update Policies on User +## Update policies on user Update policies for an existing user. @@ -166,7 +166,7 @@ Update policies for an existing user. policies to encode onto generated tokens. Depending on the auth method, this list may be supplemented by user/group/other values. -### Sample Payload +### Sample payload ```json { @@ -174,7 +174,7 @@ Update policies for an existing user. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -184,7 +184,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/userpass/users/mitchellh/policies ``` -## List Users +## List users List available userpass users. @@ -192,7 +192,7 @@ List available userpass users. | :----- | :--------------------- | | `LIST` | `/auth/userpass/users` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -201,7 +201,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/userpass/users ``` -### Sample Response +### Sample response ```json { @@ -224,7 +224,7 @@ Login with the username and password. - `username` `(string: )` – The username for the user. - `password` `(string: )` - The password for the user. -### Sample Payload +### Sample payload ```json { @@ -232,7 +232,7 @@ Login with the username and password. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -241,7 +241,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/userpass/login/mitchellh ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/index.mdx b/website/content/api-docs/index.mdx index 156b03c7d48b..2d8a651896a1 100644 --- a/website/content/api-docs/index.mdx +++ b/website/content/api-docs/index.mdx @@ -83,7 +83,7 @@ $ curl \ http://127.0.0.1:8200/v1/ns1/ns2/secret/foo ``` -## API Operations +## API operations Typically the request data, body and response data to and from Vault is in JSON. Vault sets the `Content-Type` header appropriately with its response and does @@ -177,7 +177,7 @@ $ curl \ For more examples, please look at the Vault API client. -## The `X-Vault-Request` Header +## The `X-Vault-Request` header Requests that are sent to a [Vault Proxy][proxy] that is configured to use the `require_request_header` option must include the `X-Vault-Request` header @@ -256,7 +256,7 @@ Example response: } ``` -## Error Response +## Error response A common JSON structure is always returned to return errors: @@ -271,7 +271,7 @@ A common JSON structure is always returned to return errors: This structure will be returned for any HTTP status greater than or equal to 400. -## HTTP Status Codes +## HTTP status codes The following HTTP status codes are used throughout the API. Vault tries to adhere to these whenever possible, but in case it doesn't -- then feel free to diff --git a/website/content/api-docs/relatedtools.mdx b/website/content/api-docs/relatedtools.mdx index 6a3f8da06c01..ee36237bb092 100644 --- a/website/content/api-docs/relatedtools.mdx +++ b/website/content/api-docs/relatedtools.mdx @@ -4,9 +4,9 @@ page_title: Related Tools description: Short list of third-party tools that work with or are related to Vault. --- -# Related Tools +# Related tools -## HashiCorp Tools +## HashiCorp tools - [Vault Agent](/vault/docs/agent-and-proxy/agent) can render Vault secrets either to files or directly into a child process as environment variables using `consul-template` templating syntax - [Vault Proxy](/vault/docs/agent-and-proxy/proxy) acts as an API Proxy for Vault, and can optionally allow or force interacting clients to use its automatically authenticated token @@ -14,7 +14,7 @@ description: Short list of third-party tools that work with or are related to Va - [consul-template](https://github.com/hashicorp/consul-template) is a template renderer, notifier, and supervisor for HashiCorp Consul and Vault data - [vault-ssh-helper](https://github.com/hashicorp/vault-ssh-helper) can be used to enable one-time passwords for SSH authentication via Vault -## Third-Party Tools +## Third-Party tools The following list of tools is maintained by the community of Vault users; HashiCorp has not tested or approved them and makes no claims as to their suitability or security. diff --git a/website/content/api-docs/secret/ad.mdx b/website/content/api-docs/secret/ad.mdx index 7c76bdf5833a..ca9494ba08db 100644 --- a/website/content/api-docs/secret/ad.mdx +++ b/website/content/api-docs/secret/ad.mdx @@ -4,7 +4,7 @@ page_title: Active Directory - Secrets Engines - HTTP API description: This is the API documentation for the Vault Active Directory secrets engine. --- -# Active Directory Secrets Engine (API) +# Active directory secrets engine (API) @include 'ad-secrets-deprecation.mdx' @@ -80,7 +80,7 @@ valid AD credentials with proper permissions. | `GET` | `/ad/config` | | `DELETE` | `/ad/config` | -### Sample Post Request +### Sample post request @@ -107,7 +107,7 @@ $ vault write ad/config \ -### Sample Post Payload +### Sample post payload ```json { @@ -118,7 +118,7 @@ $ vault write ad/config \ } ``` -### Sample Get Response Data +### Sample get response data ```json { @@ -155,7 +155,7 @@ When adding a role, Vault verifies its associated service account exists. | `GET` | `/ad/roles/:role_name` | | `DELETE` | `/ad/roles/:role_name` | -### Sample Post Request +### Sample post request @@ -180,7 +180,7 @@ $ vault write ad/roles/my-application \ -### Sample Post Payload +### Sample post payload ```json { @@ -189,7 +189,7 @@ $ vault write ad/roles/my-application \ } ``` -### Sample Get Role Response +### Sample get role response ```json { @@ -200,7 +200,7 @@ $ vault write ad/roles/my-application \ } ``` -### Sample List Roles Response +### Sample list roles response Performing a `LIST` on the `/ad/roles` endpoint will list the names of all the roles Vault contains. @@ -216,7 +216,7 @@ The `creds` endpoint offers the credential information for a given role. | :----- | :--------------------- | | `GET` | `/ad/creds/:role_name` | -### Sample Get Request +### Sample get request @@ -238,7 +238,7 @@ $ vault read ad/creds/my-application -### Sample Get Response +### Sample get response ```json { @@ -276,7 +276,7 @@ When adding a service account to the library, Vault verifies it already exists i | `GET` | `/ad/library/:set_name` | | `DELETE` | `/ad/library/:set_name` | -### Sample Post Request +### Sample post request ```shell-session $ curl \ @@ -286,7 +286,7 @@ $ curl \ http://127.0.0.1:8200/v1/ad/library/accounting-team ``` -### Sample Post Payload +### Sample post payload ```json { @@ -297,7 +297,7 @@ $ curl \ } ``` -### Sample Get Response +### Sample get response ```json { @@ -308,7 +308,7 @@ $ curl \ } ``` -### Sample List Response +### Sample list response Performing a `LIST` on the `/ad/library` endpoint will list the names of all the sets of service accounts Vault contains. @@ -334,7 +334,7 @@ Returns a `200` if a credential is available, and a `400` if no credential is av | :----- | :-------------------------------- | | `POST` | `/ad/library/:set_name/check-out` | -### Sample Post Request +### Sample post request ```shell-session $ curl \ @@ -344,7 +344,7 @@ $ curl \ http://127.0.0.1:8200/v1/ad/library/accounting-team/check-out ``` -### Sample Post Payload +### Sample post payload ```json { @@ -352,7 +352,7 @@ $ curl \ } ``` -### Sample Post Response +### Sample post response ```json { @@ -392,7 +392,7 @@ in _by this particular call_. | `POST` | `/ad/library/:set_name/check-in` | | `POST` | `/ad/library/manage/:set_name/check-in` | -### Sample Post Request +### Sample post request ```shell-session $ curl \ @@ -402,7 +402,7 @@ $ curl \ http://127.0.0.1:8200/v1/ad/library/accounting-team/check-in ``` -### Sample Post Payload +### Sample post payload ```json { @@ -410,7 +410,7 @@ $ curl \ } ``` -### Sample Post Response +### Sample post response ```json { @@ -433,7 +433,7 @@ $ curl \ | :----- | :----------------------------- | | `GET` | `/ad/library/:set_name/status` | -### Sample Get Request +### Sample get request ```shell-session $ curl \ @@ -442,7 +442,7 @@ $ curl \ http://127.0.0.1:8200/v1/ad/library/accounting-team/status ``` -### Sample Get Response +### Sample get response ```json { @@ -466,7 +466,7 @@ $ curl \ } ``` -## Rotate Root Credentials +## Rotate root credentials Rotate the `bindpass` to a new one known only to Vault. @@ -475,7 +475,7 @@ Rotate the `bindpass` to a new one known only to Vault. 1. When the `bindpass` is rotated, it successfully gets rotated in Active Directory but Vault can't store it so it becomes unknown. 2. If the `binddn` in use applies to more than one entity in Active Directory, root credential rotation will fail because it's unclear which entity to perform the operation for. -### Mitigating Risks +### Mitigating risks 1. Always have another account that can provision a new `binddn` and `bindpass` to replace one whose password becomes unknown. 2. Ensure the `binddn` in use only applies to one entity by including all distinguished name parameters possible. For example, use `"CN=vault-ad-test,CN=Users,DC=example,DC=com"` instead of `"CN=vault-ad-test"`. @@ -489,7 +489,7 @@ Rotate the `bindpass` to a new one known only to Vault. Generally, `rotate-root` returns a 204. However, if `rotate-root` is already in progress, it may return a 200 with a warning that root credential rotation is already in progress. -### Sample Get Request +### Sample get request ```shell-session $ curl \ @@ -498,7 +498,7 @@ $ curl \ http://127.0.0.1:8200/v1/ad/rotate-root ``` -### Sample Post Request +### Sample post request ```shell-session $ curl \ @@ -507,7 +507,7 @@ $ curl \ http://127.0.0.1:8200/v1/ad/rotate-root ``` -## Rotate Role Credentials +## Rotate role credentials Manually rotate the password of a managed Active Directory service account. @@ -519,7 +519,7 @@ Manually rotate the password of a managed Active Directory service account. Generally, `rotate-role` returns a 204. However, if `rotate-role` is already in progress, it may return a 200 with a warning that credential rotation is already in progress. -### Sample Post Request +### Sample post request ```shell-session $ curl \ diff --git a/website/content/api-docs/secret/alicloud.mdx b/website/content/api-docs/secret/alicloud.mdx index 14630697bcfb..48bb366f9696 100644 --- a/website/content/api-docs/secret/alicloud.mdx +++ b/website/content/api-docs/secret/alicloud.mdx @@ -4,7 +4,7 @@ page_title: AliCloud - Secrets Engines - HTTP API description: This is the API documentation for the Vault AliCloud secrets engine. --- -# AliCloud Secrets Engine (API) +# AliCloud secrets engine (API) This is the API documentation for the Vault AliCloud secrets engine. For general information about the usage and operation of the AliCloud secrets engine, please see @@ -41,7 +41,7 @@ the policies that should be attached to the access key you provide. - `access_key` (string, required) - The ID of an access key with appropriate policies. - `secret_key` (string, required) - The secret for that key. -### Sample Post Request +### Sample post request ```shell-session $ curl \ @@ -51,7 +51,7 @@ $ curl \ http://127.0.0.1:8200/v1/alicloud/config ``` -### Sample Post Payload +### Sample post payload ```json { @@ -60,7 +60,7 @@ $ curl \ } ``` -### Sample Get Response Data +### Sample get response data ```json { @@ -88,7 +88,7 @@ The `role` endpoint configures how Vault will generate credentials for users of | `GET` | `/alicloud/role/:role_name` | | `DELETE` | `/alicloud/role/:role_name` | -### Sample Post Request +### Sample post request ```shell-session $ curl \ @@ -98,7 +98,7 @@ $ curl \ http://127.0.0.1:8200/v1/alicloud/role/my-application ``` -### Sample Post Payload Using Policies +### Sample post payload using policies ```json { @@ -110,7 +110,7 @@ $ curl \ } ``` -### Sample Get Role Response Using Policies +### Sample get role response using policies ```json { @@ -145,7 +145,7 @@ $ curl \ } ``` -### Sample Post Payload Using Assume-Role +### Sample post payload using Assume-Role ```json { @@ -153,7 +153,7 @@ $ curl \ } ``` -### Sample Get Role Response Using Assume-Role +### Sample get role response using Assume-Role ```json { @@ -165,7 +165,7 @@ $ curl \ } ``` -### Sample List Roles Response +### Sample list roles response Performing a `LIST` on the `/alicloud/roles` endpoint will list the names of all the roles Vault contains. @@ -173,7 +173,7 @@ Performing a `LIST` on the `/alicloud/roles` endpoint will list the names of all ["policy-based", "role-based"] ``` -## Generate RAM Credentials +## Generate RAM credentials This endpoint generates dynamic RAM credentials based on the named role. This role must be created before queried. @@ -186,7 +186,7 @@ role must be created before queried. - `name` (string, required) – Specifies the name of the role to generate credentials against. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -194,7 +194,7 @@ $ curl \ http://127.0.0.1:8200/v1/alicloud/creds/example-role ``` -### Sample Response for Roles Using Policies +### Sample response for roles using policies ```json { @@ -203,7 +203,7 @@ $ curl \ } ``` -### Sample Response for Roles Using Assume-Role +### Sample response for roles using Assume-Role ```json { diff --git a/website/content/api-docs/secret/aws.mdx b/website/content/api-docs/secret/aws.mdx index 9a13139ba912..54cfdbbfab33 100644 --- a/website/content/api-docs/secret/aws.mdx +++ b/website/content/api-docs/secret/aws.mdx @@ -4,7 +4,7 @@ page_title: AWS - Secrets Engines - HTTP API description: This is the API documentation for the Vault AWS secrets engine. --- -# AWS Secrets Engine (API) +# AWS secrets engine (API) This is the API documentation for the Vault AWS secrets engine. For general information about the usage and operation of the AWS secrets engine, please see @@ -14,7 +14,7 @@ This documentation assumes the AWS secrets engine is enabled at the `/aws` path in Vault. Since it is possible to enable secrets engines at any location, please update your API calls accordingly. -## Configure Root IAM Credentials +## Configure root IAM credentials This endpoint configures the root IAM credentials to communicate with AWS. There are multiple ways to pass root IAM credentials to the Vault server, specified @@ -76,7 +76,7 @@ valid AWS credentials with proper permissions. {{ end }} ``` -### Sample Payload +### Sample payload ```json { @@ -86,7 +86,7 @@ valid AWS credentials with proper permissions. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -96,7 +96,7 @@ $ curl \ http://127.0.0.1:8200/v1/aws/config/root ``` -## Read Root Configuration +## Read root configuration This endpoint allows you to read non-secure values that have been configured in the `config/root` endpoint. In particular, the `secret_key` parameter is never returned. @@ -105,7 +105,7 @@ This endpoint allows you to read non-secure values that have been configured in | :----- | :----------------- | | `GET` | `/aws/config/root` | -### Sample Request +### Sample request ```shell-session $ curl @@ -114,7 +114,7 @@ $ curl ``` -### Sample Response +### Sample response ```json { @@ -128,7 +128,7 @@ $ curl } ``` -## Rotate Root IAM Credentials +## Rotate root IAM credentials When you have configured Vault with static credentials, you can use this endpoint to have Vault rotate the access key it used. Note that, due to AWS @@ -148,7 +148,7 @@ secret key is used to access AWS. There are no parameters to this operation. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -157,7 +157,7 @@ $ curl \ http://127.0.0.1:8200/v1/aws/config/rotate-root ``` -### Sample Response +### Sample response ```json { @@ -169,7 +169,7 @@ $ curl \ The new access key Vault uses is returned by this operation. -## Configure Lease +## Configure lease This endpoint configures lease settings for the AWS secrets engine. It is optional, as there are default values for `lease` and `lease_max`. @@ -187,7 +187,7 @@ optional, as there are default values for `lease` and `lease_max`. provided as a string duration with time suffix. "h" (hour) is the largest suffix. -### Sample Payload +### Sample payload ```json { @@ -196,7 +196,7 @@ optional, as there are default values for `lease` and `lease_max`. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -206,7 +206,7 @@ $ curl \ http://127.0.0.1:8200/v1/aws/config/lease ``` -## Read Lease +## Read lease This endpoint returns the current lease settings for the AWS secrets engine. @@ -214,7 +214,7 @@ This endpoint returns the current lease settings for the AWS secrets engine. | :----- | :------------------ | | `GET` | `/aws/config/lease` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -222,7 +222,7 @@ $ curl \ http://127.0.0.1:8200/v1/aws/config/lease ``` -### Sample Response +### Sample response ```json { @@ -233,7 +233,7 @@ $ curl \ } ``` -## Create/Update Role +## Create/Update role This endpoint creates or updates the role with the given `name`. If a role with the name does not exist, it will be created. If the role exists, it will be @@ -313,7 +313,7 @@ mixed with the parameters listed above. - `arn` `(string: )` – Specifies the full ARN reference to the desired existing policy. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -323,7 +323,7 @@ $ curl \ http://127.0.0.1:8200/v1/aws/roles/example-role ``` -### Sample Payloads +### Sample payloads Using an inline IAM policy: @@ -406,7 +406,7 @@ Using tags: -## Read Role +## Read role This endpoint queries an existing role by the given name. If the role does not exist, a 404 is returned. @@ -423,7 +423,7 @@ then it will show up in the response as `invalid_data`. - `name` `(string: )` – Specifies the name of the role to read. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -431,7 +431,7 @@ $ curl \ http://127.0.0.1:8200/v1/aws/roles/example-role ``` -### Sample Responses +### Sample responses For an inline IAM policy: @@ -475,7 +475,7 @@ For IAM groups: } ``` -## List Roles +## List roles This endpoint lists all existing roles in the secrets engine. @@ -483,7 +483,7 @@ This endpoint lists all existing roles in the secrets engine. | :----- | :----------- | | `LIST` | `/aws/roles` | -### Sample Request +### Sample request ```shell-session $ curl @@ -492,7 +492,7 @@ $ curl http://127.0.0.1:8200/v1/aws/roles ``` -### Sample Response +### Sample response ```json { @@ -502,7 +502,7 @@ $ curl } ``` -## Delete Role +## Delete role This endpoint deletes an existing role by the given name. If the role does not exist, a 404 is returned. @@ -516,7 +516,7 @@ exist, a 404 is returned. - `name` `(string: )` – Specifies the name of the role to delete. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -525,7 +525,7 @@ $ curl \ http://127.0.0.1:8200/v1/aws/roles/example-role ``` -## Generate Credentials +## Generate credentials This endpoint generates credentials based on the named role. This role must be created before queried. @@ -565,7 +565,7 @@ credentials retrieved through `/aws/creds` must be of the `iam_user` type. [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) (for `federation_token` credential types) for more details. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -573,7 +573,7 @@ $ curl \ http://127.0.0.1:8200/v1/aws/creds/example-role ``` -### Sample Response +### Sample response ```json { @@ -586,7 +586,7 @@ $ curl \ } ``` -## Create Static Role +## Create static role This endpoint creates or updates static role definitions. A static role is a 1-to-1 mapping with an AWS IAM User, which will be adopted and managed by Vault, including rotating it according to the configured `rotation_period`. @@ -614,7 +614,7 @@ is specified as part of the URL. Vault should wait before rotating the password. The minimum is 1 minute. Can be specified in either `24h` or `86400` format (see [duration format strings](/vault/docs/concepts/duration-format)). -### Sample Payload +### Sample payload ```json { @@ -623,7 +623,7 @@ specified in either `24h` or `86400` format (see [duration format strings](/vaul } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -633,9 +633,9 @@ $ curl \ http://127.0.0.1:8200/v1/aws/static-roles/my-static-role ``` -### Sample Response +### Sample response -## Read Static Role +## Read static role This endpoint queries the static role definition. @@ -648,7 +648,7 @@ This endpoint queries the static role definition. - `name` `(string: )` – Specifies the name of the static role to read. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -656,7 +656,7 @@ $ curl \ --request GET \ http://127.0.0.1:8200/v1/aws/static-roles/my-static-role ``` -### Sample Response +### Sample response ```json { @@ -666,7 +666,7 @@ $ curl \ } ``` -## Delete Static Role +## Delete static role This endpoint deletes the static role definition. The user, having been defined externally, must be cleaned up manually. @@ -680,7 +680,7 @@ must be cleaned up manually. - `name` `(string: )` – Specifies the name of the static role to delete. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -689,7 +689,7 @@ $ curl \ http://127.0.0.1:8200/v1/aws/static-roles/my-static-role ``` -## Get Static Credentials +## Get static credentials This endpoint returns the current credentials based on the named static role. @@ -702,7 +702,7 @@ This endpoint returns the current credentials based on the named static role. - `name` `(string: )` – Specifies the name of the static role to get credentials for. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -710,7 +710,7 @@ $ curl \ http://127.0.0.1:8200/v1/aws/static-creds/my-static-role ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/secret/azure.mdx b/website/content/api-docs/secret/azure.mdx index fee3fd46fae4..f0ced9b035ca 100644 --- a/website/content/api-docs/secret/azure.mdx +++ b/website/content/api-docs/secret/azure.mdx @@ -4,7 +4,7 @@ page_title: Azure - Secrets Engines - HTTP API description: This is the API documentation for the Vault Azure secrets engine. --- -# Azure Secrets Engine (API) +# Azure secrets engine (API) This is the API documentation for the Vault Azure secrets engine. For general information about the usage and operation of @@ -14,7 +14,7 @@ This documentation assumes the Azure secrets engine is enabled at the `/azure` p in Vault. Since it is possible to mount secrets engines at any path, please update your API calls accordingly. -## Configure Access +## Configure access Configures the credentials required for the plugin to perform API calls to Azure. These credentials will be used to query roles and create/delete @@ -39,7 +39,7 @@ service principals. Environment variables will override any parameters set in th - `root_password_ttl` `(string: 182d)` - Specifies how long the root password is valid for in Azure when rotate-root generates a new client secret. Uses [duration format strings](/vault/docs/concepts/duration-format). -### Sample Payload +### Sample payload ```json { @@ -53,7 +53,7 @@ service principals. Environment variables will override any parameters set in th } ``` -### Sample Request +### Sample request @@ -82,7 +82,7 @@ $ vault write azure/config \ -## Read Config +## Read config Return the stored configuration, omitting `client_secret`. @@ -90,7 +90,7 @@ Return the stored configuration, omitting `client_secret`. | :----- | :-------------- | | `GET` | `/azure/config` | -### Sample Request +### Sample request @@ -112,7 +112,7 @@ $ vault read azure/config -### Sample Response +### Sample response ```json { @@ -126,7 +126,7 @@ $ vault read azure/config } ``` -## Delete Config +## Delete config Deletes the stored Azure configuration and credentials. @@ -134,7 +134,7 @@ Deletes the stored Azure configuration and credentials. | :------- | :-------------- | | `DELETE` | `/azure/config` | -### Sample Request +### Sample request @@ -156,7 +156,7 @@ $ vault delete azure/config -## Rotate Root +## Rotate root This endpoint generates a new client secret for the root account defined in the config. The value generated will only be known by Vault. @@ -173,7 +173,7 @@ datacenters. There are no parameters to this operation. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -182,7 +182,7 @@ $ curl \ http://127.0.0.1:8200/v1/azure/rotate-root ``` -## Create/Update Role +## Create/Update role Create or update a Vault role. Either `application_object_id` or `azure_roles` must be provided, and these resources must exist for this @@ -213,7 +213,7 @@ information about roles. - `permanently_delete` (`bool: false`) - Specifies whether to permanently delete Applications and Service Principals that are dynamically created by Vault. If `application_object_id` is present, `permanently_delete` must be `false`. -### Sample Payload +### Sample payload ```json { @@ -232,7 +232,7 @@ information about roles. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -242,7 +242,7 @@ $ curl \ https://127.0.0.1:8200/v1/azure/roles/my-role ``` -## List Roles +## List roles Lists all of the roles that are registered with the plugin. @@ -250,7 +250,7 @@ Lists all of the roles that are registered with the plugin. | :----- | :------------- | | `LIST` | `/azure/roles` | -### Sample Request +### Sample request @@ -272,7 +272,7 @@ $ vault list azure/roles -### Sample Response +### Sample response ```json { @@ -282,7 +282,7 @@ $ vault list azure/roles } ``` -## Generate Credentials +## Generate credentials This endpoint generates a new service principal based on the named role. @@ -294,7 +294,7 @@ This endpoint generates a new service principal based on the named role. - `name` (`string: `) - Specifies the name of the role to create credentials against. -### Sample Request +### Sample request @@ -315,7 +315,7 @@ $ vault read azure/creds/my-role -### Sample Response +### Sample response ```json { @@ -327,7 +327,7 @@ $ vault read azure/creds/my-role } ``` -## Revoking/Renewing Secrets +## Revoking/Renewing secrets See docs on how to [renew](/vault/api-docs/system/leases#renew-lease) and [revoke](/vault/api-docs/system/leases#revoke-lease) leases. diff --git a/website/content/api-docs/secret/cassandra.mdx b/website/content/api-docs/secret/cassandra.mdx index a3c7c90ebb12..24762fb1dff3 100644 --- a/website/content/api-docs/secret/cassandra.mdx +++ b/website/content/api-docs/secret/cassandra.mdx @@ -4,7 +4,7 @@ page_title: Cassandra - Secrets Engines - HTTP API description: This is the API documentation for the Vault Cassandra secrets engine. --- -# Cassandra Secrets Engine (API) +# Cassandra secrets engine (API) @include 'x509-sha1-deprecation.mdx' @@ -22,7 +22,7 @@ This documentation assumes the Cassandra backend is mounted at the `/cassandra` path in Vault. Since it is possible to enable secrets engines at any location, please update your API calls accordingly. -## Configure Connection +## Configure connection This endpoint configures the connection information used to communicate with Cassandra. @@ -88,7 +88,7 @@ certificate, an issuing CA certificate, or both. `pem_json` should contain the same information; for convenience, the JSON format is the same as that output by the issue command from the PKI backend. -### Sample Payload +### Sample payload ```json { @@ -98,7 +98,7 @@ the issue command from the PKI backend. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -108,7 +108,7 @@ $ curl \ http://127.0.0.1:8200/v1/cassandra/config/connection ``` -## Create Role +## Create role This endpoint creates or updates the role definition. @@ -141,7 +141,7 @@ This endpoint creates or updates the role definition. provided as a string. Determines the consistency level used for operations performed on the Cassandra database. -### Sample Payload +### Sample payload ```json { @@ -149,7 +149,7 @@ This endpoint creates or updates the role definition. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -159,7 +159,7 @@ $ curl \ http://127.0.0.1:8200/v1/cassandra/roles/my-role ``` -## Read Role +## Read role This endpoint queries the role definition. @@ -172,7 +172,7 @@ This endpoint queries the role definition. - `name` `(string: )` – Specifies the name of the role to read. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -180,7 +180,7 @@ $ curl \ http://127.0.0.1:8200/v1/cassandra/roles/my-role ``` -### Sample Response +### Sample response ```json { @@ -193,7 +193,7 @@ $ curl \ } ``` -## Delete Role +## Delete role This endpoint deletes the role definition. @@ -206,7 +206,7 @@ This endpoint deletes the role definition. - `name` `(string: )` – Specifies the name of the role to delete. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -215,7 +215,7 @@ $ curl \ http://127.0.0.1:8200/v1/cassandra/roles/my-role ``` -## Generate Credentials +## Generate credentials This endpoint generates a new set of dynamic credentials based on the named role. @@ -229,7 +229,7 @@ role. - `name` `(string: )` – Specifies the name of the role to create credentials against. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -237,7 +237,7 @@ $ curl \ http://127.0.0.1:8200/v1/cassandra/creds/my-role ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/secret/consul.mdx b/website/content/api-docs/secret/consul.mdx index 87b8d7a5e1a2..ad0875ada0e5 100644 --- a/website/content/api-docs/secret/consul.mdx +++ b/website/content/api-docs/secret/consul.mdx @@ -4,7 +4,7 @@ page_title: Consul - Secrets Engines - HTTP API description: This is the API documentation for the Vault Consul secrets engine. --- -# Consul Secrets Engine (API) +# Consul secrets engine (API) @include 'x509-sha1-deprecation.mdx' @@ -18,7 +18,7 @@ This documentation assumes the Consul secrets engine is enabled at the `/consul` path in Vault. Since it is possible to enable secrets engines at any location, please update your API calls accordingly. -## Configure Access +## Configure access This endpoint configures the access information for Consul. This access information is used so that Vault can communicate with Consul and generate @@ -48,7 +48,7 @@ Consul tokens. - `client_key` `(string: "")` - Client key used for Consul's TLS communication, must be x509 PEM encoded and if this is set you need to also set client_cert. -### Sample Payload +### Sample payload ```json { @@ -58,7 +58,7 @@ Consul tokens. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -68,7 +68,7 @@ $ curl \ http://127.0.0.1:8200/v1/consul/config/access ``` -## Create/Update Role +## Create/Update role This endpoint creates or updates the Consul role definition. If the role does not exist, it will be created. If the role already exists, it will receive @@ -80,7 +80,7 @@ Consul version. | :----- | :-------------------- | | `POST` | `/consul/roles/:name` | -### Parameters for Consul versions 1.11 and above +### Parameters for consul versions 1.11 and above - `partition` `(string: "")` - Specifies the Consul admin partition in which the token is generated. The partition must exist, and the Consul policies or roles assigned to the @@ -95,7 +95,7 @@ To create a client token within a particular Consul admin partition: } ``` -### Parameters for Consul versions 1.8 and above +### Parameters for consul versions 1.8 and above - `node_identities` `(list: )` - The list of node identities to assign to the generated token. This may be a comma-separated list to attach multiple node identities to a token. @@ -111,7 +111,7 @@ To create a client token with node identities attached: } ``` -### Parameters for Consul versions 1.7 and above +### Parameters for consul versions 1.7 and above - `consul_namespace` `(string: "")` - Specifies the Consul namespace in which the token is generated. The namespace must exist, and the Consul policies or roles assigned to the Vault role must also exist @@ -125,7 +125,7 @@ To create a client token within a particular Consul namespace: } ``` -### Parameters for Consul version 1.5 and above +### Parameters for consul version 1.5 and above - `service_identities` `(list: )` - The list of service identities to assign to the generated token. This may be a comma-separated list to attach multiple service identities to a token. @@ -135,7 +135,7 @@ To create a client token within a particular Consul namespace: To create a client token with roles defined in Consul: -### Sample Payload +### Sample payload ```json { @@ -154,7 +154,7 @@ To create a client token with service identities attached: } ``` -### Parameters for Consul versions 1.4 and above +### Parameters for consul versions 1.4 and above - `name` `(string: )` – Specifies the name of an existing role against which to create this Consul credential. This is part of the request URL. @@ -184,7 +184,7 @@ To create a client token with service identities attached: - `max_ttl` `(duration: "")` – Specifies the max TTL for this role. If not provided, the default Vault Max TTL is used. Uses [duration format strings](/vault/docs/concepts/duration-format). -### Sample Payload +### Sample payload To create a client token with policies defined in Consul: @@ -194,7 +194,7 @@ To create a client token with policies defined in Consul: } ``` -### Parameters for Consul version below 1.4 +### Parameters for consul version below 1.4 - `lease` DEPRECATED (1.11) `(string: "")` – Specifies the lease for this role. Uses [duration format strings](/vault/docs/concepts/duration-format). If not @@ -205,7 +205,7 @@ To create a client token with policies defined in Consul: documentation](/consul/docs/security/acl/acl-legacy). This is required unless the `token_type` is `"management"`. -### Sample Payload +### Sample payload To create a client token with a base64-encoded policy: @@ -223,7 +223,7 @@ To create management tokens: } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -233,7 +233,7 @@ $ curl \ http://127.0.0.1:8200/v1/consul/roles/example-role ``` -## Read Role +## Read role This endpoint queries for information about a Consul role with the given name. If no role exists with that name, a 404 is returned. @@ -247,7 +247,7 @@ If no role exists with that name, a 404 is returned. - `name` `(string: )` – Specifies the name of the role to query. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -255,7 +255,7 @@ $ curl \ http://127.0.0.1:8200/v1/consul/roles/example-role ``` -### Sample Response +### Sample response ```json { @@ -267,7 +267,7 @@ $ curl \ } ``` -## List Roles +## List roles This endpoint lists all existing roles in the secrets engine. @@ -275,7 +275,7 @@ This endpoint lists all existing roles in the secrets engine. | :----- | :-------------- | | `LIST` | `/consul/roles` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -284,7 +284,7 @@ $ curl \ http://127.0.0.1:8200/v1/consul/roles ``` -### Sample Response +### Sample response ```json { @@ -294,7 +294,7 @@ $ curl \ } ``` -## Delete Role +## Delete role This endpoint deletes a Consul role with the given name. Even if the role does not exist, this endpoint will still return a successful response. @@ -308,7 +308,7 @@ not exist, this endpoint will still return a successful response. - `name` `(string: )` – Specifies the name of the role to delete. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -317,7 +317,7 @@ $ curl \ http://127.0.0.1:8200/v1/consul/roles/example-role ``` -## Generate Credential +## Generate credential This endpoint generates a dynamic Consul token based on the given role definition. @@ -331,7 +331,7 @@ definition. - `name` `(string: )` – Specifies the name of an existing role against which to create this Consul credential. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -339,7 +339,7 @@ $ curl \ http://127.0.0.1:8200/v1/consul/creds/example-role ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/secret/cubbyhole.mdx b/website/content/api-docs/secret/cubbyhole.mdx index d41cef6bc842..e819969950f9 100644 --- a/website/content/api-docs/secret/cubbyhole.mdx +++ b/website/content/api-docs/secret/cubbyhole.mdx @@ -4,7 +4,7 @@ page_title: Cubbyhole - Secrets Engines - HTTP API description: This is the API documentation for the Vault Cubbyhole secrets engine. --- -# Cubbyhole Secrets Engine (API) +# Cubbyhole secrets engine (API) This is the API documentation for the Vault Cubbyhole secrets engine. For general information about the usage and operation of the Cubbyhole secrets @@ -15,7 +15,7 @@ This documentation assumes the Cubbyhole secrets engine is enabled at the `/cubbyhole` path in Vault. Since it is possible to enable secrets engines at any location, please update your API calls accordingly. -## Read Secret +## Read secret This endpoint retrieves the secret at the specified location. @@ -28,7 +28,7 @@ This endpoint retrieves the secret at the specified location. - `path` `(string: )` – Specifies the path of the secret to read. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -36,7 +36,7 @@ $ curl \ http://127.0.0.1:8200/v1/cubbyhole/my-secret ``` -### Sample Response +### Sample response ```json { @@ -50,7 +50,7 @@ $ curl \ } ``` -## List Secrets +## List secrets This endpoint returns a list of secret entries at the specified location. Folders are suffixed with `/`. The input must be a folder; list on a file will @@ -65,7 +65,7 @@ not return a value. The values themselves are not accessible via this command. - `path` `(string: )` – Specifies the path of the secrets to list. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -74,7 +74,7 @@ $ curl \ http://127.0.0.1:8200/v1/cubbyhole/my-secret ``` -### Sample Response +### Sample response The example below shows output for a query path of `cubbyhole/` when there are secrets at `cubbyhole/foo` and `cubbyhole/foo/bar`; note the difference in the @@ -92,7 +92,7 @@ two entries. } ``` -## Create/Update Secret +## Create/Update secret This endpoint stores a secret at the specified location. @@ -109,7 +109,7 @@ This endpoint stores a secret at the specified location. be held at the given location. Multiple key/value pairs can be specified, and all will be returned on a read operation. -### Sample Payload +### Sample payload ```json { @@ -118,7 +118,7 @@ This endpoint stores a secret at the specified location. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -128,7 +128,7 @@ $ curl \ http://127.0.0.1:8200/v1/cubbyhole/my-secret ``` -## Delete Secret +## Delete secret This endpoint deletes the secret at the specified location. @@ -141,7 +141,7 @@ This endpoint deletes the secret at the specified location. - `path` `(string: )` – Specifies the path of the secret to delete. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/secret/databases/cassandra.mdx b/website/content/api-docs/secret/databases/cassandra.mdx index 88563e9708f7..5e265979f053 100644 --- a/website/content/api-docs/secret/databases/cassandra.mdx +++ b/website/content/api-docs/secret/databases/cassandra.mdx @@ -6,7 +6,7 @@ description: >- credentials to access Cassandra servers. --- -# Cassandra Database Plugin HTTP API +# Cassandra database plugin HTTP API @include 'x509-sha1-deprecation.mdx' @@ -14,7 +14,7 @@ The Cassandra database plugin is one of the supported plugins for the database secrets engine. This plugin generates database credentials dynamically based on configured roles for the Cassandra database. -## Configure Connection +## Configure connection In addition to the parameters defined by the [Database Secrets Engine](/vault/api-docs/secret/databases#configure-connection), this plugin @@ -146,7 +146,7 @@ certificate, an issuing CA certificate, or both. `pem_json` should contain the same information; for convenience, the JSON format is the same as that output by the issue command from the PKI secrets engine. -### Sample Payload +### Sample payload ```json { @@ -158,7 +158,7 @@ the issue command from the PKI secrets engine. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/secret/databases/couchbase.mdx b/website/content/api-docs/secret/databases/couchbase.mdx index 27914658f8c2..addd5bdcd24a 100644 --- a/website/content/api-docs/secret/databases/couchbase.mdx +++ b/website/content/api-docs/secret/databases/couchbase.mdx @@ -6,7 +6,7 @@ description: >- credentials to access Couchbase servers. --- -# Couchbase Database Plugin HTTP API +# Couchbase database plugin HTTP API @include 'x509-sha1-deprecation.mdx' @@ -14,7 +14,7 @@ The Couchbase database plugin is one of the supported plugins for the database secrets engine. This plugin generates database credentials dynamically based on configured roles for the Couchbase database. -## Configure Connection +## Configure connection In addition to the parameters defined by the [Database Secrets Engine](/vault/api-docs/secret/databases#configure-connection), this plugin @@ -75,7 +75,7 @@ V_{{.DisplayName | uppercase | truncate 64}}_{{.RoleName | uppercase | truncate -### Sample Payload +### Sample payload ```json { @@ -87,7 +87,7 @@ V_{{.DisplayName | uppercase | truncate 64}}_{{.RoleName | uppercase | truncate } ``` -### Sample Request +### Sample request ```bash $ curl \ diff --git a/website/content/api-docs/secret/databases/elasticdb.mdx b/website/content/api-docs/secret/databases/elasticdb.mdx index 88bee60af1ef..5b849e8ff26d 100644 --- a/website/content/api-docs/secret/databases/elasticdb.mdx +++ b/website/content/api-docs/secret/databases/elasticdb.mdx @@ -6,7 +6,7 @@ description: >- database credentials to access Elasticsearch. --- -# Elasticsearch Database Plugin HTTP API +# Elasticsearch database plugin HTTP API @include 'x509-sha1-deprecation.mdx' @@ -14,7 +14,7 @@ The Elasticsearch database plugin is one of the supported plugins for the databa secrets engine. This plugin generates credentials dynamically based on configured roles for Elasticsearch. -## Configure Connection +## Configure connection In addition to the parameters defined by the [Database Backend](/vault/api-docs/secret/databases#configure-connection), this plugin @@ -38,7 +38,7 @@ has a number of parameters to further configure a connection. - `username_template` `(string)` - [Template](/vault/docs/concepts/username-templating) describing how dynamic usernames are generated. - `use_old_xpack` `(bool: false)` - Can be set to `true` to use the `/_xpack/security` base API path when managing Elasticsearch. May be required for Elasticsearch server versions prior to 6. -### Sample Payload +### Sample payload ```json { @@ -53,7 +53,7 @@ has a number of parameters to further configure a connection. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -87,7 +87,7 @@ list the plugin does not support that statement type. roles because a privilege escalation could be performed by editing the roles used out-of-band in Elasticsearch. -### Sample Creation Statements +### Sample creation statements ```json { diff --git a/website/content/api-docs/secret/databases/hanadb.mdx b/website/content/api-docs/secret/databases/hanadb.mdx index 7bb6bcb91dbd..6c4368068ff1 100644 --- a/website/content/api-docs/secret/databases/hanadb.mdx +++ b/website/content/api-docs/secret/databases/hanadb.mdx @@ -6,13 +6,13 @@ description: >- credentials to access HANA servers. --- -# HANA Database Plugin HTTP API +# HANA database plugin HTTP API The HANA database plugin is one of the supported plugins for the database secrets engine. This plugin generates database credentials dynamically based on configured roles for the HANA database. -## Configure Connection +## Configure connection In addition to the parameters defined by the [database secrets engine](/vault/api-docs/secret/databases#configure-connection), this plugin @@ -50,7 +50,7 @@ has a number of parameters to further configure a connection. and password fields. See the [databases secrets engine docs](/vault/docs/secrets/databases#disable-character-escaping) for more information. Defaults to `false`. -### Sample Payload +### Sample payload ```json { @@ -64,7 +64,7 @@ has a number of parameters to further configure a connection. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/secret/databases/index.mdx b/website/content/api-docs/secret/databases/index.mdx index 0d80764b719d..f28b46b30a4f 100644 --- a/website/content/api-docs/secret/databases/index.mdx +++ b/website/content/api-docs/secret/databases/index.mdx @@ -4,7 +4,7 @@ page_title: Database - Secrets Engines - HTTP API description: Top page for database secrets engine information --- -# Database Secrets Engine (API) +# Database secrets engine (API) This is the API documentation for the Vault Database secrets engine. For general information about the usage and operation of the database secrets engine, @@ -15,7 +15,7 @@ This documentation assumes the database secrets engine is enabled at the `/database` path in Vault. Since it is possible to enable secrets engines at any location, please update your API calls accordingly. -## Configure Connection +## Configure connection This endpoint configures the connection string used to communicate with the desired database. In addition to the parameters listed here, each Database @@ -93,7 +93,7 @@ are supported and any additional details about them. [databases secrets engine docs.](/vault/docs/secrets/databases#disable-character-escaping) Defaults to `false`. -### Sample Payload +### Sample payload ```json { @@ -105,7 +105,7 @@ are supported and any additional details about them. } ``` -### Sample cURL Request +### Sample cURL request ```shell-session $ curl \ @@ -115,7 +115,7 @@ $ curl \ http://127.0.0.1:8200/v1/database/config/mysql ``` -### Sample CLI Request +### Sample CLI request ```shell-session $ vault write database/config/mysql \ @@ -126,7 +126,7 @@ $ vault write database/config/mysql \ password="secretpassword" ``` -### Sample CLI Request with ADO-style Connection String +### Sample CLI request with ADO-style connection string ```shell-session $ vault write database/config/mssql \ @@ -137,7 +137,7 @@ $ vault write database/config/mssql \ disable_escaping="true" ``` -## Read Connection +## Read connection This endpoint returns the configuration settings for a connection. @@ -150,7 +150,7 @@ This endpoint returns the configuration settings for a connection. - `name` `(string: )` – Specifies the name of the connection to read. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -159,7 +159,7 @@ $ curl \ http://127.0.0.1:8200/v1/database/config/mysql ``` -### Sample Response +### Sample response ```json { @@ -177,7 +177,7 @@ $ curl \ } ``` -## List Connections +## List connections This endpoint returns a list of available connections. Only the connection names are returned, not any values. @@ -186,7 +186,7 @@ are returned, not any values. | :----- | :----------------- | | `LIST` | `/database/config` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -195,7 +195,7 @@ $ curl \ http://127.0.0.1:8200/v1/database/config ``` -### Sample Response +### Sample response ```json { @@ -205,7 +205,7 @@ $ curl \ } ``` -## Delete Connection +## Delete connection This endpoint deletes a connection. @@ -218,7 +218,7 @@ This endpoint deletes a connection. - `name` `(string: )` – Specifies the name of the connection to delete. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -227,7 +227,7 @@ $ curl \ http://127.0.0.1:8200/v1/database/config/mysql ``` -## Reset Connection +## Reset connection This endpoint closes a connection and it's underlying plugin and restarts it with the configuration stored in the barrier. @@ -241,7 +241,7 @@ with the configuration stored in the barrier. - `name` `(string: )` – Specifies the name of the connection to reset. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -250,7 +250,7 @@ $ curl \ http://127.0.0.1:8200/v1/database/reset/mysql ``` -## Rotate Root Credentials +## Rotate root credentials This endpoint is used to rotate the "root" user credentials stored for the database connection. This user must have permissions to update its own @@ -268,7 +268,7 @@ recommended that you create a user for Vault to utilize rather than using the ac - `name` `(string: )` – Specifies the name of the connection to rotate. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -277,7 +277,7 @@ $ curl \ http://127.0.0.1:8200/v1/database/rotate-root/mysql ``` -## Create Role +## Create role This endpoint creates or updates a role definition. @@ -323,7 +323,7 @@ This endpoint creates or updates a role definition. @include 'db-secrets-credential-types.mdx' -### Sample Payload +### Sample payload ```json { @@ -337,7 +337,7 @@ This endpoint creates or updates a role definition. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -347,7 +347,7 @@ $ curl \ http://127.0.0.1:8200/v1/database/roles/my-role ``` -## Read Role +## Read role This endpoint queries the role definition. @@ -360,7 +360,7 @@ This endpoint queries the role definition. - `name` `(string: )` – Specifies the name of the role to read. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -368,7 +368,7 @@ $ curl \ http://127.0.0.1:8200/v1/database/roles/my-role ``` -### Sample Response +### Sample response ```json { @@ -388,7 +388,7 @@ $ curl \ } ``` -## List Roles +## List roles This endpoint returns a list of available roles. Only the role names are returned, not any values. @@ -397,7 +397,7 @@ returned, not any values. | :----- | :---------------- | | `LIST` | `/database/roles` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -406,7 +406,7 @@ $ curl \ http://127.0.0.1:8200/v1/database/roles ``` -### Sample Response +### Sample response ```json { @@ -420,7 +420,7 @@ $ curl \ } ``` -## Delete Role +## Delete role This endpoint deletes the role definition. @@ -433,7 +433,7 @@ This endpoint deletes the role definition. - `name` `(string: )` – Specifies the name of the role to delete. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -442,7 +442,7 @@ $ curl \ http://127.0.0.1:8200/v1/database/roles/my-role ``` -## Generate Credentials +## Generate credentials This endpoint generates a new set of dynamic credentials based on the named role. @@ -456,7 +456,7 @@ role. - `name` `(string: )` – Specifies the name of the role to create credentials against. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -464,7 +464,7 @@ $ curl \ http://127.0.0.1:8200/v1/database/creds/my-role ``` -### Sample Response +### Sample response ```json { @@ -475,7 +475,7 @@ $ curl \ } ``` -## Create Static Role +## Create static role This endpoint creates or updates a static role definition. Static Roles are a 1-to-1 mapping of a Vault Role to a user in a database which are automatically @@ -512,7 +512,7 @@ this in order to know the password. @include 'db-secrets-credential-types.mdx' -### Sample Payload +### Sample payload ```json { @@ -525,7 +525,7 @@ this in order to know the password. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -535,7 +535,7 @@ $ curl \ http://127.0.0.1:8200/v1/database/static-roles/my-static-role ``` -## Read Static Role +## Read static role This endpoint queries the static role definition. @@ -548,7 +548,7 @@ This endpoint queries the static role definition. - `name` `(string: )` – Specifies the name of the static role to read. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -556,7 +556,7 @@ $ curl \ http://127.0.0.1:8200/v1/database/static-roles/my-static-role ``` -### Sample Response +### Sample response ```json { @@ -572,7 +572,7 @@ $ curl \ } ``` -## List Static Roles +## List static roles This endpoint returns a list of available static roles. Only the role names are returned, not any values. @@ -581,7 +581,7 @@ returned, not any values. | :----- | :----------------------- | | `LIST` | `/database/static-roles` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -590,7 +590,7 @@ $ curl \ http://127.0.0.1:8200/v1/database/static-roles ``` -### Sample Response +### Sample response ```json { @@ -601,7 +601,7 @@ $ curl \ } ``` -## Delete Static Role +## Delete static role This endpoint deletes the static role definition. The user, having been defined externally, must be cleaned up manually. @@ -615,7 +615,7 @@ must be cleaned up manually. - `name` `(string: )` – Specifies the name of the static role to delete. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -624,7 +624,7 @@ $ curl \ http://127.0.0.1:8200/v1/database/static-roles/my-role ``` -## Get Static Credentials +## Get static credentials This endpoint returns the current credentials based on the named static role. @@ -637,7 +637,7 @@ This endpoint returns the current credentials based on the named static role. - `name` `(string: )` – Specifies the name of the static role to get credentials for. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -645,7 +645,7 @@ $ curl \ http://127.0.0.1:8200/v1/database/static-creds/my-static-role ``` -### Sample Response +### Sample response ```json { @@ -659,7 +659,7 @@ $ curl \ } ``` -## Rotate Static Role Credentials +## Rotate static role credentials This endpoint is used to rotate the Static Role credentials stored for a given role name. While Static Roles are rotated automatically by Vault at configured @@ -675,7 +675,7 @@ change the stored password and reset the TTL of the Static Role's password. - `name` `(string: )` – Specifies the name of the Static Role to trigger the password rotation for. The name is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/secret/databases/influxdb.mdx b/website/content/api-docs/secret/databases/influxdb.mdx index 681615726d29..7f4634038536 100644 --- a/website/content/api-docs/secret/databases/influxdb.mdx +++ b/website/content/api-docs/secret/databases/influxdb.mdx @@ -6,7 +6,7 @@ description: >- credentials to access Influxdb servers. --- -# Influxdb Database Plugin HTTP API +# Influxdb database plugin HTTP API @include 'x509-sha1-deprecation.mdx' @@ -14,7 +14,7 @@ The Influxdb database plugin is one of the supported plugins for the database secrets engine. This plugin generates database credentials dynamically based on configured roles for the Influxdb database. -## Configure Connection +## Configure connection In addition to the parameters defined by the [Database Secrets Engine](/vault/api-docs/secret/databases#configure-connection), this plugin @@ -80,7 +80,7 @@ certificate, an issuing CA certificate, or both. `pem_json` should contain the same information; for convenience, the JSON format is the same as that output by the issue command from the PKI secrets engine. -### Sample Payload +### Sample payload ```json { @@ -92,7 +92,7 @@ the issue command from the PKI secrets engine. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/secret/databases/mongodb.mdx b/website/content/api-docs/secret/databases/mongodb.mdx index b3f94a6b1a3b..6cdbc50c0eb8 100644 --- a/website/content/api-docs/secret/databases/mongodb.mdx +++ b/website/content/api-docs/secret/databases/mongodb.mdx @@ -6,7 +6,7 @@ description: >- credentials to access MongoDB servers. --- -# MongoDB Database Plugin HTTP API +# MongoDB database plugin HTTP API @include 'x509-sha1-deprecation.mdx' @@ -14,7 +14,7 @@ The MongoDB database plugin is one of the supported plugins for the database secrets engine. This plugin generates database credentials dynamically based on configured roles for the MongoDB database. -## Configure Connection +## Configure connection In addition to the parameters defined by the [Database Backend](/vault/api-docs/secret/databases#configure-connection), this plugin @@ -75,7 +75,7 @@ has a number of parameters to further configure a connection. -### Sample Payload +### Sample payload ```json { @@ -88,7 +88,7 @@ has a number of parameters to further configure a connection. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -125,7 +125,7 @@ list the plugin does not support that statement type. serialized JSON object. The object can optionally contain a `db` string. If no `db` value is provided, it defaults to the `admin` database. -### Sample Creation Statement +### Sample creation statement ```json { @@ -139,7 +139,7 @@ list the plugin does not support that statement type. } ``` -### Sample Revocation Statement +### Sample revocation statement ```json { diff --git a/website/content/api-docs/secret/databases/mongodbatlas.mdx b/website/content/api-docs/secret/databases/mongodbatlas.mdx index 29e8e9fa3baa..c895b92ce117 100644 --- a/website/content/api-docs/secret/databases/mongodbatlas.mdx +++ b/website/content/api-docs/secret/databases/mongodbatlas.mdx @@ -5,13 +5,13 @@ description: |- The MongoDB Atlas plugin for Vault's Database Secrets Engine generates MongoDB Database User credentials for MongoDB Atlas. --- -# MongoDB Atlas Database Plugin HTTP API +# MongoDB atlas database plugin HTTP API The MongoDB Atlas plugin is one of the supported plugins for the Database Secrets Engine. This plugin generates MongoDB Atlas Database User credentials dynamically based on configured roles. -## Configure Connection +## Configure connection In addition to the parameters defined by the [Database Backend](/vault/api-docs/secret/databases#configure-connection), this plugin @@ -30,7 +30,7 @@ has a number of parameters to further configure a connection. dynamic usernames are generated. -### Sample Payload +### Sample payload ```json { @@ -42,7 +42,7 @@ has a number of parameters to further configure a connection. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -84,7 +84,7 @@ list the plugin does not support that statement type. is allowed to be less than the mount max TTL (or, if not set, the system max TTL), but it is not allowed to be longer. See also [The TTL General Case](/vault/docs/concepts/tokens#the-general-case). -### Sample Creation Statement +### Sample creation statement ```json { diff --git a/website/content/api-docs/secret/databases/mssql.mdx b/website/content/api-docs/secret/databases/mssql.mdx index 29d46da81f47..888968cfc986 100644 --- a/website/content/api-docs/secret/databases/mssql.mdx +++ b/website/content/api-docs/secret/databases/mssql.mdx @@ -6,13 +6,13 @@ description: >- credentials to access MSSQL servers. --- -# MSSQL Database Plugin HTTP API +# MSSQL database plugin HTTP API The MSSQL database plugin is one of the supported plugins for the database secrets engine. This plugin generates database credentials dynamically based on configured roles for the MSSQL database. -## Configure Connection +## Configure connection In addition to the parameters defined by the [Database Backend](/vault/api-docs/secret/databases#configure-connection), this plugin @@ -80,7 +80,7 @@ has a number of parameters to further configure a connection. -### Sample Payload +### Sample payload ```json { @@ -94,7 +94,7 @@ has a number of parameters to further configure a connection. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/secret/databases/mysql-maria.mdx b/website/content/api-docs/secret/databases/mysql-maria.mdx index 62f4b769b5be..685e4c32890d 100644 --- a/website/content/api-docs/secret/databases/mysql-maria.mdx +++ b/website/content/api-docs/secret/databases/mysql-maria.mdx @@ -6,7 +6,7 @@ description: >- database credentials to access MySQL and MariaDB servers. --- -# MySQL/MariaDB Database Plugin HTTP API +# MySQL/MariaDB database plugin HTTP API @include 'x509-sha1-deprecation.mdx' @@ -14,7 +14,7 @@ The MySQL database plugin is one of the supported plugins for the database secrets engine. This plugin generates database credentials dynamically based on configured roles for the MySQL database. -## Configure Connection +## Configure connection In addition to the parameters defined by the [Database Backend](/vault/api-docs/secret/databases#configure-connection), this plugin @@ -121,7 +121,7 @@ has a number of parameters to further configure a connection. -### Sample Payload +### Sample payload ```json { @@ -135,7 +135,7 @@ has a number of parameters to further configure a connection. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/secret/databases/oracle.mdx b/website/content/api-docs/secret/databases/oracle.mdx index 8dd5b063bb58..2e3991c13fa3 100644 --- a/website/content/api-docs/secret/databases/oracle.mdx +++ b/website/content/api-docs/secret/databases/oracle.mdx @@ -6,13 +6,13 @@ description: >- credentials to access Oracle servers. --- -# Oracle Database Plugin HTTP API +# Oracle database plugin HTTP API The Oracle database plugin is one of the supported plugins for the database secrets engine. This plugin generates database credentials dynamically based on configured roles for the Oracle database. -## Configure Connection +## Configure connection In addition to the parameters defined by the [Database Backend](/vault/api-docs/secret/databases#configure-connection), this plugin @@ -73,7 +73,7 @@ has a number of parameters to further configure a connection. -### Sample Payload +### Sample payload ```json { @@ -87,7 +87,7 @@ has a number of parameters to further configure a connection. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/secret/databases/postgresql.mdx b/website/content/api-docs/secret/databases/postgresql.mdx index beb931b68bd4..6024cf5995bc 100644 --- a/website/content/api-docs/secret/databases/postgresql.mdx +++ b/website/content/api-docs/secret/databases/postgresql.mdx @@ -6,13 +6,13 @@ description: >- credentials to access PostgreSQL servers. --- -# PostgreSQL Database Plugin HTTP API +# PostgreSQL database plugin HTTP API The PostgreSQL database plugin is one of the supported plugins for the database secrets engine. This plugin generates database credentials dynamically based on configured roles for the PostgreSQL database. -## Configure Connection +## Configure connection In addition to the parameters defined by the [Database Backend](/vault/api-docs/secret/databases#configure-connection), this plugin @@ -89,7 +89,7 @@ has a number of parameters to further configure a connection. -### Sample Payload with URI-format Connection String +### Sample payload with URI-format connection string ```json { @@ -103,7 +103,7 @@ has a number of parameters to further configure a connection. } ``` -### Sample Payload with Keyword/Value-format Connection String +### Sample payload with Keyword/Value-format connection string ```json { @@ -117,7 +117,7 @@ has a number of parameters to further configure a connection. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -127,7 +127,7 @@ $ curl \ http://127.0.0.1:8200/v1/database/config/postgresql ``` -### Connection Strings with Multiple Hosts +### Connection strings with multiple hosts Postgres supports multiple hosts in the connection string. An example use-case for this might be having Postgres set up with Replication Manager. However, there are some formatting rules to consider when using @@ -135,7 +135,7 @@ this feature. Please refer to the ["Specifying Multiple Hosts" section of the official Postgres documentation](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNSTRING) for more information. Below are two small examples. -#### URI-format Multi-Host String: +#### URI-format Multi-Host string: ```json { @@ -143,7 +143,7 @@ for more information. Below are two small examples. } ``` -#### Keyword/Value-format Multi-Host String: +#### Keyword/Value-format Multi-Host string: ```json { diff --git a/website/content/api-docs/secret/databases/redis.mdx b/website/content/api-docs/secret/databases/redis.mdx index 9d0e096b59a4..2f8c2980ae65 100644 --- a/website/content/api-docs/secret/databases/redis.mdx +++ b/website/content/api-docs/secret/databases/redis.mdx @@ -6,13 +6,13 @@ description: >- to access Redis servers. --- -# Redis Database Plugin HTTP API +# Redis database plugin HTTP API The Redis database plugin is one of the supported plugins for the database secrets engine. This plugin generates database credentials dynamically based on configured roles for the Redis database. -## Configure Connection +## Configure connection In addition to the parameters defined by the [Database Secrets Engine](/vault/api-docs/secret/databases#configure-connection), this plugin @@ -37,7 +37,7 @@ has a number of parameters to further configure a connection. - `insecure_tls` `(bool: false)` – Specifies whether to skip verification of the server certificate when using TLS. -### Sample Payload +### Sample payload ```json { @@ -49,7 +49,7 @@ server certificate when using TLS. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/secret/databases/rediselasticache.mdx b/website/content/api-docs/secret/databases/rediselasticache.mdx index 25a18e3ad91f..bc58dfae6567 100644 --- a/website/content/api-docs/secret/databases/rediselasticache.mdx +++ b/website/content/api-docs/secret/databases/rediselasticache.mdx @@ -5,13 +5,13 @@ description: >- The Redis ElastiCache plugin for Vault's database secrets engine generates new passwords for ElastiCache users. --- -# Redis ElastiCache Database Plugin HTTP API +# Redis ElastiCache database plugin HTTP API The Redis ElastiCache database plugin is one of the supported plugins for the database secrets engine. This plugin generates static database credentials based on configured roles for the Redis ElastiCache database. -## Configure Connection +## Configure connection In addition to the parameters defined by the [Database Secrets Engine](/vault/api-docs/secret/databases#configure-connection), this plugin @@ -34,13 +34,13 @@ If omitted, authentication falls back on the AWS credentials provider chain and - `region` `(string)` – Specifies the AWS region where to ElastiCache cluster is provisioned. If omitted, falls back on the context from the environment. -### Deprecated Parameters +### Deprecated parameters - `username` `(string)` – Use `access_key_id` instead, it is strictly equivalent. - `password` `(string)` – Use `secret_access_key` instead, it is strictly equivalent. -### Sample Payload +### Sample payload ```json { @@ -53,7 +53,7 @@ the context from the environment. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/secret/databases/redshift.mdx b/website/content/api-docs/secret/databases/redshift.mdx index 30b05a729d71..4ad6de87a41f 100644 --- a/website/content/api-docs/secret/databases/redshift.mdx +++ b/website/content/api-docs/secret/databases/redshift.mdx @@ -6,13 +6,13 @@ description: >- credentials to access the AWS Redshift service. --- -# Redshift Database Plugin HTTP API +# Redshift database plugin HTTP API The Redshift database plugin is one of the supported plugins for the database secrets engine. This plugin generates database credentials dynamically based on configured roles for the Redshift database. -## Configure Connection +## Configure connection In addition to the parameters defined by the [Database Backend](/vault/api-docs/secret/databases#configure-connection), this plugin @@ -50,7 +50,7 @@ has a number of parameters to further configure a connection. and password fields. See the [databases secrets engine docs](/vault/docs/secrets/databases#disable-character-escaping) for more information. Defaults to `false`. -### Sample Payload +### Sample payload ```json { @@ -64,7 +64,7 @@ has a number of parameters to further configure a connection. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/secret/databases/snowflake.mdx b/website/content/api-docs/secret/databases/snowflake.mdx index 2bad673e7217..2d58f39184fe 100644 --- a/website/content/api-docs/secret/databases/snowflake.mdx +++ b/website/content/api-docs/secret/databases/snowflake.mdx @@ -6,13 +6,13 @@ description: >- credentials to access Snowflake servers. --- -# Snowflake Database Plugin HTTP API +# Snowflake database plugin HTTP API The Snowflake database plugin is one of the supported plugins for the database secrets engine. This plugin generates database credentials dynamically based on configured roles for the Snowflake database. -## Configure Connection +## Configure connection In addition to the parameters defined by the [Database Backend](/vault/api-docs/secret/databases#configure-connection), this plugin @@ -50,7 +50,7 @@ has a number of parameters to further configure a connection. and password fields. See the [databases secrets engine docs](/vault/docs/secrets/databases#disable-character-escaping) for more information. Defaults to `false`. -### Sample Payload +### Sample payload ```json { @@ -64,7 +64,7 @@ has a number of parameters to further configure a connection. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/secret/gcp.mdx b/website/content/api-docs/secret/gcp.mdx index 02301cf76045..6b4fdce3b526 100644 --- a/website/content/api-docs/secret/gcp.mdx +++ b/website/content/api-docs/secret/gcp.mdx @@ -4,7 +4,7 @@ page_title: Google Cloud - Secrets Engines - HTTP API description: This is the API documentation for the Vault Google Cloud secrets engine. --- -# Google Cloud Secrets Engine (API) +# Google Cloud secrets engine (API) This is the API documentation for the Vault Google Cloud Platform (GCP) secrets engine. For general information about the usage and operation of @@ -14,7 +14,7 @@ This documentation assumes the GCP secrets engine is enabled at the `/gcp` path in Vault. Since it is possible to mount secrets engines at any path, please update your API calls accordingly. -## Write Config +## Write config | Method | Path | | :----- | :------------ | @@ -35,7 +35,7 @@ This endpoint configures shared information for the secrets engine. - `max_ttl` (`int: 0 || string:"0s"`)– Specifies the maximum config TTL for long-lived credentials (i.e. service account keys). Uses [duration format strings](/vault/docs/concepts/duration-format).\*\* -### Sample Payload +### Sample payload ```json { @@ -45,7 +45,7 @@ This endpoint configures shared information for the secrets engine. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -55,7 +55,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcp/config ``` -## Rotate Root Credentials +## Rotate root credentials Request to rotate the GCP service account credentials used by Vault for this mount. A new key will be generated for the service account, @@ -72,7 +72,7 @@ account keys. | :----- | :------------------------ | | `POST` | `/gcp/config/rotate-root` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -81,7 +81,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcp/config/rotate-root ``` -## Read Config +## Read config | Method | Path | | :----- | :------------ | @@ -89,7 +89,7 @@ $ curl \ Credentials will be omitted from returned data. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -98,7 +98,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcp/config ``` -### Sample Response +### Sample response ```json { @@ -109,7 +109,7 @@ $ curl \ } ``` -## Create/Update Roleset +## Create/Update roleset | Method | Path | | :----- | :------------------- | @@ -129,7 +129,7 @@ generated under this roleset.** - `bindings` (`string: `): Bindings configuration string (expects HCL or JSON format in raw or base64-encoded string) - `token_scopes` (`array: []`): List of OAuth scopes to assign to `access_token` secrets generated under this role set (`access_token` role sets only) -### Sample Payload +### Sample payload ```json { @@ -143,7 +143,7 @@ generated under this roleset.** } ``` -#### Sample Bindings: +#### Sample bindings: See [bindings format docs](/vault/docs/secrets/gcp#bindings) for more information. @@ -168,7 +168,7 @@ resource "https://selflink/to/my/resource" { } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -178,7 +178,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcp/roleset/my-token-roleset ``` -## Rotate Roleset Account +## Rotate roleset account | Method | Path | | | :----- | :-------------------------- | ------------------ | @@ -189,7 +189,7 @@ This will rotate the service account this roleset uses to generate secrets. old secrets generated by the roleset or fix issues if a roleset's service account (and/or keys) was changed outside of Vault (i.e. through GCP APIs/cloud console). -### Sample Request +### Sample request ```shell-session $ curl \ @@ -198,7 +198,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcp/roleset/my-token-roleset/rotate ``` -## Rotate Roleset Account Key (`access_token` Roleset Only) +## Rotate roleset account key (`access_token` roleset only) | Method | Path | | | :----- | :------------------------------ | ------------------ | @@ -207,7 +207,7 @@ $ curl \ This will rotate the service account key this roleset uses to generate access tokens. This does not recreate the roleset service account. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -216,7 +216,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcp/roleset/my-token-roleset/rotate-key ``` -## Read Roleset +## Read roleset | Method | Path | | :----- | :------------------- | @@ -226,7 +226,7 @@ $ curl \ - `name` (`string:`): Name of the roleset to read. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -235,7 +235,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcp/roleset/my-token-roleset ``` -### Sample Response +### Sample response ```json { @@ -255,13 +255,13 @@ $ curl \ } ``` -## List Rolesets +## List rolesets | Method | Path | | :----- | :-------------- | | `LIST` | `/gcp/rolesets` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -270,7 +270,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcp/rolesets ``` -### Sample Response +### Sample response ```json { @@ -280,7 +280,7 @@ $ curl \ } ``` -## Delete Roleset +## Delete roleset This endpoint deletes an existing roleset by the given name. @@ -292,7 +292,7 @@ This endpoint deletes an existing roleset by the given name. - `name` (`string:`): Name of the roleset to delete. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -301,7 +301,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcp/roleset/my-token-roleset ``` -## Create/Update Static Account +## Create/Update static account | Method | Path | | :----- | :-------------------------- | @@ -321,7 +321,7 @@ generated under this static account.** - `bindings` (`string`): Bindings configuration string (expects HCL or JSON format in raw or base64-encoded string). Optional. - `token_scopes` (`array: []`): List of OAuth scopes to assign to `access_token` secrets generated under this static account (`access_token` static accounts only) -### Sample Payload +### Sample payload ```json { @@ -335,7 +335,7 @@ generated under this static account.** } ``` -#### Sample Bindings: +#### Sample bindings: See [bindings format docs](/vault/docs/secrets/gcp#bindings) for more information. @@ -360,7 +360,7 @@ resource "https://selflink/to/my/resource" { } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -370,7 +370,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcp/static-account/my-token-account ``` -## Rotate Static Account Key (`access_token` Static Account Only) +## Rotate static account key (`access_token` static account only) | Method | Path | | | :----- | :------------------------------ | ------------------------- | @@ -379,7 +379,7 @@ $ curl \ This will rotate the service account key this static account uses to generate access tokens. This does not recreate the service account. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -388,7 +388,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcp/static-account/my-token-account/rotate-key ``` -## Read Static Account +## Read static account | Method | Path | | :----- | :-------------------------- | @@ -401,7 +401,7 @@ $ curl \ This endpoint will only return bindings that are managed through the secrets engine. Bindings manually managed outside of Vault will not be returned. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -410,7 +410,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcp/static-account/my-token-account ``` -### Sample Response +### Sample response ```json { @@ -430,13 +430,13 @@ $ curl \ } ``` -## List Static Accounts +## List static accounts | Method | Path | | :----- | :--------------------- | | `LIST` | `/gcp/static-accounts` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -445,7 +445,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcp/static-accounts ``` -### Sample Response +### Sample response ```json { @@ -455,7 +455,7 @@ $ curl \ } ``` -## Delete Static Account +## Delete static account This endpoint deletes an existing static account by the given name. @@ -467,7 +467,7 @@ This endpoint deletes an existing static account by the given name. - `name` (`string:`): Name of the static account to delete. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -476,7 +476,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcp/static-account/my-token-account ``` -## Create/Update Impersonated Account +## Create/Update impersonated account | Method | Path | | :----- | :-------------------------------- | @@ -495,7 +495,7 @@ impersonated account. - `ttl` (`duration: ""`): Lifetime of the token generated. Defaults to 1 hour and is limited to a maximum of 12 hours. Uses [duration format strings](/vault/docs/concepts/duration-format). -### Sample Payload +### Sample payload ```json { @@ -508,7 +508,7 @@ impersonated account. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -518,7 +518,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcp/impersonated-account/my-token-impersonate ``` -## Read Impersonated Account +## Read impersonated account | Method | Path | | :----- | :-------------------------------- | @@ -528,7 +528,7 @@ $ curl \ - `name` (`string:`): Name of the impersonated account to read. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -537,7 +537,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcp/impersonated-account/my-token-impersonate ``` -### Sample Response +### Sample response ```json { @@ -552,7 +552,7 @@ $ curl \ }, } ``` -## List Impersonated Accounts +## List impersonated accounts This endpoint lists the configured Vault roles for impersonated accounts. @@ -560,7 +560,7 @@ This endpoint lists the configured Vault roles for impersonated accounts. | :----- | :--------------------- | | `LIST` | `/gcp/impersonated-accounts` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -569,7 +569,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcp/impersonated-accounts ``` -### Sample Response +### Sample response ```json { @@ -582,7 +582,7 @@ $ curl \ } ``` -## Delete Impersonated Account +## Delete impersonated account This endpoint deletes an existing impersonated account by the given name. @@ -594,7 +594,7 @@ This endpoint deletes an existing impersonated account by the given name. - `name` (`string:`): Name of the impersonated account to delete. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -603,7 +603,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcp/impersonated-account/my-token-impersonate ``` -## Generate Secret (IAM Service Account Creds): OAuth2 Access Token +## Generate secret (IAM service account creds): OAuth2 access token | Method | Path | | :------------- | :------------------------------------------------------ | @@ -627,7 +627,7 @@ do not apply. - `impersonated-account` (`string:`): Name of the impersonated account to generate access_token_under. -### Sample Request +### Sample request **Roleset:** ```shell-session @@ -653,7 +653,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcp/impersonated-account/my-token-impersonate/token ``` -### Sample Response +### Sample response ```json { @@ -669,7 +669,7 @@ $ curl \ } ``` -## Generate Secret (IAM Service Account Creds): Service Account Key +## Generate secret (IAM service account creds): service account key | Method | Path | | :------------- | :---------------------------------------- | @@ -695,7 +695,7 @@ or the system default if config was not defined. Accepted values are `enum(`[`ServiceAccountPrivateKeyType`](https://cloud.google.com/iam/reference/rest/v1/projects.serviceAccounts.keys#ServiceAccountPrivateKeyType)`)` - `ttl` (`string: ""`): Specifies the Time To Live value provided using a [duration format string](/vault/docs/concepts/duration-format). If not set, uses the system default value. -### Sample Payload +### Sample payload ```json { @@ -704,7 +704,7 @@ or the system default if config was not defined. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -721,7 +721,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcp/roleset/my-key-roleset/key ``` -### Sample Response +### Sample response ```json { @@ -740,7 +740,7 @@ $ curl \ } ``` -## Revoking/Renewing Secrets +## Revoking/Renewing secrets See docs on how to [renew](/vault/api-docs/system/leases#renew-lease) and [revoke](/vault/api-docs/system/leases#revoke-lease) leases. Note this only applies to service account keys. diff --git a/website/content/api-docs/secret/gcpkms.mdx b/website/content/api-docs/secret/gcpkms.mdx index 5ffaab50890a..c2e172f5c110 100644 --- a/website/content/api-docs/secret/gcpkms.mdx +++ b/website/content/api-docs/secret/gcpkms.mdx @@ -4,7 +4,7 @@ page_title: Google Cloud KMS - Secrets Engines - HTTP API description: This is the API documentation for the Vault Google Cloud KMS secrets engine. --- -# Google Cloud KMS Secrets Engine (API) +# Google Cloud KMS secrets engine (API) This is the API documentation for the Vault Google Cloud KMS secrets engine. For general information about the usage and operation of the Google Cloud KMS @@ -15,7 +15,7 @@ This documentation assumes the Google Cloud KMS secrets engine is enabled at the `/gcpkms` path in Vault. Since it is possible to enable secrets engines at any location, please update your API calls accordingly. -## Configure Credentials +## Configure credentials This endpoint configures the Google Cloud KMS secrets engine with credentials and manages the requested scope(s) for authentication. @@ -24,7 +24,7 @@ and manages the requested scope(s) for authentication. | :----- | :-------------- | | `POST` | `gcpkms/config` | -### Example Policy +### Example policy ```hcl path "gcpkms/config" { @@ -42,7 +42,7 @@ path "gcpkms/config" { The list of full-URL scopes to request when authenticating. By default, this requests https://www.googleapis.com/auth/cloudkms. -### Sample Payload +### Sample payload ```json { @@ -50,7 +50,7 @@ path "gcpkms/config" { } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -60,7 +60,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcpkms/config ``` -## Read Configuration +## Read configuration This endpoint returns the configuration endpoint for the Google Cloud KMS secrets engine. The credentials are not returned. @@ -69,7 +69,7 @@ secrets engine. The credentials are not returned. | :----- | :-------------- | | `GET` | `gcpkms/config` | -### Example Policy +### Example policy ```hcl path "gcpkms/config" { @@ -77,7 +77,7 @@ path "gcpkms/config" { } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -86,7 +86,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcpkms/config ``` -### Sample Response +### Sample response ```json { @@ -96,7 +96,7 @@ $ curl \ } ``` -## Delete Configuration +## Delete configuration This endpoint deletes any configuration for the Google Cloud KMS secrets engine. If there is no configuration, the endpoint still returns successfully. @@ -105,7 +105,7 @@ If there is no configuration, the endpoint still returns successfully. | :------- | :-------------- | | `DELETE` | `gcpkms/config` | -### Example Policy +### Example policy ```hcl path "gcpkms/config" { @@ -113,7 +113,7 @@ path "gcpkms/config" { } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -122,7 +122,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcpkms/config ``` -## Decrypt Ciphertext +## Decrypt ciphertext This endpoint uses the named encryption key to decrypt the ciphertext string. For symmetric key types, the provided ciphertext must come from a previous invocation of the `/encrypt` endpoint. For asymmetric key types, the provided ciphertext must be from the encrypt operation against the corresponding key version's public key. @@ -130,7 +130,7 @@ This endpoint uses the named encryption key to decrypt the ciphertext string. Fo | :----- | :-------------------- | | `POST` | `gcpkms/decrypt/:key` | -### Example Policy +### Example policy ```hcl path "gcpkms/decrypt/my-key" { @@ -158,7 +158,7 @@ path "gcpkms/decrypt/my-key" { required for asymmetric keys. For symmetric keys, Cloud KMS will choose the correct version automatically. -### Sample Payload +### Sample payload ```json { @@ -166,7 +166,7 @@ path "gcpkms/decrypt/my-key" { } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -176,7 +176,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcpkms/decrypt/my-key ``` -### Sample Response +### Sample response ```json { @@ -186,7 +186,7 @@ $ curl \ } ``` -## Encrypt Plaintext +## Encrypt plaintext This endpoint uses the named encryption key to encrypt arbitrary plaintext string data. The response will be base64-encoded encrypted ciphertext. @@ -195,7 +195,7 @@ string data. The response will be base64-encoded encrypted ciphertext. | :----- | :-------------------- | | `POST` | `gcpkms/encrypt/:key` | -### Example Policy +### Example policy ```hcl path "gcpkms/encrypt/my-key" { @@ -223,7 +223,7 @@ path "gcpkms/encrypt/my-key" { is limited. See the Google Cloud KMS documentation for information on size limitations by key types. -### Sample Payload +### Sample payload ```json { @@ -231,7 +231,7 @@ path "gcpkms/encrypt/my-key" { } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -241,7 +241,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcpkms/encrypt/my-key ``` -### Sample Response +### Sample response ```json { @@ -252,7 +252,7 @@ $ curl \ } ``` -## Re-Encrypt Existing Ciphertext +## Re-Encrypt existing ciphertext This endpoint uses the named encryption key to re-encrypt the underlying cryptokey to the latest version for this ciphertext without disclosing the @@ -263,7 +263,7 @@ Vault's transit secrets engine. | :----- | :---------------------- | | `POST` | `gcpkms/reencrypt/:key` | -### Example Policy +### Example policy ```hcl path "gcpkms/reencrypt/my-key" { @@ -289,7 +289,7 @@ path "gcpkms/reencrypt/my-key" { Integer version of the crypto key version to use for re-encryption. If unspecified, this defaults to the latest active crypto key version. -### Sample Payload +### Sample payload ```json { @@ -297,7 +297,7 @@ path "gcpkms/reencrypt/my-key" { } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -307,7 +307,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcpkms/reencrypt/my-key ``` -### Sample Response +### Sample response ```json { @@ -318,7 +318,7 @@ $ curl \ } ``` -## Sign Digest +## Sign digest This endpoint uses the named encryption key to sign digest string data. The response will include the base64-encoded signature. @@ -327,7 +327,7 @@ response will include the base64-encoded signature. | :----- | :----------------- | | `POST` | `gcpkms/sign/:key` | -### Example Policy +### Example policy ```hcl path "gcpkms/sign/my-key" { @@ -353,7 +353,7 @@ path "gcpkms/sign/my-key" { $ openssl dgst -sha256 -binary /my/file | base64 ``` -### Sample Payload +### Sample payload ```json { @@ -362,7 +362,7 @@ path "gcpkms/sign/my-key" { } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -372,7 +372,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcpkms/sign/my-key ``` -### Sample Response +### Sample response ```json { @@ -382,7 +382,7 @@ $ curl \ } ``` -## Verify Digest +## Verify digest This endpoint uses the named encryption key to verify a signature and digest string data. @@ -391,7 +391,7 @@ string data. | :----- | :------------------- | | `POST` | `gcpkms/verify/:key` | -### Example Policy +### Example policy ```hcl path "gcpkms/verify/my-key" { @@ -420,7 +420,7 @@ path "gcpkms/verify/my-key" { - `signature` (`string: `) - Signature of the digest as returned from a signing operation. -### Sample Payload +### Sample payload ```json { @@ -430,7 +430,7 @@ path "gcpkms/verify/my-key" { } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -440,7 +440,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcpkms/verify/my-key ``` -### Sample Response +### Sample response ```json { @@ -450,7 +450,7 @@ $ curl \ } ``` -## List Keys +## List keys This endpoint lists the named keys available for use in Vault. It does not list all Google Cloud KMS keys. @@ -459,7 +459,7 @@ all Google Cloud KMS keys. | :----- | :------------ | | `LIST` | `gcpkms/keys` | -### Example Policy +### Example policy ```hcl path "gcpkms/keys" { @@ -467,7 +467,7 @@ path "gcpkms/keys" { } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -476,7 +476,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcpkms/keys ``` -### Sample Response +### Sample response ```json { @@ -496,7 +496,7 @@ Google Cloud KMS key with the given configuration options. | :----- | :----------------- | | `POST` | `gcpkms/keys/:key` | -### Example Policy +### Example policy ```hcl path "gcpkms/keys/my-key" { @@ -549,7 +549,7 @@ path "gcpkms/keys/my-key" { | `asymmetric_decrypt` | `rsa_decrypt_oaep_2048_sha256`
`rsa_decrypt_oaep_3072_sha256`
`rsa_decrypt_oaep_4096_sha256` | | `asymmetric_sign` | `rsa_sign_pss_2048_sha256`
`rsa_sign_pss_3072_sha256`
`rsa_sign_pss_4096_sha256`
`rsa_sign_pkcs1_2048_sha256`
`rsa_sign_pkcs1_3072_sha256`
`rsa_sign_pkcs1_4096_sha256`
`ec_sign_p256_sha256`
`ec_sign_p384_sha384` | -### Sample Payload +### Sample payload ```json { @@ -561,7 +561,7 @@ path "gcpkms/keys/my-key" { } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -571,7 +571,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcpkms/keys/my-key ``` -## Delete Google Cloud KMS Key +## Delete Google Cloud KMS key This endpoint deletes a key from both Vault and Google Cloud KMS. This will disable all crypto key versions for this crypto key in Google Cloud KMS and @@ -581,7 +581,7 @@ delete Vault's reference to the crypto key. | :------- | :----------------- | | `DELETE` | `gcpkms/keys/:key` | -### Example Policy +### Example policy ```hcl path "gcpkms/keys/my-key" { @@ -589,7 +589,7 @@ path "gcpkms/keys/my-key" { } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -598,7 +598,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcpkms/keys/my-key ``` -## Read Google Cloud KMS Key +## Read Google Cloud KMS key This endpoint reads data about a Google Cloud KMS crypto key, including the key status and current primary key version. @@ -607,7 +607,7 @@ status and current primary key version. | :----- | :----------------- | | `GET` | `gcpkms/keys/:key` | -### Example Policy +### Example policy ```hcl path "gcpkms/keys/my-key" { @@ -615,7 +615,7 @@ path "gcpkms/keys/my-key" { } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -624,7 +624,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcpkms/keys/my-key ``` -### Sample Response +### Sample response ```json { @@ -642,7 +642,7 @@ $ curl \ } ``` -## Read Vault Key Configuration +## Read Vault key configuration This endpoint reads data about a Vault's configuration of the key. @@ -650,7 +650,7 @@ This endpoint reads data about a Vault's configuration of the key. | :----- | :------------------------ | | `GET` | `gcpkms/keys/config/:key` | -### Example Policy +### Example policy ```hcl path "gcpkms/keys/config/my-key" { @@ -658,7 +658,7 @@ path "gcpkms/keys/config/my-key" { } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -667,7 +667,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcpkms/keys/config/my-key ``` -### Sample Response +### Sample response ```json { @@ -679,7 +679,7 @@ $ curl \ } ``` -## Update Vault Key Configuration +## Update Vault key configuration This endpoint is used to update Vault's information about an existing key. @@ -687,7 +687,7 @@ This endpoint is used to update Vault's information about an existing key. | :----- | :------------------------ | | `POST` | `gcpkms/keys/config/:key` | -### Example Policy +### Example policy ```hcl path "gcpkms/keys/my-key" { @@ -711,7 +711,7 @@ path "gcpkms/keys/my-key" { greater than the given value are not permitted to be used. If set to 0 or a negative value, there is no maximum key version. -### Sample Payload +### Sample payload ```json { @@ -719,7 +719,7 @@ path "gcpkms/keys/my-key" { } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -729,7 +729,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcpkms/keys/config/my-key ``` -## Deregister Crypto Key +## Deregister crypto key This endpoint deregisters an existing reference Vault has to a crypto key in Google Cloud KMS. The underlying Google Cloud KMS key remains unchanged. @@ -738,7 +738,7 @@ Google Cloud KMS. The underlying Google Cloud KMS key remains unchanged. | :----- | :---------------------------- | | `POST` | `gcpkms/keys/deregister/:key` | -### Example Policy +### Example policy ```hcl path "gcpkms/keys/deregister/my-key" { @@ -746,7 +746,7 @@ path "gcpkms/keys/deregister/my-key" { } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -755,7 +755,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcpkms/keys/deregister/my-key ``` -## Register Crypto Key +## Register crypto key This endpoint registers an existing crypto key in Google Cloud KMS and makes it available for encryption and decryption in Vault. @@ -764,7 +764,7 @@ available for encryption and decryption in Vault. | :----- | :-------------------------- | | `POST` | `gcpkms/keys/register/:key` | -### Example Policy +### Example policy ```hcl path "gcpkms/keys/register/my-key" { @@ -790,7 +790,7 @@ path "gcpkms/keys/register/my-key" { before creating the storage entry in Vault. Set this to "false" if the key will not exist at creation time. -### Sample Payload +### Sample payload ```json { @@ -799,7 +799,7 @@ path "gcpkms/keys/register/my-key" { } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -809,7 +809,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcpkms/keys/register/my-key ``` -## Rotate Crypto Key +## Rotate crypto key This endpoint rotates a crypto key by creating a new crypto key version for the corresponding Google Cloud KMS key and updates the new crypto key to be the @@ -823,7 +823,7 @@ with this key.** | :----- | :------------------------ | | `POST` | `gcpkms/keys/rotate/:key` | -### Example Policy +### Example policy ```hcl path "gcpkms/keys/rotate/my-key" { @@ -831,7 +831,7 @@ path "gcpkms/keys/rotate/my-key" { } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -840,7 +840,7 @@ $ curl \ https://127.0.0.1:8200/v1/gcpkms/keys/rotate/my-key ``` -### Sample Response +### Sample response ```json { @@ -850,7 +850,7 @@ $ curl \ } ``` -## Trim KMS Key Versions +## Trim KMS key versions This endpoint deletes old crypto key versions that are older than the key's specified `min_version`. @@ -860,7 +860,7 @@ This endpoint deletes old crypto key versions that are older than the key's spec | :----- | :---------------------- | | `POST` | `gcpkms/keys/trim/:key` | -### Example Policy +### Example policy ```hcl path "gcpkms/keys/trim/my-key" { @@ -868,7 +868,7 @@ path "gcpkms/keys/trim/my-key" { } ``` -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/secret/identity/entity-alias.mdx b/website/content/api-docs/secret/identity/entity-alias.mdx index be145afa7acd..f34284e2c812 100644 --- a/website/content/api-docs/secret/identity/entity-alias.mdx +++ b/website/content/api-docs/secret/identity/entity-alias.mdx @@ -11,7 +11,7 @@ If a user can modify an entity, they can grant it additional privileges through policies. If a user can modify an alias they can login with, they can bind it to an entity with higher privileges. -## Create an Entity Alias +## Create an entity alias ~> **IMPORTANT NOTE:** Prior to creating any alias it is important to consider the cardinality of the alias' name, since there are potential security issues to be aware of. The main one revolves around alias reuse. It is possible @@ -44,7 +44,7 @@ This endpoint creates a new alias for an entity. - `custom_metadata` `(map: )` - A map of arbitrary string to string valued user-provided metadata meant to describe the alias. -### Sample Payload +### Sample payload ```json { @@ -57,7 +57,7 @@ This endpoint creates a new alias for an entity. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -67,7 +67,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/entity-alias ``` -### Sample Response +### Sample response ```json { @@ -78,7 +78,7 @@ $ curl \ } ``` -## Read Entity Alias by ID +## Read entity alias by ID This endpoint queries the entity alias by its identifier. @@ -90,7 +90,7 @@ This endpoint queries the entity alias by its identifier. - `id` `(string: )` – Identifier of entity alias. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -98,7 +98,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/entity-alias/id/34982d3d-e3ce-5d8b-6e5f-b9bb34246c31 ``` -### Sample Response +### Sample response ```json { @@ -123,7 +123,7 @@ $ curl \ } ``` -## Update Entity Alias by ID +## Update entity alias by ID This endpoint is used to update an existing entity alias. @@ -148,7 +148,7 @@ This endpoint is used to update an existing entity alias. - `custom_metadata` `(map: )` - A map of arbitrary string to string valued user-provided metadata meant to describe the alias. -### Sample Payload +### Sample payload ```json { @@ -161,7 +161,7 @@ This endpoint is used to update an existing entity alias. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -171,7 +171,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/entity-alias/id/34982d3d-e3ce-5d8b-6e5f-b9bb34246c31 ``` -### Sample Response +### Sample response ```json { @@ -182,7 +182,7 @@ $ curl \ } ``` -## Delete Entity Alias by ID +## Delete entity alias by ID This endpoint deletes an alias from its corresponding entity. @@ -194,7 +194,7 @@ This endpoint deletes an alias from its corresponding entity. - `id` `(string: )` – Identifier of the entity alias. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -203,7 +203,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/entity-alias/id/34982d3d-e3ce-5d8b-6e5f-b9bb34246c31 ``` -## List Entity Aliases by ID +## List entity aliases by ID This endpoint returns a list of available entity aliases by their identifiers. @@ -212,7 +212,7 @@ This endpoint returns a list of available entity aliases by their identifiers. | `LIST` | `/identity/entity-alias/id` | | `GET` | `/identity/entity-alias/id?list=true` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -221,7 +221,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/entity-alias/id ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/secret/identity/entity.mdx b/website/content/api-docs/secret/identity/entity.mdx index c5f77935344e..0d2e16fd7f5d 100644 --- a/website/content/api-docs/secret/identity/entity.mdx +++ b/website/content/api-docs/secret/identity/entity.mdx @@ -4,7 +4,7 @@ page_title: 'Identity Secret Backend: Entity - HTTP API' description: This is the API documentation for managing entities in the identity store. --- -## Create an Entity +## Create an entity This endpoint creates or updates an Entity. @@ -27,7 +27,7 @@ This endpoint creates or updates an Entity. - `disabled` `(bool: false)` – Whether the entity is disabled. Disabled entities' associated tokens cannot be used, but are not revoked. -### Sample Payload +### Sample payload ```json { @@ -39,7 +39,7 @@ This endpoint creates or updates an Entity. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -49,7 +49,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/entity ``` -### Sample Response +### Sample response ```json { @@ -60,7 +60,7 @@ $ curl \ } ``` -## Read Entity by ID +## Read entity by ID This endpoint queries the entity by its identifier. @@ -72,7 +72,7 @@ This endpoint queries the entity by its identifier. - `id` `(string: )` – Identifier of the entity. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -80,7 +80,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/entity/id/8d6a45e5-572f-8f13-d226-cd0d1ec57297 ``` -### Sample Response +### Sample response ```json { @@ -101,7 +101,7 @@ $ curl \ } ``` -## Update Entity by ID +## Update entity by ID This endpoint is used to update an existing entity. @@ -118,7 +118,7 @@ This endpoint is used to update an existing entity. - `disabled` `(bool: false)` – Whether the entity is disabled. Disabled entities' associated tokens cannot be used, but are not revoked. -### Sample Payload +### Sample payload ```json { @@ -131,7 +131,7 @@ This endpoint is used to update an existing entity. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -141,7 +141,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/entity/id/8d6a45e5-572f-8f13-d226-cd0d1ec57297 ``` -### Sample Response +### Sample response ```json { @@ -152,7 +152,7 @@ $ curl \ } ``` -## Delete Entity by ID +## Delete entity by ID This endpoint deletes an entity and all its associated aliases. @@ -164,7 +164,7 @@ This endpoint deletes an entity and all its associated aliases. - `id` `(string: )` – Identifier of the entity. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -173,7 +173,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/entity/id/8d6a45e5-572f-8f13-d226-cd0d1ec57297 ``` -## Batch Delete Entities +## Batch delete entities This endpoint deletes all entities provided. @@ -185,7 +185,7 @@ This endpoint deletes all entities provided. - `entity_ids` `([]string: )` – List of entity identifiers to delete. -### Sample Payload +### Sample payload ```json { @@ -201,7 +201,7 @@ This endpoint deletes all entities provided. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -211,7 +211,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/entity/batch-delete ``` -## List Entities by ID +## List entities by ID This endpoint returns a list of available entities by their identifiers. @@ -220,7 +220,7 @@ This endpoint returns a list of available entities by their identifiers. | `LIST` | `/identity/entity/id` | | `GET` | `/identity/entity/id?list=true` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -229,7 +229,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/entity/id ``` -### Sample Response +### Sample response ```json { @@ -247,7 +247,7 @@ $ curl \ } ``` -## Create/Update Entity by Name +## Create/Update entity by name This endpoint is used to create or update an entity by a given name. @@ -266,7 +266,7 @@ This endpoint is used to create or update an entity by a given name. - `disabled` `(bool: false)` – Whether the entity is disabled. Disabled entities' associated tokens cannot be used, but are not revoked. -### Sample Payload +### Sample payload ```json { @@ -278,7 +278,7 @@ This endpoint is used to create or update an entity by a given name. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -288,7 +288,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/entity/name/testentityname ``` -### Sample Response +### Sample response ```json { @@ -299,7 +299,7 @@ $ curl \ } ``` -## Read Entity by Name +## Read entity by name This endpoint queries the entity by its name. @@ -311,7 +311,7 @@ This endpoint queries the entity by its name. - `name` `(string: )` – Name of the entity. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -319,7 +319,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/entity/name/testentityname ``` -### Sample Response +### Sample response ```json { @@ -343,7 +343,7 @@ $ curl \ } ``` -## Delete Entity by Name +## Delete entity by name This endpoint deletes an entity and all its associated aliases, given the entity name. @@ -356,7 +356,7 @@ entity name. - `name` `(string: )` – Name of the entity. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -365,7 +365,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/entity/name/testentityname ``` -## List Entities by Name +## List entities by name This endpoint returns a list of available entities by their names. @@ -374,7 +374,7 @@ This endpoint returns a list of available entities by their names. | `LIST` | `/identity/entity/name` | | `GET` | `/identity/entity/name?list=true` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -383,7 +383,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/entity/name ``` -### Sample Response +### Sample response ```json { @@ -393,7 +393,7 @@ $ curl \ } ``` -## Merge Entities +## Merge entities This endpoint merges many entities into one entity. Additionally, all groups associated with `from_entity_ids` are merged with those of `to_entity_id`. Note that if these entities contain aliases sharing the same mount accessor, the merge will fail unless `conflicting_alias_ids_to_keep` is present, and @@ -424,7 +424,7 @@ information, see the [identity concepts page](/vault/docs/concepts/identity). the alias ID given in this list will be kept or merged, and the other alias will be deleted. Note that merges requiring this parameter must have only one from-Entity. -### Sample Payload +### Sample payload ```json { @@ -436,7 +436,7 @@ information, see the [identity concepts page](/vault/docs/concepts/identity). } ``` -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/secret/identity/group-alias.mdx b/website/content/api-docs/secret/identity/group-alias.mdx index 56635af37477..b4592eef478b 100644 --- a/website/content/api-docs/secret/identity/group-alias.mdx +++ b/website/content/api-docs/secret/identity/group-alias.mdx @@ -6,7 +6,7 @@ description: >- store. --- -## Create a Group Alias +## Create a group alias This endpoint creates or updates a group alias. @@ -26,7 +26,7 @@ This endpoint creates or updates a group alias. - `canonical_id` `(string: "")` - ID of the group to which this is an alias. -### Sample Payload +### Sample payload ```json { @@ -36,7 +36,7 @@ This endpoint creates or updates a group alias. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -46,7 +46,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/group-alias ``` -### Sample Response +### Sample response ```json { @@ -57,7 +57,7 @@ $ curl \ } ``` -## Update Group Alias by ID +## Update group alias by ID This endpoint is used to update an existing group alias. @@ -76,7 +76,7 @@ This endpoint is used to update an existing group alias. - `canonical_id` `(string: "")` - ID of the group to which this is an alias. -### Sample Payload +### Sample payload ```json { @@ -86,7 +86,7 @@ This endpoint is used to update an existing group alias. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -96,7 +96,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/group-alias/id/ca726050-d8ac-6f1f-4210-3b5c5b613824 ``` -### Sample Response +### Sample response ```json { @@ -107,7 +107,7 @@ $ curl \ } ``` -## Read Group Alias by ID +## Read group alias by ID This endpoint queries the group alias by its identifier. @@ -119,7 +119,7 @@ This endpoint queries the group alias by its identifier. - `id` `(string: )` – ID of the group alias. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -127,7 +127,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/group-alias/id/ca726050-d8ac-6f1f-4210-3b5c5b613824 ``` -### Sample Response +### Sample response ```json { @@ -146,7 +146,7 @@ $ curl \ } ``` -## Delete Group Alias by ID +## Delete group alias by ID This endpoint deletes a group alias. @@ -158,7 +158,7 @@ This endpoint deletes a group alias. - `id` `(string: )` – ID of the group alias. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -167,7 +167,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/group-alias/id/ca726050-d8ac-6f1f-4210-3b5c5b613824 ``` -## List Group Alias by ID +## List group alias by ID This endpoint returns a list of available group aliases by their identifiers. @@ -176,7 +176,7 @@ This endpoint returns a list of available group aliases by their identifiers. | `LIST` | `/identity/group-alias/id` | | `GET` | `/identity/group-alias/id?list=true` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -185,7 +185,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/group-alias/id ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/secret/identity/group.mdx b/website/content/api-docs/secret/identity/group.mdx index 4f5047a09d79..abcd419059f1 100644 --- a/website/content/api-docs/secret/identity/group.mdx +++ b/website/content/api-docs/secret/identity/group.mdx @@ -8,7 +8,7 @@ description: This is the API documentation for managing groups in the identity s endpoints. If a user can modify group membership, they can add their entity to a group with higher privileges. -## Create a Group +## Create a group This endpoint creates or updates a Group. @@ -38,7 +38,7 @@ This endpoint creates or updates a Group. - `member_entity_ids` `(list of strings: [])` - Entity IDs to be assigned as group members. -### Sample Payload +### Sample payload ```json { @@ -49,7 +49,7 @@ This endpoint creates or updates a Group. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -59,7 +59,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/group ``` -### Sample Response +### Sample response ```json { @@ -70,7 +70,7 @@ $ curl \ } ``` -## Read Group by ID +## Read group by ID This endpoint queries the group by its identifier. @@ -82,7 +82,7 @@ This endpoint queries the group by its identifier. - `id` `(string: )` – Identifier of the group. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -90,7 +90,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/group/id/363926d8-dd8b-c9f0-21f8-7b248be80ce1 ``` -### Sample Response +### Sample response ```json { @@ -112,7 +112,7 @@ $ curl \ } ``` -## Update Group by ID +## Update group by ID This endpoint is used to update an existing group. @@ -140,7 +140,7 @@ This endpoint is used to update an existing group. - `member_entity_ids` `(list of strings: [])` - Entity IDs to be assigned as group members. -### Sample Payload +### Sample payload ```json { @@ -152,7 +152,7 @@ This endpoint is used to update an existing group. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -162,7 +162,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/group/id/363926d8-dd8b-c9f0-21f8-7b248be80ce1 ``` -### Sample Response +### Sample response ```json { @@ -173,7 +173,7 @@ $ curl \ } ``` -## Delete Group by ID +## Delete group by ID This endpoint deletes a group. @@ -185,7 +185,7 @@ This endpoint deletes a group. - `id` `(string: )` – Identifier of the group. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -194,7 +194,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/group/id/363926d8-dd8b-c9f0-21f8-7b248be80ce1 ``` -## List Groups by ID +## List groups by ID This endpoint returns a list of available groups by their identifiers. @@ -203,7 +203,7 @@ This endpoint returns a list of available groups by their identifiers. | `LIST` | `/identity/group/id` | | `GET` | `/identity/group/id?list=true` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -212,7 +212,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/group/id ``` -### Sample Response +### Sample response ```json { @@ -229,7 +229,7 @@ $ curl \ } ``` -## Create/Update Group by Name +## Create/Update group by name This endpoint is used to create or update a group by its name. @@ -255,7 +255,7 @@ This endpoint is used to create or update a group by its name. - `member_entity_ids` `(list of strings: [])` - Entity IDs to be assigned as group members. -### Sample Payload +### Sample payload ```json { @@ -266,7 +266,7 @@ This endpoint is used to create or update a group by its name. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -276,7 +276,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/group/name/testgroupname ``` -### Sample Response +### Sample response ```json { @@ -292,7 +292,7 @@ $ curl \ } ``` -## Read Group by Name +## Read group by name This endpoint queries the group by its name. @@ -304,7 +304,7 @@ This endpoint queries the group by its name. - `name` `(string: )` – Name of the group. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -312,7 +312,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/group/name/testgroupname ``` -### Sample Response +### Sample response ```json { @@ -335,7 +335,7 @@ $ curl \ } ``` -## Delete Group by Name +## Delete group by name This endpoint deletes a group, given its name. @@ -347,7 +347,7 @@ This endpoint deletes a group, given its name. - `name` `(string: )` – Name of the group. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -356,7 +356,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/group/name/testgroupname ``` -## List Groups by Name +## List groups by name This endpoint returns a list of available groups by their names. @@ -365,7 +365,7 @@ This endpoint returns a list of available groups by their names. | `LIST` | `/identity/group/name` | | `GET` | `/identity/group/name?list=true` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -374,7 +374,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/group/name ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/secret/identity/index.mdx b/website/content/api-docs/secret/identity/index.mdx index d42355183040..e649db30ee43 100644 --- a/website/content/api-docs/secret/identity/index.mdx +++ b/website/content/api-docs/secret/identity/index.mdx @@ -4,13 +4,13 @@ page_title: Identity - Secrets Engines - HTTP API description: This is the API documentation for the Vault Identity secrets engine. --- -# Identity Secrets Engine (API) +# Identity secrets engine (API) This is the API documentation for the Vault Identity secrets engine. For general information about the usage and operation of the Identity secrets engine, please see the [Vault Identity documentation](/vault/docs/secrets/identity). -## API Sections +## API sections - [Entity](/vault/api-docs/secret/identity/entity) - [Entity Alias](/vault/api-docs/secret/identity/entity-alias) diff --git a/website/content/api-docs/secret/identity/lookup.mdx b/website/content/api-docs/secret/identity/lookup.mdx index 1a45f3b5491f..5bcb00efe8a8 100644 --- a/website/content/api-docs/secret/identity/lookup.mdx +++ b/website/content/api-docs/secret/identity/lookup.mdx @@ -6,7 +6,7 @@ description: |- store. --- -## Lookup an Entity +## Lookup an entity This endpoint looks up an entity based on the given criteria. The criteria can be `name`, `id`, `alias_id`, or a combination of `alias_name` and @@ -30,7 +30,7 @@ be `name`, `id`, `alias_id`, or a combination of `alias_name` and - `alias_mount_accessor` `(string: "")` - Accessor of the mount to which the alias belongs to. This should be supplied in conjunction with `alias_name`. -### Sample Payload +### Sample payload ```json { @@ -38,7 +38,7 @@ be `name`, `id`, `alias_id`, or a combination of `alias_name` and } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -48,7 +48,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/lookup/entity ``` -### Sample Response +### Sample response ```json { @@ -68,7 +68,7 @@ $ curl \ } ``` -## Lookup a Group +## Lookup a group This endpoint looks up a group based on the given criteria. The criteria can be `name`, `id`, `alias_id`, or a combination of `alias_name` and @@ -92,7 +92,7 @@ be `name`, `id`, `alias_id`, or a combination of `alias_name` and - `alias_mount_accessor` `(string: "")` - Accessor of the mount to which the alias belongs to. This should be supplied in conjunction with `alias_name`. -### Sample Payload +### Sample payload ```json { @@ -100,7 +100,7 @@ be `name`, `id`, `alias_id`, or a combination of `alias_name` and } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -110,7 +110,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/lookup/group ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/secret/identity/mfa/duo.mdx b/website/content/api-docs/secret/identity/mfa/duo.mdx index 80869186e48a..80df7222064c 100644 --- a/website/content/api-docs/secret/identity/mfa/duo.mdx +++ b/website/content/api-docs/secret/identity/mfa/duo.mdx @@ -5,7 +5,7 @@ description: >- The '/identity/mfa/method/duo' endpoint focuses on managing Duo MFA behaviors in Vault. --- -## Configure Duo MFA Method +## Configure Duo MFA method This endpoint defines an MFA method of type Duo. @@ -31,7 +31,7 @@ This endpoint defines an MFA method of type Duo. - `use_passcode` `(bool: false)` - If true, the user is reminded to use the passcode upon MFA validation. -### Sample Payload +### Sample payload ```json { @@ -43,7 +43,7 @@ This endpoint defines an MFA method of type Duo. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -61,7 +61,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/mfa/method/duo/4194659f-139b-400b-b5dd-86bfb726759d ``` -## Read Duo MFA Method +## Read Duo MFA method This endpoint queries the MFA configuration of Duo type for a given method ID. @@ -74,7 +74,7 @@ ID. - `id` `(string: )` – UUID of the MFA method. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -83,7 +83,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/mfa/method/duo/4194659f-139b-400b-b5dd-86bfb726759d ``` -### Sample Response +### Sample response ```json { @@ -100,7 +100,7 @@ $ curl \ } ``` -## Delete Duo MFA Method +## Delete Duo MFA method This endpoint deletes a Duo MFA method. MFA methods can only be deleted if they're not currently in use by a [login enforcement](/vault/api-docs/secret/identity/mfa/login-enforcement). @@ -113,7 +113,7 @@ by a [login enforcement](/vault/api-docs/secret/identity/mfa/login-enforcement). - `id` `(string: )` - UUID of the MFA method. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -122,7 +122,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/mfa/method/duo/4194659f-139b-400b-b5dd-86bfb726759d ``` -## List Duo MFA Methods +## List Duo MFA methods This endpoint lists Duo MFA methods that are visible in the current namespace or in parent namespaces. @@ -130,7 +130,7 @@ This endpoint lists Duo MFA methods that are visible in the current namespace or | :----- | :------------------------- | | `LIST` | `/identity/mfa/method/duo` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -139,7 +139,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/mfa/method/duo ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/secret/identity/mfa/login-enforcement.mdx b/website/content/api-docs/secret/identity/mfa/login-enforcement.mdx index f64a538d5def..a122403666d6 100644 --- a/website/content/api-docs/secret/identity/mfa/login-enforcement.mdx +++ b/website/content/api-docs/secret/identity/mfa/login-enforcement.mdx @@ -38,7 +38,7 @@ IDs are checked during login. Note that these IDs can be from the current namesp Note that while none of `auth_method_accessors`, `auth_method_types`, `identity_group_ids`, or `identity_entity_ids` is individually required, at least one of those four fields must be present to create a login enforcement. -### Sample Payload +### Sample payload ```json { @@ -47,7 +47,7 @@ individually required, at least one of those four fields must be present to crea } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -57,7 +57,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/mfa/login-enforcement/foo ``` -## Read Login Enforcement +## Read login enforcement This endpoint reads the login enforcement configuration for a given name. @@ -69,7 +69,7 @@ This endpoint reads the login enforcement configuration for a given name. - `name` `(string: )` – Name of the login enforcement. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -79,7 +79,7 @@ $ curl \ ``` -### Sample Response +### Sample response ```json { @@ -100,7 +100,7 @@ $ curl \ } ``` -## Delete Login Enforcement +## Delete login enforcement This endpoint deletes a login enforcement configuration by the given name. @@ -112,7 +112,7 @@ This endpoint deletes a login enforcement configuration by the given name. - `name` `(string: )` - Name of the login enforcement. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -122,7 +122,7 @@ $ curl \ ``` -## List Login Enforcements +## List login enforcements This endpoint lists login enforcements that are visible in the current namespace or in parent namespaces. @@ -130,7 +130,7 @@ This endpoint lists login enforcements that are visible in the current namespace |:-------|:----------------------------------| | `LIST` | `/identity/mfa/login-enforcement` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -140,7 +140,7 @@ $ curl \ ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/secret/identity/mfa/okta.mdx b/website/content/api-docs/secret/identity/mfa/okta.mdx index 10ded2cf3f3c..c5f555c13b2d 100644 --- a/website/content/api-docs/secret/identity/mfa/okta.mdx +++ b/website/content/api-docs/secret/identity/mfa/okta.mdx @@ -5,7 +5,7 @@ description: >- The '/identity/mfa/method/okta' endpoint focuses on managing Okta MFA behaviors in Vault. --- -## Configure Okta MFA Method +## Configure okta MFA method This endpoint defines an MFA method of type Okta. @@ -29,7 +29,7 @@ This endpoint defines an MFA method of type Okta. - `primary_email` `(bool: false)` - If set, the username will only match the primary email for the account. -### Sample Payload +### Sample payload ```json { @@ -39,7 +39,7 @@ This endpoint defines an MFA method of type Okta. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -57,7 +57,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/mfa/method/okta/1db034b5-81f1-4a2b-8c2b-0f51ed0bd9fc ``` -## Read Okta MFA Method +## Read okta MFA method This endpoint queries the MFA configuration of Okta type for a given method name. @@ -70,7 +70,7 @@ name. - `id` `(string: )` – UUID of the MFA method. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -79,7 +79,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/mfa/method/okta/1db034b5-81f1-4a2b-8c2b-0f51ed0bd9fc ``` -### Sample Response +### Sample response ```json { @@ -94,7 +94,7 @@ $ curl \ } ``` -## Delete Okta MFA Method +## Delete okta MFA method This endpoint deletes a Okta MFA method. The MFA methods can only be deleted if they're not currently in use by a [login enforcement](/vault/api-docs/secret/identity/mfa/login-enforcement). @@ -107,7 +107,7 @@ by a [login enforcement](/vault/api-docs/secret/identity/mfa/login-enforcement). - `id` `(string: )` - UUID of the MFA method. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -116,7 +116,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/mfa/method/okta/1db034b5-81f1-4a2b-8c2b-0f51ed0bd9fc ``` -## List Okta MFA Methods +## List okta MFA methods This endpoint lists Okta MFA methods that are visible in the current namespace or in parent namespaces. @@ -124,7 +124,7 @@ This endpoint lists Okta MFA methods that are visible in the current namespace o | :----- | :-------------------------- | | `LIST` | `/identity/mfa/method/okta` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -133,7 +133,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/mfa/method/okta ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/secret/identity/mfa/pingid.mdx b/website/content/api-docs/secret/identity/mfa/pingid.mdx index ec53322b3a30..47ae418c2341 100644 --- a/website/content/api-docs/secret/identity/mfa/pingid.mdx +++ b/website/content/api-docs/secret/identity/mfa/pingid.mdx @@ -5,7 +5,7 @@ description: >- The '/identity/mfa/method/pingid' endpoint focuses on managing PingID MFA behaviors in Vault. --- -## Configure PingID MFA Method +## Configure PingID MFA method This endpoint defines an MFA method of type PingID. @@ -23,7 +23,7 @@ This endpoint defines an MFA method of type PingID. - `settings_file_base64` `(string: )` - A base64-encoded third-party settings file retrieved from PingID's configuration page. -### Sample Payload +### Sample payload ```json { @@ -32,7 +32,7 @@ This endpoint defines an MFA method of type PingID. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -50,7 +50,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/mfa/method/pingid/f8381105-67f0-4105-8662-4b07ae5c1233 ``` -## Read PingID MFA Method +## Read PingID MFA method This endpoint queries the MFA configuration of PingID type for a given method name. @@ -63,7 +63,7 @@ name. - `id` `(string: )` – UUID of the MFA method. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -72,7 +72,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/mfa/method/pingid/f8381105-67f0-4105-8662-4b07ae5c1233 ``` -### Sample Response +### Sample response ```json { @@ -88,7 +88,7 @@ $ curl \ } ``` -## Delete PingID MFA Method +## Delete PingID MFA method This endpoint deletes a PingID MFA method. MFA methods can only be deleted if they're not currently in use by a [login enforcement](/vault/api-docs/secret/identity/mfa/login-enforcement). @@ -101,7 +101,7 @@ by a [login enforcement](/vault/api-docs/secret/identity/mfa/login-enforcement). - `id` `(string: )` - UUID of the MFA method. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -110,7 +110,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/mfa/method/pingid/f8381105-67f0-4105-8662-4b07ae5c1233 ``` -## List PingID MFA Methods +## List PingID MFA methods This endpoint lists PingID MFA methods that are visible in the current namespace or in parent namespaces. @@ -118,7 +118,7 @@ This endpoint lists PingID MFA methods that are visible in the current namespace | :----- | :---------------------------- | | `LIST` | `/identity/mfa/method/pingid` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -127,7 +127,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/mfa/method/pingid ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/secret/identity/mfa/totp.mdx b/website/content/api-docs/secret/identity/mfa/totp.mdx index 5c0d9a50ff74..163d31de5c37 100644 --- a/website/content/api-docs/secret/identity/mfa/totp.mdx +++ b/website/content/api-docs/secret/identity/mfa/totp.mdx @@ -5,7 +5,7 @@ description: >- The '/identity/mfa/method/totp' endpoint focuses on managing TOTP MFA behaviors in Vault. --- -## Configure TOTP MFA Method +## Configure TOTP MFA method This endpoint defines an MFA method of type TOTP. @@ -35,7 +35,7 @@ This endpoint defines an MFA method of type TOTP. - `max_validation_attempts` `(int: 5)` - The maximum number of consecutive failed validation attempts. -### Sample Payload +### Sample payload ```json { @@ -43,7 +43,7 @@ This endpoint defines an MFA method of type TOTP. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -61,7 +61,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/mfa/method/totp/1f36d4cf-52c9-475d-a5cd-49c573c54e55 ``` -## Read TOTP MFA Method +## Read TOTP MFA method This endpoint queries the MFA configuration of TOTP type for a given method ID. @@ -74,7 +74,7 @@ ID. - `id` `(string: )` – UUID of the MFA method. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -83,7 +83,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/mfa/method/totp/4c6b1968-b385-4c46-ac5e-9b74e7b206be ``` -### Sample Response +### Sample response ```json { @@ -102,7 +102,7 @@ $ curl \ } ``` -## Delete TOTP MFA Method +## Delete TOTP MFA method This endpoint deletes a TOTP MFA method. MFA methods can only be deleted if they're not currently in use by a [login enforcement](/vault/api-docs/secret/identity/mfa/login-enforcement). @@ -115,7 +115,7 @@ by a [login enforcement](/vault/api-docs/secret/identity/mfa/login-enforcement). - `id` `(string: )` - UUID of the MFA method. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -124,7 +124,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/mfa/method/totp/4c6b1968-b385-4c46-ac5e-9b74e7b206be ``` -## List TOTP MFA Methods +## List TOTP MFA methods This endpoint lists TOTP MFA methods that are visible in the current namespace or in parent namespaces. @@ -132,7 +132,7 @@ This endpoint lists TOTP MFA methods that are visible in the current namespace o | :----- | :-------------------------- | | `LIST` | `/identity/mfa/method/totp` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -141,7 +141,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/mfa/method/totp ``` -### Sample Response +### Sample response ```json { @@ -154,7 +154,7 @@ $ curl \ } ``` -## Generate a TOTP MFA Secret +## Generate a TOTP MFA secret This endpoint generates an MFA secret in the entity of the calling token, if it doesn't exist already, using the configuration stored under the given MFA @@ -168,7 +168,7 @@ method ID. - `method_id` `(string: )` - UUID of the MFA method. -### Sample Payload +### Sample payload ```json { @@ -176,7 +176,7 @@ method ID. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -186,7 +186,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/mfa/method/totp/generate ``` -### Sample Response +### Sample response ```json { @@ -197,7 +197,7 @@ $ curl \ } ``` -## Administratively Generate a TOTP MFA Secret +## Administratively generate a TOTP MFA secret This endpoint can be used to generate a TOTP MFA secret. Unlike the `generate` API which stores the generated secret on the entity ID of the calling token, @@ -214,7 +214,7 @@ the `admin-generate` API stores the generated secret on the given entity ID. - `entity_id` `(string: )` - Entity ID on which the generated secret needs to get stored. -### Sample Payload +### Sample payload ```json { @@ -223,7 +223,7 @@ the `admin-generate` API stores the generated secret on the given entity ID. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -233,7 +233,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/mfa/method/totp/admin-generate ``` -### Sample Response +### Sample response ```json { @@ -244,7 +244,7 @@ $ curl \ } ``` -### Administratively Destroy TOTP MFA Secret +### Administratively destroy TOTP MFA secret This endpoint deletes a TOTP MFA secret from the given entity ID. @@ -264,7 +264,7 @@ secret. - `entity_id` `(string: )` - Entity ID from which the MFA secret should be removed. -### Sample Payload +### Sample payload ```json { @@ -273,7 +273,7 @@ secret. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/secret/identity/oidc-provider.mdx b/website/content/api-docs/secret/identity/oidc-provider.mdx index 0688f6b62719..e21c5e26221c 100644 --- a/website/content/api-docs/secret/identity/oidc-provider.mdx +++ b/website/content/api-docs/secret/identity/oidc-provider.mdx @@ -5,7 +5,7 @@ description: >- This is the API documentation for configuring and managing OIDC providers with Vault. --- -## Create or Update a Provider +## Create or update a provider This endpoint creates or updates a Provider. @@ -25,7 +25,7 @@ This endpoint creates or updates a Provider. - `scopes_supported` `([]string: )` – The scopes available for requesting on the provider. -### Sample Payload +### Sample payload ```json { @@ -34,7 +34,7 @@ This endpoint creates or updates a Provider. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -44,7 +44,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/provider/test-provider ``` -## Read Provider by Name +## Read provider by name This endpoint queries the OIDC provider by its name. @@ -56,7 +56,7 @@ This endpoint queries the OIDC provider by its name. - `name` `(string: )` – The name of the provider. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -64,7 +64,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/provider/test-provider ``` -### Sample Response +### Sample response ```json { @@ -76,7 +76,7 @@ $ curl \ } ``` -## List Providers +## List providers This endpoint returns a list of all OIDC providers. @@ -84,12 +84,12 @@ This endpoint returns a list of all OIDC providers. | :----- | :------------------------------ | | `LIST` | `/identity/oidc/provider` | -### Query Parameters +### Query parameters - `allowed_client_id` `(string: )` – Filters the list of OIDC providers to those that allow the given client ID in their set of [allowed_client_ids](/vault/api-docs/secret/identity/oidc-provider#allowed_client_ids). -### Sample Request +### Sample request ```shell-session $ curl \ @@ -98,7 +98,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/provider ``` -### Sample Response +### Sample response ```json { @@ -119,7 +119,7 @@ $ curl \ } ``` -## Delete Provider by Name +## Delete provider by name This endpoint deletes an OIDC provider. @@ -131,7 +131,7 @@ This endpoint deletes an OIDC provider. - `name` `(string: )` – The name of the provider. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -140,7 +140,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/provider/test-provider ``` -## Create or Update a Scope +## Create or update a scope This endpoint creates or updates a scope. @@ -157,7 +157,7 @@ This endpoint creates or updates a scope. - `description` `(string: )` – A description of the scope. -### Sample Payload +### Sample payload ```json { @@ -166,7 +166,7 @@ This endpoint creates or updates a scope. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -176,7 +176,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/scope/test-scope ``` -## Read Scope by Name +## Read scope by name This endpoint queries a scope by its name. @@ -188,7 +188,7 @@ This endpoint queries a scope by its name. - `name` `(string: )` – The name of the scope. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -196,7 +196,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/scope/test-scope ``` -### Sample Response +### Sample response ```json { @@ -207,7 +207,7 @@ $ curl \ } ``` -## List Scopes +## List scopes This endpoint returns a list of all configured scopes. @@ -215,7 +215,7 @@ This endpoint returns a list of all configured scopes. | :----- | :------------------------------ | | `LIST` | `/identity/oidc/scope` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -224,7 +224,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/scope ``` -### Sample Response +### Sample response ```json { @@ -236,7 +236,7 @@ $ curl \ } ``` -## Delete Scope by Name +## Delete scope by name This endpoint deletes a scope. @@ -248,7 +248,7 @@ This endpoint deletes a scope. - `name` `(string: )` – The name of the scope. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -257,7 +257,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/scope/test-scope ``` -## Create or Update a Client +## Create or update a client This endpoint creates or updates a client. @@ -306,7 +306,7 @@ This endpoint creates or updates a client. - `access_token_ttl` `(int or duration: "24h")` – The time-to-live for access tokens obtained by the client. Accepts [duration format strings](/vault/docs/concepts/duration-format). -### Sample Payload +### Sample payload ```json { @@ -316,7 +316,7 @@ This endpoint creates or updates a client. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -326,7 +326,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/client/test-client ``` -## Read Client by Name +## Read client by name This endpoint queries a client by its name. @@ -338,7 +338,7 @@ This endpoint queries a client by its name. - `name` `(string: )` – The name of the client. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -346,7 +346,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/client/test-client ``` -### Sample Response +### Sample response ```json { @@ -363,7 +363,7 @@ $ curl \ } ``` -## List Clients +## List clients This endpoint returns a list of all configured clients. @@ -371,7 +371,7 @@ This endpoint returns a list of all configured clients. | :----- | :------------------------------ | | `LIST` | `/identity/oidc/client` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -380,7 +380,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/client ``` -### Sample Response +### Sample response ```json { @@ -407,7 +407,7 @@ $ curl \ } ``` -## Delete Client by Name +## Delete client by name This endpoint deletes a client. @@ -419,7 +419,7 @@ This endpoint deletes a client. - `name` `(string: )` – The name of the client. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -428,7 +428,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/client/test-client ``` -## Create or Update an Assignment +## Create or update an assignment This endpoint creates or updates an assignment. @@ -444,7 +444,7 @@ This endpoint creates or updates an assignment. - `group_ids` `([]string: )` – A list of Vault [group](/vault/docs/secrets/identity#identity-groups) IDs. -### Sample Payload +### Sample payload ```json { @@ -453,7 +453,7 @@ This endpoint creates or updates an assignment. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -463,7 +463,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/assignment/test-assignment ``` -## Read Assignment by Name +## Read assignment by name This endpoint queries an assignment by its name. @@ -475,7 +475,7 @@ This endpoint queries an assignment by its name. - `name` `(string: )` – The name of the assignment. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -483,7 +483,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/assignment/test-assignment ``` -### Sample Response +### Sample response ```json { @@ -498,7 +498,7 @@ $ curl \ } ``` -## List Assignments +## List assignments This endpoint returns a list of all configured assignments. @@ -506,7 +506,7 @@ This endpoint returns a list of all configured assignments. | :----- | :------------------------------ | | `LIST` | `/identity/oidc/assignment` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -515,7 +515,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/assignment ``` -### Sample Response +### Sample response ```json { @@ -527,7 +527,7 @@ $ curl \ } ``` -## Delete Assignment by Name +## Delete assignment by name This endpoint deletes an assignment. @@ -539,7 +539,7 @@ This endpoint deletes an assignment. - `name` `(string: )` – The name of the assignment. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -548,7 +548,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/assignment/test-assignment ``` -## Read Provider OpenID Configuration +## Read provider OpenID configuration Returns OpenID Connect Metadata for a named OIDC provider. The response is a compliant [OpenID Provider Configuration Response](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationResponse). @@ -561,7 +561,7 @@ compliant [OpenID Provider Configuration Response](https://openid.net/specs/open - `name` `(string: )` – The name of the provider. This parameter is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -569,7 +569,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/provider/test-provider/.well-known/openid-configuration ``` -### Sample Response +### Sample response ```json { @@ -608,7 +608,7 @@ $ curl \ ]} ``` -## Read Provider Public Keys +## Read provider public keys Query this path to retrieve the public portion of keys for an OIDC provider. Clients can use them to validate the authenticity of an identity token. @@ -621,7 +621,7 @@ Clients can use them to validate the authenticity of an identity token. - `name` `(string: )` – The name of the provider. This parameter is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -629,7 +629,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/provider/test-provider/.well-known/keys ``` -### Sample Response +### Sample response ```json { @@ -653,7 +653,7 @@ $ curl \ ]} ``` -## Authorization Endpoint +## Authorization endpoint Provides the [Authorization Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) for an OIDC provider. This allows OIDC clients to request an authorization code @@ -690,7 +690,7 @@ to be used for the [Authorization Code Flow](https://openid.net/specs/openid-con [PKCE](https://datatracker.ietf.org/doc/html/rfc7636) code challenge. The following methods are supported: `S256`, `plain`. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -706,7 +706,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/provider/test-provider/authorize ``` -### Sample Response +### Sample response ```json { @@ -715,7 +715,7 @@ $ curl \ } ``` -## Token Endpoint +## Token endpoint Provides the [Token Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint) for an OIDC provider. @@ -758,7 +758,7 @@ for an OIDC provider. authentication method. This header is only required for `confidential` clients using the `client_secret_basic` client authentication method. -### Sample Request +### Sample request ```shell-session $ BASIC_AUTH_CREDS=$(printf "%s:%s" "$CLIENT_ID" "$CLIENT_SECRET" | base64) @@ -772,7 +772,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/provider/test-provider/token ``` -### Sample Response +### Sample response ```json { @@ -783,7 +783,7 @@ $ curl \ } ``` -## UserInfo Endpoint +## UserInfo endpoint Provides the [UserInfo Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) for an OIDC provider. The UserInfo Endpoint is an OAuth 2.0 Protected @@ -804,7 +804,7 @@ specified as part of the URL. `Authorization: Bearer ` HTTP header acquired from the authorization endpoint. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -813,7 +813,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/provider/test-provider/userinfo ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/secret/identity/tokens.mdx b/website/content/api-docs/secret/identity/tokens.mdx index a952b08be476..11dca6bae7a6 100644 --- a/website/content/api-docs/secret/identity/tokens.mdx +++ b/website/content/api-docs/secret/identity/tokens.mdx @@ -6,7 +6,7 @@ description: >- issued identity tokens. --- -## Configure the Identity Tokens Backend +## Configure the identity tokens backend This endpoint updates configurations for OIDC-compliant identity tokens issued by Vault. @@ -18,7 +18,7 @@ This endpoint updates configurations for OIDC-compliant identity tokens issued b - `issuer` `(string: "")` – Issuer URL to be used in the iss claim of the token. If not set, Vault's api_addr will be used. The issuer is a case sensitive URL using the https scheme that contains scheme, host, and an optional port number. -### Sample Payload +### Sample payload ```json { @@ -26,7 +26,7 @@ This endpoint updates configurations for OIDC-compliant identity tokens issued b } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -36,7 +36,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/config ``` -### Sample Response +### Sample response ```json { @@ -47,7 +47,7 @@ $ curl \ } ``` -## Read Configurations for the Identity Tokens Backend +## Read configurations for the identity tokens backend This endpoint queries vault identity tokens configurations. @@ -55,7 +55,7 @@ This endpoint queries vault identity tokens configurations. | :----- | :--------------------- | | `GET` | `identity/oidc/config` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -64,7 +64,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/config ``` -### Sample Response +### Sample response ```json { @@ -74,7 +74,7 @@ $ curl \ } ``` -## Create a Named Key +## Create a named key This endpoint creates or updates a named key which is used by a role to sign tokens. @@ -94,7 +94,7 @@ This endpoint creates or updates a named key which is used by a role to sign tok - `algorithm` `(string: "RS256")` - Signing algorithm to use. Allowed values are: RS256 (default), RS384, RS512, ES256, ES384, ES512, EdDSA. -### Sample Payload +### Sample payload ```json { @@ -103,7 +103,7 @@ This endpoint creates or updates a named key which is used by a role to sign tok } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -113,7 +113,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/key/named-key-001 ``` -## Read a Named Key +## Read a named key This endpoint queries a named key and returns its configurations. @@ -125,7 +125,7 @@ This endpoint queries a named key and returns its configurations. - `name` `(string)` – Name of the key. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -134,7 +134,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/key/named-key-001 ``` -### Sample Response +### Sample response ```json { @@ -146,7 +146,7 @@ $ curl \ } ``` -## Delete a Named Key +## Delete a named key This endpoint deletes a named key. @@ -158,7 +158,7 @@ This endpoint deletes a named key. - `name` `(string)` – Name of the key. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -167,7 +167,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/key/named-key-001 ``` -## List Named Keys +## List named keys This endpoint will List all named keys. @@ -175,7 +175,7 @@ This endpoint will List all named keys. | :----- | :------------------ | | `LIST` | `identity/oidc/key` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -184,7 +184,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/key ``` -### Sample Response +### Sample response ```json { @@ -194,7 +194,7 @@ $ curl \ } ``` -## Rotate a Named Key +## Rotate a named key This endpoint rotates a named key. @@ -208,7 +208,7 @@ This endpoint rotates a named key. - `verification_ttl` `(string: )` - Controls how long the public portion of the key will be available for verification after being rotated. Setting verification_ttl here will override the verification_ttl set on the key. -### Sample Payload +### Sample payload ```json { @@ -216,7 +216,7 @@ This endpoint rotates a named key. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -226,7 +226,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/key/named-key-001/rotate ``` -## Create or Update a Role +## Create or update a role Create or update a role. ID tokens are generated against a role and signed against a named key. @@ -246,7 +246,7 @@ Create or update a role. ID tokens are generated against a role and signed again - `ttl` `(int or time string: "24h")` - TTL of the tokens generated against the role. Uses [duration format strings](/vault/docs/concepts/duration-format). -### Sample Payload +### Sample payload ```json { @@ -255,7 +255,7 @@ Create or update a role. ID tokens are generated against a role and signed again } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -265,7 +265,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/role/role-001 ``` -## Read a Role +## Read a role This endpoint queries a role and returs its configuration. @@ -277,7 +277,7 @@ This endpoint queries a role and returs its configuration. - `name` `(string)` – Name of the role. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -286,7 +286,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/role/role-001 ``` -### Sample Response +### Sample response ```json { @@ -299,7 +299,7 @@ $ curl \ } ``` -## Delete a Role +## Delete a role This endpoint deletes a role. @@ -311,7 +311,7 @@ This endpoint deletes a role. - `name` `(string)` – Name of the role. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -320,7 +320,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/role/role-001 ``` -## List Roles +## List roles This endpoint will list all signing keys. @@ -328,7 +328,7 @@ This endpoint will list all signing keys. | :----- | :------------------- | | `LIST` | `identity/oidc/role` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -337,7 +337,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/role ``` -### Sample Response +### Sample response ```json { @@ -347,7 +347,7 @@ $ curl \ } ``` -## Generate a Signed ID Token +## Generate a signed ID token Use this endpoint to generate a signed ID (OIDC) token. @@ -359,7 +359,7 @@ Use this endpoint to generate a signed ID (OIDC) token. - `name` `(string: "")` – The name of the role against which to generate a signed ID token -### Sample Request +### Sample request ```shell-session $ curl \ @@ -369,7 +369,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/token/role-001 ``` -### Sample Response +### Sample response ```json { @@ -381,7 +381,7 @@ $ curl \ } ``` -## Introspect a signed ID Token +## Introspect a signed ID token This endpoint can verify the authenticity and active state of a signed ID token. @@ -395,7 +395,7 @@ This endpoint can verify the authenticity and active state of a signed ID token. - `client_id` `(string: )` - Specifying the client ID additionally requires the token to contain a matching `aud` claim -### Sample Payload +### Sample payload ```json { @@ -403,7 +403,7 @@ This endpoint can verify the authenticity and active state of a signed ID token. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -413,7 +413,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/introspect ``` -### Sample Response +### Sample response ```json { @@ -421,7 +421,7 @@ $ curl \ } ``` -## Read .well-known Configurations +## Read .well-known configurations Query this path to retrieve a set of claims about the identity tokens' configuration. The response is a compliant [OpenID Provider Configuration Response](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationResponse). @@ -429,7 +429,7 @@ Query this path to retrieve a set of claims about the identity tokens' configura | :----- | :----------------------------------------------- | | `GET` | `identity/oidc/.well-known/openid-configuration` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -437,7 +437,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/.well-known/openid-configuration ``` -### Sample Response +### Sample response ```json { @@ -454,11 +454,11 @@ $ curl \ } ``` -## Read Active Public Keys +## Read active public keys Query this path to retrieve the public portion of named keys. Clients can use this to validate the authenticity of an identity token. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -466,7 +466,7 @@ $ curl \ http://127.0.0.1:8200/v1/identity/oidc/.well-known/keys ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/secret/index.mdx b/website/content/api-docs/secret/index.mdx index 2424114c8200..efe63dc780bf 100644 --- a/website/content/api-docs/secret/index.mdx +++ b/website/content/api-docs/secret/index.mdx @@ -6,7 +6,7 @@ description: |- endpoints are documented in this section. --- -# Secrets Engines +# Secrets engines Each secrets engine publishes its own set of API paths and methods. These endpoints are documented in this section. secrets engines are enabled at a path, diff --git a/website/content/api-docs/secret/key-management/awskms.mdx b/website/content/api-docs/secret/key-management/awskms.mdx index e3552053cd03..37699d421b0b 100644 --- a/website/content/api-docs/secret/key-management/awskms.mdx +++ b/website/content/api-docs/secret/key-management/awskms.mdx @@ -12,7 +12,7 @@ other provider-specific parameter values. The following sections provide API documentation that is specific to AWS KMS. -## Create/Update KMS Provider +## Create/Update KMS provider This endpoint creates or updates a KMS provider. If a KMS provider with the given `name` does not exist, it will be created. If the KMS provider exists, it will be updated with diff --git a/website/content/api-docs/secret/key-management/azurekeyvault.mdx b/website/content/api-docs/secret/key-management/azurekeyvault.mdx index a9f44299aba1..b6a649c88d73 100644 --- a/website/content/api-docs/secret/key-management/azurekeyvault.mdx +++ b/website/content/api-docs/secret/key-management/azurekeyvault.mdx @@ -4,7 +4,7 @@ page_title: Azure Key Vault - Key Management - Secrets Engines - HTTP API description: The Azure Key Vault API documentation for the Key Management secrets engine. --- -# Azure Key Vault (API) +# Azure key Vault (API) The Key Management secrets engine supports lifecycle management of keys in named [Azure Key Vault](https://docs.microsoft.com/en-us/azure/key-vault/) instances. @@ -13,7 +13,7 @@ provider and other provider-specific parameter values. The following sections provide API documentation that is specific to Azure Key Vault. -## Create/Update KMS Provider +## Create/Update KMS provider This endpoint creates or updates a KMS provider. If a KMS provider with the given `name` does not exist, it will be created. If the KMS provider exists, it will be updated with diff --git a/website/content/api-docs/secret/key-management/gcpkms.mdx b/website/content/api-docs/secret/key-management/gcpkms.mdx index b4b56efd20e8..b491c09f459f 100644 --- a/website/content/api-docs/secret/key-management/gcpkms.mdx +++ b/website/content/api-docs/secret/key-management/gcpkms.mdx @@ -13,7 +13,7 @@ values. The following sections provide API documentation that is specific to GCP Cloud KMS. -## Create/Update KMS Provider +## Create/Update KMS provider This endpoint creates or updates a KMS provider. If a KMS provider with the given `name` does not exist, it will be created. If the KMS provider exists, it will be updated with diff --git a/website/content/api-docs/secret/key-management/index.mdx b/website/content/api-docs/secret/key-management/index.mdx index 196901179120..223fe9598907 100644 --- a/website/content/api-docs/secret/key-management/index.mdx +++ b/website/content/api-docs/secret/key-management/index.mdx @@ -4,7 +4,7 @@ page_title: Key Management - Secrets Engines - HTTP API description: The API documentation for the Key Management secrets engine. --- -# Key Management Secrets Engine (API) +# Key management secrets engine (API) This is the API documentation for the Key Management secrets engine. For general information about the usage and operation of the secrets engine, please see the @@ -14,7 +14,7 @@ This documentation assumes the Key Management secrets engine is enabled at the `/keymgmt` path in Vault. Since it is possible to enable secrets engines at any location, please update your API calls accordingly. -## Create Key +## Create key This endpoint creates a named cryptographic key of a specified type. These parameters set cannot be changed after key creation. @@ -39,7 +39,7 @@ set cannot be changed after key creation. - `ecdsa-p384` - ECDSA using the P-384 elliptic curve (asymmetric) - `ecdsa-p521` - ECDSA using the P-521 elliptic curve (asymmetric) -### Sample Payload +### Sample payload ```json { @@ -47,7 +47,7 @@ set cannot be changed after key creation. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -57,7 +57,7 @@ $ curl \ http://127.0.0.1:8200/v1/keymgmt/key/example-key ``` -## Read Key +## Read key This endpoint returns information about a named key. The `keys` object will hold information regarding each key version. Different information will be returned depending on the key type. @@ -72,7 +72,7 @@ For example, an asymmetric key will return its public key in a PEM encoding. - `name` `(string: )` – Specifies the name of the key to read. This is provided as part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -80,7 +80,7 @@ $ curl \ http://127.0.0.1:8200/v1/keymgmt/key/example-key ``` -### Sample Response +### Sample response ```json { @@ -104,7 +104,7 @@ $ curl \ } ``` -## List Keys +## List keys This endpoint returns a list of all existing keys. @@ -112,7 +112,7 @@ This endpoint returns a list of all existing keys. | :----- | :------------- | | `LIST` | `/keymgmt/key` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -121,7 +121,7 @@ $ curl \ http://127.0.0.1:8200/v1/keymgmt/key ``` -### Sample Response +### Sample response ```json { @@ -131,7 +131,7 @@ $ curl \ } ``` -## Update Key +## Update key This endpoint updates a named key. @@ -151,7 +151,7 @@ This endpoint updates a named key. - `deletion_allowed` `(bool: false)` – Specifies if the key is allowed to be deleted. -### Sample Payload +### Sample payload ```json { @@ -160,7 +160,7 @@ This endpoint updates a named key. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -170,7 +170,7 @@ $ curl \ http://127.0.0.1:8200/v1/keymgmt/key/example-key ``` -## Rotate Key +## Rotate key This endpoint rotates the version of a named key. @@ -183,7 +183,7 @@ This endpoint rotates the version of a named key. - `name` `(string: )` – Specifies the name of the key to rotate. This is provided as part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -192,7 +192,7 @@ $ curl \ http://127.0.0.1:8200/v1/keymgmt/key/example-key/rotate ``` -## Delete Key +## Delete key This endpoint deletes a named key. The key must be removed from all KMS providers that it's been distributed to and have `deletion_allowed` set to `true` in order to be deleted. @@ -206,7 +206,7 @@ been distributed to and have `deletion_allowed` set to `true` in order to be del - `name` `(string: )` – Specifies the name of the key to delete. This is provided as part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -215,7 +215,7 @@ $ curl \ http://127.0.0.1:8200/v1/keymgmt/key/example-key ``` -## List KMS Providers of Key +## List KMS providers of key This endpoint returns a list of all KMS providers that the named key has been distributed to. Currently, a key can only be distributed to a single KMS provider. @@ -229,7 +229,7 @@ Currently, a key can only be distributed to a single KMS provider. - `name` `(string: )` – Specifies the name of the key. This is provided as part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -238,7 +238,7 @@ $ curl \ http://127.0.0.1:8200/v1/keymgmt/key/example-key/kms ``` -### Sample Response +### Sample response ```json { @@ -248,7 +248,7 @@ $ curl \ } ``` -## Create/Update KMS Provider +## Create/Update KMS provider This endpoint creates or updates a KMS provider. If a KMS provider with the given `name` does not exist, it will be created. If the KMS provider exists, it will be updated with @@ -272,7 +272,7 @@ the given parameter values. - `awskms` - `gcpckms` -### Common Parameters +### Common parameters There are common parameters that expect different values depending on the specified `provider`. Please reference the API documentation for individual KMS providers to determine which values to @@ -287,7 +287,7 @@ set for each of the parameters listed below. also be specified as environment variables. The expected keys and values for this parameter will differ depending on the specified `provider`. -### Sample Payload +### Sample payload ```json { @@ -301,7 +301,7 @@ set for each of the parameters listed below. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -311,7 +311,7 @@ $ curl \ http://127.0.0.1:8200/v1/keymgmt/kms/example-kms ``` -## Read KMS Provider +## Read KMS provider This endpoint returns information about a KMS provider. @@ -324,7 +324,7 @@ This endpoint returns information about a KMS provider. - `name` `(string: )` – Specifies the name of the KMS provider to read. This is provided as part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -333,7 +333,7 @@ $ curl \ http://127.0.0.1:8200/v1/keymgmt/kms/example-kms ``` -### Sample Response +### Sample response ```json { @@ -344,7 +344,7 @@ $ curl \ } ``` -## List KMS Providers +## List KMS providers This endpoint returns a list of all existing KMS providers. @@ -352,7 +352,7 @@ This endpoint returns a list of all existing KMS providers. | :----- | :------------- | | `LIST` | `/keymgmt/kms` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -361,7 +361,7 @@ $ curl \ http://127.0.0.1:8200/v1/keymgmt/kms ``` -### Sample Response +### Sample response ```json { @@ -371,7 +371,7 @@ $ curl \ } ``` -## Delete KMS Provider +## Delete KMS provider This endpoint deletes a KMS provider. A KMS provider cannot be deleted until all keys that have been distributed to it are removed. @@ -385,7 +385,7 @@ that have been distributed to it are removed. - `name` `(string: )` – Specifies the name of the KMS provider to delete. This is provided as part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -394,7 +394,7 @@ $ curl \ http://127.0.0.1:8200/v1/keymgmt/kms/example-kms ``` -## Distribute Key to KMS Provider +## Distribute key to KMS provider This endpoint distributes a named key to the KMS provider. The key will be securely delivered (i.e., wrapped for protection in transit) following the key import specification of the KMS @@ -430,7 +430,7 @@ provider. The parameters set cannot be changed after the key has been distribute - `hsm` - `software` -### Sample Payload +### Sample payload ```json { @@ -439,7 +439,7 @@ provider. The parameters set cannot be changed after the key has been distribute } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -449,7 +449,7 @@ $ curl \ http://127.0.0.1:8200/v1/keymgmt/kms/example-kms/key/example-key ``` -## Read Key in KMS Provider +## Read key in KMS provider This endpoint returns information about a key that's been distributed to a KMS provider. @@ -465,7 +465,7 @@ This endpoint returns information about a key that's been distributed to a KMS p - `key_name` `(string: )` – Specifies the name of the key. This is provided as part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -474,7 +474,7 @@ $ curl \ http://127.0.0.1:8200/v1/keymgmt/kms/example-kms/key/example-key ``` -### Sample Response +### Sample response ```json { @@ -490,7 +490,7 @@ $ curl \ } ``` -## List Keys in KMS Provider +## List keys in KMS provider This endpoint returns a list of all keys that have been distributed to the given KMS provider. Many keys can be distributed to a single KMS provider. @@ -504,7 +504,7 @@ provider. Many keys can be distributed to a single KMS provider. - `name` `(string: )` – Specifies the name of the KMS provider. This is provided as part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -513,7 +513,7 @@ $ curl \ http://127.0.0.1:8200/v1/keymgmt/kms/example-kms/key ``` -### Sample Response +### Sample response ```json { @@ -523,7 +523,7 @@ $ curl \ } ``` -## Remove Key from KMS Provider +## Remove key from KMS provider This endpoint removes a named key from the KMS provider. This will only delete the key from the KMS provider. The key will still exist in the secrets engine and can be redistributed to @@ -542,7 +542,7 @@ a KMS provider at a later time. To permanently delete the key from the secrets e - `key_name` `(string: )` – Specifies the name of the key. This is provided as part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/secret/kmip.mdx b/website/content/api-docs/secret/kmip.mdx index 35efae51c8e7..5f9442aee7b7 100644 --- a/website/content/api-docs/secret/kmip.mdx +++ b/website/content/api-docs/secret/kmip.mdx @@ -4,7 +4,7 @@ page_title: KMIP - Secrets Engines - HTTP API description: This is the API documentation for the Vault KMIP secrets engine. --- -# KMIP Secrets Engine (API) +# KMIP secrets engine (API) @include 'x509-sha1-deprecation.mdx' @@ -16,7 +16,7 @@ This documentation assumes the KMIP secrets engine is enabled at the `/kmip` pat in Vault. Since it is possible to mount secrets engines at any path, please update your API calls accordingly. -## Write Config +## Write config | Method | Path | | :----- | :------------- | @@ -61,7 +61,7 @@ is enabled. - `default_tls_client_ttl` (`int: 86400 || string:"24h"`) – Client certificate TTL in either an integer number of seconds (10) or an integer time unit (10s). -### Sample Payload +### Sample payload ```json { @@ -78,7 +78,7 @@ is enabled. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -88,13 +88,13 @@ $ curl \ https://127.0.0.1:8200/v1/kmip/config ``` -## Read Config +## Read config | Method | Path | | :----- | :------------- | | `GET` | `/kmip/config` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -103,7 +103,7 @@ $ curl \ https://127.0.0.1:8200/v1/kmip/config ``` -### Sample Response +### Sample response ```json { @@ -131,7 +131,7 @@ $ curl \ Returns the CA certificates in PEM format. Returns an error if config has never been written. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -140,7 +140,7 @@ $ curl \ https://127.0.0.1:8200/v1/kmip/ca ``` -### Sample Response +### Sample response ```json { @@ -162,7 +162,7 @@ Creates a new scope with the given name. - `scope` (`string: `) - Name of scope. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -179,7 +179,7 @@ $ curl \ List existing scopes. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -188,7 +188,7 @@ $ curl \ https://127.0.0.1:8200/v1/kmip/scope ``` -### Sample Response +### Sample response ```json { @@ -214,7 +214,7 @@ Delete a scope by name. fail. This value should be supplied as a query parameter, or as an argument in the CLI. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -282,7 +282,7 @@ Creates or updates a role. - `operation_revoke` (`bool: false`) - Grant permission to use the KMIP `Revoke` operation. -### Sample Payload +### Sample payload ```json { @@ -305,7 +305,7 @@ Creates or updates a role. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -328,7 +328,7 @@ Read a role. - `scope` (`string: `) - Name of scope. This is part of the request URL. - `role` (`string: `) - Name of role. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -337,7 +337,7 @@ $ curl \ https://127.0.0.1:8200/v1/kmip/scope/myscope/role/myrole ``` -### Sample Response +### Sample response ```json { @@ -374,7 +374,7 @@ List roles with a scope. - `scope` (`string: `) - Name of scope. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -383,7 +383,7 @@ $ curl \ https://127.0.0.1:8200/v1/kmip/scope/myscope/role ``` -### Sample Response +### Sample response ```json { @@ -406,7 +406,7 @@ Delete a role by name. - `scope` (`string: `) - Name of scope. This is part of the request URL. - `role` (`string: `) - Name of role. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -432,7 +432,7 @@ if entropy augmentation is enabled. - `format` (`string: "pem"`) - Format to return the certificate, private key, and CA chain in. One of `pem`, `pem_bundle`, or `der`. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -441,7 +441,7 @@ $ curl \ https://127.0.0.1:8200/v1/kmip/scope/myscope/role/myrole/credential/generate ``` -### Sample Response +### Sample response ```json { @@ -475,7 +475,7 @@ The key type and key bits used in the CSR must match those of the role. and CA chain in. One of `pem`, `pem_bundle`, or `der`. - `csr` (`string`) - CSR in PEM format. -### Sample Request +### Sample request ``` $ curl \ @@ -485,7 +485,7 @@ $ curl \ https://127.0.0.1:8200/v1/kmip/scope/myscope/role/myrole/credential/sign ``` -### Sample Response +### Sample response ```json { @@ -517,7 +517,7 @@ at generation time. - `format` (`string: "pem"`) - Format to return the certificate, private key, and CA chain in. One of `pem`, `pem_bundle`, or `der`. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -526,7 +526,7 @@ $ curl \ https://127.0.0.1:8200/v1/kmip/scope/myscope/role/myrole/credential/lookup?serial_number=728181095563584845125173905844944137943705466376 ``` -### Sample Response +### Sample response ```json { @@ -554,7 +554,7 @@ List the serial numbers of all certificates within a role. - `scope` (`string: `) - Name of scope. This is part of the request URL. - `role` (`string: `) - Name of role. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -563,7 +563,7 @@ $ curl \ https://127.0.0.1:8200/v1/kmip/scope/myscope/role/myrole/credential ``` -### Sample Response +### Sample response ```json { @@ -590,7 +590,7 @@ Delete a certificate, thereby revoking it. - `certificate` (`string: """`) - Certificate to revoke, in PEM format. Exactly one of `serial_number` or `certificate` must be provided. -### Sample Payload +### Sample payload ```json { @@ -598,7 +598,7 @@ Delete a certificate, thereby revoking it. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/secret/kubernetes.mdx b/website/content/api-docs/secret/kubernetes.mdx index 68df103b529d..bd1ff196114a 100644 --- a/website/content/api-docs/secret/kubernetes.mdx +++ b/website/content/api-docs/secret/kubernetes.mdx @@ -4,7 +4,7 @@ page_title: Kubernetes - Secrets Engines - HTTP API description: This is the API documentation for the Vault Kubernetes secrets engine. --- -# Kubernetes Secrets Engine (API) +# Kubernetes secrets engine (API) @include 'x509-sha1-deprecation.mdx' @@ -16,7 +16,7 @@ This documentation assumes the Kubernetes secrets engine is mounted at the `/kubernetes` path in Vault. Since it is possible to enable secrets engines at any location, please update your API calls accordingly. -## Write Configuration +## Write configuration This endpoint configures the plugin with the necessary information to reach the Kubernetes API and authenticate with it. @@ -40,7 +40,7 @@ Kubernetes API and authenticate with it. - `disable_local_ca_jwt` `(bool: false)` - Disable defaulting to the local CA certificate and service account JWT when running in a Kubernetes pod. -### Sample Payload +### Sample payload ```json { @@ -49,7 +49,7 @@ Kubernetes API and authenticate with it. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -59,7 +59,7 @@ $ curl \ http://127.0.0.1:8200/v1/kubernetes/config ``` -## Read Configuration +## Read configuration Returns the config previously set, excluding credentials. @@ -67,7 +67,7 @@ Returns the config previously set, excluding credentials. | :----- | :------------------------ | | `GET` | `/kubernetes/config` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -75,7 +75,7 @@ $ curl \ http://127.0.0.1:8200/v1/kubernetes/config ``` -### Sample Response +### Sample response ```json { @@ -87,7 +87,7 @@ $ curl \ } ``` -## Delete Configuration +## Delete configuration Deletes the config previously set. @@ -95,7 +95,7 @@ Deletes the config previously set. | :------- | :------------------------ | | `DELETE` | `/kubernetes/config` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -104,7 +104,7 @@ $ curl \ http://127.0.0.1:8200/v1/kubernetes/config ``` -## Create Role +## Create role A role configures what service account tokens can be generated, and what permissions will be attached to them. The permissions attached to a service @@ -181,7 +181,7 @@ Only one of `service_account_name`, `kubernetes_role_name` or [Kubernetes labels documentation](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) for more details on labels. -### Sample Payload 1 +### Sample payload 1 To generate tokens for a pre-existing service account: @@ -193,7 +193,7 @@ To generate tokens for a pre-existing service account: } ``` -### Sample Payload 2 +### Sample payload 2 To generate tokens for a pre-existing ClusterRole: @@ -205,7 +205,7 @@ To generate tokens for a pre-existing ClusterRole: } ``` -### Sample Payload 3 +### Sample payload 3 To generate tokens for a defined set of Kubernetes role rules: @@ -225,7 +225,7 @@ Or to define the same rules as JSON: } ``` -### Sample Payload 4 +### Sample payload 4 To generate tokens in namespaces based on a label selector for the namespaces: @@ -245,7 +245,7 @@ Or to define the same selector as JSON: } ``` -### Sample Payload 5 +### Sample payload 5 To generate tokens in namespaces based on a label selector for the namespaces and via a normal namespace array: @@ -261,7 +261,7 @@ namespace array: In the payload above, the token can be generated for any namespace that either contains the labels defined in the selector, or is named `vault-system` or `testing`. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -271,7 +271,7 @@ $ curl \ http://127.0.0.1:8200/v1/kubernetes/roles/default-role ``` -## Read Role +## Read role Returns the previously configured role. @@ -283,7 +283,7 @@ Returns the previously configured role. - `name` `(string: )` - Name of the role. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -291,7 +291,7 @@ $ curl \ http://127.0.0.1:8200/v1/kubernetes/role/default-role ``` -### Sample Response +### Sample response ```json { @@ -312,7 +312,7 @@ $ curl \ } ``` -## List Roles +## List roles Lists all the roles that are configured. @@ -321,7 +321,7 @@ Lists all the roles that are configured. | `LIST` | `/kubernetes/roles` | | `GET` | `/kubernetes/roles?list=true` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -330,7 +330,7 @@ $ curl \ http://127.0.0.1:8200/v1/kubernetes/roles ``` -### Sample Response +### Sample response ```json { @@ -340,7 +340,7 @@ $ curl \ } ``` -## Delete Role +## Delete role Deletes the previously configured role. @@ -352,7 +352,7 @@ Deletes the previously configured role. - `role` `(string: )` - Name of the role. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -361,7 +361,7 @@ $ curl \ http://127.0.0.1:8200/v1/kubernetes/role/default-role ``` -## Generate Credentials +## Generate credentials Generate a service account token. @@ -387,7 +387,7 @@ Generate a service account token. If not set or set to `""`, the [token_default_audiences](/vault/api-docs/secret/kubernetes#token_default_audiences) will be used. -### Sample Payload +### Sample payload ```json { @@ -396,7 +396,7 @@ Generate a service account token. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -405,7 +405,7 @@ $ curl \ http://127.0.0.1:8200/v1/kubernetes/creds/default-role ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/secret/kv/index.mdx b/website/content/api-docs/secret/kv/index.mdx index 9fcc209dfffc..6abdfbaa7d40 100644 --- a/website/content/api-docs/secret/kv/index.mdx +++ b/website/content/api-docs/secret/kv/index.mdx @@ -4,7 +4,7 @@ page_title: KV - Secrets Engines - HTTP API description: This is the API documentation for the Vault KV secrets engine. --- -# KV Secrets Engine (API) +# KV secrets engine (API) This backend can be run in one of two versions. Each of which have a distinct API. Choose the version below you are running. For more information on the KV secrets diff --git a/website/content/api-docs/secret/kv/kv-v1.mdx b/website/content/api-docs/secret/kv/kv-v1.mdx index 5eb970ae13c8..029d5fa349f9 100644 --- a/website/content/api-docs/secret/kv/kv-v1.mdx +++ b/website/content/api-docs/secret/kv/kv-v1.mdx @@ -4,7 +4,7 @@ page_title: KV - Secrets Engines - HTTP API description: This is the API documentation for the Vault KV secrets engine, version 1. --- -# KV Secrets Engine - Version 1 (API) +# KV secrets engine - version 1 (API) This is the API documentation for the Vault KV secrets engine. For general information about the usage and operation of the version 1 KV secrets engine, please @@ -16,7 +16,7 @@ documentation](/vault/docs/secrets/kv). `/secret` path in Vault. Since it is possible to enable secrets engines at any location, please update your API calls accordingly. -## Read Secret +## Read secret This endpoint retrieves the secret at the specified location. @@ -29,7 +29,7 @@ This endpoint retrieves the secret at the specified location. - `path` `(string: )` – Specifies the path of the secret to read. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -37,7 +37,7 @@ $ curl \ https://127.0.0.1:8200/v1/secret/my-secret ``` -### Sample Response +### Sample response ```json { @@ -58,7 +58,7 @@ writers to indicate how often a given value should be re-read by the client. See the [Vault KV secrets engine documentation](/vault/docs/secrets/kv/kv-v1#ttls) for more details. -## List Secrets +## List secrets This endpoint returns a list of key names at the specified location. Folders are suffixed with `/`. The input must be a folder; list on a file will not return a @@ -75,7 +75,7 @@ this API. - `path` `(string: )` – Specifies the path of the secrets to list. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -84,7 +84,7 @@ $ curl \ https://127.0.0.1:8200/v1/secret/my-secret ``` -### Sample Response +### Sample response The example below shows output for a query path of `secret/` when there are secrets at `secret/foo` and `secret/foo/bar`; note the difference in the two @@ -102,7 +102,7 @@ entries. } ``` -## Create/Update Secret +## Create/Update secret This endpoint stores a secret at the specified location. If the value does not yet exist, the calling token must have an ACL policy granting the `create` @@ -124,7 +124,7 @@ policy granting the `update` capability. some special behavior. See the [Vault KV secrets engine documentation](/vault/docs/secrets/kv/kv-v1#ttls) for details. -### Sample Payload +### Sample payload ```json { @@ -133,7 +133,7 @@ policy granting the `update` capability. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -143,7 +143,7 @@ $ curl \ https://127.0.0.1:8200/v1/secret/my-secret ``` -## Delete Secret +## Delete secret This endpoint deletes the secret at the specified location. @@ -156,7 +156,7 @@ This endpoint deletes the secret at the specified location. - `path` `(string: )` – Specifies the path of the secret to delete. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/secret/kv/kv-v2.mdx b/website/content/api-docs/secret/kv/kv-v2.mdx index 50c4b84580e2..884b6b20befe 100644 --- a/website/content/api-docs/secret/kv/kv-v2.mdx +++ b/website/content/api-docs/secret/kv/kv-v2.mdx @@ -4,7 +4,7 @@ page_title: KV - Secrets Engines - HTTP API description: This is the API documentation for the Vault KV secrets engine, version 2. --- -# KV Secrets Engine - Version 2 (API) +# KV secrets engine - version 2 (API) This is the API documentation for the Vault KV secrets engine while running in versioned mode. For general information about the usage and operation of the version 2 @@ -12,7 +12,7 @@ KV secrets engine, please see the [Vault KV documentation](/vault/docs/secrets/k For information about the differences between KV version 1 and version 2, please [see the KV overview documentation](/vault/docs/secrets/kv). -## Configure the KV Engine +## Configure the KV engine This path configures backend level settings that are applied to every key in the key-value store. @@ -39,7 +39,7 @@ key-value store. of time before a version is deleted. Accepts [duration format strings](/vault/docs/concepts/duration-format). -### Sample Payload +### Sample payload ```json { @@ -49,7 +49,7 @@ key-value store. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -59,7 +59,7 @@ $ curl \ https://127.0.0.1:8200/v1/secret/config ``` -## Read KV Engine configuration +## Read KV engine configuration This path retrieves the current configuration for the secrets backend at the given path. @@ -73,7 +73,7 @@ given path. - `secret-mount-path` `(string: )` - The path to the KV mount to read the config, of, such as `secret`. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -81,7 +81,7 @@ $ curl \ https://127.0.0.1:8200/v1/secret/config ``` -### Sample Response +### Sample response ```json { @@ -93,7 +93,7 @@ $ curl \ } ``` -## Read Secret Version +## Read secret version This endpoint retrieves the secret at the specified location. The metadata fields `created_time`, `deletion_time`, `destroyed`, and `version` are version @@ -114,7 +114,7 @@ the associated [metadata endpoint](/vault/api-docs/secret/kv/kv-v2#read-secret-m - `version` `(int: 0)` - Specifies the version to return. If not set the latest version is returned. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -122,7 +122,7 @@ $ curl \ https://127.0.0.1:8200/v1/secret/data/my-secret?version=2 ``` -### Sample Response +### Sample response ```json { @@ -144,7 +144,7 @@ $ curl \ } ``` -## Create/Update Secret +## Create/Update secret This endpoint creates a new version of a secret at the specified location. If the value does not yet exist, the calling token must have an ACL policy granting @@ -177,7 +177,7 @@ have an ACL policy granting the `update` capability. - `data` `(Map: )` – The contents of the data map will be stored and returned on read. -### Sample Payload +### Sample payload ```json { @@ -191,7 +191,7 @@ have an ACL policy granting the `update` capability. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -201,7 +201,7 @@ $ curl \ https://127.0.0.1:8200/v1/secret/data/my-secret ``` -### Sample Response +### Sample response ```json { @@ -218,7 +218,7 @@ $ curl \ } ``` -## Patch Secret +## Patch secret This endpoint provides the ability to patch an _existing_ secret at the specified location. The secret must neither be deleted nor destroyed. The calling token must @@ -250,7 +250,7 @@ applying a patch with the provided data. - `data` `(Map: )` – The contents of the data map will be applied as a partial update to the existing entry via a JSON merge patch to the existing entry. -### Sample Payload +### Sample payload ```json { @@ -266,7 +266,7 @@ applying a patch with the provided data. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -277,7 +277,7 @@ $ curl \ https://127.0.0.1:8200/v1/secret/data/my-secret ``` -### Sample Response +### Sample response ```json { @@ -294,7 +294,7 @@ $ curl \ } ``` -## Read Secret Subkeys +## Read secret subkeys This endpoint provides the subkeys within a secret entry that exists at the requested path. The secret entry at this path will be retrieved @@ -318,7 +318,7 @@ and stripped of all data by replacing underlying values of leaf keys specified `depth` value will be artificially treated as leaves and will thus be `null` even if further underlying subkeys exist. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -326,7 +326,7 @@ $ curl \ https://127.0.0.1:8200/v1/secret/subkeys/my-secret?version=1 ``` -### Sample Secret Data +### Sample secret data ```json { @@ -338,7 +338,7 @@ $ curl \ } ``` -### Sample Response +### Sample response ```json { @@ -359,7 +359,7 @@ $ curl \ } ``` -## Delete Latest Version of Secret +## Delete latest version of secret This endpoint issues a soft delete of the secret's latest version at the specified location. This marks the version as deleted and will stop it from @@ -377,7 +377,7 @@ delete can be undone using the `undelete` path. - `path` `(string: )` – Specifies the path of the secret to delete. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -386,7 +386,7 @@ $ curl \ https://127.0.0.1:8200/v1/secret/data/my-secret ``` -## Delete Secret Versions +## Delete secret versions This endpoint issues a soft delete of the specified versions of the secret. This marks the versions as deleted and will stop them from being returned from reads, @@ -407,7 +407,7 @@ but the underlying data will not be removed. A delete can be undone using the data will not be deleted, but it will no longer be returned in normal get requests. -### Sample Payload +### Sample payload ```json { @@ -415,7 +415,7 @@ but the underlying data will not be removed. A delete can be undone using the } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -425,7 +425,7 @@ $ curl \ https://127.0.0.1:8200/v1/secret/delete/my-secret ``` -## Undelete Secret Versions +## Undelete secret versions Undeletes the data for the provided version and path in the key-value store. This restores the data, allowing it to be returned on get requests. @@ -445,7 +445,7 @@ This restores the data, allowing it to be returned on get requests. - `versions` `([]int: )` - The versions to undelete. The versions will be restored and their data will be returned on normal get requests. -### Sample Payload +### Sample payload ```json { @@ -453,7 +453,7 @@ This restores the data, allowing it to be returned on get requests. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -463,7 +463,7 @@ $ curl \ https://127.0.0.1:8200/v1/secret/undelete/my-secret ``` -## Destroy Secret Versions +## Destroy secret versions Permanently removes the specified version data for the provided key and version numbers from the key-value store. @@ -483,7 +483,7 @@ numbers from the key-value store. - `versions` `([]int: )` - The versions to destroy. Their data will be permanently deleted. -### Sample Payload +### Sample payload ```json { @@ -491,7 +491,7 @@ numbers from the key-value store. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -501,7 +501,7 @@ $ curl \ https://127.0.0.1:8200/v1/secret/destroy/my-secret ``` -## List Secrets +## List secrets This endpoint returns a list of key names at the specified location. Folders are suffixed with `/`. The input must be a folder; list on a file will not return a @@ -521,7 +521,7 @@ the secret to list, such as `secret`. This is specified as part of the URL. - `path` `(string: )` – Specifies the path of the secrets to list. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -530,7 +530,7 @@ $ curl \ https://127.0.0.1:8200/v1/secret/metadata/my-secret ``` -### Sample Response +### Sample response The example below shows output for a query path of `secret/` when there are secrets at `secret/foo` and `secret/foo/bar`; note the difference in the two @@ -544,7 +544,7 @@ entries. } ``` -## Read Secret Metadata +## Read secret metadata This endpoint retrieves the metadata and versions for the secret at the specified path. Metadata is version-agnostic. @@ -561,7 +561,7 @@ specified path. Metadata is version-agnostic. - `path` `(string: )` – Specifies the path of the secret to read. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -569,7 +569,7 @@ $ curl \ https://127.0.0.1:8200/v1/secret/metadata/my-secret ``` -### Sample Response +### Sample response ```json { @@ -607,7 +607,7 @@ $ curl \ } ``` -## Create/Update Metadata +## Create/Update metadata This endpoint creates or updates the metadata of a secret at the specified location. It does not create a new version. @@ -643,7 +643,7 @@ It does not create a new version. - `custom_metadata` `(map: nil)` - A map of arbitrary string to string valued user-provided metadata meant to describe the secret. -### Sample Payload +### Sample payload ```json { @@ -658,7 +658,7 @@ It does not create a new version. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -668,7 +668,7 @@ $ curl \ https://127.0.0.1:8200/v1/secret/metadata/my-secret ``` -## Patch Metadata +## Patch metadata This endpoint patches an existing metadata entry of a secret at the specified location. The calling token must have an ACL policy granting the `patch` @@ -707,7 +707,7 @@ not create a new version. - `custom_metadata` `(map: nil)` - A map of arbitrary string to string valued user-provided metadata meant to describe the secret. -### Sample Payload +### Sample payload ```json { @@ -718,7 +718,7 @@ not create a new version. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -729,7 +729,7 @@ $ curl \ https://127.0.0.1:8200/v1/secret/metadata/my-secret ``` -## Delete Metadata and All Versions +## Delete metadata and all versions This endpoint permanently deletes the key metadata and all version data for the specified key. All version history will be removed. @@ -746,7 +746,7 @@ specified key. All version history will be removed. - `path` `(string: )` – Specifies the path of the secret to delete. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/secret/ldap.mdx b/website/content/api-docs/secret/ldap.mdx index a5ee22ccfbab..b8e0c5b7b2c1 100644 --- a/website/content/api-docs/secret/ldap.mdx +++ b/website/content/api-docs/secret/ldap.mdx @@ -4,7 +4,7 @@ page_title: LDAP - Secrets Engines - HTTP API description: This is the API documentation for the Vault LDAP secrets engine. --- -# LDAP Secrets Engine (API) +# LDAP secrets engine (API) @include 'x509-sha1-deprecation.mdx' @@ -16,7 +16,7 @@ This documentation assumes the LDAP secrets engine is enabled at the `/ldap` pat in Vault. Since it is possible to mount secrets engines at any path, please update your API calls accordingly. -## Configuration Management +## Configuration management This endpoint configures the LDAP secret engine to manage user entries. @@ -87,7 +87,7 @@ configuration if both are specified. See [LDAP secrets engine docs](/vault/docs/secrets/ldap) for additional information. -### Sample Payload +### Sample payload ```json { @@ -97,7 +97,7 @@ See [LDAP secrets engine docs](/vault/docs/secrets/ldap) for additional informat } ``` -### Sample POST Request +### Sample POST request ```shell-session $ curl \ @@ -107,7 +107,7 @@ $ curl \ http://127.0.0.1:8200/v1/ldap/config ``` -### Sample GET Request +### Sample GET request ```shell-session $ curl \ @@ -116,7 +116,7 @@ $ curl \ https://127.0.0.1:8200/v1/ldap/config ``` -### Sample Response +### Sample response ```json { @@ -135,7 +135,7 @@ $ curl \ } ``` -## Rotate Root Password +## Rotate root password The `rotate-root` endpoint offers password rotation for the `binddn` entry used to manage LDAP. This generated password will only be known to Vault and will not be retrievable once rotated. @@ -144,7 +144,7 @@ This generated password will only be known to Vault and will not be retrievable | :----- | :---------------------- | | `POST` | `/ldap/rotate-root` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -153,7 +153,7 @@ $ curl \ http://127.0.0.1:8200/v1/ldap/rotate-root ``` -## Static Roles +## Static roles The `static-role` endpoint configures Vault to manage the passwords of existing individual LDAP entries. @@ -180,7 +180,7 @@ The `static-role` endpoint configures Vault to manage the passwords of existing [duration format strings](/vault/docs/concepts/duration-format). The minimum rotation period is 5 seconds.
**Example:** `"3600", "5s", "1h"` -### Sample Payload +### Sample payload ```json { @@ -190,7 +190,7 @@ The `static-role` endpoint configures Vault to manage the passwords of existing } ``` -### Sample POST Request +### Sample POST request ```shell-session $ curl \ @@ -200,7 +200,7 @@ $ curl \ http://127.0.0.1:8200/v1/ldap/static-role/hashicorp ``` -### Sample GET Request +### Sample GET request ```shell-session $ curl \ @@ -209,7 +209,7 @@ $ curl \ http://127.0.0.1:8200/v1/ldap/static-role/hashicorp ``` -### Sample GET Response +### Sample GET response ```json { @@ -222,13 +222,13 @@ $ curl \ } ``` -### Sample LIST Response +### Sample LIST response ```json ["hashicorp", "bob"] ``` -## Static Role Passwords +## Static role passwords The `static-cred` endpoint offers the credential information for a given static-role. @@ -236,7 +236,7 @@ The `static-cred` endpoint offers the credential information for a given static- | :----- | :--------------------------------- | | `GET` | `/ldap/static-cred/:role_name` | -#### Sample Get Request +#### Sample get request ```shell-session $ curl \ @@ -245,7 +245,7 @@ $ curl \ http://127.0.0.1:8200/v1/ldap/static-cred/hashicorp ``` -#### Sample Get Response +#### Sample get response ```json { @@ -259,7 +259,7 @@ $ curl \ } ``` -## Manually Rotate Static Role Password +## Manually rotate static role password The `rotate-role` endpoint rotates the password of an existing static role. @@ -267,7 +267,7 @@ The `rotate-role` endpoint rotates the password of an existing static role. | :----- | :--------------------------------- | | `POST` | `/ldap/rotate-role/:role_name` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -276,12 +276,12 @@ $ curl \ http://127.0.0.1:8200/v1/ldap/rotate-role/:role_name ``` -## Dynamic Roles +## Dynamic roles Create or update a dynamic role configuration. This provides instructions to Vault on how to create an LDAP domain user account. -### Create/Delete Dynamic Role Configuration +### Create/Delete dynamic role configuration Creates, updates, or deletes a dynamic role. @@ -351,7 +351,7 @@ The `creation_ldif`, `deletion_ldif`, `rollback_ldif`, and `username_template` f [Username Templating](/vault/docs/concepts/username-templating) for details on how to use templating. Also see [Templates](#templates) for specifics on what data is available for each template. -#### Sample Payload +#### Sample payload Sample LDIF files: @@ -390,7 +390,7 @@ Full Payload: -> Note: The LDIF statements may optionally be base64 encoded. If they are base64 encoded when creating/updating the role configuration, the decoded version will be returned from the `GET` endpoint. -#### Sample POST Request +#### Sample POST request ```shell-session $ curl \ @@ -400,7 +400,7 @@ $ curl \ http://127.0.0.1:8200/v1/ldap/role/dynamic-role ``` -### Read Dynamic Role Configuration +### Read dynamic role configuration Retrieves a dynamic role's configuration. @@ -438,7 +438,7 @@ If a field needs to be modified (such as SHA256 hashing, base64 encoding, etc.) [built-in functions](#template-functions). This uses a "pipe" syntax: `{{.Username | base64}}`. Values may be "piped" to multiple functions: `{{.Username | lowercase | base64}}` -#### LDIF Template Fields +#### LDIF template fields The following parameters are available within the LDIF templates: @@ -470,7 +470,7 @@ time may be slightly earlier than the associated lease due to where this value i calculates details of the lease.
**Format:** Integer indicating the number of seconds elapsed since January 1, 1970. -#### Username Template Fields +#### Username template fields The following parameters are available within the username template: @@ -487,7 +487,7 @@ the dashes with underscores. See [Template Functions](#template-functions) for m `.DisplayName` - The display name associated with the user making the request against Value. -#### Template Functions +#### Template functions Both the LDIF templates and the username template use the [Go template language](https://golang.org/pkg/text/template) so all [functions](https://golang.org/pkg/text/template/#hdr-Functions) and capabilities from that language are @@ -542,7 +542,7 @@ would be `v_myrealle6da86ec_1234567890` and the username for the second role wou `uuid` - Generates a random UUID.
**Example:** `{{uuid}}` -##### LDIF Template Functions +##### LDIF template functions Additionally, the LDIF templates include an additional function to facilitate Active Directory password handling. The username template cannot use this function. @@ -550,7 +550,7 @@ The username template cannot use this function. `utf16le` - Encodes the provided value into UTF16-LE.
**Example:** `{{.FieldName | utf16le}}` -## Dynamic Role Passwords +## Dynamic role passwords The `creds` endpoint offers the credential information for a given dynamic role. @@ -558,7 +558,7 @@ The `creds` endpoint offers the credential information for a given dynamic role. | :----- | :--------------------------------- | | `GET` | `/ldap/creds/:role_name` | -#### Sample Get Request +#### Sample get request ```shell-session $ curl \ @@ -567,7 +567,7 @@ $ curl \ http://127.0.0.1:8200/v1/ldap/creds/dynamic-role ``` -#### Sample Get Response +#### Sample get response ```json { @@ -579,7 +579,7 @@ $ curl \ } ``` -## Library Set Management +## Library set management The `library` endpoint configures the sets of service accounts that Vault will offer for check-out. @@ -607,7 +607,7 @@ When adding a service account to the library, Vault verifies it already exists i - `disable_check_in_enforcement` `(bool: false, optional)` - Disable enforcing that service accounts must be checked in by the entity or client token that checked them out. Defaults to false. -### Sample POST Request +### Sample POST request ```shell-session $ curl \ @@ -617,7 +617,7 @@ $ curl \ http://127.0.0.1:8200/v1/ldap/library/accounting-team ``` -### Sample POST Payload +### Sample POST payload ```json { @@ -628,7 +628,7 @@ $ curl \ } ``` -### Sample GET Response +### Sample GET response ```json { @@ -639,7 +639,7 @@ $ curl \ } ``` -### Sample LIST Response +### Sample LIST response Performing a `LIST` on the `/ldap/library` endpoint will list the names of all the sets of service accounts Vault contains. @@ -647,7 +647,7 @@ Performing a `LIST` on the `/ldap/library` endpoint will list the names of all t ["accounting-team"] ``` -## Library Set Status Check +## Library set status check This endpoint provides the check-out status of service accounts in a library set. @@ -655,7 +655,7 @@ This endpoint provides the check-out status of service accounts in a library set | :----- | :----------------------------- | | `GET` | `/ldap/library/:set_name/status` | -### Sample GET Request +### Sample GET request ```shell-session $ curl \ @@ -664,7 +664,7 @@ $ curl \ http://127.0.0.1:8200/v1/ldap/library/accounting-team/status ``` -### Sample GET Response +### Sample GET response ```json { @@ -688,7 +688,7 @@ $ curl \ } ``` -## Check-Out Management +## Check-Out management This endpoint provides service account check out for a library set. @@ -706,7 +706,7 @@ Returns a `200` if a credential is available, and a `400` if no credential is av Defaults to the set's `ttl`. If the requested `ttl` is higher than the set's, the set's will be used. Uses [duration format strings](/vault/docs/concepts/duration-format). -### Sample POST Request +### Sample POST request ```shell-session $ curl \ @@ -716,7 +716,7 @@ $ curl \ http://127.0.0.1:8200/v1/ldap/library/accounting-team/check-out ``` -### Sample POST Payload +### Sample POST payload ```json { @@ -724,7 +724,7 @@ $ curl \ } ``` -### Sample POST Response +### Sample POST response ```json { @@ -742,7 +742,7 @@ $ curl \ } ``` -## Check-In Management +## Check-In management By default, check-in must be called by the same entity or client token used for check-out. To disable this behavior, use the `disable_check_in_enforcement` toggle on the library set. Or, use @@ -766,7 +766,7 @@ in _by this particular call_. - `service_account_names` `(string: "", or list: [] optional)` - The names of all the service accounts to be checked in. May be omitted if only one is checked out. -### Sample POST Request +### Sample POST request ```shell-session $ curl \ @@ -776,7 +776,7 @@ $ curl \ http://127.0.0.1:8200/v1/ldap/library/accounting-team/check-in ``` -### Sample POST Payload +### Sample POST payload ```json { @@ -784,7 +784,7 @@ $ curl \ } ``` -### Sample POST Response +### Sample POST response ```json { diff --git a/website/content/api-docs/secret/mongodbatlas.mdx b/website/content/api-docs/secret/mongodbatlas.mdx index 5490801eb8e5..1c3d75647820 100644 --- a/website/content/api-docs/secret/mongodbatlas.mdx +++ b/website/content/api-docs/secret/mongodbatlas.mdx @@ -5,7 +5,7 @@ description: |- The MongoDB Atlas Secrets Engine for Vault generates MongoDB Atlas Programmatic API Keys dynamically. --- -# MongoDB Atlas Secrets Engine +# MongoDB atlas secrets engine The MongoDB Atlas Secrets Engine generates Programmatic API keys for MongoDB Atlas. This allows one to manage the lifecycle of these MongoDB Atlas secrets through Vault. The created MongoDB Atlas secrets are time-based and are automatically revoked when the Vault lease expires, unless renewed. Vault will create a Programmatic API key for each lease scoped to the MongoDB Atlas project or organization denoted with the included role(s). An IP Whitelist may also be configured for the Programmatic API key with desired IPs and/or CIDR blocks. @@ -13,7 +13,7 @@ time-based and are automatically revoked when the Vault lease expires, unless re The MongoDB Atlas Programmatic API Key Public and Private Key is returned to the caller. To learn more about Programmatic API Keys visit the [Programmatic API Keys Doc](https://docs.atlas.mongodb.com/reference/api/apiKeys/). -## Configure Connection +## Configure connection In addition to the parameters defined by the Secrets Engines Backend, this plugin has a number of parameters to further configure a connection. @@ -26,7 +26,7 @@ In addition to the parameters defined by the Secrets Engines Backend, this plugi - `public_key` `(string: )` – The Public Programmatic API Key used to authenticate with the MongoDB Atlas API. - `private_key` `(string: )` - The Private Programmatic API Key used to connect with MongoDB Atlas API. -### Sample Payload +### Sample payload ```json { @@ -35,7 +35,7 @@ In addition to the parameters defined by the Secrets Engines Backend, this plugi } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -45,7 +45,7 @@ $ curl \ http://127.0.0.1:8200/mongodbatlas/config ``` -## Create/Update Programmatic API Key role +## Create/Update programmatic API key role Programmatic API Key credential types create a Vault role to generate a Programmatic API Key at either the MongoDB Atlas Organization or Project level with the designated role(s) for programmatic access. If a role with the name does not exist, it will be created. If the role exists, it will be updated with the new attributes. @@ -95,7 +95,7 @@ either the MongoDB Atlas Organization or Project level with the designated role( * `max_ttl` `(string )` - The maximum allowed lifetime of credentials issued using this role. -### Sample Payload +### Sample payload ```json { @@ -114,7 +114,7 @@ $ curl \ http://127.0.0.1:8200/mongodbatlas/roles/test-programmatic-key ``` -### Sample Response +### Sample response ```json { @@ -128,7 +128,7 @@ $ curl \ } ``` -## Read Programmatic API Key role +## Read programmatic API key role | Method | Path | | :----- | :------------- | @@ -138,7 +138,7 @@ $ curl \ - `name` `(string )` - Unique identifier name of the role name -### Sample Payload +### Sample payload ```shell-session $ curl \ @@ -148,7 +148,7 @@ $ curl \ http://127.0.0.1:8200/mongodbatlas/roles/test-programmatic-key ``` -### Sample Response +### Sample response ```json { @@ -162,13 +162,13 @@ $ curl \ } ``` -## List Programmatic API Key role +## List programmatic API key role | Method | Path | | :----- | :------- | | `GET` | `/roles` | -### Sample Payload +### Sample payload ```shell-session $ curl \ @@ -178,7 +178,7 @@ $ curl \ http://127.0.0.1:8200/mongodbatlas/roles ``` -### Sample Response +### Sample response ```json [ @@ -203,7 +203,7 @@ $ curl \ ] ``` -## Delete Programmatic API Key role +## Delete programmatic API key role | Method | Path | | :------- | :------------- | @@ -213,7 +213,7 @@ $ curl \ - `name` `(string )` - Unique identifier name of the role name -### Sample Payload +### Sample payload ```shell-session $ curl \ @@ -223,7 +223,7 @@ $ curl \ http://127.0.0.1:8200/mongodbatlas/roles/test-programmatic-key ``` -## Read Credential +## Read credential | Method | Path | | :----- | :------------- | @@ -233,7 +233,7 @@ $ curl \ - `name` `(string )` - Unique identifier name of the credential -### Sample Request +### Sample request ```shell-session $ curl \ @@ -241,7 +241,7 @@ $ curl \ http://127.0.0.1:8200/mongodbatlas/creds/0fLBv1c2YDzPlJB1PwsRRKHR ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/secret/nomad.mdx b/website/content/api-docs/secret/nomad.mdx index b71f1cacdca9..1f3151173625 100644 --- a/website/content/api-docs/secret/nomad.mdx +++ b/website/content/api-docs/secret/nomad.mdx @@ -4,7 +4,7 @@ page_title: Nomad Secrets Engine- HTTP API description: This is the API documentation for the Vault Nomad secrets engine. --- -# Nomad Secrets Engine (API) +# Nomad secrets engine (API) @include 'x509-sha1-deprecation.mdx' @@ -16,7 +16,7 @@ This documentation assumes the Nomad secrets engine is mounted at the `/nomad` p in Vault. Since it is possible to mount secrets engines at any location, please update your API calls accordingly. -## Configure Access +## Configure access This endpoint configures the access information for Nomad. This access information is used so that Vault can communicate with Nomad and generate @@ -53,7 +53,7 @@ Nomad tokens. - `client_key` `(string: "")` - Client key used for Nomad's TLS communication, must be x509 PEM encoded and if this is set you need to also set client_cert. -### Sample Payload +### Sample payload ```json { @@ -63,7 +63,7 @@ Nomad tokens. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -73,7 +73,7 @@ $ curl \ http://127.0.0.1:8200/v1/nomad/config/access ``` -## Read Access Configuration +## Read access configuration This endpoint queries for information about the Nomad connection. @@ -81,7 +81,7 @@ This endpoint queries for information about the Nomad connection. | :----- | :--------------------- | | `GET` | `/nomad/config/access` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -89,7 +89,7 @@ $ curl \ http://127.0.0.1:8200/v1/nomad/config/access ``` -### Sample Response +### Sample response ```json "data": { @@ -97,7 +97,7 @@ $ curl \ } ``` -## Configure Lease +## Configure lease This endpoint configures the lease settings for generated tokens. @@ -111,7 +111,7 @@ This endpoint configures the lease settings for generated tokens. - `max_ttl` `(string: "")` – Specifies the max ttl for the lease. Uses [duration format strings](/vault/docs/concepts/duration-format). -### Sample Payload +### Sample payload ```json { @@ -120,7 +120,7 @@ This endpoint configures the lease settings for generated tokens. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -130,7 +130,7 @@ $ curl \ http://127.0.0.1:8200/v1/nomad/config/lease ``` -## Read Lease Configuration +## Read lease configuration This endpoint queries for information about the Lease TTL for the specified mount. @@ -138,7 +138,7 @@ This endpoint queries for information about the Lease TTL for the specified moun | :----- | :-------------------- | | `GET` | `/nomad/config/lease` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -146,7 +146,7 @@ $ curl \ http://127.0.0.1:8200/v1/nomad/config/lease ``` -### Sample Response +### Sample response ```json "data": { @@ -155,7 +155,7 @@ $ curl \ } ``` -## Delete Lease Configuration +## Delete lease configuration This endpoint deletes the lease configuration. @@ -163,7 +163,7 @@ This endpoint deletes the lease configuration. | :------- | :-------------------- | | `DELETE` | `/nomad/config/lease` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -172,7 +172,7 @@ $ curl \ http://127.0.0.1:8200/v1/nomad/config/lease ``` -## Create/Update Role +## Create/Update role This endpoint creates or updates the Nomad role definition in Vault. If the role does not exist, it will be created. If the role already exists, it will receive updated attributes. @@ -193,7 +193,7 @@ updated attributes. - `type` `(string: "client")` - Specifies the type of token to create when using this role. Valid values are `"client"` or `"management"`. -### Sample Payload +### Sample payload To create a client token with a custom policy: @@ -203,7 +203,7 @@ To create a client token with a custom policy: } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -213,7 +213,7 @@ $ curl \ http://127.0.0.1:8200/v1/nomad/role/monitoring ``` -## Read Role +## Read role This endpoint queries for information about a Nomad role with the given name. If no role exists with that name, a 404 is returned. @@ -227,7 +227,7 @@ If no role exists with that name, a 404 is returned. - `name` `(string: )` – Specifies the name of the role to query. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -235,7 +235,7 @@ $ curl \ http://127.0.0.1:8200/v1/nomad/role/monitoring ``` -### Sample Response +### Sample response ```json { @@ -247,7 +247,7 @@ $ curl \ } ``` -## List Roles +## List roles This endpoint lists all existing roles in the secrets engine. @@ -256,7 +256,7 @@ This endpoint lists all existing roles in the secrets engine. | `LIST` | `/nomad/role` | | `GET` | `/nomad/role?list=true` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -265,7 +265,7 @@ $ curl \ http://127.0.0.1:8200/v1/nomad/role ``` -### Sample Response +### Sample response ```json { @@ -275,7 +275,7 @@ $ curl \ } ``` -## Delete Role +## Delete role This endpoint deletes a Nomad role with the given name. Even if the role does not exist, this endpoint will still return a successful response. @@ -289,7 +289,7 @@ not exist, this endpoint will still return a successful response. - `name` `(string: )` – Specifies the name of the role to delete. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -298,7 +298,7 @@ $ curl \ http://127.0.0.1:8200/v1/nomad/role/example-role ``` -## Generate Credential +## Generate credential This endpoint generates a dynamic Nomad token based on the given role definition. @@ -312,7 +312,7 @@ definition. - `name` `(string: )` – Specifies the name of an existing role against which to create this Nomad token. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -320,7 +320,7 @@ $ curl \ http://127.0.0.1:8200/v1/nomad/creds/example ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/secret/pki.mdx b/website/content/api-docs/secret/pki.mdx index e94a2fedb655..59a847e3c303 100644 --- a/website/content/api-docs/secret/pki.mdx +++ b/website/content/api-docs/secret/pki.mdx @@ -4,7 +4,7 @@ page_title: PKI - Secrets Engines - HTTP API description: This is the API documentation for the Vault PKI secrets engine. --- -# PKI Secrets Engine (API) +# PKI secrets engine (API) @include 'x509-sha1-deprecation.mdx' @@ -16,7 +16,7 @@ This documentation assumes the PKI secrets engine is enabled at the `/pki` path in Vault. Since it is possible to enable secrets engines at any location, please update your API calls accordingly. -## Table of Contents +## Table of contents - [Notice About New Multi-Issuer Functionality](#notice-about-new-multi-issuer-functionality) - [ACME Certificate Issuance](#acme-certificate-issuance) @@ -91,7 +91,7 @@ update your API calls accordingly. - [Managed Key](#managed-keys) (Enterprise Only) - [Vault CLI with DER/PEM responses](#vault-cli-with-der-pem-responses) -## Notice About New Multi-Issuer Functionality +## Notice about new Multi-Issuer functionality Vault since 1.11.0 allows a single PKI mount to have multiple Certificate Authority (CA) certificates ("issuers") in a single mount, for the purpose @@ -113,7 +113,7 @@ to mix different types of CAs (roots and intermediates). current issuing certificate on migration from an older Vault version (Vault < 1.11.0). -## ACME Certificate Issuance +## ACME certificate issuance Starting with Vault 1.14, Vault supports the [ACME certificate lifecycle management protocol](https://datatracker.ietf.org/doc/html/rfc8555) for issuing @@ -128,7 +128,7 @@ Using ACME with a role requires `no_store=false` to be set on the role; this allows the certificate to be stored and later fetched through the ACME protocol. -### ACME Directories +### ACME directories Vault PKI supports the following ACME directories, providing different restrictions around usage (defaults, a specific issuer and/or a specific @@ -161,7 +161,7 @@ endpoint, but with additional verification that the client has proven ownership (within the ACME protocol) of the requested certificate identifiers. -#### ACME Challenge Types +#### ACME challenge types Vault supports the following ACME challenge types presently: @@ -172,7 +172,7 @@ Vault supports the following ACME challenge types presently: A custom DNS resolver used by the server for looking up DNS names for use with both mechanisms can be added via the [ACME configuration](#set-acme-configuration). -#### ACME External Account Bindings +#### ACME external account bindings ACME External Account Binding (EAB) Policy can enforce that clients need to have a valid external account binding to Vault. Before registering a new account, @@ -197,12 +197,12 @@ Vault endpoint, but not further to the client's entity or other information. deployments. Use of the `VAULT_DISABLE_PUBLIC_ACME` environment variable can be used to enforce all ACME instances have EAB enabled. -#### ACME Accounts +#### ACME accounts ACME Accounts are created specific to a particular directory and are not portable across Performance Secondary clusters. -#### ACME Required Headers +#### ACME required headers ACME requires the following response headers (`allowed_response_headers`) to be specified by [mount tuning](/vault/api-docs/system/mounts#tune-mount-configuration): @@ -219,7 +219,7 @@ $ vault secrets tune -allowed-response-headers=Location -allowed-response-header pki/ ``` -### Get ACME EAB Binding Token +### Get ACME EAB binding token This endpoint returns a new ACME binding token. The `id` response field can be used as the key identifier and the `key` response field be used as the @@ -240,7 +240,7 @@ are not usable across different ACME directories. No parameters. -#### Sample Request +#### Sample request ``` $ curl \ @@ -249,7 +249,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/acme/new-eab ``` -#### Sample Response +#### Sample response ``` { @@ -263,7 +263,7 @@ $ curl \ } ``` -### List Unused ACME EAB Binding Tokens +### List unused ACME EAB binding tokens This endpoint returns a list of all unused ACME binding tokens; once used, they will be removed from this list. @@ -272,7 +272,7 @@ they will be removed from this list. | :----- | :--------- | | `LIST` | `/pki/eab` | -#### Sample Request +#### Sample request ``` $ curl \ @@ -281,7 +281,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/eab ``` -#### Sample Response +#### Sample response ``` { @@ -300,7 +300,7 @@ $ curl \ } ``` -### Delete Unused ACME EAB Binding Tokens +### Delete unused ACME EAB binding tokens This endpoint allows the deletion of an unused ACME binding token. @@ -313,7 +313,7 @@ This endpoint allows the deletion of an unused ACME binding token. - `key_id` `(string: )` - The id of the EAB binding token to delete. This is part of the request URL. -#### Sample Request +#### Sample request ``` $ curl \ @@ -322,7 +322,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/eab/bc8088d9-3816-5177-ae8e-d8393265f7dd ``` -### Get ACME Configuration +### Get ACME configuration This endpoint allows reading of the current ACME server configuration used by this mount. @@ -331,7 +331,7 @@ this mount. | :----- | :----------------- | | `GET` | `/pki/config/acme` | -#### Sample Request +#### Sample request ``` $ curl \ @@ -339,7 +339,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/config/acme ``` -#### Sample Response +#### Sample response ``` { @@ -358,7 +358,7 @@ $ curl \ } ``` -### Set ACME Configuration +### Set ACME configuration This endpoint allows setting the ACME server configuration used by this mount. @@ -409,7 +409,7 @@ mount. - `enabled` `(bool: false)` - Whether ACME is enabled on this mount. When ACME is disabled, all requests to ACME directory URLs will return 404. -#### Sample Payload +#### Sample payload ``` { @@ -417,7 +417,7 @@ mount. } ``` -#### Sample Request +#### Sample request ``` $ curl \ @@ -427,7 +427,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/config/acme ``` -#### Sample Response +#### Sample response ``` { @@ -446,7 +446,7 @@ $ curl \ } ``` -## Issuing Certificates +## Issuing certificates The following API endpoints allow users or operators to request certificates and are all authenticated. @@ -467,7 +467,7 @@ Vault PKI secrets engine presently only allows revocation by serial number; because this could allow users to deny access to other users, it should be restricted to operators. -### List Roles +### List roles This endpoint returns a list of available roles. Only the role names are returned, not any values. It is useful to both operators and users. @@ -476,7 +476,7 @@ returned, not any values. It is useful to both operators and users. | :----- | :----------- | | `LIST` | `/pki/roles` | -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -485,7 +485,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/roles ``` -#### Sample Response +#### Sample response ```json { @@ -499,7 +499,7 @@ $ curl \ } ``` -### Read Role +### Read role This endpoint queries the role definition. It is useful to both operators and users. @@ -513,7 +513,7 @@ users. - `name` `(string: )` - Specifies the name of the role to read. This is part of the request URL. -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -521,7 +521,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/roles/my-role ``` -#### Sample Response +#### Sample response ```json { @@ -550,7 +550,7 @@ $ curl \ -### Generate Certificate and Key +### Generate certificate and key This endpoint generates a new set of credentials (private key and certificate) based on the role named in the endpoint. The issuing CA certificate and full CA @@ -650,7 +650,7 @@ It is suggested to limit access to the path-overridden issue endpoint (on signed certificate. This field is validated against `allowed_user_ids` on the role. -#### Sample Payload +#### Sample payload ```json { @@ -658,7 +658,7 @@ It is suggested to limit access to the path-overridden issue endpoint (on } ``` -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -668,7 +668,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/issue/my-role ``` -#### Sample Response +#### Sample response ```json { @@ -690,7 +690,7 @@ $ curl \ } ``` -### Sign Certificate +### Sign certificate This endpoint signs a new certificate based upon the provided CSR and the supplied parameters, subject to the restrictions contained in the role named in @@ -776,7 +776,7 @@ It is suggested to limit access to the path-overridden sign endpoint (on signed certificate. This field is validated against `allowed_user_ids` on the role. -#### Sample Payload +#### Sample payload ```json { @@ -785,7 +785,7 @@ It is suggested to limit access to the path-overridden sign endpoint (on } ``` -#### Sample Response +#### Sample response ```json { @@ -804,7 +804,7 @@ It is suggested to limit access to the path-overridden sign endpoint (on } ``` -### Sign Intermediate +### Sign intermediate This endpoint uses the configured CA certificate to issue a certificate with appropriate values for acting as an intermediate CA. Distribution points use the @@ -963,7 +963,7 @@ when signing an externally-owned intermediate. over PKCS#1v1.5 signatures when a RSA-type issuer is used. Ignored for ECDSA/Ed25519 issuers. -#### Sample Payload +#### Sample payload ```json { @@ -972,7 +972,7 @@ when signing an externally-owned intermediate. } ``` -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -982,7 +982,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/root/sign-intermediate ``` -#### Sample Response +#### Sample response ```json { @@ -1038,7 +1038,7 @@ endpoint, you most likely should be using a different endpoint (such as - `require_matching_certificate_algorithms` `(bool: false)` - If true, requires that the public key algorithm of the CA match that of the submitted certificate. -#### Sample Payload +#### Sample payload ```json { @@ -1046,7 +1046,7 @@ that the public key algorithm of the CA match that of the submitted certificate. } ``` -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -1056,7 +1056,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/root/sign-self-issued ``` -#### Sample Response +#### Sample response ```json { @@ -1071,7 +1071,7 @@ $ curl \ } ``` -### Sign Verbatim +### Sign verbatim This endpoint signs a new certificate based upon the provided CSR. Values are taken verbatim from the CSR; the _only_ restriction is that this endpoint will @@ -1165,7 +1165,7 @@ have access.** User ID (OID 0.9.2342.19200300.100.1.1) Subject values to be placed on the signed certificate. No validation on names is performed using this endpoint. -#### Sample Payload +#### Sample payload ```json { @@ -1173,7 +1173,7 @@ have access.** } ``` -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -1183,7 +1183,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/sign-verbatim ``` -#### Sample Response +#### Sample response ```json { @@ -1202,7 +1202,7 @@ $ curl \ } ``` -### Revoke Certificate +### Revoke certificate This endpoint revokes a certificate using its serial number. This is an alternative option to the standard method of revoking using Vault lease IDs. A @@ -1230,7 +1230,7 @@ successful revocation will rotate the CRL. in PEM format. This certificate must have been signed by one of the issuers in this mount in order to be accepted for revocation. -#### Sample Payload +#### Sample payload ```json { @@ -1238,7 +1238,7 @@ successful revocation will rotate the CRL. } ``` -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -1248,7 +1248,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/revoke ``` -#### Sample Response +#### Sample response ```json { @@ -1258,7 +1258,7 @@ $ curl \ } ``` -### Revoke Certificate with Private Key +### Revoke certificate with private key This endpoint revokes a certificate using its private key as proof that the request is authorized by an appropriate individual (Proof of Possession). @@ -1297,7 +1297,7 @@ It is not possible to revoke issuers using this path. certificate/serial number) if this private key is used in multiple certificates as Vault does not maintain such a mapping. -#### Sample Payload +#### Sample payload ```json { @@ -1306,7 +1306,7 @@ It is not possible to revoke issuers using this path. } ``` -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -1316,7 +1316,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/revoke-with-key ``` -#### Sample Response +#### Sample response ```json { @@ -1327,7 +1327,7 @@ $ curl \ ``` -### List Revoked Certificates +### List revoked certificates This endpoint returns a list of serial numbers that have been revoked on the local cluster. @@ -1335,7 +1335,7 @@ This endpoint returns a list of serial numbers that have been revoked on the loc |:-------|:------------------| | `LIST` | `/certs/revoked` | -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -1344,7 +1344,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/certs/revoked ``` -#### Sample Response +#### Sample response ```json { @@ -1356,7 +1356,7 @@ $ curl \ } ``` -### List Revocation Requests +### List revocation requests This endpoint returns a list of serial numbers that have been requested to be revoked on any cluster, along with information about the request's state @@ -1366,7 +1366,7 @@ and which cluster it originated on. | :----- | :------------------------ | | `LIST` | `/certs/revocation-queue` | -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -1375,7 +1375,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/certs/revocation-queue ``` -#### Sample Response +#### Sample response ```json { @@ -1392,7 +1392,7 @@ $ curl \ } ``` -### List Cross-Cluster Revocations +### List Cross-Cluster revocations This endpoint returns a list of serial numbers that have been revoked on any cluster, along with the clusters that have a copy of that revoked certificate. @@ -1401,7 +1401,7 @@ cluster, along with the clusters that have a copy of that revoked certificate. | :----- | :----------------------- | | `LIST` | `/certs/unified-revoked` | -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -1410,7 +1410,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/certs/unified-revoked ``` -#### Sample Response +#### Sample response ```json { @@ -1431,7 +1431,7 @@ $ curl \ --- -## Accessing Authority Information +## Accessing authority information All consumers of the PKI Secrets Engine mount point will have access to the following unauthenticated APIs, useful for reading information about the @@ -1445,7 +1445,7 @@ also be read](#read-certificate), assuming their serial number is known. Finally, the list of issuing certificates is public information in this mount. -### List Issuers +### List issuers This endpoint returns a list of issuers currently provisioned in this mount. The response includes both the issuer's identifier as well as the name chosen @@ -1457,7 +1457,7 @@ This endpoint is unauthenticated. | :----- | :------------- | | `LIST` | `/pki/issuers` | -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -1465,7 +1465,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/issuers ``` -#### Sample Response +#### Sample response ```json { @@ -1488,7 +1488,7 @@ $ curl \ -### Read Issuer Certificate +### Read issuer certificate This endpoint retrieves the specified issuer's certificate. @@ -1525,14 +1525,14 @@ These are unauthenticated endpoints. ~> Note: This parameter is not present on the `/pki/cert/ca` and `/pki/ca(/pem)?` paths and takes the implicit value `default`. -#### Sample Request +#### Sample request ```shell-session $ curl \ http://127.0.0.1:8200/v1/pki/issuer/root-x1/json ``` -#### Sample Response +#### Sample response ```text { @@ -1549,7 +1549,7 @@ $ curl \ -### Read Default Issuer Certificate Chain +### Read default issuer certificate chain This endpoint retrieves the default issuer's CA certificate chain, including the default issuer. @@ -1568,14 +1568,14 @@ These are unauthenticated endpoints. (including the default issuer's certificate and all parent issuers known to Vault) in these responses. -#### Sample Request +#### Sample request ```shell-session $ curl \ http://127.0.0.1:8200/v1/pki/ca_chain ``` -#### Sample Response +#### Sample response ```text @@ -1583,7 +1583,7 @@ $ curl \ -### Read Issuer CRL +### Read issuer CRL This endpoint retrieves the specified issuer's CRL. @@ -1661,14 +1661,14 @@ These are unauthenticated endpoints. ~> Note: This parameter is not present on the `/pki/cert/crl` and `/pki/crl(/pem)?` paths and takes the implicit value `default`. -#### Sample Request +#### Sample request ```shell-session $ curl \ http://127.0.0.1:8200/v1/pki/issuer/root-x1/crl ``` -#### Sample Response +#### Sample response ```json { @@ -1678,7 +1678,7 @@ $ curl \ } ``` -### OCSP Request +### OCSP request This endpoint retrieves an OCSP response (revocation status) for a given serial number. The request/response formats are based on [RFC 6960](https://datatracker.ietf.org/doc/html/rfc6960) @@ -1714,13 +1714,13 @@ These are unauthenticated endpoints. - None -#### Sample Request +#### Sample request ```shell-session openssl ocsp -no_nonce -issuer issuer.pem -CAfile ca_chain.pem -cert cert-to-revoke.pem -text -url $VAULT_ADDR/v1/pki/ocsp ``` -### List Certificates +### List certificates This endpoint returns a list of the current certificates by serial number only. The response does not include the [special serial numbers](#read-certificate-serial-param-values) @@ -1744,7 +1744,7 @@ certificate's serial number to appear in this list. | :----- | :----------- | | `LIST` | `/pki/certs` | -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -1753,7 +1753,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/certs ``` -#### Sample Response +#### Sample response ```json { @@ -1768,7 +1768,7 @@ $ curl \ -### Read Certificate +### Read certificate This endpoint retrieves the certificate specified by its serial number, including issued certificates. @@ -1803,14 +1803,14 @@ These are unauthenticated endpoints. the `ca_chain` response, for both the `certificate` and newer `ca_chain` fields. The root certificate is no longer elided. -#### Sample Request +#### Sample request ```shell-session $ curl \ http://127.0.0.1:8200/v1/pki/cert/67:b4:f7:2c:aa:ef:b9:30:f6:ae:f5:12:21:79:ac:08:8a:86:89:72 ``` -#### Sample Response +#### Sample response ```json { @@ -1825,18 +1825,18 @@ $ curl \ --- -## Managing Keys and Issuers +## Managing keys and issuers The following endpoints are highly privileged and allow operators to generate or import new issuer certificates and keys, remove existing keys and issuers, or read internal information about keys and issuers. -### List Issuers +### List issuers Refer to the [earlier section](#list-issuers) for more information about listing issuers. -### List Keys +### List keys This endpoint returns a list of keys currently provisioned in this mount. The response includes both the key's identifier as well as the name chosen @@ -1848,7 +1848,7 @@ This endpoint is authenticated. | :----- | :----------- | | `LIST` | `/pki/keys` | -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -1857,7 +1857,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/keys ``` -#### Sample Response +#### Sample response ```json { @@ -1874,7 +1874,7 @@ $ curl \ } ``` -### Generate Key +### Generate key This endpoint generates a new private key for use in the PKI mount. This key can be used with either the [root](#generate-root) or [intermediate](#generate-intermediate-csr) @@ -1913,7 +1913,7 @@ used. 4096; with `key_type=ec`, allowed values are: 224, 256 (default), 384, or 521; ignored with `key_type=ed25519`. -#### Managed Keys Parameters +#### Managed keys parameters See [Managed Keys](#managed-keys) for additional details on this feature, if `type` was set to `kms`. One of the following parameters must be set @@ -1922,7 +1922,7 @@ See [Managed Keys](#managed-keys) for additional details on this feature, if - `managed_key_id` `(string: "")` - The managed key's UUID. -#### Sample Payload +#### Sample payload ```json { @@ -1932,7 +1932,7 @@ See [Managed Keys](#managed-keys) for additional details on this feature, if } ``` -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -1942,7 +1942,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/keys/generate/internal ``` -#### Sample Response +#### Sample response ```json { @@ -1959,7 +1959,7 @@ $ curl \ } ``` -### Generate Root +### Generate root This endpoint generates a new self-signed CA certificate and private key. If the path ends with `exported`, the private key will be returned in the @@ -2123,7 +2123,7 @@ use the values set via `config/urls`. * ~> Note: Keys of type `rsa` currently only support PKCS#1 v1.5 signatures. -#### Managed Keys Parameters +#### Managed keys parameters See [Managed Keys](#managed-keys) for additional details on this feature, if `type` was set to `kms`. One of the following parameters must be set @@ -2132,7 +2132,7 @@ See [Managed Keys](#managed-keys) for additional details on this feature, if - `managed_key_id` `(string: "")` - The managed key's UUID. -#### Sample Payload +#### Sample payload ```json { @@ -2140,7 +2140,7 @@ See [Managed Keys](#managed-keys) for additional details on this feature, if } ``` -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -2150,7 +2150,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/root/generate/internal ``` -#### Sample Response +#### Sample response ```json { @@ -2173,7 +2173,7 @@ $ curl \ -### Generate Intermediate CSR +### Generate intermediate CSR This endpoint returns a new CSR for signing, optionally generating a new private key. If using Vault as a root (and, like many other CAs), the various parameters @@ -2322,7 +2322,7 @@ based on this parameter. extension with CA: true. Only needed as a workaround in some compatibility scenarios with Active Directory Certificate Services. -#### Managed Keys Parameters +#### Managed keys parameters See [Managed Keys](#managed-keys) for additional details on this feature, if `type` was set to `kms`. One of the following parameters must be set @@ -2331,7 +2331,7 @@ See [Managed Keys](#managed-keys) for additional details on this feature, if - `managed_key_id` `(string: "")` - The managed key's UUID. -#### Sample Payload +#### Sample payload ```json { @@ -2339,7 +2339,7 @@ See [Managed Keys](#managed-keys) for additional details on this feature, if } ``` -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -2368,7 +2368,7 @@ $ curl \ -### Import CA Certificates and Keys +### Import CA certificates and keys This endpoint allows submitting (importing) the CA information for the backend via a PEM file containing the CA certificate and any private keys, concatenated @@ -2424,7 +2424,7 @@ existed within this mount. ~> Note: this parameter is **only** on the `/pki/intermediate/set-signed` path. -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -2443,7 +2443,7 @@ JSON-formatted, with newlines replaced with `\n`, like so: } ``` -#### Sample Response +#### Sample response ```json { @@ -2459,7 +2459,7 @@ JSON-formatted, with newlines replaced with `\n`, like so: } ``` -### Read Issuer +### Read issuer This endpoint allows an operator to fetch a single issuer certificate and its chain, including internal information not exposed on the [unauthenticated @@ -2479,7 +2479,7 @@ certificates, and what usage modes are set on this issuer. refer to the currently configured default issuer, or the name assigned to an issuer. This parameter is part of the request URL. -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -2487,7 +2487,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/issuer/default ``` -#### Sample Response +#### Sample response ```text { @@ -2507,7 +2507,7 @@ $ curl \ } ``` -### Update Issuer +### Update issuer This endpoint allows an operator to manage a single issuer, updating various properties about it, including its name, an explicitly constructed chain, @@ -2644,7 +2644,7 @@ do so, import a new issuer and a new `issuer_id` will be assigned. ~> **Note**: If no cluster-local address is present and templating is used, issuance will fail. -#### Sample Payload +#### Sample payload ```json { @@ -2652,7 +2652,7 @@ do so, import a new issuer and a new `issuer_id` will be assigned. } ``` -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -2662,7 +2662,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/issuer/default ``` -#### Sample Response +#### Sample response ```text { @@ -2686,7 +2686,7 @@ $ curl \ } ``` -### Revoke Issuer +### Revoke issuer This endpoint allows an operator to revoke an issuer certificate, marking it unable to issue new certificates and adding it to other issuers' CRLs, if they @@ -2713,7 +2713,7 @@ ensure this issuer is not accidentally reused in the future. No parameters. -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -2722,7 +2722,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/issuer/old-intermediate/revoke ``` -#### Sample Response +#### Sample response ```text { @@ -2743,7 +2743,7 @@ $ curl \ } ``` -### Delete Issuer +### Delete issuer This endpoint deletes the specified issuer. A warning is emitted and the default is cleared if this issuer is the default issuer. @@ -2757,7 +2757,7 @@ default is cleared if this issuer is the default issuer. | :------- | :------------------------ | | `DELETE` | `/pki/issuer/:issuer_ref` | -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -2766,7 +2766,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/issuer/root-x1 ``` -### Import Key +### Import key This endpoint allows an operator to import a single pem encoded `rsa`, `ec`, or `ed25519` key. @@ -2786,7 +2786,7 @@ key. name must be unique across all keys and not be the reserved value `default`. -#### Sample Payload +#### Sample payload ```json { @@ -2795,7 +2795,7 @@ key. } ``` -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -2805,7 +2805,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/keys/import ``` -#### Sample Response +#### Sample response ```text { @@ -2817,7 +2817,7 @@ $ curl \ } ``` -### Read Key +### Read key This endpoint allows an operator to fetch information about an existing key. @@ -2835,7 +2835,7 @@ This endpoint allows an operator to fetch information about an existing key. refer to the currently configured default key, or the name assigned to a key. This parameter is part of the request URL. -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -2843,7 +2843,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/key/default ``` -#### Sample Response +#### Sample response ```text { @@ -2855,7 +2855,7 @@ $ curl \ } ``` -### Update Key +### Update key This endpoint allows an operator to manage a single key. Currently, the only parameter that is configurable is the key's name. @@ -2882,7 +2882,7 @@ do so, import a new key and a new `key_id` will be assigned. name must be unique across all keys and not be the reserved value `default`. -#### Sample Payload +#### Sample payload ```json { @@ -2890,7 +2890,7 @@ do so, import a new key and a new `key_id` will be assigned. } ``` -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -2900,7 +2900,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/key/default ``` -#### Sample Response +#### Sample response ```text { @@ -2912,7 +2912,7 @@ $ curl \ } ``` -### Delete Key +### Delete key This endpoint deletes the specified key. A warning is emitted and the default is cleared if this key is the default key. @@ -2930,7 +2930,7 @@ default is cleared if this key is the default key. | :------- | :------------------ | | `DELETE` | `/pki/key/:key_ref` | -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -2939,7 +2939,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/key/key-root-x1 ``` -### Delete All Issuers and Keys +### Delete all issuers and keys This endpoint deletes all issuers and keys within the mount. It is highly recommended to use the individual delete operations instead. This mount @@ -2951,7 +2951,7 @@ _This endpoint requires sudo/root privileges._ | :------- | :---------- | | `DELETE` | `/pki/root` | -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -2962,18 +2962,18 @@ $ curl \ --- -## Managing Authority Information +## Managing authority information The following privileged endpoints allow the operator to control information about the core contents of certificates and to perform privileged operations like rotating the CRLs or performing tidy operations. -### List Roles +### List roles Refer to the [earlier section](#list-roles) for more information about listing roles. -### Create/Update Role +### Create/Update role This endpoint creates or updates the role definition. Note that the `allowed_domains`, `allow_subdomains`, `allow_glob_domains`, and @@ -3294,7 +3294,7 @@ request is denied. Use the bare wildcard `*` value to allow any value. See also the `user_ids` request parameter. -#### Sample Payload +#### Sample payload ```json { @@ -3303,7 +3303,7 @@ request is denied. } ``` -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -3313,12 +3313,12 @@ $ curl \ http://127.0.0.1:8200/v1/pki/roles/my-role ``` -### Read Role +### Read role Refer to the [earlier section](#read-role) for more information about reading roles. -### Delete Role +### Delete role This endpoint deletes the role definition. Deleting a role **does not** revoke certificates previously issued under this role. @@ -3332,7 +3332,7 @@ revoke certificates previously issued under this role. - `name` `(string: )` - Specifies the name of the role to delete. This is part of the request URL. -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -3350,7 +3350,7 @@ configuration will be returned until the configuration is set. | :----- | :----------------- | | `GET` | `/pki/config/urls` | -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -3358,7 +3358,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/config/urls ``` -#### Sample Response +#### Sample response ```json { @@ -3442,7 +3442,7 @@ parameter. ~> **Note**: If no cluster-local address is present and templating is used, issuance will fail. -#### Sample Payload +#### Sample payload ```json { @@ -3452,7 +3452,7 @@ parameter. } ``` -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -3462,7 +3462,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/config/urls ``` -### Read Issuers Configuration +### Read issuers configuration This endpoint allows getting the value of the default issuer. @@ -3470,7 +3470,7 @@ This endpoint allows getting the value of the default issuer. | :----- | :-------------------- | | `GET` | `/pki/config/issuers` | -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -3478,7 +3478,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/config/issuers ``` -#### Sample Response +#### Sample response ```json { @@ -3489,7 +3489,7 @@ $ curl \ } ``` -### Set Issuers Configuration +### Set issuers configuration This endpoint allows setting the value of the default issuer. @@ -3525,7 +3525,7 @@ This endpoint allows setting the value of the default issuer. ~> Note: When an import creates more than one new issuer with key material known to this mount, no default update will occur. -#### Sample Payload +#### Sample payload ```json { @@ -3533,7 +3533,7 @@ This endpoint allows setting the value of the default issuer. } ``` -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -3543,7 +3543,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/config/issuers ``` -#### Sample Response +#### Sample response ```json { @@ -3553,7 +3553,7 @@ $ curl \ } ``` -### Read Keys Configuration +### Read keys configuration This endpoint allows getting the value of the default key. @@ -3561,7 +3561,7 @@ This endpoint allows getting the value of the default key. | :----- | :----------------- | | `GET` | `/pki/config/keys` | -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -3569,7 +3569,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/config/keys ``` -#### Sample Response +#### Sample response ```json { @@ -3579,7 +3579,7 @@ $ curl \ } ``` -### Set Keys Configuration +### Set keys configuration This endpoint allows setting the value of the default key. @@ -3592,7 +3592,7 @@ This endpoint allows setting the value of the default key. - `default` `(string: "")` - Specifies the default key (by reference; either a name or an ID). -#### Sample Payload +#### Sample payload ```json { @@ -3600,7 +3600,7 @@ This endpoint allows setting the value of the default key. } ``` -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -3610,7 +3610,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/config/keys ``` -#### Sample Response +#### Sample response ```json { @@ -3620,7 +3620,7 @@ $ curl \ } ``` -### Read Cluster Configuration +### Read cluster configuration This endpoint fetches the cluster-local configuration. @@ -3638,7 +3638,7 @@ channel. | :----- | :-------------------- | | `GET` | `/pki/config/cluster` | -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -3646,7 +3646,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/config/cluster ``` -#### Sample Response +#### Sample response ```json { @@ -3661,7 +3661,7 @@ $ curl \ } ``` -### Set Cluster Configuration +### Set cluster configuration This endpoint sets cluster-local configuration. @@ -3691,7 +3691,7 @@ channel. parameter and will not be used for other purposes. As such, unlike `path` above, this could safely be an insecure transit mechanism (like HTTP without TLS). -#### Sample Payload +#### Sample payload ```json { @@ -3700,7 +3700,7 @@ channel. } ``` -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -3710,7 +3710,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/config/cluster ``` -### Read CRL Configuration +### Read CRL configuration This endpoint allows getting the duration for which the generated CRL should be marked valid. No CRL configuration will be returned until the configuration is @@ -3720,7 +3720,7 @@ set, but the CRL will still default to enabled with 72h expiration. | :----- | :---------------- | | `GET` | `/pki/config/crl` | -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -3728,7 +3728,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/config/crl ``` -#### Sample Response +#### Sample response ```json { @@ -3754,7 +3754,7 @@ $ curl \ -### Set Revocation Configuration +### Set revocation configuration This endpoint allows setting the duration for which the generated CRL should be marked valid. If the CRL is disabled, it will return a signed but zero-length @@ -3857,7 +3857,7 @@ the CRL. ~> Note: `unified_crl_on_existing_paths` is a Vault Enterprise only feature. -#### Sample Payload +#### Sample payload ```json { @@ -3875,7 +3875,7 @@ the CRL. } ``` -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -3913,7 +3913,7 @@ and **must** be called on every cluster. | :----- | :---------------- | | `GET` | `/pki/crl/rotate` | -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -3921,7 +3921,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/crl/rotate ``` -#### Sample Response +#### Sample response ```json { @@ -3931,7 +3931,7 @@ $ curl \ } ``` -### Rotate Delta CRLs +### Rotate delta CRLs This endpoint forces a rotation of all issuers' delta CRLs, when enabled. This can be used by administrators to force a rebuild of a delta CRL if @@ -3944,7 +3944,7 @@ See notes about rotating regular CRLs above as they apply here as well. | :----- | :---------------------- | | `GET` | `/pki/crl/rotate-delta` | -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -3952,7 +3952,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/crl/rotate ``` -#### Sample Response +#### Sample response ```json { @@ -3962,7 +3962,7 @@ $ curl \ } ``` -### Combine CRLs from the Same Issuer +### Combine CRLs from the same issuer This endpoint allows combining multiple different CRLs that have been signed by the same issuer into a single signed CRL. This is useful to generate a single authoritative @@ -3993,7 +3993,7 @@ clusters. - `next_update` `(string: 72h)` - The amount of time the generated CRL should be valid; defaults to 72 hours. -#### Sample Payload +#### Sample payload ```json { @@ -4004,7 +4004,7 @@ clusters. } ``` -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -4014,7 +4014,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/issuer/default/resign-crls ``` -#### Sample Response +#### Sample response ```json { @@ -4024,7 +4024,7 @@ $ curl \ } ``` -### Sign Revocation List +### Sign revocation list This endpoint allows generating a CRL based on the provided parameter data from any external source and signed by the specified issuer. Values are taken verbatim from the parameters provided. @@ -4072,7 +4072,7 @@ source and signed by the specified issuer. Values are taken verbatim from the pa - `2.5.29.27`: Delta CRL - `2.5.29.35`: Authority Key Identifier -#### Sample Payload +#### Sample payload ```json { @@ -4092,7 +4092,7 @@ source and signed by the specified issuer. Values are taken verbatim from the pa } ``` -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -4102,7 +4102,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/issuer/default/sign-revocation-list ``` -#### Sample Response +#### Sample response ```json { @@ -4232,7 +4232,7 @@ expiration time. and the amount of time after being marked revoked or deactivated. The default is 30 days as hours. -#### Sample Payload +#### Sample payload ```json { @@ -4240,7 +4240,7 @@ expiration time. } ``` -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -4250,7 +4250,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/tidy ``` -### Read Automatic Tidy Configuration +### Read automatic tidy configuration This endpoint fetches the current automatic tidy configuration. @@ -4262,7 +4262,7 @@ the tidy parameters [described above in the tidy endpoint](#tidy). | :----- | :---------------------- | | `GET` | `/pki/config/auto-tidy` | -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -4270,7 +4270,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/config/auto-tidy ``` -#### Sample Response +#### Sample response ```json { @@ -4300,7 +4300,7 @@ $ curl \ -### Set Automatic Tidy Configuration +### Set automatic tidy configuration This endpoint allows configuring periodic tidy operations, using the tidy mechanism described above. Status is from automatically run tidies are still reported at the @@ -4337,7 +4337,7 @@ The below parameters are in addition to the regular parameters accepted by the publishes the value computed by `maintain_stored_certificate_counts` to the mount's metrics. This requires the former to be enabled. -#### Sample Payload +#### Sample payload ```json { @@ -4347,7 +4347,7 @@ The below parameters are in addition to the regular parameters accepted by the } ``` -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -4357,7 +4357,7 @@ $ curl \ http://127.0.0.1:8200/v1/pki/config/auto-tidy ``` -### Tidy Status +### Tidy status This is a read only endpoint that returns information about the current tidy operation, or the most recent if none are currently running. @@ -4392,7 +4392,7 @@ The result includes the following fields: | :----- | :----------------- | | `GET` | `/pki/tidy-status` | -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -4402,7 +4402,7 @@ $ curl \ ``` -#### Sample Response +#### Sample response ```json "data": { @@ -4419,7 +4419,7 @@ $ curl \ }, ``` -### Cancel Tidy +### Cancel tidy This endpoint allows cancelling a running tidy operation. It takes no parameter and cancels the tidy at the next available checkpoint, which @@ -4432,7 +4432,7 @@ The response to this endpoint is the same as the [status](#tidy-status). | :----- | :----------------- | | `POST` | `/pki/tidy-cancel` | -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -4442,7 +4442,7 @@ $ curl \ ``` -#### Sample Response +#### Sample response ```json "data": { @@ -4461,11 +4461,11 @@ $ curl \ --- -## Cluster Scalability +## Cluster scalability See [PKI Cluster Scalability](/vault/docs/secrets/pki/considerations#cluster-scalability) in the considerations page. -## Managed Keys +## Managed keys ~> Note: Managed keys are an Enterprise only feature. diff --git a/website/content/api-docs/secret/rabbitmq.mdx b/website/content/api-docs/secret/rabbitmq.mdx index df14f54e103a..2c8cac7d11a1 100644 --- a/website/content/api-docs/secret/rabbitmq.mdx +++ b/website/content/api-docs/secret/rabbitmq.mdx @@ -4,7 +4,7 @@ page_title: RabbitMQ - Secrets Engines - HTTP API description: This is the API documentation for the Vault RabbitMQ secrets engine. --- -# RabbitMQ Secrets Engine (API) +# RabbitMQ secrets engine (API) This is the API documentation for the Vault RabbitMQ secrets engine. For general information about the usage and operation of the RabbitMQ secrets engine, please @@ -14,7 +14,7 @@ This documentation assumes the RabbitMQ secrets engine is enabled at the `/rabbitmq` path in Vault. Since it is possible to enable secrets engines at any location, please update your API calls accordingly. -## Configure Connection +## Configure connection This endpoint configures the connection string used to communicate with RabbitMQ. @@ -39,7 +39,7 @@ RabbitMQ. - `username_template` `(string)` - [Template](/vault/docs/concepts/username-templating) describing how dynamic usernames are generated. -### Sample Payload +### Sample payload ```json { @@ -50,7 +50,7 @@ RabbitMQ. } ``` -### Sample Request +### Sample request @@ -77,7 +77,7 @@ $ vault write rabbitmq/config/connection \ -## Configure Lease +## Configure lease This endpoint configures the lease settings for generated credentials. @@ -91,7 +91,7 @@ This endpoint configures the lease settings for generated credentials. - `max_ttl` `(int: 0)` – Specifies the maximum ttl provided in seconds. -### Sample Payload +### Sample payload ```json { @@ -100,7 +100,7 @@ This endpoint configures the lease settings for generated credentials. } ``` -### Sample Request +### Sample request @@ -125,7 +125,7 @@ $ vault write rabbitmq/config/lease \ -## Create Role +## Create role This endpoint creates or updates the role definition. @@ -146,7 +146,7 @@ This endpoint creates or updates the role definition. - `vhost_topics` `(string: "")` – Specifies a map of virtual hosts and exchanges to topic permissions. This option requires RabbitMQ 3.7.0 or later. -### Sample Payload +### Sample payload ```json { @@ -156,7 +156,7 @@ This endpoint creates or updates the role definition. } ``` -### Sample Request +### Sample request @@ -182,7 +182,7 @@ $ vault write rabbitmq/roles/my-role \ -## Read Role +## Read role This endpoint queries the role definition. @@ -195,7 +195,7 @@ This endpoint queries the role definition. - `name` `(string: )` – Specifies the name of the role to read. This is specified as part of the URL. -### Sample Request +### Sample request @@ -216,7 +216,7 @@ $ vault read rabbitmq/roles/my-role -### Sample Response +### Sample response ```json { @@ -228,7 +228,7 @@ $ vault read rabbitmq/roles/my-role } ``` -## Delete Role +## Delete role This endpoint deletes the role definition. @@ -241,7 +241,7 @@ This endpoint deletes the role definition. - `name` `(string: )` – Specifies the name of the role to delete. This is specified as part of the URL. -### Sample Request +### Sample request @@ -263,7 +263,7 @@ vault delete rabbitmq/roles/my-role -## Generate Credentials +## Generate credentials This endpoint generates a new set of dynamic credentials based on the named role. @@ -277,7 +277,7 @@ role. - `name` `(string: )` – Specifies the name of the role to create credentials against. This is specified as part of the URL. -### Sample Request +### Sample request @@ -298,7 +298,7 @@ $ vault read rabbitmq/creds/my-role -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/secret/ssh.mdx b/website/content/api-docs/secret/ssh.mdx index 21fcb60b05a2..dc29706364e0 100644 --- a/website/content/api-docs/secret/ssh.mdx +++ b/website/content/api-docs/secret/ssh.mdx @@ -4,7 +4,7 @@ page_title: SSH - Secrets Engines - HTTP API description: This is the API documentation for the Vault SSH secrets engine. --- -# SSH Secrets Engine (API) +# SSH secrets engine (API) This is the API documentation for the Vault SSH secrets engine. For general information about the usage and operation of the SSH secrets engine, please see @@ -14,7 +14,7 @@ This documentation assumes the SSH secrets engine is enabled at the `/ssh` path in Vault. Since it is possible to enable secrets engines at any location, please update your API calls accordingly. -## Create/Update Role +## Create/Update role This endpoint creates or updates a named role. @@ -187,7 +187,7 @@ This endpoint creates or updates a named role. - `not_before_duration` `(duration: "30s")` – Specifies the duration by which to backdate the `ValidAfter` property. Uses [duration format strings](/vault/docs/concepts/duration-format). -### Sample Payload +### Sample payload ```json { @@ -195,7 +195,7 @@ This endpoint creates or updates a named role. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -205,7 +205,7 @@ $ curl \ http://127.0.0.1:8200/v1/ssh/roles/my-role ``` -## Read Role +## Read role This endpoint queries a named role. @@ -218,7 +218,7 @@ This endpoint queries a named role. - `name` `(string: )` – Specifies the name of the role to read. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -226,7 +226,7 @@ $ curl \ http://127.0.0.1:8200/v1/ssh/roles/my-role ``` -### Sample Response +### Sample response For an OTP role: @@ -257,7 +257,7 @@ For a CA role: } ``` -## List Roles +## List roles This endpoint returns a list of available roles. Only the role names are returned, not any values. @@ -266,7 +266,7 @@ returned, not any values. | :----- | :----------- | | `LIST` | `/ssh/roles` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -275,7 +275,7 @@ $ curl \ http://127.0.0.1:8200/v1/ssh/roles ``` -### Sample Response +### Sample response ```json { @@ -294,7 +294,7 @@ $ curl \ } ``` -## Delete Role +## Delete role This endpoint deletes a named role. @@ -307,7 +307,7 @@ This endpoint deletes a named role. - `name` `(string: )` – Specifies the name of the role to delete. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -317,7 +317,7 @@ $ curl \ http://127.0.0.1:8200/v1/ssh/roles/my-role ``` -## List Zero-Address Roles +## List Zero-Address roles This endpoint returns the list of configured zero-address roles. @@ -325,7 +325,7 @@ This endpoint returns the list of configured zero-address roles. | :----- | :------------------------ | | `GET` | `/ssh/config/zeroaddress` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -333,7 +333,7 @@ $ curl \ http://127.0.0.1:8200/v1/ssh/config/zeroaddress ``` -### Sample Response +### Sample response ```json { @@ -348,7 +348,7 @@ $ curl \ } ``` -## Configure Zero-Address Roles +## Configure Zero-Address roles This endpoint configures zero-address roles. @@ -362,7 +362,7 @@ This endpoint configures zero-address roles. list of role names which allows credentials to be requested for any IP address. CIDR blocks previously registered under these roles will be ignored. -### Sample Payload +### Sample payload ```json { @@ -370,7 +370,7 @@ This endpoint configures zero-address roles. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -380,7 +380,7 @@ $ curl \ http://127.0.0.1:8200/v1/ssh/config/zeroaddress ``` -## Delete Zero-Address Role +## Delete Zero-Address role This endpoint deletes the zero-address roles configuration. @@ -388,7 +388,7 @@ This endpoint deletes the zero-address roles configuration. | :------- | :------------------------ | | `DELETE` | `/ssh/config/zeroaddress` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -397,7 +397,7 @@ $ curl \ http://127.0.0.1:8200/v1/ssh/config/zeroaddress ``` -## Generate SSH Credentials +## Generate SSH credentials This endpoint creates credentials for a specific username and IP with the parameters defined in the given role. @@ -415,7 +415,7 @@ parameters defined in the given role. - `ip` `(string: )` – Specifies the IP of the remote host. -### Sample Payload +### Sample payload ```json { @@ -423,7 +423,7 @@ parameters defined in the given role. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -433,7 +433,7 @@ $ curl \ http://127.0.0.1:8200/v1/ssh/creds/my-role ``` -### Sample Response +### Sample response For an OTP role: @@ -454,7 +454,7 @@ For an OTP role: } ``` -## List Roles by IP +## List roles by IP This endpoint lists all of the roles with which the given IP is associated. @@ -466,7 +466,7 @@ This endpoint lists all of the roles with which the given IP is associated. - `ip` `(string: )` – Specifies the IP of the remote host. -### Sample Payload +### Sample payload ```json { @@ -474,7 +474,7 @@ This endpoint lists all of the roles with which the given IP is associated. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -484,7 +484,7 @@ $ curl \ http://127.0.0.1:8200/v1/ssh/lookup ``` -### Sample Response +### Sample response An array of roles as a secret structure. @@ -518,7 +518,7 @@ endpoint. - `otp` `(string: )` – Specifies the One-Time-Key that needs to be validated. -### Sample Payload +### Sample payload ```json { @@ -526,7 +526,7 @@ endpoint. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -536,7 +536,7 @@ $ curl \ http://127.0.0.1:8200/v1/ssh/verify ``` -### Sample Response +### Sample response ```json { @@ -552,7 +552,7 @@ $ curl \ } ``` -## Submit CA Information +## Submit CA information This endpoint allows submitting the CA information for the secrets engine via an SSH key pair. _If you have already set a certificate and key, they will be @@ -594,7 +594,7 @@ overridden._ to use; `256`, `384`, or `521`, with the default `0` value resulting in a NIST P-256 key). -### Sample Payload +### Sample payload ```json { @@ -602,7 +602,7 @@ overridden._ } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -612,7 +612,7 @@ $ curl \ http://127.0.0.1:8200/v1/ssh/config/ca ``` -### Sample Response +### Sample response This will return a `204` response if `generate_signing_key` was unset or false. @@ -630,7 +630,7 @@ This will return a `200` response if `generate_signing_key` was true: } ``` -## Delete CA Information +## Delete CA information This endpoint deletes the CA information for the backend via an SSH key pair. @@ -638,7 +638,7 @@ This endpoint deletes the CA information for the backend via an SSH key pair. | :------- | :--------------- | | `DELETE` | `/ssh/config/ca` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -647,7 +647,7 @@ $ curl \ http://127.0.0.1:8200/v1/ssh/config/ca ``` -## Read Public Key (Unauthenticated) +## Read public key (Unauthenticated) This endpoint returns the configured/generated public key. This is an unauthenticated endpoint. @@ -660,19 +660,19 @@ endpoint. | :----- | :---------------- | ---------------- | | `GET` | `/ssh/public_key` | `200 text/plain` | -### Sample Request +### Sample request ```shell-session $ curl http://127.0.0.1:8200/v1/ssh/public_key ``` -### Sample Response +### Sample response ```text ssh-rsa AAAAHHNzaC1y... ``` -## Read Public Key (Authenticated) +## Read public key (Authenticated) This endpoint reads the configured/generated public key. @@ -680,7 +680,7 @@ This endpoint reads the configured/generated public key. | :----- | :--------------- | | `GET` | `/ssh/config/ca` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -688,7 +688,7 @@ $ curl \ http://127.0.0.1:8200/v1/ssh/config/ca ``` -### Sample Response +### Sample response ```json { @@ -702,7 +702,7 @@ $ curl \ } ``` -## Sign SSH Key +## Sign SSH key This endpoint signs an SSH public key based on the supplied parameters and subject to the restrictions of the role named in the path. Both `create` and @@ -755,7 +755,7 @@ parameters of the issued certificate can be further customized in this API call. - `extensions` `(map: "")` – Specifies a map of the extensions that the certificate should be signed for. Defaults to none. -### Sample Payload +### Sample payload ```json { @@ -763,7 +763,7 @@ parameters of the issued certificate can be further customized in this API call. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -773,7 +773,7 @@ $ curl \ http://127.0.0.1:8200/v1/ssh/sign/my-key ``` -### Sample Response +### Sample response ```json { @@ -788,7 +788,7 @@ $ curl \ } ``` -## Generate Certificate and Key +## Generate certificate and key This endpoint issues a new set of SSH credentials (private key and certificate). @@ -841,7 +841,7 @@ parameters of the issued certificate can be further customized in this API call. - `extensions` `(map: "")` – Specifies a map of the extensions that the certificate should be signed for. Defaults to none. -### Sample Payload +### Sample payload ```json { @@ -850,7 +850,7 @@ parameters of the issued certificate can be further customized in this API call. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -860,7 +860,7 @@ $ curl \ http://127.0.0.1:8200/v1/ssh/issue/my-role ``` -### Sample Response +### Sample response ```json { @@ -880,7 +880,7 @@ $ curl \ } ``` -## Tidy Host Keys +## Tidy host keys This endpoint removes all existing host keys from Vault, if any are present. These keys were used with the Dynamic Keys functionality, which were removed @@ -899,7 +899,7 @@ from this engine. | :------- | :----------------------- | | `DELETE` | `/ssh/tidy/dynamic-keys` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -908,7 +908,7 @@ $ curl \ http://127.0.0.1:8200/v1/ssh/issue/my-role ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/secret/terraform.mdx b/website/content/api-docs/secret/terraform.mdx index 2ab1d7c480d7..62dd5e29c954 100644 --- a/website/content/api-docs/secret/terraform.mdx +++ b/website/content/api-docs/secret/terraform.mdx @@ -4,7 +4,7 @@ page_title: Terraform Cloud Secret Backend - HTTP API description: This is the API documentation for the Vault Terraform Cloud secret backend. --- -# Terraform Cloud Secret Backend HTTP API +# Terraform Cloud secret backend HTTP API This is the API documentation for the Vault Terraform Cloud secret backend. For general information about the usage and operation of the Terraform Cloud backend, please see the @@ -14,7 +14,7 @@ This documentation assumes the Terraform Cloud backend is mounted at the `/terra in Vault. Since it is possible to mount secret backends at any location, please update your API calls accordingly. -## Configure Access +## Configure access This endpoint configures the access information for Terraform Cloud. This access information is used so that Vault can communicate with Terraform Cloud and generate @@ -34,7 +34,7 @@ Terraform Cloud tokens. use. This token must have the needed permissions to manage all Organization, Team, and User tokens desired for this mount. -### Sample Payload +### Sample payload ```json { @@ -43,7 +43,7 @@ Terraform Cloud tokens. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -53,7 +53,7 @@ $ curl \ http://127.0.0.1:8200/v1/terraform/config ``` -## Read Access Configuration +## Read access configuration This endpoint queries for information about the Terraform Cloud connection. @@ -61,7 +61,7 @@ This endpoint queries for information about the Terraform Cloud connection. | :----- | :------------------ | | `GET` | `/terraform/config` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -69,7 +69,7 @@ $ curl \ http://127.0.0.1:8200/v1/terraform/config ``` -### Sample Response +### Sample response ```json "data": { @@ -78,7 +78,7 @@ $ curl \ } ``` -## Create/Update Role +## Create/Update role This endpoint creates or updates the Terraform Cloud role definition in Vault. If the role does not exist, it will be created. If the role already exists, it @@ -132,7 +132,7 @@ information](/terraform/cloud-docs/users-teams-organizations/api-tokens). provided, the default Vault Max TTL is used. Only applies to User API tokens. Uses [duration format strings](/vault/docs/concepts/duration-format). -### Sample Payload +### Sample payload To create a Vault role to manage a Terraform Cloud User tokens @@ -144,7 +144,7 @@ To create a Vault role to manage a Terraform Cloud User tokens } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -154,7 +154,7 @@ $ curl \ http://127.0.0.1:8200/v1/terraform/role/tfuser ``` -## Read Role +## Read role This endpoint queries for information about a Terraform Cloud role with the given name. If no role exists with that name, a 404 is returned. @@ -168,7 +168,7 @@ If no role exists with that name, a 404 is returned. - `name` `(string: )` – Specifies the name of the role to query. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -176,7 +176,7 @@ $ curl \ http://127.0.0.1:8200/v1/terraform/role/tfuser ``` -### Sample Response +### Sample response ```json { @@ -189,7 +189,7 @@ $ curl \ } ``` -## List Roles +## List roles This endpoint lists all existing roles in the backend. @@ -198,7 +198,7 @@ This endpoint lists all existing roles in the backend. | `LIST` | `/terraform/role` | | `GET` | `/terraform/role?list=true` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -207,7 +207,7 @@ $ curl \ http://127.0.0.1:8200/v1/terraform/role ``` -### Sample Response +### Sample response ```json { @@ -217,7 +217,7 @@ $ curl \ } ``` -## Delete Role +## Delete role This endpoint deletes a Terraform Cloud role with the given name. Even if the role does not exist, this endpoint will still return a successful response. @@ -231,7 +231,7 @@ not exist, this endpoint will still return a successful response. - `name` `(string: )` – Specifies the name of the role to delete. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -240,7 +240,7 @@ $ curl \ http://127.0.0.1:8200/v1/terraform/role/tfuser ``` -## Rotate Role +## Rotate role This endpoint rotates the credentials for a Terraform Cloud role that manages an Organization or Team. This endpoint is only valid for those roles; attempting to @@ -255,7 +255,7 @@ rotate a role that manages user tokens will result in an error. - `name` `(string: )` – Specifies the name of the role to rotate. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -264,7 +264,7 @@ $ curl \ http://127.0.0.1:8200/v1/terraform/rotate-role/testing ``` -## Generate Credential +## Generate credential This endpoint returns a Terraform Cloud token based on the given role definition. For Organization and Team roles, the same API token is returned @@ -280,7 +280,7 @@ generated with each request. - `name` `(string: )` – Specifies the name of an existing role against which to create this Terraform Cloud token. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -288,7 +288,7 @@ $ curl \ http://127.0.0.1:8200/v1/terraform/creds/example ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/secret/totp.mdx b/website/content/api-docs/secret/totp.mdx index 6e3d78fc5630..c9944974be81 100644 --- a/website/content/api-docs/secret/totp.mdx +++ b/website/content/api-docs/secret/totp.mdx @@ -4,7 +4,7 @@ page_title: TOTP - Secrets Engines - HTTP API description: This is the API documentation for the Vault TOTP secrets engine. --- -# TOTP Secrets Engine (API) +# TOTP secrets engine (API) This is the API documentation for the Vault TOTP secrets engine. For general information about the usage and operation of the TOTP secrets engine, please see @@ -14,7 +14,7 @@ This documentation assumes the TOTP secrets engine is enabled at the `/totp` path in Vault. Since it is possible to enable secrets engines at any location, please update your API calls accordingly. -## Create Key +## Create key This endpoint creates or updates a key definition. @@ -50,7 +50,7 @@ This endpoint creates or updates a key definition. - `qr_size` `(int: 200)` – Specifies the pixel size of the square QR code when generating a new key. Only used if generate is true and exported is true. If this value is 0, a QR code will not be returned. -### Sample Payload +### Sample payload ```json { @@ -58,7 +58,7 @@ This endpoint creates or updates a key definition. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -68,7 +68,7 @@ $ curl \ http://127.0.0.1:8200/v1/totp/keys/my-key ``` -### Sample Payload +### Sample payload ```json { @@ -78,7 +78,7 @@ $ curl \ } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -88,7 +88,7 @@ $ curl \ http://127.0.0.1:8200/v1/totp/keys/my-key ``` -### Sample Response +### Sample response ```json { @@ -105,7 +105,7 @@ If a QR code is returned, it consists of base64-formatted PNG bytes. You can emb ``` -## Read Key +## Read key This endpoint queries the key definition. @@ -117,7 +117,7 @@ This endpoint queries the key definition. - `name` `(string: )` – Specifies the name of the key to read. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -125,7 +125,7 @@ $ curl \ http://127.0.0.1:8200/v1/totp/keys/my-key ``` -### Sample Response +### Sample response ```json { @@ -139,7 +139,7 @@ $ curl \ } ``` -## List Keys +## List keys This endpoint returns a list of available keys. Only the key names are returned, not any values. @@ -148,7 +148,7 @@ returned, not any values. | :----- | :----------- | | `LIST` | `/totp/keys` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -157,7 +157,7 @@ $ curl \ http://127.0.0.1:8200/v1/totp/keys ``` -### Sample Response +### Sample response ```json { @@ -171,7 +171,7 @@ $ curl \ } ``` -## Delete Key +## Delete key This endpoint deletes the key definition. @@ -184,7 +184,7 @@ This endpoint deletes the key definition. - `name` `(string: )` – Specifies the name of the key to delete. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -193,7 +193,7 @@ $ curl \ http://127.0.0.1:8200/v1/totp/keys/my-key ``` -## Generate Code +## Generate code This endpoint generates a new time-based one-time use password based on the named key. @@ -207,7 +207,7 @@ key. - `name` `(string: )` – Specifies the name of the key to create credentials against. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -215,7 +215,7 @@ $ curl \ http://127.0.0.1:8200/v1/totp/code/my-key ``` -### Sample Response +### Sample response ```json { @@ -225,7 +225,7 @@ $ curl \ } ``` -## Validate Code +## Validate code This endpoint validates a time-based one-time use password generated from the named key. @@ -240,7 +240,7 @@ key. - `code` `(string: )` – Specifies the password you want to validate. -### Sample Payload +### Sample payload ```json { @@ -248,7 +248,7 @@ key. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -258,7 +258,7 @@ $ curl \ http://127.0.0.1:8200/v1/totp/code/my-key ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/secret/transform.mdx b/website/content/api-docs/secret/transform.mdx index bfb161d11e88..b87bb59d4f78 100644 --- a/website/content/api-docs/secret/transform.mdx +++ b/website/content/api-docs/secret/transform.mdx @@ -4,7 +4,7 @@ page_title: Transform - Secrets Engines - HTTP API description: This is the API documentation for the Transform secrets engine. --- -# Transform Secrets Engine (API) +# Transform secrets engine (API) This is the API documentation for the Transform secrets engine. For general information about the usage and operation of the secrets engine, please see the @@ -14,7 +14,7 @@ This documentation assumes the transform secrets engine is enabled at the `/transform` path in Vault. Since it is possible to enable secrets engines at any location, please update your API calls accordingly. -## Create/Update Role +## Create/Update role This endpoint creates or updates the role with the given `name`. If a role with the name does not exist, it will be created. If the role exists, it will be @@ -32,7 +32,7 @@ updated with the new attributes. - `transformations` (`list: []`) - Specifies the transformations that can be used with this role. -### Sample Payload +### Sample payload ```json { @@ -40,7 +40,7 @@ updated with the new attributes. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -50,7 +50,7 @@ $ curl \ https://127.0.0.1:8200/v1/transform/role/example-role ``` -## Read Role +## Read role This endpoint queries an existing role by the given name. @@ -63,7 +63,7 @@ This endpoint queries an existing role by the given name. - `name` `(string: )` – Specifies the name of the role to read. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -71,7 +71,7 @@ $ curl \ http://127.0.0.1:8200/v1/transform/role/example-role ``` -### Sample Response +### Sample response ```json { @@ -81,7 +81,7 @@ $ curl \ } ``` -## List Roles +## List roles This endpoint lists all existing roles in the secrets engine. @@ -94,7 +94,7 @@ This endpoint lists all existing roles in the secrets engine. - `filter` `(string: "*")` – If provided, only returns role names that match the given glob. -### Sample Request +### Sample request ```shell-session $ curl @@ -103,7 +103,7 @@ $ curl http://127.0.0.1:8200/v1/transform/role ``` -### Sample Response +### Sample response ```json { @@ -113,7 +113,7 @@ $ curl } ``` -## Delete Role +## Delete role This endpoint deletes an existing role by the given name. @@ -126,7 +126,7 @@ This endpoint deletes an existing role by the given name. - `name` `(string: )` – Specifies the name of the role to delete. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -135,7 +135,7 @@ $ curl \ http://127.0.0.1:8200/v1/transform/role/example-role ``` -## Create/Update Transformation DEPRECATED (1.6) +## Create/Update transformation DEPRECATED (1.6) This endpoint creates or updates a transformation with the given `name`. If a transformation with the name does not exist, it will be created. If the @@ -185,7 +185,7 @@ configuration endpoints, and will be removed in a future release. If true, this transform can be deleted. Otherwise deletion is blocked while this value remains false. -### Sample Payload +### Sample payload ```json { @@ -196,7 +196,7 @@ configuration endpoints, and will be removed in a future release. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -206,7 +206,7 @@ $ curl \ https://127.0.0.1:8200/v1/transform/transformation/example-transformation ``` -## Create/Update FPE Transformation +## Create/Update FPE transformation This endpoint creates or updates an FPE transformation with the given `name`. If a transformation with the name does not exist, it will be created. If the @@ -241,7 +241,7 @@ transformation exists, it will be updated with the new attributes. key making decoding of FPE encoded values impossible without restoring from a backup. -### Sample Payload +### Sample payload ```json { @@ -251,7 +251,7 @@ transformation exists, it will be updated with the new attributes. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -261,7 +261,7 @@ $ curl \ https://127.0.0.1:8200/v1/transform/transformations/fpe/example-transformation ``` -## Create/Update Masking Transformation +## Create/Update masking transformation This endpoint creates or updates a masking transformation with the given `name`. If a transformation with the name does not exist, it will be created. If the @@ -291,7 +291,7 @@ transformation exists, it will be updated with the new attributes. A role using this transformation must exist in this list in order for encode and decode operations to properly function. -### Sample Payload +### Sample payload ```json { @@ -301,7 +301,7 @@ transformation exists, it will be updated with the new attributes. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -311,7 +311,7 @@ $ curl \ https://127.0.0.1:8200/v1/transform/transformations/masking/example-transformation ``` -## Create/Update Tokenization Transformation +## Create/Update tokenization transformation This endpoint creates or updates a tokenization transformation with the given `name`. If a transformation with the name does not exist, it will be created. If the @@ -357,7 +357,7 @@ transformation exists, it will be updated with the new attributes. value remains false. Note that deleting the transform deletes the underlying key making decoding of tokenized values impossible without restoring from a backup. -### Sample Payload +### Sample payload ```json { @@ -366,7 +366,7 @@ transformation exists, it will be updated with the new attributes. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -376,7 +376,7 @@ $ curl \ https://127.0.0.1:8200/v1/transform/transformations/tokenization/example-transformation ``` -## Import Key for FPE Transformation +## Import key for FPE transformation This endpoint imports an existing AES-256 key into a new FPE transformation. Currently, importing a key into an existing FPE transformation is not supported. @@ -414,7 +414,7 @@ the hash function defaults to SHA256. A role using this transformation must exist in this list for the encode and decode operations to function properly. -### Sample Payload +### Sample payload ```json { @@ -425,7 +425,7 @@ the hash function defaults to SHA256. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -435,7 +435,7 @@ $ curl \ https://127.0.0.1:8200/v1/transform/transformations/fpe/example-transformation/import ``` -## Import Key for Tokenization Transformation +## Import key for tokenization transformation This endpoint imports an existing AES-256 key into a new tokenization transformation. To import key material into an existing key, see the tokenization `import_version/` endpoint. @@ -487,7 +487,7 @@ support importing key material with the `import_version` endpoint. The list of tokenization stores to use for tokenization state. Vault's internal storage is used by default. -### Sample Payload +### Sample payload ```json { @@ -497,7 +497,7 @@ support importing key material with the `import_version` endpoint. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -507,7 +507,7 @@ $ curl \ https://127.0.0.1:8200/v1/transform/transformations/tokenization/example-transformation/import ``` -## Import Key Version for Tokenization Transformation +## Import key version for tokenization transformation This endpoint imports new key material into an existing tokenization transformation with an imported key. @@ -535,7 +535,7 @@ RSA-OAEP step of creating the ciphertext. Supported hash functions are: `SHA1`, `SHA224`, `SHA256`, `SHA384`, and `SHA512`. If not specified, the hash function defaults to SHA256. -### Sample Payload +### Sample payload ```json { @@ -543,7 +543,7 @@ the hash function defaults to SHA256. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -553,7 +553,7 @@ $ curl \ https://127.0.0.1:8200/v1/transform/transformations/tokenization/example-transformation/import_version ``` -## Get Wrapping Key +## Get wrapping key This endpoint is used to retrieve the wrapping key to use to import keys. The returned key will be a 4096-bit RSA public key. @@ -562,7 +562,7 @@ The returned key will be a 4096-bit RSA public key. | :---- | :------------------------ | | `GET` | `/transform/wrapping_key` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -571,7 +571,7 @@ $ curl \ http://127.0.0.1:8200/v1/transform/wrapping_key ``` -### Sample Response +### Sample response ```json { @@ -581,7 +581,7 @@ $ curl \ } ``` -## Read Transformation +## Read transformation This endpoint queries an existing transformation by the given name. @@ -592,7 +592,7 @@ This endpoint queries an existing transformation by the given name. - `name` `(string: )` – Specifies the name of the role to read. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -600,7 +600,7 @@ $ curl \ http://127.0.0.1:8200/v1/transform/transformation/example-transformation ``` -### Sample Response +### Sample response ```json { @@ -613,7 +613,7 @@ $ curl \ } ``` -## List Transformation +## List transformation This endpoint lists all existing transformations in the secrets engine. @@ -621,7 +621,7 @@ This endpoint lists all existing transformations in the secrets engine. | :----- | :-------------------------- | | `LIST` | `/transform/transformation` | -### Sample Request +### Sample request ```shell-session $ curl @@ -630,7 +630,7 @@ $ curl http://127.0.0.1:8200/v1/transform/transformation ``` -### Sample Response +### Sample response ```json { @@ -640,7 +640,7 @@ $ curl } ``` -## Delete Transformation +## Delete transformation This endpoint deletes an existing transformation by the given name. @@ -654,7 +654,7 @@ This endpoint deletes an existing transformation by the given name. Specifies the name of the transformation to delete. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -663,7 +663,7 @@ $ curl \ http://127.0.0.1:8200/v1/transform/transformation/example-transformation ``` -## Create/Update Template +## Create/Update template This endpoint creates or updates a template with the given `name`. If a template with the name does not exist, it will be created. If the @@ -704,7 +704,7 @@ template exists, it will be updated with the new attributes. decoded output. For example, this can be used to decode only the last four digits of a credit card number. This is only used during FPE transformations. -### Sample Payload +### Sample payload ```json { @@ -719,7 +719,7 @@ template exists, it will be updated with the new attributes. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -729,7 +729,7 @@ $ curl \ https://127.0.0.1:8200/v1/transform/template/example-template ``` -## Read Template +## Read template This endpoint queries an existing template by the given name. @@ -740,7 +740,7 @@ This endpoint queries an existing template by the given name. - `name` `(string: )` – Specifies the name of the role to read. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -748,7 +748,7 @@ $ curl \ http://127.0.0.1:8200/v1/transform/template/example-template ``` -### Sample Response +### Sample response ```json { @@ -765,7 +765,7 @@ $ curl \ } ``` -## List Template +## List template This endpoint lists all existing templates in the secrets engine. @@ -773,7 +773,7 @@ This endpoint lists all existing templates in the secrets engine. | :----- | :-------------------- | | `LIST` | `/transform/template` | -### Sample Request +### Sample request ```shell-session $ curl @@ -782,7 +782,7 @@ $ curl http://127.0.0.1:8200/v1/transform/template ``` -### Sample Response +### Sample response ```json { @@ -792,7 +792,7 @@ $ curl } ``` -## Delete Template +## Delete template This endpoint deletes an existing template by the given name. @@ -806,7 +806,7 @@ This endpoint deletes an existing template by the given name. Specifies the name of the template to delete. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -815,7 +815,7 @@ $ curl \ http://127.0.0.1:8200/v1/transform/template/example-template ``` -## Create/Update Alphabet +## Create/Update alphabet This endpoint creates or updates an alphabet with the given `name`. If an alphabet with the name does not exist, it will be created. If the @@ -835,7 +835,7 @@ alphabet exists, it will be updated with the new attributes. Specifies the set of characters that can exist within the provided value and the encoded or decoded value for a FPE transformation. -### Sample Payload +### Sample payload ```json { @@ -843,7 +843,7 @@ alphabet exists, it will be updated with the new attributes. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -853,7 +853,7 @@ $ curl \ https://127.0.0.1:8200/v1/transform/alphabet/example-alphabet ``` -## Read Alphabet +## Read alphabet This endpoint queries an existing alphabet by the given name. @@ -864,7 +864,7 @@ This endpoint queries an existing alphabet by the given name. - `name` `(string: )` – Specifies the name of the role to read. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -872,7 +872,7 @@ $ curl \ http://127.0.0.1:8200/v1/transform/alphabet/example-alphabet ``` -### Sample Response +### Sample response ```json { @@ -882,7 +882,7 @@ $ curl \ } ``` -## List Alphabets +## List alphabets This endpoint lists all existing alphabets in the secrets engine. @@ -890,7 +890,7 @@ This endpoint lists all existing alphabets in the secrets engine. | :----- | :-------------------- | | `LIST` | `/transform/alphabet` | -### Sample Request +### Sample request ```shell-session $ curl @@ -899,7 +899,7 @@ $ curl http://127.0.0.1:8200/v1/transform/alphabet ``` -### Sample Response +### Sample response ```json { @@ -909,7 +909,7 @@ $ curl } ``` -## Delete Alphabet +## Delete alphabet This endpoint deletes an existing alphabet by the given name. @@ -922,7 +922,7 @@ This endpoint deletes an existing alphabet by the given name. - `name` `(string: )` – Specifies the name of the alphabet to delete. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -931,7 +931,7 @@ $ curl \ http://127.0.0.1:8200/v1/transform/alphabet/example-alphabet ``` -## Create/Update Tokenization Store +## Create/Update tokenization store This endpoint creates or updates a storage configuration for use with tokenization. The database user configured here should only have permission to `SELECT`, @@ -983,7 +983,7 @@ The database user configured here should only have permission to `SELECT`, The maximum amount of time a connection can be open before closing it. 0 means no limit. Uses [duration format strings](/vault/docs/concepts/duration-format). -### Sample Payloads +### Sample payloads ```json { @@ -1005,7 +1005,7 @@ The database user configured here should only have permission to `SELECT`, } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1015,7 +1015,7 @@ $ curl \ https://127.0.0.1:8200/v1/transform/stores/example-store ``` -## Create/Update Store Schema +## Create/Update store schema This endpoint creates or updates the underlying schema in an SQL type tokenization store. The provided username and password are only used during @@ -1042,7 +1042,7 @@ operation. - `transformation_type`: `(string: "tokenization")` - The transformation type. Currently only `tokenization` is supported. -### Sample Payload +### Sample payload ```json { @@ -1051,7 +1051,7 @@ operation. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1061,7 +1061,7 @@ $ curl \ https://127.0.0.1:8200/v1/transform/stores/example-store/schema ``` -## Read Store +## Read store This endpoint queries an existing store by the given name. @@ -1072,7 +1072,7 @@ This endpoint queries an existing store by the given name. - `name` `(string: )` – Specifies the name of the role to read. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1080,7 +1080,7 @@ $ curl \ http://127.0.0.1:8200/v1/transform/stores/example-store ``` -### Sample Response +### Sample response ```json { @@ -1092,7 +1092,7 @@ $ curl \ } ``` -## List Stores +## List stores This endpoint lists all existing stores in the secrets engine. @@ -1100,7 +1100,7 @@ This endpoint lists all existing stores in the secrets engine. | :----- | :------------------ | | `LIST` | `/transform/stores` | -### Sample Request +### Sample request ```shell-session $ curl @@ -1109,7 +1109,7 @@ $ curl http://127.0.0.1:8200/v1/transform/store ``` -### Sample Response +### Sample response ```json { @@ -1119,7 +1119,7 @@ $ curl } ``` -## Delete Store +## Delete store This endpoint deletes an existing store configuration by the given name. @@ -1133,7 +1133,7 @@ This endpoint deletes an existing store configuration by the given name. Specifies the name of the store to delete. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1216,7 +1216,7 @@ if the `tweak_source` for the specified transformation is set to `generated`. The resource owner should properly store this tweak, which must be supplied back when decrypting the encoded value. -### Sample Payload +### Sample payload ```json { @@ -1225,7 +1225,7 @@ when decrypting the encoded value. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1235,7 +1235,7 @@ $ curl \ http://127.0.0.1:8200/v1/transform/encode/example-role ``` -### Sample Response +### Sample response ```json { @@ -1245,7 +1245,7 @@ $ curl \ } ``` -### Sample Payload +### Sample payload ```json { @@ -1263,7 +1263,7 @@ $ curl \ } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1273,7 +1273,7 @@ $ curl \ http://127.0.0.1:8200/v1/transform/encode/example-role ``` -### Sample Response +### Sample response ```json { @@ -1346,7 +1346,7 @@ This endpoint decodes the provided value using a named role. ] ``` -### Sample Payload +### Sample payload ```json { @@ -1355,7 +1355,7 @@ This endpoint decodes the provided value using a named role. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1365,7 +1365,7 @@ $ curl \ http://127.0.0.1:8200/v1/transform/decode/example-role ``` -### Sample Response +### Sample response ```json { @@ -1375,7 +1375,7 @@ $ curl \ } ``` -### Sample Payload +### Sample payload ```json { @@ -1384,7 +1384,7 @@ $ curl \ } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1394,7 +1394,7 @@ $ curl \ http://127.0.0.1:8200/v1/transform/decode/example-role/last-four ``` -### Sample Response +### Sample response ```json { @@ -1404,7 +1404,7 @@ $ curl \ } ``` -### Sample Payload +### Sample payload ```json { @@ -1422,7 +1422,7 @@ $ curl \ } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1432,7 +1432,7 @@ $ curl \ http://127.0.0.1:8200/v1/transform/decode/example-role ``` -### Sample Response +### Sample response ```json { @@ -1450,7 +1450,7 @@ $ curl \ } ``` -## Validate Token +## Validate token This endpoint determines if a provided tokenized value is valid and unexpired. Only valid for tokenization transformations. @@ -1495,7 +1495,7 @@ Only valid for tokenization transformations. ] ``` -### Sample Payload +### Sample payload ```json { @@ -1504,7 +1504,7 @@ Only valid for tokenization transformations. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1514,7 +1514,7 @@ $ curl \ http://127.0.0.1:8200/v1/transform/validate/example-role ``` -### Sample Response +### Sample response ```json { @@ -1524,7 +1524,7 @@ $ curl \ } ``` -## Check Tokenization +## Check tokenization This endpoint determines if a provided plaintext value has an valid, unexpired tokenized value. Note that this cannot return the token, just confirm that a @@ -1572,7 +1572,7 @@ This endpoint is only valid for tokenization transformations. ] ``` -### Sample Payload +### Sample payload ```json { @@ -1581,7 +1581,7 @@ This endpoint is only valid for tokenization transformations. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1591,7 +1591,7 @@ $ curl \ http://127.0.0.1:8200/v1/transform/tokenized/example-role ``` -### Sample Response +### Sample response ```json { @@ -1601,7 +1601,7 @@ $ curl \ } ``` -## Lookup Token +## Lookup token This endpoint returns the token given a plaintext and optionally an expiration or range of expirations. This operation is only supported @@ -1669,7 +1669,7 @@ transformations. ] ``` -### Sample Payload +### Sample payload ```json { @@ -1680,7 +1680,7 @@ transformations. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1690,7 +1690,7 @@ $ curl \ http://127.0.0.1:8200/v1/transform/tokens/example-role ``` -### Sample Response +### Sample response ```json { @@ -1702,7 +1702,7 @@ $ curl \ } ``` -## Retrieve Token Metadata +## Retrieve token metadata This endpoint retrieves metadata for a tokenized value using a named role. Only valid for tokenization transformations. @@ -1748,7 +1748,7 @@ Only valid for tokenization transformations. ] ``` -### Sample Payload +### Sample payload ```json { @@ -1757,7 +1757,7 @@ Only valid for tokenization transformations. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1767,7 +1767,7 @@ $ curl \ http://127.0.0.1:8200/v1/transform/encode/example-role ``` -### Sample Response +### Sample response ```json { @@ -1778,7 +1778,7 @@ $ curl \ } ``` -## Snapshot Tokenization State +## Snapshot tokenization state This endpoint starts or continues retrieving a snapshot of the stored state of a tokenization transform. This state is protected as it is @@ -1813,7 +1813,7 @@ snapshot began may or may not be included. If absent or empty, a new snapshot is started. If present, the snapshot should continue at the next available value. -### Sample Payload +### Sample payload ```json { @@ -1822,7 +1822,7 @@ snapshot began may or may not be included. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1832,7 +1832,7 @@ $ curl \ http://127.0.0.1:8200/v1//transform/transformations/tokenization/snapshot/sample-transform ``` -### Sample Response +### Sample response ```json { @@ -1847,7 +1847,7 @@ $ curl \ } ``` -## Restore Tokenization State +## Restore tokenization state This endpoint restores previously snapshotted tokenization state values to the underlying store(s) of a tokenization transform. Calls to this @@ -1869,7 +1869,7 @@ into an `exportable` mode store and vice versa. - `values` `([]string: )` - Any number of tokenization state values from a previous snapshot call. -### Sample Payload +### Sample payload ```json { @@ -1881,7 +1881,7 @@ into an `exportable` mode store and vice versa. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1891,7 +1891,7 @@ $ curl \ http://127.0.0.1:8200/v1//transform/transformations/tokenization/restore/sample-transform ``` -## Export Decoded Tokenization State +## Export decoded tokenization state This endpoint starts or continues retrieving an export of tokenization state, including the tokens and their decoded values. This call is only @@ -1927,7 +1927,7 @@ snapshot began may or may not be included. If absent or empty, a new export is started. If present, the export should continue at the next available value. -### Sample Payload +### Sample payload ```json { @@ -1936,7 +1936,7 @@ snapshot began may or may not be included. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1946,7 +1946,7 @@ $ curl \ http://127.0.0.1:8200/v1//transform/transformations/tokenization/export-decoded/sample-transform ``` -### Sample Response +### Sample response ```json { @@ -1971,7 +1971,7 @@ $ curl \ } ``` -## Rotate Tokenization Key +## Rotate tokenization key This endpoint rotates the version of the named key. After rotation, new requests will be encoded with the new version of the key. @@ -1986,7 +1986,7 @@ new requests will be encoded with the new version of the key. Specifies the transform name to use for this operation. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1995,7 +1995,7 @@ $ curl \ http://127.0.0.1:8200/v1/transform/tokenization/keys/transform_name/rotate ``` -## Update Tokenization Key Config +## Update tokenization key config This endpoint allows the minimum key version to be set for decode operations. @@ -2020,7 +2020,7 @@ Only valid for tokenization transformations. rotation. This value cannot be shorter than one hour. Uses [duration format strings](/vault/docs/concepts/duration-format). -### Sample Payload +### Sample payload ```json [ @@ -2031,7 +2031,7 @@ Only valid for tokenization transformations. ] ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -2041,7 +2041,7 @@ $ curl \ http://127.0.0.1:8200/v1/transform/tokenization/keys/transform_name/config ``` -## List Tokenization Key Configuration +## List tokenization key configuration List all tokenization keys. Only valid for tokenization transformations. @@ -2050,7 +2050,7 @@ Only valid for tokenization transformations. | :----- | :------------------------------ | | `LIST` | `/transform/tokenization/keys/` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -2059,7 +2059,7 @@ $ curl \ http://127.0.0.1:8200/v1/transform/tokenization/keys/ ``` -## Read Tokenization Key Configuration +## Read tokenization key configuration Read tokenization key configuration for a particular transform. Only valid for tokenization transformations. @@ -2074,7 +2074,7 @@ Only valid for tokenization transformations. Specifies the transform name to use for this operation. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -2082,7 +2082,7 @@ $ curl \ http://127.0.0.1:8200/v1/transform/tokenization/keys/:transform_name ``` -### Sample Response +### Sample response ```json { @@ -2096,7 +2096,7 @@ $ curl \ } ``` -## Trim Tokenization Key Version +## Trim tokenization key version This endpoint trims older key versions setting a minimum version for the keyring. Once trimmed, previous versions of the key cannot be recovered. @@ -2116,7 +2116,7 @@ Once trimmed, previous versions of the key cannot be recovered. this will be permanently forgotten. Cannot be set below `min_decryption_version` or above `latest_version`. -### Sample Payload +### Sample payload ```json { @@ -2124,7 +2124,7 @@ Once trimmed, previous versions of the key cannot be recovered. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/secret/transit.mdx b/website/content/api-docs/secret/transit.mdx index f18354ef29a1..2cf9b167e41f 100644 --- a/website/content/api-docs/secret/transit.mdx +++ b/website/content/api-docs/secret/transit.mdx @@ -4,7 +4,7 @@ page_title: Transit - Secrets Engines - HTTP API description: This is the API documentation for the Vault Transit secrets engine. --- -# Transit Secrets Engine (API) +# Transit secrets engine (API) This is the API documentation for the Vault Transit secrets engine. For general information about the usage and operation of the Transit secrets engine, please @@ -14,7 +14,7 @@ This documentation assumes the transit secrets engine is enabled at the `/transit` path in Vault. Since it is possible to enable secrets engines at any location, please update your API calls accordingly. -## Create Key +## Create key This endpoint creates a new named encryption key of the specified type. The values set here cannot be changed after key creation. @@ -86,7 +86,7 @@ values set here cannot be changed after key creation. hour. Uses [duration format strings](/vault/docs/concepts/duration-format). - `managed_key_name` `(string: "")` - The name of the managed key to use for this transit key. - `managed_key_id` `(string: "")` - The UUID of the managed key to use for this transit key. -### Sample Payload +### Sample payload ```json { @@ -95,7 +95,7 @@ values set here cannot be changed after key creation. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -105,7 +105,7 @@ $ curl \ http://127.0.0.1:8200/v1/transit/keys/my-key ``` -## Import Key +## Import key This endpoint imports existing key material into a new transit-managed encryption key. To import key material into an existing key, see the `import_version/` endpoint. @@ -193,7 +193,7 @@ key derivation. Required if `derived` is set to `true`. will disable automatic key rotation. This value cannot be shorter than one hour. -### Sample Payload +### Sample payload ```json { @@ -202,7 +202,7 @@ key derivation. Required if `derived` is set to `true`. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -212,7 +212,7 @@ $ curl \ http://127.0.0.1:8200/v1/transit/keys/my-key/import ``` -## Import Key Version +## Import key version This endpoint imports new key material into an existing imported key. @@ -257,7 +257,7 @@ is available. a new version will be created unless a private key is specified and the 'Latest' key is missing a private key. -### Sample Payload +### Sample payload ```json { @@ -265,7 +265,7 @@ a new version will be created unless a private key is specified and the } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -275,7 +275,7 @@ $ curl \ http://127.0.0.1:8200/v1/transit/keys/my-key/import_version ``` -## Get Wrapping Key +## Get wrapping key This endpoint is used to retrieve the wrapping key to use for importing keys. The returned key will be a 4096-bit RSA public key. @@ -284,7 +284,7 @@ The returned key will be a 4096-bit RSA public key. | :---- | :---------------------- | | `GET` | `/transit/wrapping_key` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -293,7 +293,7 @@ $ curl \ http://127.0.0.1:8200/v1/transit/wrapping_key ``` -### Sample Response +### Sample response ```json { @@ -303,7 +303,7 @@ $ curl \ } ``` -## Read Key +## Read key This endpoint returns information about a named encryption key. The `keys` object shows the creation time of each key version; the values are not the keys @@ -320,7 +320,7 @@ type. - `name` `(string: )` – Specifies the name of the encryption key to read. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -328,7 +328,7 @@ $ curl \ http://127.0.0.1:8200/v1/transit/keys/my-key ``` -### Sample Response +### Sample response ```json { @@ -359,7 +359,7 @@ The sample response shows a key that was created on September 22, 2015 7:50:12 P The fields `supports_encryption`, `supports_decryption`, `supports_derivation` and `supports_signing` are derived from the type of the key, and indicate which operations may be performed with it. -## List Keys +## List keys This endpoint returns a list of keys. Only the key names are returned (not the actual keys themselves). @@ -368,7 +368,7 @@ actual keys themselves). | :----- | :-------------- | | `LIST` | `/transit/keys` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -377,7 +377,7 @@ $ curl \ http://127.0.0.1:8200/v1/transit/keys ``` -### Sample Response +### Sample response ```json { @@ -390,7 +390,7 @@ $ curl \ } ``` -## Delete Key +## Delete key This endpoint deletes a named encryption key. It will no longer be possible to decrypt any data encrypted with the named key. Because this is a potentially @@ -406,7 +406,7 @@ catastrophic operation, the `deletion_allowed` tunable must be set in the key's - `name` `(string: )` – Specifies the name of the encryption key to delete. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -415,7 +415,7 @@ $ curl \ http://127.0.0.1:8200/v1/transit/keys/my-key ``` -## Update Key Configuration +## Update key configuration This endpoint allows tuning configuration values for a given key. (These values are returned during a read operation on the named key.) @@ -453,7 +453,7 @@ are returned during a read operation on the named key.) key rotation. This value cannot be shorter than one hour. When no value is provided, the period remains unchanged. Uses [duration format strings](/vault/docs/concepts/duration-format). -### Sample Payload +### Sample payload ```json { @@ -461,7 +461,7 @@ are returned during a read operation on the named key.) } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -471,7 +471,7 @@ $ curl \ http://127.0.0.1:8200/v1/transit/keys/my-key/config ``` -## Rotate Key +## Rotate key This endpoint rotates the version of the named key. After rotation, new plaintext requests will be encrypted with the new version of the key. To upgrade @@ -498,7 +498,7 @@ rotated within Vault, it will not support further import operations. ~> **Note**: If the key to be rotated is of type `managed_key`, either the `managed_key_name` or the `managed_key_id` for the new key must be provided. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -507,7 +507,7 @@ $ curl \ http://127.0.0.1:8200/v1/transit/keys/my-key/rotate ``` -## Securely Export Key +## Securely export key This endpoint returns a wrapped copy of the `source` key, protected by the `destination` key using BYOK method accepted by the @@ -537,7 +537,7 @@ CLI helper utility. specified as part of the URL. If the version is set to `latest`, the current key will be returned. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -545,7 +545,7 @@ $ curl \ http://127.0.0.1:8200/v1/transit/byok-export/wrapping-key/to-be-shared-key/1 ``` -### Sample Response +### Sample response ```json { @@ -559,7 +559,7 @@ $ curl \ ``` -## Export Key +## Export key This endpoint returns the named key. The `keys` object shows the value of the key for each version. If `version` is specified, the specific version will be @@ -590,7 +590,7 @@ be valid. all versions of the key will be returned. This is specified as part of the URL. If the version is set to `latest`, the current key will be returned. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -598,7 +598,7 @@ $ curl \ http://127.0.0.1:8200/v1/transit/export/encryption-key/my-key/1 ``` -### Sample Response +### Sample response ```json { @@ -612,7 +612,7 @@ $ curl \ } ``` -## Write Keys Configuration +## Write keys configuration This endpoint maintains global configuration across all keys. This allows removing the upsert capability of the `/encrypt/:key` endpoint, @@ -627,7 +627,7 @@ preventing new keys from being created if none exists. - `disable_upsert` `(bool: false)` - Specifies whether to disable upserting on encryption (automatic creation of unknown keys). -### Sample Payload +### Sample payload ```json { @@ -635,7 +635,7 @@ preventing new keys from being created if none exists. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -645,7 +645,7 @@ $ curl \ http://127.0.0.1:8200/v1/transit/config/keys ``` -### Sample Response +### Sample response ```json { @@ -655,7 +655,7 @@ $ curl \ } ``` -## Read Keys Configuration +## Read keys configuration This endpoint maintains global configuration across all keys. This allows removing the upsert capability of the `/encrypt/:key` endpoint, @@ -665,7 +665,7 @@ preventing new keys from being created if none exists. | :----- | :--------------------- | | `GET` | `/transit/config/keys` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -673,7 +673,7 @@ $ curl \ http://127.0.0.1:8200/v1/transit/config/keys ``` -### Sample Response +### Sample response ```json { @@ -683,7 +683,7 @@ $ curl \ } ``` -## Encrypt Data +## Encrypt data This endpoint encrypts the provided plaintext using the named key. This path supports the `create` and `update` policy capabilities as follows: if the user @@ -779,7 +779,7 @@ requirement is that Vault does not require that the plaintext is "text". It could be a binary file such as a PDF or image. The easiest safe transport mechanism for this data as part of a JSON payload is to base64-encode it. -### Sample Payload +### Sample payload Fist, encode the plaintext with base64: @@ -798,7 +798,7 @@ Use the base64-encoded plaintext in the payload: !> Vault HTTP API imposes a maximum request size of 32MB to prevent a denial of service attack. This can be tuned per [`listener` block](/vault/docs/configuration/listener/tcp) in the Vault server configuration. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -808,7 +808,7 @@ $ curl \ http://127.0.0.1:8200/v1/transit/encrypt/my-key ``` -### Sample Response +### Sample response ```json { @@ -818,7 +818,7 @@ $ curl \ } ``` -## Decrypt Data +## Decrypt data This endpoint decrypts the provided ciphertext using the named key. @@ -878,7 +878,7 @@ This endpoint decrypts the provided ciphertext using the named key. decrypt) could be indicative of a security breach and should not be ignored. -### Sample Payload +### Sample payload ```json { @@ -886,7 +886,7 @@ This endpoint decrypts the provided ciphertext using the named key. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -896,7 +896,7 @@ $ curl \ http://127.0.0.1:8200/v1/transit/decrypt/my-key ``` -### Sample Response +### Sample response ```json { @@ -906,7 +906,7 @@ $ curl \ } ``` -## Rewrap Data +## Rewrap data This endpoint rewraps the provided ciphertext using the latest version of the named key. Because this never returns plaintext, it is possible to delegate this @@ -960,7 +960,7 @@ functionality to untrusted users or scripts. ] ``` -### Sample Payload +### Sample payload ```json { @@ -968,7 +968,7 @@ functionality to untrusted users or scripts. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -978,7 +978,7 @@ $ curl \ http://127.0.0.1:8200/v1/transit/rewrap/my-key ``` -### Sample Response +### Sample response ```json { @@ -988,7 +988,7 @@ $ curl \ } ``` -## Generate Data Key +## Generate data key This endpoint generates a new high-entropy key and the value encrypted with the named key. Optionally return the plaintext of the key as well. Whether plaintext @@ -1024,7 +1024,7 @@ then made available to trusted users. - `bits` `(int: 256)` – Specifies the number of bits in the desired key. Can be 128, 256, or 512. -### Sample Payload +### Sample payload ```json { @@ -1032,7 +1032,7 @@ then made available to trusted users. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1042,7 +1042,7 @@ $ curl \ http://127.0.0.1:8200/v1/transit/datakey/plaintext/my-key ``` -### Sample Response +### Sample response ```json { @@ -1053,7 +1053,7 @@ $ curl \ } ``` -## Generate Random Bytes +## Generate random bytes This endpoint returns high-quality random bytes of the specified length. @@ -1074,7 +1074,7 @@ This endpoint returns high-quality random bytes of the specified length. `seal` sources from entropy augmentation (enterprise only). `all` mixes bytes from all available sources. -### Sample Payload +### Sample payload ```json { @@ -1082,7 +1082,7 @@ This endpoint returns high-quality random bytes of the specified length. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1092,7 +1092,7 @@ $ curl \ http://127.0.0.1:8200/v1/transit/random/164 ``` -### Sample Response +### Sample response ```json { @@ -1102,7 +1102,7 @@ $ curl \ } ``` -## Hash Data +## Hash data This endpoint returns the cryptographic hash of given data using the specified algorithm. @@ -1134,7 +1134,7 @@ algorithm. - `format` `(string: "hex")` – Specifies the output encoding. This can be either `hex` or `base64`. -### Sample Payload +### Sample payload ```json { @@ -1142,7 +1142,7 @@ algorithm. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1152,7 +1152,7 @@ $ curl \ http://127.0.0.1:8200/v1/transit/hash/sha2-512 ``` -### Sample Response +### Sample response ```json { @@ -1229,7 +1229,7 @@ be used. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1239,7 +1239,7 @@ $ curl \ http://127.0.0.1:8200/v1/transit/hmac/my-key/sha2-512 ``` -### Sample Payload +### Sample payload ```json { @@ -1247,7 +1247,7 @@ $ curl \ } ``` -### Sample Response +### Sample response ```json { @@ -1257,7 +1257,7 @@ $ curl \ } ``` -### Sample Payload with batch_input +### Sample payload with batch_input ```json { @@ -1276,7 +1276,7 @@ $ curl \ } ``` -### Sample Response for batch_input +### Sample response for batch_input ```json { @@ -1299,7 +1299,7 @@ $ curl \ } ``` -## Sign Data +## Sign data This endpoint returns the cryptographic signature of the given data using the named key and the specified hash algorithm. The key must be of a type that @@ -1416,7 +1416,7 @@ supports signing. - `hash`: Causes the salt length to equal the length of the hash used in the signature - An integer between the minimum and the maximum permissible salt lengths for the given RSA key size. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1426,7 +1426,7 @@ $ curl \ http://127.0.0.1:8200/v1/transit/sign/my-key/sha2-512 ``` -### Sample Payload +### Sample payload ```json { @@ -1434,7 +1434,7 @@ $ curl \ } ``` -### Sample Response +### Sample response ```json { @@ -1444,7 +1444,7 @@ $ curl \ } ``` -### Sample Payload with batch_input +### Sample payload with batch_input Given an ed25519 key with derived keys set, the context parameter is expected for each batch_input item, and the response will include the derived public key for each item. @@ -1465,7 +1465,7 @@ the response will include the derived public key for each item. } ``` -### Sample Response for batch_input +### Sample response for batch_input ``` { @@ -1487,7 +1487,7 @@ the response will include the derived public key for each item. } ``` -## Verify Signed Data +## Verify signed data This endpoint returns whether the provided signature is valid for the given data. @@ -1606,7 +1606,7 @@ data. - `hash`: Causes the salt length to equal the length of the hash used in the signature - An integer between the minimum and the maximum permissible salt lengths for the given RSA key size. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1616,7 +1616,7 @@ $ curl \ http://127.0.0.1:8200/v1/transit/verify/my-key/sha2-512 ``` -### Sample Payload +### Sample payload ```json { @@ -1625,7 +1625,7 @@ $ curl \ } ``` -### Sample Response +### Sample response ```json { @@ -1635,7 +1635,7 @@ $ curl \ } ``` -### Sample Payload with batch_input +### Sample payload with batch_input ``` { @@ -1659,7 +1659,7 @@ $ curl \ } ``` -### Sample Response for batch_input +### Sample response for batch_input ``` { @@ -1679,7 +1679,7 @@ $ curl \ } ``` -## Backup Key +## Backup key This endpoint returns a plaintext backup of a named key. The backup contains all the configuration data and keys of all the versions along with the HMAC key. @@ -1694,7 +1694,7 @@ restore the key. - `name` `(string: )` - Name of the key. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1702,7 +1702,7 @@ $ curl \ http://127.0.0.1:8200/v1/transit/backup/aes ``` -### Sample Response +### Sample response ```json { @@ -1712,7 +1712,7 @@ $ curl \ } ``` -## Restore Key +## Restore key This endpoint restores the backup as a named key. This will restore the key configurations and all the versions of the named key along with HMAC keys. The @@ -1738,7 +1738,7 @@ name first to verify that the operation successfully completes. - `force` `(bool: false)` - If set, force the restore to proceed even if a key by this name already exists. -### Sample Payload +### Sample payload ```json { @@ -1746,7 +1746,7 @@ name first to verify that the operation successfully completes. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1756,7 +1756,7 @@ $ curl \ http://127.0.0.1:8200/v1/transit/restore ``` -## Trim Key +## Trim key This endpoint trims older key versions setting a minimum version for the keyring. Once trimmed, previous versions of the key cannot be recovered. @@ -1774,7 +1774,7 @@ keyring. Once trimmed, previous versions of the key cannot be recovered. be set when either `min_encryption_version` or `min_decryption_version` is set to zero. -### Sample Payload +### Sample payload ```json { @@ -1782,7 +1782,7 @@ keyring. Once trimmed, previous versions of the key cannot be recovered. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1792,7 +1792,7 @@ $ curl \ http://127.0.0.1:8200/v1/transit/keys/my-key/trim ``` -## Configure Cache +## Configure cache This endpoint is used to configure the transit engine's cache. Note that configuration changes will not be applied until the transit plugin is reloaded which can be achieved @@ -1808,7 +1808,7 @@ using the [`/sys/plugins/reload/backend`][sys-plugin-reload-backend] endpoint. `0` means unlimited. A _Least Recently Used_ (LRU) caching strategy is used for a non-zero cache size. Must be 0 (default) or a value greater or equal to 10 (minimum cache size). -### Sample Payload +### Sample payload ```json { @@ -1816,7 +1816,7 @@ using the [`/sys/plugins/reload/backend`][sys-plugin-reload-backend] endpoint. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1826,7 +1826,7 @@ $ curl \ http://127.0.0.1:8200/v1/transit/cache-config ``` -## Read Transit Cache Configuration +## Read transit cache configuration This endpoint retrieves configurations for the transit engine's cache. @@ -1834,7 +1834,7 @@ This endpoint retrieves configurations for the transit engine's cache. | :----- | :---------------------- | | `GET` | `/transit/cache-config` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -1843,7 +1843,7 @@ $ curl \ http://127.0.0.1:8200/v1/transit/cache-config ``` -### Sample Response +### Sample response ```json "data": { @@ -1851,7 +1851,7 @@ $ curl \ }, ``` -## Managed Keys +## Managed keys ~> **Note**: Managed keys are an Enterprise only feature. diff --git a/website/content/api-docs/system/audit-hash.mdx b/website/content/api-docs/system/audit-hash.mdx index 1178b3029ec2..6823f4f59a40 100644 --- a/website/content/api-docs/system/audit-hash.mdx +++ b/website/content/api-docs/system/audit-hash.mdx @@ -12,7 +12,7 @@ The `/sys/audit-hash` endpoint is used to calculate the hash of the data used by an audit device's hash function and salt. This can be used to search audit logs for a hashed value when the original value is known. -## Calculate Hash +## Calculate hash This endpoint hashes the given input data with the specified audit device's hash function and salt. This endpoint can be used to discover whether a given @@ -35,7 +35,7 @@ should also be base64-encoded to supply into the `input` parameter. - `input` `(string: )` – Specifies the input string to hash. -### Sample Payload +### Sample payload ```json { @@ -43,7 +43,7 @@ should also be base64-encoded to supply into the `input` parameter. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -53,7 +53,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/audit-hash/example-audit ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/audit.mdx b/website/content/api-docs/system/audit.mdx index 752455349bbe..7819abdd1b7b 100644 --- a/website/content/api-docs/system/audit.mdx +++ b/website/content/api-docs/system/audit.mdx @@ -10,7 +10,7 @@ The `/sys/audit` endpoint is used to list, enable, and disable audit devices. Audit devices must be enabled before use, and more than one device may be enabled at a time. -## List Enabled Audit Devices +## List enabled audit devices This endpoint lists only the enabled audit devices (it does not list all available audit devices). @@ -22,7 +22,7 @@ available audit devices). | :----- | :----------- | | `GET` | `/sys/audit` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -30,7 +30,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/audit ``` -### Sample Response +### Sample response ```javascript { @@ -44,7 +44,7 @@ $ curl \ } ``` -## Enable Audit Device +## Enable audit device This endpoint enables a new audit device at the supplied path. The path can be a single word name or a more complex, nested path. @@ -76,7 +76,7 @@ relevant functionality is only supported in Vault Enterprise: - `local` `(bool: false)` – Specifies if the audit device is local within the cluster only. Local audit devices are not replicated nor (if a secondary) removed by replication. -### Sample Payload +### Sample payload ```json { @@ -87,7 +87,7 @@ relevant functionality is only supported in Vault Enterprise: } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -97,7 +97,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/audit/example-audit ``` -## Disable Audit Device +## Disable audit device This endpoint disables the audit device at the given path. @@ -117,7 +117,7 @@ the audit device at the same path, as a new salt will be created for hashing. - `path` `(string: )` – Specifies the path of the audit device to delete. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/system/auth.mdx b/website/content/api-docs/system/auth.mdx index 64e71efc2f25..1742b3e7ab6c 100644 --- a/website/content/api-docs/system/auth.mdx +++ b/website/content/api-docs/system/auth.mdx @@ -10,7 +10,7 @@ The `/sys/auth` endpoint is used to list, create, update, and delete auth methods. Auth methods convert user or machine-supplied information into a token which can be used for all future requests. -## List Auth Methods +## List auth methods This endpoint lists all enabled auth methods. @@ -18,7 +18,7 @@ This endpoint lists all enabled auth methods. | :----- | :---------- | | `GET` | `/sys/auth` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -26,7 +26,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/auth ``` -### Sample Response +### Sample response ```json { @@ -79,7 +79,7 @@ $ curl \ } ``` -## Enable Auth Method +## Enable auth method This endpoint enables a new auth method. After enabling, the auth method can be accessed and configured via the auth path specified as part of the URL. This @@ -161,7 +161,7 @@ relevant functionality is only supported in Vault Enterprise: - `seal_wrap` `(bool: false)` - Enable seal wrapping for the mount, causing values stored by the mount to be wrapped by the seal's encryption capability. -### Sample Payload +### Sample payload ```json { @@ -170,7 +170,7 @@ relevant functionality is only supported in Vault Enterprise: } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -180,7 +180,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/auth/my-auth ``` -## Read Auth Method configuration +## Read auth method configuration This endpoints returns the configuration of the auth method at the given path. @@ -188,7 +188,7 @@ This endpoints returns the configuration of the auth method at the given path. | :----- | :---------------- | | `GET` | `/sys/auth/:path` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -196,7 +196,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/auth/my-auth ``` -### Sample Response +### Sample response ```json { @@ -229,7 +229,7 @@ $ curl \ ``` -## Disable Auth Method +## Disable auth method This endpoint disables the auth method at the given auth path. @@ -245,7 +245,7 @@ This endpoint disables the auth method at the given auth path. - `path` `(string: )` – Specifies the path to disable. This is part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -254,7 +254,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/auth/my-auth ``` -## Read Auth Method Tuning +## Read auth method tuning This endpoint reads the given auth path's configuration. _This endpoint requires `sudo` capability on the final path, but the same functionality can be achieved @@ -271,7 +271,7 @@ without `sudo` via `sys/mounts/auth/[auth-path]/tune`._ - `path` `(string: )` – Specifies the path in which to tune. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -279,7 +279,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/auth/my-auth/tune ``` -### Sample Response +### Sample response ```json { @@ -291,7 +291,7 @@ $ curl \ } ``` -## Tune Auth Method +## Tune auth method Tune configuration parameters for a given auth path. _This endpoint requires `sudo` capability on the final path, but the same functionality @@ -361,7 +361,7 @@ can be achieved without `sudo` via `sys/mounts/auth/[auth-path]/tune`._ - `lockout_disable` `(bool: false)` - Disables the user lockout feature for this mount if set to true. -### Sample Payload +### Sample payload ```json { @@ -376,7 +376,7 @@ can be achieved without `sudo` via `sys/mounts/auth/[auth-path]/tune`._ } ``` -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/system/capabilities-accessor.mdx b/website/content/api-docs/system/capabilities-accessor.mdx index 7f0b4a46802f..ed53ebec2867 100644 --- a/website/content/api-docs/system/capabilities-accessor.mdx +++ b/website/content/api-docs/system/capabilities-accessor.mdx @@ -13,7 +13,7 @@ the token associated with the given accessor. The capabilities returned will be derived from the policies that are on the token, and from the policies to which the token is entitled to through the entity and entity's group memberships. -## Query Token Accessor Capabilities +## Query token accessor capabilities This endpoint returns the capabilities of the token associated with the given accessor, for the given path. Multiple paths are taken in at once and the @@ -33,7 +33,7 @@ returned. For backwards compatibility, if a single path is supplied, a - `paths` `(list: )` – Paths on which capabilities are being queried. -### Sample Payload +### Sample payload ```json { @@ -42,7 +42,7 @@ returned. For backwards compatibility, if a single path is supplied, a } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -52,7 +52,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/capabilities-accessor ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/capabilities-self.mdx b/website/content/api-docs/system/capabilities-self.mdx index 3726fcfd4638..1fb0eb7cf63f 100644 --- a/website/content/api-docs/system/capabilities-self.mdx +++ b/website/content/api-docs/system/capabilities-self.mdx @@ -14,7 +14,7 @@ will be derived from the policies that are on the token, and from the policies to which the token is entitled to through the entity and entity's group memberships. -## Query Self Capabilities +## Query self capabilities This endpoint returns the capabilities of client token on the given paths. The client token is the Vault token with which this API call is made. Multiple @@ -30,7 +30,7 @@ returned. For backwards compatibility, if a single path is supplied, a - `paths` `(list: )` – Paths on which capabilities are being queried. -### Sample Payload +### Sample payload ```json { @@ -38,7 +38,7 @@ returned. For backwards compatibility, if a single path is supplied, a } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -48,7 +48,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/capabilities-self ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/capabilities.mdx b/website/content/api-docs/system/capabilities.mdx index 33ef90a4be26..db06f1181036 100644 --- a/website/content/api-docs/system/capabilities.mdx +++ b/website/content/api-docs/system/capabilities.mdx @@ -13,7 +13,7 @@ on the given paths. The capabilities returned will be derived from the policies that are on the token, and from the policies to which the token is entitled to through the entity and entity's group memberships. -## Query Token Capabilities +## Query token capabilities This endpoint returns the list of capabilities of a given token on the given paths. Multiple paths are taken in at once and the capabilities of the token @@ -31,7 +31,7 @@ supplied, a `capabilities` field will also be returned. - `token` `(string: )` – Token for which capabilities are being queried. -### Sample Payload +### Sample payload ```json { @@ -40,7 +40,7 @@ supplied, a `capabilities` field will also be returned. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -50,7 +50,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/capabilities ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/config-auditing.mdx b/website/content/api-docs/system/config-auditing.mdx index a1b4ad800851..a69bff4baef6 100644 --- a/website/content/api-docs/system/config-auditing.mdx +++ b/website/content/api-docs/system/config-auditing.mdx @@ -8,7 +8,7 @@ description: The `/sys/config/auditing` endpoint is used to configure auditing s The `/sys/config/auditing` endpoint is used to configure auditing settings. -## Read All Audited Request Headers +## Read all audited request headers This endpoint lists the request headers that are configured to be audited. @@ -19,7 +19,7 @@ This endpoint lists the request headers that are configured to be audited. | :----- | :------------------------------------- | | `GET` | `/sys/config/auditing/request-headers` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -27,7 +27,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/config/auditing/request-headers ``` -### Sample Response +### Sample response ```json { @@ -39,7 +39,7 @@ $ curl \ } ``` -## Read Single Audit Request Header +## Read single audit request header This endpoint lists the information for the given request header. @@ -55,7 +55,7 @@ This endpoint lists the information for the given request header. - `name` `(string: )` – Specifies the name of the request header to query. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -63,7 +63,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/config/auditing/request-headers/my-header ``` -### Sample Response +### Sample response ```json { @@ -73,7 +73,7 @@ $ curl \ } ``` -## Create/Update Audit Request Header +## Create/Update audit request header This endpoint enables auditing of a header. @@ -89,7 +89,7 @@ This endpoint enables auditing of a header. - `hmac` `(bool: false)` – Specifies if this header's value should be HMAC'ed in the audit logs. -### Sample Payload +### Sample payload ```json { @@ -97,7 +97,7 @@ This endpoint enables auditing of a header. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -107,7 +107,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/config/auditing/request-headers/my-header ``` -## Delete Audit Request Header +## Delete audit request header This endpoint disables auditing of the given request header. @@ -118,7 +118,7 @@ This endpoint disables auditing of the given request header. | :------- | :------------------------------------------- | | `DELETE` | `/sys/config/auditing/request-headers/:name` | -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/system/config-control-group.mdx b/website/content/api-docs/system/config-control-group.mdx index 55cbf15cfca4..4bd1a3ae6e73 100644 --- a/website/content/api-docs/system/config-control-group.mdx +++ b/website/content/api-docs/system/config-control-group.mdx @@ -11,7 +11,7 @@ description: The '/sys/config/control-group' endpoint configures control groups. The `/sys/config/control-group` endpoint is used to configure Control Group settings. -## Read Control Group Settings +## Read control group settings This endpoint returns the current Control Group configuration. @@ -19,7 +19,7 @@ This endpoint returns the current Control Group configuration. | :----- | :-------------------------- | | `GET` | `/sys/config/control-group` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -27,7 +27,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/config/control-group ``` -### Sample Response +### Sample response ```json { @@ -35,7 +35,7 @@ $ curl \ } ``` -## Configure Control Group Settings +## Configure control group settings This endpoint allows configuring control groups. @@ -47,7 +47,7 @@ This endpoint allows configuring control groups. - `max_ttl` `int` – The maximum ttl for a control group wrapping token. This can be provided in seconds or duration (2h). -### Sample Payload +### Sample payload ```json { @@ -55,7 +55,7 @@ This endpoint allows configuring control groups. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -65,7 +65,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/config/control-group ``` -## Delete Control Group Settings +## Delete control group settings This endpoint removes any control group configuration. @@ -73,7 +73,7 @@ This endpoint removes any control group configuration. | :------- | :-------------------------- | | `DELETE` | `/sys/config/control-group` | -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/system/config-cors.mdx b/website/content/api-docs/system/config-cors.mdx index 27775f23d179..3f445ae4367e 100644 --- a/website/content/api-docs/system/config-cors.mdx +++ b/website/content/api-docs/system/config-cors.mdx @@ -13,7 +13,7 @@ The `/sys/config/cors` endpoint is used to configure CORS settings. - **`sudo` required** – All CORS endpoints require `sudo` capability in addition to any path-specific capabilities. -## Read CORS Settings +## Read CORS settings This endpoint returns the current CORS configuration. @@ -21,7 +21,7 @@ This endpoint returns the current CORS configuration. | :----- | :----------------- | | `GET` | `/sys/config/cors` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -29,7 +29,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/config/cors ``` -### Sample Response +### Sample response ```json { @@ -48,7 +48,7 @@ $ curl \ } ``` -## Configure CORS Settings +## Configure CORS settings This endpoint allows configuring the origins that are permitted to make cross-origin requests, as well as headers that are allowed on cross-origin requests. @@ -63,7 +63,7 @@ cross-origin requests, as well as headers that are allowed on cross-origin reque - `allowed_headers` `(string or string array: "" or [])` – A comma-delimited string or array of strings specifying headers that are permitted to be on cross-origin requests. Headers set via this parameter will be appended to the list of headers that Vault allows by default. -### Sample Payload +### Sample payload ```json { @@ -72,7 +72,7 @@ cross-origin requests, as well as headers that are allowed on cross-origin reque } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -82,7 +82,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/config/cors ``` -## Delete CORS Settings +## Delete CORS settings This endpoint removes any CORS configuration. @@ -90,7 +90,7 @@ This endpoint removes any CORS configuration. | :------- | :----------------- | | `DELETE` | `/sys/config/cors` | -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/system/config-group-policy-application.mdx b/website/content/api-docs/system/config-group-policy-application.mdx index de3e80926617..5a262d611092 100644 --- a/website/content/api-docs/system/config-group-policy-application.mdx +++ b/website/content/api-docs/system/config-group-policy-application.mdx @@ -23,7 +23,7 @@ regardless of what namespace the request token came from. Note that this configuration will be replicated between primary and secondaries, that is to say, primaries cannot have a different policy application mode to secondaries. -## Get Group Policy Application Information +## Get group policy application information This endpoint returns the current group policy application mode, which will be either `within_namespace_hierarchy` or `any`. @@ -33,7 +33,7 @@ either `within_namespace_hierarchy` or `any`. | :----- | :---------------------------- | | `GET` | `/sys/config/group-policy-application` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -41,7 +41,7 @@ $ curl \ 'http://127.0.0.1:8200/v1/sys/config/group-policy-application' ``` -### Sample Response +### Sample response ```json { @@ -49,7 +49,7 @@ $ curl \ } ``` -## Set Group Policy Application Information +## Set group policy application information This endpoint allows you to modify the current group policy application mode, which can be either `within_namespace_hierarchy` or `any`. `within_namespace_hierarchy` @@ -62,7 +62,7 @@ irrespective of namespace hierarchy. | :----- | :---------------------------- | | `POST`, `PUT` | `/sys/config/group-policy-application` | -### Sample Payload +### Sample payload ```json { @@ -70,7 +70,7 @@ irrespective of namespace hierarchy. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/system/config-reload.mdx b/website/content/api-docs/system/config-reload.mdx index e69b87102ad8..c7ee4c56764c 100644 --- a/website/content/api-docs/system/config-reload.mdx +++ b/website/content/api-docs/system/config-reload.mdx @@ -17,7 +17,7 @@ Currently, it only supports reloading license information from files on disk. - `subsystem` `(string: )` - Specifies the subsystem for Vault to reload. This is part of the request URL. -## Reload License File +## Reload license file ~> **Enterprise Only** – This endpoint requires Vault Enterprise. @@ -27,7 +27,7 @@ option or the `VAULT_LICENSE_PATH` environment variable. The updated license is applied to Vault, and Vault will then enable/disable licensed features if the features of the given license are different from those of the license Vault is currently using. -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/system/config-state.mdx b/website/content/api-docs/system/config-state.mdx index 9bb1a32416b7..9573633ce0af 100644 --- a/website/content/api-docs/system/config-state.mdx +++ b/website/content/api-docs/system/config-state.mdx @@ -9,7 +9,7 @@ description: The '/sys/config/state' endpoint is used to retrieve the configurat The endpoints under `sys/config/state` return Vault's configuration state. Currently, it only supports returning a sanitized version of the configuration. -## `Get Sanitized Configuration State` +## `Get sanitized configuration state` This endpoint returns a sanitized version of the configuration state. The configuration excludes certain fields and mappings in the configuration file @@ -21,7 +21,7 @@ that can potentially contain sensitive information, which includes values from | :----- | :---------------------------- | | `GET` | `/sys/config/state/sanitized` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -29,7 +29,7 @@ $ curl \ 'http://127.0.0.1:8200/v1/sys/config/state/sanitized' ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/config-ui.mdx b/website/content/api-docs/system/config-ui.mdx index cf8935923e56..9f655443ad7a 100644 --- a/website/content/api-docs/system/config-ui.mdx +++ b/website/content/api-docs/system/config-ui.mdx @@ -11,7 +11,7 @@ The `/sys/config/ui` endpoint is used to configure UI settings. - **`sudo` required** – All UI endpoints require `sudo` capability in addition to any path-specific capabilities. -## Read UI Settings +## Read UI settings This endpoint returns the given UI header configuration. @@ -25,7 +25,7 @@ This endpoint returns the given UI header configuration. - `multivalue` `(bool: )` - Returns multiple values if true. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -33,7 +33,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/config/ui/headers/X-Custom-Header ``` -### Sample Response +### Sample response ```json { @@ -41,7 +41,7 @@ $ curl \ } ``` -### Sample Request (Multi value) +### Sample request (Multi value) ```shell-session $ curl \ @@ -49,7 +49,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/config/ui/headers/X-Custom-Header?multivalue=true ``` -### Sample Response +### Sample response ```json { @@ -57,7 +57,7 @@ $ curl \ } ``` -## Configure UI Headers +## Configure UI headers This endpoint allows configuring the values to be returned for the UI header. @@ -71,7 +71,7 @@ This endpoint allows configuring the values to be returned for the UI header. - `values` `(list: )` - The values to be returned from the header. -### Sample Payload +### Sample payload ```json { @@ -79,7 +79,7 @@ This endpoint allows configuring the values to be returned for the UI header. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -89,7 +89,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/config/ui/headers/X-Custom-Header ``` -## Delete a UI Header +## Delete a UI header This endpoint removes a UI header. @@ -97,7 +97,7 @@ This endpoint removes a UI header. | :------- | :----------------------------- | | `DELETE` | `/sys/config/ui/headers/:name` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -106,7 +106,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/config/ui/headers/X-Custom-Header ``` -## List UI Headers +## List UI headers This endpoint returns a list of configured UI headers. @@ -114,7 +114,7 @@ This endpoint returns a list of configured UI headers. | :----- | :----------------------- | | `LIST` | `/sys/config/ui/headers` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -123,7 +123,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/config/ui/headers ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/control-group.mdx b/website/content/api-docs/system/control-group.mdx index 51d111f3d131..1f73716a476d 100644 --- a/website/content/api-docs/system/control-group.mdx +++ b/website/content/api-docs/system/control-group.mdx @@ -4,7 +4,7 @@ page_title: /sys/control-group - HTTP API description: The '/sys/control-group' endpoint handles the Control Group workflow. --- -## Authorize Control Group Request +## Authorize control group request ~> **Enterprise Only** – These endpoints require Vault Enterprise. @@ -18,7 +18,7 @@ This endpoint authorizes a control group request. - `accessor` `(string: )` – The accessor for the control group wrapping token. -### Sample Payload +### Sample payload ```json { @@ -26,7 +26,7 @@ This endpoint authorizes a control group request. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -36,7 +36,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/control-group/authorize ``` -### Sample Response +### Sample response ```json { @@ -46,7 +46,7 @@ $ curl \ } ``` -## Check Control Group Request Status +## Check control group request status This endpoint checks the status of a control group request. @@ -58,7 +58,7 @@ This endpoint checks the status of a control group request. - `accessor` `(string: )` – The accessor for the control group wrapping token. -### Sample Payload +### Sample payload ```json { @@ -66,7 +66,7 @@ This endpoint checks the status of a control group request. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -76,7 +76,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/control-group/request ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/decode-token.mdx b/website/content/api-docs/system/decode-token.mdx index 01cbc336de4c..ae0e3cb71a45 100644 --- a/website/content/api-docs/system/decode-token.mdx +++ b/website/content/api-docs/system/decode-token.mdx @@ -14,7 +14,7 @@ The `/sys/decode-token` endpoint is used to decode the encoded token which is th - `otp` `(string: )` - Specifies the otp code for decode. -## Sample Response +## Sample response ```json { diff --git a/website/content/api-docs/system/experiments.mdx b/website/content/api-docs/system/experiments.mdx index 93a4c10ea106..2b2f153f6066 100644 --- a/website/content/api-docs/system/experiments.mdx +++ b/website/content/api-docs/system/experiments.mdx @@ -8,7 +8,7 @@ description: The `/sys/experiments` endpoint returns information about experimen The `/sys/experiments` endpoint returns information about experiments on the Vault node. -## Read Experiments +## Read experiments This endpoint returns the experiments available and enabled on the Vault node. Experiments are per-node and cannot be changed while the node is running. See @@ -20,14 +20,14 @@ details on enabling experiments. | :----- | :----------------- | | `GET` | `/sys/experiments` | -### Sample Request +### Sample request ```shell-session $ curl \ http://127.0.0.1:8200/v1/sys/experiments ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/generate-recovery-token.mdx b/website/content/api-docs/system/generate-recovery-token.mdx index 7c073b7d4781..c7d86d822480 100644 --- a/website/content/api-docs/system/generate-recovery-token.mdx +++ b/website/content/api-docs/system/generate-recovery-token.mdx @@ -11,7 +11,7 @@ description: |- The `/sys/generate-recovery-token` endpoint is used to create a new recovery token for Vault. -## Read Recovery Token Generation Progress +## Read recovery token generation progress This endpoint reads the configuration and process of the current root generation attempt. @@ -20,14 +20,14 @@ attempt. | :----- | :------------------------------------- | | `GET` | `/sys/generate-recovery-token/attempt` | -### Sample Request +### Sample request ```shell-session $ curl \ http://127.0.0.1:8200/v1/sys/generate-recovery-token/attempt ``` -### Sample Response +### Sample response ```json { @@ -58,7 +58,7 @@ The raw bytes (char codes) of the token will be XOR'd with this value before being returned as a response to the final unseal key, encoded as base64. -## Start Recovery Token Generation +## Start recovery token generation This endpoint initializes a new recovery token generation attempt. Only a single recovery token generation attempt can take place at a time. @@ -73,7 +73,7 @@ recovery token generation attempt can take place at a time. The raw bytes of the token will be encrypted with this value before being returned to the final unseal key provider. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -81,7 +81,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/generate-recovery-token/attempt ``` -### Sample Response +### Sample response ```json { @@ -96,7 +96,7 @@ $ curl \ } ``` -## Cancel Recovery Token Generation +## Cancel recovery token generation This endpoint cancels any in-progress recovery token generation attempt. This clears any progress made. This must be called to change the OTP or PGP key being @@ -106,7 +106,7 @@ used. | :------- | :------------------------------------- | | `DELETE` | `/sys/generate-recovery-token/attempt` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -114,7 +114,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/generate-recovery-token/attempt ``` -## Provide Key Share to Generate Recovery Token +## Provide key share to generate recovery token This endpoint is used to enter a single root key share to progress the recovery token generation attempt. If the threshold number of root key shares @@ -135,7 +135,7 @@ only in memory and thus will only be valid until the next restart. - `nonce` `(string: )` – Specifies the nonce of the attempt. -### Sample Payload +### Sample payload ```json { @@ -144,7 +144,7 @@ only in memory and thus will only be valid until the next restart. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -153,7 +153,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/generate-recovery-token/update ``` -### Sample Response +### Sample response This returns a JSON-encoded object indicating the attempt nonce, and completion status, and the encoded recovery token, if the attempt is complete. diff --git a/website/content/api-docs/system/generate-root.mdx b/website/content/api-docs/system/generate-root.mdx index ed0cd7d0eeb7..29291b2688b9 100644 --- a/website/content/api-docs/system/generate-root.mdx +++ b/website/content/api-docs/system/generate-root.mdx @@ -10,7 +10,7 @@ description: |- The `/sys/generate-root` endpoint is used to create a new root key for Vault. -## Read Root Generation Progress +## Read root generation progress This endpoint reads the configuration and process of the current root generation attempt. @@ -19,14 +19,14 @@ attempt. | :----- | :--------------------------- | | `GET` | `/sys/generate-root/attempt` | -### Sample Request +### Sample request ```shell-session $ curl \ http://127.0.0.1:8200/v1/sys/generate-root/attempt ``` -### Sample Response +### Sample response ```json { @@ -57,7 +57,7 @@ The raw bytes (char codes) of the token will be XOR'd with this value before being returned as a response to the final unseal key, encoded as base64. -## Start Root Token Generation +## Start root token generation This endpoint initializes a new root generation attempt. Only a single root generation attempt can take place at a time. @@ -72,7 +72,7 @@ generation attempt can take place at a time. The raw bytes of the token will be encrypted with this value before being returned to the final unseal key provider. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -80,7 +80,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/generate-root/attempt ``` -### Sample Response +### Sample response ```json { @@ -95,7 +95,7 @@ $ curl \ } ``` -## Cancel Root Generation +## Cancel root generation This endpoint cancels any in-progress root generation attempt. This clears any progress made. This must be called to change the OTP or PGP key being used. @@ -104,7 +104,7 @@ progress made. This must be called to change the OTP or PGP key being used. | :------- | :--------------------------- | | `DELETE` | `/sys/generate-root/attempt` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -112,7 +112,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/generate-root/attempt ``` -## Provide Key Share to Generate Root +## Provide key share to generate root This endpoint is used to enter a single root key share to progress the root generation attempt. If the threshold number of root key shares is reached, @@ -130,7 +130,7 @@ nonce must be provided with each call. - `nonce` `(string: )` – Specifies the nonce of the attempt. -### Sample Payload +### Sample payload ```json { @@ -139,7 +139,7 @@ nonce must be provided with each call. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -148,7 +148,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/generate-root/update ``` -### Sample Response +### Sample response This returns a JSON-encoded object indicating the attempt nonce, and completion status, and the encoded root token, if the attempt is complete. diff --git a/website/content/api-docs/system/ha-status.mdx b/website/content/api-docs/system/ha-status.mdx index c552f90d8844..86183b3255cf 100644 --- a/website/content/api-docs/system/ha-status.mdx +++ b/website/content/api-docs/system/ha-status.mdx @@ -9,7 +9,7 @@ description: The `/sys/ha-status` endpoint is used to check the HA status of a V The `/sys/ha-status` endpoint is used to check the HA status of a Vault cluster. It lists the active node and the peers that it's heard from since it became active. -## HA Status +## HA status This endpoint returns the HA status of the Vault cluster. @@ -17,7 +17,7 @@ This endpoint returns the HA status of the Vault cluster. | :----- | :----------------- | | `GET` | `/sys/ha-status` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -25,7 +25,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/ha-status ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/health.mdx b/website/content/api-docs/system/health.mdx index aaa19cdd1c91..f8400db27a25 100644 --- a/website/content/api-docs/system/health.mdx +++ b/website/content/api-docs/system/health.mdx @@ -8,7 +8,7 @@ description: The `/sys/health` endpoint is used to check the health status of Va The `/sys/health` endpoint is used to check the health status of Vault. -## Read Health Information +## Read health information This endpoint returns the health status of Vault. This matches the semantics of a Consul HTTP health check and provides a simple way to monitor the health of a @@ -58,14 +58,14 @@ The default status codes are: - `uninitcode` `(int: 501)` – Specifies the status code that should be returned for a uninitialized node. -### Sample Request +### Sample request ```shell-session $ curl \ http://127.0.0.1:8200/v1/sys/health ``` -### Sample Response +### Sample response This response is only returned for a `GET` request. @@ -89,7 +89,7 @@ standby of its status. } ``` -### Sample Request to customize the status code being returned +### Sample request to customize the status code being returned ```shell-session $ curl -i https://127.0.0.1:8200/v1/sys/health\?drsecondarycode\=200 @@ -102,7 +102,7 @@ content-length: 364 date: Wed, 26 Jan 2022 09:21:13 GMT ``` -### Sample Response +### Sample response This response is only returned for a `GET` request. diff --git a/website/content/api-docs/system/host-info.mdx b/website/content/api-docs/system/host-info.mdx index f4abb515d17c..7426e935d861 100644 --- a/website/content/api-docs/system/host-info.mdx +++ b/website/content/api-docs/system/host-info.mdx @@ -9,7 +9,7 @@ description: The '/sys/host-info' endpoint is used to retrieve host information The `/sys/host-info` endpoint is used retrieve information about the host instance that the Vault server is running on. -## Collect Host Information +## Collect host information This endpoint returns information about the host instance that the Vault server is running on. The data returned includes CPU information, CPU @@ -19,7 +19,7 @@ times, disk usage, host info, and memory statistics. | :----- | :--------------- | | `GET` | `/sys/host-info` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -27,7 +27,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/host-info ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/in-flight-req.mdx b/website/content/api-docs/system/in-flight-req.mdx index aa5b4f62a898..efbbc5f83df5 100644 --- a/website/content/api-docs/system/in-flight-req.mdx +++ b/website/content/api-docs/system/in-flight-req.mdx @@ -10,7 +10,7 @@ The `/sys/in-flight-req` endpoint is used to get information on in-flight reques The returned information contains the `start_time`, `client_remote_address`, `request_path`, `request_method`, and `client_id` of the in-flight requests. -## Collect In-Flight Request Information +## Collect In-Flight request information This endpoint returns the information about the in-flight requests. @@ -18,7 +18,7 @@ This endpoint returns the information about the in-flight requests. | :----- | :---------- | | `GET` | `/sys/in-flight-req` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -26,7 +26,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/in-flight-req ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/index.mdx b/website/content/api-docs/system/index.mdx index d32d5345995e..11b7485f28d2 100644 --- a/website/content/api-docs/system/index.mdx +++ b/website/content/api-docs/system/index.mdx @@ -7,7 +7,7 @@ description: |- Vault and interact with many of Vault's internal features. --- -# System Backend +# System backend The system backend is a default backend in Vault that is mounted at the `/sys` endpoint. This endpoint cannot be disabled or moved, and is used to configure diff --git a/website/content/api-docs/system/init.mdx b/website/content/api-docs/system/init.mdx index b40896ac752c..c498042a42af 100644 --- a/website/content/api-docs/system/init.mdx +++ b/website/content/api-docs/system/init.mdx @@ -8,7 +8,7 @@ description: The `/sys/init` endpoint is used to initialize a new Vault. The `/sys/init` endpoint is used to initialize a new Vault. -## Read Initialization Status +## Read initialization status This endpoint returns the initialization status of Vault. @@ -16,14 +16,14 @@ This endpoint returns the initialization status of Vault. | :----- | :---------- | | `GET` | `/sys/init` | -### Sample Request +### Sample request ```shell-session $ curl \ http://127.0.0.1:8200/v1/sys/init ``` -### Sample Response +### Sample response ```json { @@ -31,7 +31,7 @@ $ curl \ } ``` -## Start Initialization +## Start initialization This endpoint initializes a new Vault. The Vault must not have been previously initialized. The recovery options, as well as the stored shares option, are only @@ -77,7 +77,7 @@ Additionally, the following options are only supported using Auto Unseal: must be base64-encoded from their original binary representation. The size of this array must be the same as `recovery_shares`. This is only available when using Auto Unseal. -### Sample Payload +### Sample payload ```json { @@ -86,7 +86,7 @@ Additionally, the following options are only supported using Auto Unseal: } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -95,7 +95,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/init ``` -### Sample Response +### Sample response A JSON-encoded object including the (possibly encrypted, if `pgp_keys` was provided) root keys, base 64 encoded root keys and initial root token: diff --git a/website/content/api-docs/system/inspect/index.mdx b/website/content/api-docs/system/inspect/index.mdx index 33fb07c8fc35..3d4e1cb64cd8 100644 --- a/website/content/api-docs/system/inspect/index.mdx +++ b/website/content/api-docs/system/inspect/index.mdx @@ -16,7 +16,7 @@ enable. Once the endpoint is turned on, it can be accessed with a root token or ~> **NOTE**: These endpoints are only available in Vault version 1.13+. Backwards compatibility is not guaranteed. These endpoints are subject to change or may disappear without notice. -## Supported Inspection Paths +## Supported inspection paths - [Router](/vault/api-docs/system/inspect/router) diff --git a/website/content/api-docs/system/inspect/router.mdx b/website/content/api-docs/system/inspect/router.mdx index 5ccebf804e6c..cb24460bd08f 100644 --- a/website/content/api-docs/system/inspect/router.mdx +++ b/website/content/api-docs/system/inspect/router.mdx @@ -20,7 +20,7 @@ This endpoint returns a list of router entries in the router's root tree. | :----- | :------------ | | `GET` | `/sys/internal/inspect/router/root` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -28,7 +28,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/internal/inspect/router/root ``` -### Sample Response +### Sample response ```json { "request_id": "819de627-d3bc-27f4-0e3c-5c5fb0b204ee", @@ -79,7 +79,7 @@ $ curl \ } ``` -## Mount UUID Cache +## Mount UUID cache This endpoint returns a list of mount entries in the router's mount UUID cache. @@ -87,7 +87,7 @@ This endpoint returns a list of mount entries in the router's mount UUID cache. | :----- | :------------ | | `GET` | `/sys/internal/inspect/router/uuid` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -95,7 +95,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/internal/inspect/router/uuid ``` -### Sample Response +### Sample response ```json { "request_id": "71512d6c-bb77-2e05-c24e-07c964139fdb", @@ -138,7 +138,7 @@ $ curl \ } ``` -## Mount Accessor Cache +## Mount accessor cache This endpoint returns a list of mount entries in the router's mount accessor cache. @@ -146,7 +146,7 @@ This endpoint returns a list of mount entries in the router's mount accessor cac | :----- | :------------ | | `GET` | `/sys/internal/inspect/router/accessor` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -154,7 +154,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/internal/inspect/router/accessor ``` -### Sample Request +### Sample request ```json { @@ -199,7 +199,7 @@ $ curl \ ``` -## Storage Prefix Tree +## Storage prefix tree This endpoint returns a list of mount entries in the router's storage prefix tree. @@ -207,7 +207,7 @@ This endpoint returns a list of mount entries in the router's storage prefix tre | :----- | :------------ | | `GET` | `/sys/internal/inspect/router/storage` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -215,7 +215,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/internal/inspect/router/storage ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/internal-counters.mdx b/website/content/api-docs/system/internal-counters.mdx index 8c3ac0079d90..42d46b550ef9 100644 --- a/website/content/api-docs/system/internal-counters.mdx +++ b/website/content/api-docs/system/internal-counters.mdx @@ -19,7 +19,7 @@ This endpoint returns the total number of Entities. | :----- | :-------------------------------- | | `GET` | `/sys/internal/counters/entities` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -28,7 +28,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/internal/counters/entities ``` -### Sample Response +### Sample response ```json { @@ -57,7 +57,7 @@ This endpoint returns the total number of Tokens. | :----- | :------------------------------ | | `GET` | `/sys/internal/counters/tokens` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -66,7 +66,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/internal/counters/tokens ``` -### Sample Response +### Sample response ```json { @@ -87,7 +87,7 @@ $ curl \ } ``` -## Client Count +## Client count This endpoint returns client activity information for a given billing period, which is represented by the `start_time` and `end_time` parameters. @@ -352,7 +352,7 @@ This endpoint was added in Vault 1.6. explicitly provide a start and end time. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -361,7 +361,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/internal/counters/activity ``` -### Sample Response +### Sample response ```json { @@ -718,7 +718,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/internal/counters/activity?end_time=2020-06-30T00%3A00%3A00Z&start_time=2020-06-01T00%3A00%3A00Z&limit_namespaces=2 ``` -## Partial Month Client Count +## Partial month client count This endpoint returns the client activity in the current month. The response will have activity attributions per namespace, per mount within each namespaces, @@ -737,7 +737,7 @@ This endpoint was added in Vault 1.7. | :----- | :---------------------------------------- | | `GET` | `/sys/internal/counters/activity/monthly` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -746,7 +746,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/internal/counters/activity/monthly ``` -### Sample Response +### Sample response ```json { @@ -861,7 +861,7 @@ $ curl \ } ``` -## Update the Client Count Configuration +## Update the client count configuration The `/sys/internal/counters/config` endpoint is used to configure logging of active clients. @@ -879,7 +879,7 @@ The `/sys/internal/counters/config` endpoint is used to configure logging of act Any missing parameters are left at their existing value. -### Sample Payload +### Sample payload ```json { @@ -889,7 +889,7 @@ Any missing parameters are left at their existing value. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -899,7 +899,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/internal/counters/config ``` -## Read the Client Count Configuration +## Read the client count configuration Reading the configuration shows the current settings, as well as a flag as to whether any data can be queried. @@ -907,7 +907,7 @@ Reading the configuration shows the current settings, as well as a flag as to wh - `queries_available` `(bool)` - indicates whether any usage report is available. This will initially be false until the end of the first calendar month after the feature is enabled. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -916,7 +916,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/internal/counters/config ``` -### Sample Response +### Sample response ```json { @@ -936,7 +936,7 @@ $ curl \ } ``` -## Activity Export +## Activity export This endpoint returns an export of the clients that had activity within the provided start and end times. The returned set of client information will be @@ -973,7 +973,7 @@ This endpoint was added in Vault 1.11. values are `csv` and `json`. If no format is provided a default of `json` will be used. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -982,7 +982,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/internal/counters/activity/export ``` -### Sample Response +### Sample response ```json {"client_id":"3f210722-7210-98e8-1f0d-e6a39ffb29c6","namespace_id":"root","timestamp":1653350457,"mount_accessor":"auth_userpass_bb52979d"} diff --git a/website/content/api-docs/system/internal-specs-openapi.mdx b/website/content/api-docs/system/internal-specs-openapi.mdx index 452c62ed9284..0ffc62dce9be 100644 --- a/website/content/api-docs/system/internal-specs-openapi.mdx +++ b/website/content/api-docs/system/internal-specs-openapi.mdx @@ -23,7 +23,7 @@ Basic documentation will be generated for all paths, but a newer path definition more detailed documentation to be added. At this time the `/sys` endpoints have been updated to use the new structure, and other endpoints will be modified incrementally. -## Get OpenAPI Document +## Get OpenAPI document This endpoint returns a single OpenAPI document describing all paths visible to the requester. @@ -36,13 +36,13 @@ This endpoint returns a single OpenAPI document describing all paths visible to - `generic_mount_paths` `(bool: false)` – Used to specify whether to use generic mount paths. If set, the mount paths will be replaced with a dynamic parameter: `{mountPath}` -### Sample Request +### Sample request ```shell-session $ curl http://127.0.0.1:8200/v1/sys/internal/specs/openapi?generic_mount_paths=false ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/internal-ui-feature.mdx b/website/content/api-docs/system/internal-ui-feature.mdx index 05a0f9f44395..138a807e0de2 100644 --- a/website/content/api-docs/system/internal-ui-feature.mdx +++ b/website/content/api-docs/system/internal-ui-feature.mdx @@ -14,7 +14,7 @@ This is currently only being used internally for the UI and is an unauthenticated endpoint. Due to the nature of its intended usage, there is no guarantee on backwards compatibility for this endpoint. -## Get Enabled Feature Flags +## Get enabled feature flags This endpoint lists the enabled feature flags relevant to the UI. @@ -22,14 +22,14 @@ This endpoint lists the enabled feature flags relevant to the UI. | :----- | :------------------------------- | | `GET` | `/sys/internal/ui/feature-flags` | -### Sample Request +### Sample request ```shell-session $ curl \ http://127.0.0.1:8200/v1/sys/internal/ui/feature-flags ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/internal-ui-mounts.mdx b/website/content/api-docs/system/internal-ui-mounts.mdx index 20bd4ca36046..c3815a2c32d8 100644 --- a/website/content/api-docs/system/internal-ui-mounts.mdx +++ b/website/content/api-docs/system/internal-ui-mounts.mdx @@ -20,7 +20,7 @@ include additional mounts which the token has been granted path capabilities on. Due to the nature of its intended usage, there is no guarantee on backwards compatibility for this endpoint. -## Get Available Visible Mounts +## Get available visible mounts This endpoint lists all enabled auth methods. @@ -28,14 +28,14 @@ This endpoint lists all enabled auth methods. | :----- | :------------------------ | | `GET` | `/sys/internal/ui/mounts` | -### Sample Request +### Sample request ```shell-session $ curl \ http://127.0.0.1:8200/v1/sys/internal/ui/mounts ``` -### Sample Response +### Sample response ```json { @@ -57,7 +57,7 @@ $ curl \ } ``` -## Get Single Mount Details +## Get single mount details This endpoint lists details for a specific mount path. This is an authenticated endpoint, and is currently only being used internally. @@ -83,7 +83,7 @@ compatibility for this endpoint. | :----- | :------------------------------ | | `GET` | `/sys/internal/ui/mounts/:path` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -91,7 +91,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/internal/ui/mounts/cubbyhole ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/internal-ui-namespaces.mdx b/website/content/api-docs/system/internal-ui-namespaces.mdx index 02b5ab7e24f1..d6019ccefe22 100644 --- a/website/content/api-docs/system/internal-ui-namespaces.mdx +++ b/website/content/api-docs/system/internal-ui-namespaces.mdx @@ -14,7 +14,7 @@ This is currently only being used internally for the UI and is an unauthenticated endpoint. Due to the nature of its intended usage, there is no guarantee on backwards compatibility for this endpoint. -## Get Namespaces +## Get namespaces This endpoint lists the namespaces relevant to the UI. @@ -22,14 +22,14 @@ This endpoint lists the namespaces relevant to the UI. | :----- | :------------------------------- | | `GET` | `/sys/internal/ui/namespaces` | -### Sample Request +### Sample request ```shell-session $ curl \ http://127.0.0.1:8200/v1/sys/internal/ui/namespaces ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/internal-ui-resultant-acl.mdx b/website/content/api-docs/system/internal-ui-resultant-acl.mdx index c519c4448315..d2990a9cef8e 100644 --- a/website/content/api-docs/system/internal-ui-resultant-acl.mdx +++ b/website/content/api-docs/system/internal-ui-resultant-acl.mdx @@ -13,7 +13,7 @@ to the UI so that it can change its behavior in response. This is currently only being used internally for the UI. Due to the nature of its intended usage, there is no guarantee on backwards compatibility for this endpoint. -## Get Resultant-acl +## Get resultant-acl This endpoint lists the resultant-acl relevant to the UI. @@ -21,14 +21,14 @@ This endpoint lists the resultant-acl relevant to the UI. | :----- | :------------------------------- | | `GET` | `/sys/internal/ui/resultant-acl` | -### Sample Request +### Sample request ```shell-session $ curl \ http://127.0.0.1:8200/v1/sys/internal/ui/resultant-acl ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/key-status.mdx b/website/content/api-docs/system/key-status.mdx index 0ead6ea9bbf1..77518eaece3a 100644 --- a/website/content/api-docs/system/key-status.mdx +++ b/website/content/api-docs/system/key-status.mdx @@ -11,7 +11,7 @@ description: |- The `/sys/key-status` endpoint is used to query info about the current encryption key of Vault. -## Get Encryption Key Status +## Get encryption key status This endpoint returns information about the current encryption key used by Vault. @@ -20,7 +20,7 @@ Vault. | :----- | :---------------- | | `GET` | `/sys/key-status` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -30,7 +30,7 @@ $ curl \ ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/leader.mdx b/website/content/api-docs/system/leader.mdx index 814207239297..e7717859aad1 100644 --- a/website/content/api-docs/system/leader.mdx +++ b/website/content/api-docs/system/leader.mdx @@ -11,7 +11,7 @@ description: |- The `/sys/leader` endpoint is used to check the high availability status and current leader of Vault. -## Read Leader Status +## Read leader status This endpoint returns the high availability status and current leader instance of Vault. @@ -20,14 +20,14 @@ of Vault. | :----- | :------------ | | `GET` | `/sys/leader` | -### Sample Request +### Sample request ```shell-session $ curl \ http://127.0.0.1:8200/v1/sys/leader ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/lease-count-quotas.mdx b/website/content/api-docs/system/lease-count-quotas.mdx index 66d588f7f15f..bb2458a1cfb8 100644 --- a/website/content/api-docs/system/lease-count-quotas.mdx +++ b/website/content/api-docs/system/lease-count-quotas.mdx @@ -10,7 +10,7 @@ description: The `/sys/quotas/lease-count` endpoint is used to create, edit and The `/sys/quotas/lease-count` endpoint is used to create, edit and delete lease count quotas. -## Create or Update a Lease Count Quota +## Create or update a lease count quota This endpoint is used to create a lease count quota with an identifier, `name`. A lease count quota must include a `max_leases` value with an optional `path` @@ -50,7 +50,7 @@ millions of leases in an automated way, it is recommended to space out the creat requests to that mount that are made with the specified role. The request will fail if the auth mount does not have a concept of roles, or `path` is not an auth mount. -### Sample Payload +### Sample payload ```json { @@ -59,7 +59,7 @@ millions of leases in an automated way, it is recommended to space out the creat } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -69,7 +69,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/quotas/lease-count/global-lease-count-quota ``` -## Delete a Lease Count Quota +## Delete a lease count quota A lease count quota can be deleted by `name`. @@ -77,7 +77,7 @@ A lease count quota can be deleted by `name`. | :------- | :------------------------------ | | `DELETE` | `/sys/quotas/lease-count/:name` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -86,7 +86,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/quotas/lease-count/global-lease-count-quota ``` -## Get a Lease Count Quota +## Get a lease count quota A lease count quota can be retrieved by `name`. @@ -94,7 +94,7 @@ A lease count quota can be retrieved by `name`. | :----- | :------------------------------ | | `GET` | `/sys/quotas/lease-count/:name` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -103,7 +103,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/quotas/lease-count/global-lease-count-quota ``` -### Sample Response +### Sample response ```json { @@ -122,7 +122,7 @@ $ curl \ } ``` -## List Lease Count Quotas +## List lease count quotas This endpoint returns a list of all the lease count quotas. A 404 response will be returned if no lease count quota has been created. @@ -131,7 +131,7 @@ be returned if no lease count quota has been created. | :----- | :------------------------ | | `LIST` | `/sys/quotas/lease-count` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -140,7 +140,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/quotas/lease-count ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/leases.mdx b/website/content/api-docs/system/leases.mdx index 2554fec6a3d2..a8a2f8938941 100644 --- a/website/content/api-docs/system/leases.mdx +++ b/website/content/api-docs/system/leases.mdx @@ -8,7 +8,7 @@ description: The `/sys/leases` endpoints are used to view and manage leases. The `/sys/leases` endpoints are used to view and manage leases in Vault. -## Read Lease +## Read lease This endpoint retrieve lease metadata. @@ -20,7 +20,7 @@ This endpoint retrieve lease metadata. - `lease_id` `(string: )` – Specifies the ID of the lease to lookup. -### Sample Payload +### Sample payload ```json { @@ -28,7 +28,7 @@ This endpoint retrieve lease metadata. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -38,7 +38,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/leases/lookup ``` -### Sample Response +### Sample response ```json { @@ -51,7 +51,7 @@ $ curl \ } ``` -## List Leases +## List leases This endpoint returns a list of lease ids. @@ -61,7 +61,7 @@ This endpoint returns a list of lease ids. | :----- | :--------------------------- | | `LIST` | `/sys/leases/lookup/:prefix` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -70,7 +70,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/leases/lookup/aws/creds/deploy/ ``` -### Sample Response +### Sample response ```json { @@ -80,7 +80,7 @@ $ curl \ } ``` -## Renew Lease +## Renew lease This endpoint renews a lease, requesting to extend the lease. Token leases cannot be renewed using this endpoint, use instead the auth/token/renew endpoint. @@ -99,7 +99,7 @@ cannot be renewed using this endpoint, use instead the auth/token/renew endpoint - `increment` `(int: 0)` – Specifies the requested amount of time (in seconds) to extend the lease. -### Sample Payload +### Sample payload ```json { @@ -108,7 +108,7 @@ cannot be renewed using this endpoint, use instead the auth/token/renew endpoint } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -118,7 +118,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/leases/renew ``` -### Sample Response +### Sample response ```json { @@ -128,7 +128,7 @@ $ curl \ } ``` -## Revoke Lease +## Revoke lease This endpoint revokes a lease immediately. @@ -146,7 +146,7 @@ This endpoint revokes a lease immediately. revocation, sync=true will revoke the lease immediately and only return once complete. -### Sample Payload +### Sample payload ```json { @@ -154,7 +154,7 @@ This endpoint revokes a lease immediately. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -164,7 +164,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/leases/revoke ``` -## Revoke Force +## Revoke force This endpoint revokes all secrets or tokens generated under a given prefix immediately. Unlike `/sys/leases/revoke-prefix`, this path ignores backend errors @@ -187,7 +187,7 @@ this endpoint should be tightly controlled. - `prefix` `(string: )` – Specifies the prefix to revoke. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -196,7 +196,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/leases/revoke-force/aws/creds ``` -## Revoke Prefix +## Revoke prefix This endpoint revokes all secrets (via a lease ID prefix) or tokens (via the tokens' path property) generated under a given prefix immediately. This requires @@ -217,7 +217,7 @@ used to revoke very large numbers of secrets/tokens at once. revocations, sync=true will revoke ths leases immediately and only return once complete. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -226,7 +226,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/leases/revoke-prefix/aws/creds ``` -## Tidy Leases +## Tidy leases This endpoint cleans up the dangling storage entries for leases: for each lease entry in storage, Vault will verify that it has an associated valid non-expired @@ -240,7 +240,7 @@ used sparingly. | :----- | :----------------- | | `POST` | `/sys/leases/tidy` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -249,7 +249,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/leases/tidy ``` -## Lease Counts +## Lease counts This endpoint returns the total count of a `type` of lease, as well as a count per mount point. Note that it currently only supports type "irrevocable". @@ -269,7 +269,7 @@ This endpoint was added in Vault 1.8. | :----- | :------------------ | | `GET` | `/sys/leases/count` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -279,7 +279,7 @@ $ curl \ -d type=irrevocable ``` -## Leases List +## Leases list This endpoint returns the total count of a `type` of lease, as well as a list of leases per mount point. Note that it currently only supports type @@ -304,7 +304,7 @@ This endpoint was added in Vault 1.8. | :----- | :------------ | | `GET` | `/sys/leases` | -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/system/license.mdx b/website/content/api-docs/system/license.mdx index 45520e819d72..2cba6033b885 100644 --- a/website/content/api-docs/system/license.mdx +++ b/website/content/api-docs/system/license.mdx @@ -13,7 +13,7 @@ description: |- The `/sys/license/status` endpoint is used to view update the license used in Vault. -## License Status +## License status This endpoint returns information about licensing. See [license autoloading](/vault/docs/enterprise/license/autoloading) for additional background. @@ -33,7 +33,7 @@ In the response: | :----- | :-------------------- | | `GET` | `/sys/license/status` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -41,7 +41,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/license/status ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/loggers.mdx b/website/content/api-docs/system/loggers.mdx index 3647701409db..6275e1ae3326 100644 --- a/website/content/api-docs/system/loggers.mdx +++ b/website/content/api-docs/system/loggers.mdx @@ -23,7 +23,7 @@ environment variable once the Vault service is reloaded or restarted. - `level` `(string: )` – Specifies the log verbosity level to be set for all loggers. Supported values (in order of detail) are `"trace"`, `"debug"`, `"info"`, `"warn"`, and `"error"`. -### Sample Payload +### Sample payload ```json { @@ -31,7 +31,7 @@ Supported values (in order of detail) are `"trace"`, `"debug"`, `"info"`, `"warn } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -53,7 +53,7 @@ $ curl \ - `level` `(string: )` – Specifies the log verbosity level to be set for the provided logger. Supported values (in order of detail) are `"trace"`, `"debug"`, `"info"`, `"warn"`, and `"error"`. -### Sample Payload +### Sample payload ```json { @@ -61,7 +61,7 @@ Supported values (in order of detail) are `"trace"`, `"debug"`, `"info"`, `"warn } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -77,7 +77,7 @@ $ curl \ | :----- | :------------- | | `GET` | `/sys/loggers` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -85,7 +85,7 @@ $ curl \ https://127.0.0.1:8200/v1/sys/loggers ``` -### Sample Response +### Sample response ```json { @@ -101,7 +101,7 @@ $ curl \ | :----- | :------------------- | | `GET` | `/sys/loggers/:name` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -109,7 +109,7 @@ $ curl \ https://127.0.0.1:8200/v1/sys/loggers/core ``` -### Sample Response +### Sample response ```json { @@ -123,7 +123,7 @@ $ curl \ | :-------- | :------------- | | `DELETE` | `/sys/loggers` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -142,7 +142,7 @@ $ curl \ - `name` `(string: )` – Specifies the logger to be modified (e.g. `audit`, `core`, `expiration`). -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/system/managed-keys.mdx b/website/content/api-docs/system/managed-keys.mdx index 762b2a181114..350e7d8764a6 100644 --- a/website/content/api-docs/system/managed-keys.mdx +++ b/website/content/api-docs/system/managed-keys.mdx @@ -21,7 +21,7 @@ This endpoint lists all the Managed Keys of a certain type within the namespace. - `type` `(string: )` – The backend type of keys to be listed. Supported options are `pkcs11`, `awskms` and `azurekeyvault`. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -30,7 +30,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/managed-keys/pkcs11 ``` -### Sample Response +### Sample response ```json { @@ -51,7 +51,7 @@ the namespace. |:-------|:--------------------------------| | `POST` | `/sys/managed-keys/:type/:name` | -### Sample Payload +### Sample payload ```json { @@ -63,7 +63,7 @@ the namespace. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -73,7 +73,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/managed-keys/pkcs11/hsm-key1 ``` -### Generic Parameters +### Generic parameters - `name` `(string: )` - A unique lowercase name that serves as identifying the key. Must be unique throughout all types in the namespace. @@ -97,7 +97,7 @@ $ curl \ - `usages` `(comma-delimited string: "sign,verify")` - A comma-delimited list of the allowed usages of this key. Valid values are encrypt, decrypt, sign, verify, wrap, unwrap, mac, and random. -#### PKCS#11 backend Parameters +#### PKCS#11 backend parameters ~> NOTE: The `pkcs11` backend is only available with Vault Enterprise Plus (HSMs) edition @@ -160,7 +160,7 @@ $ curl \ - `max_parallel` `(int: 1)` - The number of concurrent requests that may be in flight to the HSM at any given time. -#### AWS KMS Parameters +#### AWS KMS parameters - `type` `(string: "awskms")` - To select an AWS KMS backend, the type parameter must be set to `awskms`. - `access_key` `(string: )`: The AWS access key to use. This may also be provided in @@ -198,7 +198,7 @@ $ curl \ the `AWS_SECRET_ACCESS_KEY` environment variable or as part of the AWS profile from the AWS CLI or instance profile. -#### Azure Key Vault Parameters +#### Azure key Vault parameters - `type` `(string: "azurekeyvault")` - To select an Azure Key Vault backend, the type parameter must be set to `azurekeyvault`. - `tenant_id` `(string: )`: The tenant id for the Azure Active Directory organization. @@ -223,7 +223,7 @@ $ curl \ - `key_type` `(string: )`: The type of key to use. At this time only supported value is `RSA-HSM`. -#### GCP Cloud KMS Parameters +#### GCP Cloud KMS parameters - `type` `(string: "gcpckms")` - To select an GCP Cloud KMS backend, the type parameter must be set to `gcpckms`. - `credentials` `(string: )`: The path of the credential file to use for authenticating to GCP. @@ -271,7 +271,7 @@ This endpoint returns the managed key configuration at the given path. - `type` `(string: )` – The backend type for the managed key. Supported options are `pkcs11`, `awskms` and `azurekeyvault`. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -279,7 +279,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/managed-keys/pkcs11/hsm-key1 ``` -### Sample Response +### Sample response ```json { @@ -302,7 +302,7 @@ $ curl \ } ``` -## Test Sign with a managed key +## Test sign with a managed key This endpoint allows an operator to validate that a managed key configuration works by signing and verifying some randomly generated data. If the call returns a successful HTTP @@ -333,7 +333,7 @@ status code, the configuration can be considered valid. - sha3-384 - sha3-512 -### Sample Request +### Sample request ```shell-session $ curl \ @@ -357,7 +357,7 @@ listed within any mount point's `allowed_managed_keys`. - `type` `(string: )` – The backend type for the managed key. Supported options are `pkcs11`, `awskms` and `azurekeyvault`. -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/system/metrics.mdx b/website/content/api-docs/system/metrics.mdx index b1c9a788bfb2..bafea41c0fbb 100644 --- a/website/content/api-docs/system/metrics.mdx +++ b/website/content/api-docs/system/metrics.mdx @@ -8,7 +8,7 @@ description: The `/sys/metrics` endpoint is used to get telemetry metrics for Va The `/sys/metrics` endpoint is used to get telemetry metrics for Vault. -## Read Telemetry Metrics +## Read telemetry metrics This endpoint returns the telemetry metrics for Vault. It can be used by metrics collections systems like [Prometheus](https://prometheus.io) that use a pull @@ -24,7 +24,7 @@ model for metrics collection. default metrics format is JSON. Setting `format` to `prometheus` will return the metrics in [Prometheus format](https://prometheus.io/docs/instrumenting/exposition_formats/#text-based-format). -### Sample Request +### Sample request ```shell-session $ curl \ @@ -32,7 +32,7 @@ $ curl \ 'http://127.0.0.1:8200/v1/sys/metrics?format=prometheus' ``` -### Sample Response +### Sample response This response is only returned for a `GET` request. diff --git a/website/content/api-docs/system/mfa/duo.mdx b/website/content/api-docs/system/mfa/duo.mdx index 9a944de4ac76..26a95a100840 100644 --- a/website/content/api-docs/system/mfa/duo.mdx +++ b/website/content/api-docs/system/mfa/duo.mdx @@ -6,7 +6,7 @@ description: >- Vault Enterprise. --- -## Configure Duo MFA Method +## Configure Duo MFA method This endpoint defines a MFA method of type Duo. @@ -35,7 +35,7 @@ This endpoint defines a MFA method of type Duo. - `push_info` `(string)` - Push information for Duo. -### Sample Payload +### Sample payload ```json { @@ -46,7 +46,7 @@ This endpoint defines a MFA method of type Duo. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -56,7 +56,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/mfa/method/duo/my_duo ``` -## Read Duo MFA Method +## Read Duo MFA method This endpoint queries the MFA configuration of Duo type for a given method name. @@ -69,7 +69,7 @@ name. - `name` `(string: )` – Name of the MFA method. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -79,7 +79,7 @@ $ curl \ ``` -### Sample Response +### Sample response ```json { @@ -97,7 +97,7 @@ $ curl \ } ``` -## Delete Duo MFA Method +## Delete Duo MFA method This endpoint deletes a Duo MFA method. @@ -109,7 +109,7 @@ This endpoint deletes a Duo MFA method. - `name` `(string: )` - Name of the MFA method. -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/system/mfa/index.mdx b/website/content/api-docs/system/mfa/index.mdx index d44e99215fe4..cd07b63e0d83 100644 --- a/website/content/api-docs/system/mfa/index.mdx +++ b/website/content/api-docs/system/mfa/index.mdx @@ -21,7 +21,7 @@ behaviors in Vault Enterprise MFA. - [PingID](/vault/api-docs/system/mfa/pingid) -## Step-up Enterprise MFA +## Step-up enterprise MFA [Vault Enterprise](/vault/docs/enterprise/mfa) allows MFA for login and access to sensitive resources in Vault. The Step-up Enterprise MFA expects the method diff --git a/website/content/api-docs/system/mfa/okta.mdx b/website/content/api-docs/system/mfa/okta.mdx index 436c14b1da39..48503a79c736 100644 --- a/website/content/api-docs/system/mfa/okta.mdx +++ b/website/content/api-docs/system/mfa/okta.mdx @@ -6,7 +6,7 @@ description: >- Vault Enterprise. --- -## Configure Okta MFA Method +## Configure okta MFA method This endpoint defines a MFA method of type Okta. @@ -35,7 +35,7 @@ This endpoint defines a MFA method of type Okta. - `primary_email` `(bool: false)` - If set, the username will only match the primary email for the account. -### Sample Payload +### Sample payload ```json { @@ -45,7 +45,7 @@ This endpoint defines a MFA method of type Okta. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -55,7 +55,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/mfa/method/okta/my_okta ``` -## Read Okta MFA Method +## Read okta MFA method This endpoint queries the MFA configuration of Okta type for a given method name. @@ -68,7 +68,7 @@ name. - `name` `(string: )` – Name of the MFA method. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -78,7 +78,7 @@ $ curl \ ``` -### Sample Response +### Sample response ```json { @@ -95,7 +95,7 @@ $ curl \ } ``` -## Delete Okta MFA Method +## Delete okta MFA method This endpoint deletes a Okta MFA method. @@ -107,7 +107,7 @@ This endpoint deletes a Okta MFA method. - `name` `(string: )` - Name of the MFA method. -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/system/mfa/pingid.mdx b/website/content/api-docs/system/mfa/pingid.mdx index 265eac73eb75..32b5ee69a3a1 100644 --- a/website/content/api-docs/system/mfa/pingid.mdx +++ b/website/content/api-docs/system/mfa/pingid.mdx @@ -6,7 +6,7 @@ description: >- in Vault Enterprise. --- -## Configure PingID MFA Method +## Configure PingID MFA method This endpoint defines a MFA method of type PingID. @@ -29,7 +29,7 @@ This endpoint defines a MFA method of type PingID. - `settings_file_base64` `(string)` - A base64-encoded third-party settings file retrieved from PingID's configuration page. -### Sample Payload +### Sample payload ```json { @@ -38,7 +38,7 @@ This endpoint defines a MFA method of type PingID. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -48,7 +48,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/mfa/method/pingid/ping ``` -## Read PingiD MFA Method +## Read PingiD MFA method This endpoint queries the MFA configuration of PingID type for a given method name. @@ -61,7 +61,7 @@ name. - `name` `(string: )` – Name of the MFA method. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -71,7 +71,7 @@ $ curl \ ``` -### Sample Response +### Sample response ```json { @@ -89,7 +89,7 @@ $ curl \ } ``` -## Delete PingID MFA Method +## Delete PingID MFA method This endpoint deletes a PingID MFA method. @@ -101,7 +101,7 @@ This endpoint deletes a PingID MFA method. - `name` `(string: )` - Name of the MFA method. -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/system/mfa/totp.mdx b/website/content/api-docs/system/mfa/totp.mdx index 092f27cea601..e1f52d53d676 100644 --- a/website/content/api-docs/system/mfa/totp.mdx +++ b/website/content/api-docs/system/mfa/totp.mdx @@ -6,7 +6,7 @@ description: >- Vault Enterprise. --- -## Configure TOTP MFA Method +## Configure TOTP MFA method This endpoint defines a MFA method of type TOTP. @@ -34,7 +34,7 @@ This endpoint defines a MFA method of type TOTP. - `max_validation_attempts` `(int: 5)` - The maximum number of consecutive TOTP code failed validation. -### Sample Payload +### Sample payload ```json { @@ -42,7 +42,7 @@ This endpoint defines a MFA method of type TOTP. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -52,7 +52,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/mfa/method/totp/my_totp ``` -## Read TOTP MFA Method +## Read TOTP MFA method This endpoint queries the MFA configuration of TOTP type for a given method name. @@ -65,7 +65,7 @@ name. - `name` `(string: )` – Name of the MFA method. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -75,7 +75,7 @@ $ curl \ ``` -### Sample Response +### Sample response ```json { @@ -95,7 +95,7 @@ $ curl \ } ``` -## Delete TOTP MFA Method +## Delete TOTP MFA method This endpoint deletes a TOTP MFA method. @@ -107,7 +107,7 @@ This endpoint deletes a TOTP MFA method. - `name` `(string: )` - Name of the MFA method. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -117,7 +117,7 @@ $ curl \ ``` -## Generate a TOTP MFA Secret +## Generate a TOTP MFA secret This endpoint generates an MFA secret in the entity of the calling token, if it doesn't exist already, using the configuration stored under the given MFA @@ -131,7 +131,7 @@ method name. - `name` `(string: )` - Name of the MFA method. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -140,7 +140,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/mfa/method/totp/my_totp/generate ``` -### Sample Response +### Sample response ```json { @@ -151,7 +151,7 @@ $ curl \ } ``` -## Administratively Generate a TOTP MFA Secret +## Administratively generate a TOTP MFA secret This endpoint can be used to generate a TOTP MFA secret. Unlike the `generate` API which stores the generated secret on the entity ID of the calling token, @@ -168,7 +168,7 @@ the `admin-generate` API stores the generated secret on the given entity ID. - `entity_id` `(string: )` - Entity ID on which the generated secret needs to get stored. -### Sample Payload +### Sample payload ```json { @@ -176,7 +176,7 @@ the `admin-generate` API stores the generated secret on the given entity ID. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -186,7 +186,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/mfa/method/totp/my_totp/admin-generate ``` -### Sample Response +### Sample response ```json { @@ -197,7 +197,7 @@ $ curl \ } ``` -### Administratively Destroy TOTP MFA Secret +### Administratively destroy TOTP MFA secret This endpoint deletes a TOTP MFA secret from the given entity ID. @@ -217,7 +217,7 @@ secret. - `entity_id` `(string: )` - Entity ID from which the MFA secret should be removed. -### Sample Payload +### Sample payload ```json { @@ -225,7 +225,7 @@ secret. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/system/mfa/validate.mdx b/website/content/api-docs/system/mfa/validate.mdx index 046789eae223..52e3c3c19fe5 100644 --- a/website/content/api-docs/system/mfa/validate.mdx +++ b/website/content/api-docs/system/mfa/validate.mdx @@ -6,7 +6,7 @@ description: >- If validation succeeds, it returns an auth response which includes a client token. --- -## Validate Login MFA Request +## Validate login MFA request This endpoint validates a login request which is subject to MFA validation. @@ -24,7 +24,7 @@ MFA methodIDs are UUID strings which are used as keys of the map. The values of string slices. In cases where an MFA method is configured not to use passcodes, the passcode remains an empty string. -### Sample Payload +### Sample payload ```json { @@ -46,7 +46,7 @@ In versions 1.12.x and below,`passcode=` was used for Duo MFA only. Starting in } } -### Sample Request +### Sample request ```shell-session $ curl \ @@ -55,7 +55,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/mfa/validate ``` -### Sample Response +### Sample response In cases where MFA validation fails, a 403 status code is returned with the details about the error. diff --git a/website/content/api-docs/system/monitor.mdx b/website/content/api-docs/system/monitor.mdx index 377c22cac4bc..35579a14e993 100644 --- a/website/content/api-docs/system/monitor.mdx +++ b/website/content/api-docs/system/monitor.mdx @@ -29,7 +29,7 @@ default, this is text. - `log_format` `(string: "standard")` – Specifies the log format to emit when streaming logs. Supported values are "standard" and "json". The default is `standard`, if not specified. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -37,7 +37,7 @@ $ curl \ 'http://127.0.0.1:8200/v1/sys/monitor?log_level=debug' ``` -### Sample Response +### Sample response ``` 2020-09-15T11:28:09.188-0700 [INFO] core: successful mount: namespace= path=foo/ type=kv diff --git a/website/content/api-docs/system/mounts.mdx b/website/content/api-docs/system/mounts.mdx index 55d64f9e5835..8ecf1c387776 100644 --- a/website/content/api-docs/system/mounts.mdx +++ b/website/content/api-docs/system/mounts.mdx @@ -8,7 +8,7 @@ description: The `/sys/mounts` endpoint is used to manage secrets engines in Vau The `/sys/mounts` endpoint is used to manage secrets engines in Vault. -## List Mounted Secrets Engines +## List mounted secrets engines This endpoints lists all the mounted secrets engines. @@ -16,7 +16,7 @@ This endpoints lists all the mounted secrets engines. | :----- | :------------ | | `GET` | `/sys/mounts` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -24,7 +24,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/mounts ``` -### Sample Response +### Sample response ```json { @@ -117,7 +117,7 @@ $ curl \ `default_lease_ttl` or `max_lease_ttl` values of 0 mean that the system defaults are used by this backend. -## Enable Secrets Engine +## Enable secrets engine This endpoint enables a new secrets engine at the given path. @@ -192,7 +192,7 @@ relevant functionality is only supported in Vault Enterprise: - `external_entropy_access` `(bool: false)` - Enable the secrets engine to access Vault's external entropy source. -### Sample Payload +### Sample payload ```json { @@ -203,7 +203,7 @@ relevant functionality is only supported in Vault Enterprise: } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -213,7 +213,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/mounts/my-mount ``` -## Disable Secrets Engine +## Disable secrets engine This endpoint disables the mount point specified in the URL. @@ -221,7 +221,7 @@ This endpoint disables the mount point specified in the URL. | :------- | :------------------ | ------------------ | | `DELETE` | `/sys/mounts/:path` | `204 (empty body)` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -230,7 +230,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/mounts/my-mount ``` -### Force Disable +### Force disable Because disabling a secrets engine revokes secrets associated with this mount, possible errors can prevent the secrets engine from being disabled if the @@ -247,7 +247,7 @@ on the mount prefix, followed by a secrets disable when that completes. If the underlying secrets were not manually cleaned up, this method might result in dangling credentials. This is meant for extreme circumstances. -## Get the configuration of a Secret Engine +## Get the configuration of a secret engine This endpoint returns the configuration of a specific secret engine. @@ -255,7 +255,7 @@ This endpoint returns the configuration of a specific secret engine. | :----- | :------------------ | | `GET` | `/sys/mounts/:path` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -263,7 +263,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/mounts/cubbyhole ``` -### Sample Response +### Sample response ```json { @@ -308,7 +308,7 @@ $ curl \ } ``` -## Read Mount Configuration +## Read mount configuration This endpoint reads the given mount's configuration. Unlike the `mounts` endpoint, this will return the current time in seconds for each TTL, which may @@ -318,7 +318,7 @@ be the system default or a mount-specific value. | :----- | :----------------------- | | `GET` | `/sys/mounts/:path/tune` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -326,7 +326,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/mounts/my-mount/tune ``` -### Sample Response +### Sample response ```json { @@ -336,7 +336,7 @@ $ curl \ } ``` -## Tune Mount Configuration +## Tune mount configuration This endpoint tunes configuration parameters for a given mount point. @@ -379,7 +379,7 @@ This endpoint tunes configuration parameters for a given mount point. - `plugin_version` `(string: "")` – Specifies the semantic version of the plugin to use, e.g. "v1.0.0". Changes will not take effect until the mount is reloaded. -### Sample Payload +### Sample payload ```json { @@ -388,7 +388,7 @@ This endpoint tunes configuration parameters for a given mount point. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/system/namespaces.mdx b/website/content/api-docs/system/namespaces.mdx index a00961e11193..84fc6d5d1a83 100644 --- a/website/content/api-docs/system/namespaces.mdx +++ b/website/content/api-docs/system/namespaces.mdx @@ -8,7 +8,7 @@ description: The `/sys/namespaces` endpoint is used manage namespaces in Vault. The `/sys/namespaces` endpoint is used manage namespaces in Vault. -## List Namespaces +## List namespaces This endpoints lists all the namespaces. @@ -16,7 +16,7 @@ This endpoints lists all the namespaces. | :----- | :---------------- | | `LIST` | `/sys/namespaces` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -25,7 +25,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/namespaces ``` -### Sample Response +### Sample response ```json { @@ -50,7 +50,7 @@ $ curl \ } ``` -## Create Namespace +## Create namespace This endpoint creates a namespace at the given path. @@ -65,7 +65,7 @@ This endpoint creates a namespace at the given path. - `custom_metadata` `(map: nil)` - A map of arbitrary string to string valued user-provided metadata meant to describe the namespace. -### Sample Payload +### Sample payload ```json { @@ -76,7 +76,7 @@ This endpoint creates a namespace at the given path. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -86,7 +86,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/namespaces/ns1 ``` -## Patch Namespace +## Patch namespace This endpoint patches an existing namespace at the specified path. @@ -100,7 +100,7 @@ This endpoint patches an existing namespace at the specified path. - `custom_metadata` `(map: nil)` - A map of arbitrary string to string valued user-provided metadata meant to describe the namespace. -### Sample Payload +### Sample payload ```json { @@ -111,7 +111,7 @@ This endpoint patches an existing namespace at the specified path. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -122,7 +122,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/namespaces/ns1 ``` -## Delete Namespace +## Delete namespace This endpoint deletes a namespace at the specified path. @@ -130,7 +130,7 @@ This endpoint deletes a namespace at the specified path. | :------- | :---------------------- | | `DELETE` | `/sys/namespaces/:path` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -139,7 +139,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/namespaces/ns1 ``` -## Read Namespace Information +## Read namespace information This endpoint gets the metadata for the given namespace path. @@ -147,7 +147,7 @@ This endpoint gets the metadata for the given namespace path. | :----- | :---------------------- | | `GET` | `/sys/namespaces/:path` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -155,7 +155,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/namespaces/ns1 ``` -### Sample Response +### Sample response ```json { @@ -168,7 +168,7 @@ $ curl \ } ``` -## Lock Namespace +## Lock namespace This endpoint locks the API for the current namespace path or optional subpath. The behavior when interacting with Vault from a locked namespace is described in @@ -178,7 +178,7 @@ The behavior when interacting with Vault from a locked namespace is described in | :----- | :---------------------- | | `POST` | `/sys/namespaces/api-lock/lock/:subpath` | -### Sample Request - Current Namespace +### Sample request - current namespace ```shell-session $ curl \ @@ -187,7 +187,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/namespaces/api-lock/lock ``` -### Sample Response - Current Namespace +### Sample response - current namespace ```json { @@ -195,7 +195,7 @@ $ curl \ } ``` -### Sample Request - X-Vault-Namespace +### Sample request - X-Vault-Namespace ```shell-session $ curl \ @@ -205,7 +205,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/namespaces/api-lock/lock ``` -### Sample Response - X-Vault-Namespace +### Sample response - X-Vault-Namespace ```json { @@ -213,7 +213,7 @@ $ curl \ } ``` -### Sample Request - Descendant of Current Namespace +### Sample request - descendant of current namespace ```shell-session $ curl \ @@ -222,7 +222,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/namespaces/api-lock/lock/some/descendant/subpath ``` -### Sample Response - Descendant of Current Namespace +### Sample response - descendant of current namespace ```json { @@ -230,7 +230,7 @@ $ curl \ } ``` -## Unlock Namespace +## Unlock namespace This endpoint unlocks the api for the current namespace path or optional subpath. @@ -238,7 +238,7 @@ This endpoint unlocks the api for the current namespace path or optional subpath | :----- | :---------------------- | | `POST` | `/sys/namespaces/api-lock/unlock/:subpath` | -### Sample Payload - Current Namespace Non-Root +### Sample payload - current namespace Non-Root ```json { @@ -246,7 +246,7 @@ This endpoint unlocks the api for the current namespace path or optional subpath } ``` -### Sample Request - Current Namespace Non-Root +### Sample request - current namespace Non-Root ```shell-session $ curl \ @@ -256,7 +256,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/namespaces/api-lock/unlock ``` -### Sample Request - Current Namespace Root +### Sample request - current namespace root ```shell-session $ curl \ @@ -265,7 +265,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/namespaces/api-lock/unlock ``` -### Sample Payload - Descendant Namespace Non-Root +### Sample payload - descendant namespace Non-Root ```json { @@ -273,7 +273,7 @@ $ curl \ } ``` -### Sample Request - Descendant Namespace Non-Root +### Sample request - descendant namespace Non-Root ```shell-session $ curl \ diff --git a/website/content/api-docs/system/plugins-catalog.mdx b/website/content/api-docs/system/plugins-catalog.mdx index d21aba49af29..10e6c1ecf139 100644 --- a/website/content/api-docs/system/plugins-catalog.mdx +++ b/website/content/api-docs/system/plugins-catalog.mdx @@ -10,7 +10,7 @@ The `/sys/plugins/catalog` endpoint is used to read, register, update, and remove plugins in Vault's catalog. Plugins must be registered before use, and once registered backends can use the plugin by querying the catalog. -## LIST Plugins +## LIST plugins This endpoint lists the plugins in the catalog by type. @@ -18,7 +18,7 @@ This endpoint lists the plugins in the catalog by type. | :----- | :--------------------- | | `GET` | `/sys/plugins/catalog` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -26,7 +26,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/plugins/catalog ``` -### Sample Response +### Sample response ```json { @@ -81,7 +81,7 @@ $ curl \ } ``` -## LIST Plugins +## LIST plugins This endpoint lists the plugins in the catalog by type. @@ -91,7 +91,7 @@ This endpoint lists the plugins in the catalog by type. | `LIST` | `/sys/plugins/catalog/database` | | `LIST` | `/sys/plugins/catalog/secret` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -100,7 +100,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/plugins/catalog/auth ``` -### Sample Response +### Sample response ```json { @@ -116,7 +116,7 @@ $ curl \ } ``` -## Register Plugin +## Register plugin This endpoint registers a new plugin, or updates an existing one with the supplied name. @@ -154,7 +154,7 @@ supplied name. execution of the plugin. Each entry is of the form "key=value". e.g `"FOO=BAR"`. -### Sample Payload +### Sample payload ```json { @@ -163,7 +163,7 @@ supplied name. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -173,7 +173,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/plugins/catalog/secret/example-plugin ``` -## Read Plugin +## Read plugin This endpoint returns the configuration data for the plugin with the given name. @@ -195,7 +195,7 @@ This endpoint returns the configuration data for the plugin with the given name. - `version` `(string: "")` – The semantic version of the plugin to read. Required if the plugin was registered with a version. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -204,7 +204,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/plugins/catalog/secret/example-plugin?version=v1.0.0 ``` -### Sample Response +### Sample response ```json { @@ -219,7 +219,7 @@ $ curl \ } ``` -## Remove Plugin from Catalog +## Remove plugin from catalog This endpoint removes the plugin with the given name. @@ -241,7 +241,7 @@ This endpoint removes the plugin with the given name. - `version` `(string: "")` – Specifies the semantic version of the plugin to delete. -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/system/plugins-reload-backend.mdx b/website/content/api-docs/system/plugins-reload-backend.mdx index 8440a54a94f1..261371876e7b 100644 --- a/website/content/api-docs/system/plugins-reload-backend.mdx +++ b/website/content/api-docs/system/plugins-reload-backend.mdx @@ -11,7 +11,7 @@ backends. Either the plugin name (`plugin`) or the desired plugin backend mounts (`mounts`) must be provided, but not both. In the case that the plugin name is provided, all mounted paths that use that plugin backend will be reloaded. -## Reload Plugins +## Reload plugins This endpoint reloads mounted plugin backends. @@ -31,7 +31,7 @@ This endpoint reloads mounted plugin backends. plugin or mounts on this Vault instance. If 'global', will begin reloading the plugin on all instances of a cluster. -### Sample Payload +### Sample payload ```json { @@ -39,7 +39,7 @@ This endpoint reloads mounted plugin backends. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/system/policies-password.mdx b/website/content/api-docs/system/policies-password.mdx index e81fca7d2882..9e17f8403d96 100644 --- a/website/content/api-docs/system/policies-password.mdx +++ b/website/content/api-docs/system/policies-password.mdx @@ -16,7 +16,7 @@ are using for compatibility. See [Password Policies](/vault/docs/concepts/password-policies) for details of how password policies work as well as the syntax of the policies themselves. -## Create/Update Password Policy +## Create/Update password policy This endpoint adds a new or updates an existing password policy. Once a policy is updated, it takes effect immediately to all associated secret engines. @@ -40,7 +40,7 @@ generation times. base64-encoded to avoid string escaping. See [Password Policy Syntax](/vault/docs/concepts/password-policies#password-policy-syntax) for details on password policy definitions. -### Sample Payload +### Sample payload ```json { @@ -48,7 +48,7 @@ generation times. } ``` -### Sample Request +### Sample request **cURL:** @@ -77,7 +77,7 @@ rule "charset" { $ vault write sys/policies/password/my-policy policy=@my-policy.hcl ``` -## List Password Policies +## List password policies This endpoints list the password policies. @@ -86,7 +86,7 @@ This endpoints list the password policies. | `LIST` | `/sys/policies/password` | | `GET` | `/sys/policies/password?list=true` | -### Sample Request +### Sample request ```shell $ curl \ @@ -95,7 +95,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/policies/password ``` -### Sample Response +### Sample response ```json { @@ -114,7 +114,7 @@ $ curl \ } ``` -## Read Password Policy +## Read password policy This endpoint retrieves information about the named password policy. @@ -127,7 +127,7 @@ This endpoint retrieves information about the named password policy. - `name` `(string: )` – Specifies the name of the password policy to retrieve. This is specified as part of the request URL. -### Sample Request +### Sample request ```shell $ curl \ @@ -135,7 +135,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/policies/password/my-policy ``` -### Sample Response +### Sample response ```json { @@ -143,7 +143,7 @@ $ curl \ } ``` -## Delete Password Policy +## Delete password policy This endpoint deletes the password policy with the given name. This does not check if any secret engines are using it prior to deletion, so you should ensure that any engines that @@ -159,7 +159,7 @@ default behavior). - `name` `(string: )` – Specifies the name of the password policy to delete. This is specified as part of the request URL. -### Sample Request +### Sample request ```shell $ curl \ @@ -168,7 +168,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/policies/password/my-policy ``` -## Generate Password from Password Policy +## Generate password from password policy This endpoint generates a password from the specified existing password policy. @@ -181,7 +181,7 @@ This endpoint generates a password from the specified existing password policy. - `name` `(string: )` – Specifies the name of the password policy to generate a password from. This is specified as part of the request URL. -### Sample Request +### Sample request ```shell $ curl \ @@ -189,7 +189,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/policies/password/my-policy/generate ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/policies.mdx b/website/content/api-docs/system/policies.mdx index 2987cc41fbb8..21c449236cee 100644 --- a/website/content/api-docs/system/policies.mdx +++ b/website/content/api-docs/system/policies.mdx @@ -12,7 +12,7 @@ The `/sys/policies` endpoints are used to manage ACL, RGP, and EGP policies in V ~> **NOTE**: This endpoint is only available in Vault version 0.9+. Please also note that RGPs and EGPs are Vault Enterprise Premium features and the associated endpoints are not available in Vault Open Source or Vault Enterprise Pro. -## List ACL Policies +## List ACL policies This endpoint lists all configured ACL policies. @@ -20,7 +20,7 @@ This endpoint lists all configured ACL policies. | :----- | :------------------ | | `LIST` | `/sys/policies/acl` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -28,7 +28,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/policies/acl ``` -### Sample Response +### Sample response ```json { @@ -36,7 +36,7 @@ $ curl \ } ``` -## Read ACL Policy +## Read ACL policy This endpoint retrieves information about the named ACL policy. @@ -49,7 +49,7 @@ This endpoint retrieves information about the named ACL policy. - `name` `(string: )` – Specifies the name of the policy to retrieve. This is specified as part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -57,7 +57,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/policies/acl/my-policy ``` -### Sample Response +### Sample response ```json { @@ -66,7 +66,7 @@ $ curl \ } ``` -## Create/Update ACL Policy +## Create/Update ACL policy This endpoint adds a new or updates an existing ACL policy. Once a policy is updated, it takes effect immediately to all associated users. @@ -83,7 +83,7 @@ updated, it takes effect immediately to all associated users. - `policy` `(string: )` - Specifies the policy document. This can be base64-encoded to avoid string escaping. -### Sample Payload +### Sample payload ```json { @@ -91,7 +91,7 @@ updated, it takes effect immediately to all associated users. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -101,7 +101,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/policies/acl/my-policy ``` -## Delete ACL Policy +## Delete ACL policy This endpoint deletes the ACL policy with the given name. This will immediately affect all users associated with this policy. (A deleted policy set on a token @@ -116,7 +116,7 @@ acts as an empty policy.) - `name` `(string: )` – Specifies the name of the policy to delete. This is specified as part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -125,7 +125,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/policies/acl/my-policy ``` -## List RGP Policies +## List RGP policies This endpoint lists all configured RGP policies. @@ -133,7 +133,7 @@ This endpoint lists all configured RGP policies. | :----- | :------------------ | | `LIST` | `/sys/policies/rgp` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -141,7 +141,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/policies/rgp ``` -### Sample Response +### Sample response ```json { @@ -149,7 +149,7 @@ $ curl \ } ``` -## Read RGP Policy +## Read RGP policy This endpoint retrieves information about the named RGP policy. @@ -162,7 +162,7 @@ This endpoint retrieves information about the named RGP policy. - `name` `(string: )` – Specifies the name of the policy to retrieve. This is specified as part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -170,7 +170,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/policies/rgp/webapp ``` -### Sample Response +### Sample response ```json { @@ -180,7 +180,7 @@ $ curl \ } ``` -## Create/Update RGP Policy +## Create/Update RGP policy This endpoint adds a new or updates an existing RGP policy. Once a policy is updated, it takes effect immediately to all associated users. @@ -201,7 +201,7 @@ updated, it takes effect immediately to all associated users. to use. This must be one of `advisory`, `soft-mandatory`, or `hard-mandatory`. -### Sample Payload +### Sample payload ```json { @@ -210,7 +210,7 @@ updated, it takes effect immediately to all associated users. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -220,7 +220,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/policies/rgp/webapp ``` -## Delete RGP Policy +## Delete RGP policy This endpoint deletes the RGP policy with the given name. This will immediately affect all users associated with this policy. (A deleted policy set on a token @@ -235,7 +235,7 @@ acts as an empty policy.) - `name` `(string: )` – Specifies the name of the policy to delete. This is specified as part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -244,7 +244,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/policies/rgp/webapp ``` -## List EGP Policies +## List EGP policies This endpoint lists all configured EGP policies. Since EGP policies act on a path, this endpoint returns two identifiers: @@ -258,7 +258,7 @@ path, this endpoint returns two identifiers: | :----- | :------------------ | | `LIST` | `/sys/policies/egp` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -266,7 +266,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/policies/egp ``` -### Sample Response +### Sample response ```json { @@ -274,7 +274,7 @@ $ curl \ } ``` -## Read EGP Policy +## Read EGP policy This endpoint retrieves information about the named EGP policy. @@ -287,7 +287,7 @@ This endpoint retrieves information about the named EGP policy. - `name` `(string: )` – Specifies the name of the policy to retrieve. This is specified as part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -295,7 +295,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/policies/egp/breakglass ``` -### Sample Response +### Sample response ```json { @@ -306,7 +306,7 @@ $ curl \ } ``` -## Create/Update EGP Policy +## Create/Update EGP policy This endpoint adds a new or updates an existing EGP policy. Once a policy is updated, it takes effect immediately to all associated users. @@ -332,7 +332,7 @@ updated, it takes effect immediately to all associated users. characters can denote suffixes, e.g. `secret/*`; a path of `*` will affect all authenticated and login requests. -### Sample Payload +### Sample payload ```json { @@ -342,7 +342,7 @@ updated, it takes effect immediately to all associated users. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -352,7 +352,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/policies/egp/breakglass ``` -## Delete EGP Policy +## Delete EGP policy This endpoint deletes the EGP policy with the given name from all paths on which it was configured. @@ -365,7 +365,7 @@ This endpoint deletes the EGP policy with the given name from all paths on which - `name` `(string: )` – Specifies the name of the policy to delete. This is specified as part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/system/policy.mdx b/website/content/api-docs/system/policy.mdx index 525229b24415..52863af36780 100644 --- a/website/content/api-docs/system/policy.mdx +++ b/website/content/api-docs/system/policy.mdx @@ -8,7 +8,7 @@ description: The `/sys/policy` endpoint is used to manage ACL policies in Vault. The `/sys/policy` endpoint is used to manage ACL policies in Vault. -## List Policies +## List policies This endpoint lists all configured policies. @@ -16,7 +16,7 @@ This endpoint lists all configured policies. | :----- | :------------ | | `GET` | `/sys/policy` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -24,7 +24,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/policy ``` -### Sample Response +### Sample response ```json { @@ -32,7 +32,7 @@ $ curl \ } ``` -## Read Policy +## Read policy This endpoint retrieve the policy body for the named policy. @@ -45,7 +45,7 @@ This endpoint retrieve the policy body for the named policy. - `name` `(string: )` – Specifies the name of the policy to retrieve. This is specified as part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -53,7 +53,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/policy/my-policy ``` -### Sample Response +### Sample response ```json { @@ -62,7 +62,7 @@ $ curl \ } ``` -## Create/Update Policy +## Create/Update policy This endpoint adds a new or updates an existing policy. Once a policy is updated, it takes effect immediately to all associated users. @@ -78,7 +78,7 @@ updated, it takes effect immediately to all associated users. - `policy` `(string: )` - Specifies the policy document. -### Sample Payload +### Sample payload ```json { @@ -86,7 +86,7 @@ updated, it takes effect immediately to all associated users. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -96,7 +96,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/policy/my-policy ``` -## Delete Policy +## Delete policy This endpoint deletes the policy with the given name. This will immediately affect all users associated with this policy. @@ -110,7 +110,7 @@ affect all users associated with this policy. - `name` `(string: )` – Specifies the name of the policy to delete. This is specified as part of the request URL. -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/system/pprof.mdx b/website/content/api-docs/system/pprof.mdx index f2a73a5a6492..3cabbd1de25b 100644 --- a/website/content/api-docs/system/pprof.mdx +++ b/website/content/api-docs/system/pprof.mdx @@ -18,7 +18,7 @@ This endpoint returns an HTML page listing the available profiles. | :----- | :------------ | | `GET` | `/sys/pprof/` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -35,7 +35,7 @@ of the program. | :----- | :---------------- | | `GET` | `/sys/pprof/allocs` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -56,7 +56,7 @@ Vault binary. | :----- | :---------------- | | `GET` | `/sys/pprof/block` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -73,7 +73,7 @@ separated by NUL bytes. | :----- | :------------------- | | `GET` | `/sys/pprof/cmdline` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -95,7 +95,7 @@ This endpoint returns stack traces of all current goroutines. A value of `2` results in the stack traces being returned as text instead of the default pprof format. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -111,7 +111,7 @@ This endpoint returns a sampling of memory allocations of live object. | :----- | :---------------- | | `GET` | `/sys/pprof/heap` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -131,7 +131,7 @@ Vault binary. | :----- | :---------------- | | `GET` | `/sys/pprof/mutex` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -154,7 +154,7 @@ if not specified. - `seconds` `(int: 30)` - Specifies the duration to run the profiling command. This value is specified as a query parameter. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -170,7 +170,7 @@ This endpoint returns the program counters listed in the request. | :----- | :------------------ | | `GET` | `/sys/pprof/symbol` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -187,7 +187,7 @@ new OS threads. | :----- | :--------------------- | | `GET` | `/sys/pprof/threadcreate` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -211,7 +211,7 @@ specified. - `seconds` `(int: 1)` - Specifies the duration to run the tracing command. This value is specified as a query parameter. -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/system/quotas-config.mdx b/website/content/api-docs/system/quotas-config.mdx index 3761fb42ad00..1ec09b1fda92 100644 --- a/website/content/api-docs/system/quotas-config.mdx +++ b/website/content/api-docs/system/quotas-config.mdx @@ -8,7 +8,7 @@ description: The `/sys/quotas/config` endpoint is used to configure rate limit q The `/sys/quotas/config` endpoint is used to configure rate limit quotas. -## Create or Update the Rate Limit Configuration +## Create or update the rate limit configuration | Method | Path | | :----- | :------------------- | @@ -23,7 +23,7 @@ The `/sys/quotas/config` endpoint is used to configure rate limit quotas. - `enable_rate_limit_response_headers` `(bool: false)` - If set, additional rate limit quota HTTP headers will be added to responses. -### Sample Payload +### Sample payload ```json { @@ -42,7 +42,7 @@ The `/sys/quotas/config` endpoint is used to configure rate limit quotas. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -52,13 +52,13 @@ $ curl \ http://127.0.0.1:8200/v1/sys/quotas/config ``` -## Get the Rate Limit Configuration +## Get the rate limit configuration | Method | Path | | :----- | :------------------- | | `GET` | `/sys/quotas/config` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -67,7 +67,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/quotas/config ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/rate-limit-quotas.mdx b/website/content/api-docs/system/rate-limit-quotas.mdx index 5de913922862..715e4a994600 100644 --- a/website/content/api-docs/system/rate-limit-quotas.mdx +++ b/website/content/api-docs/system/rate-limit-quotas.mdx @@ -8,7 +8,7 @@ description: The `/sys/quotas/rate-limit` endpoint is used to create, edit and d The `/sys/quotas/rate-limit` endpoint is used to create, edit and delete rate limit quotas. -## Create or Update a Rate Limit Quota +## Create or update a rate limit quota This endpoint is used to create a rate limit quota with an identifier, `name`. A rate limit quota must include a `rate` value with an optional `path` that can @@ -45,7 +45,7 @@ the mount to restrict more specific API paths. requests to that mount that are made with the specified role. The request will fail if the auth mount does not have a concept of roles, or `path` is not an auth mount. -### Sample Payload +### Sample payload ```json { @@ -56,7 +56,7 @@ the mount to restrict more specific API paths. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -66,7 +66,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/quotas/rate-limit/global-rate-limiter ``` -## Delete a Rate Limit Quota +## Delete a rate limit quota A rate limit quota can be deleted by `name`. @@ -74,7 +74,7 @@ A rate limit quota can be deleted by `name`. | :------- | :----------------------------- | | `DELETE` | `/sys/quotas/rate-limit/:name` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -83,7 +83,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/quotas/rate-limit/global-rate-limiter ``` -## Get a Rate Limit Quota +## Get a rate limit quota A rate limit quota can be retrieved by `name`. @@ -91,7 +91,7 @@ A rate limit quota can be retrieved by `name`. | :----- | :----------------------------- | | `GET` | `/sys/quotas/rate-limit/:name` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -100,7 +100,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/quotas/rate-limit/global-rate-limiter ``` -### Sample Response +### Sample response ```json { @@ -121,7 +121,7 @@ $ curl \ } ``` -## List Rate Limit Quotas +## List rate limit quotas This endpoint returns a list of all the rate limit quotas. @@ -129,7 +129,7 @@ This endpoint returns a list of all the rate limit quotas. | :----- | :----------------------- | | `LIST` | `/sys/quotas/rate-limit` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -138,7 +138,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/quotas/rate-limit ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/raw.mdx b/website/content/api-docs/system/raw.mdx index a8bccb1ddf72..fa7d920895ed 100644 --- a/website/content/api-docs/system/raw.mdx +++ b/website/content/api-docs/system/raw.mdx @@ -12,7 +12,7 @@ This endpoint is off by default. See the [Vault configuration documentation](/vault/docs/configuration) to enable. -## Read Raw +## Read raw This endpoint reads the value of the key at the given path. This is the raw path in the storage backend and not the logical path that is exposed via the mount @@ -32,7 +32,7 @@ system. - `encoding` `(string: "")` - Specifies the encoding of the returned data. Defaults to no encoding. "base64" returns the value encoded in base64. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -40,7 +40,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/raw/secret/foo ``` -### Sample Response +### Sample response ```json { @@ -48,7 +48,7 @@ $ curl \ } ``` -## Create/Update Raw +## Create/Update raw This endpoint updates the value of the key at the given path. This is the raw path in the storage backend and not the logical path that is exposed via the @@ -72,7 +72,7 @@ mount system. - `encoding` `(string: "")` - Specifies the encoding of `value`. Defaults to no encoding. Use "base64" if `value` is encoded in base64. -### Sample Payload +### Sample payload ```json { @@ -80,7 +80,7 @@ mount system. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -90,7 +90,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/raw/secret/foo ``` -## List Raw +## List raw This endpoint returns a list keys for a given path prefix. @@ -101,7 +101,7 @@ This endpoint returns a list keys for a given path prefix. | `LIST` | `/sys/raw/:prefix` | | `GET` | `/sys/raw/:prefix?list=true` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -110,7 +110,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/raw/logical ``` -### Sample Response +### Sample response ```json { @@ -120,7 +120,7 @@ $ curl \ } ``` -## Delete Raw +## Delete raw This endpoint deletes the key with given path. This is the raw path in the storage backend and not the logical path that is exposed via the mount system. @@ -134,7 +134,7 @@ storage backend and not the logical path that is exposed via the mount system. - `path` `(string: )` – Specifies the raw path in the storage backend. This is specified as part of the URL. -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/system/rekey-recovery-key.mdx b/website/content/api-docs/system/rekey-recovery-key.mdx index 49b9940210d5..e38e49c87785 100644 --- a/website/content/api-docs/system/rekey-recovery-key.mdx +++ b/website/content/api-docs/system/rekey-recovery-key.mdx @@ -12,7 +12,7 @@ description: >- The `/sys/rekey-recovery-key` endpoints are used to rekey the recovery keys for Vault. -## Read Rekey Progress +## Read rekey progress This endpoint reads the configuration and progress of the current rekey attempt. @@ -20,7 +20,7 @@ This endpoint reads the configuration and progress of the current rekey attempt. | :----- | :----------------------------- | | `GET` | `/sys/rekey-recovery-key/init` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -28,7 +28,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/rekey-recovery-key/init ``` -### Sample Response +### Sample response ```json { @@ -53,7 +53,7 @@ keys will be backed up to physical storage will also be displayed. `verification_required` indicates whether verification was enabled for this operation. -## Start Rekey +## Start rekey This endpoint initializes a new rekey attempt. Only a single recovery key rekey attempt can take place at a time, and changing the parameters of a rekey @@ -94,7 +94,7 @@ nonce. returned keys can be successfully decrypted before committing to the new shares, which the backup functionality does not provide. -### Sample Payload +### Sample payload ```json { @@ -103,7 +103,7 @@ nonce. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -113,7 +113,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/rekey-recovery-key/init ``` -## Cancel Rekey +## Cancel rekey This endpoint cancels any in-progress rekey. This clears the rekey settings as well as any progress made. This must be called to change the parameters of the @@ -124,7 +124,7 @@ during the verification flow, the current unseal keys remain valid. | :------- | :----------------------------- | | `DELETE` | `/sys/rekey-recovery-key/init` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -133,7 +133,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/rekey-recovery-key/init ``` -## Read Backup Key +## Read backup key This endpoint returns the backup copy of PGP-encrypted recovery key shares. The returned value is the nonce of the rekey operation and a map of PGP key @@ -143,7 +143,7 @@ fingerprint to hex-encoded PGP-encrypted key. | :----- | :------------------------------- | | `GET` | `/sys/rekey/recovery-key-backup` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -151,7 +151,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/rekey/recovery-key-backup ``` -### Sample Response +### Sample response ```json { @@ -162,7 +162,7 @@ $ curl \ } ``` -## Delete Backup Key +## Delete backup key This endpoint deletes the backup copy of PGP-encrypted recovery key shares. @@ -170,7 +170,7 @@ This endpoint deletes the backup copy of PGP-encrypted recovery key shares. | :------- | :------------------------------- | | `DELETE` | `/sys/rekey/recovery-key-backup` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -179,7 +179,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/rekey/recovery-key-backup ``` -## Submit Key +## Submit key This endpoint is used to enter a single recovery key share to progress the rekey of the Vault. If the threshold number of recovery key shares is reached, Vault @@ -205,7 +205,7 @@ for the verification operation. - `nonce` `(string: )` – Specifies the nonce of the rekey operation. -### Sample Payload +### Sample payload ```json { @@ -214,7 +214,7 @@ for the verification operation. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -224,7 +224,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/rekey-recovery-key/update ``` -### Sample Response +### Sample response ```json { @@ -243,7 +243,7 @@ If the keys are PGP-encrypted, an array of key fingerprints will also be provided (with the order in which the keys were used for encryption) along with whether or not the keys were backed up to physical storage. -## Read Rekey Recovery Key Verification Progress +## Read rekey recovery key verification progress This endpoint reads the configuration and progress of the current rekey verification attempt. @@ -252,7 +252,7 @@ verification attempt. | :----- | :------------------------------- | | `GET` | `/sys/rekey-recovery-key/verify` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -260,7 +260,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/rekey-recovery-key/verify ``` -### Sample Response +### Sample response ```json { @@ -276,7 +276,7 @@ threshold required for the new shares to pass verification. `progress` is how many of the new unseal keys have been provided for this verification operation. The `nonce` for the current rekey operation is also displayed. -## Cancel Rekey Verification +## Cancel rekey verification This endpoint cancels any in-progress rekey verification operation. This clears any progress made and resets the nonce. Unlike a `DELETE` against @@ -288,7 +288,7 @@ along with the new nonce. | :------- | :------------------------------- | | `DELETE` | `/sys/rekey-recovery-key/verify` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -297,7 +297,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/rekey-recovery-key/verify ``` -### Sample Response +### Sample response ```json { @@ -308,7 +308,7 @@ $ curl \ } ``` -## Submit Verification Key +## Submit verification key This endpoint is used to enter a single new key share to progress the rekey verification operation. If the threshold number of new key shares is reached, @@ -332,7 +332,7 @@ below; otherwise the response will be the same as the `GET` method against - `nonce` `(string: )` – Specifies the nonce of the rekey verification operation. -### Sample Payload +### Sample payload ```json { @@ -341,7 +341,7 @@ below; otherwise the response will be the same as the `GET` method against } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -351,7 +351,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/rekey-recovery-key/verify ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/rekey.mdx b/website/content/api-docs/system/rekey.mdx index 32d3b50c8d87..4b92a07d142a 100644 --- a/website/content/api-docs/system/rekey.mdx +++ b/website/content/api-docs/system/rekey.mdx @@ -13,7 +13,7 @@ can be provided to rekey the root key since no unseal keys are available. The secret shares, secret threshold, and stored shares parameters must be set to 1. Upon successful rekey, no split unseal key shares are returned. -## Read Rekey Progress +## Read rekey progress This endpoint reads the configuration and progress of the current rekey attempt. @@ -21,7 +21,7 @@ This endpoint reads the configuration and progress of the current rekey attempt. | :----- | :---------------- | | `GET` | `/sys/rekey/init` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -29,7 +29,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/rekey/init ``` -### Sample Response +### Sample response ```json { @@ -54,7 +54,7 @@ keys will be backed up to physical storage will also be displayed. `verification_required` indicates whether verification was enabled for this operation. -## Start Rekey +## Start rekey This endpoint initializes a new rekey attempt. Only a single rekey attempt can take place at a time, and changing the parameters of a rekey requires canceling @@ -94,7 +94,7 @@ and starting a new rekey, which will also provide a new nonce. can be successfully decrypted before committing to the new shares, which the backup functionality does not provide. -### Sample Payload +### Sample payload ```json { @@ -103,7 +103,7 @@ and starting a new rekey, which will also provide a new nonce. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -113,7 +113,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/rekey/init ``` -## Cancel Rekey +## Cancel rekey This endpoint cancels any in-progress rekey. This clears the rekey settings as well as any progress made. This must be called to change the parameters of the @@ -124,7 +124,7 @@ during the verification flow, the current unseal keys remain valid. | :------- | :---------------- | | `DELETE` | `/sys/rekey/init` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -133,7 +133,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/rekey/init ``` -## Read Backup Key +## Read backup key This endpoint returns the backup copy of PGP-encrypted unseal keys. The returned value is the nonce of the rekey operation and a map of PGP key fingerprint to @@ -143,7 +143,7 @@ hex-encoded PGP-encrypted key. | :----- | :------------------ | | `GET` | `/sys/rekey/backup` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -151,7 +151,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/rekey/backup ``` -### Sample Response +### Sample response ```json { @@ -162,7 +162,7 @@ $ curl \ } ``` -## Delete Backup Key +## Delete backup key This endpoint deletes the backup copy of PGP-encrypted unseal keys. @@ -170,7 +170,7 @@ This endpoint deletes the backup copy of PGP-encrypted unseal keys. | :------- | :------------------ | | `DELETE` | `/sys/rekey/backup` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -179,7 +179,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/rekey/backup ``` -## Submit Key +## Submit key This endpoint is used to enter a single root key share to progress the rekey of the Vault. If the threshold number of root key shares is reached, Vault @@ -205,7 +205,7 @@ for the verification operation. - `nonce` `(string: )` – Specifies the nonce of the rekey operation. -### Sample Payload +### Sample payload ```json { @@ -214,7 +214,7 @@ for the verification operation. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -224,7 +224,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/rekey/update ``` -### Sample Response +### Sample response ```json { @@ -243,7 +243,7 @@ If the keys are PGP-encrypted, an array of key fingerprints will also be provided (with the order in which the keys were used for encryption) along with whether or not the keys were backed up to physical storage. -## Read Rekey Verification Progress +## Read rekey verification progress This endpoint reads the configuration and progress of the current rekey verification attempt. @@ -252,7 +252,7 @@ verification attempt. | :----- | :------------------ | | `GET` | `/sys/rekey/verify` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -260,7 +260,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/rekey/verify ``` -### Sample Response +### Sample response ```json { @@ -276,7 +276,7 @@ threshold required for the new shares to pass verification. `progress` is how many of the new unseal keys have been provided for this verification operation. The `nonce` for the current rekey operation is also displayed. -## Cancel Rekey Verification +## Cancel rekey verification This endpoint cancels any in-progress rekey verification operation. This clears any progress made and resets the nonce. Unlike a `DELETE` against @@ -288,7 +288,7 @@ nonce. | :------- | :------------------ | | `DELETE` | `/sys/rekey/verify` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -297,7 +297,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/rekey/verify ``` -### Sample Response +### Sample response ```json { @@ -308,7 +308,7 @@ $ curl \ } ``` -## Submit Verification Key +## Submit verification key This endpoint is used to enter a single new key share to progress the rekey verification operation. If the threshold number of new key shares is reached, @@ -332,7 +332,7 @@ below; otherwise the response will be the same as the `GET` method against - `nonce` `(string: )` – Specifies the nonce of the rekey verification operation. -### Sample Payload +### Sample payload ```json { @@ -341,7 +341,7 @@ below; otherwise the response will be the same as the `GET` method against } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -351,7 +351,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/rekey/verify ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/remount.mdx b/website/content/api-docs/system/remount.mdx index 6e394701fa74..8fc32ebc036a 100644 --- a/website/content/api-docs/system/remount.mdx +++ b/website/content/api-docs/system/remount.mdx @@ -10,7 +10,7 @@ description: >- The Remount documentation details the endpoints required to trigger and monitor the status of a remount operation. -## Move Backend +## Move backend The `/sys/remount` endpoint moves an already-mounted backend to a new mount point. This process works for both secret engines and auth methods. @@ -35,7 +35,7 @@ depending on which type of backend is being moved. - `to` `(string: )` – Specifies the new destination mount point. -### Sample Payload ( Cross Namespace ) +### Sample payload ( cross namespace ) ```json { @@ -44,7 +44,7 @@ depending on which type of backend is being moved. } ``` -### Sample Payload ( Cross Namespace, Auth Mount ) +### Sample payload ( cross namespace, auth mount ) ```json { @@ -53,7 +53,7 @@ depending on which type of backend is being moved. } ``` -### Sample Payload ( Within Namespace ) +### Sample payload ( within namespace ) ```json { @@ -62,7 +62,7 @@ depending on which type of backend is being moved. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -72,7 +72,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/remount ``` -### Sample Response +### Sample response ```json { @@ -80,7 +80,7 @@ $ curl \ } ``` -## Monitor Migration Status +## Monitor migration status This endpoint is used to monitor the status of a mount migration operation, using the ID returned in the response of the `sys/remount` call. The response contains the passed-in ID, the source and target mounts, and a status field @@ -94,7 +94,7 @@ that displays `in-progress`, `success` or `failure`. - `migration_id` `(string: )` – Specifies the id of the mount migration -### Sample Request +### Sample request ```shell-session $ curl \ @@ -102,7 +102,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/remount/status/ef3ba21c-8be8-4e5f-8d00-cb46a532c665 ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/replication/index.mdx b/website/content/api-docs/system/replication/index.mdx index fe38e632b601..a52a89a10902 100644 --- a/website/content/api-docs/system/replication/index.mdx +++ b/website/content/api-docs/system/replication/index.mdx @@ -10,7 +10,7 @@ description: >- ~> **Enterprise Only** – These endpoints require Vault Enterprise. -## Attempt Recovery +## Attempt recovery This endpoint attempts recovery if replication is in an adverse state. For example: an error has caused replication to stop syncing. @@ -19,7 +19,7 @@ example: an error has caused replication to stop syncing. | :----- | :------------------------- | | `POST` | `/sys/replication/recover` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -28,7 +28,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/replication/recover ``` -### Sample Response +### Sample response ```json { @@ -36,7 +36,7 @@ $ curl \ } ``` -## Reindex Replication +## Reindex replication This endpoint reindexes the local data storage. This can cause a very long delay depending on the number and size of objects in the data store. @@ -61,13 +61,13 @@ depending on the number and size of objects in the data store. asynchronously flushed the reindex may not have applied fully and a new reindex may need to be done. Defaults false. -### Sample Payload +### Sample payload ```json {} ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -76,7 +76,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/replication/reindex ``` -### Sample Response +### Sample response ```json { @@ -84,7 +84,7 @@ $ curl \ } ``` -## Check Status +## Check status This endpoint print information about the status of replication (mode, sync progress, etc). @@ -95,14 +95,14 @@ This is an unauthenticated endpoint. | :----- | :------------------------ | | `GET` | `/sys/replication/status` | -### Sample Request +### Sample request ```shell-session $ curl \ http://127.0.0.1:8200/v1/sys/replication/status ``` -### Sample Response +### Sample response The printed status of the replication environment. As an example, for a performance primary and DR primary node, it will look something like: @@ -151,7 +151,7 @@ performance primary and DR primary node, it will look something like: Possible values for `connection_status` are `connected` or `disconnected`. `last_heartbeat` is the timestamp of the last time this node exchanged heartbeats with another node. -### Sample Response from Performance Secondary & DR Primary +### Sample response from performance secondary & DR primary The printed status of the replication environment. As an example, for a performance secondary and DR primary node, it will look something like: diff --git a/website/content/api-docs/system/replication/replication-dr.mdx b/website/content/api-docs/system/replication/replication-dr.mdx index e3ba21766b44..5a4a1c92568d 100644 --- a/website/content/api-docs/system/replication/replication-dr.mdx +++ b/website/content/api-docs/system/replication/replication-dr.mdx @@ -10,7 +10,7 @@ description: >- ~> **Enterprise Only** – These endpoints require Vault Enterprise. -## Check DR Status +## Check DR status This endpoint prints information about the status of replication (mode, sync progress, etc). @@ -21,14 +21,14 @@ This is an unauthenticated endpoint. | :----- | :--------------------------- | | `GET` | `/sys/replication/dr/status` | -### Sample Request +### Sample request ```shell-session $ curl \ http://127.0.0.1:8200/v1/sys/replication/dr/status ``` -### Sample Response from Primary +### Sample response from primary The printed status of the replication environment. As an example, for a primary, it will look something like: @@ -54,7 +54,7 @@ primary, it will look something like: } ``` -### Sample Response from Secondary +### Sample response from secondary The printed status of the replication environment. As an example, for a secondary, it will look something like: @@ -82,7 +82,7 @@ secondary, it will look something like: } ``` -## Enable DR Primary Replication +## Enable DR primary replication This endpoint enables DR replication in primary mode. This is used when DR replication is currently disabled on the cluster (if the cluster is already a secondary, it @@ -99,13 +99,13 @@ must be promoted). not directly accessible and must be accessed via an alternate path/address, such as through a TCP-based load balancer. -### Sample Payload +### Sample payload ```json {} ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -115,7 +115,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/replication/dr/primary/enable ``` -## Demote DR Primary +## Demote DR primary This endpoint demotes a DR primary cluster to a secondary. This DR secondary cluster will not attempt to connect to a primary (see the update-primary call), but will @@ -126,7 +126,7 @@ DR replication set without wiping local storage. | :----- | :----------------------------------- | | `POST` | `/sys/replication/dr/primary/demote` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -135,7 +135,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/replication/dr/primary/demote ``` -## Disable DR Primary +## Disable DR primary This endpoint disables DR replication entirely on the cluster. Any secondaries will no longer be able to connect. Caution: re-enabling this node as a primary or @@ -148,7 +148,7 @@ will require a wipe of the underlying storage. | :----- | :------------------------------------ | | `POST` | `/sys/replication/dr/primary/disable` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -157,7 +157,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/replication/dr/primary/disable ``` -## Generate DR Secondary Token +## Generate DR secondary token This endpoint generates a DR secondary activation token for the cluster with the given opaque identifier, which must be unique. This @@ -181,7 +181,7 @@ identifier can later be used to revoke a DR secondary's access. secondary credentials. (Vault 1.3+). Use this to avoid making an API call to the primary during secondary activation. -### Sample Payload +### Sample payload ```json { @@ -189,7 +189,7 @@ identifier can later be used to revoke a DR secondary's access. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -199,7 +199,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/replication/dr/primary/secondary-token ``` -### Sample Response +### Sample response ```json { @@ -218,7 +218,7 @@ $ curl \ } ``` -## Revoke DR Secondary Token +## Revoke DR secondary token This endpoint revokes a DR secondary's ability to connect to the DR primary cluster; the DR secondary will immediately be disconnected and will not be allowed to @@ -232,7 +232,7 @@ connect again unless given a new activation token. This command can be run from - `id` `(string: )` – Specifies an opaque identifier, e.g. 'us-east' -### Sample Payload +### Sample payload ```json { @@ -240,7 +240,7 @@ connect again unless given a new activation token. This command can be run from } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -250,7 +250,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/replication/dr/primary/revoke-secondary ``` -## Generate DR Secondary Public Key +## Generate DR secondary public key (Vault 1.3+) @@ -262,7 +262,7 @@ needing to make an API call to the primary during activation. | :----- | :-------------------------------------------------- | | `POST` | `/sys/replication/dr/secondary/generate-public-key` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -271,7 +271,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/replication/dr/secondary/generate-public-key ``` -## Enable DR Secondary +## Enable DR secondary This endpoint enables replication on a DR secondary using a DR secondary activation token. @@ -301,7 +301,7 @@ token. token from the primary. If this and ca_file are not given, defaults to system CA roots. -### Sample Payload +### Sample payload ```json { @@ -309,7 +309,7 @@ token. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -319,7 +319,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/replication/dr/secondary/enable ``` -## Promote DR Secondary +## Promote DR secondary This endpoint promotes the DR secondary cluster to DR primary. For data safety and security reasons, new secondary tokens will need to be issued to other @@ -362,7 +362,7 @@ on older versions of Vault than downstream clusters. See certain safety checks. Caution: Forcing promotion could result in data loss if data isn't fully replicated. -### Sample Payload +### Sample payload ```json { @@ -370,7 +370,7 @@ on older versions of Vault than downstream clusters. See } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -380,7 +380,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/replication/dr/secondary/promote ``` -### Sample Response +### Sample response ```json { @@ -402,7 +402,7 @@ $ curl \ } ``` -## Disable DR Secondary +## Disable DR secondary This endpoint disables DR replication entirely on the cluster. The cluster will no longer be able to connect to the DR primary. @@ -419,7 +419,7 @@ underlying storage. | :----- | :-------------------------------------- | | `POST` | `/sys/replication/dr/secondary/disable` | -### Sample Payload +### Sample payload ```json { @@ -427,7 +427,7 @@ underlying storage. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -436,7 +436,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/replication/dr/secondary/disable ``` -## Update DR Secondary's Primary +## Update DR secondary's primary This endpoint changes a DR secondary cluster's assigned primary cluster using a secondary activation token. This does not wipe all data in the cluster. @@ -471,7 +471,7 @@ docs](#generate-disaster-recovery-operation-token) for more information. PEM-format files that the secondary can use when unwrapping the token from the primary. If this and ca_file are not given, defaults to system CA roots. -### Sample Payload +### Sample payload ```json { @@ -480,7 +480,7 @@ docs](#generate-disaster-recovery-operation-token) for more information. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -490,14 +490,14 @@ $ curl \ http://127.0.0.1:8200/v1/sys/replication/dr/secondary/update-primary ``` -## Generate Disaster Recovery Operation Token +## Generate disaster recovery operation token The `/sys/replication/dr/secondary/generate-operation-token` endpoint is used to create a new Disaster Recovery operation token for a DR secondary. These tokens are used to authorize certain DR Operations. They should be treated like traditional root tokens by being generated when needed and deleted soon after. -## Read Generation Progress +## Read generation progress This endpoint reads the configuration and process of the current generation attempt. @@ -506,14 +506,14 @@ attempt. | :----- | :--------------------------------------------------------------- | | `GET` | `/sys/replication/dr/secondary/generate-operation-token/attempt` | -### Sample Request +### Sample request ```shell-session $ curl \ http://127.0.0.1:8200/v1/sys/replication/dr/secondary/generate-operation-token/attempt ``` -### Sample Response +### Sample response ```json { @@ -534,7 +534,7 @@ complete is also displayed. If a PGP key is being used to encrypt the final token, its fingerprint will be returned. Note that if an OTP is being used to encode the final token, it will never be returned. -## Start Token Generation +## Start token generation This endpoint initializes a new generation attempt. Only a single generation attempt can take place at a time. @@ -549,7 +549,7 @@ generation attempt can take place at a time. The raw bytes of the token will be encrypted with this value before being returned to the final unseal key provider. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -557,7 +557,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/replication/dr/secondary/generate-operation-token/attempt ``` -### Sample Response +### Sample response ```json { @@ -572,7 +572,7 @@ $ curl \ } ``` -## Cancel Generation +## Cancel generation This endpoint cancels any in-progress generation attempt. This clears any progress made. This must be called to change the OTP or PGP key being used. @@ -581,7 +581,7 @@ progress made. This must be called to change the OTP or PGP key being used. | :------- | :--------------------------------------------------------------- | | `DELETE` | `/sys/replication/dr/secondary/generate-operation-token/attempt` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -589,7 +589,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/replication/dr/secondary/generate-operation-token/attempt ``` -## Provide Key Share to Generate Token +## Provide key share to generate token This endpoint is used to enter a single root key share to progress the generation attempt. If the threshold number of root key shares is reached, @@ -607,7 +607,7 @@ nonce must be provided with each call. - `nonce` `(string: )` – Specifies the nonce of the attempt. -### Sample Payload +### Sample payload ```json { @@ -616,7 +616,7 @@ nonce must be provided with each call. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -625,7 +625,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/replication/dr/secondary/generate-operation-token/update ``` -### Sample Response +### Sample response This returns a JSON-encoded object indicating the attempt nonce, and completion status, and the encoded token, if the attempt is complete. @@ -642,7 +642,7 @@ status, and the encoded token, if the attempt is complete. } ``` -## Delete DR Operation Token +## Delete DR operation token This endpoint revokes the DR Operation Token. This token does not have a TTL and therefore should be deleted when it is no longer needed. @@ -655,7 +655,7 @@ and therefore should be deleted when it is no longer needed. - `dr_operation_token` `(string: )` - DR operation token used to authorize this request. -### Sample Payload +### Sample payload ```json { @@ -663,7 +663,7 @@ and therefore should be deleted when it is no longer needed. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -673,7 +673,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/replication/dr/secondary/operation-token/delete ``` -## Reindex Replication +## Reindex replication This endpoint reindexes the local data storage. This can cause a very long delay depending on the number and size of objects in the data store. @@ -701,7 +701,7 @@ depending on the number and size of objects in the data store. - `dr_operation_token` `(string: )` - DR operation token used to authorize this request. -### Sample Payload +### Sample payload ```json { @@ -709,7 +709,7 @@ depending on the number and size of objects in the data store. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -718,7 +718,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/replication/dr/secondary/reindex ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/replication/replication-performance.mdx b/website/content/api-docs/system/replication/replication-performance.mdx index 7285ba8ef6f9..d09001983615 100644 --- a/website/content/api-docs/system/replication/replication-performance.mdx +++ b/website/content/api-docs/system/replication/replication-performance.mdx @@ -10,7 +10,7 @@ description: >- ~> **Enterprise Only** – These endpoints require Vault Enterprise. -## Check Performance Status +## Check performance status This endpoint prints information about the status of replication (mode, sync progress, etc). @@ -21,14 +21,14 @@ This is an unauthenticated endpoint. | :----- | :------------------------------------ | | `GET` | `/sys/replication/performance/status` | -### Sample Request +### Sample request ```shell-session $ curl \ http://127.0.0.1:8200/v1/sys/replication/performance/status ``` -### Sample Response from Primary +### Sample response from primary The printed status of the replication environment. As an example, for a primary, it will look something like: @@ -54,7 +54,7 @@ primary, it will look something like: } ``` -### Sample Response from Secondary +### Sample response from secondary The printed status of the replication environment. As an example, for a secondary, it will look something like: @@ -82,7 +82,7 @@ secondary, it will look something like: } ``` -## Enable Performance Primary Replication +## Enable performance primary replication This endpoint enables replication in primary mode. This is used when replication is currently disabled on the cluster (if the cluster is already a secondary, it @@ -103,13 +103,13 @@ result in data loss! such as through a TCP-based load balancer. If not set, uses vault's configured cluster address. -### Sample Payload +### Sample payload ```json {} ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -119,7 +119,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/replication/performance/primary/enable ``` -## Demote Performance Primary +## Demote performance primary This endpoint demotes a performance primary cluster to a performance secondary. This secondary cluster will not attempt to connect to a primary (see the update-primary call), @@ -130,7 +130,7 @@ replication set without wiping local storage. | :----- | :-------------------------------------------- | | `POST` | `/sys/replication/performance/primary/demote` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -139,7 +139,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/replication/performance/primary/demote ``` -## Disable Performance Primary +## Disable performance primary This endpoint disables Performance Replication entirely on the cluster. Any performance secondaries will no longer be able to connect. Caution: re-enabling @@ -152,7 +152,7 @@ they have connected before) will require a wipe of the underlying storage. | :----- | :--------------------------------------------- | | `POST` | `/sys/replication/performance/primary/disable` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -161,7 +161,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/replication/performance/primary/disable ``` -## Generate Performance Secondary Token +## Generate performance secondary token This endpoint generates a performance secondary activation token for the cluster with the given opaque identifier, which must be unique. This @@ -184,7 +184,7 @@ identifier can later be used to revoke a secondary's access. public key, if using encryption rather than response wrapping to protect the secondary credentials. (Vault 1.3+) -### Sample Payload +### Sample payload ```json { @@ -192,7 +192,7 @@ identifier can later be used to revoke a secondary's access. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -202,7 +202,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/replication/performance/primary/secondary-token ``` -### Sample Response +### Sample response ```json { @@ -221,7 +221,7 @@ $ curl \ } ``` -## Revoke Performance Secondary Token +## Revoke performance secondary token This endpoint revokes a performance secondary's ability to connect to the performance primary cluster; the secondary will immediately be disconnected and @@ -235,7 +235,7 @@ will not be allowed to connect again unless given a new activation token. - `id` `(string: )` – Specifies an opaque identifier, e.g. 'us-east' -### Sample Payload +### Sample payload ```json { @@ -243,7 +243,7 @@ will not be allowed to connect again unless given a new activation token. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -253,7 +253,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/replication/performance/primary/revoke-secondary ``` -## Create Paths Filter +## Create paths filter This endpoint is used to modify the mounts and namespaces that are filtered to a secondary. Filtering can be specified in allow mode or deny mode. In allow @@ -278,7 +278,7 @@ selected secondary. In deny mode, the mount and namespace paths are excluded. - `paths` `(array: [])` – The list of mount and namespace paths that are filtered. -### Sample Payload +### Sample payload ```json { @@ -287,7 +287,7 @@ selected secondary. In deny mode, the mount and namespace paths are excluded. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -297,7 +297,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/replication/performance/primary/paths-filter/mySecondaryID ``` -## Read Paths Filter +## Read paths filter This endpoint is used to read the mode and the mount/namespace paths that are filtered for a secondary. @@ -310,7 +310,7 @@ for a secondary. - `id` `(string: )` – Specifies the unique performance secondary identifier. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -318,7 +318,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/replication/performance/primary/paths-filter/mySecondaryID ``` -### Sample Response +### Sample response ```json { @@ -327,7 +327,7 @@ $ curl \ } ``` -## Delete Paths Filter +## Delete paths filter This endpoint is used to delete the mount and namespace filters for a secondary. @@ -339,7 +339,7 @@ This endpoint is used to delete the mount and namespace filters for a secondary. - `id` `(string: )` – Specifies the unique performance secondary identifier. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -348,7 +348,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/replication/performance/primary/paths-filter/mySecondaryID ``` -## Read Dynamically Generated Filter (PRIMARY) +## Read dynamically generated filter (PRIMARY) This endpoint is used to read the namespace and the mount paths that are dynamically filtered for a secondary on the primary. @@ -361,7 +361,7 @@ filtered for a secondary on the primary. - `id` `(string: )` – Specifies the unique performance secondary identifier. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -369,7 +369,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/replication/performance/primary/dynamic-filter/mySecondaryID ``` -### Sample Response +### Sample response ```json { @@ -378,7 +378,7 @@ $ curl \ } ``` -## Read Dynamically Generated Filter (SECONDARY) +## Read dynamically generated filter (SECONDARY) This endpoint is used to read the namespace and the mount paths that are dynamically filtered for a secondary on the secondary. @@ -391,7 +391,7 @@ filtered for a secondary on the secondary. - `id` `(string: )` – Specifies the unique performance secondary identifier. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -399,7 +399,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/replication/performance/secondary/dynamic-filter/mySecondaryID ``` -### Sample Response +### Sample response ```json { @@ -408,7 +408,7 @@ $ curl \ } ``` -## Fetch Performance Secondary Public Key +## Fetch performance secondary public key (Vault 1.3+) @@ -420,7 +420,7 @@ needing to make an API call to the primary during activation. | :----- | :----------------------------------------------------------- | | `POST` | `/sys/replication/performance/secondary/generate-public-key` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -429,7 +429,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/replication/performance/secondary/generate-public-key ``` -## Enable Performance Secondary +## Enable performance secondary This endpoint enables Performance Replication on a secondary using a secondary activation token. @@ -459,7 +459,7 @@ token. token from the primary. If this and ca_file are not given, defaults to system CA roots. -### Sample Payload +### Sample payload ```json { @@ -467,7 +467,7 @@ token. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -477,7 +477,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/replication/performance/secondary/enable ``` -## Promote Performance Secondary +## Promote performance secondary This endpoint promotes the performance secondary cluster to performance primary. For data safety and security reasons, new secondary tokens will need to be @@ -498,13 +498,13 @@ primary at a time. certain safety checks. Caution: Forcing promotion could result in data loss if data isn't fully replicated. -### Sample Payload +### Sample payload ```json {} ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -514,7 +514,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/replication/performance/secondary/promote ``` -## Disable Performance Secondary +## Disable performance secondary This endpoint disables Performance Replication entirely on the cluster. The cluster will no longer be able to connect to the performance primary. @@ -529,7 +529,7 @@ underlying storage. | :----- | :----------------------------------------------- | | `POST` | `/sys/replication/performance/secondary/disable` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -538,7 +538,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/replication/performance/secondary/disable ``` -## Update Performance Secondary's Primary +## Update performance secondary's primary This endpoint changes a performance secondary cluster's assigned primary cluster using a secondary activation token. This does not wipe all data in the cluster. @@ -574,7 +574,7 @@ secondary activation token. This does not wipe all data in the cluster. of replication. Note that it's invalid to specify this and `token` in the same API call. They are mutually exclusive. -### Sample Payload +### Sample payload ```json { @@ -582,7 +582,7 @@ secondary activation token. This does not wipe all data in the cluster. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/system/rotate-config.mdx b/website/content/api-docs/system/rotate-config.mdx index eecd0b70104c..f9abecfb8491 100644 --- a/website/content/api-docs/system/rotate-config.mdx +++ b/website/content/api-docs/system/rotate-config.mdx @@ -8,14 +8,14 @@ description: The `/sys/rotate/config` endpoint is used to configure automatic ke The `/sys/rotate` endpoint is used to configure automatic key rotation. -## Configure Automatic Key Rotation +## Configure automatic key rotation This endpoint configures the automatic rotation of the backend encryption key. By default, the key is rotated after just under 4 billion encryptions, to satisfy the recommendation of [NIST SP 800-38D](https://csrc.nist.gov/publications/detail/sp/800-38d/final). One can configure rotations after fewer encryptions or on a time based schedule. -## Create or Update the Auto Rotation Configuration +## Create or update the auto rotation configuration | Method | Path | | :----- | :------------------- | @@ -32,7 +32,7 @@ One can configure rotations after fewer encryptions or on a time based schedule. - `enabled` `(bool: true)` - If set to false, automatic rotations will not be performed. Tracking of encryption counts will continue. -### Sample Payload +### Sample payload ```json { @@ -41,7 +41,7 @@ One can configure rotations after fewer encryptions or on a time based schedule. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -51,13 +51,13 @@ $ curl \ http://127.0.0.1:8200/v1/sys/rotate/config ``` -## Get the Auto Rotation Configuration +## Get the auto rotation configuration | Method | Path | | :----- | :------------------- | | `GET` | `/sys/rotate/config` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -66,7 +66,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/rotate/config ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/rotate.mdx b/website/content/api-docs/system/rotate.mdx index afe0cf2f3302..f096a8005d3e 100644 --- a/website/content/api-docs/system/rotate.mdx +++ b/website/content/api-docs/system/rotate.mdx @@ -8,7 +8,7 @@ description: The `/sys/rotate` endpoint is used to rotate the encryption key. The `/sys/rotate` endpoint is used to rotate the encryption key. -## Rotate Encryption Key +## Rotate encryption key This endpoint triggers a rotation of the backend encryption key. This is the key that is used to encrypt data written to the storage backend, and is not provided @@ -21,7 +21,7 @@ This path requires `sudo` capability in addition to `update`. | :----- | :------------ | | `POST` | `/sys/rotate` | -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/system/seal-status.mdx b/website/content/api-docs/system/seal-status.mdx index e525dba10015..feb69e68e3cf 100644 --- a/website/content/api-docs/system/seal-status.mdx +++ b/website/content/api-docs/system/seal-status.mdx @@ -8,7 +8,7 @@ description: The `/sys/seal-status` endpoint is used to check the seal status of The `/sys/seal-status` endpoint is used to check the seal status of a Vault. -## Seal Status +## Seal status This endpoint returns the seal status of the Vault. This is an unauthenticated endpoint. @@ -17,14 +17,14 @@ endpoint. | :----- | :----------------- | | `GET` | `/sys/seal-status` | -### Sample Request +### Sample request ```shell-session $ curl \ http://127.0.0.1:8200/v1/sys/seal-status ``` -### Sample Response +### Sample response The "t" parameter is the threshold, and "n" is the number of shares. diff --git a/website/content/api-docs/system/seal.mdx b/website/content/api-docs/system/seal.mdx index 808676c3c1cf..2a0dbf9a6965 100644 --- a/website/content/api-docs/system/seal.mdx +++ b/website/content/api-docs/system/seal.mdx @@ -18,7 +18,7 @@ Standby nodes should be restarted to get the same effect. Requires a token with | :----- | :---------- | | `POST` | `/sys/seal` | -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/system/sealwrap-rewrap.mdx b/website/content/api-docs/system/sealwrap-rewrap.mdx index 67610cd33220..3d6e8498feb5 100644 --- a/website/content/api-docs/system/sealwrap-rewrap.mdx +++ b/website/content/api-docs/system/sealwrap-rewrap.mdx @@ -14,7 +14,7 @@ The `/sys/sealwrap/rewrap` endpoint is used to rewrap all seal wrapped entries. This is useful when you want to upgrade seal wrapped entries to use the latest key, for example, after a seal migration or after rotating the remote keyring. -## Read Rewrap Status +## Read rewrap status This endpoint reports whether a seal rewrap process is currently running. @@ -22,7 +22,7 @@ This endpoint reports whether a seal rewrap process is currently running. | :----- | :--------------------- | | `GET` | `/sys/sealwrap/rewrap` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -30,7 +30,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/sealwrap/rewrap ``` -### Sample Response +### Sample response ```json { @@ -45,7 +45,7 @@ $ curl \ } ``` -## Start a Seal Rewrap Process +## Start a seal rewrap process This endpoint starts a seal rewrap process if one is not currently running. The process will run in the background. Check the vault server logs for status @@ -60,7 +60,7 @@ The default status codes are: - `200` if a seal rewrap process is already running - `204` if a seal rewrap process was started -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/system/step-down.mdx b/website/content/api-docs/system/step-down.mdx index fd7fae4c3863..363acf0bd7b5 100644 --- a/website/content/api-docs/system/step-down.mdx +++ b/website/content/api-docs/system/step-down.mdx @@ -8,7 +8,7 @@ description: The `/sys/step-down` endpoint causes the node to give up active sta The `/sys/step-down` endpoint causes the node to give up active status. -## Step Down Leader +## Step down leader This endpoint forces the node to give up active status. If the node does not have active status, this endpoint does nothing. Note that the node will sleep @@ -21,7 +21,7 @@ the path. | :----- | :--------------- | | `POST` | `/sys/step-down` | -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/system/storage/raft.mdx b/website/content/api-docs/system/storage/raft.mdx index fd8f3198ba47..a2c7ac5db4bd 100644 --- a/website/content/api-docs/system/storage/raft.mdx +++ b/website/content/api-docs/system/storage/raft.mdx @@ -7,7 +7,7 @@ description: |- backend. --- -## Join a Raft cluster +## Join a raft cluster This endpoint joins a new server node to the Raft cluster. When using Shamir seal, as soon as the Vault server is brought up, this API should be invoked @@ -61,7 +61,7 @@ relevant functionality is only supported in Vault Enterprise: which results in Vault's data being replicated to it, but does not contribute to the quorum count. -### Sample Payload +### Sample payload ```json { @@ -72,7 +72,7 @@ relevant functionality is only supported in Vault Enterprise: } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -83,7 +83,7 @@ $ curl \ **Note:** Unseal the joining node immediately after this API is invoked. -## Read Raft Configuration +## Read raft configuration This endpoint returns the details of all the nodes in the raft cluster. @@ -91,7 +91,7 @@ This endpoint returns the details of all the nodes in the raft cluster. | :----- | :-------------------------------- | | `GET` | `/sys/storage/raft/configuration` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -99,7 +99,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/storage/raft/configuration ``` -### Sample Response +### Sample response ```json { @@ -132,7 +132,7 @@ $ curl \ } ``` -## Remove a node from Raft cluster +## Remove a node from raft cluster This endpoint removes a node from the raft cluster. An optional `dr_operation_token` may be provided if the node is in a DR secondary cluster. @@ -141,7 +141,7 @@ may be provided if the node is in a DR secondary cluster. | :----- | :------------------------------ | | `POST` | `/sys/storage/raft/remove-peer` | -### Sample Payload +### Sample payload ```json { @@ -150,7 +150,7 @@ may be provided if the node is in a DR secondary cluster. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -160,7 +160,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/storage/raft/remove-peer ``` -## Take a snapshot of the Raft cluster +## Take a snapshot of the raft cluster This endpoint returns a snapshot of the current state of the raft cluster. The snapshot is returned as binary data and should be redirected to a file. @@ -172,7 +172,7 @@ Unavailable if Raft is used exclusively for `ha_storage`. @include 'raft-large-snapshots.mdx' -### Sample Request +### Sample request ```shell-session $ curl \ @@ -181,7 +181,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/storage/raft/snapshot > raft.snap ``` -## Restore Raft using a snapshot +## Restore raft using a snapshot Installs the provided snapshot, returning the cluster to the state defined in it. Unavailable if Raft is used exclusively for `ha_storage`. @@ -192,7 +192,7 @@ it. Unavailable if Raft is used exclusively for `ha_storage`. @include 'raft-large-snapshots.mdx' -### Sample Request +### Sample request ```shell-session $ curl \ @@ -202,7 +202,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/storage/raft/snapshot ``` -## Force Restore Raft using a snapshot +## Force restore raft using a snapshot Installs the provided snapshot, returning the cluster to the state defined in it. This is same as writing to `/sys/storage/raft/snapshot` except that this @@ -213,7 +213,7 @@ snapshot data. Unavailable if Raft is used exclusively for `ha_storage`. | :----- | :--------------------------------- | | `POST` | `/sys/storage/raft/snapshot-force` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -234,7 +234,7 @@ is used to add more nodes to the Raft cluster. | :----- | :--------------------------- | | `POST` | `/sys/storage/raft/bootstrap` | -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/system/storage/raftautopilot.mdx b/website/content/api-docs/system/storage/raftautopilot.mdx index 538aaffb9d63..18eff4c8ded4 100644 --- a/website/content/api-docs/system/storage/raftautopilot.mdx +++ b/website/content/api-docs/system/storage/raftautopilot.mdx @@ -13,7 +13,7 @@ The `/sys/storage/raft/autopilot` endpoints are used to manage raft clusters usi with Vault's [Integrated Storage backend](/vault/docs/internals/integrated-storage). Refer to the [Integrated Storage Autopilot](/vault/tutorials/raft/raft-autopilot) tutorial to learn how to manage raft clusters using autopilot. -## Get Cluster State +## Get cluster state This endpoint is used to retrieve the raft cluster state. See the [docs page](/vault/docs/commands/operator/raft#autopilot-state) for a description of the output. @@ -21,7 +21,7 @@ This endpoint is used to retrieve the raft cluster state. See the [docs page](/v | :----- | :---------------------------------- | | `GET` | `/sys/storage/raft/autopilot/state` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -29,7 +29,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/storage/raft/autopilot/state ``` -### Sample Response +### Sample response ```json { @@ -82,11 +82,11 @@ $ curl \ } ``` -### Enterprise Only +### Enterprise only Vault Enterprise will include additional output in its API response to indicate the current state of redundancy zones, automated upgrade progress (if any), and optimistic failure tolerance. -#### Sample Response (Enterprise) +#### Sample response (Enterprise) ```json { "failure_tolerance": 0, @@ -159,7 +159,7 @@ automated upgrade progress (if any), and optimistic failure tolerance. } ``` -## Get Configuration +## Get configuration This endpoint is used to get the configuration of the autopilot subsystem of Integrated Storage. @@ -167,7 +167,7 @@ This endpoint is used to get the configuration of the autopilot subsystem of Int | :----- | :------------------------------------------ | | `GET` | `/sys/storage/raft/autopilot/configuration` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -175,7 +175,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/storage/raft/autopilot/configuration ``` -### Sample Response +### Sample response ```json { @@ -191,7 +191,7 @@ $ curl \ Note that in the above sample response, `disable_upgrade_migration` is an Enterprise-only field. -## Set Configuration +## Set configuration This endpoint is used to modify the configuration of the autopilot subsystem of Integrated Storage. @@ -225,7 +225,7 @@ This endpoint is used to modify the configuration of the autopilot subsystem of - `disable_upgrade_migration` `(bool: false)` - Disables automatically upgrading Vault using autopilot. (Enterprise-only) -### Sample Request +### Sample request ```shell-session $ curl \ @@ -235,7 +235,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/storage/raft/autopilot/configuration ``` -### Sample Payload +### Sample payload ```json { diff --git a/website/content/api-docs/system/storage/raftautosnapshots.mdx b/website/content/api-docs/system/storage/raftautosnapshots.mdx index 4cd1feeef30d..fc983ada89e2 100644 --- a/website/content/api-docs/system/storage/raftautosnapshots.mdx +++ b/website/content/api-docs/system/storage/raftautosnapshots.mdx @@ -132,7 +132,7 @@ environment variables or files on disk in predefined locations. - `azure_endpoint` `(string)` - Azure blob storage endpoint. This is typically only set when using a non-Azure implementation like Azurite. -### Sample Payload +### Sample payload ```json { @@ -144,7 +144,7 @@ environment variables or files on disk in predefined locations. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -164,7 +164,7 @@ This endpoint lists named configurations. | :----- | :--------------------------------------- | | `LIST` | `/sys/storage/raft/snapshot-auto/config` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -173,7 +173,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/storage/raft/snapshot-auto/config ``` -### Sample Response +### Sample response ```json { @@ -193,7 +193,7 @@ This endpoint reads a named configuration. | :----- | :--------------------------------------------- | | `GET` | `/sys/storage/raft/snapshot-auto/config/:name` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -201,7 +201,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/storage/raft/snapshot-auto/config/config1 ``` -### Sample Response +### Sample response ```json { @@ -226,7 +226,7 @@ This endpoint deletes a named configuration. | :------- | :--------------------------------------------- | | `DELETE` | `/sys/storage/raft/snapshot-auto/config/:name` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -243,7 +243,7 @@ This endpoint returns the status of a named configuration. | :----- | :--------------------------------------------- | | `GET` | `/sys/storage/raft/snapshot-auto/status/:name` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -251,7 +251,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/storage/raft/snapshot-auto/status/config1 ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/tools.mdx b/website/content/api-docs/system/tools.mdx index 955c6a19d067..04990e31b874 100644 --- a/website/content/api-docs/system/tools.mdx +++ b/website/content/api-docs/system/tools.mdx @@ -8,7 +8,7 @@ description: This is the API documentation for a general set of crypto tools. The `/sys/tools` endpoints are a general set of tools. -## Generate Random Bytes +## Generate random bytes This endpoint returns high-quality random bytes of the specified length. @@ -29,7 +29,7 @@ This endpoint returns high-quality random bytes of the specified length. `seal` sources from entropy augmentation (enterprise only). `all` mixes bytes from all available sources. -### Sample Payload +### Sample payload ```json { @@ -37,7 +37,7 @@ This endpoint returns high-quality random bytes of the specified length. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -47,7 +47,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/tools/random/164 ``` -### Sample Response +### Sample response ```json { @@ -57,7 +57,7 @@ $ curl \ } ``` -## Hash Data +## Hash data This endpoint returns the cryptographic hash of given data using the specified algorithm. @@ -89,7 +89,7 @@ algorithm. - `format` `(string: "hex")` – Specifies the output encoding. This can be either `hex` or `base64`. -### Sample Payload +### Sample payload ```json { @@ -97,7 +97,7 @@ algorithm. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -107,7 +107,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/tools/hash/sha2-512 ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/unseal.mdx b/website/content/api-docs/system/unseal.mdx index e7b9f6a5dfb4..1bd635b838bd 100644 --- a/website/content/api-docs/system/unseal.mdx +++ b/website/content/api-docs/system/unseal.mdx @@ -8,7 +8,7 @@ description: The `/sys/unseal` endpoint is used to unseal the Vault. The `/sys/unseal` endpoint is used to unseal the Vault. -## Submit Unseal Key +## Submit unseal key This endpoint is used to enter a single root key share to progress the unsealing of the Vault. If the threshold number of root key shares is reached, @@ -34,7 +34,7 @@ Either the `key` or `reset` parameter must be provided; if both are provided, from shamir to autoseal or autoseal to shamir. Must be provided on all unseal key calls. -### Sample Payload +### Sample payload ```json { @@ -42,7 +42,7 @@ Either the `key` or `reset` parameter must be provided; if both are provided, } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -51,7 +51,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/unseal ``` -### Sample Response +### Sample response The "t" parameter is the threshold, and "n" is the number of shares. diff --git a/website/content/api-docs/system/user-lockout.mdx b/website/content/api-docs/system/user-lockout.mdx index f43b5f2cb74b..b27eaeba2489 100644 --- a/website/content/api-docs/system/user-lockout.mdx +++ b/website/content/api-docs/system/user-lockout.mdx @@ -10,7 +10,7 @@ The `/sys/locked-users` endpoint is used to list and unlock locked users in Vaul Please visit [user lockout](/vault/docs/concepts/user-lockout) concepts page for more details about the feature. -## List Locked Users +## List locked users This endpoint lists the locked users information in Vault. @@ -33,7 +33,7 @@ This endpoint was added in Vault 1.13. belongs in the namespace in which the request was made. If no mount accessor is specified, the response will include locked users in all child namespaces of the namespace in which the request was made. -### Sample Request +### Sample request ```shell-session $ curl \ @@ -42,7 +42,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/locked-users ``` -### Sample Response +### Sample response ```json { @@ -173,7 +173,7 @@ For deleted namespaces, the response will look like: ### Sample request with mount accessor -#### Sample Payload +#### Sample payload ```json { @@ -181,7 +181,7 @@ For deleted namespaces, the response will look like: } ``` -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -191,7 +191,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/locked-users ``` -## Unlock User +## Unlock user This endpoint unlocks a locked user with provided mount_accessor and alias_identifier in namespace in which the request was made if locked. This command is idempotent, meaning it succeeds even if user with the given mount_accessor and alias_identifier is not locked. @@ -212,7 +212,7 @@ belongs to userpass backend, the name should be a valid username within userpass to an approle auth method, the name should be a valid RoleID. If the alias belongs to an ldap auth method, the name should be a valid username. -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/api-docs/system/version-history.mdx b/website/content/api-docs/system/version-history.mdx index 86e9c8aca577..2000e1013ddd 100644 --- a/website/content/api-docs/system/version-history.mdx +++ b/website/content/api-docs/system/version-history.mdx @@ -11,7 +11,7 @@ This API was added in 1.10.0. The `/sys/version-history` endpoint is used to retrieve the version history of a Vault. -## Read Version History +## Read version history This endpoint returns the version history of the Vault. The response will contain the following keys: @@ -25,7 +25,7 @@ This endpoint returns the version history of the Vault. The response will contai | :----- | :--------------------- | | `GET` | `/sys/version-history` | -### Sample Request +### Sample request ```shell-session $ curl \ @@ -33,7 +33,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/version-history ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/wrapping-lookup.mdx b/website/content/api-docs/system/wrapping-lookup.mdx index 0e7c80d46c27..146c3770ddb0 100644 --- a/website/content/api-docs/system/wrapping-lookup.mdx +++ b/website/content/api-docs/system/wrapping-lookup.mdx @@ -8,7 +8,7 @@ description: The `/sys/wrapping/lookup` endpoint returns wrapping token properti The `/sys/wrapping/lookup` endpoint returns wrapping token properties. -## Wrapping Lookup +## Wrapping lookup This endpoint looks up wrapping properties for the given token. @@ -20,7 +20,7 @@ This endpoint looks up wrapping properties for the given token. - `token` `(string: )` – Specifies the wrapping token ID. -### Sample Payload +### Sample payload ```json { @@ -28,7 +28,7 @@ This endpoint looks up wrapping properties for the given token. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -38,7 +38,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/wrapping/lookup ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/wrapping-rewrap.mdx b/website/content/api-docs/system/wrapping-rewrap.mdx index af27da6f26ff..6da9f02e2034 100644 --- a/website/content/api-docs/system/wrapping-rewrap.mdx +++ b/website/content/api-docs/system/wrapping-rewrap.mdx @@ -11,7 +11,7 @@ description: >- The `/sys/wrapping/rewrap` endpoint can be used to rotate a wrapping token and refresh its TTL. -## Wrapping Rewrap +## Wrapping rewrap This endpoint rewraps a response-wrapped token. The new token will use the same creation TTL as the original token and contain the same response. The old token @@ -26,7 +26,7 @@ response-wrapped token when rotation is a requirement. - `token` `(string: )` – Specifies the wrapping token ID. -### Sample Payload +### Sample payload ```json { @@ -34,7 +34,7 @@ response-wrapped token when rotation is a requirement. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -44,7 +44,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/wrapping/rewrap ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/wrapping-unwrap.mdx b/website/content/api-docs/system/wrapping-unwrap.mdx index 701bc6eecf28..49297a4a8c85 100644 --- a/website/content/api-docs/system/wrapping-unwrap.mdx +++ b/website/content/api-docs/system/wrapping-unwrap.mdx @@ -8,7 +8,7 @@ description: The `/sys/wrapping/unwrap` endpoint unwraps a wrapped response. The `/sys/wrapping/unwrap` endpoint unwraps a wrapped response. -## Wrapping Unwrap +## Wrapping unwrap This endpoint returns the original response inside the given wrapping token. Unlike simply reading `cubbyhole/response` (which is deprecated), this endpoint @@ -33,7 +33,7 @@ unable to be looked up, as it will basically be a double-use of the token! the client token is not the wrapping token. Do not use the wrapping token in both locations. -### Sample Payload +### Sample payload ```json { @@ -41,7 +41,7 @@ unable to be looked up, as it will basically be a double-use of the token! } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -60,7 +60,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/wrapping/unwrap ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/api-docs/system/wrapping-wrap.mdx b/website/content/api-docs/system/wrapping-wrap.mdx index 38bf14b59fe5..8071097fe82b 100644 --- a/website/content/api-docs/system/wrapping-wrap.mdx +++ b/website/content/api-docs/system/wrapping-wrap.mdx @@ -11,7 +11,7 @@ description: |- The `/sys/wrapping/wrap` endpoint wraps the given values in a response-wrapped token. -## Wrapping Wrap +## Wrapping wrap This endpoint wraps the given user-supplied data inside a response-wrapped token. @@ -26,7 +26,7 @@ token. keys/values in a JSON object. The exact set of given parameters will be contained in the wrapped response. -### Sample Payload +### Sample payload ```json { @@ -35,7 +35,7 @@ token. } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -46,7 +46,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/wrapping/wrap ``` -### Sample Response +### Sample response ```json { diff --git a/website/content/docs/agent-and-proxy/agent/apiproxy.mdx b/website/content/docs/agent-and-proxy/agent/apiproxy.mdx index de262b40a857..5ca3533eec5c 100644 --- a/website/content/docs/agent-and-proxy/agent/apiproxy.mdx +++ b/website/content/docs/agent-and-proxy/agent/apiproxy.mdx @@ -6,7 +6,7 @@ description: >- for Vault's API. --- -# Vault Agent API Proxy +# Vault agent API proxy Vault Agent's API Proxy functionality allows you to use Vault Agent's API as a proxy for Vault's API. @@ -26,7 +26,7 @@ If a `listener` has been configured alongside a `cache` stanza, the API Proxy wi first attempt to utilize the cache subsystem for qualifying requests, before forwarding the request to Vault. See the [caching docs](/vault/docs/agent-and-proxy/agent/caching) for more information on caching. -## Using Auto-Auth Token +## Using Auto-Auth token Vault Agent allows for easy authentication to Vault in a wide variety of environments using [Auto-Auth](/vault/docs/agent-and-proxy/agent/autoauth). By setting the @@ -38,7 +38,7 @@ configuration will be overridden if the request already has a token attached, in which case, the token present in the request will be used to forward the request to the Vault server. -## Forcing Auto-Auth Token +## Forcing Auto-Auth token Vault Agent can be configured to force the use of the auto-auth token by using the value `force` for the `use_auto_auth_token` option. This configuration @@ -69,13 +69,13 @@ or `"never"`. - `when_inconsistent` `(string: optional)` - Set to one of `"fail"`, `"retry"`, or `"forward"`. -### Example Configuration +### Example configuration Here is an example of a `listener` configuration alongside `api_proxy` configuration to force the use of the auto_auth token and enforce consistency. ```hcl -# Other Vault Agent configuration blocks +# Other Vault agent configuration blocks # ... api_proxy { diff --git a/website/content/docs/agent-and-proxy/agent/caching/index.mdx b/website/content/docs/agent-and-proxy/agent/caching/index.mdx index 81baef4ac202..2e6ec51fbb4c 100644 --- a/website/content/docs/agent-and-proxy/agent/caching/index.mdx +++ b/website/content/docs/agent-and-proxy/agent/caching/index.mdx @@ -7,7 +7,7 @@ description: |- newly created tokens. --- -# Vault Agent Caching +# Vault agent caching Vault Agent Caching allows client-side caching of responses containing newly created tokens and responses containing leased secrets generated off of these @@ -19,7 +19,7 @@ running on Vault 1.1 and above due to changes that were introduced alongside this feature, such as the exposure of the `orphan` field in token creation responses. -## Caching and Renewals +## Caching and renewals Response caching and renewals are managed by the agent only under these specific scenarios. @@ -36,7 +36,7 @@ specific scenarios. that are issued using the tokens managed by the agent, will be cached and its renewals are taken care of. -## Persistent Cache +## Persistent cache Vault Agent can restore tokens and leases from a persistent cache file created by a previous Vault Agent process. @@ -45,7 +45,7 @@ Refer to the [Vault Agent Persistent Caching](/vault/docs/agent-and-proxy/agent/caching/persistent-caches) page for more information on this functionality. -## Cache Evictions +## Cache evictions The eviction of cache entries pertaining to secrets will occur when the agent can no longer renew them. This can happen when the secrets hit their maximum @@ -66,7 +66,7 @@ entries. For managing the stale entries in the cache, an endpoint `/agent/v1/cache-clear`(see below) is made available to manually evict cache entries based on some of the query criteria used for indexing the cache entries. -## Request Uniqueness +## Request uniqueness In order to detect repeat requests and return cached responses, agent will need to have a way to uniquely identify the requests. This computation as it stands @@ -83,7 +83,7 @@ assumption that the clients will use consistent mechanisms to make requests, thereby resulting in consistent hash values per request is the idea upon which the caching functionality is built upon. -## Renewal Management +## Renewal management The tokens and leases are renewed by the agent using the secret renewer that is made available via the Vault server's [Go @@ -103,7 +103,7 @@ Agent's listener address will be picked up by the CLI through the ## API -### Cache Clear +### Cache clear This endpoint clears the cache based on given criteria. To use this API, some information on how the agent caches values should be known @@ -135,7 +135,7 @@ but will do nothing (there is no cache to clear) and will return a `200` respons `request_path`. The namespace of which the cache entries to be evicted for the given request path. -### Sample Payload +### Sample payload ```json { @@ -144,7 +144,7 @@ but will do nothing (there is no cache to clear) and will return a `200` respons } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -226,13 +226,13 @@ or the default role, `default`, which serves everything (including metrics). - `tls_cert_file` `(string: optional)` - Specifies the path to the certificate for TLS. -### Example Configuration +### Example configuration Here is an example of a cache configuration with the optional `persist` block, alongside a regular listener, and a listener that only serves metrics. ```hcl -# Other Vault Agent configuration blocks +# Other Vault agent configuration blocks # ... cache { diff --git a/website/content/docs/agent-and-proxy/agent/caching/persistent-caches/index.mdx b/website/content/docs/agent-and-proxy/agent/caching/persistent-caches/index.mdx index 6923ca7b09ad..6c6c1ea81d36 100644 --- a/website/content/docs/agent-and-proxy/agent/caching/persistent-caches/index.mdx +++ b/website/content/docs/agent-and-proxy/agent/caching/persistent-caches/index.mdx @@ -4,7 +4,7 @@ page_title: Vault Agent Persistent Caching description: Vault Agent Caching --- -# Vault Agent Persistent Caching +# Vault agent persistent caching Vault Agent can restore tokens and leases from a persistent cache file created by a previous Vault Agent process. The persistent cache is a BoltDB file that @@ -26,16 +26,16 @@ ensures template requests are cached and restored properly. -> **Note** Vault Agent persistent cache is currently supported only in a Kubernetes environment. -## Vault Agent Persistent Cache Types +## Vault agent persistent cache types Please see the sidebar for available types and their usage/configuration. -## Persistent Cache Example Configuration +## Persistent cache example configuration Here is an example of a persistent cache configuration. ```hcl -# Other Vault Agent configuration blocks +# Other Vault agent configuration blocks # ... cache { diff --git a/website/content/docs/agent-and-proxy/agent/caching/persistent-caches/kubernetes.mdx b/website/content/docs/agent-and-proxy/agent/caching/persistent-caches/kubernetes.mdx index febf9d3bc453..853810ed6d9a 100644 --- a/website/content/docs/agent-and-proxy/agent/caching/persistent-caches/kubernetes.mdx +++ b/website/content/docs/agent-and-proxy/agent/caching/persistent-caches/kubernetes.mdx @@ -4,7 +4,7 @@ page_title: Kubernetes - Vault Agent Persistent Cache description: Kubernetes Persistent Cache for Vault Agent Caching --- -# Vault Agent Kubernetes Persistent Cache +# Vault agent kubernetes persistent cache When `kubernetes` is configured for the persistent cache type, Vault Agent will optimize the persistent cache specifically for Kubernetes. This type of persistent cache requires a Kubernetes diff --git a/website/content/docs/agent-and-proxy/agent/index.mdx b/website/content/docs/agent-and-proxy/agent/index.mdx index e84da62d273a..2cce97d66968 100644 --- a/website/content/docs/agent-and-proxy/agent/index.mdx +++ b/website/content/docs/agent-and-proxy/agent/index.mdx @@ -6,7 +6,7 @@ description: |- functionality automatically. --- -# What is Vault Agent? +# What is Vault agent? Vault Agent aims to remove the initial hurdle to adopt Vault by providing a more scalable and simpler way for applications to integrate with Vault, by @@ -39,7 +39,7 @@ for information. Auto-Auth functionality takes place within an `auto_auth` configuration stanza. -## API Proxy +## API proxy Vault Agent can act as an API proxy for Vault, allowing you to talk to Vault's API via a listener defined for Agent. It can be configured to optionally allow or force the automatic use of @@ -73,7 +73,7 @@ See the [caching](/vault/docs/agent-and-proxy/agent/caching#api) page for detail ## Configuration -### Command Options +### Command options - `-log-level` ((#\_log_level)) `(string: "info")` - Log verbosity level. Supported values (in order of descending detail) are `trace`, `debug`, `info`, `warn`, and `error`. This can @@ -104,7 +104,7 @@ See the [caching](/vault/docs/agent-and-proxy/agent/caching#api) page for detail number of older log file archives to keep. Defaults to `0` (no files are ever deleted). Set to `-1` to discard old log files when a new one is created. -### Configuration File Options +### Configuration file options These are the currently-available general configuration options: @@ -168,7 +168,7 @@ These are the currently-available general configuration options: - `log_rotate_max_files` - Equivalent to the [`-log-rotate-max-files` command-line flag](#_log_rotate_max_files). -### vault Stanza +### vault stanza There can at most be one top level `vault` block, and it has the following configuration entries: @@ -206,7 +206,7 @@ configuration entries: connecting via TLS. This value can be overridden by setting the `VAULT_TLS_SERVER_NAME` environment variable. -#### retry Stanza +#### retry stanza The `vault` stanza may contain a `retry` stanza that controls how failing Vault requests are handled, whether these requests are issued in order to render @@ -243,7 +243,7 @@ Third, the backoff algorithm used to set the time between retries differs for the template and cache subsystems. This is a technical limitation we hope to address in the future. -### listener Stanza +### listener stanza Vault Agent supports one or more [listener][listener_main] stanzas. Listeners can be configured with or without [caching][caching], but will use the cache if it @@ -263,11 +263,11 @@ listener configuration, an Agent's listener configuration also supports the foll - `agent_api` ([agent_api][agent-api]: ) - Manages optional Agent API endpoints. -#### agent_api Stanza +#### agent_api stanza - `enable_quit` `(bool: false)` - If set to `true`, the agent will enable the [quit](/vault/docs/agent-and-proxy/agent#quit) API. -### telemetry Stanza +### telemetry stanza Vault Agent supports the [telemetry][telemetry] stanza and collects various runtime metrics about its performance, the auto-auth and the cache status: @@ -282,7 +282,7 @@ runtime metrics about its performance, the auto-auth and the cache status: | `vault.agent.cache.hit` | Number of cache hits | counter | | `vault.agent.cache.miss` | Number of cache misses | counter | -## Start Vault Agent +## Start Vault agent To run Vault Agent: @@ -312,7 +312,7 @@ As with Vault, the `-config` flag can be used in three different ways: - Use the flag multiple times to name multiple configuration files, which will be composed at runtime. - Use the flag to name a directory of configuration files, the contents of which will be composed at runtime. -## Example Configuration +## Example configuration An example configuration, with very contrived values, follows: diff --git a/website/content/docs/agent-and-proxy/agent/process-supervisor.mdx b/website/content/docs/agent-and-proxy/agent/process-supervisor.mdx index c2f5d74b4a08..99a7f54781dc 100644 --- a/website/content/docs/agent-and-proxy/agent/process-supervisor.mdx +++ b/website/content/docs/agent-and-proxy/agent/process-supervisor.mdx @@ -6,7 +6,7 @@ description: >- into a process via environment variables using Consul Template markup. --- -# Vault Agent's Process Supervisor Mode +# Vault agent's process supervisor mode Vault Agent's Process Supervisor Mode allows Vault secrets to be injected into a process via environment variables using @@ -102,7 +102,7 @@ The top level `exec` block has the following configuration entries. to force the child process to stop. -## Configuration Example +## Configuration example The following example was generated using [`vault agent generate-config`](/vault/docs/agent-and-proxy/agent/generate-config), diff --git a/website/content/docs/agent-and-proxy/agent/template.mdx b/website/content/docs/agent-and-proxy/agent/template.mdx index a34821c29965..18bfbe447975 100644 --- a/website/content/docs/agent-and-proxy/agent/template.mdx +++ b/website/content/docs/agent-and-proxy/agent/template.mdx @@ -6,7 +6,7 @@ description: >- files using Consul Template markup. --- -# Vault Agent Templates +# Vault agent templates Vault Agent's Template functionality allows Vault secrets to be rendered to files or environment variables (via the [Process Supervisor Mode](/vault/docs/agent-and-proxy/agent/process-supervisor)) @@ -33,7 +33,7 @@ for a short while (including some randomness to help prevent thundering herd scenarios) and retry. On success, secrets defined in the templates will be retrieved from Vault and rendered locally. -## Templating Language +## Templating language The template output content can be provided directly as part of the `contents` option in a `template` stanza or as a separate `.ctmpl` file and specified in @@ -60,7 +60,7 @@ The following links contain additional resources for the templating language use - [Consul Templating Documentation][consul-templating-language] - [Go Templating Language Documentation](https://pkg.go.dev/text/template#pkg-overview) -### Template Language Example +### Template language example The following is an example of a template that retrieves a generic secret from Vault's KV store: @@ -93,7 +93,7 @@ To fetch only the issuing CA for this mount, use: Alternatively, `pki/cert/ca_chain` can be used to fetch the full CA chain. -## Global Configurations +## Global configurations The top level `template_config` block has the following configuration entries that affect all templates: @@ -107,7 +107,7 @@ failures. This setting will not change how often Vault Agent Templating renders leased secrets. Uses [duration format strings](/vault/docs/concepts/duration-format). -### `template_config` Stanza Example +### `template_config` stanza example ```hcl template_config { @@ -155,7 +155,7 @@ missing, but will only error for a missing key if `error_on_missing_key` is set. Whether Vault Agent will exit when the templating engine errors depends on the value of `exit_on_retry_failure`. -## Template Configurations +## Template configurations The top level `template` block has multiple configuration entries. The parameters found in the template configuration section in the consul-template @@ -219,7 +219,7 @@ cannot be used with `env_template` entries in process supervisor mode. a new template to disk and triggering a command, separated by a colon (`:`). -### Example `template` Stanza +### Example `template` stanza ```hcl template { @@ -233,31 +233,31 @@ If you only want to use the Vault agent to render one or more templates and do not need to sink the acquired credentials, you can omit the `sink` stanza from the `auto_auth` stanza in the agent configuration. -## Renewals and Updating Secrets +## Renewals and updating secrets The Vault Agent templating automatically renews and fetches secrets/tokens. Unlike [Vault Agent caching](/vault/docs/agent-and-proxy/agent/caching), the behavior of how Vault Agent templating does this depends on the type of secret or token. The following is a high level overview of different behaviors. -### Renewable Secrets +### Renewable secrets If a secret or token is renewable, Vault Agent will renew the secret after 2/3 of the secret's lease duration has elapsed. -### Non-Renewable Secrets +### Non-Renewable secrets If a secret or token isn't renewable or leased, Vault Agent will fetch the secret every 5 minutes. This can be configured using Template config [static_secret_render_interval](/vault/docs/agent-and-proxy/agent/template#static_secret_render_interval) (requires Vault 1.8+). Non-renewable secrets include (but not limited to) [KV Version 2](/vault/docs/secrets/kv/kv-v2). -### Non-Renewable Leased Secrets +### Non-Renewable leased secrets If a secret or token is non-renewable but leased, Vault Agent will fetch the secret when 85% of the secrets time-to-live (TTL) is reached. Leased, non-renewable secrets include (but not limited to) dynamic secrets such as [database credentials](/vault/docs/secrets/databases) and [KV Version 1](/vault/docs/secrets/kv/kv-v1). -### Static Roles +### Static roles If a secret has a `rotation_period`, such as a [database static role](/vault/docs/secrets/databases#static-roles), Vault Agent template will fetch the new secret as it changes in Vault. It does @@ -297,12 +297,12 @@ behaviors on certificates: fetches and re-renders a new certificate even if the existing certificate is valid. -## Templating Configuration Example +## Templating configuration example The following demonstrates Vault Agent Templates configuration blocks. ```hcl -# Other Vault Agent configuration blocks +# Other Vault agent configuration blocks # ... template_config { @@ -326,7 +326,7 @@ And the following demonstrates how the templates look when using `env_template` ```hcl -# Other Vault Agent configuration blocks +# Other Vault agent configuration blocks # ... template_config { diff --git a/website/content/docs/agent-and-proxy/agent/versions.mdx b/website/content/docs/agent-and-proxy/agent/versions.mdx index 17c39192ffce..788ea44e6b3f 100644 --- a/website/content/docs/agent-and-proxy/agent/versions.mdx +++ b/website/content/docs/agent-and-proxy/agent/versions.mdx @@ -5,7 +5,7 @@ description: |- Guidelines for running different versions of Agent and Server --- -# Running different versions of Agent and Server +# Running different versions of agent and server There is no requirement to run identical versions of Vault Agent and Vault Server. It is safe to run different versions, however you may not be able to take advantage of all the newest features in Vault if you do not upgrade to the most recent versions of Agent and Server. We recognize that this isn’t always possible, so we do support version mismatch as best as possible. @@ -14,7 +14,7 @@ As of Vault Agent 1.13.0, Agent will write a note to its logs when it detects a This document describes the common cases. There may be occasional exceptions, which if intentional will be called out in the CHANGELOG in a `CHANGES` section. If unintentional/undocumented these should be treated as bugs and reported. -## Older version of Agent than Server +## Older version of agent than server We do not anticipate any problems stemming from continuing to run an older Agent version after the server nodes are upgraded to a later version. Existing deployments using Agent should not be impacted, as we don't generally make backwards-incompatible changes to Vault Server. @@ -29,7 +29,7 @@ Templating: - the templating language features that interact with the Vault server use stable Vault APIs to retrieve and renew secrets - even if new secret engine types are introduced in newer Vault releases, these should not require an Agent upgrade to access via templates -## Newer version of Agent than Server +## Newer version of agent than server It is possible that an Agent could depend on features that don’t exist in older Server versions. diff --git a/website/content/docs/agent-and-proxy/agent/winsvc.mdx b/website/content/docs/agent-and-proxy/agent/winsvc.mdx index f67d7f96164a..2ab784c1017d 100644 --- a/website/content/docs/agent-and-proxy/agent/winsvc.mdx +++ b/website/content/docs/agent-and-proxy/agent/winsvc.mdx @@ -5,7 +5,7 @@ description: >- Vault Agent can be run as a Windows service. --- -# Vault Agent Windows Service +# Vault agent windows service Vault Agent can be run as a Windows service. In order to do this, you need to register Vault Agent with the Windows Service Control Manager. After Vault Agent is registered, it can be started like any other Windows @@ -13,7 +13,7 @@ service. **Note:** These commands should be run in a PowerShell session with Administrator capabilities. -## Register Vault Agent as a Windows service +## Register Vault agent as a windows service There are multiple ways to register Vault Agent as a Windows service. One way is to use [`sc.exe`](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/sc-create). `sc.exe` works @@ -77,7 +77,7 @@ If anything goes wrong during this process, and you need to manually edit the pa the following key: `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VaultAgent`. You can edit the `ImagePath` value at that key to the correct path. -## Start the Vault Agent service +## Start the Vault agent service There are multiple ways to start the service. @@ -86,7 +86,7 @@ There are multiple ways to start the service. - Go to the Windows Service Manager, and look for **VaultAgent** in the service name column. Click the `Start` button to start the service. -### Example starting Vault Agent using `sc.exe` +### Example starting Vault agent using `sc.exe` ```shell-session PS C:\Windows\system32> sc.exe start VaultAgent @@ -103,7 +103,7 @@ SERVICE_NAME: VaultAgent FLAGS : ``` -### Example starting Vault Agent using `Start-Service` +### Example starting Vault agent using `Start-Service` ```shell-session PS C:\Windows\system32> Start-Service -Name "VaultAgent" diff --git a/website/content/docs/agent-and-proxy/autoauth/index.mdx b/website/content/docs/agent-and-proxy/autoauth/index.mdx index a7231704e5df..9abb33ab0759 100644 --- a/website/content/docs/agent-and-proxy/autoauth/index.mdx +++ b/website/content/docs/agent-and-proxy/autoauth/index.mdx @@ -6,7 +6,7 @@ description: |- authentication to Vault in a variety of environments. --- -# Vault Agent and Vault Proxy Auto-Auth +# Vault agent and Vault proxy Auto-Auth The Auto-Auth functionality of Vault Agent and Vault Proxy allow for easy authentication in a wide variety of environments. @@ -27,7 +27,7 @@ allowed or fails, at which point it will attempt to reauthenticate. Every time an authentication is successful, the token is written to the configured Sinks, subject to their configuration. -## Advanced Functionality +## Advanced functionality Sinks support some advanced features, including the ability for the written values to be encrypted or @@ -36,7 +36,7 @@ values to be encrypted or Both mechanisms can be used concurrently; in this case, the value will be response-wrapped, then encrypted. -### Response-Wrapping Tokens +### Response-Wrapping tokens There are two ways that tokens can be response-wrapped: @@ -56,7 +56,7 @@ There are two ways that tokens can be response-wrapped: the token renewed for the end client and automatically reauthenticate when it expires. -### Encrypting Tokens +### Encrypting tokens ~> Support for encrypted tokens is experimental; if input/output formats change, we will make every effort to provide backwards compatibility. @@ -198,13 +198,13 @@ These configuration values are common to all Sinks: - `config` `(object: required)` - Configuration of the sink itself. See the sidebar for information about each sink. -### Auto Auth Examples +### Auto auth examples Auto-Auth configuration objects take two separate forms when specified in HCL and JSON. The following examples are meant to clarify the differences between the two formats. -#### Sinks (HCL Format) +#### Sinks (HCL format) The HCL format may define any number of sink objects with an optional wrapping `sinks {...}` object. diff --git a/website/content/docs/agent-and-proxy/autoauth/methods/alicloud.mdx b/website/content/docs/agent-and-proxy/autoauth/methods/alicloud.mdx index 3b252e09840b..87b0ff34498c 100644 --- a/website/content/docs/agent-and-proxy/autoauth/methods/alicloud.mdx +++ b/website/content/docs/agent-and-proxy/autoauth/methods/alicloud.mdx @@ -4,7 +4,7 @@ page_title: Vault Auto-Auth AliCloud Method description: AliCloud Method for Vault Auto-Auth --- -# Vault Agent Auto-Auth AliCloud Method +# Vault agent Auto-Auth AliCloud method The `alicloud` method performs authentication against the [AliCloud Auth method](/vault/docs/auth/alicloud). @@ -35,7 +35,7 @@ configuration. - `credential_poll_interval` `(integer: optional)` - In seconds, how frequently the Vault agent should check for new credentials. -### Optional Static Credential Configuration (Not Preferred) +### Optional static credential configuration (Not preferred) If instance metadata is not available, you may provide credential information through the parameters below. diff --git a/website/content/docs/agent-and-proxy/autoauth/methods/approle.mdx b/website/content/docs/agent-and-proxy/autoauth/methods/approle.mdx index 22b6236167d1..348985d80649 100644 --- a/website/content/docs/agent-and-proxy/autoauth/methods/approle.mdx +++ b/website/content/docs/agent-and-proxy/autoauth/methods/approle.mdx @@ -4,7 +4,7 @@ page_title: Vault Auto-Auth AppRole Method description: AppRole Method for Vault Auto-Auth --- -# Vault Auto-Auth AppRole Method +# Vault Auto-Auth AppRole method The `approle` method reads in a role ID and a secret ID from files and sends the values to the [AppRole Auth @@ -37,7 +37,7 @@ cached. `auth/approle/role/webservers/secret-id`) and the creation path for the response-wrapping token must match the value set here. -## Example Configuration +## Example configuration An example configuration, using approle to enable [auto-auth](/vault/docs/agent-and-proxy/autoauth) and creating both a plaintext token sink and a [response-wrapped token sink file](/vault/docs/agent-and-proxy/autoauth#wrap_ttl), follows: diff --git a/website/content/docs/agent-and-proxy/autoauth/methods/aws.mdx b/website/content/docs/agent-and-proxy/autoauth/methods/aws.mdx index 45f1b56ee057..8f3d8280a317 100644 --- a/website/content/docs/agent-and-proxy/autoauth/methods/aws.mdx +++ b/website/content/docs/agent-and-proxy/autoauth/methods/aws.mdx @@ -4,7 +4,7 @@ page_title: Vault Auto-Auth AWS Method description: AWS Method for Vault Auto-Auth --- -# Vault Auto-Auth AWS Method +# Vault Auto-Auth AWS method The `aws` method performs authentication against the [AWS Auth method](/vault/docs/auth/aws). Both `ec2` and `iam` diff --git a/website/content/docs/agent-and-proxy/autoauth/methods/azure.mdx b/website/content/docs/agent-and-proxy/autoauth/methods/azure.mdx index c97c809a8b37..aea9af4a9763 100644 --- a/website/content/docs/agent-and-proxy/autoauth/methods/azure.mdx +++ b/website/content/docs/agent-and-proxy/autoauth/methods/azure.mdx @@ -4,7 +4,7 @@ page_title: Vault Auto-Auth Azure Method description: Azure Method for Vault Auto-Auth --- -# Vault Auto-Auth Azure Method +# Vault Auto-Auth Azure method The `azure` method reads in Azure instance credentials and uses them to authenticate with the [Azure Auth diff --git a/website/content/docs/agent-and-proxy/autoauth/methods/cert.mdx b/website/content/docs/agent-and-proxy/autoauth/methods/cert.mdx index 623241e791a5..4c17ad7a0520 100644 --- a/website/content/docs/agent-and-proxy/autoauth/methods/cert.mdx +++ b/website/content/docs/agent-and-proxy/autoauth/methods/cert.mdx @@ -4,7 +4,7 @@ page_title: Vault Auto-Auth Cert Method description: Cert Method for Vault Auto-Auth --- -# Vault Auto-Auth Cert Method +# Vault Auto-Auth cert method The `cert` method uses the configured TLS certificates from the `vault` stanza of the agent configuration and takes an optional `name` parameter. There is no option diff --git a/website/content/docs/agent-and-proxy/autoauth/methods/cf.mdx b/website/content/docs/agent-and-proxy/autoauth/methods/cf.mdx index e4dd4e616c09..b6aa3dd48318 100644 --- a/website/content/docs/agent-and-proxy/autoauth/methods/cf.mdx +++ b/website/content/docs/agent-and-proxy/autoauth/methods/cf.mdx @@ -4,7 +4,7 @@ page_title: Vault Auto-Auth CF Method description: CF Method for Vault Auto-Auth --- -# Vault Agent Auto-Auth CF Method +# Vault agent Auto-Auth CF method The `cf` method performs authentication against the [CF Auth method](/vault/docs/auth/cf). diff --git a/website/content/docs/agent-and-proxy/autoauth/methods/gcp.mdx b/website/content/docs/agent-and-proxy/autoauth/methods/gcp.mdx index 758e24ad2119..51b1692d845e 100644 --- a/website/content/docs/agent-and-proxy/autoauth/methods/gcp.mdx +++ b/website/content/docs/agent-and-proxy/autoauth/methods/gcp.mdx @@ -4,7 +4,7 @@ page_title: Vault Auto-Auth GCP Method description: GCP Method for Vault Auto-Auth --- -# Vault Auto-Auth GCP Method +# Vault Auto-Auth GCP method The `gcp` method performs authentication against the [GCP Auth method](/vault/docs/auth/gcp). Both `gce` and `iam` diff --git a/website/content/docs/agent-and-proxy/autoauth/methods/index.mdx b/website/content/docs/agent-and-proxy/autoauth/methods/index.mdx index 321ef526e071..c9e7645e88a1 100644 --- a/website/content/docs/agent-and-proxy/autoauth/methods/index.mdx +++ b/website/content/docs/agent-and-proxy/autoauth/methods/index.mdx @@ -4,7 +4,7 @@ page_title: Vault Auto-Auth Methods description: Methods for Vault Auto-Auth --- -# Vault Auto-Auth Methods +# Vault Auto-Auth methods Auto-auth is a mechanism used by Vault Agent and Vault Proxy to authenticate to Vault in an automatic manner, given a set of parameters allowing the diff --git a/website/content/docs/agent-and-proxy/autoauth/methods/jwt.mdx b/website/content/docs/agent-and-proxy/autoauth/methods/jwt.mdx index fd8f6d9ed884..febb3c65da4d 100644 --- a/website/content/docs/agent-and-proxy/autoauth/methods/jwt.mdx +++ b/website/content/docs/agent-and-proxy/autoauth/methods/jwt.mdx @@ -4,7 +4,7 @@ page_title: Vault Auto-Auth JWT Method description: JWT Method for Vault Auto-Auth --- -# Vault Auto-Auth JWT Method +# Vault Auto-Auth JWT method The `jwt` method reads in a JWT from a file and sends it to the [JWT Auth method](/vault/docs/auth/jwt). diff --git a/website/content/docs/agent-and-proxy/autoauth/methods/kerberos.mdx b/website/content/docs/agent-and-proxy/autoauth/methods/kerberos.mdx index 6a725ea79b7f..d2f9979f58d6 100644 --- a/website/content/docs/agent-and-proxy/autoauth/methods/kerberos.mdx +++ b/website/content/docs/agent-and-proxy/autoauth/methods/kerberos.mdx @@ -6,7 +6,7 @@ description: |- Kerberos Method for Vault Auto-Auth --- -# Vault Auto-Auth Kerberos Method +# Vault Auto-Auth Kerberos method The `kerberos` auto-auth method provides an automated mechanism to retrieve a Vault token for Kerberos entities. It reads in configuration and diff --git a/website/content/docs/agent-and-proxy/autoauth/methods/kubernetes.mdx b/website/content/docs/agent-and-proxy/autoauth/methods/kubernetes.mdx index 227d0eaba73c..57e03ec65a7d 100644 --- a/website/content/docs/agent-and-proxy/autoauth/methods/kubernetes.mdx +++ b/website/content/docs/agent-and-proxy/autoauth/methods/kubernetes.mdx @@ -4,7 +4,7 @@ page_title: Vault Auto-Auth Kubernetes Method description: Kubernetes Method for Vault Auto-Auth --- -# Vault Auto-Auth Kubernetes Method +# Vault 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 diff --git a/website/content/docs/agent-and-proxy/autoauth/methods/oci.mdx b/website/content/docs/agent-and-proxy/autoauth/methods/oci.mdx index 680d2a9e32e1..643ad08b4da6 100644 --- a/website/content/docs/agent-and-proxy/autoauth/methods/oci.mdx +++ b/website/content/docs/agent-and-proxy/autoauth/methods/oci.mdx @@ -4,7 +4,7 @@ page_title: Vault Auto-Auth OCI (Oracle Cloud Infrastructure) Method description: OCI (Oracle Cloud Infrastructure) Method for Vault Auto-Auth --- -# Vault Auto-Auth OCI (Oracle Cloud Infrastructure) Method +# Vault Auto-Auth OCI (Oracle Cloud infrastructure) method The `oci` method performs authentication against the [OCI Auth method](/vault/docs/auth/oci). diff --git a/website/content/docs/agent-and-proxy/autoauth/methods/token_file.mdx b/website/content/docs/agent-and-proxy/autoauth/methods/token_file.mdx index d8f8cba2970b..69645d2c62d7 100644 --- a/website/content/docs/agent-and-proxy/autoauth/methods/token_file.mdx +++ b/website/content/docs/agent-and-proxy/autoauth/methods/token_file.mdx @@ -4,7 +4,7 @@ page_title: Vault Auto-Auth Token File Method description: Token File Method for Vault Auto-Auth --- -# Vault Auto-Auth Token File Method +# Vault Auto-Auth token file method ~> Note: This authentication method is tailored for the development experience, and to facilitate getting started with Vault Agent and Vault Proxy. Vault Agent and @@ -23,7 +23,7 @@ auto-auth method, such that Agent and Proxy are issuing their own own authentica - `token_file_path` `(string: required)` - The path to the file with the token inside. This token cannot be a wrapping token. -## Example Configuration +## Example configuration An example configuration for Vault Agent, using the `token_file` method to enable [auto-auth](/vault/docs/agent-and-proxy/autoauth), follows: diff --git a/website/content/docs/agent-and-proxy/autoauth/sinks/file.mdx b/website/content/docs/agent-and-proxy/autoauth/sinks/file.mdx index 5ac5ec42e8d4..9e96e8900eae 100644 --- a/website/content/docs/agent-and-proxy/autoauth/sinks/file.mdx +++ b/website/content/docs/agent-and-proxy/autoauth/sinks/file.mdx @@ -4,7 +4,7 @@ page_title: Vault Agent and Vault Proxy Auto-Auth File Sink description: File sink for Auto-Auth --- -# Vault Agent and Vault Proxy Auto-Auth File Sink +# Vault agent and Vault proxy Auto-Auth file sink The `file` sink writes tokens, optionally response-wrapped and/or encrypted, to a file. This may be a local file or a file mapped via some other process (NFS, diff --git a/website/content/docs/agent-and-proxy/autoauth/sinks/index.mdx b/website/content/docs/agent-and-proxy/autoauth/sinks/index.mdx index 62e7334c7e20..aa17397cc3f3 100644 --- a/website/content/docs/agent-and-proxy/autoauth/sinks/index.mdx +++ b/website/content/docs/agent-and-proxy/autoauth/sinks/index.mdx @@ -4,7 +4,7 @@ page_title: Vault Agent and Vault Proxy Auto-Auth Sinks description: Sinks for Auto-Auth --- -# Vault Agent and Vault Proxy Auto-Auth Sinks +# Vault agent and Vault proxy Auto-Auth sinks Every time an auto-auth authentication is successful, the token is written to the enabled Sinks, subject to their configuration. Today, we only support one diff --git a/website/content/docs/agent-and-proxy/index.mdx b/website/content/docs/agent-and-proxy/index.mdx index e9f82e7c9b44..a5b82aa8206b 100644 --- a/website/content/docs/agent-and-proxy/index.mdx +++ b/website/content/docs/agent-and-proxy/index.mdx @@ -6,7 +6,7 @@ description: |- functionality automatically. --- -# Vault Agent and Vault Proxy +# Vault agent and Vault proxy A valid client token must accompany most requests to Vault. This includes all API requests, as well as via the Vault CLI and other libraries. @@ -76,7 +76,7 @@ to update and maintain the Vault integration code for every application. When third party applications are being deployed by the application, it is prohibited to add the Vault integration code. -### Introduce Vault Agent and Vault Proxy to the workflow +### Introduce Vault agent and Vault proxy to the workflow [Vault Agent][vaultagent] and [Vault Proxy][vaultproxy] aim to remove this initial hurdle to adopt Vault by providing a more scalable and simpler way for applications to integrate with Vault. Vault Agent can diff --git a/website/content/docs/agent-and-proxy/proxy/apiproxy.mdx b/website/content/docs/agent-and-proxy/proxy/apiproxy.mdx index 85f143cbf5dc..be419f42ce42 100644 --- a/website/content/docs/agent-and-proxy/proxy/apiproxy.mdx +++ b/website/content/docs/agent-and-proxy/proxy/apiproxy.mdx @@ -6,7 +6,7 @@ description: >- for Vault's API. --- -# Vault Proxy API Proxy +# Vault proxy API proxy Vault Proxy's API Proxy functionality allows you to use Vault Proxy's API as a proxy for Vault's API. @@ -23,7 +23,7 @@ If a `listener` has been configured alongside a `cache` stanza, the API Proxy wi first attempt to utilize the cache subsystem for qualifying requests, before forwarding the request to Vault. See the [caching docs](/vault/docs/agent-and-proxy/proxy/caching) for more information on caching. -## Using Auto-Auth Token +## Using Auto-Auth token Vault Proxy allows for easy authentication to Vault in a wide variety of environments using [Auto-Auth](/vault/docs/agent-and-proxy/autoauth). By setting the @@ -35,7 +35,7 @@ configuration will be overridden if the request already has a token attached, in which case, the token present in the request will be used to forward the request to the Vault server. -## Forcing Auto-Auth Token +## Forcing Auto-Auth token Vault Proxy can be configured to force the use of the auto-auth token by using the value `force` for the `use_auto_auth_token` option. This configuration @@ -66,13 +66,13 @@ or `"never"`. - `when_inconsistent` `(string: optional)` - Set to one of `"fail"`, `"retry"`, or `"forward"`. -### Example Configuration +### Example configuration Here is an example of a `listener` configuration alongside `api_proxy` configuration to force the use of the auto_auth token and enforce consistency. ```hcl -# Other Vault Proxy configuration blocks +# Other Vault proxy configuration blocks # ... api_proxy { diff --git a/website/content/docs/agent-and-proxy/proxy/caching/index.mdx b/website/content/docs/agent-and-proxy/proxy/caching/index.mdx index 948de6dafc5e..2af24af35e28 100644 --- a/website/content/docs/agent-and-proxy/proxy/caching/index.mdx +++ b/website/content/docs/agent-and-proxy/proxy/caching/index.mdx @@ -7,7 +7,7 @@ description: |- newly created tokens. --- -# Vault Proxy Caching +# Vault proxy caching Vault Proxy Caching allows client-side caching of responses containing newly created tokens and responses containing leased secrets generated off of these @@ -19,7 +19,7 @@ running on Vault 1.1 and above due to changes that were introduced alongside this feature, such as the exposure of the `orphan` field in token creation responses. -## Caching and Renewals +## Caching and renewals Response caching and renewals are managed by the proxy only under these specific scenarios. @@ -36,7 +36,7 @@ specific scenarios. that are issued using the tokens managed by the proxy, will be cached and its renewals are taken care of. -## Persistent Cache +## Persistent cache Vault Proxy can restore tokens and leases from a persistent cache file created by a previous Vault Proxy process. @@ -45,7 +45,7 @@ Refer to the [Vault Proxy Persistent Caching](/vault/docs/agent-and-proxy/proxy/caching/persistent-caches) page for more information on this functionality. -## Cache Evictions +## Cache evictions The eviction of cache entries pertaining to secrets will occur when the proxy can no longer renew them. This can happen when the secrets hit their maximum @@ -66,7 +66,7 @@ entries. For managing the stale entries in the cache, an endpoint `/proxy/v1/cache-clear`(see below) is made available to manually evict cache entries based on some of the query criteria used for indexing the cache entries. -## Request Uniqueness +## Request uniqueness In order to detect repeat requests and return cached responses, proxy will need to have a way to uniquely identify the requests. This computation as it stands @@ -83,7 +83,7 @@ assumption that the clients will use consistent mechanisms to make requests, thereby resulting in consistent hash values per request is the idea upon which the caching functionality is built upon. -## Renewal Management +## Renewal management The tokens and leases are renewed by the proxy using the secret renewer that is made available via the Vault server's [Go @@ -97,7 +97,7 @@ secrets are no longer performed by the Vault proxy. ## API -### Cache Clear +### Cache clear This endpoint clears the cache based on given criteria. To use this API, some information on how the proxy caches values should be known @@ -129,7 +129,7 @@ but will do nothing (there is no cache to clear) and will return a `200` respons `request_path`. The namespace of which the cache entries to be evicted for the given request path. -### Sample Payload +### Sample payload ```json { @@ -138,7 +138,7 @@ but will do nothing (there is no cache to clear) and will return a `200` respons } ``` -### Sample Request +### Sample request ```shell-session $ curl \ @@ -211,13 +211,13 @@ or the default role, `default`, which serves everything (including metrics). - `tls_cert_file` `(string: optional)` - Specifies the path to the certificate for TLS. -### Example Configuration +### Example configuration Here is an example of a cache configuration with the optional `persist` block, alongside a regular listener, and a listener that only serves metrics. ```hcl -# Other Vault Proxy configuration blocks +# Other Vault proxy configuration blocks # ... cache { diff --git a/website/content/docs/agent-and-proxy/proxy/caching/persistent-caches/index.mdx b/website/content/docs/agent-and-proxy/proxy/caching/persistent-caches/index.mdx index 7458dee0dd2f..0757c9a3f67f 100644 --- a/website/content/docs/agent-and-proxy/proxy/caching/persistent-caches/index.mdx +++ b/website/content/docs/agent-and-proxy/proxy/caching/persistent-caches/index.mdx @@ -4,7 +4,7 @@ page_title: Vault Proxy Persistent Caching description: Vault Proxy Caching --- -# Vault Proxy Persistent Caching +# Vault proxy persistent caching Vault Proxy can restore tokens and leases from a persistent cache file created by a previous Vault Proxy process. The persistent cache is a BoltDB file that @@ -22,16 +22,16 @@ be invalidated and secrets will need to be re-fetched from Vault. -> **Note** Vault Proxy persistent cache is currently supported only in a Kubernetes environment. -## Vault Proxy Persistent Cache Types +## Vault proxy persistent cache types Please see the sidebar for available types and their usage/configuration. -## Persistent Cache Example Configuration +## Persistent cache example configuration Here is an example of a persistent cache configuration. ```hcl -# Other Vault Proxy configuration blocks +# Other Vault proxy configuration blocks # ... cache { diff --git a/website/content/docs/agent-and-proxy/proxy/caching/persistent-caches/kubernetes.mdx b/website/content/docs/agent-and-proxy/proxy/caching/persistent-caches/kubernetes.mdx index e3428080f6ff..00be543d0abb 100644 --- a/website/content/docs/agent-and-proxy/proxy/caching/persistent-caches/kubernetes.mdx +++ b/website/content/docs/agent-and-proxy/proxy/caching/persistent-caches/kubernetes.mdx @@ -4,7 +4,7 @@ page_title: Kubernetes - Vault Proxy Persistent Cache description: Kubernetes Persistent Cache for Vault Proxy Caching --- -# Vault Proxy Kubernetes Persistent Cache +# Vault proxy kubernetes persistent cache When `kubernetes` is configured for the persistent cache type, Vault Proxy will optimize the persistent cache specifically for Kubernetes. This type of persistent cache requires a Kubernetes diff --git a/website/content/docs/agent-and-proxy/proxy/index.mdx b/website/content/docs/agent-and-proxy/proxy/index.mdx index 17bf746e81d7..8520a20892a1 100644 --- a/website/content/docs/agent-and-proxy/proxy/index.mdx +++ b/website/content/docs/agent-and-proxy/proxy/index.mdx @@ -6,7 +6,7 @@ description: |- functionality automatically, and act as a proxy for Vault's APIs. --- -# What is Vault Proxy? +# What is Vault proxy? Vault Proxy aims to remove the initial hurdle to adopt Vault by providing a more scalable and simpler way for applications to integrate with Vault. @@ -31,7 +31,7 @@ for information. Auto-Auth functionality takes place within an `auto_auth` configuration stanza. -## API Proxy +## API proxy Vault Proxy's primary purpose is to act as an API proxy for Vault, allowing you to talk to Vault's API via a listener. It can be configured to optionally allow or force the automatic use of @@ -65,7 +65,7 @@ See the [caching](/vault/docs/agent-and-proxy/proxy/caching#api) page for detail ## Configuration -### Command Options +### Command options - `-log-level` ((#\_log_level)) `(string: "info")` - Log verbosity level. Supported values (in order of descending detail) are `trace`, `debug`, `info`, `warn`, and `error`. This can @@ -96,7 +96,7 @@ value such as 30s. Defaults to 24h. number of older log file archives to keep. Defaults to `0` (no files are ever deleted). Set to `-1` to discard old log files when a new one is created. -### Configuration File Options +### Configuration file options These are the currently-available general configuration options: @@ -151,7 +151,7 @@ specified by configuration file (including overriding values set using CLI or en - `log_rotate_max_files` - Equivalent to the [`-log-rotate-max-files` command-line flag](#_log_rotate_max_files). -### vault Stanza +### vault stanza There can at most be one top level `vault` block, and it has the following configuration entries: @@ -189,7 +189,7 @@ be overridden by setting the `VAULT_SKIP_VERIFY` environment variable. connecting via TLS. This value can be overridden by setting the `VAULT_TLS_SERVER_NAME` environment variable. -#### retry Stanza +#### retry stanza The `vault` stanza may contain a `retry` stanza that controls how failing Vault requests are handled. Auto-auth, however, has its own notion of retrying and is not @@ -209,7 +209,7 @@ result codes: any 50x code except 501 ("not implemented"), as well as 412 stale read due to eventual consistency. Requests coming from the template subsystem are retried regardless of the failure. -### listener Stanza +### listener stanza Vault Proxy supports one or more [listener][listener_main] stanzas. Listeners can be configured with or without [caching][caching], but will use the cache if it @@ -229,11 +229,11 @@ to `metrics_only` listeners. - `proxy_api` ([proxy_api][proxy-api]: ) - Manages optional Proxy API endpoints. -#### proxy_api Stanza +#### proxy_api stanza - `enable_quit` `(bool: false)` - If set to `true`, the Proxy will enable the [quit](/vault/docs/agent-and-proxy/proxy#quit) API. -### telemetry Stanza +### telemetry stanza Vault Proxy supports the [telemetry][telemetry] stanza and collects various runtime metrics about its performance, the auto-auth and the cache status: @@ -248,7 +248,7 @@ runtime metrics about its performance, the auto-auth and the cache status: | `vault.proxy.cache.hit` | Number of cache hits | counter | | `vault.proxy.cache.miss` | Number of cache misses | counter | -## Start Vault Proxy +## Start Vault proxy To run Vault Proxy: @@ -278,7 +278,7 @@ As with Vault, the `-config` flag can be used in three different ways: - Use the flag multiple times to name multiple configuration files, which will be composed at runtime. - Use the flag to name a directory of configuration files, the contents of which will be composed at runtime. -## Example Configuration +## Example configuration An example configuration, with very contrived values, follows: diff --git a/website/content/docs/agent-and-proxy/proxy/versions.mdx b/website/content/docs/agent-and-proxy/proxy/versions.mdx index a1fb158e882b..5c2c9db3ea53 100644 --- a/website/content/docs/agent-and-proxy/proxy/versions.mdx +++ b/website/content/docs/agent-and-proxy/proxy/versions.mdx @@ -5,7 +5,7 @@ description: |- Guidelines for running different versions of Proxy and Server --- -# Running different versions of Proxy and Server +# Running different versions of proxy and server There is no requirement to run identical versions of Vault Proxy and Vault Server. It is safe to run different versions, however you may not be able to take advantage of all the newest features in Vault if you do not upgrade to the most recent versions of Proxy and Server. We recognize that this isn’t always possible, so we do support version mismatch as best as possible. @@ -14,7 +14,7 @@ Proxy will write a note to its logs when it detects a mismatch between Proxy and This document describes the common cases. There may be occasional exceptions, which if intentional will be called out in the CHANGELOG in a `CHANGES` section. If unintentional/undocumented these should be treated as bugs and reported. -## Older version of Proxy than Server +## Older version of proxy than server We do not anticipate any problems stemming from continuing to run an older Proxy version after the server nodes are upgraded to a later version. Existing deployments using Proxy should not be impacted, as we don't generally make backwards-incompatible changes to Vault Server. @@ -25,7 +25,7 @@ Auto-auth: Proxy: - since Proxy simply mirrors the incoming requests, even if an incoming request uses an endpoint that didn't exist when that version of Proxy was compiled, that won't impede Proxy's ability to proxy the request -## Newer version of Proxy than Server +## Newer version of proxy than server It is possible that an Proxy could depend on features that don’t exist in older Server versions. diff --git a/website/content/docs/audit/file.mdx b/website/content/docs/audit/file.mdx index 41da0ad865ff..bda7ddb8df07 100644 --- a/website/content/docs/audit/file.mdx +++ b/website/content/docs/audit/file.mdx @@ -4,7 +4,7 @@ page_title: File - Audit Devices description: The "file" audit device writes audit logs to a file. --- -# File Audit Device +# File audit device The `file` audit device writes audit logs to a file. This is a very simple audit device: it appends logs to a file. @@ -60,6 +60,6 @@ these device-specific options: -## Log File Rotation +## Log file rotation To properly rotate Vault File Audit Device log files on BSD, Darwin, or Linux-based Vault servers, it is important that you configure your log rotation software to send the `vault` process a signal hang up / `SIGHUP` after each rotation of the log file. diff --git a/website/content/docs/audit/index.mdx b/website/content/docs/audit/index.mdx index e48fb1337b7a..1d61de62363c 100644 --- a/website/content/docs/audit/index.mdx +++ b/website/content/docs/audit/index.mdx @@ -4,14 +4,14 @@ page_title: Audit Devices description: Audit devices are mountable devices that log requests and responses in Vault. --- -# Audit Devices +# Audit devices Audit devices are the components in Vault that collectively keep a detailed log of all requests and response to Vault. Because every operation with Vault is an API request/response, when using a single audit device, the audit log contains _every authenticated_ interaction with Vault, including errors. -## Enabling Multiple Devices +## Enabling multiple devices When multiple audit devices are enabled, Vault will attempt to send the audit logs to all of them. This allows you to not only have redundant copies, but also @@ -36,7 +36,7 @@ The line contains all of the information for any given request and response. By default, all the sensitive information is first hashed before logging in the audit logs. -## Sensitive Information +## Sensitive information The audit logs contain the full request and response objects for every interaction with Vault. The request and response can be matched utilizing a @@ -59,7 +59,7 @@ While most strings are hashed, Vault does make some exceptions, such as auth and [auth tune](/vault/docs/commands/auth/tune) -## Enabling/Disabling Audit Devices +## Enabling/Disabling audit devices When a Vault server is first initialized, no auditing is enabled. Audit devices must be enabled by a root user using `vault audit enable`. @@ -89,7 +89,7 @@ The existing logs that it did store are untouched. for comparison with entries in the audit logs. This is true even if you re-enable the audit device at the same path, as a new salt will be created for hashing. -## Blocked Audit Devices +## Blocked audit devices Audit device logs are critically important and ignoring auditing failures opens an avenue for attack. Vault will not respond to requests when no enabled audit devices can record them. diff --git a/website/content/docs/audit/socket.mdx b/website/content/docs/audit/socket.mdx index 4daa56874be4..08316afc0dc3 100644 --- a/website/content/docs/audit/socket.mdx +++ b/website/content/docs/audit/socket.mdx @@ -4,7 +4,7 @@ page_title: Socket - Audit Devices description: The "socket" audit device writes audit writes to a TCP or UDP socket. --- -# Socket Audit Device +# Socket audit device The `socket` audit device writes to a TCP, UDP, or UNIX socket. diff --git a/website/content/docs/audit/syslog.mdx b/website/content/docs/audit/syslog.mdx index ca114d3d1387..2aae6e6a0e21 100644 --- a/website/content/docs/audit/syslog.mdx +++ b/website/content/docs/audit/syslog.mdx @@ -4,7 +4,7 @@ page_title: Syslog - Audit Devices description: The "syslog" audit device writes audit logs to syslog. --- -# Syslog Audit Device +# Syslog audit device The `syslog` audit device writes audit logs to syslog. diff --git a/website/content/docs/auth/alicloud.mdx b/website/content/docs/auth/alicloud.mdx index 4c67ebfd8af3..e5db4c81712f 100644 --- a/website/content/docs/auth/alicloud.mdx +++ b/website/content/docs/auth/alicloud.mdx @@ -4,7 +4,7 @@ page_title: AliCloud - Auth Methods description: The AliCloud auth method allows automated authentication of AliCloud entities. --- -# AliCloud Auth Method +# AliCloud auth method The `alicloud` auth method provides an automated mechanism to retrieve a Vault token for AliCloud entities. Unlike most Vault auth methods, this @@ -18,7 +18,7 @@ that's ideally suited for the purpose. By launching an instance with a role, the role's STS credentials under instance metadata can be used to securely build the request. -## Authentication Workflow +## Authentication workflow The AliCloud STS API includes a method, [`sts:GetCallerIdentity`](https://www.alibabacloud.com/help/doc-detail/43767.htm), @@ -46,7 +46,7 @@ non-MFA authenticated credentials will still be able to authenticate to Vault using this method. It does not appear possible to enforce a RAM principal to be MFA authenticated while authenticating to Vault. -## Authorization Workflow +## Authorization workflow The basic mechanism of operation is per-role. diff --git a/website/content/docs/auth/approle.mdx b/website/content/docs/auth/approle.mdx index 085eabf1983c..f96f58777722 100644 --- a/website/content/docs/auth/approle.mdx +++ b/website/content/docs/auth/approle.mdx @@ -6,7 +6,7 @@ description: |- Vault. --- -# AppRole Auth Method +# AppRole auth method The `approle` auth method allows machines or _apps_ to authenticate with Vault-defined _roles_. The open design of `AppRole` enables a varied set of @@ -205,7 +205,7 @@ AppRole either via generation of a 128-bit purely random UUID by the role itself (`Pull` mode) or via specific, custom values (`Push` mode). Similarly to tokens, SecretIDs have properties like usage-limit, TTLs and expirations. -#### Pull And Push SecretID Modes +#### Pull and push SecretID modes If the SecretID used for login is fetched from an AppRole, this is operating in Pull mode. If a "custom" SecretID is set against an AppRole by the client, it @@ -222,7 +222,7 @@ Push mode is available for App-ID workflow compatibility, which in some specific cases is preferable, but in most cases Pull mode is more secure and should be preferred. -### Further Constraints +### Further constraints `role_id` is a required credential at the login endpoint. AppRole pointed to by the `role_id` will have constraints set on it. This dictates other `required` @@ -245,7 +245,7 @@ The AppRole auth method has a full HTTP API. Please see the [AppRole API](/vault/api-docs/auth/approle) for more details. -## Code Example +## Code example The following example demonstrates AppRole authentication with response wrapping. diff --git a/website/content/docs/auth/aws.mdx b/website/content/docs/auth/aws.mdx index 6a50945b021a..3cb08567d06a 100644 --- a/website/content/docs/auth/aws.mdx +++ b/website/content/docs/auth/aws.mdx @@ -4,7 +4,7 @@ page_title: AWS - Auth Methods description: The aws auth method allows automated authentication of AWS entities. --- -# AWS Auth Method +# AWS auth method @include 'x509-sha1-deprecation.mdx' @@ -16,7 +16,7 @@ method does not require manual first-deploying, or provisioning security-sensitive credentials (tokens, username/password, client certificates, etc), by operators under many circumstances. -## Authentication Workflow +## Authentication workflow There are two authentication types present in the aws auth method: `iam` and `ec2`. @@ -112,7 +112,7 @@ is also represented in the graphic below) is as follows: There are various modifications to this workflow that provide more or less security, as detailed later in this documentation. -## Authorization Workflow +## Authorization workflow The basic mechanism of operation is per-role. Roles are registered in the method and associated with a specific authentication type that cannot be @@ -162,7 +162,7 @@ the method to verify the authenticity of a found role tag and ensure that it has not been tampered with. There is also a mechanism to deny list role tags if one has been found to be distributed outside of its intended set of machines. -## IAM Authentication Inferences +## IAM authentication inferences With the iam auth method, normally Vault will see the IAM principal that authenticated, either the IAM user or role. However, when you have an EC2 @@ -211,7 +211,7 @@ that Vault cannot offer an iron-clad guarantee about the inference and it is up to operators to determine, based on their own AWS controls and use cases, whether or not it's appropriate to configure inferencing. -## Mixing Authentication Types +## Mixing authentication types Vault allows you to configure using either the ec2 auth method or the iam auth method, but not both auth methods. Further, Vault will prevent you from @@ -227,7 +227,7 @@ role. Some examples of how this works in practice: must login using the iam method; the RoleSessionName must be a valid instance ID viewable by Vault, and the instance must have come from the bound AMI ID. -## Comparison of the IAM and EC2 Methods +## Comparison of the IAM and EC2 methods The iam and ec2 auth methods serve similar and somewhat overlapping functionality, in that both authenticate some type of AWS entity to Vault. @@ -282,7 +282,7 @@ Here are some comparisons that illustrate why `iam` method is preferred over to, or make use of inferencing. If you need to make use of role tags, then you will need to use the ec2 auth method. -## Recommended Vault IAM Policy +## Recommended Vault IAM policy This specifies the recommended IAM policy needed by the AWS auth method. Note that if you are using the same credentials for the AWS auth and secret methods @@ -351,7 +351,7 @@ are needed. [Rotate Root Credentials](/vault/api-docs/auth/aws#rotate-root-credentials) API call. -## Client Nonce +## Client nonce Note: this only applies to the ec2 auth method. @@ -412,9 +412,9 @@ along with the authentication response, will be audit logged in plaintext. If this is undesired, clients can supply a custom nonce to the login endpoint which will not be returned and hence will not be audit logged. -## Advanced Options and Caveats +## Advanced options and caveats -### Dynamic Management of Policies Via Role Tags +### Dynamic management of policies via role tags Note: This only applies to the ec2 auth method or the iam auth method when inferencing is used. @@ -447,7 +447,7 @@ This can be useful to allow instances access to a secure "scratch space" for storing data (via the token's cubbyhole) but without granting any access to other resources provided by or resident in Vault. -### Handling Lost Client Nonces +### Handling lost client nonces Note: This only applies to the ec2 auth method. @@ -486,7 +486,7 @@ option is set to `false` on the role, a value of `true` in the role tag takes effect; however, if the option is set to `true` on the role, a value set in the role tag has no effect. -### Disabling Reauthentication +### Disabling reauthentication Note: this only applies to the ec2 auth method. @@ -509,7 +509,7 @@ option is set to `false` on the role, a value of `true` in the role tag takes effect; however, if the option is set to `true` on the role, a value set in the role tag has no effect. -### Deny listing Role Tags +### Deny listing role tags Note: this only applies to the ec2 auth method or the iam auth method when inferencing is used. @@ -524,7 +524,7 @@ further effect, the role tag can be placed on a `deny list` via the endpoint tokens that were already issued; this only blocks any further login requests from those instances that have the deny listed tag attached to them. -### Expiration Times and Tidying of `denylist` and `accesslist` Entries +### Expiration times and tidying of `denylist` and `accesslist` entries The expired entries in both identity `accesslist` and role tag `denylist` are deleted automatically. The entries in both of these lists contain an expiration @@ -547,7 +547,7 @@ were expired before 72 hours from when the tidy operation is being performed. This can be configured via `config/tidy/roletag-denylist` and `config/tidy/identity-accesslist` endpoints. -### Varying Public Certificates +### Varying public certificates Note: this only applies to the ec2 auth method. @@ -559,7 +559,7 @@ verified by the default public certificate included in Vault can register a different public certificate which can be found [here](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-identity-documents.html), via the `auth/aws/config/certificate/` endpoint. -### Dangling Tokens +### Dangling tokens An EC2 instance, after authenticating itself with the method, gets a Vault token. After that, if the instance terminates or goes down for any reason, the method @@ -567,7 +567,7 @@ will not be aware of such events. The token issued will still be valid, until it expires. The token will likely be expired sooner than its lifetime when the instance fails to renew the token on time. -### Cross Account Access +### Cross account access To allow Vault to authenticate IAM principals and EC2 instances in other accounts, Vault supports using AWS STS (Security Token Service) to assume AWS @@ -585,7 +585,7 @@ Policy](#recommended-vault-iam-policy) except it doesn't need any further Furthermore, in the master account, Vault must be granted the action `sts:AssumeRole` for the IAM Role to be assumed. -### AWS Instance Metadata Timeout +### AWS instance metadata timeout @include 'aws-imds-timeout.mdx' @@ -622,7 +622,7 @@ $ vault write auth/aws/role/dev-role-iam auth_type=iam \ bound_iam_principal_arn=arn:aws:iam::123456789012:role/MyRole policies=prod,dev max_ttl=500h ``` -#### Configure a required X-Vault-AWS-IAM-Server-ID Header (recommended) +#### Configure a required X-Vault-AWS-IAM-Server-ID header (recommended) ```shell-session $ vault write auth/aws/config/client iam_server_id_header_value=vault.example.com @@ -761,7 +761,7 @@ The AWS auth method has a full HTTP API. Please see the [AWS Auth API](/vault/api-docs/auth/aws) for more details. -## Code Example +## Code example The following example demonstrates the AWS (IAM) auth method to authenticate with Vault. diff --git a/website/content/docs/auth/azure.mdx b/website/content/docs/auth/azure.mdx index de44c2fefca1..dae629a2ed66 100644 --- a/website/content/docs/auth/azure.mdx +++ b/website/content/docs/auth/azure.mdx @@ -6,7 +6,7 @@ description: |- Directory. --- -# Azure Auth Method +# Azure auth method The `azure` auth method allows authentication against Vault using Azure Active Directory credentials. It treats Azure as a Trusted Third Party @@ -39,7 +39,7 @@ The following Azure [role assignments](https://learn.microsoft.com/en-us/azure/r must be granted to the Azure AD application in order for the auth method to access Azure APIs during authentication. -### Role Assignments +### Role assignments ~> **Note:** The role assignments are only required when the [`vm_name`](/vault/api-docs/auth/azure#vm_name), [`vmss_name`](/vault/api-docs/auth/azure#vmss_name), @@ -56,7 +56,7 @@ or [`resource_id`](/vault/api-docs/auth/azure#resource_id) parameters are used o [vmss-flex]: https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-orchestration-modes#scale-sets-with-flexible-orchestration [managed-identities]: https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/managed-identities-status -### API Permissions +### API permissions The following [API permissions](https://learn.microsoft.com/en-us/azure/active-directory/develop/permissions-consent-overview#types-of-permissions) must be assigned to the service principal provided to Vault for managing the root rotation in Azure: @@ -199,7 +199,7 @@ tool. https://127.0.0.1:8200/v1/auth/azure/role/dev-role ``` -## Azure Managed Identities +## Azure managed identities There are two types of [managed identities](https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview#managed-identity-types) in Azure: System-assigned and User-assigned. System-assigned identities are unique to @@ -217,7 +217,7 @@ for more info. [id-limitations]: https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/managed-identity-best-practice-recommendations#limitation-of-using-managed-identities-for-authorization -## Azure Debug Logs +## Azure debug logs The Azure auth plugin supports debug logging which includes additional information about requests and responses from the Azure API. @@ -233,7 +233,7 @@ AZURE_GO_SDK_LOG_LEVEL=DEBUG The Azure Auth Plugin has a full HTTP API. Please see the [API documentation](/vault/api-docs/auth/azure) for more details. -## Code Example +## Code example The following example demonstrates the Azure auth method to authenticate with Vault. diff --git a/website/content/docs/auth/cert.mdx b/website/content/docs/auth/cert.mdx index b1f481c85241..d5dc3afa1d95 100644 --- a/website/content/docs/auth/cert.mdx +++ b/website/content/docs/auth/cert.mdx @@ -6,7 +6,7 @@ description: >- client certificates. --- -# TLS Certificates Auth Method +# TLS certificates auth method @include 'x509-sha1-deprecation.mdx' @@ -25,7 +25,7 @@ lower-case. Please note that to use this auth method, `tls_disable` must be false in the Vault configuration. This is because the certificates are sent through TLS communication itself. -## Revocation Checking +## Revocation checking Since Vault 0.4, the method supports revocation checking. diff --git a/website/content/docs/auth/cf.mdx b/website/content/docs/auth/cf.mdx index 78a7621682a5..1c8b94d383e5 100644 --- a/website/content/docs/auth/cf.mdx +++ b/website/content/docs/auth/cf.mdx @@ -4,7 +4,7 @@ page_title: Cloud Foundry - Auth Methods description: The cf auth method allows automated authentication of Cloud Foundry instances. --- -# Cloud Foundry (CF) Auth Method +# Cloud Foundry (CF) auth method @include 'x509-sha1-deprecation.mdx' @@ -19,7 +19,7 @@ At a high level, this works as follows: 5. Vault validates that the `CF_INSTANCE_CERT` application ID, space ID, and org ID presently exist. 6. If all checks pass, Vault issues an appropriately-scoped token. -## Known Risks +## Known risks This authentication engine uses CF's instance identity service to authenticate users to Vault. Because CF makes its CA certificate and private key available to certain users at any time, it's possible for @@ -35,7 +35,7 @@ system, or through carefully limiting the users who can access CredHub. ## Usage -### Preparing to Configure the Plugin +### Preparing to configure the plugin To configure this plugin, you'll need to gather the CA certificate that CF uses to issue each `CF_INSTANCE_CERT`, and you'll need to configure it to access the CF API. diff --git a/website/content/docs/auth/gcp.mdx b/website/content/docs/auth/gcp.mdx index 1b44e5139bf1..c276cab2e953 100644 --- a/website/content/docs/auth/gcp.mdx +++ b/website/content/docs/auth/gcp.mdx @@ -6,7 +6,7 @@ description: |- Google Cloud service accounts. --- -# Google Cloud Auth Method +# Google Cloud auth method The `gcp` auth method allows Google Cloud Platform entities to authenticate to Vault. Vault treats Google Cloud as a trusted third party and verifies @@ -28,7 +28,7 @@ repository. ## Authentication -### Via the CLI Helper +### Via the CLI helper Vault includes a CLI helper that obtains a signed JWT locally and sends the request to Vault. @@ -128,7 +128,7 @@ management tool. For the complete list of configuration options for each type, please see the [API documentation][api-docs]. -## GCP Credentials +## GCP credentials The Google Cloud Vault auth method uses the official Google Cloud Golang SDK. This means it supports the common ways of [providing credentials to Google @@ -152,7 +152,7 @@ scope: https://www.googleapis.com/auth/cloud-platform ``` -### Required GCP Permissions +### Required GCP permissions #### Enabled GCP APIs @@ -165,7 +165,7 @@ The GCP project must have the following APIs enabled: - [cloudresourcemanager.googleapis.com](https://console.cloud.google.com/flows/enableapi?apiid=cloudresourcemanager.googleapis.com) for `iam` and `gce` type roles that set [`add_group_aliases`](/vault/api-docs/auth/gcp#add_group_aliases) to true. -#### Vault Server Permissions +#### Vault server permissions **For `iam`-type Vault roles**, the service account [`credentials`](/vault/api-docs/auth/gcp#credentials) given to Vault can have the following role: @@ -204,7 +204,7 @@ These allow Vault to: If you are using Group Aliases as described below, you will also need to add the `resourcemanager.projects.get` permission. -#### Permissions For Authenticating Against Vault +#### Permissions for authenticating against Vault If you are authenticating to Vault from Google Cloud, you can skip the following step as Vault will generate and present the identity token of the service account configured @@ -224,7 +224,7 @@ account to impersonate any service account in the GCP project where it resides. See [Managing service account impersonation](https://cloud.google.com/iam/docs/impersonating-service-accounts) for more information. -## Group Aliases +## Group aliases As of Vault 1.0, roles can specify an `add_group_aliases` boolean parameter that adds [group aliases][identity-group-aliases] to the auth response. These @@ -244,14 +244,14 @@ will include the following aliases: If you are using a custom role for Vault server, you will need to add the `resourcemanager.projects.get` permission to your custom role. -## Implementation Details +## Implementation details This section describes the implementation details for how Vault communicates with Google Cloud to authenticate and authorize JWT tokens. This information is provided for those who are curious, but these details are not required knowledge for using the auth method. -### IAM Login +### IAM login IAM login applies only to roles of type `iam`. The Vault authentication workflow for IAM service accounts looks like this: @@ -272,7 +272,7 @@ for IAM service accounts looks like this: 4. Vault authorizes the confirmed service account against the given role. If that is successful, a Vault token with the proper policies is returned. -### GCE Login +### GCE login GCE login only applies to roles of type `gce` and **must be completed on an infrastructure running on Google Cloud**. These steps will not work from your @@ -298,14 +298,14 @@ local laptop or another cloud provider. This section details the various methods and examples for obtaining JWT tokens. -### Service Account Credentials API +### Service account credentials API This describes how to use the GCP Service Account Credentials [API method][signjwt-method] directly to generate the signed JWT with the claims that Vault expects. Note the CLI does this process for you and is much easier, and that there is very little reason to do this yourself. -#### curl Example +#### curl example Vault requires the following minimum claim set: @@ -343,7 +343,7 @@ $ curl \ "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/${SERVICE_ACCOUNT}:signJwt" ``` -#### gcloud Example +#### gcloud example You can also do this through the (currently beta) gcloud command. Note that you will be required to provide the expiration claim `exp` as a part of the JWT input to the @@ -355,7 +355,7 @@ $ gcloud beta iam service-accounts sign-jwt $INPUT_JWT_CLAIMS $OUTPUT_JWT_FILE \ --project=my-project ``` -#### Golang Example +#### Golang example Read more on the [Google Open Source blog](https://opensource.googleblog.com/2017/08/hashicorp-vault-and-google-cloud-iam.html). @@ -405,7 +405,7 @@ The GCP Auth Plugin has a full HTTP API. Please see the [instance-identity]: https://cloud.google.com/compute/docs/instances/verifying-instance-identity [repo]: https://github.com/hashicorp/vault-plugin-auth-gcp -## Code Example +## Code example The following example demonstrates the Google Cloud auth method to authenticate with Vault. diff --git a/website/content/docs/auth/github.mdx b/website/content/docs/auth/github.mdx index c50b6fe06fcc..a4409364de84 100644 --- a/website/content/docs/auth/github.mdx +++ b/website/content/docs/auth/github.mdx @@ -4,7 +4,7 @@ page_title: GitHub - Auth Methods description: The GitHub auth method allows authentication with Vault using GitHub. --- -# GitHub Auth Method +# GitHub auth method The `github` auth method can be used to authenticate with Vault using a GitHub personal access token. This method of authentication is most useful for humans: diff --git a/website/content/docs/auth/index.mdx b/website/content/docs/auth/index.mdx index c086242396c0..2609029a57bf 100644 --- a/website/content/docs/auth/index.mdx +++ b/website/content/docs/auth/index.mdx @@ -4,7 +4,7 @@ page_title: Auth Methods description: Auth methods are mountable methods that perform authentication for Vault. --- -# Auth Methods +# Auth methods Auth methods are the components in Vault that perform authentication and are responsible for assigning identity and a set of policies to a user. In all cases, @@ -23,7 +23,7 @@ method is the recommended choice. To learn more about authentication, see the [authentication concepts page](/vault/docs/concepts/auth). -## Enabling/Disabling Auth Methods +## Enabling/Disabling auth methods Auth methods can be enabled/disabled using the CLI or the API. @@ -47,7 +47,7 @@ $ vault auth enable -path=my-login userpass When an auth method is disabled, all users authenticated via that method are automatically logged out. -## External Auth Method Considerations +## External auth method considerations When using an external auth method (e.g., GitHub), Vault will call the external service at the time of authentication and for subsequent token renewals. If the status diff --git a/website/content/docs/auth/jwt/index.mdx b/website/content/docs/auth/jwt/index.mdx index 225e347cba7b..491ab71d89e2 100644 --- a/website/content/docs/auth/jwt/index.mdx +++ b/website/content/docs/auth/jwt/index.mdx @@ -6,7 +6,7 @@ description: >- JWTs --- -# JWT/OIDC Auth Method +# JWT/OIDC auth method @include 'x509-sha1-deprecation.mdx' @@ -25,7 +25,7 @@ Both methods allow additional processing of the claims data in the JWT. Some of the concepts common to both methods will be covered first, followed by specific examples of OIDC and JWT usage. -## OIDC Authentication +## OIDC authentication This section covers the setup and use of OIDC roles. If a JWT is to be provided directly, refer to the [JWT Authentication](/vault/docs/auth/jwt#jwt-authentication) section below. Basic @@ -75,13 +75,13 @@ parameter in the redirect URI, if [`namespace_in_state`](/vault/api-docs/auth/jwt#namespace_in_state) is set to `true`, which is the default for new configs. -### OIDC Login (Vault UI) +### OIDC login (Vault UI) 1. Select the "OIDC" login method. 1. Enter a role name if necessary. 1. Press "Sign In" and complete the authentication with the configured provider. -### OIDC Login (CLI) +### OIDC login (CLI) The CLI login defaults to path of `/oidc`. If this auth method was enabled at a different path, specify `-path=/my-path` in the CLI. @@ -110,14 +110,14 @@ not required to be set: - `callbackport` (default: value set for `port`). This value is used in the `redirect_uri`, whereas `port` is the localhost port that the listener is using. These two may be different in advanced setups. -### OIDC Provider Configuration +### OIDC provider configuration The OIDC authentication flow has been successfully tested with a number of providers. A full guide to configuring OAuth/OIDC applications is beyond the scope of Vault documentation, but a collection of provider configuration steps has been collected to help get started: [OIDC Provider Setup](/vault/docs/auth/jwt/oidc-providers) -### OIDC Configuration Troubleshooting +### OIDC configuration troubleshooting This amount of configuration required for OIDC is relatively small, but it can be tricky to debug why things aren't working. Some tips for setting up OIDC: @@ -171,12 +171,12 @@ EOF than 200 groups, described in [Azure-specific handling configuration](/vault/docs/auth/jwt/oidc-providers/azuread#optional-azure-specific-configuration) -## JWT Authentication +## JWT authentication The authentication flow for roles of type "jwt" is simpler than OIDC since Vault only needs to validate the provided JWT. -### JWT Verification +### JWT verification JWT signatures will be verified against public keys from the issuer. This process can be done in three different ways, though only one method may be configured for a single backend: @@ -287,7 +287,7 @@ management tool. For the complete list of configuration options, please see the API documentation. -### Bound Claims +### Bound claims Once a JWT has been validated as being properly signed and not expired, the authorization flow will validate that any configured "bound" parameters match. @@ -317,7 +317,7 @@ To limit authorization to a set of email addresses: Bound claims can optionally be configured with globs. See the [API documentation](/vault/api-docs/auth/jwt#bound_claims_type) for more details. -### Claims as Metadata +### Claims as metadata Data from claims can be copied into the resulting auth token and alias metadata by configuring `claim_mappings`. This role parameter is a map of items to copy. The map elements are of the form: `"":""`. Assume @@ -336,7 +336,7 @@ it must existing in the JWT or else the authentication will fail. Note: the metadata key name "role" is reserved and may not be used for claim mappings. -### Claim Specifications and JSON Pointer +### Claim specifications and JSON pointer Some parameters (e.g. `bound_claims`, `groups_claim`, `claim_mappings`, `user_claim`) are used to point to data within the JWT. If the desired key is at the top of level of the JWT, diff --git a/website/content/docs/auth/jwt/oidc-providers/azuread.mdx b/website/content/docs/auth/jwt/oidc-providers/azuread.mdx index 36bf16a248ee..9692dcf6d7cb 100644 --- a/website/content/docs/auth/jwt/oidc-providers/azuread.mdx +++ b/website/content/docs/auth/jwt/oidc-providers/azuread.mdx @@ -4,7 +4,7 @@ page_title: OIDC Provider Setup - Auth Methods - Azure Active Directory description: OIDC provider configuration for Azure Active Directory --- -## Azure Active Directory (AAD) +## Azure active directory (AAD) ~> **Note:** Azure Active Directory Applications that have custom signing keys as a result of using the [claims-mapping](https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-claims-mapping) @@ -97,7 +97,7 @@ You should set up a [Vault policy](/vault/tutorials/policies/policies) for the A canonical_id="vault_external_group_id" ``` -### Optional Azure-specific Configuration +### Optional azure-specific configuration If a user is a member of more than 200 groups (directly or indirectly), Azure will send `_claim_names` and `_claim_sources`. For example, returned claims might look like: diff --git a/website/content/docs/auth/jwt/oidc-providers/google.mdx b/website/content/docs/auth/jwt/oidc-providers/google.mdx index 6cdd00f887c1..50e9a352a071 100644 --- a/website/content/docs/auth/jwt/oidc-providers/google.mdx +++ b/website/content/docs/auth/jwt/oidc-providers/google.mdx @@ -17,7 +17,7 @@ Main reference: [Using OAuth 2.0 to Access Google APIs](https://developers.googl 1. Configure Authorized [Redirect URIs](/vault/docs/auth/jwt#redirect-uris). 1. Save client ID and secret. -### Optional Google-specific Configuration +### Optional google-specific configuration Google-specific configuration is available when using Google as an identity provider from the Vault JWT/OIDC auth method. The configuration allows Vault to obtain Google Workspace group membership and diff --git a/website/content/docs/auth/jwt/oidc-providers/index.mdx b/website/content/docs/auth/jwt/oidc-providers/index.mdx index 7cb59d38354e..6527bbb25f13 100644 --- a/website/content/docs/auth/jwt/oidc-providers/index.mdx +++ b/website/content/docs/auth/jwt/oidc-providers/index.mdx @@ -4,7 +4,7 @@ page_title: OIDC Provider Setup - Auth Methods description: OIDC provider configuration quick starts --- -# OIDC Provider Configuration +# OIDC provider configuration This page collects high-level setup steps on how to configure an OIDC application for various providers. For more general usage and operation diff --git a/website/content/docs/auth/kerberos.mdx b/website/content/docs/auth/kerberos.mdx index 4aefe3096523..d808ede57836 100644 --- a/website/content/docs/auth/kerberos.mdx +++ b/website/content/docs/auth/kerberos.mdx @@ -4,7 +4,7 @@ page_title: Kerberos - Auth Methods description: The Kerberos auth method allows automated authentication of Kerberos entities. --- -# Kerberos Auth Method +# Kerberos auth method @include 'x509-sha1-deprecation.mdx' @@ -171,7 +171,7 @@ $ vault login -method=kerberos \ ## Troubleshooting -### Identify the Malfunctioning Piece +### Identify the malfunctioning piece Once the malfunctioning piece of the journey is identified, you can focus your debugging efforts in the most useful direction. @@ -184,7 +184,7 @@ your debugging efforts in the most useful direction. 3. While logged into your client machine, verify you can reach Vault through the following command: `$ curl $VAULT_ADDR/v1/sys/health`. -### Build Clear Steps to Reproduce the Problem +### Build clear steps to reproduce the problem If possible, make it easy for someone else to reproduce the problem who is outside of your company. For instance, if you expect that you should @@ -209,7 +209,7 @@ by posting your reproduction to the [Vault Forum](https://discuss.hashicorp.com/ or by providing it to [HashiCorp Support](https://www.hashicorp.com/support) (if applicable.) -### Additional Troubleshooting Resources +### Additional troubleshooting resources - [Troubleshooting Vault](/vault/tutorials/monitoring/troubleshooting-vault) - [The plugin's code](https://github.com/hashicorp/vault-plugin-auth-kerberos) diff --git a/website/content/docs/auth/kubernetes.mdx b/website/content/docs/auth/kubernetes.mdx index 9e44d28e2430..4e6cc191982e 100644 --- a/website/content/docs/auth/kubernetes.mdx +++ b/website/content/docs/auth/kubernetes.mdx @@ -6,7 +6,7 @@ description: |- Service Accounts. --- -# Kubernetes Auth Method +# Kubernetes auth method @include 'x509-sha1-deprecation.mdx' @@ -148,7 +148,7 @@ below for guidance if you wish to enable issuer validation in Vault. [k8s-1.21-changelog]: https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.21.md#api-change-2 [short-lived-tokens]: #how-to-work-with-short-lived-kubernetes-tokens -### How to work with short-lived Kubernetes tokens +### How to work with short-lived kubernetes tokens There are a few different ways to configure auth for Kubernetes pods when default mounted pod tokens are short-lived, each with their own tradeoffs. This @@ -286,7 +286,7 @@ vault write auth/kubernetes/config \ issuer="\"test-aks-cluster-dns-d6cbb78e.hcp.uksouth.azmk8s.io\"" ``` -## Configuring Kubernetes +## Configuring kubernetes This auth method accesses the [Kubernetes TokenReview API][k8s-tokenreview] to validate the provided JWT is still valid. Kubernetes should be running with @@ -322,7 +322,7 @@ The Kubernetes Auth Plugin has a full HTTP API. Please see the [k8s-tokenreview]: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#tokenreview-v1-authentication-k8s-io -## Code Example +## Code example The following example demonstrates the Kubernetes auth method to authenticate with Vault. diff --git a/website/content/docs/auth/ldap.mdx b/website/content/docs/auth/ldap.mdx index 1e515d48058f..e0aa1a268a6e 100644 --- a/website/content/docs/auth/ldap.mdx +++ b/website/content/docs/auth/ldap.mdx @@ -6,7 +6,7 @@ description: |- credentials. --- -# LDAP Auth Method +# LDAP auth method @include 'x509-sha1-deprecation.mdx' @@ -18,7 +18,7 @@ in multiple places. The mapping of groups and users in LDAP to Vault policies is managed by using the `users/` and `groups/` paths. -## A Note on Escaping +## A note on escaping **It is up to the administrator** to provide properly escaped DNs. This includes the user DN, bind DN for search, and so on. @@ -112,7 +112,7 @@ management tool. There are two alternate methods of resolving the user object used to authenticate the end user: _Search_ or _User Principal Name_. When using _Search_, the bind can be either anonymous or authenticated. User Principal Name is a method of specifying users supported by Active Directory. More information on UPN can be found [here](). -#### Binding - Authenticated Search +#### Binding - authenticated search - `binddn` (string, optional) - Distinguished name of object to bind when performing user and group search. Example: `cn=vault,ou=Users,dc=example,dc=com` - `bindpass` (string, optional) - Password to use along with `binddn` when performing user search. @@ -122,7 +122,7 @@ There are two alternate methods of resolving the user object used to authenticat @include 'ldap-auth-userfilter-warning.mdx' -#### Binding - Anonymous Search +#### Binding - anonymous search - `discoverdn` (bool, optional) - If true, use anonymous bind to discover the bind DN of a user - `userdn` (string, optional) - Base DN under which to perform user search. Example: `ou=Users,dc=example,dc=com` @@ -133,15 +133,15 @@ There are two alternate methods of resolving the user object used to authenticat @include 'ldap-auth-userfilter-warning.mdx' -#### Alias Dereferencing +#### Alias dereferencing - `dereference_aliases` (string, optional) - Control how aliases are dereferenced when performing the search. Possible values are: `never`, `finding`, `searching`, and `always`. `finding` will only dereference aliases during name resolution of the base. `searching` will dereference aliases after name resolution. -#### Binding - User Principal Name (AD) +#### Binding - user principal name (AD) - `upndomain` (string, optional) - userPrincipalDomain used to construct the UPN string for the authenticating user. The constructed UPN will appear as `[username]@UPNDomain`. Example: `example.com`, which will cause vault to bind as `username@example.com`. -### Group Membership Resolution +### Group membership resolution Once a user has been authenticated, the LDAP auth method must know how to resolve which groups the user is a member of. The configuration for this can vary depending on your LDAP server and your directory schema. There are two main strategies when resolving group membership - the first is searching for the authenticated user object and following an attribute to groups it is a member of. The second is to search for group objects of which the authenticated user is a member of. Both methods are supported. @@ -234,7 +234,7 @@ $ vault write auth/ldap/config \ ... ``` -## LDAP Group -> Policy Mapping +## LDAP group -> policy mapping Next we want to create a mapping from an LDAP group to a Vault policy: diff --git a/website/content/docs/auth/login-mfa/faq.mdx b/website/content/docs/auth/login-mfa/faq.mdx index f3a5df958ac7..62a3bd25a202 100644 --- a/website/content/docs/auth/login-mfa/faq.mdx +++ b/website/content/docs/auth/login-mfa/faq.mdx @@ -22,7 +22,7 @@ This FAQ section contains frequently asked questions about the Login MFA feature - [Q: I am a Step-up Enterprise MFA user using MFA for login. Should I migrate to the new Login MFA?](#q-i-am-a-step-up-enterprise-mfa-user-using-mfa-for-login-should-i-migrate-to-the-new-login-mfa) - [Q: I am a Step-up Enterprise MFA user using MFA for login. What are the steps to migrate to Login MFA?](#q-i-am-a-step-up-enterprise-mfa-user-using-mfa-for-login-what-are-the-steps-to-migrate-to-login-mfa) -### Q: What MFA features can I access if I upgrade to Vault version 1.10? +### Q: what MFA features can i access if i upgrade to Vault version 1.10? Vault supports Step-up Enterprise MFA as part of our Enterprise edition. The Step-up Enterprise MFA provides MFA on login, or for step-up access to sensitive resources in Vault using ACL and Sentinel policies, and is configurable through the CLI/API. @@ -30,7 +30,7 @@ Starting with Vault version 1.10, Vault OSS provides [MFA on login](/vault/docs/ The Step-up Enterprise MFA will co-exist with the newly introduced Login MFA starting with Vault version 1.10. -### Q: What are the various MFA workflows that are available to me as a Vault user as of Vault version 1.10, and how are they different? +### Q: what are the various MFA workflows that are available to me as a Vault user as of Vault version 1.10, and how are they different? | MFA workflow | What does it do? | Who manages the MFA? | OSS vs. Enterprise Support | | ---------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------- | ----------------------------- | @@ -40,15 +40,15 @@ The Step-up Enterprise MFA will co-exist with the newly introduced Login MFA sta ~> **Note**: [The Legacy MFA](/vault/docs/v1.10.x/auth/mfa) is a **deprecated** MFA workflow in Vault OSS. Refer [here](#q-what-is-the-legacy-mfa-feature) for more details. -### Q: What is the Legacy MFA feature? +### Q: what is the legacy MFA feature? [Legacy MFA](/vault/docs/v1.10.x/auth/mfa) is functionality that was available in Vault OSS, prior to introducing MFA in the Enterprise version. This is now a deprecated feature. Please see the [Vault Feature Deprecation Notice and Plans](/vault/docs/deprecation) for detailed product plans around deprecated features. We plan to remove Legacy MFA in 1.11. -### Q: Will HCP Vault support MFA? +### Q: will HCP Vault support MFA? Yes, HCP Vault will support MFA across all tiers and offering as part of the April 2022 release. -### Q: What is Single-Phase MFA vs. Two-Phase MFA? +### Q: what is Single-Phase MFA vs. Two-Phase MFA? - **Single-Phase MFA:** This is a single request mechanism where the required MFA information, such as MFA method ID, is provided via the X-Vault-MFA header in a single MFA request that is used to authenticate into Vault. @@ -59,11 +59,11 @@ If the configured MFA methods, such as PingID, Okta, or Duo, do not require a pa - The MFA passcode required for the configured MFA method is not provided in a header of the login request that is MFA-restricted. Instead, the user first authenticates to the auth method, and on successful authentication to the auth method, an MFA requirement is returned to the user. The MFA requirement contains the MFA RequestID and constraints applicable to the MFA as configured by the operator. - The user then must make a second request to the new endpoint `sys/mfa/validate`, providing the MFA RequestID in the request, and an MFA payload which includes the MFA methodIDs passcode (if applicable). If MFA validation passes, the new Vault token will be persisted and returned to the user in the response, just like a regular Vault token created using a non-MFA-restricted auth method. -### Q: Are there new MFA API endpoints introduced as part of the new Vault version 1.10 MFA for login functionality? +### Q: are there new MFA API endpoints introduced as part of the new Vault version 1.10 MFA for login functionality? Yes, this feature adds the following new MFA configuration endpoints: `identity/mfa/method`, `identity/mfa/login-enforcement`, and `sys/mfa/validate`. Refer to the [documentation](/vault/api-docs/secret/identity/mfa/duo) for more details. -### Q: How do MFA configurations differ between the Login MFA and Step-up Enterprise MFA? +### Q: how do MFA configurations differ between the login MFA and step-up enterprise MFA? All MFA methods supported with the Step-up Enterprise MFA are supported with the Login MFA, but they use different API endpoints: @@ -74,7 +74,7 @@ There are also two differences in how methods are defined in the two systems. The Step-up Enterprise MFA expects the method creator to specify a name for the method; Login MFA does not, and instead returns an ID when a method is created. The Step-up Enterprise MFA uses the combination of mount accessors plus a `username_format` template string, whereas in Login MFA, these are combined into a single field `username_format`, which uses the same identity [templating format](/vault/docs/concepts/policies#templated-policies) as used in policies. -### Q: What are the ways to configure the various MFA workflows? +### Q: what are the ways to configure the various MFA workflows? | MFA workflow | Configuration methods | Details | | ---------------------------------------------- | ----------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -82,7 +82,7 @@ The Step-up Enterprise MFA uses the combination of mount accessors plus a `usern | [Okta Auth MFA](/vault/docs/auth/okta) | CLI/API | MFA methods supported: [TOTP](https://help.okta.com/en/prod/Content/Topics/Security/mfa-totp-seed.htm) , [Okta Verify Push](https://help.okta.com/en/prod/Content/Topics/Mobile/ov-admin-config.htm). | | [Step-up Enterprise MFA](/vault/docs/enterprise/mfa) | CLI/API | [Configured](/vault/api-docs/system/mfa) using the `sys/mfa/method` endpoints and by referencing those methods in policies. MFA Methods supported: TOTP, Okta, Duo, PingID | -### Q: Which MFA mechanism is used with the different MFA workflows in Vault version 1.10? +### Q: which MFA mechanism is used with the different MFA workflows in Vault version 1.10? | MFA workflow | UI | CLI/API | Single-Phase | Two-Phase | | ---------------------------------------------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------- | --------------------------- | --------------------------- | @@ -90,16 +90,16 @@ The Step-up Enterprise MFA uses the combination of mount accessors plus a `usern | [Okta Auth MFA](/vault/docs/auth/okta) | N/A | N/A | MFA is not managed by Vault | MFA is not managed by Vault | | [Step-up Enterprise MFA](/vault/docs/enterprise/mfa) | N/A | Supported | Supported | N/A | -### Q: Are namespaces supported with the MFA workflows that Vault has as of Vault version 1.10? +### Q: are namespaces supported with the MFA workflows that Vault has as of Vault version 1.10? The Step-up Enterprise MFA configurations can only be configured in the root [namespace](/vault/docs/enterprise/mfa#namespaces), although they can be referenced in other namespaces via the policies. The Login MFA supports namespaces awareness. Users will need a Vault Enterprise license to user or configure Login MFA with namespaces. MFA method configurations can be defined per namespace with Login MFA, and used in enforcements defined in that namespace and its children. Everything operates in the root namespace in Vault OSS. MFA login enforcements can also be defined per namespace, and applied to that namespace and its children. -### Q: I use the Vault Agent. Does MFA pose any challenges for me? +### Q: i use the Vault agent. does MFA pose any challenges for me? The Vault Agent should not use MFA to authenticate to Vault; it should be able to relay requests with MFA-related headers to Vault successfully. -### Q: I am a Step-up Enterprise MFA user using MFA for login. Should I migrate to the new Login MFA? +### Q: i am a step-up enterprise MFA user using MFA for login. should i migrate to the new login MFA? If you are currently using Enterprise MFA, evaluate your MFA specific use cases to determine whether or not you should migrate to [Login MFA](/vault/docs/auth/login-mfa). @@ -108,7 +108,7 @@ Here are some considerations: - If you use the Step-up Enterprise MFA for login (with Sentinel EGP), you may find value in the simpler Login MFA workflow. We recommend that you to test this out to evaluate if this meets all your requirements. - If you use the Step-up Enterprise MFA for more than login, please be aware that the new MFA workflow only supports the login use case. You will still need to use the Step-up Enterprise MFA for non-login use cases. -### Q: I am a Step-up Enterprise MFA user using MFA for login. What are the steps to migrate to Login MFA? +### Q: i am a step-up enterprise MFA user using MFA for login. what are the steps to migrate to login MFA? Refer to the question [Q: I am a Step-up Enterprise MFA user using MFA for login. Should I migrate to the new Login MFA?](#q-i-am-a-step-up-enterprise-mfa-user-using-mfa-for-login-should-i-migrate-to-the-new-login-mfa) to evaluate whether or not you should migrate. diff --git a/website/content/docs/auth/login-mfa/index.mdx b/website/content/docs/auth/login-mfa/index.mdx index 6b279365582f..40a119008e7d 100644 --- a/website/content/docs/auth/login-mfa/index.mdx +++ b/website/content/docs/auth/login-mfa/index.mdx @@ -13,7 +13,7 @@ an auth method using different authentication types. We use the term `Login MFA` this feature and the [Vault Enterprise MFA](/vault/docs/enterprise/mfa). Login MFA is built on top of the Identity system of Vault. -## MFA Types +## MFA types MFA in Vault includes the following login types: @@ -37,7 +37,7 @@ MFA in Vault includes the following login types: access to the API. The PingID username will be derived from the caller identity's alias. -## Login MFA Procedure +## Login MFA procedure ~> **NOTE:** Vault's built-in Login MFA feature does not protect against brute forcing of TOTP passcodes by default. We recommend that per-client [rate limits](/vault/docs/concepts/resource-quotas) @@ -56,7 +56,7 @@ such as a one-time passcode, before being authenticated. There are two ways to validate a login request that is subject to MFA validation. -### Single-Phase Login +### Single-Phase login In the Single-phase login, the required MFA information is embedded in a login request using the `X-Vault-MFA` header. In this case, the MFA validation is done @@ -67,7 +67,7 @@ the header is `mfa_method_id[:passcode]` for TOTP, Okta, and PingID. However, fo The item in the `[]` is optional. From Vault 1.13.0, the format is consistent for all supported MFA methods, and one can use either of the above two formats. If there are multiple MFA methods that need to be validated, a user can pass in multiple `X-Vault-MFA` HTTP headers. -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -106,7 +106,7 @@ $ curl \ http://127.0.0.1:8200/v1/auth/userpass/login/alice ``` -### Two-Phase Login +### Two-Phase login The more conventional and prevalent MFA method is a two-request mechanism, also referred to as Two-phase Login MFA. In Two-phase login, the `X-Vault-MFA` header is not provided in the request. In this case, after sending a regular login request, @@ -117,7 +117,7 @@ a boolean value showing whether the MFA method uses passcodes or not. MFA constr and represent all MFA enforcements that match a login request. While the example below is for the userpass login, note that this can affect the login response on any auth mount protected by MFA validation. -#### Sample Two-Phase Login Response +#### Sample Two-Phase login response ```json { @@ -169,7 +169,7 @@ endpoint including the MFA request ID and MFA payload. MFA payload contains a ma If the configured MFA methods, such as PingID, Okta, and Duo, do not require a passcode, the associated credentials will be a list with one empty string. -#### Sample Payload +#### Sample payload ```json { @@ -191,7 +191,7 @@ If an MFA method is configured in a namespace, the MFA method name prefixed with } ``` -#### Sample Request +#### Sample request ```shell-session $ curl \ @@ -201,7 +201,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/mfa/validate ``` -#### Sample CLI Request +#### Sample CLI request A user is also able to use the CLI write command to validate the login request. @@ -209,7 +209,7 @@ A user is also able to use the CLI write command to validate the login request. $ vault write sys/mfa/validate -format=json @payload.json ``` -#### Interactive CLI for Login MFA +#### Interactive CLI for login MFA Vault supports an interactive way of authenticating to an auth method using CLI only if the login request is subject to a single MFA method validation. In this situation, if the MFA method @@ -227,7 +227,7 @@ $ vault write -non-interactive sys/mfa/validate -format=json @payload.json To get started with Login MFA, refer to the [Login MFA](/vault/tutorials/auth-methods/multi-factor-authentication) tutorial. -### TOTP Passcode Validation Rate Limit +### TOTP passcode validation rate limit Rate limiting of Login MFA paths are enforced by default in Vault 1.10.1 and above. By default, Vault allows for 5 consecutive failed TOTP passcode validation. diff --git a/website/content/docs/auth/oci.mdx b/website/content/docs/auth/oci.mdx index 02fbc9ac5882..c39cac704eba 100644 --- a/website/content/docs/auth/oci.mdx +++ b/website/content/docs/auth/oci.mdx @@ -6,7 +6,7 @@ description: >- OCI Identity credentials. --- -# OCI Auth Method +# OCI auth method The OCI Auth method for Vault enables authentication and authorization using [OCI Identity](https://docs.cloud.oracle.com/iaas/Content/Identity/Concepts/overview.htm) credentials. @@ -14,7 +14,7 @@ This plugin is developed in a separate GitHub repository at https://github.com/h but is automatically bundled in Vault releases. Please file all feature requests, bugs, and pull requests specific to the OCI plugin under that repository. -## OCI Roles +## OCI roles The OCI Auth method authorizes using roles, as shown here: ![Role Based Authorization](/img/oci/oci-role-based-authz.png) @@ -33,7 +33,7 @@ The `ocid_list` field of a role is a list of [Group or Dynamic Group](https://do ## Configuration -### Configure the OCI Tenancy to Run Vault +### Configure the OCI tenancy to run Vault The OCI Auth method requires [instance principal](https://blogs.oracle.com/cloud-infrastructure/announcing-instance-principals-for-identity-and-access-management) credentials to call OCI Identity APIs, and therefore the Vault server needs to run inside an OCI compute instance. @@ -50,7 +50,7 @@ Follow the steps below to add policies to your tenancy that allow the OCI comput allow dynamic-group VaultDynamicGroup to {GROUP_MEMBERSHIP_INSPECT} in tenancy ``` -### Configure the OCI Auth method +### Configure the OCI auth method First, enable the OCI Auth method. @@ -100,7 +100,7 @@ Group or Dynamic Group OCIDs in your tenancy that has users or instances that yo http://127.0.0.1:8200/v1/auth/oci/role/vaultadminrole (127.0.0.1:8200/v1/auth/oci/role/vaultadminrole) ``` -### Log in to Vault using OCI Auth +### Log in to Vault using OCI auth As a result of both methods described below, you will get a response that includes a token with the previously added policy. @@ -132,7 +132,7 @@ If you don't have an API key: 1. Ensure that the region in the config matches the region of the compute instance that is running Vault. -### Manage Roles in the OCI Auth method +### Manage roles in the OCI auth method 1. Similar to creating the Vault administrator role, create other roles mapped to other policies. Create a file named devrole.json with the following contents. Replace ocid_list with Groups or Dynamic Groups in your tenancy. diff --git a/website/content/docs/auth/okta.mdx b/website/content/docs/auth/okta.mdx index 56ce27e5ee3b..798fac1c6a62 100644 --- a/website/content/docs/auth/okta.mdx +++ b/website/content/docs/auth/okta.mdx @@ -6,7 +6,7 @@ description: |- credentials. --- -# Okta Auth Method +# Okta auth method The `okta` auth method allows authentication using Okta and user/password credentials. This allows Vault to be integrated into environments using Okta. @@ -134,7 +134,7 @@ management tool. will need to re-authenticate. You can force this by revoking the existing tokens. -### Okta API Token Permissions +### Okta API token permissions The `okta` auth method uses the [Authentication](https://developer.okta.com/docs/reference/api/authn/) and [User Groups](https://developer.okta.com/docs/reference/api/users/#get-user-s-groups) diff --git a/website/content/docs/auth/radius.mdx b/website/content/docs/auth/radius.mdx index a0581e7ea40a..f535cf588e68 100644 --- a/website/content/docs/auth/radius.mdx +++ b/website/content/docs/auth/radius.mdx @@ -6,7 +6,7 @@ description: |- existing RADIUS server. --- -# RADIUS Auth Method +# RADIUS auth method The `radius` auth method allows users to authenticate with Vault using an existing RADIUS server that accepts the PAP authentication scheme. diff --git a/website/content/docs/auth/token.mdx b/website/content/docs/auth/token.mdx index d743cbceaa75..f00a6455e06c 100644 --- a/website/content/docs/auth/token.mdx +++ b/website/content/docs/auth/token.mdx @@ -4,7 +4,7 @@ page_title: Token - Auth Methods description: The token store auth method is used to authenticate using tokens. --- -# Token Auth Method +# Token auth method The `token` auth method is built-in and automatically available at `/auth/token`. It allows users to authenticate using a token, as well to create new tokens, revoke diff --git a/website/content/docs/auth/userpass.mdx b/website/content/docs/auth/userpass.mdx index f168ffaabb17..72c9f2c852c8 100644 --- a/website/content/docs/auth/userpass.mdx +++ b/website/content/docs/auth/userpass.mdx @@ -6,7 +6,7 @@ description: >- username and password. --- -# Userpass Auth Method +# Userpass auth method The `userpass` auth method allows users to authenticate with Vault using a username and password combination. diff --git a/website/content/docs/browser-support.mdx b/website/content/docs/browser-support.mdx index 07663fc40189..0d5e36127cc7 100644 --- a/website/content/docs/browser-support.mdx +++ b/website/content/docs/browser-support.mdx @@ -6,7 +6,7 @@ description: |- List of browser suppport. --- -# Vault UI Browser Support +# Vault UI browser support Vault currently supports all 'evergreen' and updated browsers. the following browsers are supported: diff --git a/website/content/docs/commands/audit/list.mdx b/website/content/docs/commands/audit/list.mdx index 327e838dff1c..80d595572a9c 100644 --- a/website/content/docs/commands/audit/list.mdx +++ b/website/content/docs/commands/audit/list.mdx @@ -36,13 +36,13 @@ file/ file n/a replicated file_path=/var/log/audit.log The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-format` `(string: "table")` - Print the output in the given format. Valid formats are "table", "json", or "yaml". This can also be specified via the `VAULT_FORMAT` environment variable. -### Command Options +### Command options - `-detailed` `(bool: false)` - Print detailed information such as options and replication status about each auth device. diff --git a/website/content/docs/commands/auth/list.mdx b/website/content/docs/commands/auth/list.mdx index 8414cf62ce5e..3ac64313dade 100644 --- a/website/content/docs/commands/auth/list.mdx +++ b/website/content/docs/commands/auth/list.mdx @@ -11,14 +11,14 @@ description: |- The `auth list` command lists the auth methods enabled. The output lists the enabled auth methods and options for those methods. -## Deprecation Status Column +## Deprecation status column As of 1.12, all built-in auth engines will have an associated Deprecation Status. This status will be reflected in the `Deprecation Status` column, seen below. All auth engines which are not provided by built-in plugins will show a `Deprecation Status` of "n/a". -## Version Columns +## Version columns The `-detailed` view displays some version information for each mount. @@ -60,13 +60,13 @@ token/ token auth_token_aafab997 system system defaul The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-format` `(string: "table")` - Print the output in the given format. Valid formats are "table", "json", or "yaml". This can also be specified via the `VAULT_FORMAT` environment variable. -### Command Options +### Command options - `-detailed` `(bool: false)` - Print detailed information such as configuration and replication status about each auth method. diff --git a/website/content/docs/commands/debug.mdx b/website/content/docs/commands/debug.mdx index 0d020f4c95f4..43c3c9f05ade 100644 --- a/website/content/docs/commands/debug.mdx +++ b/website/content/docs/commands/debug.mdx @@ -64,7 +64,7 @@ path "sys/in-flight-req" { } ``` -## Capture Targets +## Capture targets The `-target` flag can be specified multiple times to capture specific information when debug is running. By default, it captures all information. @@ -88,7 +88,7 @@ library limitations in fetching the data without enabling `cgo`. [Enterprise] Telemetry can be gathered from a DR Secondary active node via the `metrics` target if [unauthenticated_metrics_access](/vault/docs/configuration/listener/tcp#unauthenticated_metrics_access) is enabled. -## Output Layout +## Output layout The output of the bundled information, once decompressed, is contained within a single directory. Each target, with the exception of profiling data, is captured @@ -155,7 +155,7 @@ $ vault debug -target=host -target=metrics The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Command Options +### Command options - `-compress` `(bool: true)` - Toggles whether to compress output package The default is true. diff --git a/website/content/docs/commands/index.mdx b/website/content/docs/commands/index.mdx index c1a536066ea8..6aa2eea3ce42 100644 --- a/website/content/docs/commands/index.mdx +++ b/website/content/docs/commands/index.mdx @@ -8,7 +8,7 @@ description: |- maps directly to the HTTP API internally. --- -# Vault Commands (CLI) +# Vault commands (CLI) ~> **Note:** The Vault command-line interface (CLI) changed substantially in 0.9.2+ and may cause confusion while using older versions of Vault with this @@ -21,7 +21,7 @@ interface (CLI) that wraps common functionality and formats output. The Vault CLI is a single static binary. It is a thin wrapper around the HTTP API. Every CLI command maps directly to the HTTP API internally. -## CLI Command Structure +## CLI command structure Each command is represented as a command or subcommand, and there are a number of command and subcommand options available: HTTP options, output options, and @@ -74,7 +74,7 @@ The four most common operations in Vault are [read](/vault/docs/commands/read), paths will contain secrets while other paths may contain configuration. Whatever it is, the primary interface for reading and writing data to Vault is similar. -### Print cURL Command +### Print cURL command To see the equivalent API call to perform the same operation, use the `-output-curl-string` flag after the subcommand. @@ -85,7 +85,7 @@ $ vault write -output-curl-string auth/userpass/users/bob password="long-passwo curl -X PUT -H "X-Vault-Request: true" -H "X-Vault-Token: $(vault print token)" -d '{"password":"long-password"}' http://127.0.0.1:8200/v1/auth/userpass/users/bob ``` -#### Print Policy Requirements +#### Print policy requirements To view the policy requirements to perform an operation, use the `-output-policy` flag after the subcommand. @@ -97,12 +97,12 @@ path "kv/data/secret" { } ``` -## Command Help +## Command help There are two primary ways to get help in Vault: [CLI help (`help`)](#cli-help) and [API help (`path-help`)](#api-help). -### CLI Help +### CLI help Use `help` (or `-h` for shorthand) to see the CLI help output which corresponds to your Vault version. @@ -121,7 +121,7 @@ $ vault kv help The help output displays available subcommands, parameters, and command flags. -### API Help +### API help To invoke the Vault API paths, you can use the [read](/vault/docs/commands/read) (for HTTP GET), [write](/vault/docs/commands/write) (for HTTP PUT or POST), @@ -170,7 +170,7 @@ This path responds to the following HTTP methods. The help output displays supported child-paths and available parameters if there are any. -## Command Input +## Command input To write data to Vault, the input can be a part of the command in key-value format. @@ -225,7 +225,7 @@ instead of `$ vault kv get secret/password`. The mount flag syntax was created t their full path (used in policies and raw API calls) actually contains a nested `/data/` element (e.g. `secret/data/password`) which can be easily overlooked when using the above KV v1-like syntax `secret/password`. To avoid this confusion, all KV-specific docs pages will use the `-mount` flag. -## Exit Codes +## Exit codes The Vault CLI aims to be consistent and well-behaved unless documented otherwise. @@ -258,7 +258,7 @@ list of available completions. Type `-` to show available flag completions. If the `VAULT_*` environment variables are set, the autocompletion will automatically query the Vault server and return helpful argument suggestions. -## Token Helper +## Token helper By default, the Vault CLI uses a "token helper" to cache the token after authentication. This is conceptually similar to how a website securely stores @@ -268,7 +268,7 @@ customizable, and you can even build your own. The default token helper stores the token in `~/.vault-token`. You can delete this file at any time to "logout" of Vault. -## Environment Variables +## Environment variables The CLI reads the following environment variables to set behavioral defaults. This can alleviate the need to repetitively type a flag. Flags always take diff --git a/website/content/docs/commands/kv/delete.mdx b/website/content/docs/commands/kv/delete.mdx index c123285458d6..eb6ebd65ce32 100644 --- a/website/content/docs/commands/kv/delete.mdx +++ b/website/content/docs/commands/kv/delete.mdx @@ -35,7 +35,7 @@ Success! Data deleted (if it existed) at: secret/data/creds There are no flags beyond the [standard set of flags](/vault/docs/commands) included on all commands. -### Command Options +### Command options - `-mount` `(string: "")` - Specifies the path where the KV backend is mounted. If specified, the next argument will be interpreted as the secret path. If diff --git a/website/content/docs/commands/kv/destroy.mdx b/website/content/docs/commands/kv/destroy.mdx index 20eb29635954..63b1cc21af96 100644 --- a/website/content/docs/commands/kv/destroy.mdx +++ b/website/content/docs/commands/kv/destroy.mdx @@ -29,13 +29,13 @@ Success! Data written to: secret/destroy/creds There are no flags beyond the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-format` `(string: "table")` - Print the output in the given format. Valid formats are "table", "json", or "yaml". This can also be specified via the `VAULT_FORMAT` environment variable. -### Command Options +### Command options - `-mount` `(string: "")` - Specifies the path where the KV backend is mounted. If specified, the next argument will be interpreted as the secret path. If diff --git a/website/content/docs/commands/kv/enable-versioning.mdx b/website/content/docs/commands/kv/enable-versioning.mdx index 5b210276dfeb..67cc3f41ff99 100644 --- a/website/content/docs/commands/kv/enable-versioning.mdx +++ b/website/content/docs/commands/kv/enable-versioning.mdx @@ -26,7 +26,7 @@ Success! Tuned the secrets engine at: secret/ There are no flags beyond the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-format` `(string: "table")` - Print the output in the given format. Valid formats are "table", "json", or "yaml". This can also be specified via the diff --git a/website/content/docs/commands/kv/get.mdx b/website/content/docs/commands/kv/get.mdx index 80f8c4b69119..31d29ed76621 100644 --- a/website/content/docs/commands/kv/get.mdx +++ b/website/content/docs/commands/kv/get.mdx @@ -57,7 +57,7 @@ my-long-passcode ## Usage -### Output Options +### Output options - `-field` `(string: "")` - Print only the field with the given name. Specifying this option will take precedence over other formatting directives. The result @@ -68,7 +68,7 @@ my-long-passcode formats are "table", "json", or "yaml". This can also be specified via the `VAULT_FORMAT` environment variable. -### Command Options +### Command options - `-mount` `(string: "")` - Specifies the path where the KV backend is mounted. If specified, the next argument will be interpreted as the secret path. If diff --git a/website/content/docs/commands/kv/list.mdx b/website/content/docs/commands/kv/list.mdx index b6ecc83bcb4c..e3187993c71c 100644 --- a/website/content/docs/commands/kv/list.mdx +++ b/website/content/docs/commands/kv/list.mdx @@ -36,7 +36,7 @@ release There are no flags beyond the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-mount` `(string: "")` - Specifies the path where the KV backend is mounted. If specified, the next argument will be interpreted as the secret path. If diff --git a/website/content/docs/commands/kv/metadata.mdx b/website/content/docs/commands/kv/metadata.mdx index 6d40126a2f42..97ea488966aa 100644 --- a/website/content/docs/commands/kv/metadata.mdx +++ b/website/content/docs/commands/kv/metadata.mdx @@ -130,13 +130,13 @@ set to a duration greater than the backend's, the backend's Delete-Version-After setting will be used. Any changes to the Delete-Version-After setting will only be applied to new versions. -#### Output Options +#### Output options - `-format` `(string: "table")` - Print the output in the given format. Valid formats are "table", "json", or "yaml". This can also be specified via the `VAULT_FORMAT` environment variable. -#### Subcommand Options +#### Subcommand options - `-cas-required` `(bool: false)` - If true the key will require the cas parameter to be set on all write requests. If false, the backend’s diff --git a/website/content/docs/commands/kv/patch.mdx b/website/content/docs/commands/kv/patch.mdx index 676ea623222e..aa1767d56945 100644 --- a/website/content/docs/commands/kv/patch.mdx +++ b/website/content/docs/commands/kv/patch.mdx @@ -58,7 +58,7 @@ $ echo "abcd1234" | vault kv patch -mount=secret foo bar=- ## Usage -### Output Options +### Output options - `-field` `(string: "")` - Print only the field with the given name. Specifying this option will take precedence over other formatting directives. The result @@ -69,7 +69,7 @@ $ echo "abcd1234" | vault kv patch -mount=secret foo bar=- formats are "table", "json", or "yaml". This can also be specified via the `VAULT_FORMAT` environment variable. -### Command Options +### Command options - `-method` `(string: "patch")` - Specifies the patch method to use. Valid methods are `patch` and `rw`. The `patch` method uses an HTTP `PATCH` request diff --git a/website/content/docs/commands/kv/put.mdx b/website/content/docs/commands/kv/put.mdx index c158f6baf632..9f9cec852215 100644 --- a/website/content/docs/commands/kv/put.mdx +++ b/website/content/docs/commands/kv/put.mdx @@ -46,7 +46,7 @@ $ echo "abcd1234" | vault kv put -mount=secret foo bar=- There are no flags beyond the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-field` `(string: "")` - Print only the field with the given name. Specifying this option will take precedence over other formatting directives. The result @@ -57,7 +57,7 @@ included on all commands. formats are "table", "json", or "yaml". This can also be specified via the `VAULT_FORMAT` environment variable. -### Command Options +### Command options - `-cas` `(int: 0)` - Specifies to use a Check-And-Set operation. If not set the write will be allowed. In order for a write to be successful, `cas` must be set to diff --git a/website/content/docs/commands/kv/rollback.mdx b/website/content/docs/commands/kv/rollback.mdx index 94191fe4cf96..ac179992f7df 100644 --- a/website/content/docs/commands/kv/rollback.mdx +++ b/website/content/docs/commands/kv/rollback.mdx @@ -36,13 +36,13 @@ version 6 There are no flags beyond the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-format` `(string: "table")` - Print the output in the given format. Valid formats are "table", "json", or "yaml". This can also be specified via the `VAULT_FORMAT` environment variable. -### Command Options +### Command options - `-mount` `(string: "")` - Specifies the path where the KV backend is mounted. If specified, the next argument will be interpreted as the secret path. If diff --git a/website/content/docs/commands/kv/undelete.mdx b/website/content/docs/commands/kv/undelete.mdx index 0428f81614e2..d65ac118e2c0 100644 --- a/website/content/docs/commands/kv/undelete.mdx +++ b/website/content/docs/commands/kv/undelete.mdx @@ -30,13 +30,13 @@ Success! Data written to: secret/undelete/creds There are no flags beyond the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-format` `(string: "table")` - Print the output in the given format. Valid formats are "table", "json", or "yaml". This can also be specified via the `VAULT_FORMAT` environment variable. -### Command Options +### Command options - `-mount` `(string: "")` - Specifies the path where the KV backend is mounted. If specified, the next argument will be interpreted as the secret path. If diff --git a/website/content/docs/commands/license/get.mdx b/website/content/docs/commands/license/get.mdx index f36f4d66023e..afddfbc51cae 100644 --- a/website/content/docs/commands/license/get.mdx +++ b/website/content/docs/commands/license/get.mdx @@ -46,7 +46,7 @@ License not found or using a temporary license. The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Command Options +### Command options - `-signed` `(bool: false)` - Return the signed license string when using a stored license. diff --git a/website/content/docs/commands/license/inspect.mdx b/website/content/docs/commands/license/inspect.mdx index 2fcef167ae00..40b973e13ad4 100644 --- a/website/content/docs/commands/license/inspect.mdx +++ b/website/content/docs/commands/license/inspect.mdx @@ -53,6 +53,6 @@ License is valid The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Command Options +### Command options - `-installation-id` `(string: "")` - Installation ID to validate the license against diff --git a/website/content/docs/commands/login.mdx b/website/content/docs/commands/login.mdx index 8228f0839476..18bc950d264c 100644 --- a/website/content/docs/commands/login.mdx +++ b/website/content/docs/commands/login.mdx @@ -125,7 +125,7 @@ token_meta_username my-username The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-field` `(string: "")` - Print only the field with the given name. Specifying this option will take precedence over other formatting directives. The result @@ -135,7 +135,7 @@ flags](/vault/docs/commands) included on all commands. formats are "table", "json", or "yaml". This can also be specified via the `VAULT_FORMAT` environment variable. -### Command Options +### Command options - `-method` `(string "token")` - Type of authentication to use such as "userpass" or "ldap". Note this corresponds to the TYPE, not the enabled path. diff --git a/website/content/docs/commands/monitor.mdx b/website/content/docs/commands/monitor.mdx index e90f94fd45c6..53af78d05200 100644 --- a/website/content/docs/commands/monitor.mdx +++ b/website/content/docs/commands/monitor.mdx @@ -36,7 +36,7 @@ $ vault monitor -log-level=debug The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-log-level` `(string: "info")` - Monitor the Vault server at this log level. Valid log levels are (in order of detail) "trace", "debug", "info", diff --git a/website/content/docs/commands/operator/diagnose.mdx b/website/content/docs/commands/operator/diagnose.mdx index 4513e546039f..65d780ec95db 100644 --- a/website/content/docs/commands/operator/diagnose.mdx +++ b/website/content/docs/commands/operator/diagnose.mdx @@ -25,13 +25,13 @@ messages or warnings. The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-format` `(string: "table")` - Print the output in the given format. Valid formats are "table", "json", or "yaml". This can also be specified via the `VAULT_FORMAT` environment variable. -#### Output Layout +#### Output layout The operator diagnose command will output a set of lines in the CLI. Each line will begin with a prefix in parenthesis. These are:. @@ -51,38 +51,38 @@ Warn or fail prefixes in nested checks will bubble up to the parent if the prefi parent prefix. Fail superceeds warn, and warn superceeds ok. For example, if the TLS checks under the Storage check fails, the `[ failure ]` prefix will bubble up to the Storage check. -### Command Options +### Command options - `-config` `(string; "")` - The path to the vault configuration file used by the vault server on startup. -### Diagnose Checks +### Diagnose checks The following section details the various checks that Diagnose runs. Check names in documentation will be separated by slashes to denote that they are nested, when applicable. For example, a check documented as `A / B` will show up as `B` in the `operator diagnose` output, and will be nested (indented) under `A`. -#### Vault Diagnose +#### Vault diagnose `Vault Diagnose` is the top level check that contains the rest of the checks. It will report the status of the check -#### Check Operating System / Check Open File Limit +#### Check operating system / check open file limit `Check Open File Limit` verifies that the open file limit value is set high enough for vault to run effectively. We recommend setting these limits to at least 1024768. This check will be skipped on openbsd, arm, and windows. -#### Check Operating System / Check Disk Usage +#### Check operating system / check disk usage `Check Disk Usage` will report disk usage for each partition. For each partition on a prod host, we recommend having at least 5% of the partition free to use, and at least 1 GB of space. This check will be skipped on openbsd and arm. -#### Parse Configuration +#### Parse configuration `Parse Configuration` will check the vault server config file for syntax errors. It will check for extra values in the configuration file, repeated stanzas, and stanzas that do not belong @@ -90,24 +90,24 @@ in the configuration file (for example a "tcpp" listener as opposed to a tcp lis Currently, the `storage` stanza is not checked. -#### Check Storage / Create Storage Backend +#### Check storage / create storage backend `Create Storage Backend` ensures that the storage stanza configured in the vault server config has enough information to create a storage object internally. Common errors will have to do with misconfigured fields in the storage stanza. -#### Check Storage / Check Consul TLS +#### Check storage / check consul TLS `Check Consul TLS` verifies TLS information included in the storage stanza if the storage type is consul. If a certificate chain is provided, Diagnose parses the root, intermediate, and leaf certificates, and checks each one for correctness. -#### Check Storage / Check Consul Direct Storage Access +#### Check storage / check consul direct storage access `Check Consul Direct Storage Access` is a consul-specific check that ensures Vault is not accessing the consul server directly, but rather through a local agent. -#### Check Storage / Check Raft Folder Permissions +#### Check storage / check raft folder permissions `Check Raft Folder Permissions` computes the permissions on the raft folder, checks that a boltDB file has been initialized within the folder previously, and ensures that the folder is not too permissive, but @@ -120,7 +120,7 @@ pre-existing server runs. This check will be skipped on windows. -#### Check Storage / Check Raft Folder Ownership +#### Check storage / check raft folder ownership `Check Raft Folder Ownership` ensures that vault does not need to run as root to access the boltDB folder. @@ -129,14 +129,14 @@ pre-existing server runs. This check will be skipped on windows. -#### Check Storage / Check For Raft Quorum +#### Check storage / check for raft quorum `Check For Raft Quorum` uses the FSM to ensure that there were an odd number of voters in the raft quorum when vault was last running. Note that this check will warn that there are 0 voters if diagnose is run without any pre-existing server runs. -#### Check Storage / Check Storage Access +#### Check storage / check storage access `Check Storage Access` will try to write a dud value, named `diagnose/latency/`, to storage. Ensure that there is no important data at this location before running diagnose, as this check @@ -146,62 +146,62 @@ the name and value is as expected. `Check Storage Access` will warn if any operation takes longer than 100ms, and error out if the entire check takes longer than 30s. -#### Check Service Discovery / Check Consul Service Discovery TLS +#### Check service discovery / check consul service discovery TLS `Check Consul Service Discovery TLS` verifies TLS information included in the service discovery stanza if the storage type is consul. If a certificate chain is provided, Diagnose parses the root, intermediate, and leaf certificates, and checks each one for correctness. -#### Check Service Discovery / Check Consul Direct Service Discovery +#### Check service discovery / check consul direct service discovery `Check Consul Direct Service Discovery` is a consul-specific check that ensures Vault is not accessing the consul server directly, but rather through a local agent. -#### Create Vault Server Configuration Seals +#### Create Vault server configuration seals `Create Vault Server Configuration Seals` creates seals from the vault configuration stanza and verifies they can be initialized and finalized. -#### Check Transit Seal TLS +#### Check transit seal TLS `Check Transit Seal TLS` checks the TLS client certificate, key, and CA certificate provided in a transit seal stanza (if one exists) for correctness. -#### Create Core Configuration / Initialize Randomness for Core +#### Create core configuration / initialize randomness for core `Initialize Randomness for Core` ensures that vault has access to the randReader that the vault core uses. -#### HA Storage +#### HA storage This check and any nested checks will be the same as the `Check Storage` checks. The only difference is that the checks here will be run on whatever is specified in the `ha_storage` section of the vault configuration, as opposed to the `storage` section. -#### Determine Redirect Address +#### Determine redirect address Ensures that one of the `VAULT_API_ADDR`, `VAULT_REDIRECT_ADDR`, or `VAULT_ADVERTISE_ADDR` environment variables are set, or that the redirect address is specified in the vault configuration. -#### Check Cluster Address +#### Check cluster address Parses the cluster address from the `VAULT_CLUSTER_ADDR` environment variable, or from the redirect address or cluster address specified in the vault configuration, and checks that the address is of the form `host:port`. -#### Check Core Creation +#### Check core creation `Check Core Creation` verifies the logical configuration checks that vault does when it creates a core object. These are runtime checks, meaning any errors thrown by this diagnose test will also be thrown by the vault server itself when it is run. -#### Check For Autoloaded License +#### Check for autoloaded license `Check For Autoloaded License` is an enterprise diagnose check, which verifies that vault has access to a valid autoloaded license that will not expire in the next 30 days. -#### Start Listeners / Check Listener TLS +#### Start listeners / check listener TLS `Check Listener TLS` verifies the server certificate file and key are valid and matching. It also checks the client CA file, if one is provided, for a valid certificate, and performs @@ -211,17 +211,17 @@ that the minimum and maximum TLS versions are within the bounds of what vault su Like all the other Diagnose TLS checks, it will warn if any of the certificates provided are set to expire within the next month. -#### Start Listeners / Create Listeners +#### Start listeners / create listeners `Create Listeners` uses the listener configuration to initialize the listeners, erroring with a server error if anything goes wrong. -#### Check Autounseal Encryption +#### Check autounseal encryption `Check Autounseal Encryption` will initialize the barrier using the seal stanza, if the seal type is not a shamir seal, and use it to encrypt and decrypt a dud value. -#### Check Server Before Runtime +#### Check server before runtime `Check Server Before Runtime` achieves parity with the server run command, running through the runtime code checks before the server is initialized to ensure that nothing fails. diff --git a/website/content/docs/commands/operator/generate-root.mdx b/website/content/docs/commands/operator/generate-root.mdx index b9c3d3fb4754..844351a5f7e2 100644 --- a/website/content/docs/commands/operator/generate-root.mdx +++ b/website/content/docs/commands/operator/generate-root.mdx @@ -55,13 +55,13 @@ $ vault operator generate-root -otp="..." The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-format` `(string: "table")` - Print the output in the given format. Valid formats are "table", "json", or "yaml". This can also be specified via the `VAULT_FORMAT` environment variable. -### Command Options +### Command options - `-cancel` `(bool: false)` - Reset the root token generation progress. This will discard any submitted unseal keys or configuration. diff --git a/website/content/docs/commands/operator/init.mdx b/website/content/docs/commands/operator/init.mdx index ea55ab098b87..d8b3558b555f 100644 --- a/website/content/docs/commands/operator/init.mdx +++ b/website/content/docs/commands/operator/init.mdx @@ -59,13 +59,13 @@ $ vault operator init -root-token-pgp-key="keybase:hashicorp" The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-format` `(string: "")` - Print the output in the given format. Valid formats are "table", "json", or "yaml". The default is table. This can also be specified via the `VAULT_FORMAT` environment variable. -### Common Options +### Common options - `-key-shares` `(int: 5)` - Number of key shares to split the generated master key into. This is the number of "unseal keys" to generate. This is aliased as @@ -91,7 +91,7 @@ flags](/vault/docs/commands) included on all commands. code of 0 means the Vault is already initialized. An exit code of 1 means an error occurred. An exit code of 2 means the Vault is not initialized. -### Consul Options +### Consul options - `-consul-auto` `(bool: false)` - Perform automatic service discovery using Consul in HA mode. When all nodes in a Vault HA cluster are registered with @@ -106,7 +106,7 @@ flags](/vault/docs/commands) included on all commands. - `-consul-service` `(string: "vault")` - Name of the service in Consul under which the Vault servers are registered. -### HSM and KMS Options +### HSM and KMS options - `-recovery-pgp-keys` `(string: "...")` - Behaves like `-pgp-keys`, but for the recovery key shares. This is only available with [Auto Unseal](/vault/docs/concepts/seal#auto-unseal) seals (HSM, KMS and Transit seals). diff --git a/website/content/docs/commands/operator/key-status.mdx b/website/content/docs/commands/operator/key-status.mdx index b9ecc9fbe83b..e39545e74423 100644 --- a/website/content/docs/commands/operator/key-status.mdx +++ b/website/content/docs/commands/operator/key-status.mdx @@ -27,7 +27,7 @@ Encryption Count 4494 The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-format` `(string: "table")` - Print the output in the given format. Valid formats are "table", "json", or "yaml". This can also be specified via the diff --git a/website/content/docs/commands/operator/members.mdx b/website/content/docs/commands/operator/members.mdx index d532302c3705..1b9029fef1b6 100644 --- a/website/content/docs/commands/operator/members.mdx +++ b/website/content/docs/commands/operator/members.mdx @@ -32,7 +32,7 @@ Note that in the above output, `Upgrade Version` and `Redundancy Zone` are Enter The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-format` `(string: "table")` - Print the output in the given format. Valid formats are "table", "json", or "yaml". This can also be specified via the diff --git a/website/content/docs/commands/operator/migrate.mdx b/website/content/docs/commands/operator/migrate.mdx index 81af3b27b5a8..111db247185a 100644 --- a/website/content/docs/commands/operator/migrate.mdx +++ b/website/content/docs/commands/operator/migrate.mdx @@ -66,7 +66,7 @@ storage_destination "consul" { ## Migrating to integrated raft storage -### Example Configuration +### Example configuration The below configuration will migrate away from Consul storage to integrated raft storage. The raft data will be stored on the local filesystem in the diff --git a/website/content/docs/commands/operator/raft.mdx b/website/content/docs/commands/operator/raft.mdx index 329a18c32102..dd2a63f738a0 100644 --- a/website/content/docs/commands/operator/raft.mdx +++ b/website/content/docs/commands/operator/raft.mdx @@ -99,7 +99,7 @@ Usage: vault operator raft list-peers $ vault operator raft list-peers ``` -### Example Output +### Example output ```json { @@ -232,7 +232,7 @@ Usage: vault operator raft autopilot state $ vault operator raft autopilot state ``` -#### Example Output +#### Example output ```text Healthy: true @@ -264,7 +264,7 @@ Servers: ``` Vault Enterprise will include additional output related to automated upgrades and redundancy zones. -#### Example Vault Enterprise Output +#### Example Vault enterprise output ```text Redundancy Zones: diff --git a/website/content/docs/commands/operator/rekey.mdx b/website/content/docs/commands/operator/rekey.mdx index 80341a2518ce..2ff5539a1f5f 100644 --- a/website/content/docs/commands/operator/rekey.mdx +++ b/website/content/docs/commands/operator/rekey.mdx @@ -108,13 +108,13 @@ $ vault operator rekey -verify -nonce="..." The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-format` `(string: "table")` - Print the output in the given format. Valid formats are "table", "json", or "yaml". This can also be specified via the `VAULT_FORMAT` environment variable. -### Command Options +### Command options - `-cancel` `(bool: false)` - Reset the rekeying progress. This will discard any submitted unseal keys or configuration. The default is false. @@ -149,7 +149,7 @@ flags](/vault/docs/commands) included on all commands. verification process is activated for the rekey. Along with `-nonce` option it indicates that the nonce given is for the verification process. -### Backup Options +### Backup options - `-backup` `(bool: false)` - Store a backup of the current PGP encrypted unseal keys in Vault's core. The encrypted values can be recovered in the event of diff --git a/website/content/docs/commands/operator/rotate.mdx b/website/content/docs/commands/operator/rotate.mdx index 40ffcec34ce9..a9de0d0fd489 100644 --- a/website/content/docs/commands/operator/rotate.mdx +++ b/website/content/docs/commands/operator/rotate.mdx @@ -34,7 +34,7 @@ Install Time 01 May 17 10:30 UTC The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-format` `(string: "table")` - Print the output in the given format. Valid formats are "table", "json", or "yaml". This can also be specified via the diff --git a/website/content/docs/commands/operator/unseal.mdx b/website/content/docs/commands/operator/unseal.mdx index 0019fcd6af1f..700224ace701 100644 --- a/website/content/docs/commands/operator/unseal.mdx +++ b/website/content/docs/commands/operator/unseal.mdx @@ -48,13 +48,13 @@ Unseal Progress: 0 The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-format` `(string: "table")` - Print the output in the given format. Valid formats are "table", "json", or "yaml". This can also be specified via the `VAULT_FORMAT` environment variable. -### Command Options +### Command options - `-migrate` `(bool: false)` - Indicate that this share is provided with the intent that it is part of a seal migration process. diff --git a/website/content/docs/commands/operator/usage.mdx b/website/content/docs/commands/operator/usage.mdx index 2a3bf728d66a..894624760cdb 100644 --- a/website/content/docs/commands/operator/usage.mdx +++ b/website/content/docs/commands/operator/usage.mdx @@ -55,13 +55,13 @@ Total 954 176 1130 The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-format` `(string: "table")` - Print the output in the given format. Valid formats are "table", "json", or "yaml". This can also be specified via the `VAULT_FORMAT` environment variable. -### Command Options +### Command options - `-start-time` `(date)` - Start month of the report to generate. May be given as YYYY-MM-DD, YYYY-MM-DD, a full RFC3339 timestamp, or a Unix epoch timestamp. Defaults to the configurable `default_report_months` diff --git a/website/content/docs/commands/patch.mdx b/website/content/docs/commands/patch.mdx index 9009359a8754..827036485212 100644 --- a/website/content/docs/commands/patch.mdx +++ b/website/content/docs/commands/patch.mdx @@ -70,7 +70,7 @@ The `vault patch` command simplifies the API call. The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-field` `(string: "")` - Print only the field with the given name. Specifying this option will take precedence over other formatting directives. The result @@ -80,7 +80,7 @@ flags](/vault/docs/commands) included on all commands. formats are "table", "json", or "yaml". This can also be specified via the `VAULT_FORMAT` environment variable. -### Command Options +### Command options - `-force` `(bool: false)` - Allow the operation to continue with no key=value pairs. This allows writing to keys that do not need or expect data. This is diff --git a/website/content/docs/commands/pki/health-check.mdx b/website/content/docs/commands/pki/health-check.mdx index ba05fdc62c9f..abffb689eb1f 100644 --- a/website/content/docs/commands/pki/health-check.mdx +++ b/website/content/docs/commands/pki/health-check.mdx @@ -73,7 +73,7 @@ This command respects the `-format` parameter to control the presentation of output sent to stdout. Fatal errors that prevent health checks from executing may not follow this formatting. -## Return Status and Output +## Return status and output This command returns the following exit codes: @@ -111,12 +111,12 @@ These correspond to the following health check status values: - status `invalid_version` / status code `5`: exit code `5`. - status `insufficient_permissions` / status code `6`: exit code `6`. -## Health Checks +## Health checks The following health checks are currently implemented. More health checks may be added in future releases and may default to being enabled. -### CA Validity Period +### CA validity period **Name**: `ca_validity_period` @@ -145,7 +145,7 @@ This health check will check each issuer in the mount for validity status, retur - Run [tidy](/vault/api-docs/secret/pki#tidy) manually with `vault write /tidy tidy_expired_issuers=true`. - Use the Vault API to call [delete issuer](/vault/api-docs/secret/pki#delete-issuer). -### CRL Validity Period +### CRL validity period **Name**: `crl_validity_period` @@ -172,7 +172,7 @@ Use `vault write` to enable CRL auto-rebuild: ```shell-session $ vault write /config/crl auto_rebuild=true -### Hardware-Backed Root Certificate +### Hardware-Backed root certificate **Name**: `hardware_backed_root` @@ -190,7 +190,7 @@ This health check checks issuers for root CAs backed by software keys. While Vau Read more about hardware-backed keys within [Vault Enterprise Managed Keys](/vault/docs/enterprise/managed-keys) -### Root Certificate Issued Non-CA Leaves +### Root certificate issued Non-CA leaves **Name**: `root_issued_leaves` @@ -215,7 +215,7 @@ This health check verifies whether a proper CA hierarchy is in use. We do this b 1. Have the root issuer sign the new intermediary issuer. 1. Issue new leaf certificates using the intermediary issuer. -### Role Allows Implicit Localhost Issuance +### Role allows implicit localhost issuance **Name**: `role_allows_localhost` @@ -235,7 +235,7 @@ Checks whether any roles exist that allow implicit localhost based issuance 1. Update the `allowed_domains` field with an explicit list of allowed localhost-like domains. -### Role Allows Glob-Based Wildcard Issuance +### Role allows Glob-Based wildcard issuance **Name**: `role_allows_glob_wildcards` @@ -263,7 +263,7 @@ other (potentially dangerous) quirks. 1. Add the roles that allow glob domains and wildcards to `allowed_roles` so Vault ignores them in future checks. -### Role Sets `no_store=false` and Performance +### Role sets `no_store=false` and performance **Name**: `role_no_store_false` @@ -295,7 +295,7 @@ to `true`. 1. Use [BYOC revocations](/vault/api-docs/secret/pki#revoke-certificate) to revoke certificates as needed. -### Accessibility of Audit Information +### Accessibility of audit information **Name**: `audit_visibility` @@ -348,7 +348,7 @@ vault secrets tune \ ``` -### ACL Policies Allow Problematic Endpoints +### ACL policies allow problematic endpoints **Name**: `policy_allow_endpoints` @@ -363,7 +363,7 @@ vault secrets tune \ This health check checks whether unsafe access to APIs (such as `sign-intermediate`, `sign-verbatim`, and `sign-self-issued`) are allowed. Any findings are a critical result and should be rectified by the administrator or explicitly allowed. -### Allow If-Modified-Since Requests +### Allow If-Modified-Since requests **Name**: `allow_if_modified_since` @@ -396,7 +396,7 @@ This health check verifies if the `If-Modified-Since` header has been added to ` ``` -### Auto-Tidy Disabled +### Auto-Tidy disabled **Name**: `enable_auto_tidy` @@ -428,7 +428,7 @@ vault write /config/auto-tidy \ tidy_revoked_cert_issuer_associations=true ``` -### Tidy Hasn't Run +### Tidy hasn't run **Name**: `tidy_last_run` @@ -461,7 +461,7 @@ This health check verifies that tidy has run within the last run window. This ca manual run. -### Too Many Certificates +### Too many certificates **Name**: `too_many_certs` @@ -518,7 +518,7 @@ This health check verifies that ACME is enabled within a mount that contains an Review the [ACME Certificate Issuance](/vault/api-docs/secret/pki#acme-certificate-issuance) API documentation to learn about enabling ACME support in Vault. -### ACME Response headers +### ACME response headers **Name**: `allow_acme_headers` diff --git a/website/content/docs/commands/pki/index.mdx b/website/content/docs/commands/pki/index.mdx index 8a6ec3379407..0a98b34e0b90 100644 --- a/website/content/docs/commands/pki/index.mdx +++ b/website/content/docs/commands/pki/index.mdx @@ -15,7 +15,7 @@ The `pki` command groups subcommands for interacting with Vault's Option flags for a given subcommand are provided after the subcommand, but before the arguments. -## Example Health Check +## Example health check To [health check](/vault/docs/commands/pki/health-check) a mount, use the `vault pki health-check ` command: @@ -31,7 +31,7 @@ ok /pki/issuer/da41ffb1-cc6d-5a5c-f147-e4d7beeb1b73 Issuer's validity ... more output elided ... ``` -## Example Verify Sign +## Example verify sign To [verify](/vault/docs/commands/pki/verify-sign) the signature between two issuer certificates, use the `vault pki verify-sign ` command: @@ -50,7 +50,7 @@ key_id_match true signature_match true ``` -## Example List Child Issuers +## Example list child issuers To [list intermediate](/vault/docs/commands/pki/list-intermediates) certificates potentially issued by a certificate inside vault, use the @@ -67,7 +67,7 @@ pki_int/issuer/2f958ec5-1838-336e-331b-07032379b958 true pki_int/issuer/b8cc0b41-e0e9-1a92-12c4-6849c9d6f837 true ``` -## Example Issue +## Example issue To [issue](/vault/docs/commands/pki/issue) a new issuer certificate, use the `vault pki issue ` command: @@ -80,7 +80,7 @@ ca_chain [-----BEGIN CERTIFICATE----- MIIDsDCCApigAwIBAgIULEPuHTW7UDtAQg+qcc18osNWgZIwDQYJKoZIhvcNAQEL... ``` -## Example Reissue +## Example reissue To [reissue](/vault/docs/commands/pki/reissue) an issuer certificate, using the same fields as an existing issuer template, use the diff --git a/website/content/docs/commands/plugin/info.mdx b/website/content/docs/commands/plugin/info.mdx index 8a1127f12c0c..e285b47cdea5 100644 --- a/website/content/docs/commands/plugin/info.mdx +++ b/website/content/docs/commands/plugin/info.mdx @@ -51,7 +51,7 @@ version n/a The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-field` `(string: "")` - Print only the field with the given name. Specifying this option will take precedence over other formatting directives. The result @@ -62,7 +62,7 @@ flags](/vault/docs/commands) included on all commands. formats are "table", "json", or "yaml". This can also be specified via the `VAULT_FORMAT` environment variable. -### Command Options +### Command options - `-plugin-version` `(string: "")` - Semantic version of the plugin to read from the catalog. If unspecified, refers to the unversioned plugin registered with diff --git a/website/content/docs/commands/plugin/list.mdx b/website/content/docs/commands/plugin/list.mdx index 6a92a4f02d29..53491a206d0b 100644 --- a/website/content/docs/commands/plugin/list.mdx +++ b/website/content/docs/commands/plugin/list.mdx @@ -9,7 +9,7 @@ description: The "plugin list" command lists all available plugins in the plugin The `plugin list` command lists all available plugins in the plugin catalog. It can be used alone or with a type such as "auth", "database", or "secret". -## Deprecation Status Column +## Deprecation status column As of 1.12, all builtin plugins will have an associated Deprecation Status. This status will be reflected in the `Deprecation Status` column, seen @@ -49,13 +49,13 @@ app-id auth v1.12.0+builtin.vault The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-format` `(string: "table")` - Print the output in the given format. Valid formats are "table", "json", or "yaml". This can also be specified via the `VAULT_FORMAT` environment variable. -### Command Options +### Command options - `-detailed` `(bool: false)` - Print detailed information such as version and deprecation status about each plugin. diff --git a/website/content/docs/commands/plugin/register.mdx b/website/content/docs/commands/plugin/register.mdx index 51bb725003a8..21847e7c9b8e 100644 --- a/website/content/docs/commands/plugin/register.mdx +++ b/website/content/docs/commands/plugin/register.mdx @@ -36,13 +36,13 @@ $ vault plugin register \ The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-format` `(string: "table")` - Print the output in the given format. Valid formats are "table", "json", or "yaml". This can also be specified via the `VAULT_FORMAT` environment variable. -### Command Options +### Command options - `-sha256` `(string: )` - Checksum (SHA256) of the plugin binary. diff --git a/website/content/docs/commands/plugin/reload.mdx b/website/content/docs/commands/plugin/reload.mdx index ec53e4350fca..9a74b809fc27 100644 --- a/website/content/docs/commands/plugin/reload.mdx +++ b/website/content/docs/commands/plugin/reload.mdx @@ -43,7 +43,7 @@ Success! Reloaded mounts: [my-custom-plugin-1/ my-custom-plugin-2/] The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Command Options +### Command options - `-plugin` `(string: "")` - The name of the plugin to reload, as registered in the plugin catalog. diff --git a/website/content/docs/commands/policy/list.mdx b/website/content/docs/commands/policy/list.mdx index 3355ac297395..849670b37f46 100644 --- a/website/content/docs/commands/policy/list.mdx +++ b/website/content/docs/commands/policy/list.mdx @@ -26,7 +26,7 @@ root The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-format` `(string: "table")` - Print the output in the given format. Valid formats are "table", "json", or "yaml". This can also be specified via the diff --git a/website/content/docs/commands/policy/read.mdx b/website/content/docs/commands/policy/read.mdx index c01334e4b496..7b2b1bbd3286 100644 --- a/website/content/docs/commands/policy/read.mdx +++ b/website/content/docs/commands/policy/read.mdx @@ -24,7 +24,7 @@ $ vault policy read my-policy The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-format` `(string: "table")` - Print the output in the given format. Valid formats are "table", "json", or "yaml". This can also be specified via the diff --git a/website/content/docs/commands/read.mdx b/website/content/docs/commands/read.mdx index 03cdeecb5bb3..36f7b9c84899 100644 --- a/website/content/docs/commands/read.mdx +++ b/website/content/docs/commands/read.mdx @@ -63,7 +63,7 @@ engine, it prints the output in more structured format that is easy to read. The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-field` `(string: "")` - Print only the field with the given name. Specifying this option will take precedence over other formatting directives. The result diff --git a/website/content/docs/commands/secrets/disable.mdx b/website/content/docs/commands/secrets/disable.mdx index 7918990e4cf1..4d22ec06a034 100644 --- a/website/content/docs/commands/secrets/disable.mdx +++ b/website/content/docs/commands/secrets/disable.mdx @@ -31,7 +31,7 @@ $ vault secrets disable aws/ There are no flags beyond the [standard set of flags](/vault/docs/commands) included on all commands. -## Force Disable +## Force disable Because `secrets disable` revokes secrets associated with this mount, possible errors can prevent the secrets engine from being disabled if the revocation diff --git a/website/content/docs/commands/secrets/list.mdx b/website/content/docs/commands/secrets/list.mdx index c4253011a847..65b866e25a2f 100644 --- a/website/content/docs/commands/secrets/list.mdx +++ b/website/content/docs/commands/secrets/list.mdx @@ -15,14 +15,14 @@ This command also outputs information about the enabled path including configured TTLs and human-friendly descriptions. A TTL of "system" indicates that the system default is in use. -## Deprecation Status Column +## Deprecation status column As of 1.12, all built-in secrets engines will have an associated Deprecation Status. This status will be reflected in the `Deprecation Status` column, seen below. All secrets engines which are not provided by built-in plugins will show a `Deprecation Status` of "n/a". -## Version Columns +## Version columns The `-detailed` view displays some version information for each mount. @@ -66,13 +66,13 @@ sys/ system system_c86bd362 n/a n/a fa The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-format` `(string: "table")` - Print the output in the given format. Valid formats are "table", "json", or "yaml". This can also be specified via the `VAULT_FORMAT` environment variable. -### Command Options +### Command options - `-detailed` `(bool: false)` - Print detailed information such as configuration and replication status about each secrets engine. diff --git a/website/content/docs/commands/server.mdx b/website/content/docs/commands/server.mdx index 5348a25351fd..8c9f08f05d0d 100644 --- a/website/content/docs/commands/server.mdx +++ b/website/content/docs/commands/server.mdx @@ -45,7 +45,7 @@ $ vault server -dev -dev-root-token-id="root" The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Command Options +### Command options - `-config` `(string: "")` - Path to a configuration file or directory of configuration files. This flag can be specified multiple times to load @@ -97,7 +97,7 @@ flags](/vault/docs/commands) included on all commands. and a downgrade must be performed in order to remove the offending engines. For more information, see the [deprecation faq](/vault/docs/deprecation/faq/#q-what-are-the-phases-of-deprecation). -### Dev Options +### Dev options - `-dev` `(bool: false)` - Enable development mode. In this mode, Vault runs in-memory and starts unsealed. As the name implies, do not run "dev" mode in diff --git a/website/content/docs/commands/ssh.mdx b/website/content/docs/commands/ssh.mdx index eefc739d6779..a0d8291f88d1 100644 --- a/website/content/docs/commands/ssh.mdx +++ b/website/content/docs/commands/ssh.mdx @@ -52,7 +52,7 @@ engine](/vault/docs/secrets/ssh). The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-field` `(string: "")` - Print only the field with the given name. Specifying this option will take precedence over other formatting directives. The result @@ -62,7 +62,7 @@ flags](/vault/docs/commands) included on all commands. formats are "table", "json", or "yaml". This can also be specified via the `VAULT_FORMAT` environment variable. -### SSH Options +### SSH options - `-mode` `(string: "")` - Name of the authentication mode (ca, dynamic, otp)." @@ -82,7 +82,7 @@ flags](/vault/docs/commands) included on all commands. the SSH configuration option "UserKnownHostsFile". This can also be specified via the `VAULT_SSH_USER_KNOWN_HOSTS_FILE` environment variable. -### CA Mode Options +### CA mode options - `-host-key-hostnames` `(string: "*")` - List of hostnames to delegate for the CA. The default value allows all domains and IPs. This is specified as a diff --git a/website/content/docs/commands/status.mdx b/website/content/docs/commands/status.mdx index 7c602346de53..ab7d41530111 100644 --- a/website/content/docs/commands/status.mdx +++ b/website/content/docs/commands/status.mdx @@ -44,7 +44,7 @@ High-Availability Enabled: false The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-format` `(string: "table")` - Print the output in the given format. Valid formats are "table", "json", or "yaml". This can also be specified via the @@ -52,7 +52,7 @@ flags](/vault/docs/commands) included on all commands. By default, the output is displayed in "table" format. -#### Output Fields +#### Output fields 1. The field for total shares is displayed as `"n"` instead of `n` in yaml outputs. 2. The following fields in "table" format are displayed only when relevant: diff --git a/website/content/docs/commands/token-helper.mdx b/website/content/docs/commands/token-helper.mdx index 3da6919e8537..7a52fbc0441f 100644 --- a/website/content/docs/commands/token-helper.mdx +++ b/website/content/docs/commands/token-helper.mdx @@ -6,7 +6,7 @@ description: >- and erasing tokens simpler to use. --- -# Token Helpers +# Token helpers A token helper is an external program that Vault calls to save, retrieve or erase a saved token. The token helper could be a very simple script or a more complex @@ -28,13 +28,13 @@ token_helper = "/path/to/token/helper.sh" You will need to use the fully qualified path to the token helper script. The script should be executable. -## Developing a Token Helper +## Developing a token helper The interface to a token helper is extremely simple: the script is passed with one argument that could be `get`, `store` or `erase`. If the argument is `get`, the script should do whatever work it needs to do to retrieve the stored token and then print the token to `STDOUT`. If the argument is `store`, Vault is asking you to store the token. Finally, if the argument is `erase`, your program should erase the stored token. If your program succeeds, it should exit with status code 0. If it encounters an issue that prevents it from working, it should exit with some other status code. You should write a user-friendly error message to `STDERR`. You should never write anything other than the token to `STDOUT`, as Vault assumes whatever it gets on `STDOUT` is the token. -### Example Token Helper +### Example token helper This is an example token helper written in Ruby that stores and retrieves tokens in a json file called `~/.vault_tokens`. The key is the environment variable \$VAULT_ADDR, this allows the Vault user to easily store and retrieve tokens from a number of different Vault servers. diff --git a/website/content/docs/commands/token/capabilities.mdx b/website/content/docs/commands/token/capabilities.mdx index dd524aa99f58..dc26fdbad2d5 100644 --- a/website/content/docs/commands/token/capabilities.mdx +++ b/website/content/docs/commands/token/capabilities.mdx @@ -37,7 +37,7 @@ deny The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-format` `(string: "table")` - Print the output in the given format. Valid formats are "table", "json", or "yaml". This can also be specified via the diff --git a/website/content/docs/commands/token/create.mdx b/website/content/docs/commands/token/create.mdx index ed66e21ea90e..5914f6f5170b 100644 --- a/website/content/docs/commands/token/create.mdx +++ b/website/content/docs/commands/token/create.mdx @@ -59,7 +59,7 @@ token_policies [my-policy] The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-field` `(string: "")` - Print only the field with the given name. Specifying this option will take precedence over other formatting directives. The result @@ -69,7 +69,7 @@ flags](/vault/docs/commands) included on all commands. formats are "table", "json", or "yaml". This can also be specified via the `VAULT_FORMAT` environment variable. -### Command Options +### Command options - `-display-name` `(string: "")` - Name to associate with this token. This is a non-sensitive value that can be used to help identify created secrets (e.g. diff --git a/website/content/docs/commands/token/lookup.mdx b/website/content/docs/commands/token/lookup.mdx index bee5061fa9f9..a96a5bcd967f 100644 --- a/website/content/docs/commands/token/lookup.mdx +++ b/website/content/docs/commands/token/lookup.mdx @@ -38,13 +38,13 @@ $ vault token lookup -accessor 9793c9b3-e04a-46f3-e7b8-748d7da248da The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-format` `(default: "table")` - Print the output in the given format. Valid formats are "table", "json", or "yaml". This can also be specified via the `VAULT_FORMAT` environment variable. -### Command Options +### Command options - `-accessor` `(bool: false)` - Treat the argument as an accessor instead of a token. When this option is selected, the output will NOT include the token. diff --git a/website/content/docs/commands/token/renew.mdx b/website/content/docs/commands/token/renew.mdx index 9ff30eafe26b..c957db9f1b43 100644 --- a/website/content/docs/commands/token/renew.mdx +++ b/website/content/docs/commands/token/renew.mdx @@ -41,13 +41,13 @@ $ vault token renew -increment=30m 96ddf4bc-d217-f3ba-f9bd-017055595017 The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-format` `(default: "table")` - Print the output in the given format. Valid formats are "table", "json", or "yaml". This can also be specified via the `VAULT_FORMAT` environment variable. -### Command Options +### Command options - `-increment` `(duration: "")` - Request a specific increment for renewal. Vault will not honor this request for periodic tokens. If not supplied, Vault will use diff --git a/website/content/docs/commands/unwrap.mdx b/website/content/docs/commands/unwrap.mdx index db562b8076b5..2432d8dd3dff 100644 --- a/website/content/docs/commands/unwrap.mdx +++ b/website/content/docs/commands/unwrap.mdx @@ -34,7 +34,7 @@ $ vault unwrap # unwraps 848f9ccf... The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-field` `(string: "")` - Print only the field with the given name. Specifying this option will take precedence over other formatting directives. The result diff --git a/website/content/docs/commands/version-history.mdx b/website/content/docs/commands/version-history.mdx index 9c31cb14f825..7b6c901da25c 100644 --- a/website/content/docs/commands/version-history.mdx +++ b/website/content/docs/commands/version-history.mdx @@ -25,7 +25,7 @@ Version Installation Time Build Date The following flags are available in addition to the [standard set of flags](/docs/commands) included on all commands. -### Output Options +### Output options - `-format` `(string: "table")` - Print the output in the given format. Valid formats are "table" or json". This can also be specified via the diff --git a/website/content/docs/commands/write.mdx b/website/content/docs/commands/write.mdx index 7755a507d3e3..989297f29879 100644 --- a/website/content/docs/commands/write.mdx +++ b/website/content/docs/commands/write.mdx @@ -104,7 +104,7 @@ you are invoking. The following flags are available in addition to the [standard set of flags](/vault/docs/commands) included on all commands. -### Output Options +### Output options - `-field` `(string: "")` - Print only the field with the given name. Specifying this option will take precedence over other formatting directives. The result @@ -114,7 +114,7 @@ flags](/vault/docs/commands) included on all commands. formats are "table", "json", or "yaml". This can also be specified via the `VAULT_FORMAT` environment variable. -### Command Options +### Command options - `-force` `(bool: false)` - Allow the operation to continue with no key=value pairs. This allows writing to keys that do not need or expect data. This is diff --git a/website/content/docs/concepts/auth.mdx b/website/content/docs/concepts/auth.mdx index 7ad6fdf89dc0..f83de23110b7 100644 --- a/website/content/docs/concepts/auth.mdx +++ b/website/content/docs/concepts/auth.mdx @@ -96,7 +96,7 @@ For example, the GitHub login endpoint is located at `auth/github/login`. And to determine the arguments needed, `vault path-help auth/github/login` can be used. -## Auth Leases +## Auth leases Just like secrets, identities have [leases](/vault/docs/concepts/lease) associated with them. This means that @@ -111,7 +111,7 @@ And just like secrets, identities can be renewed without having to completely reauthenticate. Just use `vault token renew ` with the leased token associated with your identity to renew it. -## Code Example +## Code example The following code snippet demonstrates how to renew auth tokens. diff --git a/website/content/docs/concepts/client-count/counting.mdx b/website/content/docs/concepts/client-count/counting.mdx index af2d0dd7fc77..a4ffe9b934d8 100644 --- a/website/content/docs/concepts/client-count/counting.mdx +++ b/website/content/docs/concepts/client-count/counting.mdx @@ -86,7 +86,7 @@ accuracy estimate for the approximation decreases as the difference between the number of clients in the current month and the number of clients in the billing period increases. -### Testing verification for client count approximations +### Testing verification for client count approximations Given `CM` as the number of clients for the current month and `BP` as the number of clients in the billing period, we found that the approximation becomes diff --git a/website/content/docs/concepts/client-count/faq.mdx b/website/content/docs/concepts/client-count/faq.mdx index 6cded101b213..a076324e2fe9 100644 --- a/website/content/docs/concepts/client-count/faq.mdx +++ b/website/content/docs/concepts/client-count/faq.mdx @@ -5,7 +5,7 @@ description: |- Answers to the most commonly asked questions about client count in Vault. --- -# Client Count FAQ +# Client count FAQ | Definitions | | ----------------------- | diff --git a/website/content/docs/concepts/dev-server.mdx b/website/content/docs/concepts/dev-server.mdx index acc4f54d666d..9b3443850c33 100644 --- a/website/content/docs/concepts/dev-server.mdx +++ b/website/content/docs/concepts/dev-server.mdx @@ -6,7 +6,7 @@ description: >- Vault. --- -# "Dev" Server Mode +# "Dev" server mode You can start Vault as a server in "dev" mode like so: `vault server -dev`. This dev-mode server requires no further setup, and your local `vault` CLI will @@ -46,7 +46,7 @@ flags or by specifying a configuration file): `secret/`. Please be aware that there are differences with v1 KV. If you want to use v1, use this flag `-dev-kv-v1`. -## Use Case +## Use case The dev server should be used for experimentation with Vault features, such as different auth methods, secrets engines, audit devices, etc. diff --git a/website/content/docs/concepts/duration-format.mdx b/website/content/docs/concepts/duration-format.mdx index d34c2b5a6e85..f39332f44800 100644 --- a/website/content/docs/concepts/duration-format.mdx +++ b/website/content/docs/concepts/duration-format.mdx @@ -4,14 +4,14 @@ page_title: Duration String Format description: A description of Vault's duration string format used throughout Vault. --- -# Duration String Format +# Duration string format Vault uses a unique duration string format as part of its configuration and APIs. This format is used throughout Vault wherever durations are provided. For example, telemetry configuration contains various options using this format, such as `usage_gauge_period`, which is the interval of collection for high-cardinality usage data. -## How It Works +## How it works A duration string is a possibly signed sequence of decimal numbers, each with an optional fraction and an optional unit suffix. If no unit is given, we interpret the numbers as seconds. diff --git a/website/content/docs/concepts/events.mdx b/website/content/docs/concepts/events.mdx index 50be813ea29c..a99578000e36 100644 --- a/website/content/docs/concepts/events.mdx +++ b/website/content/docs/concepts/events.mdx @@ -24,7 +24,7 @@ $ vault server -experiment events.alpha1 -> Note: Experiments can only be enabled at startup, and cannot be disabled or enabled at runtime. -## Event Types +## Event types @@ -52,7 +52,7 @@ The following events are currently generated by Vault and its builtin plugins au | kv | `kv-v2/undelete` | 1.13 | -## Event Format +## Event format Events may be formatted in protobuf binary format or as JSON. See `EventReceived` in [`sdk/logical/event.proto`](https://github.com/hashicorp/vault/blob/main/sdk/logical/event.proto) in the relevant Vault version for the protobuf schema. @@ -121,7 +121,7 @@ Here is an example event in JSON format: } ``` -## Subscribing to Events +## Subscribing to events Vault has an API endpoint, `/v1/sys/events/subscribe/{eventType}`, that allows users to subscribe to events via a WebSocket stream. @@ -161,7 +161,7 @@ path "sys/events/subscribe/*" { ``` -## Supported Versions +## Supported versions | Vault Version | Support | | ------------- | ------------------------------------------- | diff --git a/website/content/docs/concepts/ha.mdx b/website/content/docs/concepts/ha.mdx index 1a5909cbf4d4..a67b92665aff 100644 --- a/website/content/docs/concepts/ha.mdx +++ b/website/content/docs/concepts/ha.mdx @@ -6,7 +6,7 @@ description: >- against outages. --- -# High Availability Mode (HA) +# High availability mode (HA) Vault supports a multi-server mode for high availability. This mode protects against outages by running multiple Vault servers. High availability mode @@ -44,7 +44,7 @@ The sections below explain the server communication patterns and each type of request handling in more detail. At a minimum, the requirements for redirection mode must be met for an HA cluster to work successfully. -## Server-to-Server Communication +## Server-to-Server communication Both methods of request handling rely on the active node advertising information about itself to the other nodes. Rather than over the network, this @@ -66,7 +66,7 @@ sent over this TLS-protected communication channel, and acted upon by the active node. The active node then returns a response to the standby, which sends the response back to the requesting client. -## Request Forwarding +## Request forwarding If request forwarding is enabled (turned on by default in 0.6.2), clients can still force the older/fallback redirection behavior (see below) if desired by @@ -75,7 +75,7 @@ setting the `X-Vault-No-Request-Forwarding` header to any non-empty value. Successful cluster setup requires a few configuration parameters, although some can be automatically determined. -## Client Redirection +## Client redirection If `X-Vault-No-Request-Forwarding` header in the request is set to a non-empty value, the standby nodes will redirect the client using a `307` status code to @@ -98,7 +98,7 @@ accessed directly by clients, and Vault servers accessed via a load balancer. In both cases, the [`api_addr`](/vault/docs/configuration#api_addr) should be a full URL including scheme (`http`/`https`), not simply an IP address and port. -### Direct Access +### Direct access When clients are able to access Vault directly, the [`api_addr`](/vault/docs/configuration#api_addr) for each node should be that node's @@ -118,7 +118,7 @@ cause it to redirect the client to node `A`'s [`api_addr`](/vault/docs/configuration#api_addr) at `https://a.vault.mycompany.com`, and vice-versa. -### Behind Load Balancers +### Behind load balancers Sometimes clients use load balancers as an initial method to access one of the Vault servers, but actually have direct access to each Vault node. In this @@ -133,7 +133,7 @@ balancer's configuration will have been updated to know the address of the current leader. This can cause a redirect loop and as such is not a recommended setup when it can be avoided. -### Per-Node Cluster Listener Addresses +### Per-Node cluster listener addresses Each [`listener`](/vault/docs/configuration/listener) block in Vault's configuration file contains an [`address`](/vault/docs/configuration/listener/tcp#address) value on @@ -150,7 +150,7 @@ default, port `8201`). Note that _only_ active nodes have active listeners. When a node becomes active it will start cluster listeners, and when it becomes standby it will stop them. -### Per-Node Cluster Address +### Per-Node cluster address Similar to the [`api_addr`](/vault/docs/configuration#api_addr), [`cluster_addr`](/vault/docs/configuration#cluster_addr) is the value that each node, @@ -166,7 +166,7 @@ between servers.) This value can also be specified by the `VAULT_CLUSTER_ADDR` environment variable, which takes precedence. -## Storage Support +## Storage support Currently there are several storage backends that support high availability mode, including [Consul](/vault/docs/configuration/storage/consul), diff --git a/website/content/docs/concepts/identity.mdx b/website/content/docs/concepts/identity.mdx index 9b83381d97ee..c8e83f5f045f 100644 --- a/website/content/docs/concepts/identity.mdx +++ b/website/content/docs/concepts/identity.mdx @@ -14,7 +14,7 @@ an identity management solution through the **Identity secrets engine**. For more information about the Identity secrets engine and how it is used, refer to the [Identity Secrets Engine](/vault/docs/secrets/identity) documentation. -## Entities and Aliases +## Entities and aliases Each user may have multiple accounts with various identity providers, and Vault supports many of those providers to authenticate with Vault. Vault Identity can @@ -48,7 +48,7 @@ are audit logged, marking a trail of actions performed by specific users. about client count, refer to the [Client Count](/vault/docs/concepts/client-count) documentation. -## Entity Management +## Entity management Entities in Vault **do not** automatically pull identity information from anywhere. It needs to be explicitly managed by operators. This way, it is @@ -56,7 +56,7 @@ flexible in terms of administratively controlling the number of entities to be synced against Vault. In some sense, Vault will serve as a _cache_ of identities and not as a _source_ of identities. -## Entity Policies +## Entity policies Vault policies can be assigned to entities which will grant _additional_ permissions to the token on top of the existing policies on the token. If the @@ -85,7 +85,7 @@ policies. If a user can modify an alias they can login with, they can bind it to an entity with higher privileges. If a user can modify group membership, they can add their entity to a group with higher privileges. -## Mount Bound Aliases +## Mount bound aliases Vault supports multiple authentication backends and also allows enabling the same type of authentication backend on different mount paths. The alias name of @@ -122,7 +122,7 @@ a particular auth mount point. | Token | `entity_alias`, if provided | | Username (userpass) | Username | -## Local Auth Methods +## Local auth methods **Vault Enterprise:** All the auth methods will generate an entity by default when a token is being issued, with the exception of token store. This is applicable @@ -132,7 +132,7 @@ If the goal of marking an auth method as `local` was to comply to GDPR guideline then care must be taken to not set the data pertaining to local auth mount or local auth mount aliases in the metadata of the associated entity. -## Implicit Entities +## Implicit entities Operators can create entities for all the users of an auth mount beforehand and assign policies to them, so that when users login, the desired capabilities to @@ -145,13 +145,13 @@ normally have any associated identity information. An existing or new implicit entity can be assigned by using the `entity_alias` parameter, when creating a token using a token role with a configured list of `allowed_entity_aliases`. -## Identity Auditing +## Identity auditing If the token used to make API calls has an associated entity identifier, it will be audit logged as well. This leaves a trail of actions performed by specific users. -## Identity Groups +## Identity groups Vault identity has support for **groups**. A group can contain multiple entities as its members. A group can also have subgroups. Policies set on the group are @@ -162,7 +162,7 @@ on the entity itself. ![Identity overview](/img/vault-identity-doc-3.png) -## Group Hierarchical Permissions +## Group hierarchical permissions Entities can be direct members of groups, in which case they inherit the policies of the groups they belong to. Entities can also be indirect members of @@ -170,7 +170,7 @@ groups. For example, if a GroupA has GroupB as subgroup, then members of GroupB are indirect members of GroupA. Hence, the members of GroupB will have access to policies on both GroupA and GroupB. -## External vs Internal Groups +## External vs internal groups By default, the groups created in identity store are called the internal groups. The membership management of these groups should be carried out diff --git a/website/content/docs/concepts/integrated-storage/autopilot.mdx b/website/content/docs/concepts/integrated-storage/autopilot.mdx index 6e945d445935..18cd10b0d7a1 100644 --- a/website/content/docs/concepts/integrated-storage/autopilot.mdx +++ b/website/content/docs/concepts/integrated-storage/autopilot.mdx @@ -12,7 +12,7 @@ and State API. These three features were introduced in Vault 1.7. The Enterprise feature set includes 2 main features: Automated Upgrades and Redundancy Zones. These two features were introduced in Vault 1.11. -## Server Stabilization +## Server stabilization Server stabilization helps to retain the stability of the Raft cluster by safely joining new voting nodes to the cluster. When a new voter node is joined to an @@ -22,7 +22,7 @@ healthy for the entire duration of stabilization, then that node will be promoted as a voter. The server stabilization period can be tuned using `server_stabilization_time` (see below). -## Dead Server Cleanup +## Dead server cleanup Dead server cleanup automatically removes nodes deemed unhealthy from the Raft cluster, avoiding the manual operator intervention. This feature can be @@ -34,7 +34,7 @@ and `min_quorum` (see below). State API provides detailed information about all the nodes in the Raft cluster in a single call. This API can be used for monitoring for cluster health. -### Follower Health +### Follower health Follower node health is determined by 2 factors. @@ -43,7 +43,7 @@ Follower node health is determined by 2 factors. - Its ability to keep up with data replication from the leader node. Tuned using `max_trailing_logs` (see below). -### Default Configuration +### Default configuration By default, Autopilot will be enabled with clusters using Vault 1.7+, although dead server cleanup is not enabled by default. Upgrade of @@ -90,7 +90,7 @@ might also show up in Vault in comparison to Consul as well. Autopilot in Vault and Consul use different technical underpinnings requiring these differences, to provide the autopilot functionality. -## Automated Upgrades +## Automated upgrades Automated Upgrades lets you automatically upgrade a cluster of Vault nodes to a new version as updated server nodes join the cluster. Once the number of nodes on the new version is @@ -100,7 +100,7 @@ and initiate a leadership transfer from the older version leader to one of the n versioned nodes. After the leadership transfer completes, the older versioned non-voting nodes can be removed from the cluster. -## Redundancy Zones +## Redundancy zones Redundancy Zones provide both scaling and resiliency benefits by deploying non-voting nodes alongside voting nodes on a per availability zone basis. When using redundancy zones, diff --git a/website/content/docs/concepts/integrated-storage/index.mdx b/website/content/docs/concepts/integrated-storage/index.mdx index bf5797ca10dc..93575008e794 100644 --- a/website/content/docs/concepts/integrated-storage/index.mdx +++ b/website/content/docs/concepts/integrated-storage/index.mdx @@ -4,7 +4,7 @@ page_title: Integrated Storage description: Learn about the integrated raft storage in Vault. --- -# Integrated Storage +# Integrated storage Vault supports a number of storage options for the durable storage of Vault's information. As of Vault 1.4 an Integrated Storage option is offered. This @@ -23,7 +23,7 @@ Vault to use Integrated Storage. The sections below go into various details on how to operate Vault with Integrated Storage. -## Server-to-Server Communication +## Server-to-Server communication Once nodes are joined to one another they begin to communicate using mTLS over Vault's cluster port. The cluster port defaults to `8201`. The TLS information @@ -33,7 +33,7 @@ A requirement for Integrated Storage is that the [`cluster_addr`](/vault/docs/concepts/ha#per-node-cluster-address) configuration option is set. This allows Vault to assign an address to the node ID at join time. -## Cluster Membership +## Cluster membership This section will outline how to bootstrap and manage a cluster of Vault nodes running Integrated Storage. @@ -44,7 +44,7 @@ and results in a cluster of size 1. Depending on the [desired deployment size](/vault/docs/internals/integrated-storage/#deployment-table), nodes can be joined to the active Vault node. -### Joining Nodes +### Joining nodes Joining is the process of taking an uninitialized Vault node and making it a member of an existing cluster. In order to authenticate the new node to the @@ -60,7 +60,7 @@ API (both methods described below). When joining a node, the API address of the recommend setting the [`api_addr`](/vault/docs/concepts/ha#direct-access) configuration option on all nodes to make joining simpler. -#### `retry_join` Configuration +#### `retry_join` configuration This method enables setting one, or more, target leader nodes in the config file. When an uninitialized Vault server starts up it will attempt to join each potential @@ -138,7 +138,7 @@ active node's API address will need to be specified: $ vault operator raft join https://node1.vault.local:8200 ``` -#### Non-Voting Nodes (Enterprise Only) +#### Non-Voting nodes (Enterprise only) Nodes that are joined to a cluster can be specified as non-voters. A non-voting node has all of Vault's data replicated to it, but does not contribute to the @@ -150,7 +150,7 @@ a cluster in cases where a high volume of reads to servers are needed. $ vault operator raft join -non-voter https://node1.vault.local:8200 ``` -### Removing Peers +### Removing peers Removing a peer node is a necessary step when you no longer want the node in the cluster. This could happen if the node is rotated for a new one, the hostname @@ -167,7 +167,7 @@ $ vault operator raft remove-peer node1 Peer removed successfully! ``` -### Listing Peers +### Listing peers To see the current peer set for the cluster you can issue a [`list-peers`](/vault/docs/commands/operator/raft#list-peers) command. All the voting @@ -183,7 +183,7 @@ node2 node2.vault.local:8201 follower true node3 node3.vault.local:8201 leader true ``` -## Integrated Storage and TLS +## Integrated storage and TLS We've glossed over some details in the above sections on bootstrapping clusters. The instructions are sufficient for most cases, but some users have run into @@ -276,9 +276,9 @@ One potential issue here: some users want a public facing LB for clients to connect to Vault, but aren't comfortable with Vault internal traffic egressing from the internal network it normally runs on. -## Outage Recovery +## Outage recovery -### Quorum Maintained +### Quorum maintained This section outlines the steps to take when a single server or multiple servers are in a failed state but quorum is still maintained. This means the remaining @@ -298,7 +298,7 @@ possible or you'd rather manually re-write the cluster membership a [`raft/peers.json`](#manual-recovery-using-peers-json) file can be written to the configured data directory. -### Quorum Lost +### Quorum lost In the event that multiple servers are lost, causing a loss of quorum and a complete outage, partial recovery is still possible. @@ -329,7 +329,7 @@ In extreme cases, it should be possible to recover with just a single remaining server by starting that single server with itself as the only peer in the [`peers.json`](#manual-recovery-using-peers-json) recovery file. -### Manual Recovery Using peers.json +### Manual recovery using peers.json Using `raft/peers.json` for recovery can cause uncommitted Raft log entries to be implicitly committed, so this should only be used after an outage where no other @@ -382,7 +382,7 @@ At this point, you can restart all the remaining servers. The cluster should be in an operable state again. One of the nodes should claim leadership and become active. -### Other Recovery Methods +### Other recovery methods For other, non-quorum related recovery [Vault's recovery](/vault/docs/concepts/recovery-mode/) mode can be used. diff --git a/website/content/docs/concepts/lease.mdx b/website/content/docs/concepts/lease.mdx index eedd6b76ca8b..242d24d8a166 100644 --- a/website/content/docs/concepts/lease.mdx +++ b/website/content/docs/concepts/lease.mdx @@ -6,7 +6,7 @@ description: >- will revoke that secret. --- -# Lease, Renew, and Revoke +# Lease, renew, and revoke With every dynamic secret and `service` type authentication token, Vault creates a _lease_: metadata containing information such as a time duration, @@ -44,7 +44,7 @@ lease duration; see the documentation for more information. When reading a dynamic secret, such as via `vault read`, Vault always returns a `lease_id`. This is the ID used with commands such as `vault lease renew` and `vault lease revoke` to manage the lease of the secret. -## Lease Durations and Renewal +## Lease durations and renewal Along with the lease ID, a _lease duration_ can be read. The lease duration is a Time To Live value: the time in seconds for which the lease is valid. A @@ -71,7 +71,7 @@ determine what the new lease is. -> To implement token renewal logic in your application code, refer to the [code example in the Authentication doc](/vault/docs/concepts/auth#code-example). -## Prefix-based Revocation +## Prefix-based revocation In addition to revoking a single secret, operators with proper access control can revoke multiple secrets based on their lease ID prefix. diff --git a/website/content/docs/concepts/mount-migration.mdx b/website/content/docs/concepts/mount-migration.mdx index 69b0868e776b..8ae1e91b58ad 100644 --- a/website/content/docs/concepts/mount-migration.mdx +++ b/website/content/docs/concepts/mount-migration.mdx @@ -4,7 +4,7 @@ page_title: Mount Migration description: Move secrets and auth mounts within and across namespaces --- -# Mount Migration +# Mount migration Vault supports moving secrets and auth mounts, both within and across namespaces. The operation is supported by API endpoints and a CLI helper around them. @@ -18,7 +18,7 @@ When migrating from an OSS binary to an Enterprise binary, organizations may wan mounts across several namespaces. Mounts may also be moved across namespaces when there is a reorganization of roles and responsibilities. -## Async Behavior +## Async behavior The first thing to note about the `sys/remount` endpoint is that it is an asynchronous endpoint. An invocation will start the migration process, and the API will return a migration ID. This ID, in turn, be used to monitor @@ -74,7 +74,7 @@ mount in ns2/, or update the policy to refer to paths valid from the ns2/ namesp The mount being moved may have rate limit or lease count quotas.. The remount process will update these quotas to refer to the new path of the mount. -## Path Filters +## Path filters The remount operation will respect any existing path filters. Three uses cases, in particular, are shown below. here. diff --git a/website/content/docs/concepts/namespace-api-lock.mdx b/website/content/docs/concepts/namespace-api-lock.mdx index 3a92adea6aa2..99fdadc64bf8 100644 --- a/website/content/docs/concepts/namespace-api-lock.mdx +++ b/website/content/docs/concepts/namespace-api-lock.mdx @@ -4,7 +4,7 @@ page_title: Namespace API Lock description: Lock the Vault API on a per-namespace basis. --- -# Namespace Lock and Unlock +# Namespace lock and unlock Vault makes the API available (unlocked) by default for all namespaces. In this state, Vault can respond to all API/CLI ('API' from here on out) requests @@ -69,7 +69,7 @@ When the API is unlocked, it will also be unlocked for all descendants that were locked with it. If a descendant namespace was previously locked, that lock will remain in place. -## API Locked Response +## API locked response If a request is made to a non-exempt path from a locked namespace, e.g. `nsA`, Vault responds with an HTTP 503: Service Unavailable. It will also produce the diff --git a/website/content/docs/concepts/oidc-provider.mdx b/website/content/docs/concepts/oidc-provider.mdx index 1b132257c4cc..b95d4e7ac9fb 100644 --- a/website/content/docs/concepts/oidc-provider.mdx +++ b/website/content/docs/concepts/oidc-provider.mdx @@ -5,7 +5,7 @@ description: >- Describes how Vault can be an OIDC identity provider. --- -# OIDC Provider +# OIDC provider This document provides conceptual information about the Vault **OpenID Connect (OIDC) identity provider** feature. This feature enables client applications that speak the OIDC protocol to @@ -13,11 +13,11 @@ leverage Vault's source of [identity](/vault/docs/concepts/identity) and wide ra when authenticating end-users. For more information about the usage of Vault's OIDC provider, refer to the [OIDC identity provider](/vault/docs/secrets/identity/oidc-provider) documentation. -## Configuration Options +## Configuration options The next few sections of the document provide implementation details for each resource that permits Vault configuration as an OIDC identity provider. -### OIDC Providers +### OIDC providers Each Vault namespace will contain a built-in provider resource named `default`. The `default` provider will allow all client applications within the namespace to use it for OIDC flows. @@ -96,7 +96,7 @@ The following defines the claims key and value mapping for the `openid` scope: * `iat`- time of token issue * `exp`- time of token issue + ID token TTL -### Client Applications +### Client applications A client resource represents an application that wants to delegate end-user authentication to Vault using the OIDC protocol. The information provided by a client resource can be used @@ -121,7 +121,7 @@ characters from the base62 character set. ~> **Note**: At least one of the redirect URIs of a client must exactly match the `redirect_uri` parameter used in an authentication request initiated by the client. -#### Client Types +#### Client types A client resource has a `client_type` parameter which specifies the OAuth 2.0 [client type](https://datatracker.ietf.org/doc/html/rfc6749#section-2.1) based on @@ -197,7 +197,7 @@ Each provider offers an unauthenticated endpoint that facilitates OIDC Discovery Each provider offers an unauthenticated endpoint that provides the public portion of keys used to sign ID tokens. The keys are published in a JSON Web Key Set [(JWKS)](https://datatracker.ietf.org/doc/html/rfc7517) format. The keyset for an individual provider contains the keys referenced by all clients via the `allowed_client_ids` configuration parameter. A `Cache-Control` header to set based on responses, allowing clients to refresh their keys upon rotation. The `max-age` of the header is set based on the earliest rotation time of any of the keys in the keyset. -### Authorization Endpoint +### Authorization endpoint Each provider offers an authenticated [authorization endpoint](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint). The authorization endpoint for each provider is added to Vault's [default policy](/vault/docs/concepts/policies#default-policy) using the `identity/oidc/provider/+/authorize` path. The endpoint incorporates all required [authentication request](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest) parameters as input. @@ -205,7 +205,7 @@ The endpoint [validates](https://openid.net/specs/openid-connect-core-1_0.html#A An authorization code is generated with a successful validation of the request. The authorization code is single-use and cached with a lifetime of approximately 5 minutes, which mitigates the risk of leaks. A response including the original `state` presented by the client and `code` will be returned to the Vault UI which initiated the request. Vault will issue an HTTP 302 redirect to the `redirect_uri` of the request, which includes the `code` and `state` as query parameters. -### Token Endpoint +### Token endpoint Each provider will offer a [token endpoint](/vault/api-docs/secret/identity/oidc-provider#token-endpoint). The endpoint may be unauthenticated in Vault but is authenticated by requiring a `client_secret` as described in [client authentication](https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication). The endpoint ingests all required [token request](/vault/api-docs/secret/identity/oidc-provider#parameters-15) parameters as input. The endpoint [validates](https://openid.net/specs/openid-connect-core-1_0.html#TokenRequestValidation) the client requests and exchanges an authorization code for the ID token and access token. The cache of authorization codes will be verified against the code presented in the exchange. The appropriate [error codes](https://openid.net/specs/openid-connect-core-1_0.html#TokenErrorResponse) are returned for all invalid requests. @@ -213,6 +213,6 @@ The ID token is generated and returned upon successful client authentication and An access token is also generated and returned upon successful client authentication and request validation. The access token is a Vault [batch token](/vault/docs/concepts/tokens#batch-tokens) with a policy that only provides read access to the issuing provider's [userinfo endpoint](/vault/api-docs/secret/identity/oidc-provider#userinfo-endpoint). The access token is also a TTL as defined by the `access_token_ttl` of the requesting client. -### UserInfo Endpoint +### UserInfo endpoint Each provider provides an authenticated [userinfo endpoint](/vault/api-docs/secret/identity/oidc-provider#userinfo-endpoint). The endpoint accepts the access token obtained from the token endpoint as a [bearer token](/vault/api-docs#authentication). The userinfo response is a JSON object with the `application/json` content type. The JSON object contains claims for the Vault entity associated with the access token. The claims returned are determined by the scopes requested in the authentication request that produced the access token. The `sub` claim is always returned as the entity ID in the userinfo response. diff --git a/website/content/docs/concepts/password-policies.mdx b/website/content/docs/concepts/password-policies.mdx index e134ce5f5f00..40d29584069f 100644 --- a/website/content/docs/concepts/password-policies.mdx +++ b/website/content/docs/concepts/password-policies.mdx @@ -6,7 +6,7 @@ description: >- for dynamic & static users within those engines. --- -# Password Policies +# Password policies A password policy is a set of instructions on how to generate a password, similar to other password generators. These password policies are used in a subset of secret engines to allow you to configure @@ -39,7 +39,7 @@ The flow looks like: [![Vault Password Policy Flow](/img/vault-password-policy-flow.svg)](/img/vault-password-policy-flow.svg) -## Candidate Password Generation +## Candidate password generation How a candidate password is generated is extremely important. Great care must be placed to ensure that passwords aren't created in a way that can be exploited by threat actors. This section describes how we @@ -72,7 +72,7 @@ values that a single byte can be. The value is restricted to the size of the cha [modulo operation](https://en.wikipedia.org/wiki/Modulo_operation) to prevent referencing a character outside the bounds of the charset. However this can introduce a problem with bias. -### Preventing Bias +### Preventing bias When using the [modulo operation](https://en.wikipedia.org/wiki/Modulo_operation) to generate a password, you must be very careful to prevent the introduction of bias. When generating a random number between @@ -93,7 +93,7 @@ larger than our maximum allowed value, that number is ignored and we continue to do not lose any length because we continue generating numbers until the password is fully filled in to the length requested. -## Performance Characteristics +## Performance characteristics Characterizing password generation performance with this model is heavily dependent on the policy configuration. In short, the more restrictive the policy, the longer it will take to generate a password. @@ -242,7 +242,7 @@ produce passwords. -## Password Policy Syntax +## Password policy syntax Password policies are defined in [HCL](https://github.com/hashicorp/hcl) or JSON which defines the length of the password and a set of rules a password must adhere to. @@ -291,9 +291,9 @@ The following policy is **NOT** valid and will be rejected: length = 20 ``` -## Configuration & Available Rules +## Configuration & available rules -### `length` Parameter +### `length` parameter - `length` `(int: )` - Specifies how long the generated password will be. Must be >= 4. diff --git a/website/content/docs/concepts/pgp-gpg-keybase.mdx b/website/content/docs/concepts/pgp-gpg-keybase.mdx index b876a24373bb..300e76fc30c9 100644 --- a/website/content/docs/concepts/pgp-gpg-keybase.mdx +++ b/website/content/docs/concepts/pgp-gpg-keybase.mdx @@ -8,7 +8,7 @@ description: |- integrations, their use, and operation. --- -# Using PGP, GnuPG, and Keybase +# Using PGP, GnuPG, and keybase Vault has the ability to integrate with OpenPGP-compatible programs like GnuPG and services like Keybase.io to provide an additional layer of security when @@ -46,7 +46,7 @@ of public online sources. It also exposes the ability for users to have PGP keys generated, stored, and managed securely on their servers. Using Vault with Keybase will be discussed first as it is simpler. -## Initializing with Keybase +## Initializing with keybase To generate unseal keys for Keybase users, Vault accepts the `keybase:` prefix to the `-pgp-keys` argument: @@ -75,7 +75,7 @@ accounts of `jefferai`, `vishalnayak`, and `sethvargo`. These keys can be distributed over almost any medium, although common sense and judgement are best advised. The encrypted keys are base64 encoded before returning. -### Unsealing with Keybase +### Unsealing with keybase As a user, the easiest way to decrypt your unseal key is with the Keybase CLI tool. You can download it from [Keybase.io download diff --git a/website/content/docs/concepts/policies.mdx b/website/content/docs/concepts/policies.mdx index a58a39262b8a..13297a6543fb 100644 --- a/website/content/docs/concepts/policies.mdx +++ b/website/content/docs/concepts/policies.mdx @@ -77,7 +77,7 @@ the authentication steps again, they will get a _new_ token. The token will have the same permissions, but the actual token will be different. Authenticating a second time does not invalidate the original token. -## Policy Syntax +## Policy syntax Policies are written in [HCL][hcl] or JSON and describe which paths in Vault a user or machine is allowed to access. @@ -101,19 +101,19 @@ token would have no other access in Vault. Here is a more detailed policy, and it is documented inline: ```ruby -# This section grants all access on "secret/*". Further restrictions can be +# This section grants all access on "secret/*". further restrictions can be # applied to this broad policy, as shown below. path "secret/*" { capabilities = ["create", "read", "update", "patch", "delete", "list"] } # Even though we allowed secret/*, this line explicitly denies -# secret/super-secret. This takes precedence. +# secret/super-secret. this takes precedence. path "secret/super-secret" { capabilities = ["deny"] } -# Policies can also specify allowed, disallowed, and required parameters. Here +# Policies can also specify allowed, disallowed, and required parameters. here # the key "secret/restricted" can only contain "foo" (any value) and "bar" (one # of "zip" or "zap"). path "secret/restricted" { @@ -130,19 +130,19 @@ request. A policy `path` may specify an exact path to match, or it could specify a glob pattern which instructs Vault to use a prefix match: ```ruby -# Permit reading only "secret/foo". An attached token cannot read "secret/food" +# Permit reading only "secret/foo". an attached token cannot read "secret/food" # or "secret/foo/bar". path "secret/foo" { capabilities = ["read"] } -# Permit reading everything under "secret/bar". An attached token could read +# Permit reading everything under "secret/bar". an attached token could read # "secret/bar/zip", "secret/bar/zip/zap", but not "secret/bars/zip". path "secret/bar/*" { capabilities = ["read"] } -# Permit reading everything prefixed with "zip-". An attached token could read +# Permit reading everything prefixed with "zip-". an attached token could read # "secret/zip-zap" or "secret/zip-zap/zong", but not "secret/zip/zap path "secret/zip-*" { capabilities = ["read"] @@ -489,9 +489,9 @@ path "secret/foo" { ~> **Note:** the only value that can be used with the `*` parameter is `[]`. -#### Parameter Constraints Limitations +#### Parameter constraints limitations -##### Default Values +##### Default values Evaluation of policies with `allowed_parameters`, `denied_parameters`, and `required_parameters` happens without consideration of parameters' default values. @@ -551,13 +551,13 @@ or unexpected behavior: ```ruby # This allows the user to create, update, or patch "secret/foo" with a parameter -# named "bar". The values passed to parameter "bar" must start with "baz/" -# so values like "baz/quux" are fine. However, values like -# "baz/quux,wibble,wobble,wubble" would also be accepted. The API that +# named "bar". the values passed to parameter "bar" must start with "baz/" +# so values like "baz/quux" are fine. however, values like +# "baz/quux,wibble,wobble,wubble" would also be accepted. the API that # underlies "secret/foo" might allow comma delimited values for the "bar" # parameter, and if it did, specifying a value like # "baz/quux,wibble,wobble,wubble" would result in 4 different values getting -# passed along. Seeing values like "wibble" or "wobble" getting passed to +# passed along. seeing values like "wibble" or "wobble" getting passed to # "secret/foo" might surprise someone that expected the allowed_parameters # constraint to only allow values starting with "baz/". path "secret/foo" { @@ -601,12 +601,12 @@ addition, if paths are merged from different stanzas, the lowest value specified for each is the value that will result, in line with the idea of keeping token lifetimes as short as possible. -## Built-in Policies +## Built-in policies Vault has two built-in policies: `default` and `root`. This section describes the two built-in policies. -### Default Policy +### Default policy The `default` policy is a built-in Vault policy that cannot be removed. By default, it is attached to all tokens, but may be explicitly excluded at token diff --git a/website/content/docs/concepts/recovery-mode.mdx b/website/content/docs/concepts/recovery-mode.mdx index 891f77490cf2..c46e8d530b8f 100644 --- a/website/content/docs/concepts/recovery-mode.mdx +++ b/website/content/docs/concepts/recovery-mode.mdx @@ -4,7 +4,7 @@ page_title: Recovery Mode description: Recovery mode allows for doing surgery on a Vault that won't start. --- -# Recovery Mode +# Recovery mode Vault can be started using the `-recovery` flag to bring it up in Recovery Mode. The main purpose of recovery mode is to allow direct access to storage in case diff --git a/website/content/docs/concepts/resource-quotas.mdx b/website/content/docs/concepts/resource-quotas.mdx index dee76b1dc9fb..5051f1380fa8 100644 --- a/website/content/docs/concepts/resource-quotas.mdx +++ b/website/content/docs/concepts/resource-quotas.mdx @@ -4,7 +4,7 @@ page_title: Resource Quotas description: Providing measures against misbehaving applications and users overdrawing resources in Vault. --- -# Resource Quotas +# Resource quotas Every single interaction with Vault, whether to put secrets into the key/value store or to generate new pairs of database credentials for the MySQL database, @@ -24,7 +24,7 @@ and configure API rate limits. Users of Vault Enterprise have a second option, a rate limits, [lease-count quotas](/vault/docs/enterprise/lease-count-quotas), which can limit the number of leases that can be in use at one time. -## Rate Limit Quotas +## Rate limit quotas Vault allows operators to create rate limit quotas which enforce API rate limiting using a [token bucket](https://en.wikipedia.org/wiki/Token_bucket) algorithm. @@ -52,7 +52,7 @@ Vault also allows the inspection of the state of rate limiting in a Vault node through various [metrics](/vault/docs/internals/telemetry#Resource-Quota-Metrics) exposed and through enabling optional audit logging. -## Exempt Routes +## Exempt routes By default, the following paths are exempt from rate limiting. However, Vault operators can override the set of paths that are exempt from all rate limit diff --git a/website/content/docs/concepts/response-wrapping.mdx b/website/content/docs/concepts/response-wrapping.mdx index f0175557d6df..53b4c79243ac 100644 --- a/website/content/docs/concepts/response-wrapping.mdx +++ b/website/content/docs/concepts/response-wrapping.mdx @@ -4,7 +4,7 @@ page_title: Response Wrapping description: Wrapping responses in cubbyholes for secure distribution. --- -# Response Wrapping +# Response wrapping _Note_: Some of this information relies on features of response-wrapping tokens introduced in Vault 0.8 and may not be available in earlier releases. @@ -53,7 +53,7 @@ secret's exposure. Response wrapping performs all three of these duties: be much shorter), so if a client fails to come up and unwrap the token, the token can expire very quickly. -## Response-Wrapping Tokens +## Response-Wrapping tokens When a response is wrapped, the normal API response from Vault does not contain the original secret, but rather contains a set of information related to the @@ -83,7 +83,7 @@ address (and in most cases the Vault address will not change or will be set via a service discovery mechanism). As such, we rely on the fact that the token itself is not carrying authoritative data and do not sign it. -## Response-Wrapping Token Operations +## Response-Wrapping token operations Via the `sys/wrapping` path, several operations can be run against wrapping tokens: @@ -111,7 +111,7 @@ tokens: endpoint does not remove the ability for arbitrary data to be wrapped, as it can be done elsewhere in Vault. -## Response-Wrapping Token Creation +## Response-Wrapping token creation Response wrapping is per-request and is triggered by providing to Vault the desired TTL for a response-wrapping token for that request. This is set by the @@ -137,7 +137,7 @@ Note that policies can control minimum/maximum wrapping TTLs; see the [policies concepts page](/vault/docs/concepts/policies) for more information. -## Response-Wrapping Token Validation +## Response-Wrapping token validation Proper validation of response-wrapping tokens is essential to ensure that any malfeasance is detected. It's also pretty straightforward. diff --git a/website/content/docs/concepts/seal.mdx b/website/content/docs/concepts/seal.mdx index 52702f3e4d6e..7d63ca829986 100644 --- a/website/content/docs/concepts/seal.mdx +++ b/website/content/docs/concepts/seal.mdx @@ -83,7 +83,7 @@ This way, if there is a detected intrusion, the Vault data can be locked quickly to try to minimize damages. It can't be accessed again without access to the root key shares. -## Auto Unseal +## Auto unseal -> **Note:** The Seal Wrap functionality is enabled by default. For this reason, the seal provider (HSM or cloud KMS) must be available throughout @@ -134,7 +134,7 @@ against *some* of this risk. Unreplicated items such as local mounts could stil be lost. -## Recovery Key +## Recovery key When Vault is initialized while using an HSM or KMS, rather than unseal keys being returned to the operator, recovery keys are returned. These are generated @@ -167,7 +167,7 @@ generate a key, and no key is found. See ### Rekeying -#### Unseal Key +#### Unseal key Vault's unseal key can be rekeyed using a normal `vault operator rekey` operation from the CLI or the matching API calls. The rekey operation is @@ -175,7 +175,7 @@ authorized by meeting the threshold of recovery keys. After rekeying, the new barrier key is wrapped by the HSM or KMS and stored like the previous key; it is not returned to the users that submitted their recovery keys. -#### Recovery Key +#### Recovery key The recovery key can be rekeyed to change the number of shares/threshold or to target different key holders via different PGP keys. When using the Vault CLI, @@ -187,7 +187,7 @@ endpoint](/vault/api-docs/system/rekey); however, the API prefix for this operation is at `/sys/rekey-recovery-key` rather than `/sys/rekey`. -## Seal Migration +## Seal migration The Seal migration process cannot be performed without downtime, and due to the technical underpinnings of the seal implementations, the process requires that @@ -262,7 +262,7 @@ any storage backend. ### Migration pre 1.5.1 -#### Migration From Shamir to Auto Unseal +#### Migration from shamir to auto unseal To migrate from Shamir keys to Auto Unseal, take your server cluster offline and update the [seal configuration](/vault/docs/configuration/seal) with the appropriate @@ -276,7 +276,7 @@ keys. `$ vault operator unseal -migrate` -#### Migration From Auto Unseal to Shamir +#### Migration from auto unseal to shamir To migrate from Auto Unseal to Shamir keys, take your server cluster offline and update the [seal configuration](/vault/docs/configuration/seal) and add `disabled @@ -287,7 +287,7 @@ to perform the migration. All unseal commands must specify the `-migrate` flag. Once the required threshold of recovery keys are entered, the recovery keys will be migrated to be used as unseal keys. -#### Migration From Auto Unseal to Auto Unseal +#### Migration from auto unseal to auto unseal ~> **NOTE**: Migration between same Auto Unseal types is supported in Vault 1.6.0 and higher. For these pre-1.5.1 steps, it is only possible to migrate from @@ -304,7 +304,7 @@ must specify the `-migrate` flag. Once the required threshold of recovery keys are entered, the recovery keys will be kept and used as recovery keys in the new seal. -#### Migration with Integrated Storage +#### Migration with integrated storage Integrated Storage uses the Raft protocol underneath, which requires a quorum of servers to be online before the cluster is functional. Therefore, bringing the diff --git a/website/content/docs/concepts/storage.mdx b/website/content/docs/concepts/storage.mdx index a90930108801..77ddb5e15db2 100644 --- a/website/content/docs/concepts/storage.mdx +++ b/website/content/docs/concepts/storage.mdx @@ -11,7 +11,7 @@ description: >- As described on our [Architecture](/vault/docs/internals/architecture) page, Vault's storage backend is untrusted storage used purely to keep encrypted information. -## Supported Storage Backends +## Supported storage backends @include 'ent-supported-storage.mdx' @@ -37,7 +37,7 @@ When backing up Vault, there are two pieces to consider: There's also a big question - what is the error case you're trying to guard against by saving a backup? -### The Big Question - Why Take Backups? +### The big question - why take backups? It's important to consider the question of "why take a backup" while developing your ongoing backup and disaster recovery strategy. @@ -75,7 +75,7 @@ replication with Vault Enterprise. As you develop a plan for recovering from or guarding against failure, you should consider both backups and HA as critical components of that plan. -### Backing up Vault's Persisted Data +### Backing up vault's persisted data Backups and restores are ideally performed while Vault is offline. If offline backups are not feasible, we recommend using a storage backend that supports @@ -94,7 +94,7 @@ restoring backups. - Integrated Storage [snapshots](/vault/docs/commands/operator/raft#snapshot) - Consul [snapshots](/consul/commands/snapshot) -#### Backing up Multiple Clusters +#### Backing up multiple clusters If you are using Vault Enterprise [Performance Replication](/vault/docs/enterprise/replication#performance-replication-and-disaster-recovery-dr-replication), diff --git a/website/content/docs/concepts/tokens.mdx b/website/content/docs/concepts/tokens.mdx index 29b9981e61e2..295cc440da8c 100644 --- a/website/content/docs/concepts/tokens.mdx +++ b/website/content/docs/concepts/tokens.mdx @@ -33,7 +33,7 @@ Read on for a deeper dive into token concepts. See the [tokens tutorial](/vault/tutorials/tokens/tokens) for details on how these concepts play out in practice. -## Token Types +## Token types As of Vault 1.0, there are two types of tokens: `service` tokens and `batch` tokens. A section near the bottom of this page contains detailed information @@ -41,7 +41,7 @@ about their differences, but it is useful to understand other token concepts first. The features in the following sections all apply to service tokens, and their applicability to batch tokens is discussed later. -## The Token Store +## The token store Often in documentation or in help channels, the "token store" is referenced. This is the same as the [`token` authentication @@ -50,7 +50,7 @@ backend in that it is responsible for creating and storing tokens, and cannot be disabled. It is also the only auth method that has no login capability -- all actions require existing authenticated tokens. -## Root Tokens +## Root tokens Root tokens are tokens that have the `root` policy attached to them. Root tokens can do anything in Vault. _Anything_. In addition, they are the only @@ -78,7 +78,7 @@ whenever a root token is live. This way multiple people can verify as to the tasks performed with the root token, and that the token was revoked immediately after these tasks were completed. -## Token Hierarchies and Orphan Tokens +## Token hierarchies and orphan tokens Normally, when a token holder creates new tokens, these tokens will be created as children of the original token; tokens they create will be children of them; @@ -101,7 +101,7 @@ endpoint, which revokes the given token but rather than revoke the rest of the tree, it instead sets the tokens' immediate children to be orphans. Use with caution! -## Token Accessors +## Token accessors When tokens are created, a token accessor is also created and returned. This accessor is a value that acts as a reference to a token and can only be used to @@ -133,7 +133,7 @@ dangerous endpoint (since listing all of the accessors means that they can then be used to revoke all tokens), it also provides a way to audit and revoke the currently-active set of tokens. -## Token Time-To-Live, Periodic Tokens, and Explicit Max TTLs +## Token Time-To-Live, periodic tokens, and explicit max TTLs Every non-root token has a time-to-live (TTL) associated with it, which is a current period of validity since either the token's creation time or last @@ -149,7 +149,7 @@ token is a periodic token (available for creation by `root`/`sudo` users, token store roles, or some auth methods), has an explicit maximum TTL attached, or neither. -### The General Case +### The general case In the general case, where there is neither a period nor explicit maximum TTL value set on the token, the token's lifetime since it was created will be @@ -177,7 +177,7 @@ current value and the client may want to reauthenticate and acquire a new token. However, outside of direct operator interaction, Vault will never revoke a token before the returned TTL has expired. -### Explicit Max TTLs +### Explicit max TTLs Tokens can have an explicit max TTL set on them. This value becomes a hard limit on the token's lifetime -- no matter what the values in (1), (2), and (3) @@ -185,7 +185,7 @@ from the general case are, the token cannot live past this explicitly-set value. This has an effect even when using periodic tokens to escape the normal TTL mechanism. -### Periodic Tokens +### Periodic tokens In some cases, having a token be revoked would be problematic -- for instance, if a long-running service needs to maintain its SQL connection pool over a long @@ -221,31 +221,31 @@ There are a few important things to know when using periodic tokens: - A token with both a period and an explicit max TTL will act like a periodic token but will be revoked when the explicit max TTL is reached -## CIDR-Bound Tokens +## CIDR-Bound tokens Some tokens are able to be bound to CIDR(s) that restrict the range of client IPs allowed to use them. These affect all tokens except for non-expiring root tokens (those with a TTL of zero). If a root token has an expiration, it also is affected by CIDR-binding. -## Token Types in Detail +## Token types in detail There are currently two types of tokens. -### Service Tokens +### Service tokens Service tokens are what users will generally think of as "normal" Vault tokens. They support all features, such as renewal, revocation, creating child tokens, and more. They are correspondingly heavyweight to create and track. -### Batch Tokens +### Batch tokens Batch tokens are encrypted blobs that carry enough information for them to be used for Vault actions, but they require no storage on disk to track them. As a result they are extremely lightweight and scalable, but lack most of the flexibility and features of service tokens. -### Token Type Comparison +### Token type comparison This reference chart describes the difference in behavior between service and batch tokens. @@ -266,14 +266,14 @@ batch tokens. | Creation Scales with Performance Standby Node Count | No | Yes | | Cost | Heavyweight; multiple storage writes per token creation | Lightweight; no storage cost for token creation | -### Service vs. Batch Token Lease Handling +### Service vs. batch token lease handling -#### Service Tokens +#### Service tokens Leases created by service tokens (including child tokens' leases) are tracked along with the service token and revoked when the token expires. -#### Batch Tokens +#### Batch tokens Leases created by batch tokens are constrained to the remaining TTL of the batch tokens and, if the batch token is not an orphan, are tracked by the diff --git a/website/content/docs/concepts/transform.mdx b/website/content/docs/concepts/transform.mdx index b86cba1bdddb..b66bc12527a9 100644 --- a/website/content/docs/concepts/transform.mdx +++ b/website/content/docs/concepts/transform.mdx @@ -6,7 +6,7 @@ description: >- stored outside of Vault. --- -# Transform Secrets Engine +# Transform secrets engine Part of Vault's Advanced Data Protection solutions, Transform provides mechanisms for _transforming_ sensitive information to protect it even as it lives outside @@ -18,13 +18,13 @@ formats. **Masking** for replacing sensitive information with masking characters. And **Tokenization** which replaces sensitive information with mathematically unrelated tokens. -## Comparison to Transit +## Comparison to transit Transit implements many traditional cryptographic primitives, such as AES encryption and RSA signatures (among others). Transform implements solutions to protect sensitive values in more narrow, but still critical use cases. -## What Solution When? +## What solution when? When should one use a particular transform or transit encryption? Based on your use case and its requirements, this flowchart can help you choose the right diff --git a/website/content/docs/concepts/user-lockout.mdx b/website/content/docs/concepts/user-lockout.mdx index 1ecbb66cbba7..5e422a026040 100644 --- a/website/content/docs/concepts/user-lockout.mdx +++ b/website/content/docs/concepts/user-lockout.mdx @@ -7,7 +7,7 @@ description: >- returning immediately with a permission denied error. --- -# User Lockout +# User lockout @include 'user-lockout.mdx' diff --git a/website/content/docs/concepts/username-templating.mdx b/website/content/docs/concepts/username-templating.mdx index 53acabb870de..3297fab55678 100644 --- a/website/content/docs/concepts/username-templating.mdx +++ b/website/content/docs/concepts/username-templating.mdx @@ -6,7 +6,7 @@ description: >- how dynamic usernames are generated. --- -# Username Templating +# Username templating Some of the secrets engines that generate dynamic users for external systems provide the ability for Vault operators to customize how usernames are generated for said external systems. This customization feature uses the @@ -20,9 +20,9 @@ otherwise multiple calls to create the credentials may interfere with each other In addition to the functionality built into the Go template language, a number of additional functions are available: -## Available Functions +## Available functions -### String/Character Manipulation +### String/Character manipulation `lowercase` - Lowercases the input value.
**Example**: `{{.FieldName | lowercase}}` @@ -43,7 +43,7 @@ original value: `abcdefghijkl872808ff`. `uppercase` - Uppercases the input value.
**Example**: `{{.FieldName | uppercase}}` -### Generating Values +### Generating values `random` - Generates a random string from lowercase letters, uppercase letters, and numbers. Must include a number indicating how many characters to generate.
@@ -88,7 +88,7 @@ For instance: `{{.DisplayName}}` is equivalent to `{{ .DisplayName }}` To reference either of these fields, a `.` must be put in front of the field name: `{{.DisplayName}}`. Custom functions do not include a `.` in front of them: `{{random 20}}`. -### Basic Example +### Basic example **Template**: @@ -108,7 +108,7 @@ a simple string substitution. ~> This example does not have any randomness and should not be used when generating dynamic usernames. The purpose is to demonstrate referencing data within the Go template language. -### Custom Functions +### Custom functions **Template**: @@ -127,7 +127,7 @@ FOO_TOKEN_WITH_DISPLAY_NAME_MY_CUSTOM_DATABASE_ROLE_2009_02_13T11_31_30Z_0700 `{{timestamp "2006_01_02T15_04_05Z" | replace "-" "_"}}` - Generates the current timestamp using the provided format and replaces all dashes with underscores. -### Truncating to Maximum Length +### Truncating to maximum length **Template**: diff --git a/website/content/docs/configuration/entropy-augmentation.mdx b/website/content/docs/configuration/entropy-augmentation.mdx index 1d4951790ec1..51a3be822345 100644 --- a/website/content/docs/configuration/entropy-augmentation.mdx +++ b/website/content/docs/configuration/entropy-augmentation.mdx @@ -6,7 +6,7 @@ description: >- cryptographic modules. --- -# `Entropy Augmentation` Seal +# `Entropy augmentation` seal Entropy augmentation enables Vault to sample entropy from external cryptographic modules. Sourcing external entropy is done by configuring a supported [Seal](/vault/docs/configuration/seal) type which @@ -31,7 +31,7 @@ via the [PKCS11 seal](/vault/docs/configuration/seal/pkcs11): - The [GNU libltdl library](https://www.gnu.org/software/libtool/manual/html_node/Using-libltdl) — ensure that it is installed for the correct architecture of your servers -## `entropy` Example +## `entropy` example This example shows configuring entropy augmentation through a PKCS11 HSM seal from Vault's configuration file: @@ -49,7 +49,7 @@ entropy "seal" { For a more detailed tutorial, visit the [HSM Entropy Challenge](/vault/tutorials/enterprise/hsm-entropy) on HashiCorp's Learn website. -## `entropy augmentation` Parameters +## `entropy augmentation` parameters These parameters apply to the `entropy` stanza in the Vault configuration file: diff --git a/website/content/docs/configuration/index.mdx b/website/content/docs/configuration/index.mdx index 7b430454330d..337a3dc01881 100644 --- a/website/content/docs/configuration/index.mdx +++ b/website/content/docs/configuration/index.mdx @@ -4,7 +4,7 @@ page_title: Server Configuration description: Vault server configuration reference. --- -# Vault Configuration +# Vault configuration Outside of development mode, Vault servers are configured using a file. The format of this file is [HCL](https://github.com/hashicorp/hcl) or JSON. @@ -221,7 +221,7 @@ a negative effect on performance due to the tracking of each lock attempt. the `VAULT_EXPERIMENTS` environment variable as a comma-separated list, or via the [`-experiment`](/vault/docs/commands/server#experiment) flag. -### High Availability Parameters +### High availability parameters The following parameters are used on backends that support [high availability][high-availability]. @@ -248,7 +248,7 @@ The following parameters are used on backends that support [high availability][h will disable these features _only when that node is the active node_. This parameter cannot be set to `true` if `raft` is the storage type. -### Vault Enterprise Parameters +### Vault enterprise parameters The following parameters are only used with Vault Enterprise diff --git a/website/content/docs/configuration/kms-library.mdx b/website/content/docs/configuration/kms-library.mdx index ce52388ecfe7..d83655abb5c1 100644 --- a/website/content/docs/configuration/kms-library.mdx +++ b/website/content/docs/configuration/kms-library.mdx @@ -6,7 +6,7 @@ description: >- KMS access libraries --- -# `kms_library` Stanza +# `kms_library` stanza The `kms_library` stanza isolates platform specific configuration for managed keys. It defines logical names that are referenced within an API configuration keeping cluster @@ -42,7 +42,7 @@ kms_library [TYPE] { } ``` -## `pkcs11` Parameters +## `pkcs11` parameters These parameters apply to the `kms_library` stanza of type `pkcs11` in the Vault configuration file: diff --git a/website/content/docs/configuration/listener/index.mdx b/website/content/docs/configuration/listener/index.mdx index 868ea1d4fc47..caf827ba1780 100644 --- a/website/content/docs/configuration/listener/index.mdx +++ b/website/content/docs/configuration/listener/index.mdx @@ -6,7 +6,7 @@ description: |- respond to requests. --- -# `listener` Stanza +# `listener` stanza The `listener` stanza configures the addresses and ports on which Vault will respond to requests. At this time, there are two listeners: diff --git a/website/content/docs/configuration/listener/tcp.mdx b/website/content/docs/configuration/listener/tcp.mdx index 82ad27409c13..e087d19f2cff 100644 --- a/website/content/docs/configuration/listener/tcp.mdx +++ b/website/content/docs/configuration/listener/tcp.mdx @@ -6,7 +6,7 @@ description: |- port. --- -# `tcp` Listener +# `tcp` listener The TCP listener configures Vault to listen on a TCP address/port. @@ -46,7 +46,7 @@ For example, the `"Content-Security-Policy"` header is defined by default in the the value in the configuration file is set in the response headers instead of the default value in the `"/sys/config/ui"` [API endpoint](/vault/api-docs/system/config-ui). -## `tcp` Listener Parameters +## `tcp` listener parameters - `address` `(string: "127.0.0.1:8200")` – Specifies the address to bind to for listening. This can be dynamically defined with a @@ -194,19 +194,19 @@ default value in the `"/sys/config/ui"` [API endpoint](/vault/api-docs/system/co there is no X-Forwarded-For header or it is empty, the client address will be used as-is, rather than the client connection rejected. -### `telemetry` Parameters +### `telemetry` parameters - `unauthenticated_metrics_access` `(bool: false)` - If set to true, allows unauthenticated access to the `/v1/sys/metrics` endpoint. -### `profiling` Parameters +### `profiling` parameters - `unauthenticated_pprof_access` `(bool: false)` - If set to true, allows unauthenticated access to the `/v1/sys/pprof` endpoint. - `unauthenticated_in_flight_request_access` `(bool: false)` - If set to true, allows unauthenticated access to the `/v1/sys/in-flight-req` endpoint. -### `custom_response_headers` Parameters +### `custom_response_headers` parameters - `default` `(key-value-map: {})` - A map of string header names to an array of string values. The default headers are set on all endpoints regardless of @@ -224,7 +224,7 @@ default value in the `"/sys/config/ui"` [API endpoint](/vault/api-docs/system/co For example, `"2xx" = {"Header-A": ["Value1", "Value2"]}`, `"Header-A"` is set when the http response status code is `"200"`, `"204"`, etc. -## `tcp` Listener Examples +## `tcp` listener examples ### Configuring TLS @@ -237,7 +237,7 @@ listener "tcp" { } ``` -### Listening on Multiple Interfaces +### Listening on multiple interfaces This example shows Vault listening on a private interface, as well as localhost. @@ -332,7 +332,7 @@ listener "tcp" { } ``` -### Listening on all IPv6 & IPv4 Interfaces +### Listening on all IPv6 & IPv4 interfaces This example shows Vault listening on all IPv4 & IPv6 interfaces including localhost. diff --git a/website/content/docs/configuration/listener/unix.mdx b/website/content/docs/configuration/listener/unix.mdx index e338edb268b6..f3c15151da30 100644 --- a/website/content/docs/configuration/listener/unix.mdx +++ b/website/content/docs/configuration/listener/unix.mdx @@ -5,7 +5,7 @@ description: |- The Unix listener configures Vault to listen on the specified Unix domain socket. --- -# `unix` Listener +# `unix` listener The Unix listener configures Vault to listen on the specified Unix domain socket. @@ -18,7 +18,7 @@ listener "unix" { The `listener` stanza may be specified more than once to make Vault listen on multiple sockets. -## `unix` Listener Parameters +## `unix` listener parameters - `address` `(string: "/run/vault.sock", )` – Specifies the address to bind the Unix socket. - `socket_mode` `(string: "", )` – Changes the access @@ -29,9 +29,9 @@ multiple sockets. - `socket_group` `(string: "", )` – Changes the group owner of the Unix socket. -## `unix` Listener Examples +## `unix` listener examples -### Listening on Multiple Sockets +### Listening on multiple sockets This example shows Vault listening on a specified socket, as well as the default. @@ -43,7 +43,7 @@ listener "unix" { } ``` -### Listening on Multiple Interfaces +### Listening on multiple interfaces This example shows Vault listening on TCP localhost, as well as Unix socket. @@ -57,7 +57,7 @@ listener "tcp" { } ``` -### Configuring Permissions +### Configuring permissions This example shows changing access permissions and ownership of the Unix socket. ```hcl listener "unix" { diff --git a/website/content/docs/configuration/log-requests-level.mdx b/website/content/docs/configuration/log-requests-level.mdx index 7cf76fbb6447..856f8bac6e37 100644 --- a/website/content/docs/configuration/log-requests-level.mdx +++ b/website/content/docs/configuration/log-requests-level.mdx @@ -5,11 +5,11 @@ description: |- Vault can be configured to log completed requests. --- -# Log Completed Requests +# Log completed requests Vault can be configured to log completed requests using the `log_requests_level` configuration parameter. -## Activating Logging Completed Requests +## Activating logging completed requests By default, logging completed requests is disabled. To activate request logging, set the `log_requests_level` configuration option in the Vault server configuration to the desired logging level. The acceptable logging levels are @@ -31,7 +31,7 @@ listener "tcp" { } ``` -## Deactivating Logging Completed Requests +## Deactivating logging completed requests To deactivate logging completed requests, simply remove the `log_requests_level` configuration parameter from the Vault server configuration, or set it to `off`, and send a `SIGHUP` signal to the Vault process. diff --git a/website/content/docs/configuration/replication.mdx b/website/content/docs/configuration/replication.mdx index f10d2263461d..a3e917b4b018 100644 --- a/website/content/docs/configuration/replication.mdx +++ b/website/content/docs/configuration/replication.mdx @@ -5,7 +5,7 @@ description: |- The replication stanza specifies various parameters for tuning replication related values. --- -# `replication` Stanza +# `replication` stanza The `replication` stanza specifies various parameters for tuning replication related values. @@ -19,7 +19,7 @@ replication { } ``` -## `replication` Parameters +## `replication` parameters - `resolver_discover_servers` `(boolean: true)` - This feature should probably always be turned on. It enables secondary cluster nodes to reach out to nodes in the primary cluster to request information on who the active node is. This diff --git a/website/content/docs/configuration/seal/alicloudkms.mdx b/website/content/docs/configuration/seal/alicloudkms.mdx index 5220acd37aca..71e38f6faac7 100644 --- a/website/content/docs/configuration/seal/alicloudkms.mdx +++ b/website/content/docs/configuration/seal/alicloudkms.mdx @@ -8,7 +8,7 @@ description: >- mechanism. --- -# `alicloudkms` Seal +# `alicloudkms` seal -> **Note:** The Seal Wrap functionality is enabled by default. For this reason, the KMS service must be available throughout Vault's runtime and not just during the unseal process. Refer to the [Seal Wrap](/vault/docs/enterprise/sealwrap) documenation for more information. @@ -23,7 +23,7 @@ The AliCloud KMS seal is activated by one of the following: other AliCloud-related environment variables that lends to successful authentication. -## `alicloudkms` Example +## `alicloudkms` example This example shows configuring AliCloud KMS seal through the Vault configuration file by providing all the required values: @@ -37,7 +37,7 @@ seal "alicloudkms" { } ``` -## `alicloudkms` Parameters +## `alicloudkms` parameters These parameters apply to the `seal` stanza in the Vault configuration file: @@ -85,7 +85,7 @@ AliCloud authentication values: Note: The client uses the official AliCloud SDK and will use environment credentials, the specified credentials, or RAM role credentials in that order. -## `alicloudkms` Environment Variables +## `alicloudkms` environment variables Alternatively, the AliCloud KMS seal can be activated by providing the following environment variables: diff --git a/website/content/docs/configuration/seal/awskms.mdx b/website/content/docs/configuration/seal/awskms.mdx index 2d9384223e46..18342cece890 100644 --- a/website/content/docs/configuration/seal/awskms.mdx +++ b/website/content/docs/configuration/seal/awskms.mdx @@ -6,7 +6,7 @@ description: |- mechanism. --- -# `awskms` Seal +# `awskms` seal -> **Note:** The Seal Wrap functionality is enabled by default. For this reason, the KMS service must be available throughout Vault's runtime and not just during the unseal process. Refer to the [Seal Wrap](/vault/docs/enterprise/sealwrap) documenation for more information. @@ -20,7 +20,7 @@ The AWS KMS seal is activated by one of the following: other AWS-related environment variables that lends to successful authentication (i.e. `AWS_ACCESS_KEY_ID`, etc.). -## `awskms` Example +## `awskms` example This example shows configuring AWS KMS seal through the Vault configuration file by providing all the required values: @@ -35,7 +35,7 @@ seal "awskms" { } ``` -## `awskms` Parameters +## `awskms` parameters These parameters apply to the `seal` stanza in the Vault configuration file: @@ -98,7 +98,7 @@ Vault needs the following permissions on the KMS key: These can be granted via IAM permissions on the principal that Vault uses, on the KMS key policy for the KMS key, or via KMS Grants on the key. -## `awskms` Environment Variables +## `awskms` environment variables Alternatively, the AWS KMS seal can be activated by providing the following environment variables. @@ -108,7 +108,7 @@ Vault Seal specific values: - `VAULT_SEAL_TYPE` - `VAULT_AWSKMS_SEAL_KEY_ID` -## Key Rotation +## Key rotation This seal supports rotating the root keys defined in AWS KMS [doc](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html). Both automatic @@ -117,7 +117,7 @@ encrypted data. Old keys must not be disabled or deleted and are used to decrypt 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. -## AWS Instance Metadata Timeout +## AWS instance metadata timeout @include 'aws-imds-timeout.mdx' diff --git a/website/content/docs/configuration/seal/azurekeyvault.mdx b/website/content/docs/configuration/seal/azurekeyvault.mdx index 30ce8c849aa5..683445de080d 100644 --- a/website/content/docs/configuration/seal/azurekeyvault.mdx +++ b/website/content/docs/configuration/seal/azurekeyvault.mdx @@ -8,7 +8,7 @@ description: >- mechanism. --- -# `azurekeyvault` Seal +# `azurekeyvault` seal -> **Note:** The Seal Wrap functionality is enabled by default. For this reason, the KMS service must be available throughout Vault's runtime and not just during the unseal process. Refer to the [Seal Wrap](/vault/docs/enterprise/sealwrap) documenation for more information. @@ -22,7 +22,7 @@ wrapping mechanism. The Azure Key Vault seal is activated by one of the followin well as all other Azure-related environment variables that lends to successful authentication (i.e. `AZURE_TENANT_ID`, etc.). -## `azurekeyvault` Example +## `azurekeyvault` example This example shows configuring Azure Key Vault seal through the Vault configuration file by providing all the required values: @@ -37,7 +37,7 @@ seal "azurekeyvault" { } ``` -## `azurekeyvault` Parameters +## `azurekeyvault` parameters These parameters apply to the `seal` stanza in the Vault configuration file: @@ -95,7 +95,7 @@ for more best practices. configuration parameter must be specified; usually this should point to `managedhsm.azure.net`, but could point to other suffixes depending on Azure environment. -## `azurekeyvault` Environment Variables +## `azurekeyvault` environment variables Alternatively, the Azure Key Vault seal can be activated by providing the following environment variables: @@ -103,7 +103,7 @@ environment variables: - `VAULT_AZUREKEYVAULT_VAULT_NAME` - `VAULT_AZUREKEYVAULT_KEY_NAME` -## Key Rotation +## 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 diff --git a/website/content/docs/configuration/seal/gcpckms.mdx b/website/content/docs/configuration/seal/gcpckms.mdx index c6c584b80e4e..daf723ee2d1d 100644 --- a/website/content/docs/configuration/seal/gcpckms.mdx +++ b/website/content/docs/configuration/seal/gcpckms.mdx @@ -8,7 +8,7 @@ description: >- mechanism. --- -# `gcpckms` Seal +# `gcpckms` seal -> **Note:** The Seal Wrap functionality is enabled by default. For this reason, the KMS service must be available throughout Vault's runtime and not just during the unseal process. Refer to the [Seal Wrap](/vault/docs/enterprise/sealwrap) documenation for more information. @@ -22,7 +22,7 @@ wrapping mechanism. The GCP Cloud KMS seal is activated by one of the following: well as all other GCP-related environment variables that lends to successful authentication (i.e. `GOOGLE_PROJECT`, etc.). -## `gcpckms` Example +## `gcpckms` example This example shows configuring GCP Cloud KMS seal through the Vault configuration file by providing all the required values: @@ -37,7 +37,7 @@ seal "gcpckms" { } ``` -## `gcpckms` Parameters +## `gcpckms` parameters These parameters apply to the `seal` stanza in the Vault configuration file: @@ -64,7 +64,7 @@ These parameters apply to the `seal` stanza in the Vault configuration file: Refer to the [Seal Migration](/vault/docs/concepts/seal#seal-migration) documentation for more information about the seal migration process. -## Authentication & Permissions +## Authentication & permissions Authentication-related values must be provided, either as environment variables or as configuration parameters. @@ -97,7 +97,7 @@ cloudkms.cryptoKeys.get `cloudkms.cryptoKeys.get` permission is used for retrieving metadata information of keys from CloudKMS within this engine initialization process. -## `gcpckms` Environment Variables +## `gcpckms` environment variables Alternatively, the GCP Cloud KMS seal can be activated by providing the following environment variables: @@ -106,7 +106,7 @@ environment variables: - `VAULT_GCPCKMS_SEAL_KEY_RING` - `VAULT_GCPCKMS_SEAL_CRYPTO_KEY` -## Key Rotation +## Key rotation This seal supports rotating keys defined in Google Cloud KMS [doc](https://cloud.google.com/kms/docs/rotating-keys). Both scheduled rotation and manual diff --git a/website/content/docs/configuration/seal/index.mdx b/website/content/docs/configuration/seal/index.mdx index 63d09e2e5dc7..a87095a3df7f 100644 --- a/website/content/docs/configuration/seal/index.mdx +++ b/website/content/docs/configuration/seal/index.mdx @@ -6,7 +6,7 @@ description: >- protection. --- -# `seal` Stanza +# `seal` stanza The `seal` stanza configures the seal type to use for additional data protection, such as using HSM or Cloud KMS solutions to encrypt and decrypt the diff --git a/website/content/docs/configuration/seal/ocikms.mdx b/website/content/docs/configuration/seal/ocikms.mdx index c534e555bf6a..7d2e7840e8aa 100644 --- a/website/content/docs/configuration/seal/ocikms.mdx +++ b/website/content/docs/configuration/seal/ocikms.mdx @@ -6,7 +6,7 @@ description: |- mechanism. --- -# `ocikms` Seal +# `ocikms` seal -> **Note:** The Seal Wrap functionality is enabled by default. For this reason, the KMS service must be available throughout Vault's runtime and not just during the unseal process. Refer to the [Seal Wrap](/vault/docs/enterprise/sealwrap) documenation for more information. @@ -20,7 +20,7 @@ The OCI KMS seal is activated by one of the following: other OCI-related [environment variables][oci-sdk] that lends to successful authentication. -## `ocikms` Example +## `ocikms` example This example shows configuring the OCI KMS seal through the Vault configuration file by providing all the required values: @@ -34,7 +34,7 @@ seal "ocikms" { } ``` -## `ocikms` Parameters +## `ocikms` parameters These parameters apply to the `seal` stanza in the Vault configuration file: @@ -106,7 +106,7 @@ admit dynamic-group of tenancy tenantA to use keys in compa ``` -## `ocikms` Rotate OCI KMS Master Key +## `ocikms` rotate OCI KMS master key For the [OCI KMS key rotation feature][oci-kms-rotation], OCI KMS will create a new version of key internally. This process is independent from Vault, and Vault still uses the same `key_id` without any interruption. diff --git a/website/content/docs/configuration/seal/pkcs11.mdx b/website/content/docs/configuration/seal/pkcs11.mdx index bb1949ea64ac..c96c65bc420f 100644 --- a/website/content/docs/configuration/seal/pkcs11.mdx +++ b/website/content/docs/configuration/seal/pkcs11.mdx @@ -6,7 +6,7 @@ description: |- wrapping mechanism. --- -# `pkcs11` Seal +# `pkcs11` seal -> **Note:** The Seal Wrap functionality is enabled by default. For this reason, HSM must be available throughout Vault's runtime and not just during the unseal process. Refer to the [Seal Wrap](/vault/docs/enterprise/sealwrap) documentation for more information. @@ -37,7 +37,7 @@ The following software packages are required for Vault Enterprise HSM: library](https://www.gnu.org/software/libtool/manual/html_node/Using-libltdl.html) — ensure that it is installed for the correct architecture of your servers -## `pkcs11` Example +## `pkcs11` example This example shows configuring HSM PKCS11 seal through the Vault configuration file by providing all the required values: @@ -52,7 +52,7 @@ seal "pkcs11" { } ``` -## `pkcs11` Parameters +## `pkcs11` parameters These parameters apply to the `seal` stanza in the Vault configuration file: @@ -156,7 +156,7 @@ These parameters apply to the `seal` stanza in the Vault configuration file: Refer to the [Seal Migration](/vault/docs/concepts/seal#seal-migration) documentation for more information about the seal migration process. -### Mechanism Specific Flags +### Mechanism specific flags - `rsa_encrypt_local` `(string: "false")`: For HSMs that do not support encryption for RSA keys, perform encryption locally. Available for mechanisms @@ -172,7 +172,7 @@ Refer to the [Seal Migration](/vault/docs/concepts/seal#seal-migration) document `VAULT_HSM_PIN` as part of the seal's parameters, it is _strongly_ recommended to set this value via environment variables. -## `pkcs11` Environment Variables +## `pkcs11` environment variables Alternatively, the HSM seal can be activated by providing the following environment variables: @@ -197,12 +197,12 @@ VAULT_HSM_RSA_OAEP_HASH VAULT_HSM_FORCE_RW_SESSION ``` -## Vault Key Generation Attributes +## Vault key generation attributes If Vault generates the HSM key for you, the following is the list of attributes it uses. These identifiers correspond to official PKCS#11 identifiers. -### AES Key +### AES key - `CKA_CLASS`: `CKO_SECRET_KEY` (It's a secret key) - `CKA_KEY_TYPE`: `CKK_AES` (Key type is AES) @@ -219,7 +219,7 @@ it uses. These identifiers correspond to official PKCS#11 identifiers. - `CKA_UNWRAP`: `true` (Key can be used for unwrapping) - `CKA_EXTRACTABLE`: `false` (Key cannot be exported) -### RSA Key +### RSA key _Public Key_ @@ -246,7 +246,7 @@ _Private Key_ session only) - `CKA_EXTRACTABLE`: `false` (Key cannot be exported) -### HMAC Key +### HMAC key - `CKA_CLASS`: `CKO_SECRET_KEY` (It's a secret key) - `CKA_KEY_TYPE`: `CKK_GENERIC_SECRET_KEY` (Key type is a generic secret key) @@ -261,7 +261,7 @@ _Private Key_ - `CKA_VERIFY`: `true` (Key can be used for verifying) - `CKA_EXTRACTABLE`: `false` (Key cannot be exported) -## Key Rotation +## Key rotation 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 diff --git a/website/content/docs/configuration/seal/transit.mdx b/website/content/docs/configuration/seal/transit.mdx index a72b87ad7cd3..58bdb29a2ce5 100644 --- a/website/content/docs/configuration/seal/transit.mdx +++ b/website/content/docs/configuration/seal/transit.mdx @@ -6,7 +6,7 @@ description: |- autoseal mechanism. --- -# `transit` Seal +# `transit` seal The Transit seal configures Vault to use Vault's Transit Secret Engine as the autoseal mechanism. @@ -15,7 +15,7 @@ The Transit seal is activated by one of the following: - The presence of a `seal "transit"` block in Vault's configuration file - The presence of the environment variable `VAULT_SEAL_TYPE` set to `transit`. -## `transit` Example +## `transit` example This example shows configuring Transit seal through the Vault configuration file by providing all the required values: @@ -40,7 +40,7 @@ seal "transit" { } ``` -## `transit` Parameters +## `transit` parameters These parameters apply to the `seal` stanza in the Vault configuration file: @@ -119,7 +119,7 @@ otherwise when the parent token expires or gets revoked the seal will break. * consider making it a [periodic token](/vault/docs/concepts/tokens#periodic-tokens) and not setting an explicit max TTL, otherwise at some point it will cease to be renewable. -## Key Rotation +## Key rotation This seal supports key rotation using the Transit Secret Engine's key rotation endpoints. See [doc](/vault/api-docs/secret/transit#rotate-key). Old keys must not be disabled or deleted and are diff --git a/website/content/docs/configuration/sentinel.mdx b/website/content/docs/configuration/sentinel.mdx index 5a61f5deddb3..8cbc8e27d8bd 100644 --- a/website/content/docs/configuration/sentinel.mdx +++ b/website/content/docs/configuration/sentinel.mdx @@ -5,7 +5,7 @@ description: |- The sentinel stanza specifies configurations for Vault's Sentinel integration. --- -# `sentinel` Stanza +# `sentinel` stanza The sentinel stanza specifies configurations for [Vault's Sentinel](/vault/docs/enterprise/sentinel) integration. @@ -20,7 +20,7 @@ sentinel { A valid Vault Enterprise license is required for use of Sentinel policies. -## `sentinel` Parameters +## `sentinel` parameters The sentinel stanza currently supports only one parameter, `additional_enabled_modules`. diff --git a/website/content/docs/configuration/service-registration/consul.mdx b/website/content/docs/configuration/service-registration/consul.mdx index 3f2a4f614dc9..ea7db6f59036 100644 --- a/website/content/docs/configuration/service-registration/consul.mdx +++ b/website/content/docs/configuration/service-registration/consul.mdx @@ -8,7 +8,7 @@ description: >- health check. --- -# Consul Service Registration +# Consul service registration Consul Service Registration registers Vault as a service in [Consul][consul] with a default health check. When Consul is configured as the storage backend, the stanza @@ -60,7 +60,7 @@ vault.service.consul Sealed Vault instances will mark themselves as unhealthy to avoid being returned at Consul's service discovery layer. -## `consul` Parameters +## `consul` parameters - `address` `(string: "127.0.0.1:8500")` – Specifies the address of the Consul agent to communicate with. This can be an IP address, DNS record, or unix @@ -139,9 +139,9 @@ that your service name is `vault`: } ``` -## `consul` Examples +## `consul` examples -### Local Agent +### Local agent This example shows a sample configuration which communicates with a local Consul agent running on `127.0.0.1:8500`. @@ -150,7 +150,7 @@ Consul agent running on `127.0.0.1:8500`. service_registration "consul" {} ``` -### Detailed Customization +### Detailed customization This example shows communicating with Consul on a custom address with an ACL token. @@ -162,7 +162,7 @@ service_registration "consul" { } ``` -### Consul via Unix Socket +### Consul via unix socket This example shows communicating with Consul over a local unix socket. diff --git a/website/content/docs/configuration/service-registration/index.mdx b/website/content/docs/configuration/service-registration/index.mdx index 1bd5cf466377..0882fd56d6df 100644 --- a/website/content/docs/configuration/service-registration/index.mdx +++ b/website/content/docs/configuration/service-registration/index.mdx @@ -6,7 +6,7 @@ description: |- service registration. --- -# `service_registration` Stanza +# `service_registration` stanza The optional `service_registration` stanza configures Vault's mechanism for service registration. The `service_registration` stanza is designed for use cases diff --git a/website/content/docs/configuration/service-registration/kubernetes.mdx b/website/content/docs/configuration/service-registration/kubernetes.mdx index 56e489474d52..346af756407a 100644 --- a/website/content/docs/configuration/service-registration/kubernetes.mdx +++ b/website/content/docs/configuration/service-registration/kubernetes.mdx @@ -6,7 +6,7 @@ description: >- for use with selectors. --- -# Kubernetes Service Registration +# Kubernetes service registration Kubernetes Service Registration tags Vault pods with their current status for use with selectors. Service registration is only available when Vault is running in @@ -89,7 +89,7 @@ metadata: vault-version: 1.13.1 ``` -## Label Definitions +## Label definitions - `vault-active` `(string: "true"/"false")` – Vault active is updated dynamically each time Vault's active status changes. True indicates that this Vault pod is currently the leader. False indicates that this Vault pod is currently a standby. @@ -104,9 +104,9 @@ metadata: is currently unsealed. - `vault-version` `(string: "1.13.1")` – Vault version is a string that will not change during a pod's lifecycle. -## Working with Vault's Service Discovery Labels +## Working with vault's service discovery labels -### Example Service +### Example service With labels applied to the pod, services can be created using selectors to filter pods with specific Vault HA roles, effectively allowing direct communication with subsets of Vault pods. Note the `vault-active: "true"` line below. @@ -151,7 +151,7 @@ $ vault write -f sys/replication/performance/primary/enable \ primary_cluster_addr='https://vault-active-us-east:8201' ``` -### Example Upgrades +### Example upgrades In conjunction with the pod labels and the `OnDelete` upgrade strategy, upgrades are much easier to orchestrate: diff --git a/website/content/docs/configuration/storage/aerospike.mdx b/website/content/docs/configuration/storage/aerospike.mdx index bb47140325de..c9bf68cef7d2 100644 --- a/website/content/docs/configuration/storage/aerospike.mdx +++ b/website/content/docs/configuration/storage/aerospike.mdx @@ -6,7 +6,7 @@ description: |- cluster. --- -# Aerospike Storage Backend +# Aerospike storage backend The Aerospike storage backend is used to persist Vault's data in an [Aerospike][aerospike] cluster. @@ -33,7 +33,7 @@ storage "aerospike" { } ``` -## `aerospike` Parameters +## `aerospike` parameters - `hostname` `(string: "127.0.0.1")` – Specifies the Aerospike seed hostname. diff --git a/website/content/docs/configuration/storage/alicloudoss.mdx b/website/content/docs/configuration/storage/alicloudoss.mdx index 565462c98cd4..5ff1197e1445 100644 --- a/website/content/docs/configuration/storage/alicloudoss.mdx +++ b/website/content/docs/configuration/storage/alicloudoss.mdx @@ -6,7 +6,7 @@ description: |- an Alicloud OSS bucket. --- -# Alicloud OSS Storage Backend +# Alicloud OSS storage backend The Alicloud OSS storage backend is used to persist Vault's data in an [Alicloud OSS][alicloudoss] bucket. @@ -28,7 +28,7 @@ storage "alicloudoss" { } ``` -## `alicloudoss` Parameters +## `alicloudoss` parameters - `bucket` `(string: )` – Specifies the name of the OSS bucket. This can also be provided via the environment variable `ALICLOUD_OSS_BUCKET`. @@ -47,9 +47,9 @@ The following settings are used for authenticating to Alicloud. - `max_parallel` `(string: "128")` – Specifies the maximum number of concurrent requests to Alicloud OSS. -## `alicloudoss` Examples +## `alicloudoss` examples -### Default Example +### Default example This example shows using Alicloud OSS as a storage backend. diff --git a/website/content/docs/configuration/storage/azure.mdx b/website/content/docs/configuration/storage/azure.mdx index fbf48bd6b62d..ab0b418496e2 100644 --- a/website/content/docs/configuration/storage/azure.mdx +++ b/website/content/docs/configuration/storage/azure.mdx @@ -7,7 +7,7 @@ description: |- credentials must have read and write permissions to the storage container. --- -# Azure Storage Backend +# Azure storage backend The Azure storage backend is used to persist Vault's data in an [Azure Storage Container][azure-storage]. The storage container must already @@ -36,7 +36,7 @@ storage "azure" { The current implementation is limited to a maximum of 4 megabytes per blob. -## `azure` Parameters +## `azure` parameters - `accountName` `(string: )` – Specifies the Azure Storage account name. @@ -58,7 +58,7 @@ The current implementation is limited to a maximum of 4 megabytes per blob. - `max_parallel` `(string: "128")` – Specifies The maximum number of concurrent requests to Azure. -## `azure` Examples +## `azure` examples This example shows configuring the Azure storage backend with a custom number of maximum parallel connections. diff --git a/website/content/docs/configuration/storage/cassandra.mdx b/website/content/docs/configuration/storage/cassandra.mdx index 421d17af22ea..6d89ce236bc8 100644 --- a/website/content/docs/configuration/storage/cassandra.mdx +++ b/website/content/docs/configuration/storage/cassandra.mdx @@ -6,7 +6,7 @@ description: |- Cassandra cluster. --- -# Cassandra Storage Backend +# Cassandra storage backend The Cassandra storage backend is used to persist Vault's data in an [Apache Cassandra][cassandra] cluster. @@ -46,7 +46,7 @@ CREATE TABLE "vault"."entries" ( ) WITH CLUSTERING ORDER BY (key ASC); ``` -## `cassandra` Parameters +## `cassandra` parameters - `hosts` `(string: "127.0.0.1")` – Comma-separated list of Cassandra hosts to connect to. diff --git a/website/content/docs/configuration/storage/cockroachdb.mdx b/website/content/docs/configuration/storage/cockroachdb.mdx index eec616cd570d..16f2b6766d36 100644 --- a/website/content/docs/configuration/storage/cockroachdb.mdx +++ b/website/content/docs/configuration/storage/cockroachdb.mdx @@ -6,7 +6,7 @@ description: >- CockroachDB server or cluster. --- -# CockroachDB Storage Backend +# CockroachDB storage backend The CockroachDB storage backend is used to persist Vault's data in a [CockroachDB][cockroachdb] server or cluster. @@ -26,7 +26,7 @@ storage "cockroachdb" { **Note** - CockroachDB is compatible with the PostgreSQL database driver and uses that driver to interact with the database. -## `cockroachdb` Parameters +## `cockroachdb` parameters - `connection_url` `(string: )` – Specifies the connection string to use to authenticate and connect to CockroachDB. A full list of supported @@ -44,7 +44,7 @@ uses that driver to interact with the database. - `ha_table` `(string: "vault_ha_locks")` - Specifies the name of the table to use for storing high availability information. -## `cockroachdb` Examples +## `cockroachdb` examples This example shows connecting to a CockroachDB cluster using full SSL verification (recommended) and high availability enabled. diff --git a/website/content/docs/configuration/storage/consul.mdx b/website/content/docs/configuration/storage/consul.mdx index 00d3607087c9..073f73633e30 100644 --- a/website/content/docs/configuration/storage/consul.mdx +++ b/website/content/docs/configuration/storage/consul.mdx @@ -8,7 +8,7 @@ description: |- check. --- -# Consul Storage Backend +# Consul storage backend The Consul storage backend is used to persist Vault's data in [Consul's][consul] key-value store. In addition to providing durable storage, inclusion of this @@ -55,7 +55,7 @@ Note that if you have configured multiple listeners for Vault, you must specify which one Consul should advertise to the cluster using [`api_addr`][api-addr] and [`cluster_addr`][cluster-addr] ([example][listener-example]). -## `consul` Parameters +## `consul` parameters - `address` `(string: "127.0.0.1:8500")` – Specifies the address of the Consul agent to communicate with. This can be an IP address, DNS record, or unix @@ -200,9 +200,9 @@ language: } ``` -## `consul` Examples +## `consul` examples -### Local Agent +### Local agent This example shows a sample physical backend configuration which communicates with a local Consul agent running on `127.0.0.1:8500`. @@ -211,7 +211,7 @@ with a local Consul agent running on `127.0.0.1:8500`. storage "consul" {} ``` -### Detailed Customization +### Detailed customization This example shows communicating with Consul on a custom address with an ACL token. @@ -223,7 +223,7 @@ storage "consul" { } ``` -### Custom Storage Path +### Custom storage path This example shows storing data at a custom path in Consul's key-value store. This path must be readable and writable by the Consul ACL token, if Consul @@ -235,7 +235,7 @@ storage "consul" { } ``` -### Consul via Unix Socket +### Consul via unix socket This example shows communicating with Consul over a local unix socket. diff --git a/website/content/docs/configuration/storage/couchdb.mdx b/website/content/docs/configuration/storage/couchdb.mdx index c5a7ae86c3cd..f4a5540f71d8 100644 --- a/website/content/docs/configuration/storage/couchdb.mdx +++ b/website/content/docs/configuration/storage/couchdb.mdx @@ -6,7 +6,7 @@ description: |- database. --- -# CouchDB Storage Backend +# CouchDB storage backend The CouchDB storage backend is used to persist Vault's data in [CouchDB][couchdb] table. @@ -27,7 +27,7 @@ storage "couchdb" { } ``` -## `couchdb` Parameters +## `couchdb` parameters - `endpoint` `(string: "")` – Specifies your CouchDB endpoint. This can also be provided via the environment variable `COUCHDB_ENDPOINT`. diff --git a/website/content/docs/configuration/storage/dynamodb.mdx b/website/content/docs/configuration/storage/dynamodb.mdx index 6c01617f7898..ba5d7eabf70c 100644 --- a/website/content/docs/configuration/storage/dynamodb.mdx +++ b/website/content/docs/configuration/storage/dynamodb.mdx @@ -6,7 +6,7 @@ description: |- table. --- -# DynamoDB Storage Backend +# DynamoDB storage backend The DynamoDB storage backend is used to persist Vault's data in [DynamoDB][dynamodb] table. @@ -32,7 +32,7 @@ storage "dynamodb" { For more information about the read/write capacity of DynamoDB tables, please see the [official AWS DynamoDB documentation][dynamodb-rw-capacity]. -## DynamoDB Parameters +## DynamoDB parameters - `endpoint` `(string: "")` – Specifies an alternative, AWS compatible, DynamoDB endpoint. This can also be provided via the environment variable @@ -79,7 +79,7 @@ cause Vault to attempt to retrieve credentials from the AWS metadata service. - `session_token` `(string: "")` – Specifies the AWS session token. This can also be provided via the environment variable `AWS_SESSION_TOKEN`. -## Required AWS Permissions +## Required AWS permissions The governing policy for the IAM user or EC2 instance profile that Vault uses to access DynamoDB must contain the following permissions for Vault to perform @@ -112,7 +112,7 @@ the required operations on the DynamoDB table: }, ``` -## Table Schema +## Table schema If you are going to create the DynamoDB table prior to the execution and initialization of Vault, you will need to create a table with these attributes: @@ -155,13 +155,13 @@ If the table does not already exist, Vault will try to create it, with read and write capacities set to the values of `read_capacity` and `write_capacity` respectively. -## AWS Instance Metadata Timeout +## AWS instance metadata timeout @include 'aws-imds-timeout.mdx' -## DynamoDB Examples of Vault Configuration +## DynamoDB examples of Vault configuration -### Custom Table and Read-Write Capacity +### Custom table and Read-Write capacity This example shows using a custom table name and read/write capacity. @@ -174,7 +174,7 @@ storage "dynamodb" { } ``` -### Enabling High Availability +### Enabling high availability This example shows enabling high availability for the DynamoDB storage backend. diff --git a/website/content/docs/configuration/storage/etcd.mdx b/website/content/docs/configuration/storage/etcd.mdx index d7a5fe553257..8c69eb2fb7ec 100644 --- a/website/content/docs/configuration/storage/etcd.mdx +++ b/website/content/docs/configuration/storage/etcd.mdx @@ -7,7 +7,7 @@ description: |- on the version of the Etcd cluster. --- -# Etcd Storage Backend +# Etcd storage backend The Etcd storage backend is used to persist Vault's data in [Etcd][etcd]. It supports both the v2 and v3 Etcd APIs, and the version is automatically detected @@ -37,7 +37,7 @@ storage "etcd" { } ``` -## `etcd` Parameters +## `etcd` parameters - `address` `(string: "http://localhost:2379")` – Specifies the addresses of the Etcd instances as a comma-separated list. This can also be provided via the @@ -92,9 +92,9 @@ storage "etcd" { - `lock_timeout` `(string: "15s")` – Specifies lock timeout for master Vault instance. Set bigger value if you don't need faster recovery. -## `etcd` Examples +## `etcd` examples -### DNS Discovery of cluster members +### DNS discovery of cluster members This example configures vault to discover the Etcd cluster members via SRV records as outlined in the @@ -106,7 +106,7 @@ storage "etcd" { } ``` -### Custom Authentication +### Custom authentication This example shows connecting to the Etcd cluster using a username and password. @@ -117,7 +117,7 @@ storage "etcd" { } ``` -### Custom Path +### Custom path This example shows storing data in a custom path. @@ -127,7 +127,7 @@ storage "etcd" { } ``` -### Enabling High Availability +### Enabling high availability This example shows enabling high availability for the Etcd storage backend. diff --git a/website/content/docs/configuration/storage/filesystem.mdx b/website/content/docs/configuration/storage/filesystem.mdx index d0b04225d393..8c4c2498f070 100644 --- a/website/content/docs/configuration/storage/filesystem.mdx +++ b/website/content/docs/configuration/storage/filesystem.mdx @@ -7,7 +7,7 @@ description: |- situations, or to develop locally where durability is not critical. --- -# Filesystem Storage Backend +# Filesystem storage backend The Filesystem storage backend stores Vault's data on the filesystem using a standard directory structure. It can be used for durable single server @@ -28,13 +28,13 @@ storage "file" { Even though Vault's data is encrypted at rest, you should still take appropriate measures to secure access to the filesystem. -## `file` Parameters +## `file` parameters - `path` `(string: )` – The absolute path on disk to the directory where the data will be stored. If the directory does not exist, Vault will create it. -## `file` Examples +## `file` examples This example shows the Filesystem storage backend being mounted at `/mnt/vault/data`. diff --git a/website/content/docs/configuration/storage/foundationdb.mdx b/website/content/docs/configuration/storage/foundationdb.mdx index b9537bb9fb0c..2eeacb6b8c7d 100644 --- a/website/content/docs/configuration/storage/foundationdb.mdx +++ b/website/content/docs/configuration/storage/foundationdb.mdx @@ -6,7 +6,7 @@ description: |- FoundationDB KV store. --- -# FoundationDB Storage Backend +# FoundationDB storage backend The FoundationDB storage backend is used to persist Vault's data in [FoundationDB][foundationdb]. @@ -41,7 +41,7 @@ storage "foundationdb" { } ``` -## `foundationdb` Parameters +## `foundationdb` parameters - `api_version` `(int)` - The FoundationDB API version to use; this is a required parameter and doesn't have a default value. The minimum required API diff --git a/website/content/docs/configuration/storage/google-cloud-spanner.mdx b/website/content/docs/configuration/storage/google-cloud-spanner.mdx index 7b2a9d826edc..e5511fb07209 100644 --- a/website/content/docs/configuration/storage/google-cloud-spanner.mdx +++ b/website/content/docs/configuration/storage/google-cloud-spanner.mdx @@ -7,7 +7,7 @@ description: |- offers transactional consistency at global scale. --- -# Google Cloud Spanner Storage Backend +# Google Cloud spanner storage backend The Google Cloud Spanner storage backend is used to persist Vault's data in [Spanner][spanner-docs], a fully managed, mission-critical, relational database @@ -33,7 +33,7 @@ storage "spanner" { For more information on schemas or Google Cloud Spanner, please see the [Google Cloud Spanner documentation][spanner-docs]. -## `spanner` Setup +## `spanner` setup To use the Google Cloud Spanner Vault storage backend, you must have a Google Cloud Platform account. Either using the API or web interface, create a database @@ -62,7 +62,7 @@ automatically at this time, but this could be a future enhancement. For more information on schemas or Google Cloud Spanner, please see the [Google Cloud Spanner documentation][spanner-docs]. -## `spanner` Authentication +## `spanner` authentication The Google Cloud Spanner Vault storage backend uses the official Google Cloud Golang SDK. This means it supports the common ways of [providing credentials to @@ -86,7 +86,7 @@ minimum scope(s): https://www.googleapis.com/auth/google-cloud-spanner.data ``` -## `spanner` Parameters +## `spanner` parameters - `database` `(string: )` – Specifies the name of the database. Note that this is specified as a "path" including the project ID and instance, for @@ -102,7 +102,7 @@ https://www.googleapis.com/auth/google-cloud-spanner.data - `max_parallel` `(int: 128)` - Specifies the maximum number of parallel operations to take place. -### High Availability Parameters +### High availability parameters - `ha_enabled` `(string: "false")` - Specifies if high availability mode is enabled. This is a boolean value, but it is specified as a string like "true" @@ -112,9 +112,9 @@ https://www.googleapis.com/auth/google-cloud-spanner.data storing high availability information. By default, this is the name of the `table` suffixed with "HA". -## `spanner` Examples +## `spanner` examples -### High Availability +### High availability This example shows configuring Google Cloud Spanner with high availability enabled. @@ -128,7 +128,7 @@ storage "spanner" { } ``` -### Custom Tables +### Custom tables This example shows listing custom table names for data and HA with the Google Cloud Spanner Vault storage backend. diff --git a/website/content/docs/configuration/storage/google-cloud-storage.mdx b/website/content/docs/configuration/storage/google-cloud-storage.mdx index 2317d1de12f0..eddbf93f661d 100644 --- a/website/content/docs/configuration/storage/google-cloud-storage.mdx +++ b/website/content/docs/configuration/storage/google-cloud-storage.mdx @@ -6,7 +6,7 @@ description: |- Google Cloud Storage. --- -# Google Cloud Storage Storage Backend +# Google Cloud storage storage backend The Google Cloud Storage storage backend is used to persist Vault's data in [Google Cloud Storage][gcs-docs]. @@ -30,7 +30,7 @@ storage "gcs" { For more information on schemas or Google Cloud Storage, please see the [Google Cloud Storage documentation][gcs-docs]. -## `gcs` Setup +## `gcs` setup To use the Google Cloud Storage Vault storage backend, you must have a Google Cloud Platform account with permissions to create Google Cloud Storage buckets. @@ -69,7 +69,7 @@ Then give Vault the service account's credential file as a configuration option. For more information on schemas or Google Cloud Storage, please see the [Google Cloud Storage documentation][gcs-docs]. -## `gcs` Authentication +## `gcs` authentication The Google Cloud Storage Vault storage backend uses the official Google Cloud Golang SDK. This means it supports the common ways of [providing credentials to @@ -93,7 +93,7 @@ minimum scope(s): https://www.googleapis.com/auth/devstorage.read_write ``` -## `gcs` Parameters +## `gcs` parameters - `bucket` `(string: )` – Specifies the name of the bucket to use for storage. Alternatively, this parameter can be omitted and the `GOOGLE_STORAGE_BUCKET` @@ -113,7 +113,7 @@ https://www.googleapis.com/auth/devstorage.read_write - `max_parallel` `(int: 128)` - Specifies the maximum number of parallel operations to take place. -### High Availability Parameters +### High availability parameters - `ha_enabled` `(string: "false")` - Specifies if high availability mode is enabled. This is a boolean value, but it is specified as a string like "true" @@ -123,9 +123,9 @@ https://www.googleapis.com/auth/devstorage.read_write the parameter in the stanza are set, the value of the environment variable will take precedence. -## `gcs` Examples +## `gcs` examples -### High Availability +### High availability This example shows configuring Google Cloud Storage with high availability enabled. @@ -139,7 +139,7 @@ storage "gcs" { } ``` -### Custom Chunk Size +### Custom chunk size This example shows setting a custom chunk size for uploads. When uploading large data to Vault, setting a lower number can reduce Vault's memory consumption, but diff --git a/website/content/docs/configuration/storage/in-memory.mdx b/website/content/docs/configuration/storage/in-memory.mdx index 8fc9f24ab088..0f8f1f6f1d8f 100644 --- a/website/content/docs/configuration/storage/in-memory.mdx +++ b/website/content/docs/configuration/storage/in-memory.mdx @@ -8,7 +8,7 @@ description: |- in production except in very specific use-cases. --- -# In-Memory Storage Backend +# In-Memory storage backend The In-Memory storage backend is used to persist Vault's data entirely in-memory on the same machine in which Vault is running. This is useful for development @@ -29,11 +29,11 @@ is restarted. storage "inmem" {} ``` -## `inmem` Parameters +## `inmem` parameters The In-Memory storage backend has no configuration parameters. -## `inmem` Examples +## `inmem` examples This example shows activating the In-Memory storage backend. diff --git a/website/content/docs/configuration/storage/index.mdx b/website/content/docs/configuration/storage/index.mdx index fbb00a5b293c..6d43c306285f 100644 --- a/website/content/docs/configuration/storage/index.mdx +++ b/website/content/docs/configuration/storage/index.mdx @@ -9,7 +9,7 @@ description: |- process. --- -# `storage` Stanza +# `storage` stanza The `storage` stanza configures the storage backend, which represents the location for the durable storage of Vault's information. Each backend has pros, @@ -41,7 +41,7 @@ For configuration options which also read an environment variable, the environment variable will take precedence over values in the configuration file. -## Integrated Storage vs. External Storage +## Integrated storage vs. external storage HashiCorp recommends using Vault's [integrated storage](/vault/docs/configuration/storage/raft) for most use cases rather than @@ -63,7 +63,7 @@ Storage. Suppose you decide that the additional operational complexity of extern | Data location | The encrypted Vault data is stored on the same host where the Vault server process runs. | The encrypted Vault data is stored where the external storage is located. Therefore, the Vault server and the data storage are hosted on physically separate hosts. | | System requirements | Avoid "burstable" CPU and storage options. SSDs should be used for the hard drive.

See the [Reference Architecture](/vault/tutorials/day-one-raft/raft-reference-architecture#system-requirements) guide. | Follow the system requirements given by your chosen storage backend. | -### Integrated Storage vs. Consul as Vault Storage +### Integrated storage vs. consul as Vault storage [HashiCorp Consul](/consul/docs/intro) is a comprehensive multi-cloud service networking solution including service mesh, service diff --git a/website/content/docs/configuration/storage/manta.mdx b/website/content/docs/configuration/storage/manta.mdx index 451d7f259cfe..c208e5618617 100644 --- a/website/content/docs/configuration/storage/manta.mdx +++ b/website/content/docs/configuration/storage/manta.mdx @@ -8,7 +8,7 @@ description: >- Storage. The storage folder must already exist. --- -# Manta Storage Backend +# Manta storage backend The Manta storage backend is used to persist Vault's data in [Triton's Manta Object Storage][manta-object-store]. The storage folder must already exist. @@ -29,7 +29,7 @@ storage "manta" { } ``` -## `manta` Parameters +## `manta` parameters - `directory` `(string: )` – Specifies the name of the manta directory to use. This will be in the `/stor/` folder in the specific manta account @@ -51,7 +51,7 @@ The following settings are used for authenticating to Manta. - `max_parallel` `(string: "128")` – Specifies The maximum number of concurrent requests to Manta. -## `manta` Examples +## `manta` examples This example shows configuring the Azure storage backend with a custom number of maximum parallel connections. diff --git a/website/content/docs/configuration/storage/mssql.mdx b/website/content/docs/configuration/storage/mssql.mdx index e5f1ccca1d52..db5f5b5eeaf4 100644 --- a/website/content/docs/configuration/storage/mssql.mdx +++ b/website/content/docs/configuration/storage/mssql.mdx @@ -6,7 +6,7 @@ description: >- Server. --- -# MSSQL Storage Backend +# MSSQL storage backend The MSSQL storage backend is used to persist Vault's data in a Microsoft SQL Server. @@ -33,7 +33,7 @@ storage "mssql" { } ``` -## `mssql` Parameters +## `mssql` parameters - `server` `(string: )` – host or host\instance. @@ -64,9 +64,9 @@ storage "mssql" { - `max_parallel` `(string: "128")` – Specifies the maximum number of concurrent requests to MSSQL. -## `mssql` Examples +## `mssql` examples -### Custom Database, Table and Schema +### Custom database, table and schema This example shows configuring the MSSQL backend to use a custom database and table name. diff --git a/website/content/docs/configuration/storage/mysql.mdx b/website/content/docs/configuration/storage/mysql.mdx index 08b5c07b3b9f..70b97f7a5ff7 100644 --- a/website/content/docs/configuration/storage/mysql.mdx +++ b/website/content/docs/configuration/storage/mysql.mdx @@ -6,7 +6,7 @@ description: |- cluster. --- -# MySQL Storage Backend +# MySQL storage backend The MySQL storage backend is used to persist Vault's data in a [MySQL][mysql] server or cluster. @@ -30,7 +30,7 @@ storage "mysql" { } ``` -## `mysql` Parameters +## `mysql` parameters - `address` `(string: "127.0.0.1:3306")` – Specifies the address of the MySQL host. @@ -70,7 +70,7 @@ Additionally, Vault requires the following authentication information. - `password` `(string: )` – Specifies the MySQL password to connect to the database. -### High Availability Parameters +### High availability parameters - `ha_enabled` `(string: "false")` - Specifies if high availability mode is enabled. This is a boolean value, but it is specified as a string like "true" @@ -81,9 +81,9 @@ Additionally, Vault requires the following authentication information. of the `table` suffixed with `_lock`. If the table does not exist, Vault will attempt to create it. -## `mysql` Examples +## `mysql` examples -### Custom Database and Table +### Custom database and table This example shows configuring the MySQL backend to use a custom database and table name. diff --git a/website/content/docs/configuration/storage/oci-object-storage.mdx b/website/content/docs/configuration/storage/oci-object-storage.mdx index 403a260b8a5e..2cdcdaf55e16 100644 --- a/website/content/docs/configuration/storage/oci-object-storage.mdx +++ b/website/content/docs/configuration/storage/oci-object-storage.mdx @@ -6,7 +6,7 @@ description: >- Storage. --- -# OCI Object Storage Storage Backend +# OCI object storage storage backend The OCI Object Storage backend is used to persist Vault's data in OCI Object Storage. @@ -27,19 +27,19 @@ storage "oci" { For more information on OCI Object Storage, please see the Oracle's [OCI Object Storage documentation][ocios-docs]. -## `oci` Setup +## `oci` setup To use the OCI Object Storage Vault storage backend, you must have a OCI account. Either using the API or web interface, create the data bucket and lock bucket if enabling high availability. The OCI Object Storage backend does not support creating the buckets automatically at this time. -## `oci` Authentication +## `oci` authentication The OCI Object Storage Vault storage backend uses the official OCI Golang SDK. This means it supports the common ways of providing credentials to OCI. For more information on service accounts, please see the [OCI Identity documentation][oci-identity]. -## `oci` Parameters +## `oci` parameters - `region` `(string: )` - Specifies the OCI region where Vault should look for object storage buckets. If not specified the OCI Storage Backend will use the region specified in your OCI credentials configuration. @@ -47,7 +47,7 @@ For more information on service accounts, please see the [OCI Identity documenta - `bucket_name` `(string: )` - Specifies the name of the bucket that will be used to store the Vault data. -### High Availability Parameters +### High availability parameters - `ha_enabled` `(string: "")` - Specifies if high availability mode is enabled. This is a boolean value, but it is specified as a string like "true" @@ -55,7 +55,7 @@ For more information on service accounts, please see the [OCI Identity documenta - `lock_bucket_name` `(string: "")` - Specifies the name of the bucket that will be used to store the node lease data. -## `oci` Examples +## `oci` examples ### Standalone Vault instance @@ -68,7 +68,7 @@ storage "oci" { } ``` -### High Availability +### High availability This example shows configuring OCI Object Storage with high availability enabled. diff --git a/website/content/docs/configuration/storage/postgresql.mdx b/website/content/docs/configuration/storage/postgresql.mdx index d970b74dbdc8..85a8399bf413 100644 --- a/website/content/docs/configuration/storage/postgresql.mdx +++ b/website/content/docs/configuration/storage/postgresql.mdx @@ -6,7 +6,7 @@ description: |- server or cluster. --- -# PostgreSQL Storage Backend +# PostgreSQL storage backend The PostgreSQL storage backend is used to persist Vault's data in a [PostgreSQL][postgresql] server or cluster. @@ -87,7 +87,7 @@ $$ LANGUAGE plpgsql; ``` -## `postgresql` Parameters +## `postgresql` parameters - `connection_url` `(string: )` – Specifies the connection string to use to authenticate and connect to PostgreSQL. The connection URL can also be @@ -113,9 +113,9 @@ LANGUAGE plpgsql; for storing high availability information. This table must already exist (Vault will not attempt to create it). -## `postgresql` Examples +## `postgresql` examples -### Custom SSL Verification +### Custom SSL verification This example shows connecting to a PostgreSQL cluster using full SSL verification (recommended). diff --git a/website/content/docs/configuration/storage/raft.mdx b/website/content/docs/configuration/storage/raft.mdx index cc399f6ebdc6..61e2c95d2a3e 100644 --- a/website/content/docs/configuration/storage/raft.mdx +++ b/website/content/docs/configuration/storage/raft.mdx @@ -10,7 +10,7 @@ description: |- Consensus Algorithm. --- -# Integrated Storage (Raft) Backend +# Integrated storage (Raft) backend The Integrated Storage backend is used to persist Vault's data. Unlike other storage backends, Integrated Storage does not operate from a single source of data. Instead @@ -42,7 +42,7 @@ backend cannot be declared. ~> **Note:** When using the Integrated Storage backend, it is strongly recommended to set [`disable_mlock`](/vault/docs/configuration#disable_mlock) to `true`, and to disable memory swapping on the system. -## `raft` Parameters +## `raft` parameters - `path` `(string: "")` – The file system path where all the Vault data gets stored. diff --git a/website/content/docs/configuration/storage/s3.mdx b/website/content/docs/configuration/storage/s3.mdx index 2c684ef9501e..14526bc051c5 100644 --- a/website/content/docs/configuration/storage/s3.mdx +++ b/website/content/docs/configuration/storage/s3.mdx @@ -6,7 +6,7 @@ description: |- bucket. --- -# S3 Storage Backend +# S3 storage backend The S3 storage backend is used to persist Vault's data in an [Amazon S3][s3] bucket. @@ -27,7 +27,7 @@ storage "s3" { } ``` -## `s3` Parameters +## `s3` parameters - `bucket` `(string: )` – Specifies the name of the S3 bucket. This can also be provided via the environment variable `AWS_S3_BUCKET`. @@ -74,9 +74,9 @@ cause Vault to attempt to retrieve credentials from the AWS metadata service. - `path` `(string: "")` - Specifies the path in the S3 Bucket where Vault data will be stored. -## `s3` Examples +## `s3` examples -### Default Example +### Default example This example shows using Amazon S3 as a storage backend. @@ -88,7 +88,7 @@ storage "s3" { } ``` -### S3 KMS Encryption with Default Key +### S3 KMS encryption with default key This example shows using Amazon S3 as a storage backend using KMS encryption with the default S3 KMS key for the account. @@ -102,7 +102,7 @@ storage "s3" { } ``` -### S3 KMS Encryption with Custom Key +### S3 KMS encryption with custom key This example shows using Amazon S3 as a storage backend using KMS encryption with a customer managed KMS key. @@ -118,6 +118,6 @@ storage "s3" { [s3]: https://aws.amazon.com/s3/ -## AWS Instance Metadata Timeouts +## AWS instance metadata timeouts @include 'aws-imds-timeout.mdx' diff --git a/website/content/docs/configuration/storage/swift.mdx b/website/content/docs/configuration/storage/swift.mdx index 65b9065ee536..6f16e8ad4a05 100644 --- a/website/content/docs/configuration/storage/swift.mdx +++ b/website/content/docs/configuration/storage/swift.mdx @@ -6,7 +6,7 @@ description: |- Swift Container. --- -# Swift Storage Backend +# Swift storage backend The Swift storage backend is used to persist Vault's data in an [OpenStack Swift Container][swift]. @@ -28,7 +28,7 @@ storage "swift" { } ``` -## `swift` Parameters +## `swift` parameters - `auth_url` `(string: )` – Specifies the OpenStack authentication endpoint. This can also be provided via the environment variable `OS_AUTH_URL`. @@ -63,9 +63,9 @@ storage "swift" { - `auth_token` `(string: "")` - Specifies auth token from alternate authentication. This can also be provided via the environment variable `OS_AUTH_TOKEN`. -## `swift` Examples +## `swift` examples -### Default Example +### Default example This example shows a default configuration for Swift. diff --git a/website/content/docs/configuration/storage/zookeeper.mdx b/website/content/docs/configuration/storage/zookeeper.mdx index d362f0a45fda..e2120e6a19e9 100644 --- a/website/content/docs/configuration/storage/zookeeper.mdx +++ b/website/content/docs/configuration/storage/zookeeper.mdx @@ -4,7 +4,7 @@ page_title: Zookeeper - Storage Backends - Configuration description: The Zookeeper storage backend is used to persist Vault's data in Zookeeper. --- -# Zookeeper Storage Backend +# Zookeeper storage backend The Zookeeper storage backend is used to persist Vault's data in [Zookeeper][zk]. @@ -24,7 +24,7 @@ storage "zookeeper" { } ``` -## `zookeeper` Parameters +## `zookeeper` parameters - `address` `(string: "localhost:2181")` – Specifies the addresses of the Zookeeper instances as a comma-separated list. @@ -87,9 +87,9 @@ znodes and, potentially, take Vault out of service. zookeeper server's IP is verified in the presented certificates CN/SAN entry. When set to 'false' the server's DNS name is verified in the certificates CN/SAN entry. -## `zookeeper` Examples +## `zookeeper` examples -### Custom Address and Path +### Custom address and path This example shows configuring Vault to communicate with a Zookeeper installation running on a custom port and to store data at a custom path. @@ -101,7 +101,7 @@ storage "zookeeper" { } ``` -### zNode Vault User Only +### zNode Vault user only This example instructs Vault to set an ACL on all of its zNodes which permit access only to the user "vaultUser". As per Zookeeper's ACL model, the digest @@ -114,7 +114,7 @@ storage "zookeeper" { } ``` -### zNode Localhost Only +### zNode localhost only This example instructs Vault to only allow access from localhost. As this is the `ip` no `auth_info` is required since Zookeeper uses the address of the client diff --git a/website/content/docs/configuration/telemetry.mdx b/website/content/docs/configuration/telemetry.mdx index 9aa2eb1b976f..93d0ca2eee4b 100644 --- a/website/content/docs/configuration/telemetry.mdx +++ b/website/content/docs/configuration/telemetry.mdx @@ -6,7 +6,7 @@ description: |- metrics to upstream systems. --- -# `telemetry` Stanza +# `telemetry` stanza The `telemetry` stanza specifies various configurations for Vault to publish metrics to upstream systems. Available Vault metrics can be found in the @@ -18,7 +18,7 @@ telemetry { } ``` -## `telemetry` Parameters +## `telemetry` parameters Due to the number of configurable parameters to the `telemetry` stanza, parameters on this page are grouped by the telemetry provider. diff --git a/website/content/docs/configuration/user-lockout.mdx b/website/content/docs/configuration/user-lockout.mdx index 1306c9aea44c..f3c81c80522f 100644 --- a/website/content/docs/configuration/user-lockout.mdx +++ b/website/content/docs/configuration/user-lockout.mdx @@ -5,11 +5,11 @@ description: |- The user_lockout stanza specifies various configurations for user lockout behaviour for failed logins in vault. --- -# User Lockout +# User lockout @include 'user-lockout.mdx' -## `user_lockout` Stanza +## `user_lockout` stanza The `user_lockout` stanza specifies various configurations for user lockout behaviour for failed logins in vault. They can be configured for all supported auth methods @@ -57,7 +57,7 @@ lockout duration of 5 minutes, lockout counter reset of 10 minutes. Approle auth The user lockout configuration for the auth method at a given path can be tuned using auth tune. Please see [auth tune command](/vault/docs/commands/auth/tune) or [auth tune api](/vault/api-docs/system/auth#tune-auth-method) for more details. -## `user_lockout` Parameters +## `user_lockout` parameters The following options are available on all user_lockout configurations. diff --git a/website/content/docs/deprecation/faq.mdx b/website/content/docs/deprecation/faq.mdx index c953ef5a576a..9b6afb48d6e6 100644 --- a/website/content/docs/deprecation/faq.mdx +++ b/website/content/docs/deprecation/faq.mdx @@ -6,7 +6,7 @@ description: |- An FAQ page to communicate frequently asked questions concerning feature deprecations. --- -# Feature Deprecation FAQ +# Feature deprecation FAQ This page provides frequently asked questions concerning decisions made about Vault feature deprecations. If you are looking for information about Vault licensing, refer to the [Licensing FAQ](/vault/docs/enterprise/license/faq) page. Pleaser refer to the [Feature Deprecation Notice and Plans](/vault/docs/deprecation) document for up-to-date information on Vault feature deprecations and notice. @@ -16,19 +16,19 @@ This page provides frequently asked questions concerning decisions made about Va - [Q: What is the impact of removing support for X.509 certificates with signatures that use SHA-1?](#q-what-is-the-impact-of-removing-support-for-x-509-certificates-with-signatures-that-use-sha-1) - [Q: What are the phases of deprecation?](#q-what-are-the-phases-of-deprecation) -### Q: What is the impact on anyone using the legacy MFA feature? +### Q: what is the impact on anyone using the legacy MFA feature? If you are an Enterprise Vault user, there is no impact. There are no changes to the Enterprise MFA offering. If you are an OSS user and use the legacy MFA, this will impact you since we plan to deprecate the legacy MFA feature. However, while we will continue to provide support for MFA in Vault OSS in the upcoming Vault 1.10 release, our target is to remove the legacy MFA feature from the product in the following Vault 1.11 release. Therefore, you should plan to migrate to the new MFA feature when Vault OSS supports it. -### Q: I'm currently using the Etcd storage backend feature. How does the deprecation impact me? +### Q: i'm currently using the etcd storage backend feature. how does the deprecation impact me? The Etcd v2 has been deprecated with the release of Etcd v3.5 and will be decommissioned by Etcd v3.6. Etcd v2 API will be removed in Vault 1.10. The Etcd storage backend users should migrate Vault storage to an Etcd V3 cluster before upgrading to Vault 1.10. We recommend that you back up all storage migrations before upgrading. If you are an Enterprise user, we recommend that you consider migrating to HashiCorp supported storage backends: **Integrated Storage** or **Consul** (if your use case requires you to use this). Your HashiCorp sales or support representative can assist you with this decision. -### Q: What should I do if I use Mount Filters, AppID, or any of the standalone DB engines? +### Q: what should i do if i use mount filters, AppID, or any of the standalone DB engines? These features were deprecated in prior releases of Vault. We are targeting the removal of these features from the product in the Vault 1.12 release. Please plan to upgrade to these features before the release of Vault 1.12. Refer to the table below for a list of alternative features. @@ -40,7 +40,7 @@ These features were deprecated in prior releases of Vault. We are targeting the **Note:** After upgrading to 1.12, any attempt to unseal a core with one of the following features enabled will result in a core shutdown. This may temporarily be overridden using the `VAULT_ALLOW_PENDING_REMOVAL_MOUNTS` environment variable when launching the Vault server. These features will be officially removed from Vault in version 1.13 and this environment variable will not work. In order to upgrade to 1.13, you will have to completely disable all removed features. -### Q: What is the impact of removing support for X.509 certificates with signatures that use SHA-1? +### Q: what is the impact of removing support for x.509 certificates with signatures that use SHA-1? Starting with Vault 1.12.0, Vault will be built with Go 1.18 or later. The standard library in Go 1.18 and later [rejects X.509 signatures](https://go.dev/doc/go1.18#sha1) that use a SHA-1 hash. @@ -61,7 +61,7 @@ Any signature algorithms that contain `sha1` will be potentially problematic. Here are the use cases that may still use certificates with SHA-1: -#### Auth Methods +#### Auth methods - [AWS Auth Method](/vault/docs/auth/aws): [AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-identity-documents.html) can use SHA-1-based PKCS7 signatures for DSA key pairs. - [Cloud Foundry (CF) Auth Method ](/vault/docs/auth/cf) @@ -71,7 +71,7 @@ Here are the use cases that may still use certificates with SHA-1: - [JWT/OIDC Auth Method](/vault/docs/auth/jwt/) - [TLS Certificates Auth Method](/vault/docs/auth/cert) -#### Database Secrets Engines +#### Database secrets engines - [Cassandra Database Secrets Engine](/vault/docs/secrets/databases/cassandra) - [Couchbase Database Secrets Engine](/vault/docs/secrets/databases/couchbase) @@ -80,7 +80,7 @@ Here are the use cases that may still use certificates with SHA-1: - [MongoDB Database Secrets Engine](/vault/docs/secrets/databases/mongodb) - [MySQL/MariaDB Database Secrets Engine](/vault/docs/secrets/databases/mysql-maria) -#### Secrets Engines +#### Secrets engines - [Active Directory Secrets Engine](/vault/docs/secrets/ad) - [Consul Secrets Engine](/vault/docs/secrets/consul) @@ -89,7 +89,7 @@ Here are the use cases that may still use certificates with SHA-1: - [LDAP Secrets Engine](/vault/docs/secrets/ldap) - [PKI Secrets Engine](/vault/docs/secrets/pki/) -### Q: What are the phases of deprecation? +### Q: what are the phases of deprecation? As of version 1.12, Vault implements a multi-phased approach to deprecation. The intent of this approach is to provide sufficient warning that a feature will be removed and safe handling of stored data when the associated feature has been removed. @@ -113,7 +113,7 @@ This status reflects a feature which has been marked for deprecation in a later 3. All `POST/GET/LIST` endpoints associated with this feature will return `warnings` in response data. -#### Pending Removal +#### Pending removal This status reflects a feature which has been officially deprecated in this release of Vault. This is the first phase in the process that fundamentally alters the behavior of Vault. The effects are two-fold: @@ -133,7 +133,7 @@ This status reflects a feature which has been officially removed from Vault. `Re 2. Any new `Removed` features will fail and log `Error`-level messages to the Vault log and CLI/API. -#### Migration Path +#### Migration path In order to successfully upgrade, use of the `Removed` feature must be discontinued. To accomplish this: diff --git a/website/content/docs/deprecation/index.mdx b/website/content/docs/deprecation/index.mdx index 561c1b0b2b27..e61b75388f60 100644 --- a/website/content/docs/deprecation/index.mdx +++ b/website/content/docs/deprecation/index.mdx @@ -6,7 +6,7 @@ description: |- An announcement page to communicate feature deprecations and plans. --- -# Feature Deprecation Notice and Plans +# Feature deprecation notice and plans This announcement page is maintained and updated periodically to communicate important decisions made concerning End of Support(EoS) for Vault features as well as features we have removed or disabled from the product. We document the removal of features, enable the community with a plan and timeline for eventual deprecations, and supply alternative paths to explore and evaluate to minimize business disruptions. If you have questions or concerns about a deprecated feature, please create a topic on [the community forum](https://discuss.hashicorp.com/c/vault/30) or raise a ticket with your support team. Please refer to the [FAQ](/vault/docs/deprecation/faq) page for frequently asked questions concerning Vault feature deprecations. diff --git a/website/content/docs/enterprise/automated-integrated-storage-snapshots.mdx b/website/content/docs/enterprise/automated-integrated-storage-snapshots.mdx index 5bebd9653324..9e04dee1bd81 100644 --- a/website/content/docs/enterprise/automated-integrated-storage-snapshots.mdx +++ b/website/content/docs/enterprise/automated-integrated-storage-snapshots.mdx @@ -7,7 +7,7 @@ description: |- in the cloud. --- -# Automated Integrated Storage Snapshots +# Automated integrated storage snapshots -> **Note**: This feature requires [Vault Enterprise](https://www.hashicorp.com/products/vault/) @@ -43,7 +43,7 @@ Storage Snapshots. -# vs Snapshot Agents +# vs snapshot agents Nomad and Consul Enterprise offer the same functionality in a slightly different way. They provide a `snapshot agent`, which is a standalone program that runs diff --git a/website/content/docs/enterprise/automated-upgrades.mdx b/website/content/docs/enterprise/automated-upgrades.mdx index e77bcf6a56a6..3b8b578b27b9 100644 --- a/website/content/docs/enterprise/automated-upgrades.mdx +++ b/website/content/docs/enterprise/automated-upgrades.mdx @@ -5,7 +5,7 @@ description: |- Vault Enterprise can upgrade itself automatically. --- -# Automated Upgrades +# Automated upgrades ~> **Note**: Automated Upgrades requires [Vault Enterprise](https://www.hashicorp.com/products/vault/) to be configured to use Integrated Storage. @@ -40,7 +40,7 @@ Below is a flowchart depicting Autopilot's automated upgrade state machine. The status of the automated upgrade can be monitored by consulting the [Autopilot state API endpoint](/vault/api-docs/system/storage/raftautopilot#get-cluster-state). ## Examples -### Using Vault's built-in version +### Using vault's built-in version This is the easiest method to perform an automated upgrade; no configuration is needed, and automated upgrades are enabled by default. diff --git a/website/content/docs/enterprise/consistency.mdx b/website/content/docs/enterprise/consistency.mdx index b97b84af0e99..b4b240c2df47 100644 --- a/website/content/docs/enterprise/consistency.mdx +++ b/website/content/docs/enterprise/consistency.mdx @@ -4,7 +4,7 @@ page_title: Vault Enterprise Eventual Consistency description: Vault Enterprise Consistency Model --- -# Vault Eventual Consistency +# Vault eventual consistency When running in a cluster, Vault has an eventual consistency model. Only one node (the leader) can write to Vault's storage. @@ -15,7 +15,7 @@ standbys with Integrated Storage, or when using performance replication, there are some sequences of operations that don't always yield read-after-write consistency. -## Performance Standby Nodes +## Performance standby nodes When using the Integrated Storage backend without performance standbys, only a single Vault node (the active node) handles requests. Requests sent to @@ -89,7 +89,7 @@ This mitigation option still exists in Vault 1.7, though now there is a configuration option to adjust the wait time: [best_effort_wal_wait_duration](/vault/docs/configuration/replication). -## Vault 1.7 Mitigations +## Vault 1.7 mitigations There are now a variety of other mitigations available: @@ -105,7 +105,7 @@ how to use them. Note that any headers requesting forwarding are disabled by default, and must be enabled using [allow_forwarding_via_header](/vault/docs/configuration/replication). -### Unconditional Forwarding (Performance standbys only) +### Unconditional forwarding (Performance standbys only) The simplest solution to never experience stale reads from a performance standby is to provide the following HTTP header in the request: @@ -120,7 +120,7 @@ makes sense to use selectively. This mitigation will not help with stale reads relating to performance replication. -### Conditional Forwarding (Performance standbys only) +### Conditional forwarding (Performance standbys only) As of Vault Enterprise 1.7, all requests that modify storage now return a new HTTP response header: @@ -173,7 +173,7 @@ methods for propagating the X-Vault-Index response header into the request header of subsequent requests. Those not using the Vault Go API will want to build equivalent functionality into their client library. -### Vault Proxy and consistency headers +### Vault proxy and consistency headers When configured, the [Vault API Proxy](/vault/docs/agent-and-proxy/proxy/apiproxy) will proxy incoming requests to Vault. There is Proxy configuration available in the `api_proxy` stanza that allows making use @@ -192,7 +192,7 @@ The option `when_inconsistent` controls how stale reads are prevented: `X-Vault-Inconsistent: forward-active-node` header as described above under Conditional Forwarding -## Vault 1.10 Mitigations +## Vault 1.10 mitigations In Vault 1.10, the token format has changed, where service tokens now employ server side consistency. This means that by default, requests made diff --git a/website/content/docs/enterprise/control-groups.mdx b/website/content/docs/enterprise/control-groups.mdx index 2f614e62758b..e92971057351 100644 --- a/website/content/docs/enterprise/control-groups.mdx +++ b/website/content/docs/enterprise/control-groups.mdx @@ -4,7 +4,7 @@ page_title: Vault Enterprise Control Groups description: Vault Enterprise has support for Control Group Authorization. --- -# Vault Enterprise Control Groups +# Vault enterprise control groups -> **Note**: This feature requires [Vault Enterprise Plus](https://www.hashicorp.com/products/vault/). @@ -17,7 +17,7 @@ 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 group factors Control Groups can verify the following factors: @@ -39,12 +39,12 @@ the path `secret/foo` cannot specify a control group factor with `list` as a con Please see the following section for example ACL Policies. -## Control Groups In ACL Policies +## Control groups in ACL policies Control Group requirements on paths are specified as `control_group` along with other ACL parameters. -### Sample ACL Policies +### Sample ACL policies ``` path "secret/foo" { @@ -168,13 +168,13 @@ one superuser approval and one admin approval. `List` will require no extra appr from any of the control group factors, and a token with this policy will not be required to go through the control group workflow in order to execute a read operation against `kv/*`. -## Control Groups in Sentinel +## Control groups in sentinel Control Groups are also supported in Sentinel policies using the `controlgroup` import. See [Sentinel Documentation](/vault/docs/enterprise/sentinel) for more details on available properties. -### Sample Sentinel Policy +### Sample sentinel policy ``` import "time" diff --git a/website/content/docs/enterprise/entropy-augmentation.mdx b/website/content/docs/enterprise/entropy-augmentation.mdx index d1592f74b08b..f3fff6a6e89d 100644 --- a/website/content/docs/enterprise/entropy-augmentation.mdx +++ b/website/content/docs/enterprise/entropy-augmentation.mdx @@ -6,7 +6,7 @@ description: |- cryptographic modules. --- -# Entropy Augmentation +# Entropy augmentation -> **Note**: This feature requires [Vault Enterprise Plus](https://www.hashicorp.com/products/vault/). @@ -21,7 +21,7 @@ entropy from hardware-based random number generators is desirable. To use this feature, you must have an active or trial license for Vault Enterprise. To start a trial, contact [HashiCorp sales](mailto:sales@hashicorp.com). -# Critical Security Parameters (CSPs) +# Critical security parameters (CSPs) Entropy augmentation allows Vault Enterprise to supplement its system entropy with entropy from an external cryptography module. Designed to operate in environments diff --git a/website/content/docs/enterprise/fips/fips1402.mdx b/website/content/docs/enterprise/fips/fips1402.mdx index 1ec4ff7d353a..a434994adaca 100644 --- a/website/content/docs/enterprise/fips/fips1402.mdx +++ b/website/content/docs/enterprise/fips/fips1402.mdx @@ -6,7 +6,7 @@ description: |- the Vault binary. This can directly be used for FIPS compliance. --- -# FIPS 140-2 Inside +# FIPS 140-2 inside -> **Note**: This feature requires [Vault Enterprise Plus](https://www.hashicorp.com/products/vault/). @@ -18,7 +18,7 @@ To use this feature, you must have an active or trial license for Vault Enterprise Plus (HSMs). To start a trial, contact [HashiCorp sales](mailto:sales@hashicorp.com). -## Using FIPS 140-2 Vault Enterprise +## Using FIPS 140-2 Vault enterprise FIPS 140-2 Inside versions of Vault Enterprise behave like non-FIPS versions of Vault. No restrictions are placed on algorithms; it is up to the operator @@ -68,9 +68,9 @@ from the following sources: mlock, or use the `--env SKIP_SETCAP=1` option, to disable mlock completely, as appropriate for your environment. -### Usage Restrictions +### Usage restrictions -#### Migration Restrictions +#### Migration restrictions Hashicorp **does not** support in-place migrations from non-FIPS Inside versions of Vault to FIPS Inside versions of Vault, regardless of version. @@ -91,7 +91,7 @@ reasons: Combined, we suggest leaving the existing cluster in place, and carefully consider migration of specific workloads to the FIPS-backed cluster. -#### Entropy Augmentation Restrictions +#### Entropy augmentation restrictions Entropy Augmentation **does not** work with FIPS 140-2 Inside. The internal BoringCrypto RNG is FIPS 140-2 certified and does not accept entropy from @@ -99,7 +99,7 @@ other sources. On Vault 1.11.0 and later, attempting to use Entropy Augmentation will result in a warning ("Entropy Augmentation is not supported...") and Entropy Augmentation will be disabled. -#### TLS Restrictions +#### TLS restrictions Vault Enterprise's FIPS modifications include restrictions to supported TLS cipher suites and key information. Only the following cipher suites are @@ -120,7 +120,7 @@ Additionally, only the following key types are allowed in TLS chains of trust: Finally, only TLSv1.2 or higher is supported in FIPS mode. These are in line with recent NIST guidance and recommendations. -#### Heterogeneous Cluster Deployments +#### Heterogeneous cluster deployments Hashicorp does not support mixed deployment scenarios within the same Vault cluster, e.g., mixing FIPS and non-FIPS Vault binary versions, or mixing FIPS @@ -131,7 +131,7 @@ the FIPS Inside binary is permitted. Running a heterogeneous cluster is not permitted by FIPS, as components of the system are not compliant with FIPS. -## Technical Details +## Technical details Vault Enterprise's FIPS 140-2 Inside binaries rely on a special version of the Go toolchain which include a FIPS-validated BoringCrypto version. To ensure @@ -147,14 +147,14 @@ server, make sure you see a line with `Fips: Enabled`, such as: additionally opted to certify only on the AMD64 architecture at this time. This means these binaries will not work on Alpine Linux based containers. -### FIPS 140-2 Inside and External Plugins +### FIPS 140-2 inside and external plugins Vault Enterprise's built-in plugins are compiled into the Vault binary using the same Go toolchain version that compiled the core Vault; this results in these plugins having FIPS 140-2 compliance status as well. This same guarantee does not apply to external plugins. -### Validating FIPS 140-2 Inside +### Validating FIPS 140-2 inside To validate that the FIPS 140-2 Inside binary correctly includes BoringCrypto, run `go tool nm` on the binary to get a symbol dump. On non-FIPS builds, @@ -186,14 +186,14 @@ $ gdb --args vault server -dev ...additional GDB output elided... Thread 1 "vault" hit Breakpoint 1, 0x0000000000454950 in _goboringcrypto_BORINGSSL_bcm_power_on_self_test () (gdb) backtrace -#0 0x0000000000454950 in _goboringcrypto_BORINGSSL_bcm_power_on_self_test () -#1 0x00000000005da8f0 in runtime.asmcgocall () at /usr/local/hashicorp-fips-go-devel/src/runtime/asm_amd64.s:765 -#2 0x00007fffd07a5a18 in ?? () -#3 0x00007fffffffdf28 in ?? () -#4 0x000000000057ebce in runtime.persistentalloc.func1 () at /usr/local/hashicorp-fips-go-devel/src/runtime/malloc.go:1371 -#5 0x00000000005d8a49 in runtime.systemstack () at /usr/local/hashicorp-fips-go-devel/src/runtime/asm_amd64.s:383 -#6 0x00000000005dd189 in runtime.newproc (siz=6129989, fn=0x5d88fb ) at :1 -#7 0x0000000000000000 in ?? () +#0 0x0000000000454950 in _goboringcrypto_BORINGSSL_bcm_power_on_self_test () +#1 0x00000000005da8f0 in runtime.asmcgocall () at /usr/local/hashicorp-fips-go-devel/src/runtime/asm_amd64.s:765 +#2 0x00007fffd07a5a18 in ?? () +#3 0x00007fffffffdf28 in ?? () +#4 0x000000000057ebce in runtime.persistentalloc.func1 () at /usr/local/hashicorp-fips-go-devel/src/runtime/malloc.go:1371 +#5 0x00000000005d8a49 in runtime.systemstack () at /usr/local/hashicorp-fips-go-devel/src/runtime/asm_amd64.s:383 +#6 0x00000000005dd189 in runtime.newproc (siz=6129989, fn=0x5d88fb ) at :1 +#7 0x0000000000000000 in ?? () ``` Exact output may vary. @@ -222,7 +222,7 @@ with the FIPS integrity check succeeding. -### BoringCrypto Certification +### BoringCrypto certification BoringCrypto Version 7 uses the following FIPS 140-2 Certificate and software version: @@ -243,7 +243,7 @@ The following algorithms were certified as part of this release: - TLSv1.0/TLSv1.1 and TLSv1.2 KDFs, - AES-256 based CRT_DRBG CS-PRNG. -### Leidos Compliance +### Leidos compliance See the updated [Leidos Compliance Letter (V Entr v1.10.0+entrfips) for FIPS Inside](https://www.datocms-assets.com/2885/1653327036-boringcrypto_compliance_letter_signed.pdf) using the Boring Crypto Libraries for more details. All [past letters](https://www.hashicorp.com/vault-compliance) are also available for reference. diff --git a/website/content/docs/enterprise/fips/index.mdx b/website/content/docs/enterprise/fips/index.mdx index 0c5a82407408..643b488aa5db 100644 --- a/website/content/docs/enterprise/fips/index.mdx +++ b/website/content/docs/enterprise/fips/index.mdx @@ -11,19 +11,19 @@ is a cryptography-focused certification standard for U.S. Government usage. Hashicorp's Vault Enterprise supports the modes of FIPS compliance documented below. -## FIPS 140-2 Inside +## FIPS 140-2 inside Vault Enterprise now includes release flavors with FIPS 140-2 compliant cryptography built into the Vault binary. More information on these releases can be found on the [FIPS 140-2 Inside](/vault/docs/enterprise/fips/fips1402) page. -## Seal Wrap +## Seal wrap Before our FIPS Inside effort, Vault [depended on](https://www.hashicorp.com/vault-compliance) an external HSM for FIPS 140-2 compliance. This uses the [Seal Wrap](/vault/docs/enterprise/fips/sealwrap) functionality to wrap security relevant keys in an extra layer of encryption. -## Comparison of Versions +## Comparison of versions The below table attempts to documents the FIPS compliance of various Vault operations between FIPS Inside and FIPS Seal Wrap. This table is by no means diff --git a/website/content/docs/enterprise/fips/sealwrap.mdx b/website/content/docs/enterprise/fips/sealwrap.mdx index 3094f631a03b..5d667a836a0e 100644 --- a/website/content/docs/enterprise/fips/sealwrap.mdx +++ b/website/content/docs/enterprise/fips/sealwrap.mdx @@ -7,7 +7,7 @@ description: |- a certified HSM. --- -# Seal Wrap for FIPS Compliance +# Seal wrap for FIPS compliance -> **Note**: This feature requires [Vault Enterprise Plus](https://www.hashicorp.com/products/vault/). @@ -20,12 +20,12 @@ To use this feature, you must have an active or trial license for Vault Enterprise Plus (HSMs). To start a trial, contact [HashiCorp sales](mailto:sales@hashicorp.com). -## Using Seal Wrap +## Using seal wrap See [the Enterprise documentation](/vault/docs/enterprise/sealwrap) for instructions on how to use and enable Seal Wrap. -## FIPS 140-2 Compliance +## FIPS 140-2 compliance Vault's Seal Wrap feature has been evaluated by Leidos for compliance with FIPS 140-2 requirements. When used with a FIPS 140-2-compliant HSM, Vault will @@ -36,7 +36,7 @@ section below for details. [Download the current compliance letter](/vault/docs/enterprise/sealwrap/Vault_Compliance_Letter_signed.pdf) -### Updates Since The Latest FIPS Compliance Audit +### Updates since the latest FIPS compliance audit The following are values that take advantage of seal wrapping in the current release of Vault that have not yet been asserted as compliant by Leidos. The @@ -48,7 +48,7 @@ evaluated by the auditors. - Client authentication information for the GCP Auth Backend - Client authentication information for the Kubernetes Auth Backend -## Seal Wrap and Replication +## Seal wrap and replication Because of the level of flexibility targeted for replication, values sent over replication connections do not currently meet KeyTransit requirements for FIPS diff --git a/website/content/docs/enterprise/hsm/behavior.mdx b/website/content/docs/enterprise/hsm/behavior.mdx index f9f0757e79ef..f7496413c4a1 100644 --- a/website/content/docs/enterprise/hsm/behavior.mdx +++ b/website/content/docs/enterprise/hsm/behavior.mdx @@ -6,12 +6,12 @@ description: >- and recovery keys as well as rekey and recovery operations. --- -# Vault Enterprise HSM Behavioral Changes +# Vault enterprise HSM behavioral changes This page contains information about the behavioral differences that take effect when using Vault with an HSM. -## Key Split Between Unseal Keys and Recovery Keys +## Key split between unseal keys and recovery keys Normally, Vault uses a single set of unseal keys to perform both decryption of the cryptographic barrier and to authorize recovery operations, such as the @@ -26,7 +26,7 @@ sets of keys: unseal keys and recovery keys. [Seal/Unseal](/vault/docs/concepts/seal#recovery-key) documentation to learn more about recovery keys. -## Unseal (Root) Key +## Unseal (Root) key Vault usually generates a root key and splits it using [Shamir's Secret Sharing](https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing) to prevent a @@ -44,7 +44,7 @@ rather than change parameters set by an operator.) Both rekeying the root key and rotation of the underlying data encryption key are supported when using an HSM. -## Performance and Availability +## Performance and availability When an HSM is used for generating various CSPs or for entropy augmentation, interaction with the HSM becomes part of the request processing for diff --git a/website/content/docs/enterprise/hsm/index.mdx b/website/content/docs/enterprise/hsm/index.mdx index 1e96b8f27a3d..95083c2f51af 100644 --- a/website/content/docs/enterprise/hsm/index.mdx +++ b/website/content/docs/enterprise/hsm/index.mdx @@ -6,7 +6,7 @@ description: >- automatic unsealing. --- -# Vault Enterprise HSM Support +# Vault enterprise HSM support -> **Note**: This feature requires [Vault Enterprise Plus](https://www.hashicorp.com/products/vault/). diff --git a/website/content/docs/enterprise/hsm/security.mdx b/website/content/docs/enterprise/hsm/security.mdx index bb7c1cc63576..fc51204f5fb8 100644 --- a/website/content/docs/enterprise/hsm/security.mdx +++ b/website/content/docs/enterprise/hsm/security.mdx @@ -4,12 +4,12 @@ page_title: Security Details - HSM Integration - Vault Enterprise description: Recommendations to ensure the security of a Vault Enterprise HSM deployment. --- -# Vault Enterprise HSM Security Details +# Vault enterprise HSM security details This page provides information to help ensure that a Vault HSM deployment is performed as securely as possible. -## PKCS#11 Authentication +## PKCS#11 authentication PKCS#11 authentication occurs via a slot number and PIN. In practice, because the PIN is not required to be numeric (and some HSMs require more complex @@ -29,7 +29,7 @@ is running, the attacker will be able to access the HSM key protecting Vault's root key. Therefore, it is extremely important that access to the machine on which Vault is running is also tightly controlled. -## Recovery Key Shares Protection +## Recovery key shares protection Recovery key shares should be protected in the same way as your organization would protect key shares for the cryptographic barrier. As a quorum of recovery diff --git a/website/content/docs/enterprise/index.mdx b/website/content/docs/enterprise/index.mdx index 871018a86111..25220a6310ed 100644 --- a/website/content/docs/enterprise/index.mdx +++ b/website/content/docs/enterprise/index.mdx @@ -6,7 +6,7 @@ description: |- source offering that may be beneficial in certain workflows. --- -# Vault Enterprise +# Vault enterprise Vault Enterprise includes a number of features that may be useful in specific workflows. Please use the sidebar navigation on the left to choose a specific @@ -14,7 +14,7 @@ topic. These features are part of [Vault Enterprise](https://www.hashicorp.com/vault?utm_source=oss&utm_medium=docs&utm_campaign=vault&_ga=1.201793489.1956619674.1489356624). -## Vault Enterprise Licenses +## Vault enterprise licenses A Vault Enterprise license needs to be applied to a Vault cluster in order to use Vault Enterprise features. See diff --git a/website/content/docs/enterprise/lease-count-quotas.mdx b/website/content/docs/enterprise/lease-count-quotas.mdx index b15c1f49fc41..2580eb64f5b8 100644 --- a/website/content/docs/enterprise/lease-count-quotas.mdx +++ b/website/content/docs/enterprise/lease-count-quotas.mdx @@ -5,7 +5,7 @@ description: |- Vault Enterprise features a mechanism to create lease count quotas. --- -# Lease Count Quotas +# Lease count quotas Vault features an extension to resource quotas that allows operators to enforce limits on how many leases are created. For a given lease count quota, if the diff --git a/website/content/docs/enterprise/license/autoloading.mdx b/website/content/docs/enterprise/license/autoloading.mdx index dafd15bec28b..35d936a5ab90 100644 --- a/website/content/docs/enterprise/license/autoloading.mdx +++ b/website/content/docs/enterprise/license/autoloading.mdx @@ -4,7 +4,7 @@ page_title: License Autoloading description: An overview of license autoloading. --- -# License Autoloading +# License autoloading Prior to Vault 1.8, Vault Enterprise would be licensed using special binaries that contained embedded licenses, or via a license written into Vault storage diff --git a/website/content/docs/enterprise/license/faq.mdx b/website/content/docs/enterprise/license/faq.mdx index 4538645f7baf..5b41c5eea42b 100644 --- a/website/content/docs/enterprise/license/faq.mdx +++ b/website/content/docs/enterprise/license/faq.mdx @@ -28,13 +28,13 @@ This FAQ section is for license changes and updates introduced for Vault Enterpr - [Q: How can the new ADP modules be purchased and what features are customer entitled to as part of that purchase?](#q-how-can-the-new-adp-modules-be-purchased-and-what-features-are-customer-entitled-to-as-part-of-that-purchase) - [Q: What is the impact to customers based on these ADP module licensing changes?](#q-what-is-the-impact-to-customers-based-on-these-adp-module-licensing-changes) -### Q: What is the product behavior change introduced by the licensing changes? +### Q: what is the product behavior change introduced by the licensing changes? Per the [feature deprecation plans](/vault/docs/deprecation), Vault will no longer support licenses in storage. An [auto-loaded license](/vault/docs/enterprise/license/autoloading) must be used instead. If you are using stored licenses, you must migrate to auto-loaded licenses prior to upgrading to Vault 1.11 Vault 1.12 will also introduce different termination behavior for evaluation licenses versus non-evaluation licenses. An evaluation license will include a 30-day trial period after which a running Vault server will terminate. Vault servers using a non-evaluation license will not terminate. -### Q: How do the license termination changes affect upgrades? +### Q: how do the license termination changes affect upgrades? Vault 1.12 will introduce changes to the license termination behavior. Upgrades when using expired licenses will now be limited. Vault will not startup if the build date of the binary is _after_ the expiration date of a license. License expiration date and binary build date compatibility can be verified using the [Check for Autoloaded License](/vault/docs/commands/operator/diagnose#check-for-autoloaded-license) check performed by the `vault operator diagnose` command. The build date of a binary can also be found using the [vault version](/vault/docs/commands/version#version) command. @@ -61,22 +61,22 @@ Vault will not start The Vault support team can issue you a temporary evaluation license to allow for security upgrades if your license has expired. -### Q: Will these license changes impact HCP Vault? +### Q: will these license changes impact HCP Vault? No, these changes will not impact HCP Vault. -### Q: Do these license changes impact all Vault customers/licenses? +### Q: do these license changes impact all Vault customers/licenses? | Customer/licenses | Impacted? | | --------------------------------------------------------------------------------------------------------------------------- | --------- | | ENT binaries (evaluation or non-evaluation downloaded from [releases.hashicorp.com](https://releases.hashicorp.com/vault/)) | Yes | | Open-Source (OSS) | No | -### Q: What is the product behavior change introduced by the licensing changes? +### Q: what is the product behavior change introduced by the licensing changes? With Vault 1.11, the use of an [auto-loaded license](/vault/docs/enterprise/license/autoloading) is required for Vault to start successfully. -### Q: How will Vault behave at startup when a license expires or terminates? +### Q: how will Vault behave at startup when a license expires or terminates? When a license expires, Vault continues to function until the license terminates. This behavior exists today and remains unchanged in Vault 1.11. The grace period, defined as the time between license expiration and license termination, is one day for evaluation licenses (as of 1.8), and ten years for non-evaluation licenses. Customers must provide a valid license before the grace period expires. This license is required to be [auto-loaded](/vault/docs/enterprise/license/autoloading). When license terminates (upon grace period expiry), Vault will seal itself and customers will need a valid license in order to successfully bring-up Vault. If a valid license was not installed after license expiry, customers will need to provide one, and this license will need to be auto-loaded. @@ -86,39 +86,39 @@ Vault will not start when attempting to use an expired license and binary with a License expiration date and binary build date compatibility can be verified using the [Check for Autoloaded License](/vault/docs/commands/operator/diagnose#check-for-autoloaded-license) check performed by the `vault operator diagnose` command. The build date of a binary can also be found using the [vault version](/vault/docs/commands/version#version) command. -### Q: What is the impact on evaluation licenses due to this change? +### Q: what is the impact on evaluation licenses due to this change? As of Vault 1.8, any Vault cluster deployed must have a valid [auto-loaded](/vault/docs/enterprise/license/autoloading) license. Vault 1.12 introduces [expiration and termination behavior changes](#q-how-will-vault-behave-at-startup-when-a-license-expires-or-terminates) for non-evaluation licenses. Evaluation licenses will continue to have a 1-day grace period upon license expiry after which they will terminate. Vault will seal itself and shutdown once an evaluation license terminates. -### Q: Are there any changes to existing methods for manual license loading (API or CLI)? +### Q: are there any changes to existing methods for manual license loading (API or CLI)? The [`/sys/license`](/vault/api-docs/v1.10.x/system/license#install-license) and [`/sys/license/signed`](/vault/api-docs/v1.10.x/system/license#read-signed-license) endpoints have been removed as of Vault 1.11. With that said, it is no longer possible to provide a license via the `/sys/license` endpoint. License [auto-loading](/vault/docs/enterprise/license/autoloading) must be used instead. The [`/sys/config/reload/license`](/vault/api-docs/system/config-reload#reload-license-file) endpoint can be used to reload an auto-loaded license provided as a path via an environment variable or configuration. -### Q: Is there a grace period when evaluation licenses expire? +### Q: is there a grace period when evaluation licenses expire? Evaluation licenses have a 1-day grace period. The grace period is the time until the license expires. Upon expiration, Vault will seal and will require a valid license to unseal and function properly. -### Q: Are the license files locked to a specific cluster? +### Q: are the license files locked to a specific cluster? The changes to licenses apply to all nodes in a cluster. The license files are not locked to a cluster, but are independently applied to the appropriate clusters. -### Q: Will a EULA check happen every time a Vault restarts? +### Q: will a EULA check happen every time a Vault restarts? Yes, starting with Vault 1.8, ENT binaries will be subjected to a EULA check. The release of Vault 1.8 introduces the EULA check for evaluation licenses (non-evaluation licenses are evaluated with a EULA check during contractual agreement) . Although the agreement to a EULA occurs only once (when the user receives their license), Vault will check for the presence of a valid license every time a node is restarted. Starting Vault 1.11, when customers deploy new Vault clusters, or upgrade existing Vault clusters, a valid [auto-loaded](/vault/docs/enterprise/license/autoloading) license must exist for the upgrade to be successful. -### Q: What scenarios should a customer plan for due to these license changes? +### Q: what scenarios should a customer plan for due to these license changes? - **New Cluster Deployment**: When a customer deploys new clusters to Vault 1.11 or later, a valid license must exist to successfully deploy. This valid license must be on-disk ([auto-loaded](/vault/docs/enterprise/license/autoloading)). - **Eventual Migration**: Vault 1.11 removes support for in-storage licenses. Migrating to an auto-loaded license is required for Vault to start successfully using version 1.11 or greater. Pre-existing license storage entries will be automatically removed from storage upon startup. -### Q: What is the migration path for customers who want to migrate from their existing license-as-applied-via-the-CLI flow to the license on disk flow? +### Q: what is the migration path for customers who want to migrate from their existing license-as-applied-via-the-CLI flow to the license on disk flow? If a Vault cluster using a stored license is planned to be upgraded to Vault 1.11 or greater, the operator must migrate to using an auto-loaded license. The [`vault license get -signed`](/vault/docs/v1.10.x/commands/license/get) command (or underlying [`/sys/license/signed`](/vault/api-docs/v1.10.x/system/license#read-signed-license) endpoint) can be used to retrieve the license from storage in a running cluster. It is not necessary to remove the stored license entry. That will occur automatically upon startup in Vault 1.11 or greater. Prior to completing the [recommended upgrade steps](/vault/docs/upgrading), perform the following to ensure your license is properly configured: @@ -127,15 +127,15 @@ It is not necessary to remove the stored license entry. That will occur automati 2. Put the license on disk 3. Configure license auto-loading by specifying the [`license_path`](/vault/docs/configuration#license_path) config option or setting the [`VAULT_LICENSE`](/vault/docs/commands#vault_license) or [`VAULT_LICENSE_PATH`](/vault/docs/commands#vault_license_path) environment variable. -### Q: What is the path for customers who want to downgrade/rollback from Vault 1.11 or later (auto-loaded license mandatory) to a pre-Vault 1.11 (auto-loading not mandatory, stored license supported)? +### Q: what is the path for customers who want to downgrade/rollback from Vault 1.11 or later (auto-loaded license mandatory) to a pre-Vault 1.11 (auto-loading not mandatory, stored license supported)? The downgrade procedure remains the same for Vault customers who are currently on Vault 1.11 or later, have a license installed via auto-loading, and would like to downgrade their cluster to a pre-1.11 version. Please refer to the [upgrade procedures](/vault/tutorials/standard-procedures/sop-upgrade) that remind the customers that they must take a snapshot before the upgrade. Customers will need to restore their version from the snapshot, apply the pre-1.11 enterprise binary version they wish to roll back, and bring up the clusters. -### Q: Is there a limited time for support of licenses that are in storage? +### Q: is there a limited time for support of licenses that are in storage? The support of licenses installed by alternative means often leads to difficulties providing the appropriate support. To provide the support expected by our customers, as we have announced in [Vault feature deprecations and plans](/vault/docs/deprecation) we are removing support for licenses in storage with Vault 1.11. This implies licensing endpoints that deal with licenses in storage will be removed, and Vault will no longer check for valid licenses in storage. This change requires that all customers have [auto-loaded](/vault/docs/enterprise/license/autoloading) licenses to upgrade to 1.11(+) successfully. -### Q: What are the steps to upgrade from one autoloaded license to another autoloaded license? +### Q: what are the steps to upgrade from one autoloaded license to another autoloaded license? Follow these steps to migrate from one autoloaded license to another autoloaded license. @@ -145,11 +145,11 @@ Follow these steps to migrate from one autoloaded license to another autoloaded 1. Invoke the [reload command](/vault/api-docs/system/config-reload#reload-license-file) on each individual Vault server, starting with the standbys and doing the leader last. Invoking in this manner reduces possible disruptions if something was performed incorrectly with the above steps. You can either use the [reload command](/vault/api-docs/system/config-reload#reload-license-file) or send a SIGHUP. 1. On each node, ensure that the new license is in use by using the [`vault license get`](/vault/docs/commands/license/get) command and/or checking the logs. -# ADP Licensing +# ADP licensing This FAQ section is for the Advanced Data Protection (ADP) license changes introduced in Vault Enterprise 1.8. -### Q: What are the Vault ADP module licensing changes introduced in 1.8? +### Q: what are the Vault ADP module licensing changes introduced in 1.8? As of Vault Enterprise 1.8, the functionality formerly sold as the Vault ADP module is now separated between two new modules: @@ -163,7 +163,7 @@ As of Vault Enterprise 1.8, the functionality formerly sold as the Vault ADP mod - [Transform Secrets Engine (TSE)](/vault/docs/secrets/transform) -### Q: How can the new ADP modules be purchased and what features are customer entitled to as part of that purchase? +### Q: how can the new ADP modules be purchased and what features are customer entitled to as part of that purchase? **ADP-KM includes**: @@ -175,7 +175,7 @@ As of Vault Enterprise 1.8, the functionality formerly sold as the Vault ADP mod - This module cannot be purchased as a standalone. It requires a Vault Enterprise binary, and customers must purchase the base Vault Enterprise Standard license (at least) to use the corresponding Enterprise features. - The ADP-Transform SKU can be applied as an add-on. This workflow is similar to the consolidated ADP SKU. -### Q: What is the impact to customers based on these ADP module licensing changes? +### Q: what is the impact to customers based on these ADP module licensing changes? Customers need to be aware of the following as a result of these changes: diff --git a/website/content/docs/enterprise/license/index.mdx b/website/content/docs/enterprise/license/index.mdx index 596fc4a68fc1..5861298c524e 100644 --- a/website/content/docs/enterprise/license/index.mdx +++ b/website/content/docs/enterprise/license/index.mdx @@ -4,7 +4,7 @@ page_title: Vault Enterprise License description: An overview of license. --- -# Vault License +# Vault license Licenses and EULA enhancements have been introduced in Vault 1.8 release. Please refer to the [FAQ](/vault/docs/enterprise/license/faq) for common questions concerning these changes. diff --git a/website/content/docs/enterprise/license/utilization-reporting.mdx b/website/content/docs/enterprise/license/utilization-reporting.mdx index f9604a9a7c03..06a0f9c9af73 100644 --- a/website/content/docs/enterprise/license/utilization-reporting.mdx +++ b/website/content/docs/enterprise/license/utilization-reporting.mdx @@ -5,7 +5,7 @@ description: >- Learn what data HashiCorp collects to meter Enterprise license utilization. Enable or disable reporting. Review sample payloads and logs. --- -# Automated License utilization reporting +# Automated license utilization reporting Automated license utilization reporting sends license utilization data to HashiCorp without requiring you to manually collect and report them. It also @@ -30,7 +30,7 @@ traffic is configured correctly and upgrade your enterprise product to a version that supports it. If your installation is air-gapped or network settings are not in place, automated reporting will not work. -### 1. Allow outbound HTTPS traffic on port 443 +### 1. allow outbound HTTPS traffic on port 443 Make sure that your network allows HTTPS egress on port 443 to https://reporting.hashicorp.services by allow-listing the following IP @@ -41,7 +41,7 @@ addresses: - 23.95.85.111 - 44.215.244.1 -### 2. Upgrade +### 2. upgrade Upgrade to a release that supports license utilization reporting. These releases include: @@ -51,7 +51,7 @@ releases include: - [Vault Enterprise 1.12.8](https://releases.hashicorp.com/vault/) and later 1.12.x versions - [Vault Enterprise 1.11.12](https://releases.hashicorp.com/vault/) -### 3. Check logs +### 3. check logs Automatic license utilization reporting will start sending data within 24 hours. Check the server logs for records that the data sent successfully. @@ -283,7 +283,7 @@ HashiCorp collects the following utilization data as JSON payloads: -## Pre-1.9 Counts +## Pre-1.9 counts When upgrading Vault from 1.8 (or earlier) to 1.9 (or later), utilization reporting will only include the [non-entity tokens](/vault/docs/concepts/client-count#non-entity-tokens) that are used after the upgrade. diff --git a/website/content/docs/enterprise/managed-keys.mdx b/website/content/docs/enterprise/managed-keys.mdx index fe71a3adc67e..d7387b563409 100644 --- a/website/content/docs/enterprise/managed-keys.mdx +++ b/website/content/docs/enterprise/managed-keys.mdx @@ -5,7 +5,7 @@ description: >- Managed Keys is a system in Vault that defers all private key operations to a third party system. --- -# Managed Keys +# Managed keys Within certain environments, customers want to leverage key management systems @@ -34,13 +34,13 @@ Every configured Managed Key is bound to a given namespace, defaulting to the root namespace. Any secrets engine's mount path must exist within the same namespace as the Managed Key for which it intends to use. -## Backend Support +## Backend support Managed Keys were developed to support different types of external backends. At this time supported backends are PKCS#11, AWS KMS, Azure Key Vault, and Google Cloud KMS. Support for additional integrations may be added in the future. -## Secret and Auth Engine Support +## Secret and auth engine support The [PKI Secrets Engine](/vault/api-docs/secret/pki#managed-keys) has been integrated with Managed Keys to offer certificate generation, both root and intermediary diff --git a/website/content/docs/enterprise/mfa/index.mdx b/website/content/docs/enterprise/mfa/index.mdx index cd9d9953c8c8..89bf4dbee41c 100644 --- a/website/content/docs/enterprise/mfa/index.mdx +++ b/website/content/docs/enterprise/mfa/index.mdx @@ -6,7 +6,7 @@ description: >- different authentication types. --- -# Vault Enterprise MFA Support +# Vault enterprise MFA support -> **Note**: This section highlights the Step-up Enterprise MFA feature and its capabilities specifically available for [Vault Enterprise](https://www.hashicorp.com/products/vault/) users. @@ -14,7 +14,7 @@ Vault Enterprise has support for Multi-factor Authentication (MFA), using different authentication types. MFA is built on top of the Identity system of Vault. -## MFA Types +## MFA types MFA in Vault can be of the following types. @@ -38,18 +38,18 @@ MFA in Vault can be of the following types. the access to the API. The PingID username will be derived from the caller identity's alias. -## Configuring MFA Methods +## Configuring MFA methods MFA methods are globally managed within the `System Backend` using the HTTP API. Please see [MFA API](/vault/api-docs/system/mfa) for details on how to configure an MFA method. -## MFA Methods In Policies +## MFA methods in policies MFA requirements on paths are specified as `mfa_methods` along with other ACL parameters. -### Sample Policy +### Sample policy ```hcl path "secret/foo" { @@ -95,13 +95,13 @@ When using TOTP, any user with ACL permissions can self-generate credentials. Admins can generate or destroy credentials only if the targeted entity is in the same namespace. -## Supplying MFA Credentials +## Supplying MFA credentials MFA credentials are retrieved from the `X-Vault-MFA` HTTP header. The format of the header is `mfa_method_name[:key[=value]]`. The items in the `[]` are optional. -### Sample Request +### Sample request ```shell-session $ curl \ diff --git a/website/content/docs/enterprise/namespaces.mdx b/website/content/docs/enterprise/namespaces.mdx index 2b31c53a6292..e4476b406aa4 100644 --- a/website/content/docs/enterprise/namespaces.mdx +++ b/website/content/docs/enterprise/namespaces.mdx @@ -6,7 +6,7 @@ description: >- Multi-tenancy (SMT) and self-management. --- -# Vault Enterprise Namespaces +# Vault enterprise namespaces diff --git a/website/content/docs/enterprise/performance-standby.mdx b/website/content/docs/enterprise/performance-standby.mdx index 3f33d3199d8b..7812ae1a096b 100644 --- a/website/content/docs/enterprise/performance-standby.mdx +++ b/website/content/docs/enterprise/performance-standby.mdx @@ -4,7 +4,7 @@ page_title: Performance Standby Nodes - Vault Enterprise description: Performance Standby Nodes - Vault Enterprise --- -# Performance Standby Nodes +# Performance standby nodes -> **Note**: This feature requires [Vault Enterprise Premium](https://www.hashicorp.com/products/vault/). @@ -17,7 +17,7 @@ Vault Enterprise offers additional features that allow HA nodes to service read-only requests on the local standby node. Read-only requests are requests that do not modify Vault's storage. -## Server-to-Server Communication +## Server-to-Server communication Performance Standbys require the request forwarding method described in the [HA Server-to-Server](/vault/docs/concepts/ha#server-to-server-communication) docs. @@ -29,7 +29,7 @@ for use in creating a new mutually-authenticated TLS connection to the cluster port. This connection will be used to send updates from the active node to the standby. -## Request Forwarding +## Request forwarding A Performance Standby will attempt to process requests that come in. If a storage write is detected the standby will forward the request over the cluster @@ -41,7 +41,7 @@ slightly slower than going directly to the active node. A client that has advanced knowledge of the behavior of the call can choose to point the request to the appropriate node. -### Direct Access +### Direct access A Performance Standby will tag itself as such in consul if service registration is enabled. To access the set of Performance Standbys the `performance-standby` @@ -49,14 +49,14 @@ tag can be used. For example to send requests to only the performance standbys `https://performance-standby.vault.dc1.consul` could be used (host name may vary based on consul configuration). -### Behind Load Balancers +### Behind load balancers Additionally, if you wish to point your load balancers at performance standby nodes, the `sys/health` endpoint can be used to determine if a node is a performance standby. See the [sys/health API](/vault/api-docs/system/health) docs for more info. -## Disabling Performance Standbys +## Disabling performance standbys To disable performance standbys the `disable_performance_standby` flag should be set to true in the Vault config file. This will both tell a standby not to @@ -65,7 +65,7 @@ performance standby connections. This setting should be synced across all nodes in the cluster. -## Monitoring Performance Standbys +## Monitoring performance standbys To verify your node is a performance standby the `vault status` command can be used: diff --git a/website/content/docs/enterprise/pkcs11-provider/aws-xks.mdx b/website/content/docs/enterprise/pkcs11-provider/aws-xks.mdx index 81b54fdab01e..c6b85e7f4cd6 100644 --- a/website/content/docs/enterprise/pkcs11-provider/aws-xks.mdx +++ b/website/content/docs/enterprise/pkcs11-provider/aws-xks.mdx @@ -5,7 +5,7 @@ description: |- AWS KMS External Key Store can use Vault as a key store via the Vault PKCS#11 Provider. --- -# Vault with AWS KMS External Key Store (XKS) via PKCS#11 and XKS Proxy +# Vault with AWS KMS external key store (XKS) via PKCS#11 and XKS proxy ~> **Note**: AWS [`xks-proxy`](https://github.com/aws-samples/aws-kms-xks-proxy) is used in this document as a sample implementation. @@ -33,7 +33,7 @@ There are 3 parts to this setup: In order to serve requests with this latency, we recommend hosting Vault and the XKS proxy as close as possible to the desired KMS region. -## Vault Setup +## Vault setup On the Vault server, we need to [setup the KMIP Secrets Engine](/vault/docs/secrets/kmip): @@ -76,7 +76,7 @@ On the Vault server, we need to [setup the KMIP Secrets Engine](/vault/docs/secr jq --raw-output --exit-status '.data.certificate' kmip.json > cert.pem ``` -## XKS Proxy Setup +## XKS proxy setup The rest of the steps take place on the XKS Proxy server. diff --git a/website/content/docs/enterprise/pkcs11-provider/index.mdx b/website/content/docs/enterprise/pkcs11-provider/index.mdx index 3ecbc02f4780..6fe998c3d8b1 100644 --- a/website/content/docs/enterprise/pkcs11-provider/index.mdx +++ b/website/content/docs/enterprise/pkcs11-provider/index.mdx @@ -7,7 +7,7 @@ description: |- This requires the Enterprise ADP-KM license. --- -# PKCS#11 Provider +# PKCS#11 provider [PKCS#11](http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html) is an open standard C API that provides a means to access cryptographic capabilities on a device. @@ -17,7 +17,7 @@ Vault provides a PKCS#11 library (or provider) so that Vault can be used as an S This allows a user to treat Vault like any other PKCS#11 device to manage keys, objects, and perform encryption and decryption in Vault using PKCS#11 calls. The PKCS#11 library connects to Vault's [KMIP Secrets Engine](/vault/docs/secrets/kmip) to provide cryptographic operations and object storage. -## Platform Support +## Platform support This library works with Vault Enterprise 1.11+ with the advanced data protection module in the license with the KMIP Secrets Engine. @@ -35,7 +35,7 @@ distro's glibc version, choose the `vault-pkcs11-provider` built against the sam The provider comes in the form of a shared C library, `libvault-pkcs11.so` (for Linux) or `libvault-pkcs11.dylib` (for macOS). It can be downloaded from [releases.hashicorp.com](https://releases.hashicorp.com/vault-pkcs11-provider). -## Quick Start +## Quick start 1. To use the provider, you will need access to a Vault Enterprise instance with the KMIP Secrets Engine. @@ -169,7 +169,7 @@ Environment variables can be also used to configure these parameters and more. - `VAULT_LOG_FILE`: the location of the file the provider will use for logging. Defaults to standard out. - `VAULT_EMULATE_HARDWARE`: whether or not the provider will report that it is backed by a hardware device. -## Encrypted TLS Key Support +## Encrypted TLS key support The TLS key returned by the KMIP engine is unencrypted by default. However, the PKCS#11 provider does support (limited) encryption options for the key using [RFC 1423](https://www.rfc-editor.org/rfc/rfc1423). @@ -189,7 +189,7 @@ The password can be supplied to the provider in two ways: Note that only a single password can be supplied via the `VAULT_KMIP_KEY_PASSWORD`, so if multiple slots in the HCL file use encrypted TLS keys, they will need to be encrypted with the same password, or use the `C_Login` method to specify the password. -## Error Handling +## Error handling If an error occurs, the first place to check will be the `VAULT_LOG_FILE` for any relevant error messages. @@ -412,7 +412,7 @@ Here is the list of supported and unsupported PKCS#11 functions: -## Limitations and Notes +## Limitations and notes Due to the nature of Vault, the KMIP Secrets Engine, and PKCS#11, there are some other limitations to be aware of: diff --git a/website/content/docs/enterprise/pkcs11-provider/oracle-tde.mdx b/website/content/docs/enterprise/pkcs11-provider/oracle-tde.mdx index b67407f53fb5..c7347021a082 100644 --- a/website/content/docs/enterprise/pkcs11-provider/oracle-tde.mdx +++ b/website/content/docs/enterprise/pkcs11-provider/oracle-tde.mdx @@ -21,7 +21,7 @@ To setup Oracle TDE backed by Vault, the following are required: - Vault has TCP port 5696 accessible to the Oracle database. - `libvault-pkcs11.so` downloaded from [releases.hashicorp.com](https://releases.hashicorp.com/vault-pkcs11-provider) for the operating system running the Oracle database (the RHEL 7 x86-64 version for Oracle Enterprise Linux 7). -## Vault Setup +## Vault setup On the Vault server, we need to [setup the KMIP Secrets Engine](/vault/docs/secrets/kmip): @@ -69,7 +69,7 @@ On the Vault server, we need to [setup the KMIP Secrets Engine](/vault/docs/secr jq --raw-output --exit-status '.data.certificate' kmip.json > cert.pem ``` -## Oracle TDE Preparation +## Oracle TDE preparation The rest of the steps take place on the Oracle server. diff --git a/website/content/docs/enterprise/redundancy-zones.mdx b/website/content/docs/enterprise/redundancy-zones.mdx index 07a9148a38fe..960bdb924532 100644 --- a/website/content/docs/enterprise/redundancy-zones.mdx +++ b/website/content/docs/enterprise/redundancy-zones.mdx @@ -5,7 +5,7 @@ description: |- Vault Enterprise clusters can have hot standby nodes for scalability and resiliency. --- -# Redundancy Zones +# Redundancy zones -> **Note**: This feature requires [Vault Enterprise](https://www.hashicorp.com/products/vault/) configured to use Integrated Storage. diff --git a/website/content/docs/enterprise/replication.mdx b/website/content/docs/enterprise/replication.mdx index c406668e04d3..ae9052964c8a 100644 --- a/website/content/docs/enterprise/replication.mdx +++ b/website/content/docs/enterprise/replication.mdx @@ -7,7 +7,7 @@ description: >- recovery workloads. --- -# Vault Enterprise Replication +# Vault enterprise replication ## Overview @@ -85,7 +85,7 @@ Storage Autopilot configuration is an `ignored` storage entry, which allows for secondaries to have a different configuration than their primary. Tokens and leases are written to `local` storage entries. -## Performance Replication +## Performance replication In Performance Replication, secondaries keep track of their own tokens and leases but share the underlying configuration, policies, and supporting secrets (K/V values, @@ -98,7 +98,7 @@ in `transit`, etc.) can be satisfied by the local secondary, allowing Vault to s relatively horizontally with the number of secondaries rather than vertically as in the past. -### Paths Filter +### Paths filter The primary cluster's mount configuration gets replicated across its secondary clusters when you enable Performance Replication. In some cases, you may not @@ -138,7 +138,7 @@ Filter](/vault/tutorials/enterprise/paths-filter) tutorial for step-by-step instructions. -## Disaster Recovery (DR) Replication +## Disaster recovery (DR) replication In disaster recovery (or DR) replication, secondaries share the same underlying configuration, policy, and supporting secrets (K/V values, encryption keys for `transit`, etc) infrastructure @@ -154,7 +154,7 @@ They do not forward service read or write requests until they are elected and be For more information on the capabilities of performance and disaster recovery replication, see the Vault Replication [API Documentation](/vault/api-docs/system/replication). -## Primary and Secondary Cluster Compatibility +## Primary and secondary cluster compatibility ### Storage engines @@ -196,12 +196,12 @@ versions any longer than necessary to perform the upgrade. Details on the internal design of the replication feature can be found in the [replication internals](/vault/docs/internals/replication) document. -## Security Model +## Security model Vault is trusted all over the world to keep secrets safe. As such, we have put extreme focus to detail to our replication model as well. -### Primary/Secondary Communication +### Primary/Secondary communication When a cluster is marked as the primary it generates a self-signed CA certificate. On request, and given a user-specified identifier, the primary @@ -224,7 +224,7 @@ Vault makes use of Application Layer Protocol Negotiation on its cluster port. This allows the same port to handle both request forwarding and replication, even while keeping the certificate root of trust and feature set different. -### Secondary Activation Tokens +### Secondary activation tokens A secondary activation token is an extremely sensitive item and as such is protected via response wrapping. Experienced Vault users will note that the @@ -247,7 +247,7 @@ generation until it is used. Once a secondary is activated, its cluster information is stored safely behind its encrypted barrier. -## Mutual TLS and Load Balancers +## Mutual TLS and load balancers Vault generates its own certificates for cluster members. All replication traffic uses the cluster port using these Vault-generated certificates after initial diff --git a/website/content/docs/enterprise/sealwrap.mdx b/website/content/docs/enterprise/sealwrap.mdx index 762b12424cef..9f6978a05168 100644 --- a/website/content/docs/enterprise/sealwrap.mdx +++ b/website/content/docs/enterprise/sealwrap.mdx @@ -6,7 +6,7 @@ description: |- encryption for supporting seals. --- -# Seal Wrap +# Seal wrap -> **Note**: This feature requires [Vault Enterprise Plus](https://www.hashicorp.com/products/vault/). @@ -37,7 +37,7 @@ wrapping status will change. Similarly, if the flag is removed, it will be a lazy upgrade (which is the case when initially upgrading to a seal wrap-supporting version of Vault). -## Activating Seal Wrapping +## Activating seal wrapping For some values, seal wrapping is always enabled with a supporting seal. This includes the recovery key, any stored key shares, the root key, the keyring, @@ -59,7 +59,7 @@ from HSMs or remote seals. However, values will be cached in memory un-seal-wrapped (but still encrypted by Vault's built-in cryptographic barrier) in Vault, which will mitigate this for read-heavy workloads. -## Seal Wrap and Replication +## Seal wrap and replication Seal wrapping takes place below the replication logic. As a result, it is transparent to replication. Replication will convey which values should be @@ -72,7 +72,7 @@ In addition, it is possible to replicate from a Shamir-protected primary cluster to clusters that use HSMs when seal wrapping is required in downstream datacenters but not in the primary. -## Wrapped Parameters +## Wrapped parameters Each plugin (whether secret or auth) maintains control over parameters it feels are best to Seal Wrap. These are usually just a few core values as @@ -89,7 +89,7 @@ Some examples of places where seal wrapping is used include: keys) and its CA keys. - [Transit](/vault/docs/secrets/transit) for storing keys and their policy. -## FIPS Status +## FIPS status See the [FIPS-specific Seal Wrap documentation](/vault/docs/enterprise/fips/sealwrap) for more information about using Seal Wrapping to achieve FIPS 140-2 compliance. diff --git a/website/content/docs/enterprise/sentinel/examples.mdx b/website/content/docs/enterprise/sentinel/examples.mdx index 8b8acab68790..8a47168ff618 100644 --- a/website/content/docs/enterprise/sentinel/examples.mdx +++ b/website/content/docs/enterprise/sentinel/examples.mdx @@ -12,7 +12,7 @@ understand some best practices. Additional examples can be found [here](https://github.com/hashicorp/vault-guides/tree/master/governance). -## MFA and CIDR Check on Login +## MFA and CIDR check on login The following Sentinel policy requires the incoming user to successfully validate with an Okta MFA push request before authenticating with LDAP. @@ -29,7 +29,7 @@ cidrcheck = rule { sockaddr.is_contained("10.20.0.0/16", request.connection.remote_addr) } -# Require Ping MFA validation to succeed +# Require ping MFA validation to succeed ping_valid = rule { mfa.methods.ping.valid } @@ -53,7 +53,7 @@ describes the conditions under which a matching request is successful. This keeps the default-deny feeling of Vault; if the evaluation condition isn't met, the policy is simply a no-op. -## Allow Only Specific Identity Entities or Groups +## Allow only specific identity entities or groups ```python main = rule { @@ -73,7 +73,7 @@ constraint is that they must be unique. Using IDs guarantees that only that specific entity or group is sufficient; if the group or entity are deleted and recreated with the same name, the match will fail. -## Instantly Disallow All Previously-Generated Tokens +## Instantly disallow all Previously-Generated tokens Imagine a break-glass scenario where it is discovered that there have been compromises of some unknown number of previously-generated tokens. @@ -106,7 +106,7 @@ operates on with a token created before the given time. Tokens created after this time, since they were not a part of the compromise, will not be subject to this restriction. -## Delegate EGP Policy Management Under a Path +## Delegate EGP policy management under a path The following policy gives token holders with this policy (via their tokens or their Identity entities/groups) the ability to write EGP policies that can only diff --git a/website/content/docs/enterprise/sentinel/index.mdx b/website/content/docs/enterprise/sentinel/index.mdx index ebc2ecc1bef3..bb4750f0fe30 100644 --- a/website/content/docs/enterprise/sentinel/index.mdx +++ b/website/content/docs/enterprise/sentinel/index.mdx @@ -14,7 +14,7 @@ high-risk secrets and assets, and because of its default-deny stance, integration with Vault is implemented in a defense-in-depth fashion. This takes the form of multiple types of policies and a fixed evaluation order. -## Policy Types +## Policy types Vault's policy system has been expanded to support three types of policies: @@ -42,7 +42,7 @@ Sentinel execution should be considered to be significantly slower than normal ACL policy checking. If high performance is needed, testing should be performed appropriately when introducing Sentinel policies. -## Policy Evaluation +## Policy evaluation During evaluation, all policy types, if they exist, must grant access. Evaluation uses the following logic: @@ -58,7 +58,7 @@ Evaluation uses the following logic: Any failure at any of these steps results in a denied request. -## Policy Overriding +## Policy overriding Vault supports normal Sentinel overriding behavior. Requests to override can be specified on the command line via the `policy-override` flag or in HTTP @@ -83,7 +83,7 @@ necessary to pre-populate Identity entries or supply additional parameters with the request if you require more information to use MFA than the endpoint is able to glean from the original request alone. -# Using Sentinel +# Using sentinel ## Configuration @@ -103,7 +103,7 @@ subject to an EGPs exactly matching the requested path and any glob EGPs sitting further up the request path, an EGP with a path of `*` will thus take effect on all requests. -## Properties and Examples +## Properties and examples See the [Examples](/vault/docs/enterprise/sentinel/examples) page for examples of Sentinel in action, and the diff --git a/website/content/docs/enterprise/sentinel/properties.mdx b/website/content/docs/enterprise/sentinel/properties.mdx index 2e61ae49d66e..9d78d64b5b6b 100644 --- a/website/content/docs/enterprise/sentinel/properties.mdx +++ b/website/content/docs/enterprise/sentinel/properties.mdx @@ -12,7 +12,7 @@ enumerated on this page. The following properties are available for use in Sentinel policies. -## Namespace Properties +## Namespace properties The `namespace` (Sentinel) namespace gives access to information about the namespace in which the request is running. (This may or may not match the @@ -23,7 +23,7 @@ client's chosen namespace, if a request reaches into a child namespace). | `id` | `string` | The namespace ID | | `path` | `string` | The root path of the namespace | -## Request Properties +## Request properties The following properties are available in the `request` namespace. @@ -38,7 +38,7 @@ The following properties are available in the `request` namespace. | `wrapping.ttl` | `duration` | The requested response-wrapping TTL in nanoseconds, suitable for use with the `time` import | | `wrapping.ttl_seconds` | `int` | The requested response-wrapping TTL in seconds | -### Replication Properties +### Replication properties The following properties exists at the `replication.mode` namespace. @@ -47,7 +47,7 @@ The following properties exists at the `replication.mode` namespace. | `dr` | `string` | The state of DR replication. Valid values are "disabled", "bootstrapping", "primary", and "secondary" | | `replication` | `string` | The state of performance replication. Valid values are "disabled", "bootstrapping", "primary", and "secondary" | -## Token Properties +## Token properties The following properties, if available, are in the `token` namespace. The namespace will not exist if there is no token information attached to a @@ -72,7 +72,7 @@ request, e.g. when logging in. | `role` | `string` | If created via a token role, the role that created the token | | `type` | `string` | The type of token, currently will be either `batch` or `service` | -## Token Namespace Properties +## Token namespace properties The following properties, if available, are in the `token.namespace` namespace. The (Sentinel) namespace will not exist if there is no token information attached to a @@ -83,7 +83,7 @@ request, e.g. when logging in. | `id` | `string` | The namespace ID | | `path` | `string` | The root path of the namespace | -## Identity Properties +## Identity properties The following properties, if available, are in the `identity` namespace. The namespace may not exist if there is no token information attached to the @@ -91,7 +91,7 @@ request; however, at login time the user's request data will be used to attempt to find any existing Identity information, or create some information to pass to MFA functions. -### Entity Properties +### Entity properties These exist at the `identity.entity` namespace. @@ -106,7 +106,7 @@ These exist at the `identity.entity` namespace. | `aliases` | `list (alias)` | List of aliases associated with this entity | | `policies` | `list (string)` | List of the policies set on this entity | -### Alias Properties +### Alias properties These can be retrieved from `identity.entity.aliases`. @@ -123,7 +123,7 @@ These can be retrieved from `identity.entity.aliases`. | `mount_type` | `string` | The type of the mount that created this alias | | `name` | `string` | The alias's name | -### Groups Properties +### Groups properties These exist at the `identity.groups` namespace. @@ -132,7 +132,7 @@ These exist at the `identity.groups` namespace. | `by_id` | `map (string -> group)` | A map of group ID to group information | | `by_name` | `map (string -> group)` | A map of group name to group information; unlike the group ID, there is no guarantee that the current name will always represent the same group | -### Group Properties +### Group properties These can be retrieved from the `identity.groups` maps. @@ -147,7 +147,7 @@ These can be retrieved from the `identity.groups` maps. | `parent_group_ids` | `list (string)` | A list of IDs of groups that are parents of this group | | `policies` | `list (string)` | List of the policies set on this group | -## MFA Properties +## MFA properties These properties exist at the `mfa` namespace. @@ -155,7 +155,7 @@ These properties exist at the `mfa` namespace. | :-------- | :----------------------- | :---------------------------------------- | | `methods` | `map (string -> method)` | A map of method name to method properties | -### MFA Method Properties +### MFA method properties These properties can be accessed via the `mfa.methods` selector. @@ -163,7 +163,7 @@ These properties can be accessed via the `mfa.methods` selector. | :------ | :----- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `valid` | `bool` | Whether the method has successfully been validated; if validation has not been attempted, this will trigger the validation attempt. The result of the validation attempt will be used for this method for all policies for the given request. | -## Control Group Properties +## Control group properties These properties exist at the `controlgroup` namespace. @@ -172,7 +172,7 @@ These properties exist at the `controlgroup` namespace. | `time`, `request_time` | `string` | The original request time in RFC3339 format | | `authorizations` | `list (authorization)` | List of control group authorizations | -### Control Group Authorization +### Control group authorization These properties can be accessed via the `controlgroup.authorizations` selector. diff --git a/website/content/docs/faq/index.mdx b/website/content/docs/faq/index.mdx index a83e3bd59a10..3c1056e41093 100644 --- a/website/content/docs/faq/index.mdx +++ b/website/content/docs/faq/index.mdx @@ -6,6 +6,6 @@ description: |- An FAQ page for product and features. --- -# Product Features FAQ +# Product features FAQ You can access a number of different FAQ pages to get answers to questions about our product and features. These FAQ pages are updated periodically so please check back for the latest updates and new FAQ questions. diff --git a/website/content/docs/faq/ssct.mdx b/website/content/docs/faq/ssct.mdx index a4da089d7342..73f7245a011a 100644 --- a/website/content/docs/faq/ssct.mdx +++ b/website/content/docs/faq/ssct.mdx @@ -4,7 +4,7 @@ page_title: Server Side Consistent Token FAQ description: An list of frequently asked questions about server side consistent tokens --- -# Server Side Consistent Token FAQ +# Server side consistent token FAQ This FAQ section contains frequently asked questions about the Server Side Consistent Token feature. @@ -19,7 +19,7 @@ This FAQ section contains frequently asked questions about the Server Side Consi - [Q: What are the main mitigation options that Vault offers to achieve consistency, and what are the differences between them?](#q-what-are-the-main-mitigation-options-that-vault-offers-to-achieve-consistency-and-what-are-the-differences-between-them) - [Q: Is this feature something I need with Consul Storage?](#q-is-this-feature-something-i-need-with-consul-storage) -### Q: What is the Server Side Consistent Token feature? +### Q: what is the server side consistent token feature? ~> **Note**: This features requires Vault Enterprise. @@ -31,11 +31,11 @@ To help with such cases, we’ve now added support for the Server Side Consisten This feature provides a way for Service tokens, returned from logins (or token create requests), to have the relevant minimum WAL state information embedded within the token itself. Clients can then use this token to authenticate subsequent requests. Thus, clients can obtain read-after-write consistency for the token without typically having to make changes to their code or architecture. If a performance standby does not have the state required to authenticate the token, it returns a 412 error to allow the client to retry. If client retry is not possible, there is a server config to allow for the consistency. -### Q: I have Vault OSS. How does this feature impact me? +### Q: i have Vault OSS. how does this feature impact me? For the sake of standardization between OSS and Enterprise, and due to the value of adding token prefixes in OSS for token scanning use cases, the token formats are changed across OSS and Enterprise starting Vault 1.10. However, since there are no performance standbys or replication in Vault OSS, the new Vault OSS token will always show the local index of the WAL as 0 to indicate there is nothing to wait for. -### Q: What token changes does the Server Side Consistent Tokens feature introduce? +### Q: what token changes does the server side consistent tokens feature introduce? Server Side Consistent Tokens introduces the following key changes: @@ -50,17 +50,17 @@ Server Side Consistent Tokens introduces the following key changes: | Batch Tokens | b. | hvb. | | Recovery Tokens | r. | hvr. | -### Q: Why are we changing the token? +### Q: why are we changing the token? To help with use cases that need read-after-write consistency, the Server Side Consistent Tokens feature provides a way for Service tokens, returned from logins (or token create requests), to embed the relevant information for Vault servers using Integrated Storage to know the minimum WAL index that includes the storage write for the token. This entails changes to the service token format. The token prefix is being updated to make it easier for static-analysis code scanning tools to scan for Vault tokens, for example, to identify Vault tokens that are accidentally stored in a version control system. -### Q: What type of tokens are impacted by this feature? +### Q: what type of tokens are impacted by this feature? With the exception of the prefix changes detailed above that apply to all token types, only Service tokens are impacted by the changes that are introduced by this feature. Other token types such as batch tokens, recovery tokens, or root service tokens are not impacted. -### Q: Is there a new configuration that this feature introduces? +### Q: is there a new configuration that this feature introduces? There is a new configuration in the replication section as follows: @@ -72,7 +72,7 @@ replication { This configuration allows Vault clusters to be configured so that requests made to performance standbys that don’t yet have the most up-to-date WAL index are forwarded to the active node. Please note that there will be extra load on the active node with this type of configuration. -### Q: Is there anything else I need to consider to achieve consistency, besides upgrading to Vault 1.10? +### Q: is there anything else i need to consider to achieve consistency, besides upgrading to Vault 1.10? Yes, there are several considerations to keep in mind, and possibly things that may require you to take action, depending on your use case. @@ -90,7 +90,7 @@ replication { ~> **Note:** If you are generating root tokens or recovery tokens without using the Vault CLI, you will need to modify the OTP length used. refer [here](/vault/docs/upgrading/upgrade-to-1.10.x) for details. -### Q: What do I need to be paying attention to if I rely on tokens for some of my workflows? +### Q: what do i need to be paying attention to if i rely on tokens for some of my workflows? Our documentation on [tokens](/vault/docs/concepts/tokens) clearly identifies that the token body itself is subject to change between versions and should not be relied on. We strongly recommend that you consider this while architecting your environment. @@ -98,7 +98,7 @@ However, if you use scripting and tooling to help in the authentication process If your workflow used the embedded NamespaceID suffix, you will need to perform a [token lookup](/vault/docs/commands/token/lookup) because this is currently absent in the new tokens. -### Q: What are the main mitigation options that Vault offers to achieve consistency, and what are the differences between them? +### Q: what are the main mitigation options that Vault offers to achieve consistency, and what are the differences between them? Vault offers the following options to achieve consistency: @@ -122,6 +122,6 @@ Finally, when speaking of performance implications above, there are two kinds th - Using forwarding will impact horizontal scalability by placing additional load on the active node - No using forwarding will impact latency of client requests due to retrying until the state is consistency -### Q: Is this feature something I need with Consul Storage? +### Q: is this feature something i need with consul storage? Consul has a [default consistency model](/consul/api-docs/features/consistency) and this feature is not relevant with Consul storage. diff --git a/website/content/docs/get-started/developer-qs.mdx b/website/content/docs/get-started/developer-qs.mdx index d0ae87f993b9..4a642a097d3f 100644 --- a/website/content/docs/get-started/developer-qs.mdx +++ b/website/content/docs/get-started/developer-qs.mdx @@ -4,7 +4,7 @@ page_title: Developer Quick Start description: Learn how to store and retrieve your first secret. --- -# Developer Quick Start +# Developer quick start This quick start will explore how to use Vault client libraries inside your application code to store and retrieve your first secret value. Vault takes the security burden away from developers by providing a secure, centralized secret store for an application’s sensitive data: credentials, certificates, encryption keys, and more. @@ -27,7 +27,7 @@ For an out-of-the-box runnable demo application showcasing these concepts and mo -> **Note**: Make sure you are using the [latest version](https://docs.docker.com/engine/release-notes/) of Docker. Older versions may not work. As of 1.12.0, the recommended version of Docker is 20.10.17 or higher. -## Step 1: Start Vault +## Step 1: start Vault !> **Warning**: This in-memory “dev” server is useful for practicing with Vault locally for the first time, but is insecure and **should never be used in production**. For developers who need to manage their own production Vault installations, this [page](/vault/tutorials/operations/production-hardening) provides some guidance on how to make your setup more production-friendly. @@ -51,7 +51,7 @@ The `-dev-root-token-id` flag for dev servers tells the Vault server to allow fu Vault is now listening over HTTP on port **8200**. With all the setup out of the way, it's time to get coding! -## Step 2: Install a client library +## Step 2: install a client library To read and write secrets in your application, you need to first configure a client to connect to Vault. Let's install the Vault client library for your language of choice. @@ -227,7 +227,7 @@ using Vault.Client; -## Step 3: Authenticate to Vault +## Step 3: authenticate to Vault A variety of [authentication methods](/vault/docs/auth) can be used to prove your application's identity to the Vault server. To explore more secure authentication methods, such as via Kubernetes or your cloud provider, see the auth code snippets in the [vault-examples](https://github.com/hashicorp/vault-examples) repository. @@ -335,7 +335,7 @@ vaultClient.SetToken("dev-only-token"); -## Step 4: Store a secret +## Step 4: store a secret Secrets are sensitive data like API keys and passwords that we shouldn’t be storing in our code or configuration files. Instead, we want to store values like this in Vault. @@ -457,7 +457,7 @@ We also provided the path to our secret in Vault. We will reference this path in Run the code now, and you should see `Secret written successfully`. If not, check that you've used the correct value for the root token and Vault server address. -## Step 5: Retrieve a secret +## Step 5: retrieve a secret Now that we know how to write a secret, let's practice reading one. diff --git a/website/content/docs/glossary.mdx b/website/content/docs/glossary.mdx index 88e751a93d7e..f5c2ce4a66c2 100644 --- a/website/content/docs/glossary.mdx +++ b/website/content/docs/glossary.mdx @@ -21,14 +21,14 @@ documentation for Vault. - [Server](#server) - [Storage Backend](#storage-backend) -### Audit Device +### Audit device An audit device is responsible for managing audit logs. Every request to Vault and response from Vault goes through the configured audit devices. This provides a simple way to integrate Vault with multiple audit logging destinations of different types. -### Auth Method +### Auth method An auth method is used to authenticate users or applications which are connecting to Vault. Once authenticated, the auth method returns the @@ -42,7 +42,7 @@ allows users to authenticate via GitHub. Almost everything Vault writes to storage is encrypted using the keyring, which is protected by the seal. We refer to this practice as "the barrier". There are a few exceptions to the rule, for example, the seal configuration is stored in an unencrypted file since it's needed to unseal the barrier, and the keyring is encrypted using the root key, while the root key is encrypted using the seal. -### Client Token +### Client token A client token (aka "Vault Token") is conceptually similar to a session cookie on a web site. Once a user authenticates, Vault @@ -56,13 +56,13 @@ Plugins are a feature of Vault that can be enabled, disabled, and customized to some degree. All Vault [auth methods](/vault/docs/auth) and [secrets engines](/vault/docs/secrets) are considered plugins. -#### Built-in Plugin +#### Built-in plugin Built-in plugins are shipped with Vault, often for commonly used implementations, and require no additional operator intervention to run. Built-in plugins are just like any other backend code inside Vault. -#### External Plugin +#### External plugin External plugins are not shipped with Vault and require additional operator intervention to run. Vault's external plugins are completely separate, @@ -70,7 +70,7 @@ standalone applications that Vault executes and communicates with over RPC. Each time a Vault secret engine or auth method is mounted, a new process is spawned. -#### External Multiplexed Plugin +#### External multiplexed plugin An external plugin may make use of [plugin multiplexing](/vault/docs/plugins/plugin-architecture#plugin-multiplexing). A multiplexed plugin allows a single plugin process to be used for multiple @@ -88,7 +88,7 @@ operator may intervene to revoke the Dynamic Secret before the lease is over. Th contract between Vault and its clients is critical, as it allows for changes in keys and policies without manual intervention. -### Secrets Engine +### Secrets engine A secrets engine is responsible for managing secrets. Simple secrets engines, such as the "kv" secrets engine, return the same @@ -108,7 +108,7 @@ secret lease revocation. Having a server based architecture decouples clients from the security keys and policies, enables centralized audit logging, and simplifies administration for operators. -### Storage Backend +### Storage backend A storage backend is responsible for durable storage of _encrypted_ data. Backends are not trusted by Vault and are only expected to diff --git a/website/content/docs/install.mdx b/website/content/docs/install.mdx index 24f41c896776..612c6122460f 100644 --- a/website/content/docs/install.mdx +++ b/website/content/docs/install.mdx @@ -18,14 +18,14 @@ There are several options to install Vault: 1. [Helm for Kubernetes](/vault/docs/platform/k8s/helm) -## Package Manager +## Package manager HashiCorp manages packages for Ubuntu, Debian, Fedora, RHEL, Amazon Linux, and other distributions. Follow the instructions at [HashiCorp Tutorials][learn-vault-install] to add our PGP key, add a repository, and install. -## Precompiled Binaries +## Precompiled binaries To install the precompiled binary, [download](/vault/downloads) the applicable package for your system. Vault is packaged as a zip file. @@ -40,7 +40,7 @@ command-line, ensure that you place the binary somewhere on your `PATH`. Refer to the [HashiCorp Tutorials][learn-vault-dev-server] to start a server, `put` your first secret, and use other features of Vault. -## Compiling from Source +## Compiling from source To compile from source, you will need [Go](https://golang.org) installed and properly configured (including a `GOPATH` environment variable set), as well as @@ -69,7 +69,7 @@ for only your local build environment (no cross-compiled targets). $ make dev ``` -## Verifying the Installation +## Verifying the installation To verify Vault is installed, run `vault -h` on your system. You should see the help output. If you are executing it from the command line, ensure it is diff --git a/website/content/docs/internals/architecture.mdx b/website/content/docs/internals/architecture.mdx index 1abe2c7617ac..6a275776bc48 100644 --- a/website/content/docs/internals/architecture.mdx +++ b/website/content/docs/internals/architecture.mdx @@ -10,7 +10,7 @@ Vault is an intricate system with numerous distinct components. This page detail ~> **Note:** This page covers the technical details of Vault. The descriptions and elements contained within are for users that wish to learn about Vault without having to reference the source code. Although not required, we encourage all users and operators to review the provided information before using Vault due to its significance in an environment. -# High-Level Overview +# High-Level overview The diagram below illustrates the intricacies and distinct components of Vault. diff --git a/website/content/docs/internals/high-availability.mdx b/website/content/docs/internals/high-availability.mdx index 7af93fcc9a16..8df22b29a9b7 100644 --- a/website/content/docs/internals/high-availability.mdx +++ b/website/content/docs/internals/high-availability.mdx @@ -4,12 +4,12 @@ page_title: High Availability description: Learn about the high availability design of Vault. --- -# High Availability +# High availability Vault can run in a high availability (HA) mode to protect against outages by running multiple Vault servers. -# Design Overview +# Design overview The primary design goal for making Vault Highly Available (HA) is to minimize downtime without affecting horizontal scalability. Vault is @@ -35,7 +35,7 @@ Please note that only _unsealed_ Vault servers may act as a standby. If a server is in a sealed state, it cannot act as a standby. Servers in a sealed state cannot serve any requests if the active server fails. -# Performance Standby Nodes (Enterprise) +# Performance standby nodes (Enterprise) Performance Standby Nodes service read-only requests from users or applications. Read-only requests are requests that do not modify Vault's storage. Vault quickly scales its ability to service these operations, diff --git a/website/content/docs/internals/index.mdx b/website/content/docs/internals/index.mdx index 34a197e512e8..909f5c6164b5 100644 --- a/website/content/docs/internals/index.mdx +++ b/website/content/docs/internals/index.mdx @@ -6,7 +6,7 @@ description: >- Vaults operation. --- -# Vault Internals +# Vault internals This section covers the internals of Vault and explains the technical details of how Vault functions, its architecture and security properties. diff --git a/website/content/docs/internals/integrated-storage.mdx b/website/content/docs/internals/integrated-storage.mdx index 286e75c68bf8..c2bf4d664ee1 100644 --- a/website/content/docs/internals/integrated-storage.mdx +++ b/website/content/docs/internals/integrated-storage.mdx @@ -4,7 +4,7 @@ page_title: Integrated Storage description: Learn about the integrated raft storage in Vault. --- -# Integrated Storage +# Integrated storage Vault supports several storage options for the durable storage of Vault's information. Each backend offers pros, cons, advantages, and trade-offs. For @@ -15,7 +15,7 @@ As of Vault 1.4, an Integrated Storage option is offered. This storage backend does not rely on any third party systems; it implements high availability, supports Enterprise Replication features, and provides backup/restore workflows. -## Consensus Protocol +## Consensus protocol Vault's Integrated Storage uses a [consensus protocol]() to provide @@ -24,7 +24,7 @@ The consensus protocol is based on ["Raft: In search of an Understandable Consensus Algorithm"](https://raft.github.io/raft.pdf). For a visual explanation of Raft, see [The Secret Lives of Data](http://thesecretlivesofdata.com/raft). -### Raft Protocol Overview +### Raft protocol overview Raft is a consensus algorithm that is based on [Paxos](https://en.wikipedia.org/wiki/Paxos_%28computer_science%29). Compared @@ -61,14 +61,14 @@ and managing when an entry is committed. The leader node is also the active Vaul - **Committed Entry** - An entry is considered _committed_ when it is durably stored on a quorum of nodes. An entry is applied once its committed. -#### Node States +#### Node states Raft nodes are always in one of three states: follower, candidate, or leader. All nodes initially start out as a follower. In this state, nodes can accept log entries from a leader and cast votes. If no entries are received for a period of time, nodes will self-promote to the candidate state. In the candidate state, nodes request votes from their peers. If a candidate receives a quorum of votes, then it is promoted to a leader. The leader must accept new log entries and replicate to all the other followers. -#### Writing Logs +#### Writing logs Once a cluster has a leader, it is able to accept new log entries. A client can request that a leader append a new log entry (from Raft's perspective, a log entry @@ -79,7 +79,7 @@ is application specific; in Vault's case, we use [BoltDB](https://github.com/etcd-io/bbolt) to maintain a cluster state. Vault's writes are blocked until they are _committed_ and _applied_. -#### Compacting Logs +#### Compacting logs It would be undesirable to allow a replicated log to grow in an unbounded fashion. Raft provides a mechanism by which the current state is saved to @@ -138,7 +138,7 @@ forwarded to the leader. Similar to other storage backends, data that is written to the Raft log and FSM will be encrypted by Vault's barrier. -### Quorum Management +### Quorum management #### Autopilot @@ -164,7 +164,7 @@ manual operator intervention. This is enabled via the [Autopilot API](/vault/api If you wish to decommission a node manually, this can be done with the `remove peer` [command](/vault/docs/commands/operator/raft#remove-peer). -#### Without Autopilot +#### Without autopilot Older versions of Vault, 1.6.x & lower, as well as cases where Autopilot may be disabled or misconfigured, behave differently. @@ -190,7 +190,7 @@ For this reason, we recommend ensuring new nodes have Raft indexes that are close to the leader before adding additional nodes. Raft indexes are visible via `vault status`. -### Deployment Table +### Deployment table Below is a table that shows quorum size and failure tolerance for various cluster sizes. The recommended production deployment consists of 5 servers. A @@ -244,7 +244,7 @@ in a failure scenario. -### Minimums & Scaling +### Minimums & scaling The [Vault Reference Architecture](/vault/tutorials/day-one-raft/raft-reference-architecture#recommended-architecture) recommends a 5 node cluster to ensure a minimum failure tolerance of at least 2. diff --git a/website/content/docs/internals/limits.mdx b/website/content/docs/internals/limits.mdx index 1f4550deacd9..22ab544494e7 100644 --- a/website/content/docs/internals/limits.mdx +++ b/website/content/docs/internals/limits.mdx @@ -4,7 +4,7 @@ page_title: Limits and Maximums description: Learn about the maximum number of objects within Vault. --- -# Vault Limits and Maximums +# Vault limits and maximums Vault imposes fixed upper limits on the size of certain fields and objects, and configurable limits on others. Vault also has upper diff --git a/website/content/docs/internals/replication.mdx b/website/content/docs/internals/replication.mdx index b8b2d55677e4..2a359c3ff827 100644 --- a/website/content/docs/internals/replication.mdx +++ b/website/content/docs/internals/replication.mdx @@ -4,7 +4,7 @@ page_title: Replication description: Learn about the details of multi-datacenter replication within Vault. --- -# Replication (Vault Enterprise) +# Replication (Vault enterprise) Vault Enterprise 0.7 adds support for multi-datacenter replication. Before using this feature, it is useful to understand the intended use cases, design @@ -15,7 +15,7 @@ replication, focusing on high availability for global deployments. The trade-offs made in the design and implementation of replication reflect these high level goals. -# Use Cases +# Use cases Vault replication is based on a number of common use cases: @@ -35,7 +35,7 @@ Vault replication is based on a number of common use cases: allows load to be distributed across additional servers to scale request throughput. -# Design Goals +# Design goals Based on the use cases for Vault Replication, we had a number of design goals for the implementation: @@ -101,7 +101,7 @@ the work of TTL management between the clusters. The caveat is that clients will need to re-authenticate if they switch the Vault cluster they are communicating with. -# Implementation Details +# Implementation details It is important to understand the high-level architecture of replication to ensure the trade-offs are appropriate for your use case. The implementation diff --git a/website/content/docs/internals/rotation.mdx b/website/content/docs/internals/rotation.mdx index 519b50b8be48..29c3970764cd 100644 --- a/website/content/docs/internals/rotation.mdx +++ b/website/content/docs/internals/rotation.mdx @@ -4,7 +4,7 @@ page_title: Key Rotation description: Learn about the details of key rotation within Vault. --- -# Key Rotation +# Key rotation Vault has multiple encryption keys that are used for various purposes. These keys support rotation so that they can be periodically changed or in response to a potential leak or @@ -57,7 +57,7 @@ without requiring operators to perform another unseal. The `rotate/config` endpoint is used to configure the number of operations or time interval between automatic rotations of the backend encryption key. -## NIST Rotation Guidance +## NIST rotation guidance Periodic rotation of the encryption keys is recommended, even in the absence of compromise. Due to the nature of the AES-256-GCM encryption used, keys should be diff --git a/website/content/docs/internals/security.mdx b/website/content/docs/internals/security.mdx index e900e34a01ad..0ccbe1aab02b 100644 --- a/website/content/docs/internals/security.mdx +++ b/website/content/docs/internals/security.mdx @@ -4,7 +4,7 @@ page_title: Security Model description: Learn about the security model of Vault. --- -# Security Model +# Security model Due to the nature of Vault and the confidentiality of data it manages, the Vault security model is very critical. The overall goal of Vault's security @@ -17,7 +17,7 @@ to access data or modify policies. All interactions must be auditable and traced uniquely back to the origin entity, and the system must be robust against intentional attempts to bypass any of its access controls. -# Threat Model +# Threat model The following are the various parts of the Vault threat model: @@ -81,7 +81,7 @@ The following are not considered part of the Vault threat model: configuration files should be validated. If an attacker can write to Vault's configuration, then the confidentiality or integrity of data can be compromised. -# External Threat Overview +# External threat overview Vault architecture compromises of three distinct systems: @@ -121,7 +121,7 @@ this is not applicable. Because storage backends are untrusted, an eavesdropper would only gain access to encrypted data even if communication with the backend was intercepted. -# Internal Threat Overview +# Internal threat overview Within the Vault system, a critical security concern is an attacker attempting to gain access to secret material they are not authorized to. This is an internal diff --git a/website/content/docs/internals/telemetry.mdx b/website/content/docs/internals/telemetry.mdx index 4a578886257a..6514b6a6083b 100644 --- a/website/content/docs/internals/telemetry.mdx +++ b/website/content/docs/internals/telemetry.mdx @@ -57,7 +57,7 @@ The following sections describe the available Vault metrics. The metrics interva Some Vault metrics come with additional [labels](#metric-labels) describing the measurement in more detail, such as the namespace in which an operation takes place or the auth method used to create a token. This additional information is incorporated into the metrics name in the in-memory telemetry or other telemetry engines that do not support labels. The metric name in the table below is followed by a list of labels supported, in the order in which they appear, if flattened. -## Audit Metrics +## Audit metrics These metrics relate to auditing. @@ -70,7 +70,7 @@ These metrics relate to auditing. **NOTE:** In addition, there are audit metrics for each enabled audit device represented as `vault.audit..log_request`. For example, if a file audit device is enabled, its metrics would be `vault.audit.file.log_request` and `vault.audit.file.log_response` . -## Core Metrics +## Core metrics These metrics represent operational aspects of the running Vault instance. @@ -116,7 +116,7 @@ These metrics represent operational aspects of the running Vault instance. | `vault.route.read.` | Time taken to dispatch a read operation to a backend, and for that backend to process it. | ms | summary | | `vault.route.rollback.` | Time taken to dispatch a rollback operation to a backend, and for that backend to process it. Rollback operations are automatically scheduled to clean up partial errors. | ms | summary | -## Runtime Metrics +## Runtime metrics These metrics collect information from Vault's Go runtime, such as memory usage information. @@ -132,7 +132,7 @@ These metrics collect information from Vault's Go runtime, such as memory usage | `vault.runtime.gc_pause_ns` | Total duration of the last garbage collection run | ns | summary | | `vault.runtime.total_gc_runs` | Total number of garbage collection runs since Vault was last started | operations | gauge | -## Policy Metrics +## Policy metrics These metrics report measurements of the time spent performing policy operations. @@ -143,7 +143,7 @@ These metrics report measurements of the time spent performing policy operations | `vault.policy.delete_policy` | Time taken to delete a policy | ms | summary | | `vault.policy.set_policy` | Time taken to set a policy | ms | summary | -## Token, Identity, and Lease Metrics +## Token, identity, and lease metrics These metrics cover the measurement of token, identity, and lease operations, and counts of the number of such objects managed by Vault. @@ -189,7 +189,7 @@ These metrics cover the measurement of token, identity, and lease operations, an | `vault.token.revoke-tree` | Time taken to revoke a token tree | ms | summary | | `vault.token.store` | Time taken to store an updated token entry without writing to the secondary index | ms | summary | -## Resource Quota Metrics +## Resource quota metrics These metrics relate to rate limit and lease count quotas. Each metric comes with a label "name" identifying the specific quota. @@ -200,7 +200,7 @@ These metrics relate to rate limit and lease count quotas. Each metric comes wit | `vault.quota.lease_count.max` | Total maximum number of leases allowed by the lease count quota | lease | gauge | | `vault.quota.lease_count.counter` | Total current number of leases generated by the lease count quota | lease | gauge | -## Merkle Tree and Write Ahead Log Metrics +## Merkle tree and write ahead log metrics These metrics relate to internal operations on Merkle Trees and Write Ahead Logs (WAL) @@ -219,7 +219,7 @@ These metrics relate to internal operations on Merkle Trees and Write Ahead Logs | `vault.wal.flushReady` | Time taken to flush a ready Write Ahead Log (WAL) to storage | ms | summary | | `vault.wal.flushReady.queue_len` | Size of the write queue in the WAL system | WAL | summary | -## HA Metrics +## HA metrics These metrics are emitted on standbys when talking to the active node, and in some cases by performance standbys as well. @@ -230,7 +230,7 @@ These metrics are emitted on standbys when talking to the active node, and in so | `vault.ha.rpc.client.echo` | Time taken to send an echo request from a standby to the active node | ms | summary | | `vault.ha.rpc.client.echo.errors` | Number of standby echo request failures | errors | counter | -## Replication Metrics +## Replication metrics These metrics relate to [Vault Enterprise Replication](/vault/docs/enterprise/replication). The following metrics are not available in telemetry unless replication is in an unhealthy state: `replication.fetchRemoteKeys`, `replication.merkleDiff`, and `replication.merkleSync`. @@ -291,7 +291,7 @@ These metrics relate to [Vault Enterprise Replication](/vault/docs/enterprise/re | `vault.replication.rpc.standby.server.register_lease_request` | Duration of time taken by standby register lease request | ms | summary | | `vault.replication.rpc.standby.server.wrap_token_request` | Duration of time taken by standby wrap token request | ms | summary | -## Secrets Engines Metrics +## Secrets engines metrics These metrics relate to the supported [secrets engines][secrets-engines]. @@ -334,7 +334,7 @@ These metrics relate to the supported [secrets engines][secrets-engines]. | `vault.secret.kv.count` (cluster, namespace, mount_point) | Number of entries in each key-value secret engine. | paths | gauge | | `vault.secret.lease.creation` (cluster, namespace, secret_engine, mount_point, creation_ttl) | Counts the number of leases created by secret engines. | leases | counter | -## Storage Backend Metrics +## Storage backend metrics These metrics relate to the supported [storage backends][storage-backends]. @@ -408,7 +408,7 @@ These metrics relate to the supported [storage backends][storage-backends]. | `vault.zookeeper.delete` | Duration of a DELETE operation against the [ZooKeeper storage backend][zookeeper-storage-backend] | ms | summary | | `vault.zookeeper.list` | Duration of a LIST operation against the [ZooKeeper storage backend][zookeeper-storage-backend] | ms | summary | -## Integrated Storage (Raft) +## Integrated storage (Raft) These metrics relate to raft based [integrated storage][integrated-storage]. @@ -484,7 +484,7 @@ These metrics relate to raft based [integrated storage][integrated-storage]. | `vault.raft_storage.follower.applied_index_delta` | Delta between leader applied index and each follower's applied index reported by echoes. | logs | gauge | | `vault.raft_storage.follower.last_heartbeat_ms` | Time since last echo request received by each follower. | ms | gauge | -## Integrated Storage (Raft) Autopilot +## Integrated storage (Raft) autopilot | Metric | Description | Unit | Type | | :---------------------------------- | :---------------------------------------------------------------------------------------------------- | :---- | :---- | @@ -494,7 +494,7 @@ These metrics relate to raft based [integrated storage][integrated-storage]. Since Autopilot runs only on the active node, these metrics are emitted by the active node only. -## Integrated Storage (Raft) Leadership Changes +## Integrated storage (Raft) leadership changes | Metric | Description | Unit | Type | | :------------------------------ | :------------------------------------------------------------------------------------------------------------ | :-------- | :------ | @@ -508,7 +508,7 @@ Since Autopilot runs only on the active node, these metrics are emitted by the a lower than 200ms, leader > 0 and candidate == 0. Deviations from this might indicate flapping leadership. -## Integrated Storage (Raft) Automated Snapshots +## Integrated storage (Raft) automated snapshots These metrics related to the Enterprise feature [Raft Automated Snapshots](/vault/docs/enterprise/automated-integrated-storage-snapshots). @@ -523,7 +523,7 @@ These metrics related to the Enterprise feature [Raft Automated Snapshots](/vaul | `vault.autosnapshots.rotate.duration` | Measures the time taken to rotate (i.e. delete) old snapshots to satisfy configured retention | ms | summary | | `vault.autosnapshots.snapshots.in.storage` | Number of snapshots in storage | n/a | gauge | -## Metric Labels +## Metric labels | Metric | Description | Example | | :--------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :---------------------- | diff --git a/website/content/docs/internals/token.mdx b/website/content/docs/internals/token.mdx index 0dc81e9c62dd..efa0796662c9 100644 --- a/website/content/docs/internals/token.mdx +++ b/website/content/docs/internals/token.mdx @@ -4,7 +4,7 @@ page_title: Token Authentication description: Learn about the client token authentication in Vault. --- -# Token Authentication +# Token authentication The `token` auth method is built-in and is at the core of client authentication. Other auth methods may be used to diff --git a/website/content/docs/interoperability-matrix.mdx b/website/content/docs/interoperability-matrix.mdx index 4f48c56741b2..60c700b62bff 100644 --- a/website/content/docs/interoperability-matrix.mdx +++ b/website/content/docs/interoperability-matrix.mdx @@ -1,93 +1,93 @@ ---- -layout: docs -page_title: Vault Interoperability Matrix -description: Guide to viewing which partners Vault integrates with. ---- - -# Vault Interoperability Matrix - -Vault integrates with various appliances, platforms and applications for different use cases. Below are two tables indicating the partner’s product that has been verified to work with Vault for [Auto Unsealing](/vault/docs/concepts/seal#auto-unseal) / [HSM Support](/vault/docs/enterprise/hsm) and [External Key Management](https://vaultproject.io/use-cases/key-management). - -Auto Unseal and HSM Support was developed to aid in reducing the operational complexity of keeping the unseal key secure. This feature delegates the responsibility of securing the unseal key from users to a trusted device or service. At startup Vault will connect to the device or service implementing the seal and ask it to decrypt the root key Vault read from storage. - -Vault centrally manages and automates encryption keys across environments allowing customers to control their own encryption keys used in third party services or products. - -## Vault Seal and HSM Interoperability - -The below table shows the partner product and if the partner’s technology works with each individual seal component. - -| Partner | Product | Auto Unseal
(Vault 0.9+) | Entropy Augmentation
(Vault 1.3+) | Seal Wrap
(Vault 0.9+) | Managed Keys
(Vault 1.10+) | Min. Vault Version Verified | -| ----------------- | -------------------------------------- | ------------ | -------------------- | ------------ |-------------- | --------------------------- | -| AliCloud | AliCloud KMS | Yes | No | Yes | No | 0.11.2 | -| Atos | Trustway Proteccio HSM | Yes | Yes | Yes | No | 1.9 | -| AWS | AWS KMS | Yes | Yes | Yes | Yes | 0.9 | -| Crypto4a | QxEDGE™️ HSP | Yes | Yes | Yes | Yes | 1.9 | -| Entrust | nShield HSM | Yes | Yes | Yes | Yes | 1.3 | -| Fortanix | FX2200 Series | Yes | Yes | Yes | No | 0.10 | -| FutureX | Vectera Plus, KMES Series 3 | Yes | Yes | Yes | Yes | 1.5 | -| FutureX | VirtuCrypt cloud HSM | Yes | Yes | Yes | Yes | 1.5 | -| Google | GCP Cloud KMS | Yes | No | Yes | Yes | 0.9 | -| Marvell | Cavium HSM | Yes | Yes | Yes | Yes | 1.11 | -| Microsoft | Azure Key Vault | Yes | No | Yes | Yes | 0.10.2 | -| Oracle | OCI KMS | Yes | No | Yes | No | 1.2.3 | -| PrimeKey | SignServer Hardware Appliance | Yes | Yes | Yes | No | 1.6 | -| Qrypt | Quantum Entropy Service | No | Yes | No | No | 1.11 | -| Quintessence Labs | TSF 400 | Yes | Yes | Yes | No | 1.4 | -| Securosys SA | Primus HSM | Yes | Yes | Yes | Yes | 1.7 | -| Thales | Luna HSM | Yes | Yes | Yes | Yes | 1.4 | -| Thales | Luna TCT HSM | Yes | Yes | Yes | Yes | 1.4 | -| Thales | CipherTrust Manager | Yes | Yes | Yes | No | 1.7 | -| Utimaco | HSM | Yes | Yes | Yes | Yes | 1.4 | -| Yubico | YubiHSM 2 | Yes | Yes | Yes | No | 1.5 | -Last Updated May 03, 2023 - -## Vault as an External Key Management System (EKMS) - -Partners who integrate with Vault to have Vault store and/or manage encryption keys with their products - -~> Note: HCP Vault Verified means that the integration has been verified to work with HCP Vault. All integrations have been verified with Vault self-managed. - - -Vault Secrets Engine Key: K/V = K/V secrets engine; KMSE = Key Management Secrets Engine; KMIP = KMIP Secrets Engine; Transit = Transit Secrets Engine - - -| Partner | Product | Vault Secrets Engine | Min. Vault Version Verified | HCP Vault Verified | -| ----------------- | ------------------------ | -------------------- | --------------------------- | ------------------- | -| AWS | AWS KMS | KMSE | 1.8 | Yes | -| Baffle | Shield | K/V | 1.3 | No | -| Bloombase | StoreSafe | KMIP | 1.9 | N/A | -| Cloudian | HyperStore 7.5.1 | KMIP | 1.12 | N/A | -| Cockroach Labs | Cockroach Cloud DB | KMSE | 1.10 | N/A | -| Cockroach Labs | Cockroach DB | Transit | 1.10 | Yes | -| Commvault Systems | CommVault | KMIP | 1.9 | N/A | -| Cribl | Cribl Stream | K/V | 1.8 | Yes | -| DataStax | DataStax Enterprise | KMIP | 1.11 | Yes | -| Dell | PowerMax | KMIP | 1.12.1 | N/A | -| EnterpriseDB | Postgres Advanced Server | KMIP | 1.12.6 | N/A | -| Garantir | GaraSign | Transit | 1.5 | Yes | -| Google | Google KMS | KMSE | 1.9 | N/A | -| HPE | Exmeral Data Fabric | KMIP | 1.2 | N/A | -| Intel | Key Broker Service | KMIP | 1.11 | N/A | -| JumpWire | JumpWire | K/V | 1.12 | Yes | -| Micro Focus | Connected Mx | Transit | 1.7 | No | -| Microsoft | Azure Key Vault | KMSE | 1.6 | N/A | -| MinIO | Key Encryption Service | K/V | 1.11 | No | -| MongoDB | Atlas | KMSE | 1.6 | N/A | -| MongoDB | MongoDB Enterprise | KMIP | 1.2 | N/A | -| MongoDB | Client Libraries | KMIP | 1.9 | N/A | -| NetApp | ONTAP | KMIP | 1.2 | N/A | -| NetApp | StorageGrid | KMIP | 1.2 | N/A | -| Nutanix | AHV/AOS 6.5.1.6 | KMIP | 1.12 | N/A | -| Ondat | Trousseau | Transit | 1.9 | Yes | -| Oracle | MySQL | KMIP | 1.2 | N/A | -| Percona | Server 8.0 | KMIP | 1.9 | N/A | -| Percona | XtraBackup 8.0 | KMIP | 1.9 | N/A | -| Snowflake | Snowflake | KMSE | 1.6 | N/A | -| VMware | vSphere 7.0, 8.0 | KMIP | 1.2 | N/A | -| VMware | vSan 7.0, 8.0 | KMIP | 1.2 | N/A | -| Yugabyte | Yugabyte Platform | Transit | 1.9 | No | -Last Updated May 03, 2023 - -Please reach out to [technologypartners@hashicorp.com](mailto:technologypartners@hashicorp.com) if there are any questions on the above tables. - -Missing an integration? Join the [Vault Integration Program](/vault/docs/partnerships) and get the integration listed. +--- +layout: docs +page_title: Vault Interoperability Matrix +description: Guide to viewing which partners Vault integrates with. +--- + +# Vault interoperability matrix + +Vault integrates with various appliances, platforms and applications for different use cases. Below are two tables indicating the partner’s product that has been verified to work with Vault for [Auto Unsealing](/vault/docs/concepts/seal#auto-unseal) / [HSM Support](/vault/docs/enterprise/hsm) and [External Key Management](https://vaultproject.io/use-cases/key-management). + +Auto Unseal and HSM Support was developed to aid in reducing the operational complexity of keeping the unseal key secure. This feature delegates the responsibility of securing the unseal key from users to a trusted device or service. At startup Vault will connect to the device or service implementing the seal and ask it to decrypt the root key Vault read from storage. + +Vault centrally manages and automates encryption keys across environments allowing customers to control their own encryption keys used in third party services or products. + +## Vault seal and HSM interoperability + +The below table shows the partner product and if the partner’s technology works with each individual seal component. + +| Partner | Product | Auto Unseal
(Vault 0.9+) | Entropy Augmentation
(Vault 1.3+) | Seal Wrap
(Vault 0.9+) | Managed Keys
(Vault 1.10+) | Min. Vault Version Verified | +| ----------------- | -------------------------------------- | ------------ | -------------------- | ------------ |-------------- | --------------------------- | +| AliCloud | AliCloud KMS | Yes | No | Yes | No | 0.11.2 | +| Atos | Trustway Proteccio HSM | Yes | Yes | Yes | No | 1.9 | +| AWS | AWS KMS | Yes | Yes | Yes | Yes | 0.9 | +| Crypto4a | QxEDGE™️ HSP | Yes | Yes | Yes | Yes | 1.9 | +| Entrust | nShield HSM | Yes | Yes | Yes | Yes | 1.3 | +| Fortanix | FX2200 Series | Yes | Yes | Yes | No | 0.10 | +| FutureX | Vectera Plus, KMES Series 3 | Yes | Yes | Yes | Yes | 1.5 | +| FutureX | VirtuCrypt cloud HSM | Yes | Yes | Yes | Yes | 1.5 | +| Google | GCP Cloud KMS | Yes | No | Yes | Yes | 0.9 | +| Marvell | Cavium HSM | Yes | Yes | Yes | Yes | 1.11 | +| Microsoft | Azure Key Vault | Yes | No | Yes | Yes | 0.10.2 | +| Oracle | OCI KMS | Yes | No | Yes | No | 1.2.3 | +| PrimeKey | SignServer Hardware Appliance | Yes | Yes | Yes | No | 1.6 | +| Qrypt | Quantum Entropy Service | No | Yes | No | No | 1.11 | +| Quintessence Labs | TSF 400 | Yes | Yes | Yes | No | 1.4 | +| Securosys SA | Primus HSM | Yes | Yes | Yes | Yes | 1.7 | +| Thales | Luna HSM | Yes | Yes | Yes | Yes | 1.4 | +| Thales | Luna TCT HSM | Yes | Yes | Yes | Yes | 1.4 | +| Thales | CipherTrust Manager | Yes | Yes | Yes | No | 1.7 | +| Utimaco | HSM | Yes | Yes | Yes | Yes | 1.4 | +| Yubico | YubiHSM 2 | Yes | Yes | Yes | No | 1.5 | +Last Updated May 03, 2023 + +## Vault as an external key management system (EKMS) + +Partners who integrate with Vault to have Vault store and/or manage encryption keys with their products + +~> Note: HCP Vault Verified means that the integration has been verified to work with HCP Vault. All integrations have been verified with Vault self-managed. + + +Vault Secrets Engine Key: K/V = K/V secrets engine; KMSE = Key Management Secrets Engine; KMIP = KMIP Secrets Engine; Transit = Transit Secrets Engine + + +| Partner | Product | Vault Secrets Engine | Min. Vault Version Verified | HCP Vault Verified | +| ----------------- | ------------------------ | -------------------- | --------------------------- | ------------------- | +| AWS | AWS KMS | KMSE | 1.8 | Yes | +| Baffle | Shield | K/V | 1.3 | No | +| Bloombase | StoreSafe | KMIP | 1.9 | N/A | +| Cloudian | HyperStore 7.5.1 | KMIP | 1.12 | N/A | +| Cockroach Labs | Cockroach Cloud DB | KMSE | 1.10 | N/A | +| Cockroach Labs | Cockroach DB | Transit | 1.10 | Yes | +| Commvault Systems | CommVault | KMIP | 1.9 | N/A | +| Cribl | Cribl Stream | K/V | 1.8 | Yes | +| DataStax | DataStax Enterprise | KMIP | 1.11 | Yes | +| Dell | PowerMax | KMIP | 1.12.1 | N/A | +| EnterpriseDB | Postgres Advanced Server | KMIP | 1.12.6 | N/A | +| Garantir | GaraSign | Transit | 1.5 | Yes | +| Google | Google KMS | KMSE | 1.9 | N/A | +| HPE | Exmeral Data Fabric | KMIP | 1.2 | N/A | +| Intel | Key Broker Service | KMIP | 1.11 | N/A | +| JumpWire | JumpWire | K/V | 1.12 | Yes | +| Micro Focus | Connected Mx | Transit | 1.7 | No | +| Microsoft | Azure Key Vault | KMSE | 1.6 | N/A | +| MinIO | Key Encryption Service | K/V | 1.11 | No | +| MongoDB | Atlas | KMSE | 1.6 | N/A | +| MongoDB | MongoDB Enterprise | KMIP | 1.2 | N/A | +| MongoDB | Client Libraries | KMIP | 1.9 | N/A | +| NetApp | ONTAP | KMIP | 1.2 | N/A | +| NetApp | StorageGrid | KMIP | 1.2 | N/A | +| Nutanix | AHV/AOS 6.5.1.6 | KMIP | 1.12 | N/A | +| Ondat | Trousseau | Transit | 1.9 | Yes | +| Oracle | MySQL | KMIP | 1.2 | N/A | +| Percona | Server 8.0 | KMIP | 1.9 | N/A | +| Percona | XtraBackup 8.0 | KMIP | 1.9 | N/A | +| Snowflake | Snowflake | KMSE | 1.6 | N/A | +| VMware | vSphere 7.0, 8.0 | KMIP | 1.2 | N/A | +| VMware | vSan 7.0, 8.0 | KMIP | 1.2 | N/A | +| Yugabyte | Yugabyte Platform | Transit | 1.9 | No | +Last Updated May 03, 2023 + +Please reach out to [technologypartners@hashicorp.com](mailto:technologypartners@hashicorp.com) if there are any questions on the above tables. + +Missing an integration? Join the [Vault Integration Program](/vault/docs/partnerships) and get the integration listed. diff --git a/website/content/docs/partnerships.mdx b/website/content/docs/partnerships.mdx index 3c725c41c43e..a7d66d51c971 100644 --- a/website/content/docs/partnerships.mdx +++ b/website/content/docs/partnerships.mdx @@ -4,7 +4,7 @@ page_title: Vault Integration Program description: Guide to partnership integrations and creating plugins for Vault. --- -# Vault Integration Program +# Vault integration program The HashiCorp Vault Integration Program allows for partners to integrate their products to work with HashiCorp Vault (Open Source or Enterprise versions) or [HashiCorp Cloud Platform](https://cloud.hashicorp.com/) (HCP) Vault. Vault covers a relatively large surface area and thereby a large set of possible integrations, some of which require the partner to build a Vault plugin or an integration that results in the partner’s solution working tightly with Vault. @@ -12,7 +12,7 @@ Partners integrating their solutions via the Vault Integration Process provide t This program is intended to be largely a self-service process with links and guidance to information sources, clearly defined steps, and checkpoints. -## Types of Vault Integrations +## Types of Vault integrations Vault is an Identity-based security solution that leverages trusted sources of identity to keep secrets and application data secured with one centralized, audited workflow for tightly controlling access to secrets across applications, systems, and infrastructure while encrypting data both in flight and at rest. For a full description of the current features please refer to the Vault [website](/). @@ -54,7 +54,7 @@ HCP Vault is a managed version of Vault which is operated by HashiCorp to allow Sign up for HCP Vault [here](https://portal.cloud.hashicorp.com/) and check out [this](/vault/tutorials/cloud) learn guide for quickly getting started. -### Vault Integration Badges +### Vault integration badges There are two types of badges that partners could receive: Vault Enterprise Verified and HCP Vault Verified badges. Partners will be issued the Vault Enterprise badge for integrations that work with Vault Enterprise features such as namespaces, HSM support, or key management. Partners will be issued the HCP Vault badge once their integration has been verified to work with HCP Vault. The badge(s) would be displayed on their partner page (example: [MongoDB](https://www.hashicorp.com/partners/tech/mongodb#vault) and can also be used on their own website to help provide better visibility and differentiation to customers. The process for verification of these integrations is detailed below. @@ -71,7 +71,7 @@ There are two types of badges that partners could receive: Vault Enterprise Veri -## Development Process +## Development process The Vault integration development process is divided into six steps. By following these steps, Vault integrations can be developed alongside HashiCorp to ensure that the integrations are able to be verified and supported in Vault as quickly as possible. A visual representation of the self-guided steps is depicted below. @@ -84,7 +84,7 @@ The Vault integration development process is divided into six steps. By followin 1. Release: Verified integration made available and listed on the HashiCorp website once the HashiCorp technology partnership agreement has been executed 1. Support: Ongoing maintenance and support of the integration by the partner. -### 1. Engage +### 1. engage Please begin by providing some basic information about the integration that is being built via a simple [webform](https://docs.google.com/forms/d/e/1FAIpQLSfQL1uj-mL59bd2EyCPI31LT9uvVT-xKyoHAb5FKIwWwwJ1qQ/viewform). @@ -92,7 +92,7 @@ This information is recorded and used by HashiCorp to track the integration thro Vault has a large and active community and ecosystem of partners that may have already started working on a similar integration. We'll do our best to connect similar parties to avoid duplicate work. -### 2. Enable +### 2. enable While not mandatory, HashiCorp encourages partners to sign an MNDA (Mutual Non-Disclosure Agreement) to allow for open dialog and sharing of ideas during the integration process. @@ -105,7 +105,7 @@ In an effort to support our self-serve model, we’ve included links to resource We encourage partners to closely follow the above guidance. Adopting the same structure and coding patterns helps expedite the review and release cycles. -### 3. Develop and Test +### 3. develop and test For our partners who are building runtime integrations with Vault, we encourage them to support multiple [authentication](/vault/docs/auth) methods (e.g. Approle, JWT, K8s) besides tokens. Additionally we encourage them to add as much flexibility when specifying paths for secrets engines. For our partners who want to build a plugin, the only knowledge necessary to write a plugin is basic command-line skills and knowledge of the Go programming language. When writing in Go-Language, HashiCorp has found the integration development process to be straightforward and simple when partners pay close attention and follow the resources by adopting the same structure and coding patterns to help expedite the review and release cycles. @@ -148,7 +148,7 @@ Additional resources: - [Namespaces - Vault Enterprise](/vault/docs/enterprise/namespaces) - [Create a Vault Cluster on HCP | HashiCorp Learn](/vault/tutorials/cloud/get-started-vault) -### 4. Review +### 4. review During the review process, HashiCorp will provide feedback on the newly developed integration for both Vault and HCP Vault. This is an important step to allow HashiCorp to review and verify your Vault integration. Please reach out to [technologypartners@hashicorp.com](mailto:technologypartners@hashicorp.com) for verification. @@ -156,7 +156,7 @@ The review process can take some time to complete and may require some iteration Once the integration has been verified, the partner is requested to sign the HashiCorp Technology Partner Agreement to have their integration listed on the HashiCorp website upon release. -### 5. Release +### 5. release At this stage, it is expected that the integration is fully complete, the necessary documentation has been written, and HashiCorp has reviewed the integration. @@ -164,7 +164,7 @@ For Auth or Secret Engine plugins specifically, once the plugin has been verifie For HCP Vault verifications, the partner will be issued an HCP Vault Verified badge and will have this displayed on their partner page. -### 6. Support +### 6. support At HashiCorp, we view the release step as the beginning of the journey. Getting the integration built is just the first step in enabling users to leverage it against their infrastructure. Once development is completed, on-going effort is required to support the developed integration and address any issues in a timely manner. @@ -182,6 +182,6 @@ Below is a checklist of steps that should be followed during the Vault integrati - Execute HashiCorp Partner Agreement Documents, review logo guidelines, partner listing and more. - Plan to continue supporting the integration with additional functionality and responding to customer issues -## Contact Us +## Contact us For any questions or feedback, please contact us at: [technologypartners@hashicorp.com](mailto:technologypartners@hashicorp.com) diff --git a/website/content/docs/platform/aws/index.mdx b/website/content/docs/platform/aws/index.mdx index 7934aae56ed7..32e4b7500e43 100644 --- a/website/content/docs/platform/aws/index.mdx +++ b/website/content/docs/platform/aws/index.mdx @@ -6,7 +6,7 @@ description: >- and Vault Enterprise. --- -# AWS Marketplace +# AWS marketplace Vault can be deployed onto Amazon Web Services (AWS) using HashiCorp’s official AWS Marketplace offerings. HashiCorp packages the latest version of both Vault Open Source and Vault Enterprise as Amazon Machine Images (AMIs). @@ -16,7 +16,7 @@ The AWS Marketplace listings can be found below. - [HashiCorp Vault OSS](http://aws.amazon.com/marketplace/pp/B07YLYPLYB) -## Use Cases +## Use cases The Vault AMIs listed in the AWS Marketplace are intended to serve as an easy starting point for a Vault installation. Vault AMIs are built on top of a minimal Ubuntu distribution and contain up to date packages for both Vault and the underlying operating system dependencies. diff --git a/website/content/docs/platform/aws/lambda-extension.mdx b/website/content/docs/platform/aws/lambda-extension.mdx index a9decea5a20e..cd45918951dc 100644 --- a/website/content/docs/platform/aws/lambda-extension.mdx +++ b/website/content/docs/platform/aws/lambda-extension.mdx @@ -5,7 +5,7 @@ description: >- The Vault Lambda Extension allows a Lambda function to read secrets from a Vault deployment. --- -# Vault Lambda Extension +# Vault lambda extension AWS Lambda lets you run code without provisioning and managing servers. The [Vault Lambda Extension](https://github.com/hashicorp/vault-lambda-extension) utilizes the AWS Lambda Extensions API to help your Lambda function read secrets from your Vault deployment. @@ -45,7 +45,7 @@ to read secrets, which can both be used side-by-side: - Configure environment variables such as `VAULT_SECRET_PATH` for the extension to read a secret and write it to disk. -### Adding the extension to your existing Lambda and Vault infrastructure +### Adding the extension to your existing lambda and Vault infrastructure #### Requirements @@ -55,7 +55,7 @@ to read secrets, which can both be used side-by-side: - A secret in Vault that you want your Lambda to access, and a policy giving read access to it - Your Lambda function must use one of the [supported runtimes][https://docs.aws.amazon.com/lambda/latest/dg/runtimes-extensions-api.html] for extensions -#### Step 1. Configure Vault +#### Step 1. configure Vault Enable the aws auth method. @@ -79,7 +79,7 @@ $ vault write auth/aws/role/vault-lambda-role \ ttl=1h ``` -#### Step 2. Option a) Install the extension for Lambda functions packaged in zip archives +#### Step 2. option a) install the extension for lambda functions packaged in zip archives If you deploy your Lambda function as a zip file, you can add the extension to your Lambda layers using the console or [cli](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html#configuration-layers-using): @@ -88,7 +88,7 @@ to your Lambda layers using the console or [cli](https://docs.aws.amazon.com/lam arn:aws:lambda::634166935893:layer:vault-lambda-extension:11 ``` -#### Step 2. Option b) Install the extension for Lambda functions packaged in container images +#### Step 2. option b) install the extension for lambda functions packaged in container images Alternatively, if you deploy your Lambda function as a container image, simply place the built binary in the `/opt/extensions` directory of your image. @@ -118,7 +118,7 @@ Or to build the binary from source. This requires Golang installed. Run from the $ GOOS=linux GOARCH=amd64 go build -o vault-lambda-extension main.go ``` -#### Step 3. Configure vault-lambda-extension +#### Step 3. configure vault-lambda-extension Configure the extension using [Lambda environment variables](https://docs.aws.amazon.com/lambda/latest/dg/configuration-envvars.html): diff --git a/website/content/docs/platform/aws/run.mdx b/website/content/docs/platform/aws/run.mdx index 8f4c955904b8..1f4069067ec7 100644 --- a/website/content/docs/platform/aws/run.mdx +++ b/website/content/docs/platform/aws/run.mdx @@ -32,9 +32,9 @@ HashiCorp’s AWS Marketplace offerings provide an easy way to deploy Vault in a For additional guidance on best practices for running Vault in production, please refer to the [Production Hardening](/vault/tutorials/operations/production-hardening) tutorial. -# Getting Support +# Getting support -## Open Source +## Open source For the Open Source Vault AMI, support can be obtained through the [community channels](https://www.vaultproject.io/community) diff --git a/website/content/docs/platform/github-actions.mdx b/website/content/docs/platform/github-actions.mdx index f218608003e3..557c955ec433 100644 --- a/website/content/docs/platform/github-actions.mdx +++ b/website/content/docs/platform/github-actions.mdx @@ -5,7 +5,7 @@ description: >- GitHub Actions --- -# GitHub Actions +# GitHub actions Workflows in GitHub Actions can make use of secrets stored in Vault by using a [`vault-action`](https://github.com/marketplace/actions/vault-secrets) step. @@ -38,7 +38,7 @@ This example will authenticate to Vault instance at `https://vault.example.com:8 - The secret at path `secret/data/ci/aws` with the key `secretKey` available in the environment variable `AWS_SECRET_ACCESS_KEY` - The secret at path `secret/data/ci` with the key `npm_token` available in the environment variable `NPM_TOKEN` -## Further Information +## Further information For more information on using the `vault-action` GitHub Action, visit: diff --git a/website/content/docs/platform/k8s/csi/configurations.mdx b/website/content/docs/platform/k8s/csi/configurations.mdx index f20bbed67cd0..e0a00068d0bf 100644 --- a/website/content/docs/platform/k8s/csi/configurations.mdx +++ b/website/content/docs/platform/k8s/csi/configurations.mdx @@ -77,7 +77,7 @@ If installing via the helm chart, they can be set using e.g. - `-version` `(bool: false)` - print version information and exit. -# Secret Provider Class Parameters +# Secret provider class parameters The following parameters are supported by the Vault provider. Each parameter is an entry under `spec.parameters` in a SecretProviderClass object. The full diff --git a/website/content/docs/platform/k8s/csi/examples.mdx b/website/content/docs/platform/k8s/csi/examples.mdx index 05f3747ec4c5..a895f360cadd 100644 --- a/website/content/docs/platform/k8s/csi/examples.mdx +++ b/website/content/docs/platform/k8s/csi/examples.mdx @@ -4,13 +4,13 @@ page_title: Vault CSI Provider Examples description: This section documents examples of using the Vault CSI Provider. --- -# Vault CSI Provider Examples +# Vault CSI provider examples The following examples demonstrate how the Vault CSI Provider can be used. ~> A common mistake is to not install the CSI Secret Store Driver before using the Vault CSI Provider. -## File Based Dynamic Database Credentials +## File based dynamic database credentials The following Secret Provider Class retrieves dynamic database credentials from Vault and extracts the generated username and password. The secrets are then mounted as files in the @@ -79,7 +79,7 @@ created the containers will find two files containing secrets: - `/mnt/secrets-store/dbUsername` - `/mnt/secrets-store/dbPassword` -## Environment Variable Dynamic Database Credentials +## Environment variable dynamic database credentials The following Secret Provider Class retrieves dynamic database credentials from Vault and extracts the generated username and password. The secrets are then synced to Kubernetes secrets diff --git a/website/content/docs/platform/k8s/csi/index.mdx b/website/content/docs/platform/k8s/csi/index.mdx index 062a21d221b1..bebc6bbb1342 100644 --- a/website/content/docs/platform/k8s/csi/index.mdx +++ b/website/content/docs/platform/k8s/csi/index.mdx @@ -5,7 +5,7 @@ description: >- The Vault CSI Provider allows pods to consume Vault secrets using CSI volumes. --- -# Vault CSI Provider +# Vault CSI provider The Vault CSI Provider allows pods to consume Vault secrets using [CSI Secrets Store](https://github.com/kubernetes-sigs/secrets-store-csi-driver) volumes. @@ -48,7 +48,7 @@ must be bound to a Vault role and a policy granting access to the secrets desire It is highly recommended to run pods with dedicated Kubernetes service accounts to ensure applications cannot access more secrets than they require. -## Secret Provider Class Example +## Secret provider class example The following is an example of a Secret Provider Class using the `vault` provider: @@ -85,7 +85,7 @@ spec: ~> Secret Provider Class is a namespaced object in Kubernetes. -## Using Secret Provider Classes +## Using secret provider classes An application pod uses the example Secret Provider Class above by mounting it as a CSI volume: diff --git a/website/content/docs/platform/k8s/csi/installation.mdx b/website/content/docs/platform/k8s/csi/installation.mdx index 9fa130bc541f..e3a41988c85e 100644 --- a/website/content/docs/platform/k8s/csi/installation.mdx +++ b/website/content/docs/platform/k8s/csi/installation.mdx @@ -4,7 +4,7 @@ page_title: Vault CSI Provider Installation description: The Vault CSI Provider can be installed using Vault Helm. --- -# Installing the Vault CSI Provider +# Installing the Vault CSI provider ## Prerequisites diff --git a/website/content/docs/platform/k8s/helm/enterprise.mdx b/website/content/docs/platform/k8s/helm/enterprise.mdx index 8c21049209fc..4be0ba9fd370 100644 --- a/website/content/docs/platform/k8s/helm/enterprise.mdx +++ b/website/content/docs/platform/k8s/helm/enterprise.mdx @@ -5,7 +5,7 @@ description: >- Vault Helm supports deploying Vault Enterprise, including license autoloading. --- -# Vault Enterprise License Management +# Vault enterprise license management You can use this Helm chart to deploy Vault Enterprise by following a few extra steps around licensing. @@ -13,9 +13,9 @@ You can use this Helm chart to deploy Vault Enterprise by following a few extra @include 'helm/version.mdx' -## Vault Enterprise 1.8+ +## Vault enterprise 1.8+ -### License Install +### License install First create a Kubernetes secret using the contents of your license file. For example, the following commands create a secret with the name `vault-ent-license` and key `license`: @@ -50,7 +50,7 @@ Once the cluster is [initialized and unsealed](/vault/docs/platform/k8s/helm/run kubectl exec -ti vault-0 -- vault license get ``` -### License Update +### License update To update the autoloaded license in Vault, you may do the following: @@ -95,7 +95,7 @@ kubectl exec vault-0 -- pkill -HUP vault kubectl exec vault-0 -- vault license get ``` -## Vault Enterprise prior to 1.8 +## Vault enterprise prior to 1.8 In your chart overrides, set the values of `server.image` to one of the enterprise [release tags](https://hub.docker.com/r/hashicorp/vault-enterprise/tags). Install the chart, and initialize and unseal vault as described in [Running Vault](/vault/docs/platform/k8s/helm/run). diff --git a/website/content/docs/platform/k8s/helm/examples/enterprise-dr-with-raft.mdx b/website/content/docs/platform/k8s/helm/examples/enterprise-dr-with-raft.mdx index 687704cf4ab0..f637b445b45a 100644 --- a/website/content/docs/platform/k8s/helm/examples/enterprise-dr-with-raft.mdx +++ b/website/content/docs/platform/k8s/helm/examples/enterprise-dr-with-raft.mdx @@ -6,7 +6,7 @@ description: |- Describes how to set up Diaster Recovery clusters with Integrated Storage (Raft) --- -# Highly Available Vault Enterprise Disaster Recovery Clusters with Integrated Storage (Raft) +# Highly available Vault enterprise disaster recovery clusters with integrated storage (Raft) @include 'helm/version.mdx' @@ -16,7 +16,7 @@ For more information on Disaster Recovery, [see the official documentation](/vau -> For license configuration refer to [Running Vault Enterprise](/vault/docs/platform/k8s/helm/enterprise). -## Primary Cluster +## Primary cluster First, create the primary cluster: @@ -67,7 +67,7 @@ e6876c97-aaaa-a92e-b99a-0aafab105745 vault-primary-1.vault-primary-internal:8 4b5d7383-ff31-44df-e008-6a606828823b vault-primary-2.vault-primary-internal:8201 follower true ``` -## Secondary Cluster +## Secondary cluster With the primary cluster created, next create a secondary cluster and enable disaster recovery replication. @@ -119,7 +119,7 @@ e6876c97-aaaa-a92e-b99a-0aafab105745 vault-secondary-1.vault-secondary-intern 4b5d7383-ff31-44df-e008-6a606828823b vault-secondary-2.vault-secondary-internal:8201 follower true ``` -## Enable Disaster Recovery Replication On Primary +## Enable disaster recovery replication on primary With the initial clusters setup, we can now configure them for disaster recovery replication. @@ -137,7 +137,7 @@ kubectl exec -ti vault-primary-0 -- vault write sys/replication/dr/primary/secon The token in the output will be used when configuring the secondary cluster. -## Enable Disaster Recovery Replication On Secondary +## Enable disaster recovery replication on secondary Using the token created in the last step, enable disaster recovery replication on the secondary: diff --git a/website/content/docs/platform/k8s/helm/examples/enterprise-perf-with-raft.mdx b/website/content/docs/platform/k8s/helm/examples/enterprise-perf-with-raft.mdx index 89ab693bbb78..9fc61036c203 100644 --- a/website/content/docs/platform/k8s/helm/examples/enterprise-perf-with-raft.mdx +++ b/website/content/docs/platform/k8s/helm/examples/enterprise-perf-with-raft.mdx @@ -6,7 +6,7 @@ description: |- Describes how to set up Performance clusters with Integrated Storage (Raft) --- -# Highly Available Vault Enterprise Performance Clusters with Integrated Storage (Raft) +# Highly available Vault enterprise performance clusters with integrated storage (Raft) @include 'helm/version.mdx' @@ -16,7 +16,7 @@ For more information on Disaster Recovery, [see the official documentation](/vau -> For license configuration refer to [Running Vault Enterprise](/vault/docs/platform/k8s/helm/enterprise). -## Primary Cluster +## Primary cluster First, create the primary cluster: @@ -67,7 +67,7 @@ e6876c97-aaaa-a92e-b99a-0aafab105745 vault-primary-1.vault-primary-internal:8 4b5d7383-ff31-44df-e008-6a606828823b vault-primary-2.vault-primary-internal:8201 follower true ``` -## Secondary Cluster +## Secondary cluster With the primary cluster created, next create a secondary cluster. @@ -118,7 +118,7 @@ e6876c97-aaaa-a92e-b99a-0aafab105745 vault-secondary-1.vault-secondary-intern 4b5d7383-ff31-44df-e008-6a606828823b vault-secondary-2.vault-secondary-internal:8201 follower true ``` -## Enable Performance Replication On Primary +## Enable performance replication on primary With the initial clusters setup, we can now configure them for Performance Replication. @@ -136,7 +136,7 @@ kubectl exec -ti vault-primary-0 -- vault write sys/replication/performance/prim The token in the output will be used when configuring the secondary cluster. -## Enable Performance Replication On Secondary +## Enable performance replication on secondary Using the token created in the last step, enable Performance Replication on the secondary: diff --git a/website/content/docs/platform/k8s/helm/examples/enterprise-with-raft.mdx b/website/content/docs/platform/k8s/helm/examples/enterprise-with-raft.mdx index 1989275a6884..a2c29bc04d62 100644 --- a/website/content/docs/platform/k8s/helm/examples/enterprise-with-raft.mdx +++ b/website/content/docs/platform/k8s/helm/examples/enterprise-with-raft.mdx @@ -6,7 +6,7 @@ description: |- Describes how to set up a highly available Vault Enterprise cluster with Integrated Storage (Raft) --- -# Highly Available Vault Enterprise Cluster with Integrated Storage (Raft) +# Highly available Vault enterprise cluster with integrated storage (Raft) @include 'helm/version.mdx' diff --git a/website/content/docs/platform/k8s/helm/examples/ha-with-consul.mdx b/website/content/docs/platform/k8s/helm/examples/ha-with-consul.mdx index 2d216de4dac0..411c30352a6e 100644 --- a/website/content/docs/platform/k8s/helm/examples/ha-with-consul.mdx +++ b/website/content/docs/platform/k8s/helm/examples/ha-with-consul.mdx @@ -6,7 +6,7 @@ description: |- Describes how to set up a highly available Vault cluster with Consul backend --- -# Highly Available Vault Cluster with Consul +# Highly available Vault cluster with consul @include 'helm/version.mdx' diff --git a/website/content/docs/platform/k8s/helm/examples/ha-with-raft.mdx b/website/content/docs/platform/k8s/helm/examples/ha-with-raft.mdx index 8d6bed985dfc..27391d2fcf70 100644 --- a/website/content/docs/platform/k8s/helm/examples/ha-with-raft.mdx +++ b/website/content/docs/platform/k8s/helm/examples/ha-with-raft.mdx @@ -6,7 +6,7 @@ description: |- Describes how to set up a highly available Vault cluster with Integrated Storage (Raft) --- -# Highly Available Vault Cluster with Integrated Storage (Raft) +# Highly available Vault cluster with integrated storage (Raft) @include 'helm/version.mdx' diff --git a/website/content/docs/platform/k8s/helm/examples/index.mdx b/website/content/docs/platform/k8s/helm/examples/index.mdx index 4863496ebb06..4f20d3c93270 100644 --- a/website/content/docs/platform/k8s/helm/examples/index.mdx +++ b/website/content/docs/platform/k8s/helm/examples/index.mdx @@ -6,7 +6,7 @@ description: |- This section documents configuration options for the Vault Helm chart --- -# Helm Chart Examples +# Helm chart examples @include 'helm/version.mdx' diff --git a/website/content/docs/platform/k8s/helm/examples/injector-tls-cert-manager.mdx b/website/content/docs/platform/k8s/helm/examples/injector-tls-cert-manager.mdx index 1ce19b4e8bc2..312d68619e99 100644 --- a/website/content/docs/platform/k8s/helm/examples/injector-tls-cert-manager.mdx +++ b/website/content/docs/platform/k8s/helm/examples/injector-tls-cert-manager.mdx @@ -6,7 +6,7 @@ description: |- Describes how to set up the Vault Agent Injector with certificates and keys generated by cert-manager. --- -# Vault Agent Injector TLS with Cert-Manager +# Vault agent injector TLS with Cert-Manager The following instructions demonstrate how to configure the Vault Agent Injector to use certificates generated by [cert-manager](https://cert-manager.io/). This allows you to run multiple replicas of the Vault Agent Injector in a Kubernetes cluster. @@ -23,7 +23,7 @@ $ helm install cert-manager jetstack/cert-manager \ --set installCRDs=true ``` -## Create a Certificate Authority (CA) +## Create a certificate authority (CA) For this example we will bootstrap a self-signed certificate authority (CA) [Issuer](https://cert-manager.io/docs/configuration/). If you already have a [ClusterIssuer](https://cert-manager.io/docs/concepts/issuer/) configured for your cluster, you may skip this step. @@ -79,7 +79,7 @@ NAME READY SECRET ISSUER STATUS injector-selfsigned-ca True injector-ca-secret selfsigned Certificate is up to date and has not expired 32s ``` -## Create the Vault Agent Injector Certificate +## Create the Vault agent injector certificate Next we can create a request for cert-manager to generate a certificate and key signed by the certificate authority above. This certificate and key will be used diff --git a/website/content/docs/platform/k8s/helm/examples/injector-tls.mdx b/website/content/docs/platform/k8s/helm/examples/injector-tls.mdx index 4e7eabafdf22..6e5aac5e941e 100644 --- a/website/content/docs/platform/k8s/helm/examples/injector-tls.mdx +++ b/website/content/docs/platform/k8s/helm/examples/injector-tls.mdx @@ -6,14 +6,14 @@ description: |- Describes how to set up the Vault Agent Injector with manually generated certificates and keys. --- -# Vault Agent Injector TLS Configuration +# Vault agent injector TLS configuration @include 'helm/version.mdx' The following instructions demonstrate how to manually configure the Vault Agent Injector with self-signed certificates. -## Create a Certificate Authority (CA) +## Create a certificate authority (CA) First, create a private key to be used by our custom Certificate Authority (CA): @@ -37,7 +37,7 @@ $ openssl req \ -subj "/C=US/ST=CA/L=San Francisco/O=HashiCorp/CN=vault-agent-injector-svc" ``` -## Create Vault Agent Injector Certificate +## Create Vault agent injector certificate 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 diff --git a/website/content/docs/platform/k8s/helm/examples/kubernetes-auth.mdx b/website/content/docs/platform/k8s/helm/examples/kubernetes-auth.mdx index 762b71e1c7b7..08fe7eef4117 100644 --- a/website/content/docs/platform/k8s/helm/examples/kubernetes-auth.mdx +++ b/website/content/docs/platform/k8s/helm/examples/kubernetes-auth.mdx @@ -6,7 +6,7 @@ description: |- Describes how to set up Kubernetes Auth method --- -# Bootstrapping Kubernetes Auth Method +# Bootstrapping kubernetes auth method @include 'helm/version.mdx' diff --git a/website/content/docs/platform/k8s/helm/examples/standalone-audit.mdx b/website/content/docs/platform/k8s/helm/examples/standalone-audit.mdx index 476773872a6c..66c486649a2d 100644 --- a/website/content/docs/platform/k8s/helm/examples/standalone-audit.mdx +++ b/website/content/docs/platform/k8s/helm/examples/standalone-audit.mdx @@ -6,7 +6,7 @@ description: |- Describes how to set up a standalone Vault with audit storage --- -# Standalone Server with Audit Storage +# Standalone server with audit storage @include 'helm/version.mdx' diff --git a/website/content/docs/platform/k8s/helm/examples/standalone-load-balanced-ui.mdx b/website/content/docs/platform/k8s/helm/examples/standalone-load-balanced-ui.mdx index 7476af2986b3..444b63ad7ba6 100644 --- a/website/content/docs/platform/k8s/helm/examples/standalone-load-balanced-ui.mdx +++ b/website/content/docs/platform/k8s/helm/examples/standalone-load-balanced-ui.mdx @@ -6,7 +6,7 @@ description: |- Describes how to set up a standalone Vault with a load balanced UI --- -# Standalone Server with Load Balanced UI +# Standalone server with load balanced UI @include 'helm/version.mdx' diff --git a/website/content/docs/platform/k8s/helm/examples/standalone-tls.mdx b/website/content/docs/platform/k8s/helm/examples/standalone-tls.mdx index 7f0cec50ef93..6983b8260ee4 100644 --- a/website/content/docs/platform/k8s/helm/examples/standalone-tls.mdx +++ b/website/content/docs/platform/k8s/helm/examples/standalone-tls.mdx @@ -6,7 +6,7 @@ description: |- Describes how to set up a standalone Vault with TLS certificate --- -# Standalone Server with TLS +# Standalone server with TLS @include 'helm/version.mdx' @@ -16,25 +16,25 @@ This example can be used to set up a single server Vault cluster using TLS. 2. Store key & cert into [Kubernetes secrets store](https://kubernetes.io/docs/concepts/configuration/secret/) 3. Configure helm chart to use Kubernetes secret from step 2 -## 1. Create key & certificate using Kubernetes CA +## 1. create key & certificate using kubernetes CA There are four variables that will be used in this example. ```bash -# SERVICE is the name of the Vault service in Kubernetes. +# SERVICE is the name of the Vault service in kubernetes. # It does not have to match the actual running service, though it may help for consistency. export SERVICE=vault-server-tls # NAMESPACE where the Vault service is running. export NAMESPACE=vault-namespace -# SECRET_NAME to create in the Kubernetes secrets store. +# SECRET_NAME to create in the kubernetes secrets store. export SECRET_NAME=vault-server-tls # TMPDIR is a temporary working directory. export TMPDIR=/tmp -# CSR_NAME will be the name of our certificate signing request as seen by Kubernetes. +# CSR_NAME will be the name of our certificate signing request as seen by kubernetes. export CSR_NAME=vault-csr ``` @@ -129,7 +129,7 @@ e is 65537 (0x10001) vault-csr 1m13s kubernetes.io/kubelet-serving kubernetes-admin Approved,Issued ``` -## 2. Store key, cert, and Kubernetes CA into Kubernetes secrets store +## 2. store key, cert, and kubernetes CA into kubernetes secrets store 1. Retrieve the certificate. @@ -171,7 +171,7 @@ e is 65537 (0x10001) # secret/vault-server-tls created ``` -## 3. Helm Configuration +## 3. helm configuration The below `custom-values.yaml` can be used to set up a single server Vault cluster using TLS. This assumes that a Kubernetes `secret` exists with the server certificate, key and diff --git a/website/content/docs/platform/k8s/helm/index.mdx b/website/content/docs/platform/k8s/helm/index.mdx index 49daba2a31af..53f410103b93 100644 --- a/website/content/docs/platform/k8s/helm/index.mdx +++ b/website/content/docs/platform/k8s/helm/index.mdx @@ -6,7 +6,7 @@ description: >- Kubernetes. --- -# Helm Chart +# Helm chart @include 'helm/version.mdx' @@ -22,7 +22,7 @@ properly installed and configured with your Kubernetes cluster. @include 'kubernetes-supported-versions.mdx' -## Using the Helm Chart +## Using the helm chart Helm must be installed and configured on your machine. Please refer to the [Helm documentation](https://helm.sh/) or the [Vault Installation to Minikube via diff --git a/website/content/docs/platform/k8s/helm/openshift.mdx b/website/content/docs/platform/k8s/helm/openshift.mdx index 637533174b8b..75e7c5084700 100644 --- a/website/content/docs/platform/k8s/helm/openshift.mdx +++ b/website/content/docs/platform/k8s/helm/openshift.mdx @@ -37,7 +37,7 @@ on OpenShift: ~> **Note:** Support for Consul on OpenShift is available since [Consul 1.9](https://www.hashicorp.com/blog/introducing-openshift-support-for-consul-on-kubernetes). However, for highly available deployments, Raft integrated storage is recommended. -## Additional Resources +## Additional resources The documentation, configuration and examples for Vault Helm and Vault K8s Agent Injector are applicable to OpenShift installations. For more examples see the existing documentation: @@ -45,7 +45,7 @@ are applicable to OpenShift installations. For more examples see the existing do - [Vault Helm documentation](/vault/docs/platform/k8s/helm) - [Vault K8s documentation](/vault/docs/platform/k8s/injector) -## Helm Chart +## Helm chart The [Vault Helm chart](https://github.com/hashicorp/vault-helm) is the recommended way to install and configure Vault on OpenShift. @@ -134,7 +134,7 @@ $ helm install vault hashicorp/vault \ --set "server.dev.enabled=true" ``` -#### Highly Available Raft Mode +#### Highly available raft mode The following creates a Vault cluster using the Raft integrated storage backend. diff --git a/website/content/docs/platform/k8s/helm/run.mdx b/website/content/docs/platform/k8s/helm/run.mdx index cec137ee96e0..cdaaacdde145 100644 --- a/website/content/docs/platform/k8s/helm/run.mdx +++ b/website/content/docs/platform/k8s/helm/run.mdx @@ -7,14 +7,14 @@ description: >- Kubernetes. --- -# Run Vault on Kubernetes +# Run Vault on kubernetes Vault works with Kubernetes in various modes: `dev`, `standalone`, `ha`, and `external`. @include 'helm/version.mdx' -## Helm Chart +## Helm chart The [Vault Helm chart](https://github.com/hashicorp/vault-helm) is the recommended way to install and configure Vault on Kubernetes. @@ -219,7 +219,7 @@ vault-1 1/1 Running 0 1m49s vault-2 1/1 Running 0 1m49s ``` -#### Google KMS Auto Unseal +#### Google KMS auto unseal The Helm chart may be run with [Google KMS for Auto Unseal](/vault/docs/configuration/seal/gcpckms). This enables Vault server pods to @@ -228,7 +228,7 @@ auto unseal if they are rescheduled. Vault Helm requires the Google Cloud KMS credentials stored in `credentials.json` and mounted as a secret in each Vault server pod. -##### Create the Secret +##### Create the secret First, create the secret in Kubernetes: @@ -238,7 +238,7 @@ kubectl create secret generic kms-creds --from-file=credentials.json Vault Helm mounts this to `/vault/userconfig/kms-creds/credentials.json`. -##### Config Example +##### Config example This is a Vault Helm configuration that uses Google KMS: @@ -289,7 +289,7 @@ server: } ``` -#### Amazon KMS Auto Unseal +#### Amazon KMS auto unseal The Helm chart may be run with [AWS KMS for Auto Unseal](/vault/docs/configuration/seal/awskms). This enables Vault server pods to auto @@ -298,7 +298,7 @@ unseal if they are rescheduled. Vault Helm requires the AWS credentials stored as environment variables that are defined in each Vault server pod. -##### Create the Secret +##### Create the secret First, create a secret with your KMS access key/secret: @@ -308,7 +308,7 @@ $ kubectl create secret generic kms-creds \ --from-literal=AWS_SECRET_ACCESS_KEY="${AWS_SECRET_ACCESS_KEY?}" ``` -##### Config Example +##### Config example This is a Vault Helm configuration that uses AWS KMS: @@ -368,7 +368,7 @@ server: Using this customized probe, a `postStart` script could automatically run once the pod is ready for additional setup. -### Upgrading Vault on Kubernetes +### Upgrading Vault on kubernetes To upgrade Vault on Kubernetes, we follow the same pattern as [generally upgrading Vault](/vault/docs/upgrading), except we can use @@ -388,7 +388,7 @@ structure that make the data incompatible with a downgrade. If you need to roll back to a previous version of Vault, you should roll back your data store as well. -#### Upgrading Vault Servers +#### Upgrading Vault servers !> **IMPORTANT NOTE:** Helm will install the latest chart found in a repo by default. It's recommended to specify the chart version when upgrading. @@ -482,7 +482,7 @@ $ kubectl exec -ti -- vault operator unseal After a few moments the Vault cluster should elect a new active primary. The Vault cluster is now upgraded! -### Protecting Sensitive Vault Configurations +### Protecting sensitive Vault configurations Vault Helm renders a Vault configuration file during installation and stores the file in a Kubernetes configmap. Some configurations require sensitive data to be @@ -536,7 +536,7 @@ that eases operating a Vault cluster and we document those below. The standard [production deployment](/vault/tutorials/operations/production-hardening) tutorial is still an important read even if running Vault within Kubernetes. -### Production Deployment Checklist +### Production deployment checklist _End-to-End TLS._ Vault should always be used with TLS in production. If intermediate load balancers or reverse proxies are used to front Vault, diff --git a/website/content/docs/platform/k8s/helm/terraform.mdx b/website/content/docs/platform/k8s/helm/terraform.mdx index 8e0f8ec3db9c..4a77b1071153 100644 --- a/website/content/docs/platform/k8s/helm/terraform.mdx +++ b/website/content/docs/platform/k8s/helm/terraform.mdx @@ -6,7 +6,7 @@ description: |- Describes how to configure the Vault Helm chart using Terraform --- -# Configuring Vault Helm with Terraform +# Configuring Vault helm with terraform Terraform may also be used to configure and deploy the Vault Helm chart, by using the [Helm provider](https://registry.terraform.io/providers/hashicorp/helm/latest/docs). @@ -65,7 +65,7 @@ resource "helm_release" "vault" { The values file can also be used directly in the Terraform configuration with the [`values` directive](https://registry.terraform.io/providers/hashicorp/helm/latest/docs/resources/release#values#values). -## Further Examples +## Further examples ### Vault config as a multi-line string diff --git a/website/content/docs/platform/k8s/index.mdx b/website/content/docs/platform/k8s/index.mdx index f1e09fb53be4..dbc5fdc48ab1 100644 --- a/website/content/docs/platform/k8s/index.mdx +++ b/website/content/docs/platform/k8s/index.mdx @@ -14,7 +14,7 @@ The Helm chart allows users to deploy Vault in various configurations: - High-Availability (HA): a cluster of Vault servers that use an HA storage backend such as Consul (default) - External: a Vault Agent Injector server that depends on an external Vault server -## Use Cases +## Use cases **Running a Vault Service:** The Vault server cluster can run directly on Kubernetes. This can be used by applications running within Kubernetes as well as external to @@ -40,7 +40,7 @@ to the Vault cluster which can be used to [store audit logs](/vault/docs/audit). native integrations provided by Vault itself, any other tool built for Kubernetes can choose to leverage Vault. -## Getting Started with Vault and Kubernetes +## Getting started with Vault and kubernetes There are several ways to try Vault with Kubernetes in different environments. @@ -54,24 +54,24 @@ There are several ways to try Vault with Kubernetes in different environments. - [Vault on Kubernetes Deployment Guide](/vault/tutorials/kubernetes/kubernetes-raft-deployment-guide) covers the steps required to install and configure a single HashiCorp Vault cluster as defined in the [Vault on Kubernetes Reference Architecture](/vault/tutorials/kubernetes/kubernetes-reference-architecture). -### High Level Comparison of Integrations +### High level comparison of integrations There are currently 3 different integrations to help Kubernetes workloads seamlessly consume secrets from Vault, without the need to modify the application to interact directly with Vault. Each integration addresses slightly different use-cases. The following is a brief overview of the strengths of each integration. -#### Agent Injector +#### Agent injector - No durable secret storage outside Vault. All secrets written to disk are in ephemeral in-memory volumes. - No highly privileged service accounts required. All secrets are fetched with the pod's own service account without the need for any other service accounts to impersonate it. - More mature solution, with proven production record and advanced features like templating, wider array of auth methods, etc. -#### Vault Secrets Operator +#### Vault secrets operator - More native UX for app developers. Workloads can mount Kubernetes secrets without adding any Vault-specific configuration. - Reduced load on Vault. Secrets are synced per CRD instead of per consuming pod. - Better Vault secret availability. Kubernetes secrets act as a durable cluster-local cache of Vault secrets. -#### Vault CSI Provider +#### Vault CSI provider - The CSI driver that the provider is based on is vendor neutral. - No durable secret storage outside Vault if the secret sync feature isn't used. All secrets written to disk are in ephemeral in-memory volumes. diff --git a/website/content/docs/platform/k8s/injector-csi.mdx b/website/content/docs/platform/k8s/injector-csi.mdx index 819e1d4fe961..9b54b8be2bb8 100644 --- a/website/content/docs/platform/k8s/injector-csi.mdx +++ b/website/content/docs/platform/k8s/injector-csi.mdx @@ -4,19 +4,19 @@ page_title: Agent Injector vs. Vault CSI Provider description: This section compares Sidecar Injector and Vault CSI Provider for Kubernetes and Vault integration. --- -# Agent Injector vs. Vault CSI Provider +# Agent injector vs. Vault CSI provider This document explores two different methods for integrating HashiCorp Vault with Kubernetes. The information provided is intended for DevOps practitioners who understand secret management concepts and are familiar with HashiCorp Vault and Kubernetes. This document also offers practical guidance to help you understand and choose the best method for your use case. Information contained within this document details the contrast between the Agent Injector, also referred as _Vault Sidecar_ or _Sidecar_ in this document, and the Vault Container Storage Interface (CSI) provider used to integrate Vault and Kubernetes. -## Vault Sidecar Agent Injector +## Vault sidecar agent injector The [Vault Sidecar Agent Injector](/vault/docs/platform/k8s/injector) leverages the [sidecar pattern](https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar) to alter pod specifications to include a Vault Agent container that renders Vault secrets to a shared memory volume. By rendering secrets to a shared volume, containers within the pod can consume Vault secrets without being Vault-aware. The injector is a Kubernetes mutating webhook controller. The controller intercepts pod events and applies mutations to the pod if annotations exist within the request. This functionality is provided by the [vault-k8s](https://github.com/hashicorp/vault-k8s) project and can be automatically installed and configured using the Vault Helm chart. ![Vault Sidecar Injection Workflow](/img/vault-sidecar-inject-workflow.png) -## Vault CSI Provider +## Vault CSI provider The [Vault CSI provider](/vault/docs/platform/k8s/csi) allows pods to consume Vault secrets by using ephemeral [CSI Secrets Store](https://github.com/kubernetes-sigs/secrets-store-csi-driver) volumes. At a high level, the CSI Secrets Store driver enables users to create `SecretProviderClass` objects. These objects define which secret provider to use and what secrets to retrieve. When pods requesting CSI volumes are made, the CSI Secrets Store driver sends the request to the Vault CSI provider if the provider is `vault`. The Vault CSI provider then uses the specified `SecretProviderClass` and the pod’s service account to retrieve the secrets from Vault and mount them into the pod’s CSI volume. Note that the secret is retrieved from Vault and populated to the CSI secrets store volume during the `ContainerCreation` phase. Therefore, pods are blocked from starting until the secrets are read from Vault and written to the volume. @@ -99,7 +99,7 @@ The below chart provides a high-level comparison between the two solutions. ![Comparison Chart](/img/comparison-table.png) -## Going Beyond the Native Kubernetes Secrets +## Going beyond the native kubernetes secrets On the surface, Kubernetes native secrets might seem similar to the two approaches presented above, but there are significant differences between them: @@ -113,7 +113,7 @@ On the surface, Kubernetes native secrets might seem similar to the two approach Designing secrets management in Kubernetes is an intricate task. There are multiple approaches, each with its own set of attributes. We recommend exploring the options presented in this document to increase your understanding of the internals and decide on the best option for your use case. -## Additional Resources +## Additional resources - [HashiCorp Vault: Delivering Secrets with Kubernetes](https://medium.com/hashicorp-engineering/hashicorp-vault-delivering-secrets-with-kubernetes-1b358c03b2a3) diff --git a/website/content/docs/platform/k8s/injector/annotations.mdx b/website/content/docs/platform/k8s/injector/annotations.mdx index 62f5b9a5e1d5..0dbc64169f13 100644 --- a/website/content/docs/platform/k8s/injector/annotations.mdx +++ b/website/content/docs/platform/k8s/injector/annotations.mdx @@ -10,7 +10,7 @@ The following are the available annotations for the injector. These annotations are organized into two sections: agent and vault. All of the annotations below change the configurations of the Vault Agent containers injected into the pod. -## Agent Annotations +## Agent annotations Agent annotations change the Vault Agent containers templating configuration. For example, agent annotations allow users to define what secrets they want, how to render @@ -232,7 +232,7 @@ them, optional commands to run, etc. - `vault.hashicorp.com/agent-init-json-patch` - same as `vault.hashicorp.com/agent-json-patch`, except that the JSON patch will be applied to the injected init container instead. -## Vault Annotations +## Vault annotations Vault annotations change how the Vault Agent containers communicate with Vault. For example, Vault's address, TLS certificates to use, client parameters such as timeouts, diff --git a/website/content/docs/platform/k8s/injector/examples.mdx b/website/content/docs/platform/k8s/injector/examples.mdx index 240922fe8a06..b9af233ed820 100644 --- a/website/content/docs/platform/k8s/injector/examples.mdx +++ b/website/content/docs/platform/k8s/injector/examples.mdx @@ -4,7 +4,7 @@ page_title: Vault Agent Sidecar Injector Examples description: This section documents examples of using the Vault Agent Injector. --- -# Vault Agent Injector Examples +# Vault agent injector examples The following are different configuration examples to support a variety of deployment models. @@ -13,7 +13,7 @@ deployment models. Ensure that the injector annotations are specified on the pod specification when using higher level constructs such as deployments, jobs or statefulsets. -## Before Using the Vault Agent Injector +## Before using the Vault agent injector Before applying Vault Agent injection annotations to pods, the following requirements should be satisfied. @@ -32,7 +32,7 @@ clusters](https://cloud.google.com/kubernetes-engine/docs/how-to/private-cluster the Kubernetes API will connect directly to the injector service endpoint, which is on port `8080`. -### Kubernetes and Vault Configuration +### Kubernetes and Vault configuration - Kubernetes auth method should be configured and enabled in Vault, - Pod should have a service account, @@ -51,7 +51,7 @@ owner of the pod. Check the following for errors: that owns the pod. - If the pod was created by a job, check the `job` for errors. -## Patching Existing Pods +## Patching existing pods To patch existing pods, a Kubernetes patch can be applied to add the required annotations to pods. When applying a patch, the pods will be rescheduled. @@ -140,7 +140,7 @@ spec: serviceAccountName: app-example ``` -## ConfigMap Example +## ConfigMap example The following example creates a deployment that mounts a Kubernetes ConfigMap containing Vault Agent configuration files. For a complete list of the Vault @@ -247,7 +247,7 @@ data: } ``` -## Environment Variable Example +## Environment variable example The following example demonstrates how templates can be used to create environment variables. A template should be created that exports a Vault secret as an environment @@ -292,7 +292,7 @@ spec: - containerPort: 9090 ``` -## AppRole Authentication +## AppRole authentication The following example demonstrates how the AppRole authentication method can be used by Vault Agent for retrieving secrets. A Kubernetes secret containing the AppRole secret ID @@ -341,7 +341,7 @@ spec: - containerPort: 9090 ``` -## PKI Cert Example +## PKI cert example The following example demonstrates how to use the [`pkiCert` function][pkiCert] and [`writeToFile` function][writeToFile] from consul-template to create two files diff --git a/website/content/docs/platform/k8s/injector/index.mdx b/website/content/docs/platform/k8s/injector/index.mdx index f55642978513..eafb61addf50 100644 --- a/website/content/docs/platform/k8s/injector/index.mdx +++ b/website/content/docs/platform/k8s/injector/index.mdx @@ -6,7 +6,7 @@ description: >- Vault Agent containers to pods for consuming Vault secrets. --- -# Agent Sidecar Injector +# Agent sidecar injector The Vault Agent Injector alters pod specifications to include Vault Agent containers that render Vault secrets to a shared memory volume using @@ -61,7 +61,7 @@ A service account must be present to use the Vault Agent Injector with the Kuber authentication method. It is _not_ recommended to bind Vault roles to the default service account provided to pods if no service account is defined. -### Requesting Secrets +### Requesting secrets There are two methods of configuring the Vault Agent containers to render secrets: @@ -70,7 +70,7 @@ There are two methods of configuring the Vault Agent containers to render secret Only one of these methods may be used at any time. -#### Secrets via Annotations +#### Secrets via annotations To configure secret injection using annotations, the user must supply: @@ -106,7 +106,7 @@ vault.hashicorp.com/role: 'app' The secret unique name must consist of alphanumeric characters, `.`, `_` or `-`. -##### Secret Templates +##### Secret templates ~> Vault Agent uses the Consul Template project to render secrets. For more information on writing templates, see the [Consul Template documentation](https://github.com/hashicorp/consul-template). @@ -171,12 +171,12 @@ username: v-kubernet-pg-app-q0Z7WPfVNqqTJuoDqCTY-1576529094 ~> Some secrets such as KV are stored in maps. Their data can be accessed using `.Data.data.` -### Renewals and Updating Secrets +### Renewals and updating secrets For more information on when Vault Agent fetches and renews secrets, see the [Agent documentation](/vault/docs/agent-and-proxy/agent/template#renewals-and-updating-secrets). -### Vault Agent Configuration Map +### Vault agent configuration map For advanced use cases, it may be required to define Vault Agent configuration files to mount instead of using secret and template annotations. The Vault Agent diff --git a/website/content/docs/platform/k8s/injector/installation.mdx b/website/content/docs/platform/k8s/injector/installation.mdx index 4cffe808b155..ae052dbbaad3 100644 --- a/website/content/docs/platform/k8s/injector/installation.mdx +++ b/website/content/docs/platform/k8s/injector/installation.mdx @@ -4,7 +4,7 @@ page_title: Agent Sidecar Injector Installation description: The Vault Agent Sidecar Injector can be installed using Vault Helm. --- -# Installing the Agent Injector +# Installing the agent injector The [Vault Helm chart](/vault/docs/platform/k8s/helm) is the recommended way to install and configure the Agent Injector in Kubernetes. @@ -32,7 +32,7 @@ Docs](/vault/docs/platform/k8s/helm/configuration). Commonly used values in the chart include limiting the namespaces the injector runs in, TLS options and more. -## TLS Options +## TLS options Admission webhook controllers require TLS to run within Kubernetes. The Injector defaults to supporting TLS 1.2 and above, and supports configuring the minimum @@ -80,7 +80,7 @@ For more information on configuring manual TLS, see the [Vault Helm cert values] This option may also be used in conjunction with [cert-manager for certificate management](/vault/docs/platform/k8s/helm/examples/injector-tls-cert-manager). -## Multiple Replicas and TLS +## Multiple replicas and TLS The Vault Agent Injector can be run with multiple replicas if using [Manual TLS](#manual-tls) or [cert-manager](/vault/docs/platform/k8s/helm/examples/injector-tls-cert-manager), and as of v0.7.0 multiple replicas are also supported with @@ -101,7 +101,7 @@ With Manual TLS and multiple replicas, [injector.leaderElector.enabled](/vault/docs/platform/k8s/helm/configuration#enabled-2) can be set to `false` since leader determination is not necessary in this case. -## Namespace Selector +## Namespace selector By default, the Vault Agent Injector will process all namespaces in Kubernetes except the system namespaces `kube-system` and `kube-public`. To limit what namespaces diff --git a/website/content/docs/platform/k8s/vso/api-reference.mdx b/website/content/docs/platform/k8s/vso/api-reference.mdx index a91f9f737105..16237412c6da 100644 --- a/website/content/docs/platform/k8s/vso/api-reference.mdx +++ b/website/content/docs/platform/k8s/vso/api-reference.mdx @@ -9,7 +9,7 @@ description: >- copied from docs/api/api-reference.md in the vault-secrets-operator repo. commit SHA=90ae1b3095c65c1e3eeec157971bd6a3e2c3f5e1 --> -# API Reference +# API reference ## Packages - [secrets.hashicorp.com/v1beta1](#secretshashicorpcomv1beta1) @@ -19,7 +19,7 @@ description: >- Package v1beta1 contains API Schema definitions for the secrets v1beta1 API group -### Resource Types +### Resource types - [VaultAuth](#vaultauth) - [VaultAuthList](#vaultauthlist) - [VaultConnection](#vaultconnection) diff --git a/website/content/docs/platform/k8s/vso/examples.mdx b/website/content/docs/platform/k8s/vso/examples.mdx index 020cca360981..51c8cefe7693 100644 --- a/website/content/docs/platform/k8s/vso/examples.mdx +++ b/website/content/docs/platform/k8s/vso/examples.mdx @@ -5,7 +5,7 @@ description: >- The Vault Secrets Operator allows Pods to consume Vault secrets natively from Kubernetes Secrets. --- -# Vault Secrets Operator Examples +# Vault secrets operator examples The Operator project provides the following examples: - Sample use-cases are documented [here](https://github.com/hashicorp/vault-secrets-operator#samples) diff --git a/website/content/docs/platform/k8s/vso/helm.mdx b/website/content/docs/platform/k8s/vso/helm.mdx index ae150e35d0d8..2fabbcb3602c 100644 --- a/website/content/docs/platform/k8s/vso/helm.mdx +++ b/website/content/docs/platform/k8s/vso/helm.mdx @@ -5,7 +5,7 @@ description: >- Configuration for the Vault Secrets Operator Helm chart. --- -# Vault Secrets Operator Helm Chart +# Vault secrets operator helm chart The chart is customizable using [Helm configuration values](https://helm.sh/docs/intro/using_helm/#customizing-the-chart-before-installing). @@ -14,7 +14,7 @@ The chart is customizable using the vault-secrets-operator repo's values.yaml: file commit=e9c2b499105d977fa23a9f746186253991ebcee1 --> -## Top-Level Stanzas +## Top-Level stanzas Use these links to navigate to a particular top-level stanza. @@ -25,7 +25,7 @@ Use these links to navigate to a particular top-level stanza. - [`telemetry`](#h-telemetry) - [`tests`](#h-tests) -## All Values +## All values ### controller ((#h-controller)) @@ -412,7 +412,7 @@ Use these links to navigate to a particular top-level stanza. -## Helm Chart Examples +## Helm chart examples The below `config.yaml` results in a single replica installation of the Vault Secrets Operator with a default vault connection and auth method custom resource deployed. @@ -431,7 +431,7 @@ defaultAuthMethod: ``` -## Customizing the Helm Chart +## Customizing the helm chart If you need to extend the Helm chart with additional options, we recommend using a third-party tool, such as [kustomize](https://github.com/kubernetes-sigs/kustomize) using the project repo `config/` path diff --git a/website/content/docs/platform/k8s/vso/index.mdx b/website/content/docs/platform/k8s/vso/index.mdx index c1091edb05ff..796e7cd29fd8 100644 --- a/website/content/docs/platform/k8s/vso/index.mdx +++ b/website/content/docs/platform/k8s/vso/index.mdx @@ -5,7 +5,7 @@ description: >- The Vault Secrets Operator allows Pods to consume Vault secrets natively from Kubernetes Secrets. --- -# Vault Secrets Operator +# Vault secrets operator The Vault Secrets Operator (VSO) allows Pods to consume Vault secrets natively from Kubernetes Secrets. @@ -34,7 +34,7 @@ The following features are supported by the Vault Secrets Operator: - Support for installing using: `Helm` or `Kustomize`
*see the [installation](/vault/docs/platform/k8s/vso/installation) docs for more details* -## Supported Vault Versions +## Supported Vault versions - Vault OSS 1.11+ - Vault Enterprise 1.11+ @@ -42,7 +42,7 @@ The following features are supported by the Vault Secrets Operator: @include 'kubernetes-supported-versions.mdx' -## Supported Cloud Providers +## Supported Cloud providers The Vault Secrets Operator has been tested successfully in the following hosted Kubernetes environments: - Amazon Elastic Kubernetes Service (EKS) @@ -54,12 +54,12 @@ Basic integration tests are available in the project repository. Please report any incompatibilities via a [Github Issue](https://github.com/hashicorp/vault-secrets-operator/issues). -## Vault Access and Custom Resource Definitions +## Vault access and custom resource definitions The Vault connection and authentication configuration is provided by the `VaultConnection` and `VaultAuth` CRDs. These can be considered as foundational Custom Resources that all secret replication type resources will reference. -### VaultConnection Custom Resource +### VaultConnection custom resource Provides the configuration necessary for the Operator to connect to a single Vault server instance. @@ -86,7 +86,7 @@ spec: # caCertSecretRef: "" ``` -### VaultAuth Custom Resource +### VaultAuth custom resource Provide the configuration necessary for the Operator to authenticate to a single Vault server instance as specified in a `VaultConnection` Custom Resource. @@ -125,12 +125,12 @@ spec: # headers: [] ``` -## Vault Secret Custom Resource Definitions +## Vault secret custom resource definitions Provide the configuration necessary for the Operator to replicate a single Vault Secret to a single Kubernetes Secret. Each supported CRD is specialized to a *class* of Vault secret, documented below. -### VaultStaticSecret Custom Resource +### VaultStaticSecret custom resource Provides the configuration necessary for the Operator to synchronize a single Vault *static* Secret to a single Kubernetes Secret.
Supported secrets engines: [kv-v2](/vault/docs/secrets/kv/kv-v2), [kv-v1](/vault/docs/secrets/kv/kv-v1) @@ -180,7 +180,7 @@ spec: name: static-secret2 ``` -### VaultPKISecret Custom Resource +### VaultPKISecret custom resource Provides the configuration necessary for the Operator to synchronize a single Vault *PKI* Secret to a single Kubernetes Secret.
Supported secrets engines: [pki](/vault/docs/secrets/pki) @@ -207,7 +207,7 @@ spec: name: pki1 ``` -### VaultDynamicSecret Custom Resource +### VaultDynamicSecret custom resource Provides the configuration necessary for the Operator to synchronize a single Vault *dynamic* Secret to a single Kubernetes Secret.
Supported secrets engines *non-exhaustive*: [databases](/vault/docs/secrets/databases), [aws](/vault/docs/secrets/aws), diff --git a/website/content/docs/platform/k8s/vso/installation.mdx b/website/content/docs/platform/k8s/vso/installation.mdx index f2ee045e4d34..b06a815af8b2 100644 --- a/website/content/docs/platform/k8s/vso/installation.mdx +++ b/website/content/docs/platform/k8s/vso/installation.mdx @@ -5,7 +5,7 @@ description: >- The Vault Secrets Operator can be installed using Helm. --- -# Installing the Vault Secrets Operator +# Installing the Vault secrets operator ## Prerequisites @@ -43,5 +43,5 @@ always run Helm with `--dry-run` before any install or upgrade to verify changes. -### Helm Chart Values +### Helm chart values All supported Helm chart values can be found [here](/vault/docs/platform/k8s/vso/helm) diff --git a/website/content/docs/platform/mssql/changelog.mdx b/website/content/docs/platform/mssql/changelog.mdx index 41f362dbf93b..0bec1f551a16 100644 --- a/website/content/docs/platform/mssql/changelog.mdx +++ b/website/content/docs/platform/mssql/changelog.mdx @@ -4,7 +4,7 @@ page_title: Vault EKM Provider Release Notes description: Release notes for the Vault EKM Provider for Microsoft SQL Server. --- -# Release Notes +# Release notes Each version is available to download from the [releases](https://releases.hashicorp.com/vault-mssql-ekm-provider/) page. diff --git a/website/content/docs/platform/mssql/configuration.mdx b/website/content/docs/platform/mssql/configuration.mdx index 36a5e1a19e6d..a19efdd62a2b 100644 --- a/website/content/docs/platform/mssql/configuration.mdx +++ b/website/content/docs/platform/mssql/configuration.mdx @@ -4,7 +4,7 @@ page_title: Configure the Vault EKM Provider description: Configuration options for the Vault EKM Provider for Microsoft SQL Server. --- -# Configuring the Vault EKM Provider +# Configuring the Vault EKM provider Configuration is stored in a `config.json` file under ProgramData in a path that mirrors the installation folder. This defaults to diff --git a/website/content/docs/platform/mssql/index.mdx b/website/content/docs/platform/mssql/index.mdx index 094658738959..6b9c549d7b37 100644 --- a/website/content/docs/platform/mssql/index.mdx +++ b/website/content/docs/platform/mssql/index.mdx @@ -5,7 +5,7 @@ description: >- The Vault EKM module for Microsoft SQL Server allows Vault to act as a provider for TDE. --- -# Vault EKM provider for SQL Server +# Vault EKM provider for SQL server -> **Note**: This feature requires [Vault Enterprise](https://www.hashicorp.com/products/vault/) with the Advanced Data Protection Key Management module. diff --git a/website/content/docs/platform/mssql/installation.mdx b/website/content/docs/platform/mssql/installation.mdx index c30c44dc2261..4c0d5b2afe88 100644 --- a/website/content/docs/platform/mssql/installation.mdx +++ b/website/content/docs/platform/mssql/installation.mdx @@ -4,7 +4,7 @@ page_title: Install the Vault EKM Provider description: Installation steps for the Vault EKM Provider for Microsoft SQL Server. --- -# Installing the Vault EKM Provider +# Installing the Vault EKM provider This guide assumes you are installing the Vault EKM Provider for the first time. For upgrade instructions, see [upgrading](/vault/docs/platform/mssql/upgrading). @@ -88,7 +88,7 @@ EKM provider to use it. EOF ``` -## Configuring SQL Server +## Configuring SQL server The remaining steps are all run on the database server. @@ -213,7 +213,7 @@ installation. ``` -## Key Rotation +## Key rotation Both the database encryption key and Vault Transit's asymmetric key can be rotated independently. diff --git a/website/content/docs/platform/mssql/troubleshooting.mdx b/website/content/docs/platform/mssql/troubleshooting.mdx index 3d233cb1debb..534b6273764c 100644 --- a/website/content/docs/platform/mssql/troubleshooting.mdx +++ b/website/content/docs/platform/mssql/troubleshooting.mdx @@ -4,9 +4,9 @@ page_title: Troubleshoot the Vault EKM Provider description: Troubleshooting steps for the Vault EKM Provider for Microsoft SQL Server. --- -# Troubleshooting the Vault EKM Provider +# Troubleshooting the Vault EKM provider -## Check Windows Event Logs +## Check windows event logs Logs from the Vault EKM provider will appear in Windows Event Viewer under "Windows Logs" > "Application" with source "Transit Vault EKM Provider". @@ -19,7 +19,7 @@ your issue, you can [enable trace logging](/vault/docs/platform/mssql/configurat Restart SQL Server for the config change to take effect, and you should see more detailed logs in the same section of Windows Event Viewer. -## Check SQL Server error logs +## Check SQL server error logs If the Vault EKM provider is not generating event logs, you may find some information in the SQL Server's error logs. Check for an event with ID @@ -45,11 +45,11 @@ certutil -f -ent -AddStore Root .\certs\ddfb16cd4931c973a2037d3fc83a4d7d775d05e4 Remove-Item -Recurse .\certs\ ``` -## Error Codes +## Error codes During installation, the EKM provider registers a manifest of coded event logs to aid debugging. You may see the following error codes during operation. -### 2050 License error +### 2050 license error The EKM provider was unable to verify that Vault has the correct license features. This could be due to: diff --git a/website/content/docs/platform/mssql/upgrading.mdx b/website/content/docs/platform/mssql/upgrading.mdx index 8a083bd7f94d..54956c98471f 100644 --- a/website/content/docs/platform/mssql/upgrading.mdx +++ b/website/content/docs/platform/mssql/upgrading.mdx @@ -4,7 +4,7 @@ page_title: Upgrade the Vault EKM Provider description: Upgrade steps for the Vault EKM Provider for Microsoft SQL Server. --- -# Upgrading the Vault EKM Provider +# Upgrading the Vault EKM provider ~> **Note:** The upgrade process will put the database into maintenance mode and require a restart. It is highly recommended to test this procedure in a diff --git a/website/content/docs/platform/servicenow/configuration.mdx b/website/content/docs/platform/servicenow/configuration.mdx index 22ebd9bbf20c..2126f6d38f1a 100644 --- a/website/content/docs/platform/servicenow/configuration.mdx +++ b/website/content/docs/platform/servicenow/configuration.mdx @@ -4,7 +4,7 @@ page_title: Configure Vault ServiceNow Credential Resolver description: This section documents the configurables for the Vault ServiceNow Credential Resolver. --- -# Configuring the Vault Credential Resolver +# Configuring the Vault credential resolver ## MID server properties diff --git a/website/content/docs/platform/servicenow/index.mdx b/website/content/docs/platform/servicenow/index.mdx index 8af7b938a367..9c0c02af078a 100644 --- a/website/content/docs/platform/servicenow/index.mdx +++ b/website/content/docs/platform/servicenow/index.mdx @@ -5,7 +5,7 @@ description: >- The Vault Credential Resolver allows ServiceNow MID servers to use Vault as an enterprise-grade external secret store. --- -# Vault Credential Resolver +# Vault credential resolver ServiceNow® MID servers can use the Vault Credential Resolver to consume secrets directly from Vault for the purpose of performing discovery. See diff --git a/website/content/docs/platform/servicenow/installation.mdx b/website/content/docs/platform/servicenow/installation.mdx index a257dd9d3e04..dc01ec8cb6e7 100644 --- a/website/content/docs/platform/servicenow/installation.mdx +++ b/website/content/docs/platform/servicenow/installation.mdx @@ -4,7 +4,7 @@ page_title: Install Vault ServiceNow Credential Resolver description: Installation steps for the Vault ServiceNow Credential Resolver. --- -# Installing the Vault Credential Resolver +# Installing the Vault credential resolver ## Prerequisites @@ -13,7 +13,7 @@ description: Installation steps for the Vault ServiceNow Credential Resolver. * Discovery and external credential plugins activated on ServiceNow * Working Vault deployment accessible from the MID server -## Installing Vault Agent +## Installing Vault agent * Select your desired auth method from Agent's [supported auth methods](/vault/docs/agent-and-proxy/autoauth/methods) and set it up in Vault diff --git a/website/content/docs/platform/servicenow/troubleshooting.mdx b/website/content/docs/platform/servicenow/troubleshooting.mdx index 1f976a9ae524..c462a1740586 100644 --- a/website/content/docs/platform/servicenow/troubleshooting.mdx +++ b/website/content/docs/platform/servicenow/troubleshooting.mdx @@ -23,7 +23,7 @@ or if it couldn't communicate with Vault. [log files]: https://docs.servicenow.com/bundle/quebec-servicenow-platform/page/product/mid-server/reference/r_MIDServerTroubleshooting.html -## Use the Test credential feature +## Use the test credential feature When creating or configuring a credential in the ServiceNow UI, you should be able to click "Test credential" to perform a quick targeted test. Select the diff --git a/website/content/docs/plugins/index.mdx b/website/content/docs/plugins/index.mdx index 9e1783566f09..4556f37d9c54 100644 --- a/website/content/docs/plugins/index.mdx +++ b/website/content/docs/plugins/index.mdx @@ -5,7 +5,7 @@ description: Learn about Vault's plugin system. --- -# Plugin System +# Plugin system Vault supports 3 types of plugins; auth methods, secret engines, and database plugins. This concept allows both built-in and external plugins to be treated @@ -21,12 +21,12 @@ be registered. See [Plugin Upgrade Procedure](/vault/docs/upgrading/plugins#plugin-upgrade-procedure) for details on how to upgrade a built-in plugin in-place. -## Built-In Plugins +## Built-In plugins Built-in plugins are shipped with Vault, often for commonly used integrations, and can be used without any prerequisite steps. -## External Plugins +## External plugins External plugins are not shipped with Vault and require additional operator intervention to run. @@ -45,7 +45,7 @@ reused across all mounts of a given type. -> **NOTE:** See the [Vault Integrations](/vault/integrations) page to find a curated collection of official, partner, and community Vault plugins. -## Plugin Versioning +## Plugin versioning Vault supports managing, running and upgrading plugins using semantic version information. @@ -62,7 +62,7 @@ for any available plugins whose type and name match: * The plugin with the most recent semantic version among any registered versions * The plugin built into Vault -### Built-In Versions +### Built-In versions Vault will report a version for built-in plugins to indicate what version of the plugin code got built into Vault as a dependency. For example: diff --git a/website/content/docs/plugins/plugin-architecture.mdx b/website/content/docs/plugins/plugin-architecture.mdx index efcbfbbad586..6c02d1808b82 100644 --- a/website/content/docs/plugins/plugin-architecture.mdx +++ b/website/content/docs/plugins/plugin-architecture.mdx @@ -4,7 +4,7 @@ page_title: External Plugin Architecture description: Learn about Vault's plugin architecture. --- -# External Plugin Architecture +# External plugin architecture Vault's external plugins are completely separate, standalone applications that Vault executes and communicates with over RPC. This means the plugin process does not @@ -19,7 +19,7 @@ when enabling it. -> **NOTE:** See the [Vault Integrations](/vault/integrations) page to find a curated collection of official, partner, and community Vault plugins. -## External Plugin Lifecycle +## External plugin lifecycle Vault external plugins are long-running processes that remain running once they are spawned by Vault, the parent process. Plugin processes can be started by Vault's @@ -46,7 +46,7 @@ plugins, these processes should not be terminated by anything other than Vault. If a plugin process is shutdown out-of-band, the plugin process will be lazily loaded when a request that requires the plugin is received by Vault. -### External Plugin Scaling Characteristics +### External plugin scaling characteristics External plugins can leverage [Performance Standbys](/vault/docs/enterprise/performance-standby) without any explicit action by a plugin author. The default behavior of Vault @@ -57,7 +57,7 @@ code will then forward the full original request transparently to the active node. In other words, plugins can scale horizontally on Vault Enterprise without any effort on the plugin author's part. -## Plugin Communication +## Plugin communication Vault communicates with external plugins over RPC. To secure this communication, Vault creates a mutually authenticated TLS connection with the @@ -74,14 +74,14 @@ detection (e.g. Consul), Vault will automatically attempt to determine the ~> Note: Prior to Vault version 1.9.2, reading the original connection's TLS connection state is not supported in plugins. -## Plugin Registration +## Plugin registration An important consideration of Vault's plugin system is to ensure the plugin invoked by Vault is authentic and maintains integrity. There are two components that a Vault operator needs to configure before external plugins can be run- the plugin directory and the plugin catalog entry. -### Plugin Directory +### Plugin directory The plugin directory is a configuration option of Vault and can be specified in the [configuration file](/vault/docs/configuration). @@ -93,7 +93,7 @@ added to Vault. @include 'plugin-file-permissions-check.mdx' -### Plugin Catalog +### Plugin catalog The plugin catalog is Vault's list of approved plugins. The catalog is stored in Vault's barrier and can only be updated by a Vault user with sudo permissions. @@ -126,7 +126,7 @@ $ vault write sys/plugins/catalog/database/myplugin-database-plugin \ Success! Data written to: sys/plugins/catalog/database/myplugin-database-plugin ``` -### Plugin Execution +### Plugin execution When a backend wants to run a plugin, it first looks up the plugin, by name, in the catalog. It then checks the executable's SHA256 sum against the one @@ -138,13 +138,13 @@ settings. Like Vault, plugins support [the use of mlock when available](/vault/d and each plugin executable in your [plugins directory](/vault/docs/plugins/plugin-architecture#plugin-directory) must be given the ability to use the `mlock` syscall. -### Plugin Upgrades +### Plugin upgrades External plugins may be updated by registering and reloading them. More details on the upgrade procedure can be found in [Upgrading Vault Plugins](/vault/docs/upgrading/plugins). -## Plugin Multiplexing +## Plugin multiplexing To avoid spawning multiple plugin processes for mounts of the same type, plugins can implement plugin multiplexing. This allows a single diff --git a/website/content/docs/plugins/plugin-development.mdx b/website/content/docs/plugins/plugin-development.mdx index bc1bd831d861..3448b6ca5182 100644 --- a/website/content/docs/plugins/plugin-development.mdx +++ b/website/content/docs/plugins/plugin-development.mdx @@ -4,7 +4,7 @@ page_title: Plugin Development description: Learn about Vault plugin development. --- -# Plugin Development +# Plugin development ~> Advanced topic! Plugin development is a highly advanced topic in Vault, and is not required knowledge for day-to-day usage. If you don't plan on writing any @@ -31,9 +31,9 @@ backend running the plugin. ~> Note: Plugins should be prepared to handle multiple concurrent requests from Vault. -## Serving A Plugin +## Serving a plugin -### Serving A Plugin with Multiplexing +### Serving a plugin with multiplexing ~> Plugin multiplexing requires `github.com/hashicorp/vault/sdk v0.5.4` or above. @@ -75,7 +75,7 @@ func main() { And that's basically it! You would just need to change `myPlugin` to your actual plugin. -## Plugin Backwards Compatibility with Vault +## Plugin backwards compatibility with Vault Let's take a closer look at a snippet from the above main package. @@ -113,7 +113,7 @@ instead implement the [`PluginVersioner`](https://github.com/hashicorp/vault/blob/sdk/v0.6.0/sdk/logical/logical.go#L150-L154) interface directly. -## Building a Plugin from Source +## Building a plugin from source To build a plugin from source, first navigate to the location holding the desired plugin version. Next, run `go build` to obtain a new binary for the @@ -121,7 +121,7 @@ plugin. Finally, [register](/vault/docs/plugins/plugin-architecture#plugin-registration) the plugin and enable it. -## Plugin Development - Resources +## Plugin development - resources For more information on how to register and enable your plugin, refer to the [Building Plugin Backends](/vault/tutorials/app-integration/plugin-backends) @@ -132,7 +132,7 @@ Other HashiCorp plugin development resources: * [vault-auth-plugin-example](https://github.com/hashicorp/vault-auth-plugin-example) * [Custom Secrets Engines](/vault/tutorials/custom-secrets-engine) -### Plugin Development - Resources - Community +### Plugin development - resources - community See the [Vault Integrations](/vault/integrations) page to find Community plugin examples/guides developed by community members. HashiCorp does not diff --git a/website/content/docs/plugins/plugin-management.mdx b/website/content/docs/plugins/plugin-management.mdx index 1f949babc504..298d6c0735d7 100644 --- a/website/content/docs/plugins/plugin-management.mdx +++ b/website/content/docs/plugins/plugin-management.mdx @@ -6,7 +6,7 @@ description: >- plugin system. --- -# Plugin Management +# Plugin management External plugins are the components in Vault that can be implemented separately from Vault's built-in plugins. These plugins can be either authentication or @@ -20,7 +20,7 @@ Consul), Vault will automatically attempt to determine the `api_addr` as well. Detailed information regarding the plugin system can be found in the [internals documentation](/vault/docs/plugins). -## Registering External Plugins +## Registering external plugins Before an external plugin can be mounted, it needs to be [registered](/vault/docs/plugins/plugin-architecture#plugin-registration) in the @@ -35,7 +35,7 @@ $ vault plugin register -sha256= \ Success! Registered plugin: passthrough-plugin ``` -## Enabling/Disabling External Plugins +## Enabling/Disabling external plugins After the plugin is registered, it can be mounted by specifying the registered plugin name: @@ -60,7 +60,7 @@ Disabling an external plugins is identical to disabling a built-in plugin: $ vault secrets disable my-secrets ``` -## Upgrading Plugins +## Upgrading plugins Upgrade instructions can be found in the [Upgrading Plugins - Guides][upgrading_plugins] page. diff --git a/website/content/docs/release-notes/1.10.0.mdx b/website/content/docs/release-notes/1.10.0.mdx index bff701f24213..3f169e3b9ec8 100644 --- a/website/content/docs/release-notes/1.10.0.mdx +++ b/website/content/docs/release-notes/1.10.0.mdx @@ -5,7 +5,7 @@ description: |- This page contains release notes for Vault 1.10.0 --- -# Vault 1.10.0 Release notes +# Vault 1.10.0 release notes **Software Release date:** Mar 23, 2022 @@ -22,11 +22,11 @@ Some of these enhancements and changes in this release include: - Support of PKCE on Vault’s OIDC auth method with Telemetry support for the Vault Agent. - Improvement of key areas and parity to support using Terraform Provider with Vault. -## New Features +## New features This section describes the new features introduced as part of Vault -### Multi-Factor Authentication (MFA) for Vault OSS +### Multi-Factor authentication (MFA) for Vault OSS Vault has had support for the [Step-up Enterprise MFA](/vault/docs/enterprise/mfa) as part of its Enterprise edition. The Step-up Enterprise MFA allows having an MFA on login, or for step-up access to sensitive resources in Vault. @@ -40,43 +40,43 @@ Refer to the [Login MFA FAQ](/vault/docs/auth/login-mfa/faq) to understand the v Vault’s support to act as an OIDC provider is now generally available. Furthermore, Vault’s OIDC provider functionality can now support PKCE for authorization code flow as well. Thanks to all the excellent community feedback received, we have simplified the user experience around configuration of OIDC provider functionality. -### Caching support for Vault Lambda Extension +### Caching support for Vault lambda extension With 0.6.0, Vault Lambda Extension supports [caching](https://github.com/hashicorp/vault-lambda-extension#caching) in the local proxy server to avoid proxying every request to enable setting expiry time and invalidate cache, as needed. -### Terraform Provider for Vault +### Terraform provider for Vault We have introduced three new resources to enable configuration of the [KMIP secrets engine](https://registry.terraform.io/providers/hashicorp/vault/latest/docs/resources/kmip_secret_backend) using the Terraform Provider for Vault. In addition, frequent releases on the Terraform Provider for Vault have been incorporating the ability to configure newer resources and data sources. Please read the [documentation](https://registry.terraform.io/providers/hashicorp/vault/latest/docs) for more details. -### KV Secrets Engine v2 patch operations +### KV secrets engine v2 patch operations We now support an additional method for managing [KV v2 secrets](/vault/api-docs/secret/kv/kv-v2) to maintain least privilege security in certain types of automated environments. This feature creates a new PATCH capability that enables partial updates to KV v2 secrets without requiring the READ privilege to the entire endpoint for an entity. -### DB2 Dynamic Secrets support +### DB2 dynamic secrets support Vault operators can leverage the openldap secrets engine to manage credentials for IBM DB2 and the LDAP security plugin for Db2. This allows Db2 to offload authentication and authorization to the LDAP security plugin and allows Vault to manage static credentials or even generate dynamic users. For more details, refer to the For more details, refer to the [IBM Db2 Credentials Management](/vault/tutorials/secrets-management/ibm-db2-openldap) tutorial. -### Temporal Transit Key rotation +### Temporal transit key rotation Proper key management includes occasionally rotating encryption keys to reduce the risks of a nonce reuse and opportunities for keys to be compromised. Previously, there was no automated way to rotate keys that is native to Vault. Now, we have provided a new configuration element on transit keys and tokenization transform configurations where a time interval triggers the keys to automatically rotate after the interval has lapsed. -### PKI HSM Forwarding +### PKI HSM forwarding To address security and compliance needs, customers may require that keys be either created or stored within Hardware Security Models (HSMs). Vault 1.10.0 introduces an accommodation for this requirement with regards to the PKI Secrets Engine. We now support offloading selected PKI operations to HSMs, in particular allowing customers to both generate new PKI key pairs and sign/verify some certificate workflows. All of these operations are conducted in a way that never allows the private key material to leave the secure confines of the HSM itself. -### AWS and AKV KMS Forwarding +### AWS and AKV KMS forwarding The work done above to support HSM-backed PKI operations inspired us to consider what other key possession paradigms we could support. This led us to extend the implementation to support Cloud Key Management Systems in addition to HSMs. In Vault 1.10.0, users may generate new PKI pairs and perform sign/verify certificate workflows, all with those keys never leaving the cloud KMS itself. Vault 1.10.0 provides support for AWS Key Management Service and Azure Key Vault Key Management Service. -### Server Side Consistent Tokens +### Server side consistent tokens Vault’s [eventual consistency](/vault/docs/enterprise/consistency) model precludes read-after-write guarantees when clients interact with performance standbys or performance replication clusters. The [Client Controlled Consistency](/vault/docs/enterprise/consistency#vault-1-7-mitigations) mitigations supported with Vault 1.7 provide ways to achieve consistency through client modifications or by using the agent for proxied requests, which is not possible in all cases. The Server Side Consistent Tokens feature provides an implicit way to achieve consistency by embedding the minimum Write-Ahead-Log state information in the Service tokens returned from logins or token-create requests. This feature introduces changes in the token format and the new tokesn will be the default tokens starting in Vault 1.10.0. Vault 1.10.0 is backwards compatible with old tokens. See [Replication](/vault/docs/configuration/replication), [Vault Eventual Consistency](/vault/docs/enterprise/consistency), [Upgrade to 1.10.0](/vault/docs/upgrading/upgrade-to-1.10.x) and [Server Side Consistent Token FAQ](/vault/docs/faq/ssct) to understand the various consistency options available with Vault 1.10.0 and the considerations to be aware of prior to selecting an option for your use case. -## Vault Agent Features +## Vault agent features -### Support for Telemetry +### Support for telemetry Starting with Vault 1.10.0, the Vault Agent supports a new metrics endpoint and [Telemetry](/vault/docs/agent#telemetry-stanza) metrics around run time, authentication success, authentication failures, cache hits, cache misses, proxy succes, and proxy client errors. This Vault Agent Telemetry should greatly help with the retrieval of key operational insights for Vault Agent deployments. @@ -88,27 +88,27 @@ With this [enhancement](/vault/docs/agent/autoauth/methods/azure), users can spe Previously, for instances where the Agent is a sidecar in a Kubernetes job and the job hangs, you must either use `shareProcessNamespace: true` for the container so that the process kill signals can be sent, or avoid the sidecar container entirely and solely rely on an init container. With this [enhancement](/vault/docs/agent#quit), we have added support for a Quit API endpoint to automatically shut down the Vault Agent, therefore eliminating the need to perform the workarounds. -## Other Features and Enhancements +## Other features and enhancements This section describes other features and enhancements introduced as part of the Vault 1.10.0 release. -### Client Count improvements +### Client count improvements We have introduced auth mount-based attribution of clients to help better understand where clients are being used within a cluster. This is available via UI and API. This is an enhancement on top of the namespace attribution capability we introduced in Vault 1.9. We have also introduced the ability to view changes to clients month over month via the client count API, and made other UI enhancements. Refer to [What is a Client?](/vault/docs/concepts/client-count) and [Client Count FAQ](/vault/docs/concepts/client-count/faq) for more details. -### Mount Migration +### Mount migration We have made improvements to the `sys/remount` API endpoint to simplify the complexities of moving data, such as secret engine and authentication method configuration from one mount to another, within a namespace or across namespaces. This can help with restructuring namespaces and mounts for various reasons, including migrating mounts from root to other namespaces when transitioning to using namespaces for the first time. For step-by-step instructions, refer to the [Mount Move](/vault/tutorials/enterprise/mount-move) tutorial. -### Scaling External Database plugins +### Scaling external database plugins Database plugins can now implement [plugin multiplexing](/vault/docs/plugins/plugin-architecture#plugin-multiplexing) which allows a single plugin process to be used for multiple database connections. Database plugin multiplexing will be enabled on the Oracle Database plugin starting in v0.6.0. We will extend this functionality to additional database plugins in subsequent releases. Any external database plugins that want to adopt multiplexing support will have to update their main.go call from [dbplugin.Serve()](https://github.com/hashicorp/vault/blob/sdk/v0.4.1/sdk/database/dbplugin/v5/plugin_server.go#L13) to [dbplugin.ServeMultiplex()](https://github.com/hashicorp/vault/blob/sdk/v0.4.1/sdk/database/dbplugin/v5/plugin_server.go#L42). Multiplexable database plugins are compatible with older versions of Vault down to Vault 1.6. Refer to this [Oracle Database PR](https://github.com/hashicorp/vault-plugin-database-oracle/pull/74) as an example of the upgrade process. -### Consul Secrets Engine enhancements +### Consul secrets engine enhancements Consul has supported [namespace](/consul/docs/enterprise/namespaces), [admin partitions](/consul/docs/enterprise/admin-partitions) and [ACL roles](/consul/commands/acl/role) for some time now. In this release we have added enhancements to the Consul Secrets engine to support namespace awareness and add admin partition and role support for Consul ACL tokens. This significantly simplifies the integrations for customers who want to achieve a zero trust security posture with both Vault and Consul. @@ -116,7 +116,7 @@ Consul has supported [namespace](/consul/docs/enterprise/namespaces), [admin par Prior to Vault 1.10.0, the Vault UI used localStorage to store authentication information. The data in localStorage was persisted in browsers and removed only on demand. Now, we have switched the Vault UI to use sessionStorage instead, which ensures that the authentication information is stored in the current browser tab alone, thereby improving security. -### Advanced I/O Handling for Transform FPE +### Advanced I/O handling for transform FPE The Transform Secrets Engine allows users to securely encrypt data while providing control over the output format. In Vault 1.9, we introduced [additional format fields](/vault/docs/release-notes/1.9.0#advanced-i-o-handling-for-tranform-fpe-adp-transform) on the templates used for this workflow. In Vault 1.10.0, we have now added those two new fields, `encode_format` and `decode_format`, to the Create Template page on the UI under Advanced Templating. @@ -146,7 +146,7 @@ We will have a fix for this issue in Vault 1.10.1. Until this issue is fixed, yo When a user has a policy that allows creating a secret engine but not reading it, after successful creation, the user sees a message `n is undefined` instead of a permissions error. We will have a fix for this issue in an upcoming minor release. -### Adding/Modifying Duo MFA method for Enterprise MFA triggers a panic error +### Adding/Modifying Duo MFA method for enterprise MFA triggers a panic error When adding or modifying a Duo MFA method for step-up Enterprise MFA using the `sys/mfa/method/duo` endpoint, a panic gets triggered due to a missing schema field. We will have a fix for this in Vault 1.10.1. Until this issue is fixed, avoid making any changes to your Duo configuration if you are upgrading Vault to v1.10.0. @@ -161,10 +161,10 @@ There is a workaround for this error that will allow you to sign in to Vault usi auth method. Select the "Other" tab instead of selecting the specific OIDC auth mount tab. From there, select "OIDC" from the "Method" select box and proceed to sign in to Vault. -### Error Initializing Raft Storage type with Windows +### Error initializing raft storage type with windows When trying to start Vault server 1.10.0 on Windows, and there is less than 100GB of free disk space, there is an initialization error with raft DB related to insufficient space on the disk. See this [issue](https://github.com/hashicorp/vault/issues/14895) for details. Windows users should wait till 1.10.1 to upgrade. -## Feature Deprecations and EOL +## Feature deprecations and EOL Please refer to the [Deprecation Plans and Notice](/vault/docs/deprecation) page for up-to-date information on feature deprecations and plans. An [Feature Deprecation FAQ](/vault/docs/deprecation/faq) page is also available to address questions concerning decisions made about Vault feature deprecations. diff --git a/website/content/docs/release-notes/1.11.0.mdx b/website/content/docs/release-notes/1.11.0.mdx index 46391667445f..5e6db5a2d22b 100644 --- a/website/content/docs/release-notes/1.11.0.mdx +++ b/website/content/docs/release-notes/1.11.0.mdx @@ -5,7 +5,7 @@ description: |- This page contains release notes for Vault 1.11.0 --- -# Vault 1.11.0 Release Notes +# Vault 1.11.0 release notes **Software Release date:** June 21, 2022 @@ -26,7 +26,7 @@ Some of these enhancements and changes in this release include: - Plugin Multiplexing support is extended to secret and auth plugins, allowing them to be managed more efficiently with a single process -## New Features +## New features This section describes the new features introduced as part of Vault 1.11.0. @@ -35,11 +35,11 @@ This section describes the new features introduced as part of Vault 1.11.0. The GCP auth method only allows for public API endpoints to be configured for authentication purposes. Workloads running in GCP that do not have external internet access need the ability to authenticate using [Private Google Access](https://cloud.google.com/vpc/docs/private-google-access#pga). In Vault 1.11.0, we allow for customization of certain service endpoints. For more information, refer to the [GCP auth method](/vault/api-docs/auth/gcp#custom_endpoint) documentation. -### Support for key/pair based authentication for Snowflake +### Support for key/pair based authentication for snowflake In Vault 1.11.0, the Snowflake Database Engine supports an additional credential type that can be generated. For users not wanting to rely on the standard user/pass authentication to Snowflake, Vault can now dynamically generate RSA key pairs that allow users to authenticate into Snowflake. For more information, refer to the [Snowflake Database Secrets Engine](/vault/docs/secrets/databases/snowflake) and [Database Secrets Engine (API)](/vault/api-docs/secret/databases) documentation. -### Dynamic Kubernetes service account secrets +### Dynamic kubernetes service account secrets Kubernetes service accounts must be manually generated and passed to a Kubernetes configuration file or the command line using a CLI tool such as kubectl to interact with Kubernetes clusters. With this method, service account credentials, which contain static secrets, can be exposed and would require a periodic manual rotation. To address this issue, we now support generating short-lived dynamic service accounts and associate role bindings to specific Kubernetes namespaces. For more information, refer to the [Kubernetes Auth Method](/vault/docs/auth/kubernetes) and [Kubernetes Auth Method (API)](/vault/api-docs/auth/kubernetes) documentation. @@ -53,15 +53,15 @@ The KV version 2 secrets engine now includes a set of utilities and enhancements For more details, refer to the [Version Key/Value Secrets Engine](/vault/tutorials/secrets-management/versioned-kv) tutorial. -### Support for node identity and service identity for Vault Consul secrets engine +### Support for node identity and service identity for Vault consul secrets engine Within the Consul secrets engine, practitioners writing a Vault role can specify node-identity or service-identity. You can also specify multiples of each identity on a Vault role. For more information, refer to the [Consul Secrets Engine](/vault/docs/secrets/consul) and [Consul Secrets Engine (API)](/vault/api-docs/secret/consul) documentation. -### Autopilot (Vault Enterprise) +### Autopilot (Vault enterprise) Vault release 1.7 introduced the Autopilot feature to Integrated Storage. In this release, new Autopilot features are added to Vault Enterprise to perform seamless automatic upgrades and support redundancy zones for improved cluster resiliency. Refer to the [autopilot endpoint](/vault/api-docs/system/storage/raftautopilot#sys-storage-raft-autopilot), [operator raft](/vault/docs/commands/operator/raft), [Autopilot](/vault/docs/concepts/integrated-storage/autopilot), [Automated Upgrades](/vault/docs/enterprise/automated-upgrades), and [Redundancy Zones](/vault/docs/enterprise/redundancy-zones) documentation for more information. -## Other Features and Enhancements +## Other features and enhancements This section describes other features and enhancements introduced as part of the Vault 1.11.0 release. @@ -69,26 +69,26 @@ This section describes other features and enhancements introduced as part of the Historically, Vault has only allowed the Transit secrets engine to utilize keys that were created by Vault itself. In this release, we have introduced an import feature for the Transit secrets engine that enables individuals to bring externally-generated encryption keys into a Transit keyring. These keys can then be used identically to internally-generated Transit keys. -### Improved CA Rotation +### Improved CA rotation PKI secrets engine users have sought a way to rotate root or intermediate CAs without causing service interruptions to any entities referencing them. Vault can now create the newly rotated PKI key pairs for servicing new certificates at the same path as the pre-existing keypair. This allows operators to gradually transition entities over to the new root certificate while the old is still active. -### Client Count tooling improvements +### Client count tooling improvements We have made the following improvements to the Client Count tooling: * Provide the ability to export the unique clients that contribute to the client count aggregate for the selected billing period via a new [activity export API endpoint](/vault/api-docs/system/internal-counters#activity-export). This feature is available in tech preview mode. * Provide the ability to view changes to client counts month over month in the UI. -### MFA Enhancements +### MFA enhancements Vault 1.10 introduced [Login MFA](/vault/docs/auth/login-mfa) support for Vault OSS. In this release, we included additional enhancements to the Login MFA feature by introducing the ability to configure Login MFA via the UI and providing an enhanced TOTP configuration experience via the QR code scan. -### Vault Agent: Support for using an existing valid certificate upon re-authentication +### Vault agent: support for using an existing valid certificate upon re-authentication Enhancements have been made to the Vault Agent to support the parsing of a certificate that's been fetched. A new certificate will only be fetched upon a re-authentication if the certificate's lifetime has expired. This enhancement drastically reduces the resource overhead that Vault Agent users often experience due to over-fetching certificates. -### Namespace enhancements for Vault Terraform +### Namespace enhancements for Vault terraform With Terraform Vault provider v3.7.0, we have made enhancements where it’s now possible to specify the namespace directly within the resource or data source. All resource or data source-specific namespaces are relative to their provider’s configured namespace. This enhancement encourages a better workflow for namespaces, reduces execution time when handling failures of a Terraform plan, and eases the burden on system resources such as memory, CPU, etc. @@ -108,6 +108,6 @@ When you use Vault 1.11.0+ as a Consul's Connect CA, you may encounter an issue -> Refer to this [Knowledge Base article](https://support.hashicorp.com/hc/en-us/articles/11308460105491) for more details. -## Feature Deprecations and EOL +## Feature deprecations and EOL Please refer to the [Deprecation Plans and Notice](/vault/docs/deprecation) page for up-to-date information on feature deprecations and plans. An [Feature Deprecation FAQ](/vault/docs/deprecation/faq) page is also available to address questions concerning decisions made about Vault feature deprecations. diff --git a/website/content/docs/release-notes/1.12.0.mdx b/website/content/docs/release-notes/1.12.0.mdx index 796eefd1aa78..f16b8723d829 100644 --- a/website/content/docs/release-notes/1.12.0.mdx +++ b/website/content/docs/release-notes/1.12.0.mdx @@ -5,7 +5,7 @@ description: |- This page contains release notes for Vault 1.12.0 --- -# Vault 1.12.0 Release Notes +# Vault 1.12.0 release notes **Software Release date:** Oct. 12, 2022 @@ -29,91 +29,91 @@ Some of these enhancements and changes in this release include the following: ~> **Vault Enterprise:** Use [Integrated Storage](/vault/docs/configuration/storage/raft) or [Consul](/vault/docs/configuration/storage/consul) as your Vault's storage backend. Vault Enterprise will no longer start up if configured to use a storage backend other than Integrated Storage or Consul. (See the [Upgrade Guide](/vault/docs/upgrading/upgrade-to-1.12.x).) -## New Features +## New features This section describes the new features introduced in Vault 1.12.0. -### Transform Secrets Engine Enhancements +### Transform secrets engine enhancements -> **NOTE:** These features need the Vault Enterprise ADP License. -#### Bring Your Own Key (BYOK) for Transform +#### Bring your own key (BYOK) for transform In release 1.11, we introduced BYOK support to Vault, enabling customers to import existing keys into the Vault Transit Secrets Engine and enabling secure and flexible Vault deployments. We are extending that support to the Vault Transform Secrets Engine in this release. -#### MSSQL Support +#### MSSQL support An MSSQL store is now available to be used as an external storage engine with tokenization Transform Secrets Engine. Refer to the following documents, [Transform Secrets Engine(API)](/vault/api-docs/secret/transform), [Transform Secrets Engine](/vault/docs/secrets/transform), and [Tokenization Transform](/vault/docs/secrets/transform/tokenization) for more information. -#### Key Auto Rotation +#### Key auto rotation Periodic rotation of encryption keys is a recommended key management practice for a good security posture. In Vault release 1.10, we added support for Auto key rotation for Transit Secrets Engine. In Vault 1.12, the Transform secrets engine is now enhanced, allowing users to set the rotation policy during key creation in a time interval, which will cause Vault to rotate the Transform keys when the time interval elapses automatically. Refer to the following documentation [Tokenization Transform](/vault/docs/secrets/transform/tokenization) and [Transform Secrets Engine(API)](/vault/api-docs/secret/transform#rotate-tokenization-key) for more information. -### PKI Secrets Engine Improvements +### PKI secrets engine improvements -#### PKI Secrets Engine Revocation enhancements +#### PKI secrets engine revocation enhancements We are improving Vault PKI Engine’s revocation capabilities by adding support for the Online Certificate Status Protocol (OCSP) and a delta Certificate Revocation List (CRL) to track changes to the main CRL. These enhancements significantly streamline customer experience with the PKI engine making the certification revocation semantics easier to understand and manage. Additionally, support for automatic CRL rotation and periodic tidy operations help reduce operator burden, alleviate the demand on cluster resources during periods of high revocation, and ensure clients are always served valid CRLs. Finally, support for Bring-Your-Own-Cert (BYOC) allows revocation of `no_store=true` certificates and for Proof-of-Possession (PoP) allows end-users to safely revoke their own certificates (with corresponding private key) without operator intervention. -#### PKI and Managed Key support for RSA-PSS Signatures +#### PKI and managed key support for RSA-PSS signatures Since its initial release, Vault's PKI secrets engine only supported RSA-PKCS#1v1.5 (Public Key Cryptographic Standards) signatures for issuers and leaves. To conform with NIST's guidance around key transport and for compatibility with newer HSM Firmware, we have included support for RSA-PSS signatures (Probabilistic Signature Scheme). See the section on [PSS Support in the PKI documentation](/vault/docs/secrets/pki/considerations#pss-support) for limitations of this feature. -#### PKI Telemetry Improvements +#### PKI telemetry improvements In this release, we are adding additional telemetry to Vault’s PKI secrets engine, enabling customers to gather better insights into certificate usage via the count of stored and revoked certificates. Additionally, the Vault `tidy` function is enhanced with additional metrics that reflect the remaining stored and revoked certificates. -#### Auto-fetch CRL in the Certificate Auth Method +#### Auto-fetch CRL in the certificate auth method Operators will now be able to specify one or more CRL URLs that Vault will automatically fetch and keep up-to-date, rather than having to push the CRLs to the cert auth method. This should make certificate management easier for those users that have large cert auth deployments. -#### GCP Cloud Key Manager Support +#### GCP Cloud key manager support Managed Keys let Vault secrets engines (currently PKI) use keys stored in Cloud KMS systems for cryptographic operations like certificate signing. Vault 1.12 adds support for GCP Cloud KMS to the Managed Key system, where previously AWS, Azure, and PKCS#11 Hardware Security Modules were supported. -### KMIP Server Profile +### KMIP server profile The [Baseline Server Profile](https://docs.oasis-open.org/kmip/kmip-profiles/v2.1/os/kmip-profiles-v2.1-os.html) specifies the basic functionality expected of a KMIP server. In Vault 1.12, we offer support for the operations and attributes in the Baseline server profile. With this release, Vault Enterprise now supports the Symmetric Key lifecycle server profile, Baseline server profile, and the Basic Cryptographic server profile (as of Release 1.11), enabling the support of KMIP integrations with various clients more effectively. This requires the Vault Enterprise ADP license. -### SSH Secrets Engine Support for Generating Keys +### SSH secrets engine support for generating keys Previously, Vault's SSH Secrets Engine when used as an SSH CA required requesters to provide their own public key for signing. In Vault 1.12, Vault can now generate credential key pairs dynamically, returning them to the requester. This was a community contributed enhancement. -### Path and Role-Based Resource Quotas +### Path and Role-Based resource quotas In this release, the existing resource quota functionality has been enhanced. In addition to applying the API rate limiting and lease quotas at the namespace or mount level, you can now use the quotas to the [API path suffixes and auth mount roles](/vault/docs/enterprise/lease-count-quotas). This enhancement provides users with more control over issued certificates. -### Client Count Improvements +### Client count improvements The billing period for client counting API can now be specified with the [current month](/vault/docs/concepts/client-count) for the end date parameter. When this is done the "new_clients" field will have an hyperlog approximate value indicating the number of new clients that came in the current month. Note that for the previous months, the number will be an exact value. -### Redis Database Secrets Engine +### Redis database secrets engine With the support of the Redis database secrets engine, users can use Vault to manage static and dynamic credentials for Redis OSS. The engine works similarly to other database secrets engines. Refer to the [Redis](/vault/docs/secrets/databases/redis) documentation for more information. Huge thanks to [Francis Hitchens](https://github.com/fhitchen), who contributed their repository to HashiCorp -### AWS Elasticache Database Secrets Engine +### AWS elasticache database secrets engine With the support of the AWS ElastiCache database secrets engine, users may use Vault to manage static credentials for AWS Elasticache instances. The engine will work similarly to other database secrets engines. Refer to the [elasticache](/vault/docs/secrets/databases/rediselasticache) documentation for more information. -### LDAP Secrets Engine +### LDAP secrets engine Vault 1.12 introduces a new LDAP secrets engine that unifies the user experience between the Active Directory (AD) secrets engine and OpenLDAP secrets engine. This new engine simplifies the user experience when Vault is used to manage credentials for directory services. This new engine supports all implementations from both of the engines mentioned above (AD, LDAP and RACF) and brings dynamic credential capabilities for users relying on Active Directory. ~> **Note:** This engine does _not_ replace the current Active Directory secrets engine. We will continue to maintain the engine and provide bug fixes, but encourage all new users to use the unified LDAP engine. We will communicate the schedule to deprecate the Active Directory secrets engine well in advance, providing time for users to migrate over. -### Terraform Vault Provider: Vault Version Detection +### Terraform Vault provider: Vault version detection Vault Terraform provider v3.9.0 can now query Vault to detect the server’s version of the server and then perform a semantic version comparison against a provided minimum threshold version to determine whether a selected feature is available for use. This allows for the Vault provider to deterministically anticipate Vault’s behavior. -### Plugin Versioning +### Plugin versioning In prior versions of Vault, plugins were not “version-aware,” creating a suboptimal user experience during plugin installation and upgrades. In Vault 1.12, we are introducing the concept of versions to plugins, making plugins “version-aware” and allowing standardization of the release processes and offering a better user experience when installing and upgrading plugins. -### PKCS#11 Client support +### PKCS#11 client support ​​ Software solutions often require cryptographic objects-like keys, X.509 certificates, or perform operations like a certificate or key generation, hashing, encryption, decryption, and signing. Hardware Security Modules (HSM) are traditionally used as a secure option, but are expensive and challenging to operationalize. @@ -125,24 +125,24 @@ Vault Enterprise 1.12 is a PKCS#11 2.40 compliant provider, extended profile. PK With Vault 1.12, Vault Enterprise (ADP-KM) can now act as an external key manager for Oracle instances when Transparent Data Encryption is enabled. TDE allows users to conjure and use Vault to protect their Data Encryption Keys by using Vault to protect them using a Key Encryption Key. Reading and writing of data securely are handled transparently by Oracle database instances without needing user intervention. This will need the Enterprise ADP license. -### UI Support for Okta Number Challenge +### UI support for okta number challenge In Vault 1.11, we added support for Okta’s Number Challenge feature in the CLI and API. In Vault 1.12, we’ve extended this support to the Vault UI, allowing users to complete the Okta Number Challenge from a web browser, the command line, and the HTTP API. -### OIDC Provider Support in the UI +### OIDC provider support in the UI Vault can now act as an OIDC provider for applications that wish to delegate authentication to Vault and leverage its identity system. As an OIDC provider, Vault supports PKCE for authorization code flow, preventing attacks such as SSRF. After OIDC provider functionality went GA, our design and user research team gathered feedback from community members, and we simplified the setup experience. With a few CLI commands or UI clicks, users can now have a default OIDC provider with its defaults configured and ready to go for applications to utilize the functionality. -## Other Features and Enhancements +## Other features and enhancements -### License Termination Behavior +### License termination behavior The Licensing termination behavior has changed where non-evaluation licenses (production licenses) no longer have a termination date, making Vault more robust for Vault Enterprise customers. Also refer to the updated [licensing FAQ](/vault/docs/enterprise/license/faq) for more information. -### Namespace Custom Metadata +### Namespace custom metadata Customers can now specify [custom metadata](/vault/api-docs/system/namespaces) on the namespaces. The new `vault namespace patch` [command](/vault/docs/commands/namespace) can be used to update existing namespaces with custom metadata as well. This will make it possible to tag namespaces with additional fields (For example: owner, region department) describing it. -### Vault Agent Improvements +### Vault agent improvements Vault Agent introduced new configuration parameters that will significantly improve the use of Vault Agent. These includes: @@ -156,6 +156,6 @@ Vault Agent introduced new configuration parameters that will significantly impr There are no known issues documented for this release. -## Feature Deprecations and EOL +## Feature deprecations and EOL Please refer to the [Deprecation Plans and Notice](/vault/docs/deprecation) page for up-to-date information on feature deprecations and plans. A [Feature Deprecation FAQ](/vault/docs/deprecation/faq) page addresses questions about decisions made about Vault feature deprecations. diff --git a/website/content/docs/release-notes/1.13.0.mdx b/website/content/docs/release-notes/1.13.0.mdx index 2153be0ebc32..088ea271d769 100644 --- a/website/content/docs/release-notes/1.13.0.mdx +++ b/website/content/docs/release-notes/1.13.0.mdx @@ -5,7 +5,7 @@ description: |- This page contains release notes for Vault 1.13.0 --- -# Vault 1.13.0 Release Notes +# Vault 1.13.0 release notes **Software Release date:** March 1, 2023 @@ -119,7 +119,7 @@ The fix for this UI issue is coming in the Vault 1.13.1 release. @include 'update-primary-known-issue.mdx' -## Feature Deprecations and EOL +## Feature deprecations and EOL Please refer to the [Deprecation Plans and Notice](/vault/docs/deprecation) page for up-to-date information on feature deprecations and plans. A [Feature diff --git a/website/content/docs/release-notes/1.5.0.mdx b/website/content/docs/release-notes/1.5.0.mdx index 8396145ce28f..91d03b93d113 100644 --- a/website/content/docs/release-notes/1.5.0.mdx +++ b/website/content/docs/release-notes/1.5.0.mdx @@ -7,7 +7,7 @@ description: |- # Vault 1.5.0 -## Vault 1.5 Release Highlights +## Vault 1.5 release highlights **Resource Quotas:** A new set of functionality called Resource Quotas that allows operators to define API quotas which impose usage limits at the system, endpoint, and namespace level (Enterprise Only) in order to ensure applications and users do not overuse Vault’s resources. The following quota options will be supported: @@ -42,7 +42,7 @@ description: |- **Performance Improvements for Transit:** Vault now features infrastructure improvements to how transit handles encryption/decryption calls with batch tokens. -## What’s Changed +## What’s changed `storage/gcs:` The `credentials_file` config option has been removed. The `GOOGLE_APPLICATION_CREDENTIALS` environment variable or default credentials may be used instead diff --git a/website/content/docs/release-notes/1.6.0.mdx b/website/content/docs/release-notes/1.6.0.mdx index 6060512cfdea..fd7fe73bb276 100644 --- a/website/content/docs/release-notes/1.6.0.mdx +++ b/website/content/docs/release-notes/1.6.0.mdx @@ -7,7 +7,7 @@ description: |- # Vault 1.6.0 -## Vault 1.6 Release Highlights +## Vault 1.6 release highlights **Transform: Tokenization Tech Preview (Enterprise ADP Module Only)**: Vault 1.6 introduces a new transformation method for tokenizing sensitive data stored in un-trusted/semi-trusted systems. Tokenization is available as part of the @@ -44,7 +44,7 @@ to be used in conjunction with Microsoft’s Azure Key Vault. - Add MongoDB Atlas root credential rotation - Added support for root credential & static credential rotation for HanaDB -## What’s Changed +## What’s changed - Vault 1.6 will use Go 1.15, which has dropped support for 32-bit binaries for [Darwin](https://golang.org/doc/go1.15#darwin), so we will no longer be issuing `darwin_386` builds of Vault. diff --git a/website/content/docs/release-notes/1.7.0.mdx b/website/content/docs/release-notes/1.7.0.mdx index f1ffe079ad75..7774e5e38019 100644 --- a/website/content/docs/release-notes/1.7.0.mdx +++ b/website/content/docs/release-notes/1.7.0.mdx @@ -7,9 +7,9 @@ description: |- # Vault 1.7.0 -## Vault 1.7 Release Highlights +## Vault 1.7 release highlights -### Secrets Engine Enhancements +### Secrets engine enhancements - **Tokenization (Enterprise ADP Module)**: General Availability of a new transformation method for tokenizing sensitive data stored in un-trusted/semi-trusted systems. Tokenization is available as part of the “Advanced Data Protection” module in Vault Enterprise. Tokenization provides non-reversible data protection pursuant to requirements for data irreversibility (PCI-DSS, GDPR, etc.). - **Key Management Secrets Engine General Availability (Enterprise ADP Module):** A new Key Management Secrets Engine to help manage and securely distribute keys to various cloud KMS services. This feature is to be used in conjunction with Microsoft’s Azure KeyVault (GA) and AWS KMS (Beta). @@ -18,7 +18,7 @@ description: |- - **TFE/TFC Secrets Engine:** New secrets engine to allow TFE/TFC users to generate short-lived ephemeral user/team or organization tokens credentials to be used in their pipelines. - **Active Directory Dynamic Credentials:** Allows for creation of short lived AD accounts when using the OpenLDAP engine in "AD" mode. -### Storage Backend Enhancements +### Storage backend enhancements - **Integrated Storage Autopilot:** New autopilot enhancements to simplify and automate the cluster management operational experience. These include: - Checks to monitor node health and status @@ -27,12 +27,12 @@ description: |- For Vault Enterprise, autopilot will automatically include non-voter considerations to the above functionality. - **Aerospike Storage Backend:** Support for using Aerospike as a community supported storage backend option. -### Security and Cryptography Enhancements +### Security and cryptography enhancements - **Barrier Auto Key Rotation:** Updates to allow Vault to automatically rotate to a new barrier key for future encryption after crossing the 2^32 encryption threshold, thereby improving security. - **KMIP Entropy Augmentation (Enterprise ADP Module):** The ability to use entropy augmentation to generate KMIP certificates. -### Vault Metrics Enhancements +### Vault metrics enhancements - **Usage Metrics Visibility:** - Vault Auditor now includes the active KMIP certificate count as part of the client usage metrics. @@ -40,7 +40,7 @@ description: |- - Added API for partial month client count. - **Telemetry Metrics:** Added new metrics related to lease expiration. -### Performance and Reliability Improvements +### Performance and reliability improvements - **Expiration Manager Improvements:** Improved how Vault resources are consumed during lease revocations. - **Client Controlled Consistency (Enterprise):** New options to use configurable headers to control the consistency of reads after writes to performance secondary clusters and performance standby nodes. @@ -56,7 +56,7 @@ description: |- - Added support for an agent persistent cache to allow for a graceful handoff between init and sidecar containers when using vault-k8s (mutating admissions controller) for secrets injection. - **Operator enhancement:** The Vault status command (which prints the current state of Vault including whether it is sealed and if HA mode is enabled) now works when a namespace is set. -## Known Issues +## Known issues - There is a known issue that may cause Autopilot to be unable to determine the leader node. This occurs if the IP in the raft peer list is different from the configured cluster address. If affected you should disable Autopilot by setting the VAULT_RAFT_AUTOPILOT_DISABLE environment variable to 1. - Autopilot is not currently supported with Integrated Storage's HA-only mode or with DR secondary clusters. diff --git a/website/content/docs/release-notes/1.8.0.mdx b/website/content/docs/release-notes/1.8.0.mdx index 642419acaf55..75fcd3fbe993 100644 --- a/website/content/docs/release-notes/1.8.0.mdx +++ b/website/content/docs/release-notes/1.8.0.mdx @@ -7,7 +7,7 @@ description: |- # Vault 1.8.0 -## Vault 1.8 Release Highlights +## Vault 1.8 release highlights **Licensing Changes:** There are a few key licensing changes that are introduced with 1.8: @@ -19,7 +19,7 @@ description: |- **Vault Diagnose:** A new `vault operator diagnose` command enables faster troubleshooting and user-friendly diagnostics in situations when Vault is not starting. -### Secrets Engine Enhancements +### Secrets engine enhancements - **Key Management Secrets Engine (Enterprise ADP-KM Module Only)**: Key Management Secrets Engine that was released as generally available for Azure in Vault 1.7, is now generally available for AWS. - **UI for the Database Secrets Engine:** Expansion of the UI for the database secrets engine, allowing for users to interact with MSSQL and MySQL database engines via the Vault UI. @@ -27,7 +27,7 @@ description: |- - **Username templating:** With Vault 1.8 users have the ability to customize usernames for the snowflake, redshift, elasticsearch, influxdb, rabbitmq and mongodb atlas database engines. - **Active Directory:** Vault now has the ability to manually rotate a credential for an account being managed via the AD secrets engine. -### Other Enhancements +### Other enhancements - **ServiceNow Credential Resolver:** Vault can now act as an external credential store for the ServiceNow MID servers when using a ServiceNow workflow for service discovery - **RedHat certified helm charts:** Vault’s Kubernetes Helm charts are now certified by RedHat! diff --git a/website/content/docs/release-notes/1.9.0.mdx b/website/content/docs/release-notes/1.9.0.mdx index d19e54d8e139..3a9b70883f58 100644 --- a/website/content/docs/release-notes/1.9.0.mdx +++ b/website/content/docs/release-notes/1.9.0.mdx @@ -5,17 +5,17 @@ description: |- This page contains release notes for Vault 1.9.0. --- -# Vault 1.9.0 Release notes +# Vault 1.9.0 release notes **Software Release Date**: November 19, 2021 **Summary**: This document captures major updates as part of Vault release 1.9.0, including new features, breaking changes, enhancements, deprecation, and EOL plans. Refer to the [Changelog](https://github.com/hashicorp/vault/blob/main/CHANGELOG.md) for additional changes made within the Vault 1.9 release. -## New Features +## New features This section describes the new features introduced as part of Vault 1.9.0. -### Client Count Improvements +### Client count improvements Several improvements to client count were made to help customers better track and identify client attribution and reduce overcomputing. @@ -29,11 +29,11 @@ The improvements made include the following: * Displays client counts per namespace (top ten, descending order by attribution) in the usage metrics UI with the ability to export data for all namespaces * Displays clients earlier than a month in the usage metrics UI (within ten minutes since initiation of computation) -### Advanced Data Protection Module (ADP) Enhancements +### Advanced data protection module (ADP) enhancements The following section provides details about the ADP module features added in this release. -#### Advanced I/O handling for Tranform FPE (ADP-Transform) +#### Advanced I/O handling for tranform FPE (ADP-Transform) Users of the Format Preserving Encryption (FPE) feature of ADP Transform will now benefit from increased flexibility with regards to formatting the input and output of their data. [Transformation templates](/vault/tutorials/adp/transform#advanced-handling) are receiving two new fields- **encode_format** and **decode_formats** -that allow users to specify and format individual [capturing groups](https://www.regular-expressions.info/refcapture.html) within the regular expressions that define their formats. @@ -41,15 +41,15 @@ Users of the Format Preserving Encryption (FPE) feature of ADP Transform will no We added support to Vault Enterprise for customers who want Vault to manage encryption keys for Transparent Data Encryption on MSSQL servers. -#### Key Management Secrets(KMS) engine - GCP (ADP-KM) +#### Key management Secrets(KMS) engine - GCP (ADP-KM) The [KMS Engine for GCP](/vault/docs/secrets/gcpkms) provides key management via the Google Cloud KMS to assist with automating many GCP key management functions. -## Other Features and Enhancements +## Other features and enhancements This section describes other features and enhancements introduced as part of the Vault 1.9 release. -### Vault Agent improvements +### Vault agent improvements Improvements were made to the Vault Agent Cache to ensure that [consul-template is always routed through the Vault Agent cache](/vault/docs/agent/template), therefore, eliminating the need for listeners to be defined in the Vault Agent for just templating. @@ -69,11 +69,11 @@ This feature adds support for Vault to run on the IBM s390x architecture via the This [feature](/vault/docs/concepts/namespace-api-lock) allows namespace administrators to flexibly control operations such as locking APIs from child namespaces to which they have access. This enables them to restrict access to their domain in a multi-tenant environment and perform break-glass procedures in times of emergency to protect a cluster from within their child namespace. -### Vault Terraform Provider v3 +### Vault terraform provider v3 We have upgraded the [Vault Terraform Provider](https://registry.terraform.io/providers/hashicorp/vault/latest/docs) to the latest version of the [Terraform Plugin SDKv2](/terraform/plugin/sdkv2) to leverage new features. -### Azure Secrets Engine +### Azure secrets engine The following enhancement are included: @@ -84,7 +84,7 @@ The following enhancement are included: This [enhancement](/vault/api-docs/secret/kv/kv-v2) provides the ability to set version-agnostic custom key metadata for Vault KVv2 secrets via a metadata endpoint. This custom metadata is also visible in the UI. -## UI Enhancements +## UI enhancements ### Expanding the UI for more DB secrets engines We have been adding support for DB secrets engines in the UI over the past few releases. In the Vault 1.9 release, we have added support for [Oracle](/vault/docs/secrets/databases/oracle) and [ElasticSearch](/vault/docs/secrets/databases/elasticdb) and [PostgresSQL](/vault/docs/secrets/databases/postgresql) database secrets engines in the UI. @@ -93,17 +93,17 @@ We have been adding support for DB secrets engines in the UI over the past few r The [PKI Secrets Engine](/vault/docs/secrets/pki) now displays additional PKI certificate metadata in the UI, such as date issued, date of expiry, serial number, and subject/name. -## Tech Preview Features +## Tech preview features -### KV Secrets Engine v2 patch operations +### KV secrets engine v2 patch operations This feature provides a more streamlined method for managing [KV v2 secrets](/vault/api-docs/secret/kv/kv-v2), enabling customers to better maintain least privilege security in automated environments. This feature allows performing partial updates to KV v2 secrets without requiring to read the full KV secret's key/value pairs. -### Vault as an OIDC Provider +### Vault as an OIDC provider Vault can now act as an OIDC Provider so applications can leverage the pre-existing [Vault identities](/vault/api-docs/secret/identity) to authenticate into applications. -## Breaking Changes +## Breaking changes The following section details breaking changes introduced in Vault 1.9. @@ -114,6 +114,6 @@ Please refer to the [upgrade guide](/vault/docs/upgrading/upgrade-to-1.9.x) for As called out in the documentation, Vault does not make backwards compatible guarantees on internal APIs (those prefaced with `sys/internal`). They are subject to change and may disappear without notice. -## Feature Deprecations and EOL +## Feature deprecations and EOL Please refer to the [Deprecation Plans and Notice](/vault/docs/deprecation) page for up-to-date information on feature deprecations and plans. An [FAQ](/vault/docs/deprecation/faq) page is also available to address questions concerning decisions made about Vault feature deprecations. diff --git a/website/content/docs/release-notes/index.mdx b/website/content/docs/release-notes/index.mdx index 2d35e21e8ce9..c525f248bde9 100644 --- a/website/content/docs/release-notes/index.mdx +++ b/website/content/docs/release-notes/index.mdx @@ -4,7 +4,7 @@ page_title: Release Notes description: Release notes for new Vault versions. --- -# Release Notes +# Release notes Release notes describe major updates in new versions of Vault. diff --git a/website/content/docs/secrets/ad/index.mdx b/website/content/docs/secrets/ad/index.mdx index 8c94477f49bc..f17e7964729b 100644 --- a/website/content/docs/secrets/ad/index.mdx +++ b/website/content/docs/secrets/ad/index.mdx @@ -5,7 +5,7 @@ description: >- The Active Directory secrets engine allowing Vault to generate dynamic credentials. --- -# Active Directory Secrets Engine +# Active directory secrets engine @include 'ad-secrets-deprecation.mdx' @@ -28,9 +28,9 @@ be checked out by a person or by machines. Vault will automatically rotate the p each time a service account is checked in. Service accounts can be voluntarily checked in, or Vault will check them in when their lending period (or, "ttl", in Vault's language) ends. -## Password Rotation +## Password rotation -### Customizing Password Generation +### Customizing password generation There are two ways of customizing how passwords are generated in the Active Directory secret engine: @@ -41,7 +41,7 @@ Utilizing password policies is the recommended path as the `length` and `formatt been deprecated in favor of password policies. The `password_policy` field within the configuration cannot be specified alongside either `length` or `formatter` to prevent a confusing configuration. -### A Note on Lazy Rotation +### A note on lazy rotation To drive home the point that passwords are rotated "lazily", consider this scenario: @@ -60,7 +60,7 @@ Therefore, the AD TTL can be considered a soft contract. It's fulfilled when the To ensure your passwords are rotated as expected, we'd recommend you configure services to request each password at least twice as often as its TTL. -### A Note on Escaping +### A note on escaping **It is up to the administrator** to provide properly escaped DNs. This includes the user DN, bind DN for search, and so on. @@ -81,7 +81,7 @@ For reference, see [RFC 4514](https://www.ietf.org/rfc/rfc4514.txt) and this [TechNet post on characters to escape in Active Directory](http://social.technet.microsoft.com/wiki/contents/articles/5312.active-directory-characters-to-escape.aspx). -### Quick Setup +### Quick setup Most secrets engines must be configured in advance before they can perform their functions. These steps are usually completed by an operator or configuration @@ -131,7 +131,7 @@ management tool. ### FAQ -#### What if someone directly rotates an Active Directory password that Vault is managing? +#### What if someone directly rotates an active directory password that Vault is managing? If an administrator at your company rotates a password that Vault is managing, the next time an application asks _Vault_ for that password, Vault won't know @@ -159,7 +159,7 @@ this, Vault returns the current password with the last password if it's known. That way, if a new password isn't fully operational, the last password can also be used. -## Service Account Check-Out +## Service account Check-Out Vault offers the ability to check service accounts in and out. This is a separate, different set of functionality from the password rotation feature above. Let's walk @@ -319,7 +319,7 @@ discussing how to configure this behavior. This behavior appears to vary by AD version. We recommend you test the behavior of your particular AD server, and edit its settings to gain the desired behavior. -#### I get a lot of 400 Bad Request's when trying to check out service accounts. +#### I get a lot of 400 bad request's when trying to check out service accounts. This will occur when there aren't enough service accounts for those requesting them. Let's suppose our "accounting-team" service accounts are the ones being requested. When Vault @@ -347,7 +347,7 @@ of a new password to travel across all AD instances in a cluster. In larger clus have observed the password taking over 10 seconds to propagate fully. The simplest way to handle this is to simply wait and retry using the new password. -#### When trying to read credentials I get 'LDAP Result Code 53 "Unwilling To Perform"' +#### When trying to read credentials i get 'LDAP result code 53 "Unwilling to perform"' Active Directory will only support password changes over a secure connection. Ensure that your configuration block is not using an unsecured LDAP connection. diff --git a/website/content/docs/secrets/ad/migration-guide.mdx b/website/content/docs/secrets/ad/migration-guide.mdx index 5af91330f4b0..a467ee47e457 100644 --- a/website/content/docs/secrets/ad/migration-guide.mdx +++ b/website/content/docs/secrets/ad/migration-guide.mdx @@ -5,14 +5,14 @@ description: >- The guide for migrating from the Active Directory secrets engine to the LDAP secrets engine. --- -# Migration Guide - Active Directory Secrets Engine +# Migration guide - active directory secrets engine The Vault [Active Directory secrets engine](/vault/docs/secrets/ad) has been deprecated as of the Vault 1.13 release. This document provides guidance for migrating from the Active Directory secrets engine to the [LDAP secrets engine](/vault/docs/secrets/ldap) that was introduced in Vault 1.12. -## Deprecation Timeline +## Deprecation timeline Beginning from the Vault 1.13 release, we will continue to support the Active Directory (AD) secrets engine in maintenance mode for six major Vault releases. Maintenance mode means that @@ -24,12 +24,12 @@ the AD secrets engine. At Vault 1.19, we will mark the AD secrets engine as [removed](/vault/docs/deprecation/faq#removed). At this time, the AD secrets engine will be removed from Vault. Vault will not start up with the AD secrets engine mounts enabled. -## Migration Steps +## Migration steps The following sections detail how to migrate the AD secrets engine configuration and applications consuming secrets to the new LDAP secrets engine. -### 1. Enable LDAP Secrets Engine +### 1. enable LDAP secrets engine The LDAP secrets engine needs to be enabled in order to have a target for migration of existing AD secrets engine mounts. AD secrets engine mounts should be mapped 1-to-1 with @@ -50,13 +50,13 @@ $ vault secrets enable -path= ldap If enabled at a custom path, the `/ldap/` path segment in API paths must be replaced with the custom path value. -### 2. Migrate Configuration +### 2. migrate configuration The AD secrets engine [configuration](/vault/api-docs/secret/ad#configuration) will need to be migrated to an LDAP secrets engine [configuration](/vault/api-docs/secret/ldap#configuration-management). The API paths and parameters will need to be considered during the migration. -#### API Path +#### API path | AD Secrets Engine | LDAP Secrets Engine | | ----------------- |-------------------- | @@ -76,13 +76,13 @@ exception and must be considered during the migration. | [max_ttl](/vault/api-docs/secret/ad#max_ttl) | N/A | Not supported for [static roles](#3-migrate-roles). Can be set using [max_ttl](/vault/api-docs/secret/ldap#max_ttl-1) for library sets. | | [last_rotation_tolerance](/vault/api-docs/secret/ad#last_rotation_tolerance) | N/A | Not supported by the LDAP secrets engine. Passwords will be rotated based on the static role [rotation_period](/vault/api-docs/secret/ldap#rotation_period). | -### 3. Migrate Roles +### 3. migrate roles AD secrets engine [roles](/vault/api-docs/secret/ad#role-management) will need to be migrated to LDAP secrets engine [static roles](/vault/api-docs/secret/ldap#static-roles). The API paths, parameters, and rotation periods will need to be considered during the migration. -#### API Path +#### API path | AD Secrets Engine | LDAP Secrets Engine | | ----------------- | ------------------- | @@ -97,7 +97,7 @@ The following parameters must be migrated. | [ttl](/vault/api-docs/secret/ad#ttl-1) | [rotation_period](/vault/api-docs/secret/ldap#rotation_period) | N/A | | [service_account_name](/vault/api-docs/secret/ad#service_account_name) | [username](/vault/api-docs/secret/ldap#username) | If `username` is set without setting the [dn](/vault/api-docs/secret/ldap#dn) value, then the configuration [userdn](/vault/api-docs/secret/ldap#userdn) must also be set. | -#### Rotation Periods +#### Rotation periods Rotations that occur from AD secrets engine [roles](/vault/api-docs/secret/ad#role-management) may conflict with rotations performed by LDAP secrets engine [static roles](/vault/api-docs/secret/ldap#static-roles) @@ -109,13 +109,13 @@ the chance of this happening. Additionally, tuning the AD secrets engine [last_r parameter could help mitigate applications reading stale passwords, since the parameter allows rotation of the password if it's been rotated out-of-band within a given duration. -### 4. Migrate Library Sets +### 4. migrate library sets AD secrets engine [library sets](/vault/api-docs/secret/ad#library-management) will need to be migrated to LDAP secrets engine [library sets](/vault/api-docs/secret/ldap#library-set-management). The API paths and parameters will need to be considered during the migration. -#### API Path +#### API path | AD Secrets Engine | LDAP Secrets Engine | | ----------------- | ------------------- | @@ -126,7 +126,7 @@ The API paths and parameters will need to be considered during the migration. The parameters from existing AD secrets engine library sets can be exactly mapped 1-to-1 to LDAP secrets engine library sets. There are no exceptions to consider. -### 5. Migrate Applications +### 5. migrate applications The AD secrets engine provides APIs to obtain credentials for AD users and service accounts. Applications, or Vault clients, are typically the consumer of these credentials. For applications @@ -136,7 +136,7 @@ with an ACL [policy](/vault/docs/concepts/policies) that authorizes access to th The following section details credential-providing APIs and how their response formats differ between the AD secrets engine and LDAP secrets engine. -#### API Paths +#### API paths | AD Secrets Engine | LDAP Secrets Engine | Details | | ----------------- | ------------------- | ------- | @@ -144,7 +144,7 @@ between the AD secrets engine and LDAP secrets engine. | [/ad/library/:set_name/check-out](/vault/api-docs/secret/ad#check-a-credential-out) | [/ldap/library/:set_name/check-out](/vault/api-docs/secret/ldap#check-out-management) | Response formats do not differ. | | [/ad/library/:set_name/check-in](/vault/api-docs/secret/ad#check-a-credential-in) | [/ldap/library/:set_name/check-in](/vault/api-docs/secret/ldap#check-in-management) | Response formats do not differ. | -### 6. Disable AD Secrets Engines +### 6. disable AD secrets engines AD secrets engine mounts can be disabled after successful migration of configuration and applications to the LDAP secrets engine. Note that disabling the secrets engine will erase diff --git a/website/content/docs/secrets/alicloud.mdx b/website/content/docs/secrets/alicloud.mdx index a892725d3468..17ff7cb7c76d 100644 --- a/website/content/docs/secrets/alicloud.mdx +++ b/website/content/docs/secrets/alicloud.mdx @@ -8,7 +8,7 @@ description: >- dynamically based on RAM policies or roles. --- -# AliCloud Secrets Engine +# AliCloud secrets engine The AliCloud secrets engine dynamically generates AliCloud access tokens based on RAM policies, or AliCloud STS credentials based on RAM roles. This generally @@ -105,12 +105,12 @@ management tool. Since we will be assuming the role to gain credentials, the `access_key` and `secret_key` in the config must qualify as a trusted actor. -### Helpful Links +### Helpful links - [More on roles](https://www.alibabacloud.com/help/doc-detail/28649.htm) - [More on policies](https://www.alibabacloud.com/help/doc-detail/28652.htm) -### Example RAM Policy for Vault +### Example RAM policy for Vault While AliCloud credentials can be supplied by environment variables, an explicit setting in the `alicloud/config`, or through instance metadata, the resulting diff --git a/website/content/docs/secrets/aws.mdx b/website/content/docs/secrets/aws.mdx index f9615ed3db27..4695c6ea7b27 100644 --- a/website/content/docs/secrets/aws.mdx +++ b/website/content/docs/secrets/aws.mdx @@ -6,7 +6,7 @@ description: |- IAM policies. --- -# AWS Secrets Engine +# AWS secrets engine The AWS secrets engine generates AWS access credentials dynamically based on IAM policies. This generally makes working with AWS IAM easier, since it does not @@ -32,7 +32,7 @@ Vault supports three different types of credentials to retrieve from AWS: passing in the supplied AWS policy document and return the access key, secret key, and session token to the caller. -### Static Roles +### Static roles The AWS secrets engine supports the concept of "static roles", which are a 1-to-1 mapping of Vault Roles to IAM users. The current password for the user is stored and automatically rotated by Vault on a @@ -179,7 +179,7 @@ the proper permission, it can generate credentials. See the [AWS secrets engine API](/vault/api-docs/secret/aws#rotate-root-iam-credentials) for further information on `config/rotate-root` functionality. -## Example IAM Policy for Vault +## Example IAM policy for Vault The `aws/config/root` credentials need permission to manage dynamic IAM users. Here is an example AWS IAM policy that grants the most commonly required @@ -269,7 +269,7 @@ them). The above demonstrated usage with `iam_user` credential types. As mentioned, Vault also supports `assumed_role` and `federation_token` credential types. -### STS Federation Tokens +### STS federation tokens ~> **Notice:** Due to limitations in AWS, in order to use the `federation_token` credential type, Vault **must** be configured with IAM user credentials. AWS @@ -483,7 +483,7 @@ See http://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.ht Vault 0.5.1 or later is recommended when using STS tokens to avoid validation errors for exceeding the AWS limit of 32 characters on STS token names. -### AWS Instance Metadata Timeouts +### AWS instance metadata timeouts @include 'aws-imds-timeout.mdx' diff --git a/website/content/docs/secrets/azure.mdx b/website/content/docs/secrets/azure.mdx index 2f255154d2af..e418b7a5382c 100644 --- a/website/content/docs/secrets/azure.mdx +++ b/website/content/docs/secrets/azure.mdx @@ -6,7 +6,7 @@ description: |- service principals and role assignments. --- -# Azure Secrets Engine +# Azure secrets engine The Azure secrets engine dynamically generates Azure service principals along with role and group assignments. Vault roles can be mapped to one or more Azure @@ -103,7 +103,7 @@ This endpoint generates a renewable set of credentials. The application can logi using the `client_id`/`client_secret` and will have access provided by configured service principal or the Azure roles set in the "my-role" configuration. -## Root Credential Rotation +## Root credential rotation If the mount is configured with credentials directly, the credential's key may be rotated to a Vault-generated value that is not accessible by the operator. @@ -125,13 +125,13 @@ roles will be assigned to a newly created service principal. The Vault role may role-specific `ttl` and/or `max_ttl` values. When the lease is created, the more restrictive of the mount or role TTL value will be used. -### Application Object IDs +### Application object IDs If an existing service principal is to be used, the Application Object ID must be set on the Vault role. This ID can be found by inspecting the desired Application with the `az` CLI tool, or via the Azure Portal. Note that the Application **Object** ID must be provided, not the Application ID. -### Azure Roles +### Azure roles If dynamic service principals are used, Azure roles must be configured on the Vault role. Azure roles are provided as a JSON list, with each element describing an Azure role and scope to be assigned. @@ -146,7 +146,7 @@ role management operations. All roles _must exist_ when the configuration is wri The `scope` must be provided for every role assignment. -### Azure Groups +### Azure groups If dynamic service principals are used, a list of Azure groups may be configured on the Vault role. When the service principal is created, it will be assigned to these groups. Similar to the format used @@ -191,7 +191,7 @@ $ cat az_groups.json ] ``` -### Permanently Delete Azure Objects +### Permanently delete Azure objects If dynamic service principals are used, the option to permanently delete the applications and service principals created by Vault may be configured on the Vault role. When this option is enabled and a lease is expired or revoked, the application and service principal associated with the lease will be [permanently deleted](https://docs.microsoft.com/en-us/graph/api/directory-deleteditems-delete) from the Azure Active Directory. @@ -223,7 +223,7 @@ If the client ID or secret are not present and Vault is running on an Azure VM, to access Azure. Note that when MSI is used, tenant and subscription IDs must still be explicitly provided in the configuration or environment variables. -### MS Graph API Permissions +### MS graph API permissions The following MS Graph [API permissions](https://learn.microsoft.com/en-us/azure/active-directory/develop/permissions-consent-overview#types-of-permissions) must be assigned to the service principal provided to Vault for managing Azure. The permissions @@ -244,7 +244,7 @@ service principals. | Application.ReadWrite.All | Application | | GroupMember.ReadWrite.All | Application | -### Role Assignments +### Role assignments The following Azure [role assignments](https://learn.microsoft.com/en-us/azure/role-based-access-control/role-assignments-cli) must be granted in order for the secrets engine to manage role assignments for service @@ -274,7 +274,7 @@ Application. An error will be returned if the object size is reached. This limit managed by reducing the role TTL, or by creating another Vault role against a different Azure service principal configured with the same permissions. -## Additional Notes +## Additional notes - **If a referenced Azure role doesn't exist, a credential will not be generated.** Service principals will only be generated if _all_ role assignments are successful. @@ -297,7 +297,7 @@ Azure service principal configured with the same permissions. `ffffff`. These may be used to search for Vault-created credentials using the `az` tool or Portal. -## Help & Support +## Help & support The Azure secrets engine is written as an external Vault plugin and thus exists outside the main Vault repository. It is automatically bundled with diff --git a/website/content/docs/secrets/consul.mdx b/website/content/docs/secrets/consul.mdx index 031c606f1b18..5dd3ea9e2687 100644 --- a/website/content/docs/secrets/consul.mdx +++ b/website/content/docs/secrets/consul.mdx @@ -4,7 +4,7 @@ page_title: Consul - Secrets Engines description: The Consul secrets engine for Vault generates tokens for Consul dynamically. --- -# Consul Secrets Engine +# Consul secrets engine @include 'x509-sha1-deprecation.mdx' diff --git a/website/content/docs/secrets/cubbyhole.mdx b/website/content/docs/secrets/cubbyhole.mdx index cf99ab790c4f..841ced4c2e44 100644 --- a/website/content/docs/secrets/cubbyhole.mdx +++ b/website/content/docs/secrets/cubbyhole.mdx @@ -6,7 +6,7 @@ description: >- token. --- -# Cubbyhole Secrets Engine +# Cubbyhole secrets engine The `cubbyhole` secrets engine is used to store arbitrary secrets within the configured physical storage for Vault namespaced to a token. In `cubbyhole`, diff --git a/website/content/docs/secrets/databases/cassandra.mdx b/website/content/docs/secrets/databases/cassandra.mdx index c8d6cc6d3c23..8f98fd286d17 100644 --- a/website/content/docs/secrets/databases/cassandra.mdx +++ b/website/content/docs/secrets/databases/cassandra.mdx @@ -7,7 +7,7 @@ description: |- roles for the Cassandra database. --- -# Cassandra Database Secrets Engine +# Cassandra database secrets engine @include 'x509-sha1-deprecation.mdx' diff --git a/website/content/docs/secrets/databases/couchbase.mdx b/website/content/docs/secrets/databases/couchbase.mdx index 7cd879e47125..a009cd91930f 100644 --- a/website/content/docs/secrets/databases/couchbase.mdx +++ b/website/content/docs/secrets/databases/couchbase.mdx @@ -7,7 +7,7 @@ description: |- roles for the Couchbase database. --- -# Couchbase Database Secrets Engine +# Couchbase database secrets engine @include 'x509-sha1-deprecation.mdx' diff --git a/website/content/docs/secrets/databases/custom.mdx b/website/content/docs/secrets/databases/custom.mdx index 535a699f751a..3f1b7c770aa9 100644 --- a/website/content/docs/secrets/databases/custom.mdx +++ b/website/content/docs/secrets/databases/custom.mdx @@ -9,7 +9,7 @@ description: |- plugins while keeping Vault itself statically linked. --- -# Custom Database Secrets Engines +# Custom database secrets engines ~> The interface for custom database plugins has changed in Vault 1.6. Vault will continue to recognize the now deprecated version of this interface for some time. @@ -38,7 +38,7 @@ connections. To enable multiplexing, the plugin must be compiled with the `ServeMultiplex` function call from Vault's `dbplugin` package. -## Plugin Interface +## Plugin interface All plugins for the database secrets engine must implement the same interface. This interface is found in `sdk/database/dbplugin/v5/database.go` @@ -107,9 +107,9 @@ the configuration is valid and able to connect to the database in question. If t false, no connection should be made during the `Initialize` call, but subsequent calls to the other functions will need to open a connection. -## Serving A Plugin +## Serving a plugin -### Serving A Plugin with Multiplexing +### Serving a plugin with multiplexing ~> Plugin multiplexing requires `github.com/hashicorp/vault/sdk v0.4.0` or above. @@ -179,7 +179,7 @@ func (db *MyDatabase) secretValues() map[string]string { Replacing `MyDatabase` with the actual implementation of your database plugin. -### Serving A Plugin without Multiplexing +### Serving a plugin without multiplexing Serving a plugin without multiplexing requires calling the `Serve` function from `sdk/database/dbplugin/v5` to serve your plugin. @@ -278,7 +278,7 @@ Some use cases that should avoid plugin multiplexing might include: * Avoiding restart across all mounts/database connections for a plugin type on crashes or plugin reload calls -## Upgrading database plugins to the V5 interface +## Upgrading database plugins to the v5 interface ### Background diff --git a/website/content/docs/secrets/databases/db2.mdx b/website/content/docs/secrets/databases/db2.mdx index ff16dc2b0f12..978e12879b88 100644 --- a/website/content/docs/secrets/databases/db2.mdx +++ b/website/content/docs/secrets/databases/db2.mdx @@ -5,7 +5,7 @@ description: |- Manage credentials for IBM Db2 using Vault's LDAP secrets engine. --- -# IBM Db2 +# IBM db2 Access to Db2 is managed by facilities that reside outside the Db2 database system. By default, user authentication is completed by a security facility that relies on operating diff --git a/website/content/docs/secrets/databases/elasticdb.mdx b/website/content/docs/secrets/databases/elasticdb.mdx index 137bbc207484..214ea2decc89 100644 --- a/website/content/docs/secrets/databases/elasticdb.mdx +++ b/website/content/docs/secrets/databases/elasticdb.mdx @@ -10,7 +10,7 @@ description: >- for Elasticsearch. --- -# Elasticsearch Database Secrets Engine +# Elasticsearch database secrets engine @include 'x509-sha1-deprecation.mdx' @@ -27,17 +27,17 @@ more information about setting up the database secrets engine. | ------------------------------- | ------------------------ | ------------- | ------------ | ---------------------- | | `elasticsearch-database-plugin` | Yes | Yes | Yes (1.6+) | Yes (1.8+) | -## Getting Started +## Getting started To take advantage of this plugin, you must first enable Elasticsearch's native realm of security by activating X-Pack. These instructions will walk you through doing this using Elasticsearch 7.1.1. -### Enable X-Pack Security in Elasticsearch +### Enable X-Pack security in elasticsearch Read [Securing the Elastic Stack](https://www.elastic.co/guide/en/elastic-stack-overview/7.1/elasticsearch-security.html) and follow [its instructions for enabling X-Pack Security](https://www.elastic.co/guide/en/elasticsearch/reference/7.1/setup-xpack.html). -### Enable Encrypted Communications +### Enable encrypted communications This plugin communicates with Elasticsearch's security API. ES requires TLS for these communications so they can be encrypted. @@ -57,12 +57,12 @@ and using `sudo dpkg-reconfigure ca-certificates`. The above instructions may vary if you are not using an Ubuntu machine. Please ensure you're using the methods specific to your operating environment. Describing every operating environment is outside the scope of these instructions. -### Set Up Passwords +### Set up passwords When done, verify that you've enabled X-Pack by running `$ $ES_HOME/bin/elasticsearch-setup-passwords interactive`. You'll know it's been set up successfully if it takes you through a number of password-inputting steps. -### Create a Role for Vault +### Create a role for Vault Next, in Elasticsearch, we recommend that you create a user just for Vault to use in managing secrets. diff --git a/website/content/docs/secrets/databases/hanadb.mdx b/website/content/docs/secrets/databases/hanadb.mdx index 2361d08e99fd..9c8b77f967ef 100644 --- a/website/content/docs/secrets/databases/hanadb.mdx +++ b/website/content/docs/secrets/databases/hanadb.mdx @@ -7,7 +7,7 @@ description: |- for the HANA database. --- -# HANA Database Secrets Engine +# HANA database secrets engine HANA is one of the supported plugins for the database secrets engine. This plugin generates database credentials dynamically based on configured roles for diff --git a/website/content/docs/secrets/databases/index.mdx b/website/content/docs/secrets/databases/index.mdx index 8a765744d7fe..d53dfabd72c2 100644 --- a/website/content/docs/secrets/databases/index.mdx +++ b/website/content/docs/secrets/databases/index.mdx @@ -26,7 +26,7 @@ it down to the specific instance of a service based on the SQL username. Vault makes use of its own internal revocation system to ensure that users become invalid within a reasonable time of the lease expiring. -### Static Roles +### Static roles The database secrets engine supports the concept of "static roles", which are a 1-to-1 mapping of Vault Roles to usernames in a database. The current password @@ -128,7 +128,7 @@ the proper permission, it can generate credentials. username v-vaultuser-e2978cd0-ugp7iqI2hdlff5hfjylJ-1602537260 ``` -## Database Capabilities +## Database capabilities As of Vault 1.6, all databases support dynamic roles and static roles. All plugins except MongoDB Atlas support rotating the root user's credentials. MongoDB Atlas cannot support rotating the root user's credentials because it uses a public @@ -152,13 +152,13 @@ and private key pair to authenticate. | [Redshift](/vault/docs/secrets/databases/redshift) | Yes | Yes | Yes | Yes (1.8+) | password | | [Snowflake](/vault/docs/secrets/databases/snowflake) | Yes | Yes | Yes | Yes (1.8+) | password, rsa_private_key | -## Custom Plugins +## Custom plugins This secrets engine allows custom database types to be run through the exposed plugin interface. Please see the [custom database plugin](/vault/docs/secrets/databases/custom) for more information. -## Credential Types +## Credential types Database systems support a variety of authentication methods and credential types. The database secrets engine supports management of credentials alternative to usernames @@ -168,7 +168,7 @@ of dynamic and static roles configure the credential that Vault will generate an make available to database plugins. See the documentation of individual database plugins for the credential types they support and usage examples. -## Password Generation +## Password generation Passwords are generated via [Password Policies](/vault/docs/concepts/password-policies). Databases can optionally set a password policy for use across all roles or at the @@ -201,7 +201,7 @@ rule "charset" { } ``` -## Disable Character Escaping +## Disable character escaping As of Vault 1.10, you can now specify the option `disable_escaping` with a value of `true ` in some secrets engines to prevent Vault from escaping special characters in the username and password diff --git a/website/content/docs/secrets/databases/influxdb.mdx b/website/content/docs/secrets/databases/influxdb.mdx index d97e6692e9a1..5ad221238592 100644 --- a/website/content/docs/secrets/databases/influxdb.mdx +++ b/website/content/docs/secrets/databases/influxdb.mdx @@ -7,7 +7,7 @@ description: |- roles for the InfluxDB database. --- -# InfluxDB Database Secrets Engine +# InfluxDB database secrets engine @include 'x509-sha1-deprecation.mdx' diff --git a/website/content/docs/secrets/databases/mongodb.mdx b/website/content/docs/secrets/databases/mongodb.mdx index 1ce48c92c7be..f69d337fdbc5 100644 --- a/website/content/docs/secrets/databases/mongodb.mdx +++ b/website/content/docs/secrets/databases/mongodb.mdx @@ -7,7 +7,7 @@ description: |- for the MongoDB database. --- -# MongoDB Database Secrets Engine +# MongoDB database secrets engine @include 'x509-sha1-deprecation.mdx' @@ -79,7 +79,7 @@ the proper permission, it can generate credentials. username v-vaultuser-my-role-ItceCZHlp0YGn90Puy9Z-1602542024 ``` -## Client x509 Certificate Authentication +## Client x509 certificate authentication This plugin supports using MongoDB's [x509 Client-side Certificate Authentication](https://docs.mongodb.com/manual/core/security-x.509/) diff --git a/website/content/docs/secrets/databases/mongodbatlas.mdx b/website/content/docs/secrets/databases/mongodbatlas.mdx index 9a4a5b6e6071..78dc5eb58f05 100644 --- a/website/content/docs/secrets/databases/mongodbatlas.mdx +++ b/website/content/docs/secrets/databases/mongodbatlas.mdx @@ -7,7 +7,7 @@ description: |- for MongoDB Atlas databases. --- -# MongoDB Atlas Database Secrets Engine +# MongoDB atlas database secrets engine MongoDB Atlas is one of the supported plugins for the database secrets engine. This plugin generates database credentials dynamically based on configured roles for @@ -51,7 +51,7 @@ more information about setting up the database secrets engine. After the secrets engine is configured and a user/machine has a Vault token with the proper permissions, it can generate credentials. -#### Password Credentials +#### Password credentials 1. Configure a role that maps a name in Vault to a MongoDB Atlas command that executes and creates the database user credential: @@ -79,7 +79,7 @@ the proper permissions, it can generate credentials. username v-my-password-role-DKbQEg6uRn ``` -#### Client Certificate Credentials +#### Client certificate credentials 1. Configure a role that maps a name in Vault to a MongoDB Atlas command that executes and creates the X509 type database user credential: @@ -121,7 +121,7 @@ of the role: username CN=token_my-dynamic-certificate-role_1677262121 ``` -## Client Certificate Authentication +## Client certificate authentication MongoDB Atlas supports [X.509 client certificate based authentication](https://www.mongodb.com/docs/manual/tutorial/configure-x509-client-authentication/) for enhanced authentication security as an alternative to username and password authentication. diff --git a/website/content/docs/secrets/databases/mssql.mdx b/website/content/docs/secrets/databases/mssql.mdx index a24d55609684..569a94ff7e03 100644 --- a/website/content/docs/secrets/databases/mssql.mdx +++ b/website/content/docs/secrets/databases/mssql.mdx @@ -8,7 +8,7 @@ description: |- for the MSSQL database. --- -# MSSQL Database Secrets Engine +# MSSQL database secrets engine MSSQL is one of the supported plugins for the database secrets engine. This plugin generates database credentials dynamically based on configured roles for @@ -96,7 +96,7 @@ the proper permission, it can generate credentials. username v-vaultuser-my-role-r7kCtKGGr3eYQP1OGR6G-1602542258 ``` -## Example for Azure SQL Database +## Example for Azure SQL database Here is a complete example using Azure SQL Database. Note that databases in Azure SQL Database are [contained databases](https://docs.microsoft.com/en-us/sql/relational-databases/databases/contained-databases) and that we do not create a login for the user; instead, we associate the password directly with the user itself. Also note that you will need a separate connection and role for each Azure SQL database for which you want to generate dynamic credentials. You can use a single database backend mount for all these databases or use a separate mount for each of them. In this example, we use a custom path for the database backend. diff --git a/website/content/docs/secrets/databases/mysql-maria.mdx b/website/content/docs/secrets/databases/mysql-maria.mdx index 0b23b91f7c03..a101da85f6cb 100644 --- a/website/content/docs/secrets/databases/mysql-maria.mdx +++ b/website/content/docs/secrets/databases/mysql-maria.mdx @@ -7,7 +7,7 @@ description: |- for the MySQL database. --- -# MySQL/MariaDB Database Secrets Engine +# MySQL/MariaDB database secrets engine @include 'x509-sha1-deprecation.mdx' @@ -89,7 +89,7 @@ the proper permission, it can generate credentials. username v_vaultuser_my-role_crBWVqVh2Hc1 ``` -## Client x509 Certificate Authentication +## Client x509 certificate authentication This plugin supports using MySQL's [x509 Client-side Certificate Authentication](https://dev.mysql.com/doc/refman/8.0/en/using-encrypted-connections.html#using-encrypted-connections-client-side-configuration) diff --git a/website/content/docs/secrets/databases/postgresql.mdx b/website/content/docs/secrets/databases/postgresql.mdx index 691f7b8e1b69..c1bcb8b77d78 100644 --- a/website/content/docs/secrets/databases/postgresql.mdx +++ b/website/content/docs/secrets/databases/postgresql.mdx @@ -7,7 +7,7 @@ description: |- roles for the PostgreSQL database. --- -# PostgreSQL Database Secrets Engine +# PostgreSQL database secrets engine PostgreSQL is one of the supported plugins for the database secrets engine. This plugin generates database credentials dynamically based on configured roles for diff --git a/website/content/docs/secrets/databases/redis.mdx b/website/content/docs/secrets/databases/redis.mdx index 9d861cda15c7..9ac6b933d6fb 100644 --- a/website/content/docs/secrets/databases/redis.mdx +++ b/website/content/docs/secrets/databases/redis.mdx @@ -7,7 +7,7 @@ description: |- roles for the Redis database, and also supports [Static Roles](/vault/docs/secrets/databases#static-roles). --- -# Redis Database Secrets Engine +# Redis database secrets engine Redis is one of the supported plugins for the database secrets engine. This plugin generates database credentials dynamically based on configured roles for diff --git a/website/content/docs/secrets/databases/rediselasticache.mdx b/website/content/docs/secrets/databases/rediselasticache.mdx index e35aa23c0000..b8f624b76569 100644 --- a/website/content/docs/secrets/databases/rediselasticache.mdx +++ b/website/content/docs/secrets/databases/rediselasticache.mdx @@ -6,7 +6,7 @@ description: |- This plugin generates static credentials for existing managed roles. --- -# Redis ElastiCache Database Secrets Engine +# Redis ElastiCache database secrets engine Redis ElastiCache is one of the supported plugins for the database secrets engine. This plugin generates static credentials for existing managed roles. diff --git a/website/content/docs/secrets/databases/redshift.mdx b/website/content/docs/secrets/databases/redshift.mdx index 3676925b62cf..1dab02ad79e5 100644 --- a/website/content/docs/secrets/databases/redshift.mdx +++ b/website/content/docs/secrets/databases/redshift.mdx @@ -7,7 +7,7 @@ description: |- roles for the AWS Redshift database service. --- -# Redshift Database Secrets Engine +# Redshift database secrets engine Redshift is a supported plugin for the database secrets engine. This plugin generates database credentials dynamically based on configured roles for diff --git a/website/content/docs/secrets/databases/snowflake.mdx b/website/content/docs/secrets/databases/snowflake.mdx index 93f1bc7c9f8e..bddbee649894 100644 --- a/website/content/docs/secrets/databases/snowflake.mdx +++ b/website/content/docs/secrets/databases/snowflake.mdx @@ -7,7 +7,7 @@ description: |- roles for Snowflake hosted databases. --- -# Snowflake Database Secrets Engine +# Snowflake database secrets engine Snowflake is one of the supported plugins for the database secrets engine. This plugin generates database credentials dynamically based on configured roles for Snowflake-hosted @@ -74,9 +74,9 @@ The Snowflake database secrets engine uses After the secrets engine is configured, configure dynamic and static roles to enable generating credentials. -### Dynamic Roles +### Dynamic roles -#### Password Credentials +#### Password credentials 1. Configure a role that creates new Snowflake users with password credentials: @@ -105,7 +105,7 @@ enable generating credentials. username v_root_my_password_role_fU0jqEy4wMNoAY2h60yd_1610561532 ``` -#### Key Pair Credentials +#### Key pair credentials 1. Configure a role that creates new Snowflake users with key pair credentials: @@ -143,9 +143,9 @@ enable generating credentials. for a list of clients and instructions for establishing a connection using key pair authentication. -### Static Roles +### Static roles -#### Password Credentials +#### Password credentials 1. Configure a static role that rotates the password credential for an existing Snowflake user. @@ -171,7 +171,7 @@ enable generating credentials. username my-existing-couchbase-user ``` -#### Key Pair Credentials +#### Key pair credentials 1. Configure a static role that rotates the key pair credential for an existing Snowflake user: @@ -206,7 +206,7 @@ enable generating credentials. for a list of clients and instructions for establishing a connection using key pair authentication. -## Key Pair Authentication +## Key pair authentication Snowflake supports using [key pair authentication](https://docs.snowflake.com/en/user-guide/key-pair-auth.html) for enhanced authentication security as an alternative to username and password authentication. diff --git a/website/content/docs/secrets/gcp.mdx b/website/content/docs/secrets/gcp.mdx index eef36380d71b..985f4113c6f8 100644 --- a/website/content/docs/secrets/gcp.mdx +++ b/website/content/docs/secrets/gcp.mdx @@ -6,7 +6,7 @@ description: |- service account keys and OAuth tokens based on IAM policies. --- -# Google Cloud Secrets Engine +# Google Cloud secrets engine The Google Cloud Vault secrets engine dynamically generates Google Cloud service account keys and OAuth tokens based on IAM policies. This enables users to gain @@ -75,7 +75,7 @@ when creating or updating the roleset. For more information on the differences between rolesets and static accounts, see the [things to note](#things-to-note) section below. -### Roleset Policy Considerations +### Roleset policy considerations Starting with Vault 1.8.0, existing permissive policies containing globs for the GCP Secrets Engine may grant additional privileges due to the introduction @@ -150,7 +150,7 @@ below. For more information on creating and managing rolesets, see the [GCP secrets engine API docs][api] docs. -## Static Accounts +## Static accounts Static accounts are GCP service accounts that are created outside of Vault and then provided to Vault to generate access tokens or keys. You can also use Vault to optionally manage IAM bindings @@ -211,7 +211,7 @@ below. For more information on creating and managing static accounts, see the [GCP secrets engine API docs][api] docs. -## Impersonated Accounts +## Impersonated accounts Impersonated accounts are a way to generate an OAuth2 [access token](/vault/docs/secrets/gcp#access-tokens) that is granted the permissions and accesses of another given service account. These access @@ -241,7 +241,7 @@ After the secrets engine is configured and a user/machine has a Vault token with the proper permission, it can generate credentials. Depending on how the Vault role was configured, you can generate OAuth2 tokens or service account keys. -### Access Tokens +### Access tokens To generate OAuth2 [access tokens](https://cloud.google.com/docs/authentication/token-types#access), read from the [`gcp/.../token`](/vault/api-docs/secret/gcp#generate-secret-iam-service-account-creds-oauth2-access-token) @@ -292,7 +292,7 @@ to GCP APIs: $ curl -H "Authorization: Bearer ya29.c.ElodBmNPwHUNY5gcBpnXcE4ywG4w1k..." ``` -### Service Account Keys +### Service account keys To generate service account keys, read from `gcp/.../key`. Vault returns the service account key data as a base64-encoded string in the `private_key_data` field. This can @@ -472,13 +472,13 @@ minimum scope(s): https://www.googleapis.com/auth/cloud-platform ``` -### Required Permissions +### Required permissions The credentials given to Vault must have the following permissions when using rolesets at the project level: ```text -# Service Account + Key Admin +# Service account + key admin iam.serviceAccounts.create iam.serviceAccounts.delete iam.serviceAccounts.get @@ -507,7 +507,7 @@ iam.serviceAccountKeys.list When using rolesets or static accounts with bindings, Vault must have the following permissions: ```text -# IAM Policy Changes +# IAM policy changes ..getIamPolicy ..setIamPolicy ``` @@ -524,7 +524,7 @@ resourcemanager.projects.setIamPolicy compute.*.getIamPolicy compute.*.setIamPolicy -# BigQuery Datasets +# BigQuery datasets bigquery.datasets.get bigquery.datasets.update ``` @@ -544,16 +544,16 @@ You can either: This means to update access on the dataset, Vault must be able to update the dataset's metadata. -### Root Credential Rotation +### Root credential rotation If the mount is configured with credentials directly, the credential's key may be rotated to a Vault-generated value that is not accessible by the operator. For more details on this operation, please see the [Root Credential Rotation](/vault/api-docs/secret/gcp#rotate-root-credentials) API docs. -## Things to Note +## Things to note -### Rolesets vs. Static Accounts +### Rolesets vs. static accounts Advantages of rolesets: @@ -574,7 +574,7 @@ Disadvantages of static accounts: - Self management of service accounts is necessary. -### Access Tokens vs. Service Account Keys +### Access tokens vs. service account keys Advantages of `access_tokens`: @@ -601,7 +601,7 @@ and is never accessible to other users, and the underlying key can be rotated. See the [GCP API documentation][api] for more information on rotation. -### Service Accounts are Tied to Rolesets +### Service accounts are tied to rolesets Service Accounts are created when the roleset is created (or updated) rather than each time a secret is generated. This may be different from how other @@ -619,7 +619,7 @@ secrets engines behave, but it is for good reasons: Accounts were created per secret, this quota limit would reduce the number of secrets that can be generated. -### Service Account Keys Quota Limits +### Service account keys quota limits GCP IAM has a hard limit (currently 10) on the number of Service Account keys. Attempts to generate more keys will result in an error. If you find yourself @@ -634,12 +634,12 @@ running into this limit, consider the following: - Where possible, use OAuth2 access tokens instead of Service Account keys. -### Resources in IAM Bindings Must Exist at Roleset or Static Account Creation +### Resources in IAM bindings must exist at roleset or static account creation Because the bindings for the Service Account are set during roleset/static account creation, resources that do not exist will fail the `getIamPolicy` API call. -### Roleset Creation May Partially Fail +### Roleset creation may partially fail Every Service Account creation, key creation, and IAM policy change is a GCP API call per resource. If an API call to one of these resources fails, the roleset @@ -649,7 +649,7 @@ These rollbacks are API calls, so they may also fail. The secrets engine uses a WAL to ensure that unused bindings are cleaned up. In the case of quota limits, you may need to clean these up manually. -### Do Not Modify Vault-owned IAM Accounts +### Do not modify vault-owned IAM accounts While Vault will initially create and assign permissions to IAM service accounts, it is possible that an external user deletes or modifies this service @@ -665,7 +665,7 @@ vault-@... Communicate with your teams (or use IAM permissions) to not modify these resources. -## Help & Support +## Help & support The Google Cloud Vault secrets engine is written as an external Vault plugin and thus exists outside the main Vault repository. It is automatically bundled with @@ -693,9 +693,9 @@ for more details. [quotas]: https://cloud.google.com/compute/quotas [service-accounts]: https://cloud.google.com/compute/docs/access/service-accounts -## Upgrade Guides +## Upgrade guides -### Deprecation of Access Token Leases +### Deprecation of access token leases ~> **NOTE**: This deprecation only affects access tokens. There is no change to the `service_account_key` secret type. diff --git a/website/content/docs/secrets/gcpkms.mdx b/website/content/docs/secrets/gcpkms.mdx index 8c3c28bc43ad..6d8a3342b402 100644 --- a/website/content/docs/secrets/gcpkms.mdx +++ b/website/content/docs/secrets/gcpkms.mdx @@ -6,7 +6,7 @@ description: |- KMS for encryption/decryption of data and KMS key management through Vault. --- -# Google Cloud KMS Secrets Engine +# Google Cloud KMS secrets engine The Google Cloud KMS Vault secrets engine provides encryption and key management via [Google Cloud KMS][kms]. It supports management of keys, including creation, @@ -196,7 +196,7 @@ Google Cloud manages the key ring which is used to encrypt and decrypt data. This will make it impossible to encrypt, decrypt, or sign values by conventional means. -### Asymmetric Decryption +### Asymmetric decryption This section describes using a Cloud KMS key for asymmetric decryption. In this model Google Cloud manages the key ring and exposes the public key via an API @@ -270,7 +270,7 @@ which decrypts the value using the corresponding private key. plaintext hello world ``` -### Asymmetric Signing +### Asymmetric signing This section describes using a Cloud KMS key for asymmetric signing. In this model Google Cloud manages the key ring and exposes the public key via an API @@ -373,7 +373,7 @@ minimum scope(s): https://www.googleapis.com/auth/kms ``` -### Required Permissions +### Required permissions The credentials given to Vault must have the following role: @@ -421,7 +421,7 @@ The plugin is free and open source. KMS costs vary by key type and the number of operations. Please see the [Cloud KMS pricing page][kms-pricing] for more details. -## Help & Support +## Help & support The Google Cloud KMS Vault secrets engine is written as an external Vault plugin. The code lives outside the main Vault repository. It is automatically diff --git a/website/content/docs/secrets/identity/identity-token.mdx b/website/content/docs/secrets/identity/identity-token.mdx index 745f0822d831..8e14200e71d1 100644 --- a/website/content/docs/secrets/identity/identity-token.mdx +++ b/website/content/docs/secrets/identity/identity-token.mdx @@ -4,7 +4,7 @@ page_title: Identity Tokens description: Details and best practices for identity tokens. --- -# Identity Tokens +# Identity tokens ## Introduction @@ -18,7 +18,7 @@ unauthenticated endpoint following OIDC discovery and JWKS conventions, which should be directly usable by JWT/OIDC libraries. An introspection endpoint is also provided by Vault for token verification. -### Roles and Keys +### Roles and keys OIDC-compliant ID tokens are generated against a role which allows configuration of token claims via a templating system, token ttl, and a way to specify which @@ -51,7 +51,7 @@ A key's list of allowed client IDs limits which roles may reference the key. The parameter may be set to `*` to allow all roles. The validity evaluation is made when a token is requested, not during configuration. -### Token Contents and Templates +### Token contents and templates Identity tokens will always contain, at a minimum, the claims required by OIDC: @@ -140,14 +140,14 @@ The full list of template parameters is shown below: | `time.now.plus.` | Current time plus a [duration format string](/vault/docs/concepts/duration-format) | | `time.now.minus.` | Current time minus a [duration format string](/vault/docs/concepts/duration-format) | -### Token Generation +### Token generation An authenticated client may request a token using the [token generation endpoint](/vault/api-docs/secret/identity/tokens#generate-a-signed-id-token). The token will be generated per the requested role's specifications, for the requester's entity. It is not possible to generate tokens for an arbitrary entity. -### Verifying Authenticity of ID Tokens Generated by Vault +### Verifying authenticity of ID tokens generated by Vault An identity token may be verified by the client party using the public keys published by Vault, or via a Vault-provided introspection endpoint. @@ -170,7 +170,7 @@ cannot be determined from the token alone. Unlike the .well-known endpoint, acce introspection endpoint does require a valid Vault token and sufficient authorization. -### Issuer Considerations +### Issuer considerations The identity token system has one configurable parameter: issuer. The issuer `iss` claim is particularly important for proper validation of the token by diff --git a/website/content/docs/secrets/identity/index.mdx b/website/content/docs/secrets/identity/index.mdx index 3998135fa433..5d50d6dd4739 100644 --- a/website/content/docs/secrets/identity/index.mdx +++ b/website/content/docs/secrets/identity/index.mdx @@ -4,7 +4,7 @@ page_title: Identity - Secrets Engines description: The Identity secrets engine for Vault manages client identities. --- -# Identity Secrets Engine +# Identity secrets engine Name: `identity` diff --git a/website/content/docs/secrets/identity/oidc-provider.mdx b/website/content/docs/secrets/identity/oidc-provider.mdx index 3ad049eb5e9c..f9a4b2233814 100644 --- a/website/content/docs/secrets/identity/oidc-provider.mdx +++ b/website/content/docs/secrets/identity/oidc-provider.mdx @@ -5,7 +5,7 @@ description: >- Setup and configuration for Vault as an OpenID Connect (OIDC) identity provider. --- -# OIDC Identity Provider +# OIDC identity provider Vault is an OpenID Connect ([OIDC](https://openid.net/specs/openid-connect-core-1_0.html)) identity provider. This enables client applications that speak the OIDC protocol to leverage @@ -154,7 +154,7 @@ for details on configuring OIDC authentication for other HashiCorp products: Otherwise, refer to the documentation of the specific OIDC relying party for usage details. -## Supported Flows +## Supported flows The Vault OIDC provider feature currently supports the following authentication flow: diff --git a/website/content/docs/secrets/index.mdx b/website/content/docs/secrets/index.mdx index 7e23aee24fa7..14f218365f59 100644 --- a/website/content/docs/secrets/index.mdx +++ b/website/content/docs/secrets/index.mdx @@ -4,7 +4,7 @@ page_title: Secrets Engines description: Secrets engines are mountable engines that store or generate secrets in Vault. --- -# Secrets Engines +# Secrets engines Secrets engines are components which store, generate, or encrypt data. Secrets engines are incredibly flexible, so it is easiest to think about them in terms @@ -22,7 +22,7 @@ secrets engine. In this way, each secrets engine defines its own paths and properties. To the user, secrets engines behave similar to a virtual filesystem, supporting operations like read, write, and delete. -## Secrets Engines Lifecycle +## Secrets engines lifecycle Most secrets engines can be enabled, disabled, tuned, and moved via the CLI or API. @@ -60,7 +60,7 @@ cannot create a mount point that is named as a prefix of an existing mount. As an example, the mounts `foo/bar` and `foo/baz` can peacefully coexist with each other whereas `foo` and `foo/baz` cannot -## Barrier View +## Barrier view Secrets engines receive a _barrier view_ to the configured Vault physical storage. This is a lot like a [chroot](https://en.wikipedia.org/wiki/Chroot). diff --git a/website/content/docs/secrets/key-management/awskms.mdx b/website/content/docs/secrets/key-management/awskms.mdx index a841ee3eaf70..8cf557c5c1c8 100644 --- a/website/content/docs/secrets/key-management/awskms.mdx +++ b/website/content/docs/secrets/key-management/awskms.mdx @@ -59,13 +59,13 @@ $ vault write keymgmt/kms/example-kms \ Refer to the AWS KMS [API documentation](/vault/api-docs/secret/key-management/awskms) for a detailed description of individual configuration parameters. -## Key Transfer Specification +## Key transfer specification Keys are securely transferred from the secrets engine to AWS KMS regions in accordance with the AWS KMS [Bring Your Own Key](https://docs.aws.amazon.com/kms/latest/developerguide/importing-keys.html) specification. -## Key Rotation +## Key rotation AWS KMS keys with imported key material are not eligible for [automatic key rotation](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html) @@ -74,7 +74,7 @@ within AWS KMS. As such, key rotations performed by the secrets engine use the process. Applications should refer to the [alias](https://docs.aws.amazon.com/kms/latest/developerguide/kms-alias.html) associated with imported keys. Aliases will always have the form: `hashicorp/-`. -## Key Purpose Compatability +## Key purpose compatability The following table defines which key [purposes](/vault/api-docs/secret/key-management#purpose) can be used for each key type supported by AWS KMS. diff --git a/website/content/docs/secrets/key-management/azurekeyvault.mdx b/website/content/docs/secrets/key-management/azurekeyvault.mdx index 62e906e4d59c..d56b8b8d551e 100644 --- a/website/content/docs/secrets/key-management/azurekeyvault.mdx +++ b/website/content/docs/secrets/key-management/azurekeyvault.mdx @@ -4,7 +4,7 @@ page_title: Azure Key Vault - Key Management - Secrets Engines description: Azure Key Vault is a supported KMS provider of the Key Management secrets engine. --- -# Azure Key Vault +# Azure key Vault The Key Management secrets engine supports lifecycle management of keys in named [Azure Key Vault](https://docs.microsoft.com/en-us/azure/key-vault/) instances. @@ -57,13 +57,13 @@ $ vault write keymgmt/kms/example-kms \ Refer to the Azure Key Vault [API documentation](/vault/api-docs/secret/key-management/azurekeyvault) for a detailed description of individual configuration parameters. -## Key Transfer Specification +## Key transfer specification Keys are securely transferred from the secrets engine to Azure key vault instances in accordance with the Azure [Bring Your Own Key](https://docs.microsoft.com/en-us/azure/key-vault/keys/byok-specification) specification. -## Key Purpose Compatability +## Key purpose compatability The following table defines which key [purposes](/vault/api-docs/secret/key-management#purpose) can be used for each key type supported by GCP Cloud KMS. @@ -74,7 +74,7 @@ for each key type supported by GCP Cloud KMS. | `rsa-3072` | [All purposes](/vault/api-docs/secret/key-management#purpose) | | `rsa-4096` | [All purposes](/vault/api-docs/secret/key-management#purpose) | -## Azure Private Link +## Azure private link The secrets engine can be configured to communicate with Azure Key Vault instances using [Azure Private Endpoints](https://docs.microsoft.com/en-us/azure/private-link/private-endpoint-overview). diff --git a/website/content/docs/secrets/key-management/gcpkms.mdx b/website/content/docs/secrets/key-management/gcpkms.mdx index bd0f4072b3f7..7e358cc31f7b 100644 --- a/website/content/docs/secrets/key-management/gcpkms.mdx +++ b/website/content/docs/secrets/key-management/gcpkms.mdx @@ -53,12 +53,12 @@ $ vault write keymgmt/kms/example-kms \ Refer to the GCP Cloud KMS [API documentation](/vault/api-docs/secret/key-management/gcpkms) for a detailed description of individual configuration parameters. -## Key Transfer Specification +## Key transfer specification Keys are securely transferred from the secrets engine to GCP Cloud KMS in accordance with the [key import](https://cloud.google.com/kms/docs/key-import) specification. -## Key Purpose Compatability +## Key purpose compatability The following table defines which key [purposes](/vault/api-docs/secret/key-management#purpose) can be used for each key type supported by GCP Cloud KMS. diff --git a/website/content/docs/secrets/key-management/index.mdx b/website/content/docs/secrets/key-management/index.mdx index 866aed868a38..5e81a225cf2e 100644 --- a/website/content/docs/secrets/key-management/index.mdx +++ b/website/content/docs/secrets/key-management/index.mdx @@ -6,7 +6,7 @@ description: >- management of cryptographic keys in various key management service (KMS) providers. --- -# Key Management Secrets Engine +# Key management secrets engine -> **Note**: This secrets engine requires [Vault Enterprise](https://www.hashicorp.com/products/vault/) (1.6.0+) with the Advanced Data @@ -129,7 +129,7 @@ manage the lifecycle of cryptographic keys in [supported KMS providers](#kms-pro To permanently delete the key from the secrets engine, the [delete key](/vault/api-docs/secret/key-management#delete-key) API may be invoked. -## Key Types +## Key types The Key Management secrets engine supports generation of the following key types: @@ -141,7 +141,7 @@ The Key Management secrets engine supports generation of the following key types - `ecdsa-p384` - ECDSA using the P-384 elliptic curve (asymmetric) - `ecdsa-p521` - ECDSA using the P-521 elliptic curve (asymmetric) -## KMS Providers +## KMS providers The Key Management secrets engine supports lifecycle management of keys in the following KMS providers: diff --git a/website/content/docs/secrets/kmip-profiles.mdx b/website/content/docs/secrets/kmip-profiles.mdx index 95b098c5451f..8be5555e5b89 100644 --- a/website/content/docs/secrets/kmip-profiles.mdx +++ b/website/content/docs/secrets/kmip-profiles.mdx @@ -8,7 +8,7 @@ description: |- environment or context of use. --- -# KMIP Profiles Version 1.4 +# KMIP profiles version 1.4 This document specifies conformance clauses in accordance with the OASIS TC Process ([TC-PROC section 2.18 paragraph 8a][tc-proc-2.18] ) for the KMIP Specification ([KMIP-SPEC 12.1 and 12.2][kmip-spec]) for a KMIP server or KMIP client through profiles that define the @@ -17,7 +17,7 @@ KMIP server and client interaction. Vault implements version 1.4 of the following Key Management Interoperability Protocol Profiles: -## [Baseline Server][baseline-server] +## [Baseline server][baseline-server] 1. Supports the following objects: | Object | Supported | @@ -117,7 +117,7 @@ Vault implements version 1.4 of the following Key Management Interoperability Pr 11. Optionally supports any clause within [KMIP-SPEC][kmip-spec] that is not listed above 12. Optionally supports extensions outside the scope of this standard (e.g., vendor extensions, conformance clauses) that do not contradict any KMIP requirements - We do not have any extensions -## [Symmetric Key Lifecycle Server][lifecycle-server] +## [Symmetric key lifecycle server][lifecycle-server] 1. SHALL conform to the [Baseline Server][baseline-server] 2. Supports the following objects: @@ -158,7 +158,7 @@ Vault implements version 1.4 of the following Key Management Interoperability Pr 6. MAY support any clause within [KMIP-SPEC][kmip-spec] provided it does not conflict with any other clause within the section [Symmetric Key Lifecycle Server][lifecycle-server] 7. MAY support extensions outside the scope of this standard (e.g., vendor extensions, conformance clauses) that do not contradict any KMIP requirements. -## [Basic Cryptographic Server][basic-cryptographic-server] +## [Basic cryptographic server][basic-cryptographic-server] 1. SHALL conform to the [Baseline Server][baseline-server] 2. Supports the following client-to-server operations: @@ -171,7 +171,7 @@ Vault implements version 1.4 of the following Key Management Interoperability Pr 3. MAY support any clause within [KMIP-SPEC][kmip-spec] provided it does not conflict with any other clause within the section [Basic Cryptographic Server][basic-cryptographic-server] 4. MAY support extensions outside the scope of this standard (e.g., vendor extensions, conformance clauses) that do not contradict any KMIP requirements. -## [Asymmetric Key Lifecycle Server][asymmetric-key-lifecycle-server] +## [Asymmetric key lifecycle server][asymmetric-key-lifecycle-server] 1. SHALL conform to the [Baseline Server][baseline-server] @@ -219,7 +219,7 @@ Vault implements version 1.4 of the following Key Management Interoperability Pr 6. MAY support any clause within [KMIP-SPEC][kmip-spec] provided it does not conflict with any other clause within the section [Symmetric Key Lifecycle Server][lifecycle-server] 7. MAY support extensions outside the scope of this standard (e.g., vendor extensions, conformance clauses) that do not contradict any KMIP requirements. -## [Advanced Cryptographic Server][advanced-cryptographic-server] +## [Advanced cryptographic server][advanced-cryptographic-server] 1. SHALL conform to the [Baseline Server][baseline-server] 2. Supports the following client-to-server operations: diff --git a/website/content/docs/secrets/kmip.mdx b/website/content/docs/secrets/kmip.mdx index aaac0aaf65dc..d1ce62b3870f 100644 --- a/website/content/docs/secrets/kmip.mdx +++ b/website/content/docs/secrets/kmip.mdx @@ -6,7 +6,7 @@ description: |- handle the lifecycle of its KMIP managed objects. --- -# KMIP Secrets Engine +# KMIP secrets engine -> **Note**: This secret engine requires [Vault Enterprise](https://www.hashicorp.com/products/vault/) with the Advanced Data Protection Module. @@ -20,7 +20,7 @@ its storage and lifecycle to a key management server. Vault's KMIP secrets engine listens on a separate port from the standard Vault listener. Each Vault server in a Vault cluster configured with a KMIP secrets engine uses the same listener configuration. The KMIP listener defaults to port 5696 and is configurable to alternative ports, for example, if there are multiple KMIP secrets engine mounts configured. KMIP clients connect and authenticate to this KMIP secrets engine listener port using generated TLS certificates. KMIP clients may connect directly to any of the Vault servers on the configured KMIP port. A layer 4 tcp load balancer may be used in front of the Vault server's KMIP ports. The load balancer should support long-lived connections and it may use a round robin routing algorithm as Vault servers will forward to the primary Vault server, if necessary. -## KMIP Conformance +## KMIP conformance Vault implements version 1.4 of the following Key Management Interoperability Protocol Profiles: @@ -77,7 +77,7 @@ requests. ## Usage -### Scopes and Roles +### Scopes and roles The KMIP secrets engine uses the concept of scopes to partition KMIP managed object storage into multiple named buckets. Within a scope, roles can be created @@ -104,7 +104,7 @@ allowed operations for it. Success! Data written to: kmip/scope/my-service/role/admin ``` -### Supported KMIP Operations +### Supported KMIP operations The KMIP secrets engine currently supports the following set of operations: @@ -151,7 +151,7 @@ operation_all operation_none ``` -### Client Certificate Generation +### Client certificate generation Once a scope and role has been created, client certificates can be generated for that role. The client certificate can then be provided to applications and @@ -217,7 +217,7 @@ which will be used when evaluating permissions during a KMIP request. serial_number 317328055225536560033788492808123425026102524390 ``` -### Client Certificate Signing +### Client certificate signing As an alternative to the above section on generating client certificates, the KMIP secrets engine supports signing of Certificate Signing Requests diff --git a/website/content/docs/secrets/kubernetes.mdx b/website/content/docs/secrets/kubernetes.mdx index f6c9eb26a28f..63d7680eeeef 100644 --- a/website/content/docs/secrets/kubernetes.mdx +++ b/website/content/docs/secrets/kubernetes.mdx @@ -6,7 +6,7 @@ description: >- tokens, service accounts, role bindings, and roles dynamically. --- -# Kubernetes Secrets Engine +# Kubernetes secrets engine @include 'x509-sha1-deprecation.mdx' @@ -208,7 +208,7 @@ management tool. token_default_ttl="10m" ``` -## Generating Credentials +## Generating credentials After a user has authenticated to Vault and has sufficient permissions, a write to the `creds` endpoint for the Vault role will generate and return a new service account token. @@ -342,7 +342,7 @@ $ echo 'eyJhbGc...' | cut -d'.' -f2 | base64 -d {"aud":["another-custom-audience"]... ``` -## Automatically Managing Roles and Service Accounts +## Automatically managing roles and service accounts When configuring the Vault role, you can pass in parameters to specify that you want to automatically generate the Kubernetes service account and role binding, diff --git a/website/content/docs/secrets/kv/index.mdx b/website/content/docs/secrets/kv/index.mdx index 815f6cdce22b..4cba4d80aa5e 100644 --- a/website/content/docs/secrets/kv/index.mdx +++ b/website/content/docs/secrets/kv/index.mdx @@ -4,7 +4,7 @@ page_title: KV - Secrets Engines description: The KV secrets engine can store arbitrary secrets. --- -# KV Secrets Engine +# KV secrets engine The `kv` secrets engine is a generic Key-Value store used to store arbitrary secrets within the configured physical storage for Vault. This backend can be @@ -12,7 +12,7 @@ run in one of two modes; either it can be configured to store a single value for a key or, versioning can be enabled and a configurable number of versions for each key will be stored. -## KV Version 1 +## KV version 1 When running the `kv` secrets backend non-versioned, only the most recently written value for a key will be preserved. The benefits of non-versioned `kv` @@ -24,7 +24,7 @@ and no locking. More information about running in this mode can be found in the [K/V Version 1 Docs](/vault/docs/secrets/kv/kv-v1) -## KV Version 2 +## KV version 2 When running v2 of the `kv` backend a key can retain a configurable number of versions. This defaults to 10 versions. The older versions' metadata and data diff --git a/website/content/docs/secrets/kv/kv-v1.mdx b/website/content/docs/secrets/kv/kv-v1.mdx index ba010881f344..ee2f29da987f 100644 --- a/website/content/docs/secrets/kv/kv-v1.mdx +++ b/website/content/docs/secrets/kv/kv-v1.mdx @@ -4,7 +4,7 @@ page_title: KV - Secrets Engines description: The KV secrets engine can store arbitrary secrets. --- -# KV Secrets Engine - Version 1 +# KV secrets engine - version 1 The `kv` secrets engine is used to store arbitrary secrets within the configured physical storage for Vault. diff --git a/website/content/docs/secrets/kv/kv-v2.mdx b/website/content/docs/secrets/kv/kv-v2.mdx index 6f26ba786cc7..0f33eaeefbfe 100644 --- a/website/content/docs/secrets/kv/kv-v2.mdx +++ b/website/content/docs/secrets/kv/kv-v2.mdx @@ -4,7 +4,7 @@ page_title: KV - Secrets Engines description: The KV secrets engine can store arbitrary secrets. --- -# KV Secrets Engine - Version 2 +# KV secrets engine - version 2 The `kv` secrets engine is used to store arbitrary secrets within the configured physical storage for Vault. @@ -41,7 +41,7 @@ Additionally, when running a dev-mode server, the v2 `kv` secrets engine is enab path `secret/` (for non-dev servers, it is currently v1). It can be disabled, moved, or enabled multiple times at different paths. Each instance of the KV secrets engine is isolated and unique. -## Upgrading from Version 1 +## Upgrading from version 1 An existing version 1 kv store can be upgraded to a version 2 kv store via the CLI or API, as shown below. This will start an upgrade process to upgrade the existing key/value data to a versioned format. The mount will be inaccessible during this process. This process could take a long time, so plan accordingly. @@ -73,7 +73,7 @@ $ curl \ http://127.0.0.1:8200/v1/sys/mounts/secret/tune ``` -## ACL Rules +## ACL rules The version 2 kv store uses a prefixed API, which is different from the version 1 API. Before upgrading from a version 1 kv the ACL rules @@ -412,7 +412,7 @@ You can also use [Vault's password policy](/vault/docs/concepts/password-policie password !hh&be1e4j16dVc0ggae ``` -### Deleting and Destroying Data +### Deleting and destroying data When deleting data the standard `vault kv delete` command will perform a soft delete. It will mark the version as deleted and populate a `deletion_time` @@ -465,7 +465,7 @@ See the commands below for more information: Success! Data written to: secret/destroy/my-secret ``` -### Key Metadata +### Key metadata All versions and key metadata can be tracked with the metadata command & API. Deleting the metadata key will cause all metadata and versions for that key to diff --git a/website/content/docs/secrets/ldap.mdx b/website/content/docs/secrets/ldap.mdx index 5a7d8178878a..c4551ff6e068 100644 --- a/website/content/docs/secrets/ldap.mdx +++ b/website/content/docs/secrets/ldap.mdx @@ -5,7 +5,7 @@ description: >- The LDAP secret engine manages LDAP entry passwords. --- -# LDAP Secrets Engine +# LDAP secrets engine @include 'x509-sha1-deprecation.mdx' @@ -71,7 +71,7 @@ There are many object classes that provide `userPassword` including for example: - `person` - `posixAccount` -#### Resource Access Control Facility (RACF) +#### Resource access control facility (RACF) For managing IBM's Resource Access Control Facility (RACF) security system, the secret engine must be configured to use the schema `racf`. @@ -88,7 +88,7 @@ $ vault write ldap/config \ password_policy=racf_password_policy ``` -#### Active Directory (AD) +#### Active directory (AD) For managing Active Directory instances, the secret engine must be configured to use the schema `ad`. @@ -101,7 +101,7 @@ $ vault write ldap/config \ schema=ad ``` -## Static Credentials +## Static credentials ### Setup @@ -121,14 +121,14 @@ $ vault write ldap/config \ $ vault read ldap/static-cred/hashicorp ``` -### Password Rotation +### Password rotation Passwords can be managed in two ways: - automatic time based rotation - manual rotation -### Auto Password Rotation +### Auto password rotation Passwords will automatically be rotated based on the `rotation_period` configured in the static role (minimum of 5 seconds). When requesting credentials for a static @@ -138,17 +138,17 @@ Auto-rotation is currently only supported for static roles. The `binddn` account by Vault should be rotated using the `rotate-root` endpoint to generate a password only Vault will know. -### Manual Rotation +### Manual rotation Static roles can be manually rotated using the `rotate-role` endpoint. When manually rotated the rotation period will start over. -### Deleting Static Roles +### Deleting static roles Passwords are not rotated upon deletion of a static role. The password should be manually rotated prior to deleting the role or revoking access to the static role. -## Dynamic Credentials +## Dynamic credentials ### Setup @@ -184,7 +184,7 @@ The `distinguished_names` field is an array of DNs that are created from the `cr one LDIF entry is included, the DN from each statement will be included in this field. Each entry in this field corresponds to a single LDIF statement. No de-duplication occurs and order is maintained. -### LDIF Entries +### LDIF entries User account management is provided through LDIF entries. The LDIF entries may be a base64-encoded version of the LDIF string. The string will be parsed and validated to ensure that it adheres to LDIF syntax. A good reference @@ -197,7 +197,7 @@ Some important things to remember when crafting your LDIF entries: - Multiple modifications for a `dn` can be defined in a single `modify` block. Each modification needs to close with a single dash (`-`) -### Active Directory (AD) +### Active directory (AD) For Active Directory, there are a few additional details that are important to remember: @@ -234,7 +234,7 @@ forward link/back link pairs, with the forward link able to be modified. In the group's `member` attribute is the forward link. In order to add a newly-created dynamic user to a group, we also need to issue a `modify` request to the desired group and update the group membership with the new user. -#### Active Directory LDIF Example +#### Active directory LDIF example The various `*_ldif` parameters are templates that use the [go template](https://golang.org/pkg/text/template/) language. A complete LDIF example for creating an Active Directory user account is provided here for reference: @@ -265,7 +265,7 @@ member: CN={{.Username}},OU=HashiVault,DC=adtesting,DC=lab - ``` -## Service Account Check-Out +## Service account Check-Out Service account check-out provides a library of service accounts that can be checked out by a person or by machines. Vault will automatically rotate the password each time a @@ -418,7 +418,7 @@ $ vault lease revoke ldap/library/accounting-team/check-out/PvBVG0m7pEg2940Cb3Jw All revocation operations queued successfully! ``` -## Password Generation +## Password generation This engine previously allowed configuration of the length of the password that is generated when rotating credentials. This mechanism was deprecated in Vault 1.5 in favor of @@ -433,7 +433,7 @@ rule "charset" { } ``` -## LDAP Password Policy +## LDAP password policy The LDAP secret engine does not hash or encrypt passwords prior to modifying values in LDAP. This behavior can cause plaintext passwords to be stored in LDAP. diff --git a/website/content/docs/secrets/mongodbatlas.mdx b/website/content/docs/secrets/mongodbatlas.mdx index 5d2cd62d5755..34432fa7da1f 100644 --- a/website/content/docs/secrets/mongodbatlas.mdx +++ b/website/content/docs/secrets/mongodbatlas.mdx @@ -6,7 +6,7 @@ description: |- Programmatic API Keys dynamically. --- -# MongoDB Atlas Secrets Engine +# MongoDB atlas secrets engine The MongoDB Atlas Secrets Engine generates Programmatic API keys. The created MongoDB Atlas secrets are time-based and are automatically revoked when the Vault lease expires, unless renewed. @@ -61,7 +61,7 @@ steps are usually completed by an operator or configuration management tool. ~> **Note:** It is highly recommended to _not_ use your MongoDB Atlas root account credentials. Generate a dedicated Programmatic API key with appropriate roles instead. -## Programmatic API Keys +## Programmatic API keys Programmatic API Key credential types use a Vault role to generate a Programmatic API Key at either the MongoDB Atlas Organization or Project level with the designated role(s) for programmatic access. @@ -100,7 +100,7 @@ $ vault write mongodbatlas/roles/test \ roles=GROUP_DATA_ACCESS_READ_ONLY ``` -## Programmatic API Key Network Access list +## Programmatic API key network access list ~> **Note:** MongoDB Atlas has deprecated whitelists, and the API will be disabled in June 2021. It is replaced by a similar access list API which is live now. If you specify CIDR blocks or IP addresses to allow, you need to run **Vault @@ -135,7 +135,7 @@ Verify the created Programmatic API Key Vault role has the added CIDR block and ttl 30m ``` -## TTL and Max TTL +## TTL and max TTL Programmatic API Keys Vault have a time-to-live (TTL) and maximum time-to-live (Max TTL). When a credential expires it's automatically revoked. You can set the TTL and Max TTL for each role @@ -167,7 +167,7 @@ $ vault read mongodbatlas/roles/test max_ttl 5h0m0s ``` -## Generating Credentials +## Generating credentials After a user has authenticated to Vault has has sufficient permissions, a read request to the `creds` endpoint for the role will generate and return new Programmatic API Keys: diff --git a/website/content/docs/secrets/nomad.mdx b/website/content/docs/secrets/nomad.mdx index 8edf56a4db93..e5bf452bcb98 100644 --- a/website/content/docs/secrets/nomad.mdx +++ b/website/content/docs/secrets/nomad.mdx @@ -4,7 +4,7 @@ page_title: Nomad Secrets Engine description: The Nomad secrets engine for Vault generates tokens for Nomad dynamically. --- -# Nomad Secrets Engine +# Nomad secrets engine @include 'x509-sha1-deprecation.mdx' @@ -18,7 +18,7 @@ on every path, use `vault path-help` after mounting the secrets engine. ~> **Version information** ACLs are only available on Nomad 0.7.0 and above. -## Quick Start +## Quick start The first step to using the Vault secrets engine is to enable it. diff --git a/website/content/docs/secrets/pki/considerations.mdx b/website/content/docs/secrets/pki/considerations.mdx index 74e589c283fb..5227765d0c9b 100644 --- a/website/content/docs/secrets/pki/considerations.mdx +++ b/website/content/docs/secrets/pki/considerations.mdx @@ -4,14 +4,14 @@ page_title: 'PKI - Secrets Engines: Considerations' description: The PKI secrets engine for Vault generates TLS certificates. --- -# PKI Secrets Engine - Considerations +# PKI secrets engine - considerations To successfully deploy this secrets engine, there are a number of important considerations to be aware of, as well as some preparatory steps that should be undertaken. You should read all of these _before_ using this secrets engine or generating the CA to use with this secrets engine. -## Table of Contents +## Table of contents - [Be Careful with Root CAs](#be-careful-with-root-cas) - [Managed Keys](#managed-keys) @@ -50,7 +50,7 @@ generating the CA to use with this secrets engine. - [PSS Support](#pss-support) - [Issuer Storage Migration Issues](#issuer-storage-migration-issues) -## Be Careful with Root CAs +## Be careful with root CAs Vault storage is secure, but not as secure as a piece of paper in a bank vault. It is, after all, networked software. If your root CA is hosted outside of @@ -68,7 +68,7 @@ If you plan on using intermediate CAs with Vault, it is suggested that you let Vault create CSRs and do not export the private key, then sign those with your root CA (which may be a second mount of the `pki` secrets engine). -### Managed Keys +### Managed keys Since 1.10, Vault Enterprise can access private key material in a [_managed key_](/vault/docs/enterprise/managed-keys). In this case, Vault never sees the @@ -76,7 +76,7 @@ private key, and the external KMS or HSM performs certificate signing operations Managed keys are configured by selecting the `kms` type when generating a root or intermediate. -## One CA Certificate, One Secrets Engine +## One CA certificate, one secrets engine Since Vault 1.11.0, the PKI Secrets Engine supports multiple issuers in a single mount. However, in order to simplify the configuration, it is _strongly_ @@ -119,7 +119,7 @@ by the HSM and one backed by Vault -- can satisfy both use cases. Operators can make roles setting maximum TTLs for each issuer and consumers of the mount can decide which to use. -### Always Configure a Default Issuer +### Always configure a default issuer For backwards compatibility, [the default issuer](/vault/api-docs/secret/pki#read-issuers-configuration) is used to service PKI endpoints without an explicit issuer (either via path @@ -129,7 +129,7 @@ issuer's CRL. This means maintaining a default issuer is important for both backwards compatibility for issuing certificates and for ensuring revoked certificates land on a CRL. -## Key Types Matter +## Key types matter Certain key types have impacts on performance. Signing certificates from a RSA key will be slower than issuing from an ECDSA or Ed25519 key. Key generation @@ -144,7 +144,7 @@ also be more expensive. Careful consideration of both issuer and issued key types can have meaningful impacts on performance of not only Vault, but systems using these certificates. -### Cluster Performance and Key Type +### Cluster performance and key type The [benchmark-vault](https://github.com/hashicorp/vault-benchmark) project can be used to measure the performance of a Vault PKI instance. In general, @@ -198,7 +198,7 @@ The use of ACME adds additional latency into these numbers, both because certificates need to be stored and because challenge validation needs to be performed. -## Use a CA Hierarchy +## Use a CA hierarchy It is generally recommended to use a hierarchical CA setup, with a root certificate which issues one or more intermediates (based on usage), which @@ -223,7 +223,7 @@ parameter to set the Name Constraints extension](/vault/api-docs/secret/pki#perm on root and intermediate generation. This allows for several layers of separation of concerns between TLS-based services. -### Cross-Signed Intermediates +### Cross-Signed intermediates When cross-signing intermediates from two separate roots, two separate intermediate issuers will exist within the Vault PKI mount. In order to @@ -239,7 +239,7 @@ can be constructed in the following order: All requests to this issuer for signing will now present the full cross-signed chain. -## Cluster URLs are Important +## Cluster URLs are important In Vault 1.13, support for [templated AIA URLs](/vault/api-docs/secret/pki#enable_aia_url_templating-1) @@ -257,7 +257,7 @@ ACME clients to discover the URL of this cluster. address). If this configuration is not set on every Performance Replication cluster, certificate issuance (via REST and/or via ACME) will fail. -## Automate Rotation with ACME +## Automate rotation with ACME In Vault 1.14, support for the [Automatic Certificate Management Environment (ACME)](https://datatracker.ietf.org/doc/html/rfc8555) protocol has been @@ -277,7 +277,7 @@ support for ACME; no client functionality has been included. Aligning with Let's Encrypt, we do not support the optional `NotBefore` and `NotAfter` order request parameters. -### ACME Stores Certificates +### ACME stores certificates Because ACME requires stored certificates in order to function, the notes [below about automating tidy](#automate-crl-building-and-tidying) are @@ -297,7 +297,7 @@ Scalability](#cluster-scalability) section, because these roles have of PR clusters; standby nodes, if contacted, will transparently forward all requests to the active node. -### ACME Role Restrictions Require EAB +### ACME role restrictions require EAB Because ACME by default has no external authorization engine and is unauthenticated from a Vault perspective, the use of roles with ACME @@ -328,7 +328,7 @@ are that role templating, based on entity information, cannot be used as there is no token and thus no entity associated with the request, even when EAB binding is used. -### ACME and the Public Internet +### ACME and the public internet Using ACME is possible over the public internet; public CAs like Let's Encrypt offer this as a service. Similarly, organizations running internal PKI @@ -346,7 +346,7 @@ System administrators of Vault instances can enforce this by [setting the `VAULT_DISABLE_PUBLIC_ACME=true` environment variable](/vault/api-docs/secret/pki#acme-external-account-bindings). -### ACME Errors are in Server Logs +### ACME errors are in server logs Because the ACME client is not necessarily trusted (as account registration may not be tied to a valid Vault token when EAB is not used), many error @@ -356,7 +356,7 @@ the client's logs, if any, (e.g., certbot will state the log location on errors), and then correlate with Vault server logs to identify the failure reason. -### ACME Security Considerations +### ACME security considerations ACME allows any client to use Vault to make some sort of external call; while the design of ACME attempts to minimize this scope and will prohibit @@ -384,7 +384,7 @@ places no restrictions on requesting client/destination identifier validations paths; a client could use a HTTP challenge to force Vault to reach out to a server on a network it could otherwise not access. -### ACME and Client Counting +### ACME and client counting In Vault 1.14, ACME contributes differently to usage metrics than other interactions with the PKI Secrets Engine. Due to its use of unauthenticated @@ -397,7 +397,7 @@ renewals, other ACME clients, mounts, and namespaces, contributing to the activity log presently as a non-entity token attributed to the first mount which created that request. -## Keep Certificate Lifetimes Short, For CRL's Sake +## Keep certificate lifetimes short, for CRL's sake This secrets engine aligns with Vault's philosophy of short-lived secrets. As such it is not expected that CRLs will grow large; the only place a private key @@ -442,7 +442,7 @@ is down. still can be expensive with lots of certificates, it will be done on a schedule rather than on demand. -### NotAfter Behavior on Leaf Certificates +### NotAfter behavior on leaf certificates In Vault 1.11.0, the PKI Secrets Engine has introduced a new `leaf_not_after_behavior` [parameter on @@ -463,7 +463,7 @@ range of 30 to 90 days), and the [rotation strategies discussed in other sections](/vault/docs/secrets/pki/rotation-primitives), this should keep the CRLs adequately small. -### Cluster Performance and Quantity of Leaf Certificates +### Cluster performance and quantity of leaf certificates As mentioned above, keeping TTLs short (or using `no_store=true`) and avoiding leases is important for a healthy cluster. However it is important to note @@ -523,7 +523,7 @@ OCSP responses are signed by the issuing CA within Vault). This means both are fine to distribute over non-secure and non-authenticated channels, such as HTTP. -## Automate CRL Building and Tidying +## Automate CRL building and tidying Since Vault 1.12, the PKI Secrets Engine supports automated CRL rebuilding (including optional Delta CRLs which can be built more frequently than @@ -532,7 +532,7 @@ revoked and expired certificates can be configured automatically via the `/config/auto-tidy` endpoint. Both of these should be enabled to ensure compatibility with the wider PKIX ecosystem and performance of the cluster. -## Spectrum of Revocation Support +## Spectrum of revocation support Starting with Vault 1.13, the PKI secrets engine has the ability to support a spectrum of cluster sizes and certificate revocation quantities. @@ -575,7 +575,7 @@ unreasonably large, each cluster's certificates could have AIA info point to an externally stored and maintained, sharded CRL. However, Vault has no mechanism to sign OCSP requests at this time. -### What Are Cross-Cluster CRLs? +### What are Cross-Cluster CRLs? Vault Enterprise supports a clustering mode called [Performance Replication](/vault/docs/enterprise/replication#performance-replication). In @@ -633,7 +633,7 @@ retried, but in the event of an issue writing a cross-cluster revocation entry when the cert existed locally, the revocation will eventually be synced across clusters when the connection comes back. -## Issuer Subjects and CRLs +## Issuer subjects and CRLs As noted on several [GitHub issues](https://github.com/hashicorp/vault/issues/10176), Go's x509 library has an opinionated parsing and structuring mechanism for @@ -647,7 +647,7 @@ between OCSP and CRLs. ~> Note: As of Go 1.20 and Vault 1.13, Go correctly formats the CRL's issuer name and this notice [does not apply](https://github.com/golang/go/commit/a367981b4c8e3ae955eca9cc597d9622201155f3). -## Automate Leaf Certificate Renewal +## Automate leaf certificate renewal To manage certificates for services at scale, it is best to automate the certificate renewal as much as possible. Vault Agent [has support for @@ -656,7 +656,7 @@ based on the `validTo` field. Other solutions might involve using [cert-manager](https://cert-manager.io/) in Kubernetes or OpenShift, backed by the Vault CA. -## Safe Minimums +## Safe minimums Since its inception, this secrets engine has enforced SHA256 for signature hashes rather than SHA1. As of 0.5.1, a minimum of 2048 bits for RSA keys is @@ -664,7 +664,7 @@ also enforced. Software that can handle SHA256 signatures should also be able to handle 2048-bit keys, and 1024-bit keys are considered unsafe and are disallowed in the Internet PKI. -## Token Lifetimes and Revocation +## Token lifetimes and revocation When a token expires, it revokes all leases associated with it. This means that long-lived CA certs need correspondingly long-lived tokens, something that is @@ -673,7 +673,7 @@ associated leases, to prevent unintended revocation when not using a token with a long enough lifetime. To revoke these certificates, use the `pki/revoke` endpoint. -## Safe Usage of Roles +## Safe usage of roles The Vault PKI Secrets Engine supports many options to limit issuance via [Roles](/vault/api-docs/secret/pki#create-update-role). @@ -793,7 +793,7 @@ nature: - `pem_bundle` this request parameter is only used on the issuer-import paths and may contain sensitive private key material. -## Role-Based Access +## Role-Based access Vault supports [path-based ACL Policies](/vault/tutorials/getting-started/getting-started-policies) for limiting access to various paths within Vault. @@ -911,7 +911,7 @@ from other clusters. These CRLs should either be unified into a single CRL for distribution from a single URI, or server operators should know to fetch all CRLs from all clusters. -## Cluster Scalability +## Cluster scalability Most non-introspection operations in the PKI secrets engine require a write to storage, and so are forwarded to the cluster's active node for execution. @@ -937,7 +937,7 @@ set to false. If `generate_lease` is true the lease creation will be forwarded t the active node; if `no_store` is false the entire request will be forwarded to the active node. -## PSS Support +## PSS support Go lacks support for PSS certificates, keys, and CSRs using the `rsaPSS` OID (`1.2.840.113549.1.1.10`). It requires all RSA certificates, keys, and CSRs @@ -976,7 +976,7 @@ certain KMS devices (like HSMs and GCP) may not support this with the same key. As a result, the OCSP responder may fail to sign responses, returning an internal error. -## Issuer Storage Migration Issues +## Issuer storage migration issues When Vault migrates to the new multi-issuer storage layout on releases prior to 1.11.6, 1.12.2, and 1.13, and storage write errors occur during the mount diff --git a/website/content/docs/secrets/pki/index.mdx b/website/content/docs/secrets/pki/index.mdx index 56b6ecd51429..404d461840db 100644 --- a/website/content/docs/secrets/pki/index.mdx +++ b/website/content/docs/secrets/pki/index.mdx @@ -4,7 +4,7 @@ page_title: PKI - Secrets Engines description: The PKI secrets engine for Vault generates TLS certificates. --- -# PKI Secrets Engine +# PKI secrets engine @include 'x509-sha1-deprecation.mdx' @@ -27,7 +27,7 @@ allows for ephemeral certificates. Certificates can be fetched and stored in memory upon application startup and discarded upon shutdown, without ever being written to disk. -## Table of Contents +## Table of contents The PKI Secrets Engine documentation is split into the following pieces: diff --git a/website/content/docs/secrets/pki/quick-start-intermediate-ca.mdx b/website/content/docs/secrets/pki/quick-start-intermediate-ca.mdx index 1c13f5a22325..b9930229cd09 100644 --- a/website/content/docs/secrets/pki/quick-start-intermediate-ca.mdx +++ b/website/content/docs/secrets/pki/quick-start-intermediate-ca.mdx @@ -4,7 +4,7 @@ page_title: 'PKI - Secrets Engines: Quick Start: Intermediate CA Setup' description: The PKI secrets engine for Vault generates TLS certificates. --- -# PKI Secrets Engine - Quick Start - Intermediate CA Setup +# PKI secrets engine - quick start - intermediate CA setup In the [first Quick Start guide](/vault/docs/secrets/pki/quick-start-root-ca), certificates were issued directly from the root certificate authority. @@ -23,7 +23,7 @@ $ vault secrets enable -path=pki_int pki Successfully mounted 'pki' at 'pki_int'! ``` -#### Configure an Intermediate CA +#### Configure an intermediate CA ```shell-session $ vault secrets tune -max-lease-ttl=43800h pki_int @@ -144,7 +144,7 @@ $ vault write pki_int/roles/example-dot-com \ Success! Data written to: pki_int/roles/example-dot-com ``` -#### Issue Certificates +#### Issue certificates By writing to the `roles/example-dot-com` path we are defining the `example-dot-com` role. To generate a new certificate, we simply write diff --git a/website/content/docs/secrets/pki/quick-start-root-ca.mdx b/website/content/docs/secrets/pki/quick-start-root-ca.mdx index 17e4f5f61b6a..ac17d1be5a6d 100644 --- a/website/content/docs/secrets/pki/quick-start-root-ca.mdx +++ b/website/content/docs/secrets/pki/quick-start-root-ca.mdx @@ -4,7 +4,7 @@ page_title: 'PKI - Secrets Engines: Quick Start: Root CA Setup' description: The PKI secrets engine for Vault generates TLS certificates. --- -# PKI Secrets Engine - Quick Start - Root CA Setup +# PKI secrets engine - quick start - root CA setup This document provides a brief overview of setting up a Vault PKI Secrets Engine with a Root CA certificate. @@ -117,7 +117,7 @@ $ vault write pki/roles/example-dot-com \ Success! Data written to: pki/roles/example-dot-com ``` -#### Issue Certificates +#### Issue certificates By writing to the `roles/example-dot-com` path we are defining the `example-dot-com` role. To generate a new certificate, we simply write diff --git a/website/content/docs/secrets/pki/rotation-primitives.mdx b/website/content/docs/secrets/pki/rotation-primitives.mdx index 066f3bb7b046..5217c31bac66 100644 --- a/website/content/docs/secrets/pki/rotation-primitives.mdx +++ b/website/content/docs/secrets/pki/rotation-primitives.mdx @@ -4,14 +4,14 @@ page_title: 'PKI - Secrets Engine: Rotation Primitives' description: The PKI secrets engine for Vault generates TLS certificates. --- -# PKI Secrets Engine - Rotation Primitives +# PKI secrets engine - rotation primitives Since Vault 1.11.0, Vault's PKI Secrets Engine supports multiple issuers in a single mount point. By using the certificate types below, rotation can be accomplished in various situations involving both root and intermediate CAs managed by Vault. -## X.509 Certificate Fields +## X.509 certificate fields X.509 is a complex specification; modern implementations tend to refer to [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280) for specific @@ -108,7 +108,7 @@ The following fields on the final certificate are relevant to rotation: it will appear on its parent's CRL, and may prevent rotation from happening. -## X.509 Rotation Primitives +## X.509 rotation primitives Rotation (from an organizational standpoint) can only safely happen with certain intermediate X.509 certificates being issued. To distinguish the two @@ -155,7 +155,7 @@ Key to their success is the following note: with the same subject but different public keys cannot validate the same leaf certificate; only if the keys are the same can this occur. -### Cross-Signed Primitive +### Cross-Signed primitive This is the most common type of rotation primitive. A common CSR is signed by two CAs, resulting in two certificates. These certificates must have the same @@ -167,7 +167,7 @@ Note that, due to restrictions in how end-entity certificates are used and validated (services and validation libraries expect only one), cross-signing most typically only applies to intermediate. -#### A Note on Cross-Signed Roots +#### A note on Cross-Signed roots Technically, cross-signing can occur between two roots, allowing trust bundles with either root to validate certs issued through the other. However, this @@ -180,7 +180,7 @@ certificate has been used to directly issue leaf certificates. So, the rest of this process flow assumes an intermediate is being cross-signed as this is more common. -##### Process Flow +##### Process flow ``` ------------------- @@ -208,7 +208,7 @@ there's no limit on the number of cross-signed "duplicate" (used loosely--with the same subject and key material) certificates: this could be cross-signed by many different root certificates if necessary and desired. -##### Certificate Hierarchy +##### Certificate hierarchy ``` -------- -------- @@ -286,7 +286,7 @@ $ vault patch pki/issuer/intB manual_chain=self,rootB,intA,rootA This will ensure that issuance with either copy of the intermediate reports the full cross-signed chain when signing leaf certs. -### Reissuance Primitive +### Reissuance primitive The second most common type of rotation primitive. In this scheme, the existing key material is used to generate a new certificate, usually at a much later @@ -303,7 +303,7 @@ still validate. Unlike the cross-signed primitive, this primitive type can be used on all types of certificates (including leaves, intermediates, and roots). -#### Process Flow +#### Process flow ``` ------------------- @@ -327,7 +327,7 @@ strictly no limit on the number of times a key can be reissued, at some point safety would dictate the key material should be rotated instead of being continually reissued. -#### Certificate Hierarchy +#### Certificate hierarchy ``` ------ @@ -388,7 +388,7 @@ prevented so by a `manual_chain` value). name parameters from the existing issuer; it merely reuses the same key material. -### Temporal Primitives +### Temporal primitives We can use the above primitive types to rotate roots and intermediates to new keys and extend their lifetimes. This time-based rotation is what ultimately @@ -416,7 +416,7 @@ both of the above primitives (cross-signing and reissuance) into a single backwards primitive step. In the future, these organizations should probably move to a more standard, hierarchical setup. -### Limitations of Primitives +### Limitations of primitives The certificate's [Authority Key Identifier](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.1) extension field may contain either or both of the issuer's keyIdentifier @@ -434,7 +434,7 @@ CA with that serial. This does not work when using a reissuance primitive as the are technically the same authority and thus this authority must issue certificates with unique serial numbers. -## Suggested Root Rotation Procedure +## Suggested root rotation procedure The following is a suggested process for achieving root rotation easily and without (outage) impact to the broader organization, assuming [best diff --git a/website/content/docs/secrets/pki/setup.mdx b/website/content/docs/secrets/pki/setup.mdx index ee9ba55809fb..ef0a560012bf 100644 --- a/website/content/docs/secrets/pki/setup.mdx +++ b/website/content/docs/secrets/pki/setup.mdx @@ -4,7 +4,7 @@ page_title: 'PKI - Secrets Engines: Setup and Usage' description: The PKI secrets engine for Vault generates TLS certificates. --- -# PKI Secrets Engine - Setup and Usage +# PKI secrets engine - setup and usage This document provides a brief overview of the setup and usage of the PKI Secrets Engine. diff --git a/website/content/docs/secrets/rabbitmq.mdx b/website/content/docs/secrets/rabbitmq.mdx index 7671bc657876..65d7418621fd 100644 --- a/website/content/docs/secrets/rabbitmq.mdx +++ b/website/content/docs/secrets/rabbitmq.mdx @@ -6,7 +6,7 @@ description: >- RabbitMQ. --- -# RabbitMQ Secrets Engine +# RabbitMQ secrets engine The RabbitMQ secrets engine generates user credentials dynamically based on configured permissions and virtual hosts. This means that services that need to diff --git a/website/content/docs/secrets/ssh/index.mdx b/website/content/docs/secrets/ssh/index.mdx index ad9f9ab22151..c9fb4d263354 100644 --- a/website/content/docs/secrets/ssh/index.mdx +++ b/website/content/docs/secrets/ssh/index.mdx @@ -7,7 +7,7 @@ description: |- SSH secrets engine including signed SSH certificates and one-time passwords. --- -# SSH Secrets Engine +# SSH secrets engine Name: `ssh` @@ -24,7 +24,7 @@ individually documented on its own page. All guides assume a basic familiarity with the SSH protocol. -## Removal of Dynamic Keys feature +## Removal of dynamic keys feature Per [Vault 1.12's deprecation notice page](/vault/docs/v1.12.x/deprecation), the dynamic keys functionality of this engine has been removed in Vault 1.13. diff --git a/website/content/docs/secrets/ssh/one-time-ssh-passwords.mdx b/website/content/docs/secrets/ssh/one-time-ssh-passwords.mdx index 085d9d29b0d1..8d2ac5831fe6 100644 --- a/website/content/docs/secrets/ssh/one-time-ssh-passwords.mdx +++ b/website/content/docs/secrets/ssh/one-time-ssh-passwords.mdx @@ -7,7 +7,7 @@ description: |- host using a helper command on the remote host to perform verification. --- -# One-Time SSH Passwords +# One-Time SSH passwords The One-Time SSH Password (OTP) SSH secrets engine type allows a Vault server to issue a One-Time Password every time a client wants to SSH into a remote host @@ -45,7 +45,7 @@ $ vault secrets enable ssh Successfully mounted 'ssh' at 'ssh'! ``` -### Create a Role +### Create a role Create a role with the `key_type` parameter set to `otp`. All of the machines represented by the role's CIDR list should have helper properly installed and @@ -59,7 +59,7 @@ $ vault write ssh/roles/otp_key_role \ Success! Data written to: ssh/roles/otp_key_role ``` -### Create a Credential +### Create a credential Create an OTP credential for an IP of the remote host that belongs to `otp_key_role`. diff --git a/website/content/docs/secrets/ssh/signed-ssh-certificates.mdx b/website/content/docs/secrets/ssh/signed-ssh-certificates.mdx index 705180b99b09..7d77eec1148e 100644 --- a/website/content/docs/secrets/ssh/signed-ssh-certificates.mdx +++ b/website/content/docs/secrets/ssh/signed-ssh-certificates.mdx @@ -12,7 +12,7 @@ description: >- This key will be used to sign other SSH keys. --- -# Signed SSH Certificates +# Signed SSH certificates The signed SSH certificates is the simplest and most powerful in terms of setup complexity and in terms of being platform agnostic. By leveraging Vault's @@ -26,14 +26,14 @@ this is confusing, substitute "client" with "user". This page will show a quick start for this secrets engine. For detailed documentation on every path, use `vault path-help` after mounting the secrets engine. -## Client Key Signing +## Client key signing Before a client can request their SSH key be signed, the Vault SSH secrets engine must be configured. Usually a Vault administrator or security team performs these steps. It is also possible to automate these actions using a configuration management tool like Chef, Puppet, Ansible, or Salt. -### Signing Key & Role Configuration +### Signing key & role configuration The following steps are performed in advance by a Vault administrator, security team, or configuration management tooling. @@ -128,7 +128,7 @@ team, or configuration management tooling. EOH ``` -### Client SSH Authentication +### Client SSH authentication The following steps are performed by the client (user) that wants to authenticate to machines managed by Vault. These commands are usually run from @@ -199,7 +199,7 @@ the client's local workstation. $ ssh -i signed-cert.pub -i ~/.ssh/id_rsa username@10.0.23.5 ``` -## Host Key Signing +## Host key signing For an added layers of security, we recommend enabling host key signing. This is used in conjunction with client key signing to provide an additional integrity @@ -207,7 +207,7 @@ layer. When enabled, the SSH agent will verify the target host is valid and trusted before attempting to SSH. This will reduce the probability of a user accidentally SSHing into an unmanaged or malicious machine. -### Signing Key Configuration +### Signing key configuration 1. Mount the secrets engine. For the most security, mount at a different path from the client signer. @@ -302,7 +302,7 @@ accidentally SSHing into an unmanaged or malicious machine. Restart the SSH service to pick up the changes. -### Client-Side Host Verification +### Client-Side host verification 1. Retrieve the host signing CA public key to validate the host signature of target machines. @@ -389,7 +389,7 @@ issue: EOH ``` -### No Prompt After Login +### No prompt after login If you do not see a prompt after authenticating to the host machine, the signed certificate may not have the `permit-pty` extension. There are two ways to add @@ -421,7 +421,7 @@ this extension to the signed certificate. EOH ``` -### No Port Forwarding +### No port forwarding If port forwarding from the guest to the host is not working, the signed certificate may not have the `permit-port-forwarding` extension. Add the @@ -436,7 +436,7 @@ forwarding. See [no prompt after login](#no-prompt-after-login) for examples. } ``` -### No X11 Forwarding +### No x11 forwarding If X11 forwarding from the guest to the host is not working, the signed certificate may not have the `permit-X11-forwarding` extension. Add the @@ -451,7 +451,7 @@ forwarding. See [no prompt after login](#no-prompt-after-login) for examples. } ``` -### No Agent Forwarding +### No agent forwarding If agent forwarding from the guest to the host is not working, the signed certificate may not have the `permit-agent-forwarding` extension. Add the @@ -466,7 +466,7 @@ forwarding. See [no prompt after login](#no-prompt-after-login) for examples. } ``` -### Key Comments +### Key comments There are additional steps needed to preserve [comment attributes](https://www.rfc-editor.org/rfc/rfc4716#section-3.3.2) in keys which ought to be considered if they are required. Private and public key may have comments applied to them and for example where `ssh-keygen` is used @@ -484,7 +484,7 @@ parameters as per the Vault CLI and API steps demonstrated below. vault secrets enable -path=hosts-ca ssh KEY_PRI=$(cat ~/.ssh/id_rsa | sed -z 's/\n/\\n/g') KEY_PUB=$(cat ~/.ssh/id_rsa.pub | sed -z 's/\n/\\n/g') -# Create / Update keypair in Vault +# Create / update keypair in Vault vault write ssh-client-signer/config/ca \ generate_signing_key=false \ private_key="${KEY_PRI}" \ @@ -503,14 +503,14 @@ tee payload.json < **IMPORTANT:** Do NOT add a private key password since Vault can't decrypt it. Destroy the keypair and `payload.json` from your hosts immediately after they have been confirmed as successfully uploaded. -### Known Issues +### Known issues - On SELinux-enforcing systems, you may need to adjust related types so that the SSH daemon is able to read it. For example, adjust the signed host certificate to be an `sshd_key_t` type. diff --git a/website/content/docs/secrets/terraform.mdx b/website/content/docs/secrets/terraform.mdx index d3de02b8b86d..a61af98cc02d 100644 --- a/website/content/docs/secrets/terraform.mdx +++ b/website/content/docs/secrets/terraform.mdx @@ -4,7 +4,7 @@ page_title: Terraform Cloud Secret Backend description: The Terraform Cloud secret backend for Vault generates tokens for Terraform Cloud dynamically. --- -# Terraform Cloud Secret Backend +# Terraform Cloud secret backend Name: `Terraform Cloud` @@ -20,7 +20,7 @@ Cloud ([app.terraform.io](https://app.terraform.io/session)) as well as on-prem Terraform Enterprise. Any version requirements will be documented alongside the features that require them, if any. -## Quick Start +## Quick start Most secrets engines must be configured in advance before they can perform their functions. These steps are usually completed by an operator or configuration @@ -82,14 +82,14 @@ token TJFDSIFDSKFEKZX.FKFKA.akjlfdiouajlkdakadfiowe token_id at-123acbdfask ``` -## Organization, Team, and User Roles +## Organization, team, and user roles Terraform Cloud supports three distinct types of API tokens; Organizations, Teams, and Users. Each token type has distinct access levels and generation workflows. A given Vault role can manage any one of the three types at a time, however there are important differences to be aware of. -### Organization and Team roles +### Organization and team roles The Terraform Cloud API limits both Organization and Team roles to **one active token at any given time**. Generating a new Organization or Team API token by diff --git a/website/content/docs/secrets/totp.mdx b/website/content/docs/secrets/totp.mdx index cfe0559d758f..4bec57a1d355 100644 --- a/website/content/docs/secrets/totp.mdx +++ b/website/content/docs/secrets/totp.mdx @@ -4,7 +4,7 @@ page_title: TOTP - Secrets Engines description: The TOTP secrets engine for Vault generates time-based one-time use passwords. --- -# TOTP Secrets Engine +# TOTP secrets engine The TOTP secrets engine generates time-based credentials according to the TOTP standard. The secrets engine can also be used to generate a new key and validate @@ -13,7 +13,7 @@ passwords generated by that key. The TOTP secrets engine can act as both a generator (like Google Authenticator) and a provider (like the Google.com sign in service). -## As a Generator +## As a generator The TOTP secrets engine can act as a TOTP code generator. In this mode, it can replace traditional TOTP generators like Google Authenticator. It provides an @@ -67,7 +67,7 @@ the proper permission, it can generate credentials. that trusted operators can manage the key definitions, and both users and applications are restricted in the credentials they are allowed to read. -## As a Provider +## As a provider The TOTP secrets engine can also act as a TOTP provider. In this mode, it can be used to generate new keys and validate passwords generated using those keys. diff --git a/website/content/docs/secrets/transform/ff3-tweak-details.mdx b/website/content/docs/secrets/transform/ff3-tweak-details.mdx index 7380271e62f3..bc8d5061923e 100644 --- a/website/content/docs/secrets/transform/ff3-tweak-details.mdx +++ b/website/content/docs/secrets/transform/ff3-tweak-details.mdx @@ -4,7 +4,7 @@ page_title: FF3-1 Tweak Usage Documentation description: |- Details and best practices for FF3-1 transform usage. --- -# FF3-1 Tweak Usage Documentation +# FF3-1 tweak usage documentation ## Introduction @@ -24,7 +24,7 @@ This page will detail some best practices when using tweaks. Note that this guidance only holds when the tweak source selected when using the Vault FF3-1 transform is `supplied` or `internal`. -## FF3-1 Best Practices: +## FF3-1 best practices: Vault recommends the following practices when utilizing tweaks with the FF3-1 transform. @@ -42,7 +42,7 @@ two of the same values that correspond to different underlying entities. The following section aims to give some broad motivation for these recommendations. For details, please see the Further Resources section at the bottom of the page. -## FF3-1 Tweak Usage +## FF3-1 tweak usage FF3-1 is a tweakable encryption scheme that was created to solve the problem of encrypting on small domains. Tweaks were introduced to synthetically increase the @@ -75,7 +75,7 @@ In practice, using randomly chosen tweaks will be enough -- however, it is impor to avoid using an algorithm to generate tweaks that yields similarity between two halves of tweaks [4]. -## Further Resources: +## Further resources: * 1: https://eprint.iacr.org/2020/1311.pdf * 2: https://csrc.nist.gov/news/2017/recent-cryptanalysis-of-ff3 diff --git a/website/content/docs/secrets/transform/index.mdx b/website/content/docs/secrets/transform/index.mdx index e3faf0938538..382999c49417 100644 --- a/website/content/docs/secrets/transform/index.mdx +++ b/website/content/docs/secrets/transform/index.mdx @@ -5,7 +5,7 @@ description: >- The Transform secrets engine for Vault performs secure data transformation. --- -# Transform Secrets Engine +# Transform secrets engine -> **Note**: This secret engine requires [Vault Enterprise](https://www.hashicorp.com/products/vault/) with the Advanced Data @@ -123,7 +123,7 @@ values. be provided. If one isn't provided, the decoded output will be formatted to match the template's pattern as in the previous example. -## Roles, Transformations, Templates, and Alphabets +## Roles, transformations, templates, and alphabets The Transform secrets engine contains several types of resources that encapsulate different aspects of the information required in order to perform @@ -147,13 +147,13 @@ data transformation. ## Transformations -### Format Preserving Encryption +### Format preserving encryption Format Preserving Encryption (FPE) performs cryptographically secure transformation via FF3-1 to encode input values while maintaining its data format and length. -#### Tweak and Tweak Source +#### Tweak and tweak source FF3-1 uses a non-confidential parameter called the tweak along with the ciphertext when performing encryption and decryption operations. The tweak @@ -190,7 +190,7 @@ Your team and organization should weigh the trade-offs when it comes to choosing the proper tweak source to use. For `supplied` and `internal` sourcing, please see [FF3-1 Tweak Usage Details](/vault/docs/secrets/transform/ff3-tweak-details) -#### Input Limits +#### Input limits FF3-1 specifies both minimum and maximum limits on the length of an input. These limits are driven by the security goals, making sure that for a given @@ -209,7 +209,7 @@ valid input lengths would be between 6 and 56 characters. This is because Of course, in the case of credit card numbers valid input would always be between 12 and 19 decimal digits. -#### Output Limitations +#### Output limitations After transformation and formatting by the template, the value is an encrypted version of the input with the format preserved. However, the value itself may @@ -266,7 +266,7 @@ Tokenization is stateful. Tokenized state can be stored internally (the default) or in an external store. Currently only PostgreSQL, MySQL, and MSSQL are supported for external storage. -#### Mapping Modes +#### Mapping modes [Tokenization](/vault/docs/secrets/transform/tokenization) stores the results of an encode operation in storage using a cryptographic construct that enhances the safety of its values. @@ -280,7 +280,7 @@ operators may need to recover the full set of decoded inputs in an emergency via the export operation. It is strongly recommended that one use the `default` mode if possible, as it is resistant to more types of attack. -#### Convergent Tokenization +#### Convergent tokenization ~> **Note:** Convergent tokenization is not supported for transformations with imported keys. @@ -290,7 +290,7 @@ that tokenizing a plaintext and expiration more than once results in the same token value. Enabling convergence has performance and security [considerations](/vault/docs/secrets/transform/tokenization#convergence). -## Deletion Behavior +## Deletion behavior The deletion of resources, aside from roles, is guarded by checking whether any other related resources are currently using it in order to avoid accidental data @@ -305,7 +305,7 @@ The following rules applies when it comes to deleting a resource: - A template or store cannot be deleted if it's in use by a transformation. - An alphabet cannot be deleted if it's in use by a template. -## Provided Builtin Resources +## Provided builtin resources The secret engine provides a set of builtin templates and alphabets that are considered common. Builtin templates cannot be deleted, and the prefix @@ -355,7 +355,7 @@ transformations: Refer to the [Transform Secrets Engine](/vault/tutorials/adp/transform) tutorial to learn how to use the Transform secrets engine to handle secure data transmission and tokenization against provided secrets. -## Bring Your Own Key (BYOK) +## Bring your own key (BYOK) ~> **Note:** Key import functionality supports cases where there is a need to bring in an existing key from an HSM or other outside systems. It is more secure to @@ -389,7 +389,7 @@ The ciphertext is constructed by appending the wrapped target key to the wrapped The ciphertext bytes should be base64-encoded. -### Manual Process +### Manual process If the target key is not stored in an HSM or KMS, the following steps can be used to construct the ciphertext for the input of the `import` endpoint: diff --git a/website/content/docs/secrets/transform/tokenization.mdx b/website/content/docs/secrets/transform/tokenization.mdx index f43684caac0a..89417c2f2cbb 100644 --- a/website/content/docs/secrets/transform/tokenization.mdx +++ b/website/content/docs/secrets/transform/tokenization.mdx @@ -5,7 +5,7 @@ description: >- More information on the Tokenization transform. --- -# Tokenization Transform +# Tokenization transform Not to be confused with Vault tokens, Tokenization exchanges a sensitive value for an unrelated value called a _token_. The original sensitive @@ -46,7 +46,7 @@ metadata when convergently encoding. It is recommended that if one has some use cases that require convergence and some that do not, one should create two different tokenization transforms with convergence enabled on only one. -### Token Lookup +### Token lookup Some use cases may want to lookup the value of a token given its plaintext. Ordinarily this is contrary to the nature of tokenization where we want to prevent the ability @@ -57,9 +57,9 @@ operation is supported, but only in some configurations of the tokenization transformation. Token lookup is supported when convergence is enabled, or if the mapping mode is exportable *and* the storage backend is external. -## Performance Considerations +## Performance considerations -### Builtin (Internal) Store +### Builtin (Internal) store As tokenization is stateful, the encode operation necessarily writes values to storage. By default, that storage is the Vault backend store itself. This @@ -81,14 +81,14 @@ secondaries, so other read operations like decode or metadata may not succeed on the secondaries until this happens. In other words, tokenization is eventually consistent. -### External Storage +### External storage All nodes (except DRs) can participate in all operations using external storage, but one must take care to monitor and scale the external storage for the level of traffic experienced. The storage schema is simple however and well known approaches should be effective. -## Security Considerations +## Security considerations 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 @@ -119,7 +119,7 @@ original plaintext value. As it has it's own retrieval endpoint, operators can configure policies that may allow access to the metadata of a token but not its decoded value to enable workflows that operate just on the metadata. -## TTLs and Tidying +## 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 strongly encouraged @@ -134,7 +134,7 @@ can immediately reject the operation when presented with an expired token. ## Storage -### External SQL Stores +### External SQL stores Currently the PostgreSQL, MySQL, and MSSQL relational databases are supported as external storage backends for tokenization. @@ -155,7 +155,7 @@ 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 transform. -### Export Decoded +### Export decoded For stores configured with the `exportable` mapping mode, the export decoded endpoint allows operators to retrieve the _decoded_ contents of tokenization @@ -184,7 +184,7 @@ functionality to perform a zero-downtime migration to a new store: 1. Perform any desired validations. 1. Modify the tokenization transform to use only the new store. -## Key Management +## Key management Tokenization supports key rotation. Keys are tied to transforms, so key names are the same as the name of the corresponding tokenization transform. diff --git a/website/content/docs/secrets/transit/index.mdx b/website/content/docs/secrets/transit/index.mdx index db44a6278712..831f15ef9f7a 100644 --- a/website/content/docs/secrets/transit/index.mdx +++ b/website/content/docs/secrets/transit/index.mdx @@ -6,7 +6,7 @@ description: >- doesn't store any secrets. --- -# Transit Secrets Engine +# Transit secrets engine The transit secrets engine handles cryptographic functions on data in-transit. Vault doesn't store the data sent to the secrets engine. It can also be viewed @@ -29,7 +29,7 @@ bit length be returned to them, encrypted with the named key. Normally this will also return the key in plaintext to allow for immediate use, but this can be disabled to accommodate auditing requirements. -## Working Set Management +## Working set management The Transit engine supports versioning of keys. Key versions that are earlier than a key's specified `min_decryption_version` gets archived, and the rest of @@ -49,7 +49,7 @@ multiple of five) may provide a good alternative, allowing for several keys to be live at once and a deterministic way to decide which key to use at any given time. -## NIST Rotation Guidance +## NIST rotation guidance Periodic rotation of the encryption keys is recommended, even in the absence of compromise. For AES-GCM keys, rotation should occur before approximately 232 @@ -60,7 +60,7 @@ that prevents the guidance limits from being reached. For example, if one determ that the estimated rate is 40 million operations per day, then rotating a key every three months is sufficient. -## Key Types +## Key types As of now, the transit secrets engine supports the following key types (all key types also generate separate HMAC keys): @@ -105,7 +105,7 @@ RSA operations use one of the following methods: - PSS (sign, verify), with configurable hash function also used for MGF, and - PKCS#1v1.5: (sign, verify), with configurable hash function. -## Convergent Encryption +## Convergent encryption Convergent encryption is a mode where the same set of plaintext+context always result in the same ciphertext. It does this by deriving a key using a key @@ -251,7 +251,7 @@ the proper permission, it can use this secrets engine. data, since the process would not be able to get access to the plaintext data. -## Bring Your Own Key (BYOK) +## Bring your own key (BYOK) ~> **Note:** Key import functionality supports cases in which there is a need to bring in an existing key from an HSM or other outside system. It is more secure to @@ -285,7 +285,7 @@ The ciphertext is constructed by appending the wrapped target key to the wrapped The ciphertext bytes should be base64-encoded. -### Manual Process +### Manual process If the target key is not stored in an HSM or KMS, the following steps can be used to construct the ciphertext for the input of the `import` endpoint: diff --git a/website/content/docs/secrets/transit/key-wrapping-guide.mdx b/website/content/docs/secrets/transit/key-wrapping-guide.mdx index 917142302efe..5ee584d492bd 100644 --- a/website/content/docs/secrets/transit/key-wrapping-guide.mdx +++ b/website/content/docs/secrets/transit/key-wrapping-guide.mdx @@ -5,7 +5,7 @@ description: |- Details about wrapping keys for import into the transit secrets engine. --- -# Key Wrapping for Transit Key Import +# Key wrapping for transit key import The "bring your own key" (BYOK) functionality for the transit secrets engine allows users to import keys that were generated @@ -34,7 +34,7 @@ This returns a 4096-bit RSA key. The steps after this depend on whether the key is stored using a software solution or in an HSM. -### Software Example (Go) +### Software example (Go) This example assumes that the key is stored in software using the variable name `key`. It demonstrates how to wrap the target key using @@ -117,7 +117,7 @@ $ vault write transit/keys/test-key/import ciphertext=$CIPHERTEXT hash_function= ``` -### AWS CloudHSM Example +### AWS CloudHSM example This example demonstrates how to import a key into the transit secrets engine from an AWS CloudHSM cluster. The process and mechanisms used will apply to importing diff --git a/website/content/docs/secrets/venafi.mdx b/website/content/docs/secrets/venafi.mdx index fda09fb0869d..b74f2a2077c7 100644 --- a/website/content/docs/secrets/venafi.mdx +++ b/website/content/docs/secrets/venafi.mdx @@ -4,7 +4,7 @@ page_title: Venafi - Secrets Engines description: The Venafi integrated secrets engine for Vault. --- -# Venafi Secrets Engine for HashiCorp Vault +# Venafi secrets engine for HashiCorp Vault The Venafi Machine Identity Secrets Engine provides applications with the ability to dynamically generate SSL/TLS certificates that serve as machine @@ -36,7 +36,7 @@ To successfully deploy this secrets engine, there are some important considerations. Before using Venafi secrets engine, you should read every consideration. -### Venafi Trust Protection Platform Requirements +### Venafi trust protection platform requirements Your certificate authority (CA) must be able to issue a certificate in under one minute. Microsoft Active Directory Certificate Services (ADCS) is a @@ -72,7 +72,7 @@ information see the _Venafi Administration Guide_. extensions, some applications will fail, such as NGINX ingress controllers. These applications aren't able to retrieve CRL and OCSP information. -#### Trust between Vault and Trust Protection Platform +#### Trust between Vault and trust protection platform The Trust Protection Platform REST API (WebSDK) must be secured with a certificate. Generally, the certificate is issued by a CA that is not publicly @@ -87,7 +87,7 @@ in PEM format (e.g. /opt/venafi/bundle.pem) and reference it using the `trust_bundle_file` parameter whenever you create or update a PKI role in your Vault. -### Venafi Cloud Requirements +### Venafi Cloud requirements If you are using Venafi Cloud, be sure to set up an issuing template, project, and any other dependencies that appear in the Venafi Cloud documentation. diff --git a/website/content/docs/upgrading/index.mdx b/website/content/docs/upgrading/index.mdx index 95f7ec63b2de..ba779cb48864 100644 --- a/website/content/docs/upgrading/index.mdx +++ b/website/content/docs/upgrading/index.mdx @@ -25,7 +25,7 @@ supported. The upgrade notes for each intervening version must be reviewed. The upgrade notes may describe additional steps or configuration to update before, during, or after the upgrade. -## Integrated Storage Autopilot +## Integrated storage autopilot Vault 1.11 introduced [automated upgrades](/vault/docs/concepts/integrated-storage/autopilot#automated-upgrades) as @@ -46,7 +46,7 @@ period. The Vault Agent version can lag behind the Vault Server version, though we recommend keeping all Vault instances up to date with the most recent minor Vault version to the extent possible. -## Testing the Upgrade +## Testing the upgrade It's always a good idea to try to ensure that the upgrade will be successful in your environment. The ideal way to do this is to take a snapshot of your data @@ -56,11 +56,11 @@ do not allow external network connectivity during testing, in case credentials expire. This prevents the test cluster from trying to revoke these resources along with the non-test cluster. -## OSS to Enterprise Installations +## OSS to enterprise installations Upgrading to Vault Enterprise installations follow the same steps as OSS upgrades except that the Vault Enterprise binary is to be used and the license file [applied](/vault/api-docs/system/license#install-license), when applicable. The Enterprise binary and license file can be obtained through your HashiCorp sales team. -## Non-HA Installations +## Non-HA installations Upgrading non-HA installations of Vault is as simple as replacing the Vault binary with the new version and restarting Vault. Any upgrade tasks that can be @@ -71,7 +71,7 @@ Always use `SIGINT` or `SIGTERM` to properly shut down Vault. Be sure to also read and follow any instructions in the version-specific upgrade notes. -## HA Installations +## HA installations The recommended upgrade procedure depends on the version of Vault you're currently on and the storage backend of Vault. If you're currently running on Vault 1.11 or later with Integrated Storage and you have Autopilot enabled, you should let Autopilot do the upgrade for you, as that's easier and less prone to human error. Please refer to our [automated @@ -82,7 +82,7 @@ tutorial for more details. If you're currently on a version of Vault before 1.11, or you've chosen to opt-out the Autopilot automated upgrade features when running Vault after 1.11 with Integrated Storage, or if you are running Vault with other storage backend such as Consul. Please refer to our [Vault HA upgrades Pre 1.11/Without Autopilot Upgrade Automation](/vault/docs/upgrading/vault-ha-upgrade) documentation for more details. Please note that this upgrade procedure also applies if you are upgrading Vault from pre 1.11 to post 1.11. -## Enterprise Replication Installations +## Enterprise replication installations diff --git a/website/content/docs/upgrading/plugins.mdx b/website/content/docs/upgrading/plugins.mdx index 3bf71daa2544..5f9bf9e43341 100644 --- a/website/content/docs/upgrading/plugins.mdx +++ b/website/content/docs/upgrading/plugins.mdx @@ -4,9 +4,9 @@ page_title: Upgrading Plugins - Guides description: These are general upgrade instructions for Vault plugins. --- -# Upgrading Vault Plugins +# Upgrading Vault plugins -## Plugin Upgrade Procedure +## Plugin upgrade procedure The following procedures detail steps for upgrading a plugin that has been mounted at a path on a running server. The steps are the same whether the plugin being @@ -132,7 +132,7 @@ Until the last step, the mount will still run the first version of `my-db-plugin the reload is triggered, Vault will kill `my-db-plugin`’s process and start the new plugin process for `my-db-plugin` version 1.0.1. -### Downgrading Plugins +### Downgrading plugins Plugin downgrades follow the same procedure as upgrades. You can use the Vault plugin list command to check what plugin versions are available to downgrade to: @@ -166,7 +166,7 @@ totp v1.12.0+builtin.vault transit v1.12.0+builtin.vault ``` -### Additional Upgrade Notes +### Additional upgrade notes * As mentioned earlier, disabling existing mounts will wipe the existing data. * Overwriting an existing version in the catalog will affect all uses of that diff --git a/website/content/docs/upgrading/upgrade-to-0.10.0.mdx b/website/content/docs/upgrading/upgrade-to-0.10.0.mdx index 8bb419ec89d0..5ed33f7bb162 100644 --- a/website/content/docs/upgrading/upgrade-to-0.10.0.mdx +++ b/website/content/docs/upgrading/upgrade-to-0.10.0.mdx @@ -11,9 +11,9 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 0.10.0 compared to 0.9.0. Please read it carefully. -## Changes Since 0.9.6 +## Changes since 0.9.6 -### Database Plugin Compatibility +### Database plugin compatibility The database plugin interface was enhanced to support some additional functionality related to root credential rotation and supporting templated @@ -24,7 +24,7 @@ root rotation. Additionally, the Initialize method was deprecated in favor of a new Init method that supports configuration modifications that occur in the plugin back to the primary data store. -### Removal of Returned Secret Information +### Removal of returned secret information For a long time Vault has returned configuration given to various secret engines and auth methods with secret values (such as secret API keys or @@ -39,42 +39,42 @@ accommodate this as best as possible, and users of other tools may have to make adjustments, but in the end we felt that the ends did not justify the means and we needed to prioritize security over operational convenience. -### LDAP Auth Method Case Sensitivity +### LDAP auth method case sensitivity We now treat usernames and groups configured locally for policy assignment in a case insensitive fashion by default. Existing configurations will continue to work as they do now; however, the next time a configuration is written `case_sensitive_names` will need to be explicitly set to `true`. -### TTL Handling Moved to Core +### TTL handling moved to core All lease TTL handling has been centralized within the core of Vault to ensure consistency across all backends. Since this was previously delegated to individual backends, there may be some slight differences in TTLs generated from some backends. -### Default `secret/` Mount is Deprecated +### Default `secret/` mount is deprecated In 0.12 we will stop mounting `secret/` by default at initialization time (it will still be available in `dev` mode). -## Full List Since 0.9.0 +## Full list since 0.9.0 -### Change to AWS Role Output +### Change to AWS role output The AWS authentication backend now allows binds for inputs as either a comma-delimited string or a string array. However, to keep consistency with input and output, when reading a role the binds will now be returned as string arrays rather than strings. -### Change to AWS IAM Auth ARN Prefix Matching +### Change to AWS IAM auth ARN prefix matching In order to prefix-match IAM role and instance profile ARNs in AWS auth backend, you now must explicitly opt-in by adding a `*` to the end of the ARN. Existing configurations will be upgraded automatically, but when writing a new role configuration the updated behavior will be used. -### Backwards Compatible CLI Changes +### Backwards compatible CLI changes This upgrade guide is typically reserved for breaking changes, however it is worth calling out that the CLI interface to Vault has been completely @@ -89,7 +89,7 @@ Documentation for previous versions of Vault can be accessed using the GitHub interface by browsing tags (eg [0.9.1 website tree](https://github.com/hashicorp/vault/tree/v0.9.1/website)) or by [building the Vault website locally](https://github.com/hashicorp/vault/tree/v0.9.1/website#running-the-site-locally). -### `sys/health` DR Secondary Reporting +### `sys/health` DR secondary reporting The `replication_dr_secondary` bool returned by `sys/health` could be misleading since it would be `false` both when a cluster was not a DR secondary @@ -104,20 +104,20 @@ replication is disabled or the state is still being discovered. As a result, an LB check can positively verify that the node is both not `disabled` and is not a DR secondary, and avoid sending traffic to it if either is true. -### PKI Secret Backend Roles Parameter Types +### PKI secret backend roles parameter types For `ou` and `organization` in role definitions in the PKI secret backend, input can now be a comma-separated string or an array of strings. Reading a role will now return arrays for these parameters. -### Plugin API Changes +### Plugin API changes The plugin API has been updated to utilize golang's context.Context package. Many function signatures now accept a context object as the first parameter. Existing plugins will need to pull in the latest Vault code and update their function signatures to begin using context and the new gRPC transport. -### AppRole Case Sensitivity +### AppRole case sensitivity In prior versions of Vault, `list` operations against AppRole roles would require preserving case in the role name, even though most other operations @@ -125,36 +125,36 @@ within AppRole are case-insensitive with respect to the role name. This has been fixed; existing roles will behave as they have in the past, but new roles will act case-insensitively in these cases. -### Token Auth Backend Roles Parameter Types +### Token auth backend roles parameter types For `allowed_policies` and `disallowed_policies` in role definitions in the token auth backend, input can now be a comma-separated string or an array of strings. Reading a role will now return arrays for these parameters. -### Transit Key Exporting +### Transit key exporting You can now mark a key in the `transit` backend as `exportable` at any time, rather than just at creation time; however, once this value is set, it still cannot be unset. -### PKI Secret Backend Roles Parameter Types +### PKI secret backend roles parameter types For `allowed_domains` and `key_usage` in role definitions in the PKI secret backend, input can now be a comma-separated string or an array of strings. Reading a role will now return arrays for these parameters. -### SSH Dynamic Keys Method Defaults to 2048-bit Keys +### SSH dynamic keys method defaults to 2048-bit keys When using the dynamic key method in the SSH backend, the default is now to use 2048-bit keys if no specific key bit size is specified. -### Consul Secret Backend Lease Handling +### Consul secret backend lease handling The `consul` secret backend can now accept both strings and integer numbers of seconds for its lease value. The value returned on a role read will be an integer number of seconds instead of a human-friendly string. -### Unprintable Characters Not Allowed in API Paths +### Unprintable characters not allowed in API paths Unprintable characters are no longer allowed in names in the API (paths and path parameters), with an extra restriction on whitespace characters. Allowed diff --git a/website/content/docs/upgrading/upgrade-to-0.10.2.mdx b/website/content/docs/upgrading/upgrade-to-0.10.2.mdx index e90569baaeb6..8b84ac7ccf8d 100644 --- a/website/content/docs/upgrading/upgrade-to-0.10.2.mdx +++ b/website/content/docs/upgrading/upgrade-to-0.10.2.mdx @@ -11,7 +11,7 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 0.10.2 compared to 0.10.1. Please read it carefully. -### Convergent Encryption version 3 +### Convergent encryption version 3 If you are using `transit`'s convergent encryption feature, which prior to this release was at version 2, we recommend diff --git a/website/content/docs/upgrading/upgrade-to-0.10.4.mdx b/website/content/docs/upgrading/upgrade-to-0.10.4.mdx index 77c0c19ee872..c4d7fa32fecb 100644 --- a/website/content/docs/upgrading/upgrade-to-0.10.4.mdx +++ b/website/content/docs/upgrading/upgrade-to-0.10.4.mdx @@ -20,13 +20,13 @@ attained via the `-sync` CLI flag or `sync` API parameter. When in synchronous mode, if the operation results in failure it is up to the user to retry. -### CLI Retries +### CLI retries The CLI will no longer retry commands on 5xx errors. This was a source of confusion to users as to why Vault would "hang" before returning a 5xx error. The Go API client still defaults to two retries. -### Identity Entity Alias metadata +### Identity entity alias metadata You can no longer manually set metadata on entity aliases. All alias data (except the canonical entity ID it refers to) diff --git a/website/content/docs/upgrading/upgrade-to-0.11.0.mdx b/website/content/docs/upgrading/upgrade-to-0.11.0.mdx index 1477c780e399..0bb0e4880f4c 100644 --- a/website/content/docs/upgrading/upgrade-to-0.11.0.mdx +++ b/website/content/docs/upgrading/upgrade-to-0.11.0.mdx @@ -11,14 +11,14 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 0.11.0 compared to 0.10.0. Please read it carefully. -## Known Issues +## Known issues -### Nomad Integration +### Nomad integration Users that integrate Vault with Nomad should hold off on upgrading. A modification to Vault's API is causing a runtime issue with the Nomad to Vault integration. -### Minified JSON Policies +### Minified JSON policies Users that generate policies in minfied JSON may cause a parsing errors due to a regression in the policy parser when it encounters repeating brackets. Although @@ -27,7 +27,7 @@ should work in place of HCL. To work around this error, pretty print the JSON po or add spaces between repeating brackets. This regression will be addressed in a future release. -### Common Mount Prefixes +### Common mount prefixes Before running the upgrade, users should run `vault secrets list` and `vault auth list` to check their mount table to ensure that mounts do not have common prefix "folders". @@ -35,15 +35,15 @@ For example, if there is a mount with path `team1/` and a mount with path `team1 Vault will fail to unseal. Before upgrade, these mounts must be remounted at a path that does not share a common prefix. -## Changes Since 0.10.4 +## Changes since 0.10.4 -### Request Timeouts +### Request timeouts A default request timeout of 90s is now enforced. This setting can be overwritten in the config file. If you anticipate requests taking longer than 90s this setting should be configured before upgrading. -### `sys/` Top Level Injection +### `sys/` top level injection For the last two years for backwards compatibility data for various `sys/` routes has been injected into both the Secret's Data map and into the top level @@ -51,7 +51,7 @@ of the JSON response object. However, this has some subtle issues that pop up from time to time and is becoming increasingly complicated to maintain, so it's finally being removed. -### Path Fallback for List Operations +### Path fallback for list operations For a very long time Vault has automatically adjusted `list` operations to always end in a `/`, as list operations operates on prefixes, so all list @@ -65,13 +65,13 @@ putting `list` capabilities in the same path block as most other capabilities for that path, while not providing any extra access if `list` wasn't actually provided there. -### Performance Standbys On By Default +### Performance standbys on by default If your flavor/license of Vault Enterprise supports Performance Standbys, they are on by default. You can disable this behavior per-node with the `disable_performance_standby` configuration flag. -### AWS Secret Engine Roles +### AWS secret engine roles Roles in the AWS Secret Engine were previously ambiguous. For example, if the `arn` parameter had been specified, that could have been interpreted as the ARN @@ -108,7 +108,7 @@ credential type depending on the path used to access it (IAM User if accessed via the `/aws/creds/` endpoint and Federation Token if accessed via the `/aws/sts/` endpoint). -## Full List Since 0.10.0 +## Full list since 0.10.0 ### Revocations of dynamic secrets leases now asynchronous @@ -119,20 +119,20 @@ attained via the `-sync` CLI flag or `sync` API parameter. When in synchronous mode, if the operation results in failure it is up to the user to retry. -### CLI Retries +### CLI retries The CLI will no longer retry commands on 5xx errors. This was a source of confusion to users as to why Vault would "hang" before returning a 5xx error. The Go API client still defaults to two retries. -### Identity Entity Alias metadata +### Identity entity alias metadata You can no longer manually set metadata on entity aliases. All alias data (except the canonical entity ID it refers to) is intended to be managed by the plugin providing the alias information, so allowing it to be set manually didn't make sense. -### Convergent Encryption version 3 +### Convergent encryption version 3 If you are using `transit`'s convergent encryption feature, which prior to this release was at version 2, we recommend diff --git a/website/content/docs/upgrading/upgrade-to-0.11.2.mdx b/website/content/docs/upgrading/upgrade-to-0.11.2.mdx index a36165aca78b..dd79e97f0e12 100644 --- a/website/content/docs/upgrading/upgrade-to-0.11.2.mdx +++ b/website/content/docs/upgrading/upgrade-to-0.11.2.mdx @@ -11,13 +11,13 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 0.11.2 compared to 0.11.1. Please read it carefully. -### `sys/seal-status` Behavior Change +### `sys/seal-status` behavior change The `sys/seal-status` endpoint now includes an initialized boolean in the output. If Vault is not initialized, it will return a 200 with this value set false instead of a 400 -### Mount Config Passthrough Headers +### Mount config passthrough headers The mount config option for `passthrough_request_headers` will now deny certain headers from being provided to backends based on a global denylist. diff --git a/website/content/docs/upgrading/upgrade-to-0.11.6.mdx b/website/content/docs/upgrading/upgrade-to-0.11.6.mdx index 5e58ca08eb54..8e8c9227978d 100644 --- a/website/content/docs/upgrading/upgrade-to-0.11.6.mdx +++ b/website/content/docs/upgrading/upgrade-to-0.11.6.mdx @@ -11,7 +11,7 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 0.11.6 compared to 0.11.5. Please read it carefully. -### Database Secret Engine Role Reads +### Database secret engine role reads On role read, empty statements will be returned as empty slices instead of potentially being returned as JSON null values. This makes it diff --git a/website/content/docs/upgrading/upgrade-to-0.5.0.mdx b/website/content/docs/upgrading/upgrade-to-0.5.0.mdx index 22b53ac6701c..f1c236d48f5f 100644 --- a/website/content/docs/upgrading/upgrade-to-0.5.0.mdx +++ b/website/content/docs/upgrading/upgrade-to-0.5.0.mdx @@ -16,7 +16,7 @@ by HashiCorp have been updated with support for these changes, but if you are using community-supported libraries, you should ensure that they are ready for Vault 0.5 before upgrading. -## Rekey Requires Nonce +## Rekey requires nonce Vault now generates a nonce when a rekey operation is started in order to ensure that the operation cannot be hijacked. The nonce is output when the @@ -31,21 +31,21 @@ As a convenience, if using the CLI interactively to provide the unseal key, the nonce will be displayed for verification but the user will not be required to manually re-type it. -## `TTL` Field in Token Lookup +## `TTL` field in token lookup Previously, the `ttl` field returned when calling `lookup` or `lookup-self` on the token auth method displayed the TTL set at token creation. It now displays the time remaining (in seconds) for the token's validity period. The original behavior has been moved to a field named `creation_ttl`. -## Grace Periods Removed +## Grace periods removed Vault no longer uses grace periods internally for leases or token TTLs. Previously these were set by backends and could differ greatly from one backend to another, causing confusion. TTLs (the `lease_duration` field for a lease, or, for a token lookup, the `ttl`) are now exact. -## `token-renew` CLI Command +## `token-renew` CLI command If the token given for renewal is the same as the token in use by the client, the `renew-self` endpoint will be used in the API rather than the `renew` @@ -53,13 +53,13 @@ endpoint. Since the `default` policy contains `auth/token/renew-self` this makes it much more likely that the request will succeed rather than somewhat confusingly failing due to a lack of permissions on `auth/token/renew`. -## `status` CLI Command +## `status` CLI command The `status` CLI command now returns an exit code of `0` for an unsealed Vault (as before), `2` for a sealed Vault, and `1` for an error. This keeps error return codes consistent across commands. -## Transit Upsertion Behavior Uses Capabilities +## Transit upsertion behavior uses capabilities Previously, attempting to encrypt with a key that did not exist would create a key with default values. This was convenient but ultimately allowed a client to @@ -69,19 +69,19 @@ upsertion behavior is controlled by whether the client has the `create` capability for the request (upsertion is allowed) or only the `update` capability (upsertion is denied). -## etcd Physical Backend Uses `sync` +## etcd physical backend uses `sync` The `etcd` physical backend now supports `sync` functionality and it is turned on by default, which maps to the upstream library's default. It can be disabled; see the configuration page for information. -## S3 Physical Backend Prefers Environment Variables +## S3 physical backend prefers environment variables The `s3` physical backend now prefers environment variables over configuration file variables. This matches the behavior of the rest of the backends and of Vault generally. -## Lease Default and Renewal Handling +## Lease default and renewal handling All backends now honor system and mount-specific default and maximum lease times, except when specifically overridden by backend configuration or role @@ -111,7 +111,7 @@ amount of time a lease or token is valid for before it can no longer be renewed and must be reissued. A mount can be more restrictive with its maximum TTL, but cannot be less restrictive than the mount's maximum TTL.) -#### Credential (Auth) Backends +#### Credential (Auth) backends - `github` – The renewal function now uses the backend's configured maximum TTL, if set; otherwise, the mount maximum TTL is used. @@ -122,7 +122,7 @@ cannot be less restrictive than the mount's maximum TTL.) - `userpass` – The renew function now uses the backend's configured maximum TTL, if set; otherwise the mount maximum TTL is used. -#### Secrets Engines +#### Secrets engines - `aws` – New IAM roles no longer always have a default TTL of one hour, instead honoring the configured default if available and the mount default TTL if not diff --git a/website/content/docs/upgrading/upgrade-to-0.5.1.mdx b/website/content/docs/upgrading/upgrade-to-0.5.1.mdx index dba203163799..9259d080ddfd 100644 --- a/website/content/docs/upgrading/upgrade-to-0.5.1.mdx +++ b/website/content/docs/upgrading/upgrade-to-0.5.1.mdx @@ -11,7 +11,7 @@ description: |- This page contains the list of breaking changes for Vault 0.5.1. Please read it carefully. -## PKI Backend Disallows RSA Keys < 2048 Bits +## PKI backend disallows RSA keys < 2048 bits The PKI backend now refuses to issue a certificate, sign a CSR, or save a role that specifies an RSA key of less than 2048 bits. Smaller keys are considered @@ -21,7 +21,7 @@ inception the PKI backend has mandated SHA256 hashes for its signatures, and software able to handle these certificates should be able to handle certificates with >= 2048-bit RSA keys as well. -## PKI Backend Does Not Automatically Delete Expired Certificates +## PKI backend does not automatically delete expired certificates The PKI backend now does not automatically delete expired certificates, including from the CRL. Doing so could lead to a situation where a time @@ -35,7 +35,7 @@ certificate storage, or both. In addition, you can specify a safety buffer (defaulting to 72 hours) to ensure that any time discrepancies between your hosts is accounted for. -## Cert auth method Performs Client Checking During Renewals +## Cert auth method performs client checking during renewals The `cert` backend now performs a variant of channel binding at renewal time for increased security. In order to not overly burden clients, a notion of diff --git a/website/content/docs/upgrading/upgrade-to-0.6.0.mdx b/website/content/docs/upgrading/upgrade-to-0.6.0.mdx index 4d1098c37741..02626b998d74 100644 --- a/website/content/docs/upgrading/upgrade-to-0.6.0.mdx +++ b/website/content/docs/upgrading/upgrade-to-0.6.0.mdx @@ -11,7 +11,7 @@ description: |- This page contains the list of breaking changes for Vault 0.6 compared to the previous release. Please read it carefully. -## PKI Backend Does Not Issue Leases for CA Certificates +## PKI backend does not issue leases for CA certificates When a token expires, it revokes all leases associated with it. This means that long-lived CA certs need correspondingly long-lived tokens, something that is @@ -24,13 +24,13 @@ CA certificates that have already been issued and acquired leases will report to the lease manager that revocation was successful, but will not actually be revoked and placed onto the CRL. -## The `auth/token/revoke-prefix` Endpoint Has Been Removed +## The `auth/token/revoke-prefix` endpoint has been removed As part of addressing a minor security issue, this endpoint has been removed in favor of using `sys/revoke-prefix` for prefix-based revocation of both tokens and secrets leases. -## Go API Uses `json.Number` For Decoding +## Go API uses `json.Number` for decoding When using the Go API, it now calls `UseNumber()` on the decoder object. As a result, rather than always decode as a `float64`, numbers are returned as a @@ -39,12 +39,12 @@ result, rather than always decode as a `float64`, numbers are returned as a errors where numbers were being decoded as `float64` and printed in scientific notation. -## List Operations Return `404` On No Keys Found +## List operations return `404` on no keys found Previously, list operations on an endpoint with no keys found would return an empty response object. Now, a `404` will be returned instead. -## Consul TTL Checks Automatically Registered +## Consul TTL checks automatically registered If using the Consul HA storage backend, Vault will now automatically register itself as the `vault` service and perform its own health checks/lifecycle diff --git a/website/content/docs/upgrading/upgrade-to-0.6.1.mdx b/website/content/docs/upgrading/upgrade-to-0.6.1.mdx index 6ff4fd4f10f2..5af3b0254483 100644 --- a/website/content/docs/upgrading/upgrade-to-0.6.1.mdx +++ b/website/content/docs/upgrading/upgrade-to-0.6.1.mdx @@ -11,14 +11,14 @@ description: |- This page contains the list of breaking changes for Vault 0.6.1. Please read it carefully. -## Standby Nodes Must Be 0.6.1 As Well +## Standby nodes must be 0.6.1 as well Once an active node is running 0.6.1, only standby nodes running 0.6.1+ will be able to form an HA cluster. If following our [general upgrade instructions](/vault/docs/upgrading) this will not be an issue. -## Health Endpoint Status Code Changes +## Health endpoint status code changes Prior to 0.6.1, the health endpoint would return a `500` (Internal Server Error) for both a sealed and uninitialized state. In both states this was @@ -34,14 +34,14 @@ be adjusted with the `uninitcode` query parameter. This removes ambiguity/confusion and falls more in line with the intention of each status code (including `500`). -## Root Token Creation Restrictions +## Root token creation restrictions Root tokens (tokens with the `root` policy) can no longer be created except by another root token or the [`generate-root`](/vault/api-docs/system/generate-root) endpoint or CLI command. -## PKI Backend Certificates Will Contain Default Key Usages +## PKI backend certificates will contain default key usages Issued certificates from the `pki` backend against roles created or modified after upgrading will contain a set of default key usages. This increases @@ -52,7 +52,7 @@ This behavior is fully adjustable; see the [PKI backend documentation](/vault/docs/secrets/pki) for details. -## DynamoDB Does Not Support HA By Default +## DynamoDB does not support HA by default If using DynamoDB and want to use HA support, you will need to explicitly enable it in Vault's configuration; see the @@ -64,7 +64,7 @@ it is _very important_ that you set this option **before** upgrading your Vault instances. Without doing so, each Vault instance will believe that it is standalone and there could be consistency issues. -## LDAP Auth Method Forgets Bind Password and Insecure TLS Settings +## LDAP auth method forgets bind password and insecure TLS settings Due to a bug, these two settings are forgotten if they have been configured in the LDAP backend prior to 0.6.1. If you are using these settings with LDAP, @@ -72,7 +72,7 @@ please be sure to re-submit your LDAP configuration to Vault after the upgrade, so ensure that you have a valid token to do so before upgrading if you are relying on LDAP authentication for permissions to modify the backend itself. -## LDAP Auth Method Does Not Search `memberOf` +## LDAP auth method does not search `memberOf` The LDAP backend went from a model where all permutations of storing and filtering groups were tried in all cases to one where specific filters are @@ -93,7 +93,7 @@ that they have valid tokens with policies allowing modification of LDAP parameters before upgrading, so that once an upgrade is performed, the new configuration can be specified successfully. -## App-ID is Deprecated +## App-ID is deprecated With the addition of the new [AppRole backend](/vault/docs/auth/approle), App-ID is diff --git a/website/content/docs/upgrading/upgrade-to-0.6.2.mdx b/website/content/docs/upgrading/upgrade-to-0.6.2.mdx index 077c68258c62..fa669d48c9ce 100644 --- a/website/content/docs/upgrading/upgrade-to-0.6.2.mdx +++ b/website/content/docs/upgrading/upgrade-to-0.6.2.mdx @@ -11,14 +11,14 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 0.6.2. Please read it carefully. -## Request Forwarding On By Default +## Request forwarding on by default In 0.6.1 this feature was in beta and required opting-in, but is now enabled by default. This can be disabled via the `"disable_clustering"` parameter in Vault's [config](/vault/docs/configuration), or per-request with the `X-Vault-No-Request-Forwarding` header. -## AppRole Role Constraints +## AppRole role constraints Creating or updating a role now requires at least one constraint to be enabled, whereas previously it was sufficient to require only the role ID by itself. @@ -27,7 +27,7 @@ Currently there are two constraints: `bind_secret_id` and `bound_cidr_list`. the role ID for authentication will continue to work but will require a constraint to be specified if updated. -## Convergent Encryption v2 +## Convergent encryption v2 New keys in `transit` using convergent mode will use a new nonce derivation mechanism rather than require the user to supply a nonce. While not explicitly @@ -36,7 +36,7 @@ improperly and impact the security of their keys. Keys in convergent mode that were created in 0.6.1 will continue to work with the same mechanism (user-supplied nonce). -## `etcd` HA Off By Default +## `etcd` HA off by default Following in the footsteps of `dynamodb`, the `etcd` storage backend now requires that `ha_enabled` be explicitly specified in the configuration file. @@ -45,26 +45,26 @@ use by default without explicitly enabling it. If you are using this functionality, when upgrading, you should set `ha_enabled` to `"true"` _before_ starting the new versions of Vault. -## Reading Wrapped Responses From `cubbyhole/response` Is Deprecated +## Reading wrapped responses from `cubbyhole/response` is deprecated The `sys/wrapping/unwrap` endpoint should be used instead as it provides additional security, auditing, and other benefits. The ability to read directly will be removed in a future release. -## Default/Max Lease/Token TTLs Now 32 Days +## Default/Max Lease/Token TTLs now 32 days In previous versions of Vault the default was 30 days, but changing it to 32 days allows some operations (e.g. reauthenticating, renewing, etc.) to be performed via a monthly cron job. -## AppRole Secret ID Endpoints Changed +## AppRole secret ID endpoints changed Secret ID and Secret ID accessors are no longer part of request URLs. The `GET` and `DELETE` operations are now moved to new endpoints (`/lookup` and `/destroy`) which consumes the input from the body via `POST` (or `PUT`) and not the URL. -## Behavior Change for `bound_iam_role_arn` in AWS-EC2 Backend +## Behavior change for `bound_iam_role_arn` in AWS-EC2 backend In prior versions a bug caused the `bound_iam_role_arn` value in the `aws-ec2` auth method to actually use the instance profile ARN. This has been diff --git a/website/content/docs/upgrading/upgrade-to-0.6.3.mdx b/website/content/docs/upgrading/upgrade-to-0.6.3.mdx index 5404450c7178..63ce624e3384 100644 --- a/website/content/docs/upgrading/upgrade-to-0.6.3.mdx +++ b/website/content/docs/upgrading/upgrade-to-0.6.3.mdx @@ -11,7 +11,7 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 0.6.3. Please read it carefully. -## LDAP Null Binds Disabled By Default +## LDAP null binds disabled by default When using the LDAP auth method, `deny_null_bind` has a default value of `true`, preventing a successful user authentication when an empty password @@ -20,12 +20,12 @@ be set to `false`. Upgrades will keep previous behavior until the LDAP configuration information is rewritten, at which point the new behavior will be utilized. -## Request Size Limitation +## Request size limitation A maximum request size of 32MB is imposed to prevent a denial of service attack with arbitrarily large requests. -## Any Audit Device Successfully Activated Allows Active Duty +## Any audit device successfully activated allows active duty Previously, when a new Vault node was taking over service in an HA cluster, all audit devices were required to be active successfully to take over active diff --git a/website/content/docs/upgrading/upgrade-to-0.6.4.mdx b/website/content/docs/upgrading/upgrade-to-0.6.4.mdx index 59c86dcbb7ae..4421aa44e026 100644 --- a/website/content/docs/upgrading/upgrade-to-0.6.4.mdx +++ b/website/content/docs/upgrading/upgrade-to-0.6.4.mdx @@ -13,7 +13,7 @@ for Vault 0.6.4. Please read it carefully. Note: both of these are security sensitive changes. -## Changes to `default` Policy Addition Rules for `auth/token/create` +## Changes to `default` policy addition rules for `auth/token/create` An issue was reported indicating that in some cases, the stated behavior of the `default` policy being added to tokens unless specifically requested could lead @@ -41,7 +41,7 @@ creating tokens using this endpoint: and `no_default_policy` has been set `true` for the request, the `default` policy will be stripped from the final set of policies. -## Many Users Should Run `auth/token/tidy` +## Many users should run `auth/token/tidy` While investigating a report of accessor entries not being removed correctly from Vault's data store, a security issue was discovered: if limited use-count diff --git a/website/content/docs/upgrading/upgrade-to-0.7.0.mdx b/website/content/docs/upgrading/upgrade-to-0.7.0.mdx index 3d13ac492f1d..f26fc33b375b 100644 --- a/website/content/docs/upgrading/upgrade-to-0.7.0.mdx +++ b/website/content/docs/upgrading/upgrade-to-0.7.0.mdx @@ -18,7 +18,7 @@ storage has now been renamed to `storage`. Vault will alias the old key to the new path, though users are encouraged to update their configuration to ensure minimal disruption in the future when the alias is removed. -## List Operations Always Use Trailing Slash +## List operations always use trailing slash Any list operation, whether via the `GET` or `LIST` HTTP verb, will now internally canonicalize the path to have a trailing slash. This makes policy @@ -28,7 +28,7 @@ it also means that policies allowing `list` capability must be carefully checked to ensure that they contain a trailing slash; some policies may need to be split into multiple stanzas to accommodate. -## PKI Defaults to Unleased Certificates +## PKI defaults to unleased certificates When issuing certificates from the PKI backend, by default, no leases will be issued. If you want to manually revoke a certificate, its serial number can be diff --git a/website/content/docs/upgrading/upgrade-to-0.8.0.mdx b/website/content/docs/upgrading/upgrade-to-0.8.0.mdx index 9d18421290c1..2ceee82a847f 100644 --- a/website/content/docs/upgrading/upgrade-to-0.8.0.mdx +++ b/website/content/docs/upgrading/upgrade-to-0.8.0.mdx @@ -11,7 +11,7 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 0.8.0 compared to the most recent release. Please read it carefully. -## Enterprise Upgrade Procedure +## Enterprise upgrade procedure If you are upgrading from Vault Enterprise, you should take one of the following upgrade paths. Please note that reindexing stops the ability of the @@ -25,26 +25,26 @@ different indexes. One will happen automatically when the cluster is upgraded to 0.8.0. _This happens even if you are not currently using replication._ The other can be done in one of a few ways, as follows. -### If Not Using Replication +### If not using replication If not using replication, no further action needs to be taken. -### If Using Replication +### If using replication -#### Option 1: Reindex the Primary, then Upgrade Secondaries +#### Option 1: reindex the primary, then upgrade secondaries The first option is to issue a write to [`sys/replication/reindex`][reindex] on the primary (it is not necessary on the secondaries). When the reindex on the primary is finished, upgrade the secondaries, then upgrade the primary. -#### Option 2: Upgrade All Nodes Simultaneously +#### Option 2: upgrade all nodes simultaneously The second option is to upgrade all nodes to 0.8.0 at the same time. This removes the need to perform an explicit reindex but may equate to more down time since secondaries will not be able to service requests while the primary is performing an explicit reindex. -## `sys/revoke-force` Requires `sudo` Capability +## `sys/revoke-force` requires `sudo` capability This path was meant to require `sudo` capability but was not implemented this way. It now requires `sudo` capability to run. diff --git a/website/content/docs/upgrading/upgrade-to-0.9.0.mdx b/website/content/docs/upgrading/upgrade-to-0.9.0.mdx index f977bcc91c20..e2b7a6fca37d 100644 --- a/website/content/docs/upgrading/upgrade-to-0.9.0.mdx +++ b/website/content/docs/upgrading/upgrade-to-0.9.0.mdx @@ -11,34 +11,34 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 0.9.0 compared to the most recent release. Please read it carefully. -### PKI Root Generation (Since 0.8.1) +### PKI root generation (Since 0.8.1) Calling [`pki/root/generate`][generate-root] when a CA cert/key already exists will now return a `204` instead of overwriting an existing root. If you want to recreate the root, first run a delete operation on `pki/root` (requires `sudo` capability), then generate it again. -### Token Period in AWS IAM Auth (Since 0.8.2) +### Token period in AWS IAM auth (Since 0.8.2) In prior versions of Vault, if authenticating via AWS IAM and requesting a periodic token, the period was not properly respected. This could lead to tokens expiring unexpectedly, or a token lifetime being longer than expected. Upon token renewal with Vault 0.8.2 the period will be properly enforced. -### SSH CLI Parameters (Since 0.8.2) +### SSH CLI parameters (Since 0.8.2) `vault ssh` users should supply `-mode` and `-role` to reduce the number of API calls. A future version of Vault will mark these optional values are required. Failure to supply `-mode` or `-role` will result in a warning. -### Vault Plugin Init (Since 0.8.2) +### Vault plugin init (Since 0.8.2) Vault plugins will first briefly run a restricted version of the plugin to fetch metadata, and then lazy-load the plugin on first request to prevent crash/deadlock of Vault during the unseal process. Plugins will need to be built with the latest changes in order for them to run properly. -### Policy Input Format Standardization (Since 0.8.3) +### Policy input format standardization (Since 0.8.3) For all built-in authentication backends, policies can now be specified as a comma-delimited string or an array if using JSON as API input; on read, @@ -70,7 +70,7 @@ for the encryption keyring itself. To better reflect its actual use, the `generic` backend is now `kv`. Using `generic` will still work for backwards compatibility. -### HSM Users Need to Specify New Config Options (In 0.9) +### HSM users need to specify new config options (In 0.9) When using Vault with an HSM, a new parameter is required: `hmac_key_label`. This performs a similar function to `key_label` but for the HMAC key Vault will @@ -94,7 +94,7 @@ clients can choose to supply a custom nonce to the login endpoint. The custom nonce set by the client will from now on, not be returned back with the authentication response, and hence not audit logged. -### AWS Auth role options (In 0.9) +### AWS auth role options (In 0.9) The API will now error when trying to create or update a role with the mutually-exclusive options `disallow_reauthentication` and diff --git a/website/content/docs/upgrading/upgrade-to-0.9.1.mdx b/website/content/docs/upgrading/upgrade-to-0.9.1.mdx index 06a28495d523..1a2df1af12e2 100644 --- a/website/content/docs/upgrading/upgrade-to-0.9.1.mdx +++ b/website/content/docs/upgrading/upgrade-to-0.9.1.mdx @@ -11,7 +11,7 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 0.9.1 compared to 0.9.0. Please read it carefully. -### AppRole Case Sensitivity +### AppRole case sensitivity In prior versions of Vault, `list` operations against AppRole roles would require preserving case in the role name, even though most other operations @@ -19,36 +19,36 @@ within AppRole are case-insensitive with respect to the role name. This has been fixed; existing roles will behave as they have in the past, but new roles will act case-insensitively in these cases. -### Token Auth Backend Roles Parameter Types +### Token auth backend roles parameter types For `allowed_policies` and `disallowed_policies` in role definitions in the token auth backend, input can now be a comma-separated string or an array of strings. Reading a role will now return arrays for these parameters. -### Transit Key Exporting +### Transit key exporting You can now mark a key in the `transit` backend as `exportable` at any time, rather than just at creation time; however, once this value is set, it still cannot be unset. -### PKI Secret Backend Roles Parameter Types +### PKI secret backend roles parameter types For `allowed_domains` and `key_usage` in role definitions in the PKI secret backend, input can now be a comma-separated string or an array of strings. Reading a role will now return arrays for these parameters. -### SSH Dynamic Keys Method Defaults to 2048-bit Keys +### SSH dynamic keys method defaults to 2048-bit keys When using the dynamic key method in the SSH backend, the default is now to use 2048-bit keys if no specific key bit size is specified. -### Consul Secret Backend Lease Handling +### Consul secret backend lease handling The `consul` secret backend can now accept both strings and integer numbers of seconds for its lease value. The value returned on a role read will be an integer number of seconds instead of a human-friendly string. -### Unprintable Characters Not Allowed in API Paths +### Unprintable characters not allowed in API paths Unprintable characters are no longer allowed in names in the API (paths and path parameters), with an extra restriction on whitespace characters. Allowed diff --git a/website/content/docs/upgrading/upgrade-to-0.9.2.mdx b/website/content/docs/upgrading/upgrade-to-0.9.2.mdx index 0e827c511dcc..3bfd242e0d58 100644 --- a/website/content/docs/upgrading/upgrade-to-0.9.2.mdx +++ b/website/content/docs/upgrading/upgrade-to-0.9.2.mdx @@ -11,7 +11,7 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 0.9.2 compared to 0.9.1. Please read it carefully. -### Backwards Compatible CLI Changes +### Backwards compatible CLI changes This upgrade guide is typically reserved for breaking changes, however it is worth calling out that the CLI interface to Vault has been completely @@ -26,7 +26,7 @@ Documentation for previous versions of Vault can be accessed using the GitHub interface by browsing tags (eg [0.9.1 website tree](https://github.com/hashicorp/vault/tree/v0.9.1/website)) or by [building the Vault website locally](https://github.com/hashicorp/vault/tree/v0.9.1/website#running-the-site-locally). -### `sys/health` DR Secondary Reporting +### `sys/health` DR secondary reporting The `replication_dr_secondary` bool returned by `sys/health` could be misleading since it would be `false` both when a cluster was not a DR secondary @@ -41,13 +41,13 @@ replication is disabled or the state is still being discovered. As a result, an LB check can positively verify that the node is both not `disabled` and is not a DR secondary, and avoid sending traffic to it if either is true. -### PKI Secret Backend Roles Parameter Types +### PKI secret backend roles parameter types For `ou` and `organization` in role definitions in the PKI secret backend, input can now be a comma-separated string or an array of strings. Reading a role will now return arrays for these parameters. -### Plugin API Changes +### Plugin API changes The plugin API has been updated to utilize golang's context.Context package. Many function signatures now accept a context object as the first parameter. diff --git a/website/content/docs/upgrading/upgrade-to-0.9.6.mdx b/website/content/docs/upgrading/upgrade-to-0.9.6.mdx index 747b16741517..22df2d7e7503 100644 --- a/website/content/docs/upgrading/upgrade-to-0.9.6.mdx +++ b/website/content/docs/upgrading/upgrade-to-0.9.6.mdx @@ -11,14 +11,14 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 0.9.6 compared to 0.9.5. Please read it carefully. -### Change to AWS Role Output +### Change to AWS role output The AWS authentication backend now allows binds for inputs as either a comma-delimited string or a string array. However, to keep consistency with input and output, when reading a role the binds will now be returned as string arrays rather than strings. -### Change to AWS IAM Auth ARN Prefix Matching +### Change to AWS IAM auth ARN prefix matching In order to prefix-match IAM role and instance profile ARNs in AWS auth backend, you now must explicitly opt-in by adding a `*` to the end of the ARN. diff --git a/website/content/docs/upgrading/upgrade-to-1.0.0.mdx b/website/content/docs/upgrading/upgrade-to-1.0.0.mdx index 497fbd80b892..7def400dd099 100644 --- a/website/content/docs/upgrading/upgrade-to-1.0.0.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.0.0.mdx @@ -11,38 +11,38 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 0.11.5 compared to 1.0.0. Please read it carefully. -## Token Format Change +## Token format change Tokens are now prefixed by a designation to indicate what type of token they are. Service tokens start with s. and batch tokens start with b.. Existing tokens will still work (they are all of service type and will be considered as such). Prefixing allows us to be more efficient when consuming a token, which keeps the critical path of requests faster. -## Key Encoding Enforcement +## Key encoding enforcement Vault will no longer accept updates when the storage key has invalid UTF-8 character encoding. -## Upsert in Mount Tuning Endpoints +## Upsert in mount tuning endpoints Mount/Auth tuning the options map on backends will now upsert any provided values, and keep any of the existing values in place if not provided. The options map itself cannot be unset once it's set, but the keypairs within the map can be unset if an empty value is provided, with the exception of the version keypair which is handled differently for KVv2 purposes. -## Agent Reauthentication +## Agent reauthentication Agent no longer automatically reauthenticates when new credentials are detected. It's not strictly necessary and in some cases was causing reauthentication much more often than intended. -## HSM Key Regeneration Removed +## HSM key regeneration removed Vault no longer supports destroying and regenerating encryption keys on an HSM; it only supports creating them. Although this has never been a source of a customer incident, it is simply a code path that is too trivial to activate, especially by mistyping regenerate_key instead of generate_key. -## Seal Upgrade before Migration +## Seal upgrade before migration When upgrading from Vault 0.8.x, the seal type in the barrier config storage entry will be upgraded from "hsm-auto" to "awskms" or "pkcs11" upon unseal if using AWSKMS or HSM seals. If performing seal migration, the barrier config should first be upgraded prior to starting migration. -## Pooled API Client +## Pooled API client The Go API client now uses a connection-pooling HTTP client by default. For CLI operations this makes no difference but it should provide significant performance benefits for those writing custom clients using the Go API library. As before, this can be changed to any custom HTTP client by the caller. -## Plugin Catalog Changes +## Plugin catalog changes Builtin Secret Engines and Auth Methods are integrated deeper into the plugin system. The plugin catalog can now override builtin plugins with custom versions of the same name. Additionally the plugin system now requires a plugin type field when configuring plugins, this can be "auth", "database", or "secret". -## Removed Endpoints +## Removed endpoints Paths within auth/token that allow specifying a token or accessor in the URL have been removed. These have been deprecated since March 2016 and undocumented, but were retained for backwards compatibility. They shouldn't be used due to the possibility of those paths being logged, so at this point they are simply being removed. diff --git a/website/content/docs/upgrading/upgrade-to-1.1.0.mdx b/website/content/docs/upgrading/upgrade-to-1.1.0.mdx index 8e2138c7af79..2231a83bc254 100644 --- a/website/content/docs/upgrading/upgrade-to-1.1.0.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.1.0.mdx @@ -11,7 +11,7 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 1.0.3 compared to 1.1.0. Please read it carefully. -## JWT Backend Changes +## JWT backend changes Specifying the group claims parameter has changed to use a standards based lookup. The groups_claim_delimiter_pattern has been removed and if the groups claim is not at the top level, it can now be specified as a JSONPointer. @@ -19,17 +19,17 @@ has been removed and if the groups claim is not at the top level, it can now be Additionally, roles now have a "role type" parameter with a default type of "oidc". To configure new JWT roles, a role type of "jwt" must be explicitly specified. -## Deprecated CLI Commands Removed +## Deprecated CLI commands removed CLI commands deprecated in 0.9.2 are now removed. Please see the CLI help output for updated commands. -## Additional Changes +## Additional changes - Vault no longer automatically mounts a k/v backend at the "secret/" path when initializing Vault. - Vault's cluster port will now be opened on HA standby nodes. - Vault no longer supports running netRPC plugins. These were deprecated in favor of gRPC based plugins and any plugin built since 0.9.4 defaults to gRPC. Older plugins may need to be recompiled against the latest Vault dependencies. -## Known Issues +## Known issues -> **NOTE:** This is a known issue applicable to _Vault Enterprise_. diff --git a/website/content/docs/upgrading/upgrade-to-1.1.1.mdx b/website/content/docs/upgrading/upgrade-to-1.1.1.mdx index 7d469f52c8b3..21acde16b8a3 100644 --- a/website/content/docs/upgrading/upgrade-to-1.1.1.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.1.1.mdx @@ -11,7 +11,7 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 1.1.0 compared to 1.1.1. Please read it carefully. -## Known Issues +## Known issues ### Issue with some KVv2 mounts @@ -21,7 +21,7 @@ contains no data. This will be fixed in 1.1.2. Additionally a work around does exist: prior to upgrading ensure all KV v2 mounts have at least one key written to it. -### Change in LDAP Group CN handling +### Change in LDAP group CN handling A bug fix to allow group CNs to be found from an LDAP server in lowercase `cn` as well as uppercase `CN` had an unintended consequence. If prior to that a @@ -50,11 +50,11 @@ and we recommend upgrading to Vault 1.1.3+ rather than any prior 1.1.x version. We also strongly recommend upgrading your Vault cluster to 1.1.3 if you are running Vault Enterprise 1.1.0, 1.1.1 or 1.1.2. -## JWT/OIDC Plugin +## JWT/OIDC plugin Logins of role_type "oidc" via the /login path are no longer allowed. -## ACL Wildcards +## ACL wildcards New ordering defines which policy wins when there are multiple inexact matches and at least one path contains `+`. `+*` is now illegal in policy paths. The diff --git a/website/content/docs/upgrading/upgrade-to-1.1.2.mdx b/website/content/docs/upgrading/upgrade-to-1.1.2.mdx index 313ffb0f95b9..18f32c5a407d 100644 --- a/website/content/docs/upgrading/upgrade-to-1.1.2.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.1.2.mdx @@ -11,7 +11,7 @@ description: |- This page explains a known issue upgrading to Vault 1.1.2 for Enterprise users. Please read it carefully. -## Known Issues +## Known issues -> **NOTE:** This is a known issue applicable to _Vault Enterprise_. diff --git a/website/content/docs/upgrading/upgrade-to-1.10.x.mdx b/website/content/docs/upgrading/upgrade-to-1.10.x.mdx index 15dd4db04477..6522bccc593e 100644 --- a/website/content/docs/upgrading/upgrade-to-1.10.x.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.10.x.mdx @@ -11,7 +11,7 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 1.10.x compared to 1.9. Please read it carefully. -## SSH Secrets Engine +## SSH secrets engine The new default value of `algorithm_signer` for SSH CA roles has been changed to `rsa-sha2-256` from `ssh-rsa`. Existing roles will be migrated to @@ -32,7 +32,7 @@ All storage migrations should have [backups](/vault/docs/concepts/storage#backing-up-vault-s-persisted-data) taken prior to migration. -## OTP Generation Process +## OTP generation process Customers passing in OTPs during the process of generating root tokens must modify the OTP generation to include an additional 2 characters before upgrading so that the @@ -47,7 +47,7 @@ via login), if the token and its lease haven't yet been replicated to the perf standby, an HTTP 412 error will be returned. Before 1.10.0 this typically would've resulted in a 400, 403, or 50x response. -## Token Format Change +## Token format change Token prefixes were updated to be more easily identifiable. @@ -61,7 +61,7 @@ still work. Refer to the [Server Side Consistent Token FAQ](/vault/docs/faq/ssct) for details. -## OIDC Provider Built-in Resources +## OIDC provider built-in resources In Vault 1.9, the [OIDC identity provider](/vault/docs/secrets/identity/oidc-provider) feature was released as a tech preview. In Vault 1.10, built-in resources were introduced to the @@ -85,7 +85,7 @@ naming collisions could result unexpected default behavior. Additionally, we rec the corresponding details in the OIDC provider [concepts](/vault/docs/concepts/oidc-provider) document to understand how the built-in resources are used in the system. -## Known Issues +## Known issues @include 'raft-retry-join-failure.mdx' @@ -93,7 +93,7 @@ to understand how the built-in resources are used in the system. @include 'tokenization-rotation-persistence.mdx' -### Errors returned by perf standbys lagging behind active node with Consul storage +### Errors returned by perf standbys lagging behind active node with consul storage The introduction of [Server Side Consistent Tokens](/vault/docs/faq/ssct) means that when issuing a request to a perf standby right after having obtained a token (e.g. @@ -115,7 +115,7 @@ We will have a fix for this issue in Vault 1.10.3. Until this issue is fixed, yo When a user has a policy that allows creating a secret engine but not reading it, after successful creation, the user sees a message n is undefined instead of a permissions error. We will have a fix for this issue in an upcoming minor release. -### Adding/Modifying Duo MFA method for Enterprise MFA triggers a panic error +### Adding/Modifying Duo MFA method for enterprise MFA triggers a panic error When adding or modifying a Duo MFA method for step-up Enterprise MFA using the `sys/mfa/method/duo` endpoint, a panic gets triggered due to a missing schema field. We will have a fix for this in Vault 1.10.1. Until this issue is fixed, avoid making any changes to your Duo configuration if you are upgrading Vault to v1.10.0. diff --git a/website/content/docs/upgrading/upgrade-to-1.11.x.mdx b/website/content/docs/upgrading/upgrade-to-1.11.x.mdx index adc3279ceb12..54d775ec70bf 100644 --- a/website/content/docs/upgrading/upgrade-to-1.11.x.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.11.x.mdx @@ -11,7 +11,7 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 1.11.x compared to 1.10. Please read it carefully. -## Elasticsearch Database Secrets Engine +## Elasticsearch database secrets engine The Elaticsearch Database Secrets Engine now uses the new `/_security` base API path instead of `/_xpack/security` when managing Elasticsearch. If users are on @@ -23,13 +23,13 @@ API path by setting the [bool config option](/vault/api-docs/secret/databases/el @include 'pgx-params.mdx' -## Known Issues +## Known issues @include 'raft-retry-join-failure.mdx' @include 'tokenization-rotation-persistence.mdx' -### LDAP Pagination Issue +### LDAP pagination issue There was a regression introduced in 1.11.10 relating to LDAP maximum page sizes, resulting in an error `no LDAP groups found in groupDN [...] only policies from locally-defined groups available`. The issue @@ -40,7 +40,7 @@ As a workaround, disable paged searching using the following: vault write auth/ldap/config max_page_size=-1 ``` -#### Impacted Versions +#### Impacted versions Affects Vault 1.11.10. diff --git a/website/content/docs/upgrading/upgrade-to-1.12.x.mdx b/website/content/docs/upgrading/upgrade-to-1.12.x.mdx index 368b2c0a63f9..43036cc9d716 100644 --- a/website/content/docs/upgrading/upgrade-to-1.12.x.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.12.x.mdx @@ -13,7 +13,7 @@ for Vault 1.12.x compared to 1.11. Please read it carefully. ## Changes -### Supported Storage Backends +### Supported storage backends Vault Enterprise will now perform a supported storage check at startup. There is no impact on open-source Vault users. @@ -21,7 +21,7 @@ Vault Enterprise will now perform a supported storage check at startup. There is @include 'consul-dataplane-upgrade-note.mdx' -### External Plugin Loading +### External plugin loading Vault 1.12.0 introduced a change to how external plugins are loaded. Prior to Vault 1.12.0 plugins were lazy loaded on startup. This means that plugin @@ -29,7 +29,7 @@ processes were killed after a successful mount and then respawned when a request is routed to them. Vault 1.12.0 introduced auto mutual TLS for secrets/auth plugins so we do not lazy load them on startup anymore. -## Known Issues +## Known issues ### Pinning to builtin plugin versions may cause failure on upgrade @@ -88,7 +88,7 @@ remediations if you have any affected mounts: The bug was introduced by commit https://github.com/hashicorp/vault/commit/c36330f4c713b886a8a23c08cbbd862a7c530fc8. -#### Impacted Versions +#### Impacted versions Affects upgrading from 1.12.0 to 1.12.1. All other upgrade paths are unaffected. 1.12.2 will introduce a fix that enables upgrades from affected deployments of @@ -127,7 +127,7 @@ feature](/vault/docs/deprecation/faq#q-what-should-i-do-if-i-use-mount-filters-a For more information on the phases of deprecation, see the [Deprecation Notices FAQ](/vault/docs/deprecation/faq#q-what-are-the-phases-of-deprecation). -#### Impacted Versions +#### Impacted versions Affects upgrading from any version of Vault to 1.12.x. All other upgrade paths are unaffected. @@ -165,7 +165,7 @@ will succeed: The bug was introduced by commit https://github.com/hashicorp/vault/commit/76165052e54f884ed0aa2caa496083dc84ad1c19. -#### Impacted Versions +#### Impacted versions Affects versions 1.12.0, 1.12.1, and 1.12.2. A fix will be released in 1.12.3. @@ -177,7 +177,7 @@ handler. As a workaround, OCSP POST requests can be used which are unaffected. -#### Impacted Versions +#### Impacted versions Affects version 1.12.3. A fix will be released in 1.12.4. @@ -185,7 +185,7 @@ Affects version 1.12.3. A fix will be released in 1.12.4. @include 'ocsp-redirect.mdx' -### LDAP Pagination Issue +### LDAP pagination issue There was a regression introduced in 1.12.6 relating to LDAP maximum page sizes, resulting in an error `no LDAP groups found in groupDN [...] only policies from locally-defined groups available`. The issue @@ -196,11 +196,11 @@ As a workaround, disable paged searching using the following: vault write auth/ldap/config max_page_size=-1 ``` -#### Impacted Versions +#### Impacted versions Affects Vault 1.12.6. -### Slow Startup Time When Storing PKI Certificates +### Slow startup time when storing PKI certificates There was a regression introduced in 1.12.0 where Vault is slow to start because the PKI secret engine performs a list operation on the stored certificates. If a large number @@ -210,7 +210,7 @@ There is currently no workaround for this other than limiting the number of cert in Vault via the [PKI tidy](/vault/api-docs/secret/pki#tidy) or using `no_store` flag for [PKI roles](/vault/api-docs/secret/pki#createupdate-role). -#### Impacted Versions +#### Impacted versions Affects Vault 1.12.0+ diff --git a/website/content/docs/upgrading/upgrade-to-1.13.x.mdx b/website/content/docs/upgrading/upgrade-to-1.13.x.mdx index 30e4b75cc3d2..db3990364898 100644 --- a/website/content/docs/upgrading/upgrade-to-1.13.x.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.13.x.mdx @@ -36,7 +36,7 @@ releases. Maintenance mode means that we will fix bugs and security issues but w new features. For additional information, see the [deprecation table](/vault/docs/deprecation) and [migration guide](/vault/docs/secrets/ad/migration-guide). -### AliCloud Auth Role Parameter +### AliCloud auth role parameter The AliCloud auth plugin will now require the `role` parameter on login. This has always been documented as a required field but the requirement will now be @@ -84,18 +84,18 @@ feature](/vault/docs/deprecation/faq#q-what-should-i-do-if-i-use-mount-filters-a For more information on the phases of deprecation, see the [Deprecation Notices FAQ](/vault/docs/deprecation/faq#q-what-are-the-phases-of-deprecation). -#### Impacted Versions +#### Impacted versions Affects upgrading from any version of Vault to 1.13.x. All other upgrade paths are unaffected. -## Known Issues +## Known issues @include 'tokenization-rotation-persistence.mdx' @include 'ocsp-redirect.mdx' -### PKI Revocation Request Forwarding +### PKI revocation request forwarding If a revocation request comes in to a standby or performance secondary node, for a certificate that is present locally, the request will not be correctly @@ -116,11 +116,11 @@ An additional workaround for users rendering STS credentials via the Vault Agent `static-secret-render-interval` for a template using the credentials. Setting this configuration to 15 minutes accommodates the default minimum duration of an STS token and overrides the default render interval of 5 minutes. -#### Impacted Versions +#### Impacted versions Affects Vault 1.13.0 only. -### LDAP Pagination Issue +### LDAP pagination issue There was a regression introduced in 1.13.2 relating to LDAP maximum page sizes, resulting in an error `no LDAP groups found in groupDN [...] only policies from locally-defined groups available`. The issue @@ -131,11 +131,11 @@ As a workaround, disable paged searching using the following: vault write auth/ldap/config max_page_size=-1 ``` -#### Impacted Versions +#### Impacted versions Affects Vault 1.13.2. -### PKI Cross-Cluster Revocation Requests and Unified CRL/OCSP +### PKI Cross-Cluster revocation requests and unified CRL/OCSP When revoking certificates on a cluster that doesn't own the certificate, writing the revocation request will fail with @@ -147,7 +147,7 @@ As a workaround, submit revocation requests to the cluster which issued the certificate, or use BYOC revocation. Use cluster-local OCSP and CRLs until this is resolved. -#### Impacted Versions +#### Impacted versions Affects Vault 1.13.0 to 1.13.2. Fixed in 1.13.3. @@ -155,7 +155,7 @@ On upgrade, all local revocations will be synchronized between clusters; revocation requests are not persisted when failing to write cross-cluster. -### Slow Startup Time When Storing PKI Certificates +### Slow startup time when storing PKI certificates There was a regression introduced in 1.13.0 where Vault is slow to start because the PKI secret engine performs a list operation on the stored certificates. If a large number @@ -165,7 +165,7 @@ There is currently no workaround for this other than limiting the number of cert in Vault via the [PKI tidy](/vault/api-docs/secret/pki#tidy) or using `no_store` flag for [PKI roles](/vault/api-docs/secret/pki#createupdate-role). -#### Impacted Versions +#### Impacted versions Affects Vault 1.13.0+ diff --git a/website/content/docs/upgrading/upgrade-to-1.2.0.mdx b/website/content/docs/upgrading/upgrade-to-1.2.0.mdx index fbdb4f59891e..5a641852f109 100644 --- a/website/content/docs/upgrading/upgrade-to-1.2.0.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.2.0.mdx @@ -11,15 +11,15 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 1.2.0 compared to 1.1.0. Please read it carefully. -## Known Issues +## Known issues -### AppRole Upgrade Issue +### AppRole upgrade issue Due to a bug, on upgrade AppRole roles cannot be read properly. If using AppRole, do not upgrade until this issue is fixed in 1.2.1. ## Changes/Deprecations -### Path Character Handling +### Path character handling Due to underlying changes in Go's runtime past version 1.11.5, Vault is now stricter about what characters it will accept in path names. Whereas before it @@ -29,24 +29,24 @@ library before the request is passed to Vault, and this cannot be disabled. To continue using these (e.g. for already-written paths), they must be properly percent-encoded (e.g. `\r` becomes `%0D`, `\x00` becomes `%00`, and so on). -### AWSKMS Seal Region +### AWSKMS seal region The user-configured regions on the AWSKMS seal stanza will now be preferred over regions set in the enclosing environment. -### Audit Logging of Empty Values +### Audit logging of empty values All values in audit logs now are omitted if they are empty. This helps reduce the size of audit log entries by not reproducing keys in each entry that commonly don't contain any value, which can help in cases where audit log entries are above the maximum UDP packet size and others. -### Rollback Logging +### Rollback logging Rollback will no longer display log messages when it runs; it will only display messages if an error occurs. -### Database Plugins +### Database plugins Database plugins now default to 4 max open connections rather than 2. This should be safe in nearly all cases and fixes some issues where a single @@ -55,7 +55,7 @@ connections just for that operation. However, this could result in an increase in held open file descriptors for each database configuration, so ensure that there is sufficient overhead. -### AppRole Various Changes +### AppRole various changes - AppRole uses new, common token fields for values that overlap with other auth methods. `period` and `policies` will continue to work, with priority being @@ -68,7 +68,7 @@ there is sufficient overhead. - The long-deprecated `bound_cidr_list` is no longer returned when reading a role. -### Token Store Roles Changes +### Token store roles changes Token store roles use new, common token fields for the values that overlap with other auth backends. `period`, `explicit_max_ttl`, and `bound_cidrs` will @@ -78,7 +78,7 @@ if they were used to provide values initially; however, in Vault 1.4 if `period` or `explicit_max_ttl` is zero they will no longer be returned. (`explicit_max_ttl` was already not returned if empty.) -### Go API/SDK Changes +### Go API/SDK changes Vault now uses Go's official dependency management system, Go Modules, to manage dependencies. As a result to both reduce transitive dependencies for API @@ -88,7 +88,7 @@ functions have also moved from plugin helper code to the `api/` submodule. If you are a plugin author, take a look at some of our official plugins and the paths they are importing for guidance. -### Change in LDAP Group CN handling +### Change in LDAP group CN handling A bug fix put in place in Vault 1.1.1 to allow group CNs to be found from an LDAP server in lowercase `cn` as well as uppercase `CN` had an unintended @@ -101,11 +101,11 @@ there is a boolean config setting `use_pre111_group_cn_behavior` to allow reverting to the old matching behavior; we also attempt to upgrade exiting configs to have that defaulted to true. -### JWT/OIDC Plugin +### JWT/OIDC plugin Logins of role_type "oidc" via the /login path are no longer allowed. -### ACL Wildcards +### ACL wildcards New ordering put into place in Vault 1.1.1 defines which policy wins when there are multiple inexact matches and at least one path contains `+`. `+*` is now diff --git a/website/content/docs/upgrading/upgrade-to-1.2.1.mdx b/website/content/docs/upgrading/upgrade-to-1.2.1.mdx index 55757a086f6d..aba0db599bc8 100644 --- a/website/content/docs/upgrading/upgrade-to-1.2.1.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.2.1.mdx @@ -11,9 +11,9 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 1.2.1 compared to 1.2.0. Please read it carefully. -## Known Issues +## Known issues -### AppRole Upgrade Issue +### AppRole upgrade issue Vault 1.2.1 contains a known issue where an existing AppRole role may not be read or updated under a specific scenario. The role in diff --git a/website/content/docs/upgrading/upgrade-to-1.2.4.mdx b/website/content/docs/upgrading/upgrade-to-1.2.4.mdx index b52ce22a10a6..5b09b112d7b1 100644 --- a/website/content/docs/upgrading/upgrade-to-1.2.4.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.2.4.mdx @@ -11,7 +11,7 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 1.2.4 compared to 1.2.3. Please read it carefully. -## Detached Leases From Tokens in non-root Namespaces +## Detached leases from tokens in non-root namespaces In a non-root namespace, revocation of a token scoped to a non-root namespace did not trigger the expected revocation of dynamic secret leases associated with @@ -19,7 +19,7 @@ that token. As a result, dynamic secret leases in non-root namespaces may outlive the token that created them. This vulnerability, CVE-2019-18616, affects Vault Enterprise 0.11.0 and newer. -## Mount Filtering in Disaster Recovery Secondary Clusters +## Mount filtering in disaster recovery secondary clusters Disaster Recovery secondary clusters did not delete already-replicated data after a mount filter has been created on an upstream Performance secondary @@ -33,7 +33,7 @@ Enterprise 0.8 and newer. Update version of Go to 1.12.12 to fix Go bug golang.org/issue/34960 which corresponds to CVE-2019-17596. -## AWS Region Detection in Agent and CLI +## AWS region detection in agent and CLI If a custom sts_endpoint is configured, Vault Agent and the CLI should provide the corresponding region via the region parameter (which already existed as a diff --git a/website/content/docs/upgrading/upgrade-to-1.2.5.mdx b/website/content/docs/upgrading/upgrade-to-1.2.5.mdx index a0741e18875c..6022aa3807b2 100644 --- a/website/content/docs/upgrading/upgrade-to-1.2.5.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.2.5.mdx @@ -11,7 +11,7 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 1.2.5 compared to 1.2.4. Please read it carefully. -## Known Issues +## Known issues Due to the known issues, we recommend skipping 1.2.5 and upgrading directly to 1.2.6. diff --git a/website/content/docs/upgrading/upgrade-to-1.2.6.mdx b/website/content/docs/upgrading/upgrade-to-1.2.6.mdx index 9e05284c0ede..c30960b72718 100644 --- a/website/content/docs/upgrading/upgrade-to-1.2.6.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.2.6.mdx @@ -11,7 +11,7 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 1.2.6 compared to 1.2.4. Please read it carefully. -## Known Issues +## Known issues @include 'aws-invalid-header.mdx' diff --git a/website/content/docs/upgrading/upgrade-to-1.3.0.mdx b/website/content/docs/upgrading/upgrade-to-1.3.0.mdx index dac71b509523..28dd8e549d97 100644 --- a/website/content/docs/upgrading/upgrade-to-1.3.0.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.3.0.mdx @@ -28,7 +28,7 @@ on port scanners and other security utilities that assumed insecure ciphers were being used. The previous behavior can be achieved by setting the value of the (undocumented) cluster_cipher_suites config flag to tls12. -## API/Agent Renewal Behavior +## API/Agent renewal behavior The API now allows multiple options for how it deals with renewals. The legacy behavior in the Agent/API is for the renewer (now called the lifetime watcher) @@ -39,7 +39,7 @@ custom code, to disable renewals entirely, which allows the lifetime watcher to simply return when it believes it is time for your code to renew or reauthenticate. -## Filtered Mount Replication Deprecation +## Filtered mount replication deprecation As of 1.3.0, paths that were once filtered with [Filtered Mount Replication](/vault/api-docs/system/replication/replication-performance#create-mounts-filter-deprecated) diff --git a/website/content/docs/upgrading/upgrade-to-1.3.5.mdx b/website/content/docs/upgrading/upgrade-to-1.3.5.mdx index 1d8d42d9ceda..3422171b5a8c 100644 --- a/website/content/docs/upgrading/upgrade-to-1.3.5.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.3.5.mdx @@ -11,7 +11,7 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 1.3.5 compared to 1.3.4. Please read it carefully. -## AWS Auth Metadata +## AWS auth metadata The metadata handling for AWS Auth logins has changed: @@ -19,7 +19,7 @@ The default set of metadata fields has been changed to `account_id` and `auth_ty application relies on fields that were removed, they may be added back via the AWS Auth identity configuration endpoint (see example below). -## Known Issues +## Known issues The AWS metadata changes have caused an issue preventing renewal of tokens issued via AWS Auth. This has been fixed in Vault 1.3.6. The issue may be addressed in Vault 1.3.5 by configuring the diff --git a/website/content/docs/upgrading/upgrade-to-1.3.8.mdx b/website/content/docs/upgrading/upgrade-to-1.3.8.mdx index 9ee083ed4512..8d65543946cb 100644 --- a/website/content/docs/upgrading/upgrade-to-1.3.8.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.3.8.mdx @@ -11,7 +11,7 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 1.3.8 compared to 1.3.7. Please read it carefully. -## Known Issues +## Known issues Due to the known issues, we recommend skipping 1.3.8 and upgrading directly to 1.3.9. diff --git a/website/content/docs/upgrading/upgrade-to-1.3.9.mdx b/website/content/docs/upgrading/upgrade-to-1.3.9.mdx index 22053da8a45e..d361c93b16c2 100644 --- a/website/content/docs/upgrading/upgrade-to-1.3.9.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.3.9.mdx @@ -11,7 +11,7 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 1.3.9 compared to 1.3.7. Please read it carefully. -## Known Issues +## Known issues @include 'aws-invalid-header.mdx' diff --git a/website/content/docs/upgrading/upgrade-to-1.4.0.mdx b/website/content/docs/upgrading/upgrade-to-1.4.0.mdx index 50088dd246ed..ebaf36f68867 100644 --- a/website/content/docs/upgrading/upgrade-to-1.4.0.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.4.0.mdx @@ -11,7 +11,7 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 1.3.X compared to 1.4.0. Please read it carefully. -## Known Issues +## Known issues @include 'primary-cluster-addr-change.mdx' diff --git a/website/content/docs/upgrading/upgrade-to-1.4.1.mdx b/website/content/docs/upgrading/upgrade-to-1.4.1.mdx index bb862b0d24bb..83373628272d 100644 --- a/website/content/docs/upgrading/upgrade-to-1.4.1.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.4.1.mdx @@ -11,7 +11,7 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 1.4.1 compared to 1.4.0. Please read it carefully. -## AWS Auth Metadata +## AWS auth metadata The metadata handling for AWS Auth logins has changed: @@ -19,7 +19,7 @@ The default set of metadata fields has been changed to `account_id` and `auth_ty application relies on fields that were removed, they may be added back via the AWS Auth identity configuration endpoint (see example below). -## Known Issues +## Known issues The AWS metadata changes have caused an issue preventing renewal of tokens issued via AWS Auth. This has been fixed in Vault 1.4.2. The issue may be addressed in Vault 1.4.1 by configuring the diff --git a/website/content/docs/upgrading/upgrade-to-1.4.4.mdx b/website/content/docs/upgrading/upgrade-to-1.4.4.mdx index 571498b7c31f..d8b4544bc732 100644 --- a/website/content/docs/upgrading/upgrade-to-1.4.4.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.4.4.mdx @@ -11,7 +11,7 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 1.4.4 compared to 1.4.3. Please read it carefully. -## Known Issues +## Known issues Due to the known issues, we recommend skipping 1.4.4 and upgrading directly to 1.4.5. diff --git a/website/content/docs/upgrading/upgrade-to-1.4.5.mdx b/website/content/docs/upgrading/upgrade-to-1.4.5.mdx index d2f890744191..9141c0be12a2 100644 --- a/website/content/docs/upgrading/upgrade-to-1.4.5.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.4.5.mdx @@ -11,7 +11,7 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 1.4.5 compared to 1.4.3. Please read it carefully. -## Known Issues +## Known issues @include 'aws-invalid-header.mdx' diff --git a/website/content/docs/upgrading/upgrade-to-1.5.0.mdx b/website/content/docs/upgrading/upgrade-to-1.5.0.mdx index 676a06cf5687..58d0a2558b74 100644 --- a/website/content/docs/upgrading/upgrade-to-1.5.0.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.5.0.mdx @@ -11,14 +11,14 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 1.5.0 compared to 1.4.1. Please read it carefully. -## Google Cloud Storage `credentials_file` removed +## Google Cloud storage `credentials_file` removed The deprecated `credentials_file` config option has been removed. The `GOOGLE_APPLICATION_CREDENTIALS` environment variable or default credentials may be used instead. See [GCS Authentication](/vault/docs/configuration/storage/google-cloud-storage#gcs-authentication) for details on supported options. -## Raft Configuration +## Raft configuration A new Raft configuration value, `max_entry_size`, has been introduced. This value limits the size in bytes for a Raft K/V entry. It applies to both put operations and diff --git a/website/content/docs/upgrading/upgrade-to-1.5.1.mdx b/website/content/docs/upgrading/upgrade-to-1.5.1.mdx index 44586bbd378e..41d798e5697b 100644 --- a/website/content/docs/upgrading/upgrade-to-1.5.1.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.5.1.mdx @@ -11,7 +11,7 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 1.5.1 compared to 1.5.0. Please read it carefully. -## Known Issues +## Known issues Due to the known issues, we recommend skipping 1.5.1 and upgrading directly to 1.5.2. diff --git a/website/content/docs/upgrading/upgrade-to-1.5.2.mdx b/website/content/docs/upgrading/upgrade-to-1.5.2.mdx index fb07a62b9628..610dad7db91e 100644 --- a/website/content/docs/upgrading/upgrade-to-1.5.2.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.5.2.mdx @@ -11,7 +11,7 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 1.5.2 compared to 1.5.0. Please read it carefully. -## Known Issues +## Known issues @include 'aws-invalid-header.mdx' diff --git a/website/content/docs/upgrading/upgrade-to-1.6.0.mdx b/website/content/docs/upgrading/upgrade-to-1.6.0.mdx index 6660b5089c27..7e61b57b209f 100644 --- a/website/content/docs/upgrading/upgrade-to-1.6.0.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.6.0.mdx @@ -11,7 +11,7 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 1.6.0 compared to 1.5. Please read it carefully. -## Go Version +## Go version Vault 1.6.0 is built with Go 1.15. Please review the [Go Release Notes](https://golang.org/doc/go1.15) for full details. A few items of @@ -23,14 +23,14 @@ particular note: host name. X.509 certificates should be validated and potentially regenerated before upgrading if they do not have Subject Alternative Names. -## Transform Secrets Engine Storage Upgrade +## Transform secrets engine storage upgrade The Transform Secrets Engine (Enterprise only) will automatically upgrade the storage of its configuration in order to accommodate the new transformation type oriented configuration API. Secondaries will receive the modifications via replication. -## Database Engine Interface Upgrade +## Database engine interface upgrade The Database Engine has changed the underlying interface between Vault and each database implementation. This change allows use of [password policies](/vault/docs/concepts/password-policies) @@ -44,7 +44,7 @@ more information on upgrading custom database plugins. @include 'alpine-314.mdx' -## Known Issues +## Known issues Due to the known issue, Transform Secrets Engine users are recommended to upgrade to version 1.6.4. Due to the known issue, Lease Count Quota users with DR Secondaries are recommended to upgrade to version 1.6.6. diff --git a/website/content/docs/upgrading/upgrade-to-1.6.1.mdx b/website/content/docs/upgrading/upgrade-to-1.6.1.mdx index 8227a8ec2e5a..8328952a216d 100644 --- a/website/content/docs/upgrading/upgrade-to-1.6.1.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.6.1.mdx @@ -11,7 +11,7 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 1.6.1 compared to 1.6.0. Please read it carefully. -## Known Issues +## Known issues Due to the known issue, Transform Secrets Engine users are recommended to upgrade to version 1.6.4. diff --git a/website/content/docs/upgrading/upgrade-to-1.6.2.mdx b/website/content/docs/upgrading/upgrade-to-1.6.2.mdx index 207458fd8f55..86db33363178 100644 --- a/website/content/docs/upgrading/upgrade-to-1.6.2.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.6.2.mdx @@ -11,7 +11,7 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 1.6.2 compared to 1.6.1. Please read it carefully. -## Known Issues +## Known issues Due to the known issue, Transform Secrets Engine users are recommended to upgrade to version 1.6.4. diff --git a/website/content/docs/upgrading/upgrade-to-1.6.3.mdx b/website/content/docs/upgrading/upgrade-to-1.6.3.mdx index bbd1a6c5785e..671bf52a9abe 100644 --- a/website/content/docs/upgrading/upgrade-to-1.6.3.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.6.3.mdx @@ -11,7 +11,7 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 1.6.3 compared to 1.6.2. Please read it carefully. -## Known Issues +## Known issues Due to the known issue, Transform Secrets Engine users are recommended to upgrade to version 1.6.4. diff --git a/website/content/docs/upgrading/upgrade-to-1.7.x.mdx b/website/content/docs/upgrading/upgrade-to-1.7.x.mdx index 90300d4719d5..a5e9407c28f9 100644 --- a/website/content/docs/upgrading/upgrade-to-1.7.x.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.7.x.mdx @@ -11,13 +11,13 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 1.7.x compared to 1.6. Please read it carefully. -## Go Version +## Go version Vault 1.7.8 and higher are built with Go 1.16. Please review the [Go Release Notes](https://golang.org/doc/go1.16) for full details. Vault 1.7.0-1.7.7 are built with Go 1.15. -## Barrier Key Auto-Rotation +## Barrier key Auto-Rotation If your Vault installation is at least a year old, the barrier key will be automatically rotated once, and then subsequently will be rotated per the @@ -26,7 +26,7 @@ ensure the number of encryptions performed by the barrier key is fewer than that recommended by [NIST SP 800-38D](https://csrc.nist.gov/publications/detail/sp/800-38d/final). -## AWS Auth Endpoint Changes and Deprecations +## AWS auth endpoint changes and deprecations AWS Auth concepts and endpoints that use the "whitelist" and "blacklist" terms have been updated to more inclusive language (e.g. `/auth/aws/identity-whitelist` has been @@ -39,7 +39,7 @@ endpoint changes is available in the [AWS Auth API docs](/vault/api-docs/auth/aw @include 'entity-alias-mapping.mdx' -## Known Issues +## Known issues Due to the known issue, Transform Secrets Engine users are recommended to upgrade to version 1.7.0. Due to the known issue, Lease Count Quota users with DR Secondaries are recommended to upgrade to version 1.7.4. diff --git a/website/content/docs/upgrading/upgrade-to-1.8.x.mdx b/website/content/docs/upgrading/upgrade-to-1.8.x.mdx index fad33d7ccd9e..70a8f0247a3f 100644 --- a/website/content/docs/upgrading/upgrade-to-1.8.x.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.8.x.mdx @@ -11,7 +11,7 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 1.8.x compared to 1.7. Please read it carefully. -## License Enhancements +## License enhancements Licenses and EULA enhancements have been introduced in the Vault 1.8 release. These changes are important for Enterprise customers to review. They do not affect @@ -30,7 +30,7 @@ The following API endpoints have been deprecated and will be removed in a future -> **Note:** Policies containing globs should be avoided when giving users read access to `/gcp/roleset` to avoid giving users permissions to generate tokens. -## Go Version +## Go version Vault 1.8.0 is built with Go 1.16. Please review the [Go Release Notes](https://golang.org/doc/go1.16) for full details. Of particular note: @@ -44,7 +44,7 @@ Notes](https://golang.org/doc/go1.16) for full details. Of particular note: @include 'pki-forwarding-bug.mdx' -## Known Issues +## Known issues @include 'raft-panic-old-tls-key.mdx' @@ -53,7 +53,7 @@ Notes](https://golang.org/doc/go1.16) for full details. Of particular note: MSSQL integrations (storage and secrets engine) will crash with a "panic: not implemented" error ([#12830](https://github.com/hashicorp/vault/issues/12830)). This affects Vault versions 1.8.0 and up. It will be fixed in the next minor update. -### Vault Enterprise binaries +### Vault enterprise binaries Vault Enterprise binaries for `arm64` architectures will crash immediately when using production-ready storage backends. This issue is addressed in Vault 1.8.1. diff --git a/website/content/docs/upgrading/upgrade-to-1.9.x.mdx b/website/content/docs/upgrading/upgrade-to-1.9.x.mdx index f186a6ad2bb0..9d3a1f8d2d0b 100644 --- a/website/content/docs/upgrading/upgrade-to-1.9.x.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.9.x.mdx @@ -11,7 +11,7 @@ description: |- This page contains the list of deprecations and important or breaking changes for Vault 1.9.x compared to 1.8. Please read it carefully. -## OIDC Provider +## OIDC provider Vault 1.9.0 introduced the ability for Vault to be an OpenID Connect (OIDC) identity provider. To support the feature, Vault's [default policy](/vault/docs/concepts/policies#default-policy) @@ -25,13 +25,13 @@ ACL rule must be added to the default policy **or** a policy associated with the the OIDC flow. ```hcl -# Allow a token to make requests to the Authorization Endpoint for OIDC providers. +# Allow a token to make requests to the authorization endpoint for OIDC providers. path "identity/oidc/provider/+/authorize" { capabilities = ["read", "update"] } ``` -## Identity Tokens +## Identity tokens The Identity secrets engine has changed the procedure for creating Identity token roles. When creating a role, the key parameter is required and the key @@ -42,7 +42,7 @@ All calls to [create or update a role](/vault/api-docs/secret/identity/tokens#cr must be checked to ensure that roles are not being created or updated with non-existent keys. -## SSH Role Parameter `allowed_extensions` Behavior Change +## SSH role parameter `allowed_extensions` behavior change Prior versions of Vault allowed clients to specify any extension when requesting SSH certificate [signing requests](/vault/api-docs/secret/ssh#sign-ssh-key) @@ -60,7 +60,7 @@ specified by clients. ## Deprecations -### HTTP Request Counter Deprecation +### HTTP request counter deprecation In Vault 1.9, the internal HTTP Request count [API](/vault/api-docs/v1.8.x/system/internal-counters#http-requests) @@ -85,7 +85,7 @@ an Etcd v3 cluster prior to upgrading to Vault 1.10. All storage migrations should have [backups](/vault/docs/concepts/storage#backing-up-vault-s-persisted-data) taken prior to migration. -## TLS Cipher Suites Changes +## TLS cipher suites changes In Vault 1.9, due to changes in Go 1.17, the `tls_prefer_server_cipher_suites` TCP configuration parameter has been deprecated and its value will be ignored. @@ -98,11 +98,11 @@ See [this blog post](https://go.dev/blog/tls-cipher-suites) for more information @include 'pki-forwarding-bug.mdx' -## Known Issues +## Known issues @include 'raft-panic-old-tls-key.mdx' -### Identity Token Backend Key Rotations +### Identity token backend key rotations Existing Vault installations that use the [Identity Token backend](/vault/api-docs/secret/identity/tokens) and have [named @@ -116,7 +116,7 @@ corrupted on storage and become unusable. In this case, the key will need to be deleted and re-created. A fix to fully mitigate this panic will be addressed on Vault 1.9.3. -### Activity Log Non-Entity Tokens +### Activity log Non-Entity tokens When upgrading Vault from 1.8 (or earlier) to 1.9 (or later), client counts of [non-entity tokens](/vault/docs/concepts/client-count#non-entity-tokens) will only include the tokens used after the upgrade. diff --git a/website/content/docs/upgrading/vault-ha-upgrade.mdx b/website/content/docs/upgrading/vault-ha-upgrade.mdx index 01c3e74d6309..91828fca8eed 100644 --- a/website/content/docs/upgrading/vault-ha-upgrade.mdx +++ b/website/content/docs/upgrading/vault-ha-upgrade.mdx @@ -5,7 +5,7 @@ description: |- Upgrade instructions for Vault HA Pre 1.11 or Vault without autopilot upgrade automation being enabled. Be sure to read the Upgrading-Vault Guides as well. --- -# Vault HA upgrades without Autopilot Upgrade Automation (Pre 1.11) +# Vault HA upgrades without autopilot upgrade automation (Pre 1.11) This is our recommended upgrade procedure if **one** of the following applies: @@ -26,7 +26,7 @@ Enterprise](/vault/tutorials/raft/raft-upgrade-automation) tutorial for additional guidance. -## HA Installations +## HA installations Regardless of the method you use, do not fail over from a newer version of Vault to an older version. Our suggested procedure is designed to prevent this. @@ -95,6 +95,6 @@ takes over active duty. Be sure to also read and follow any instructions in the version-specific upgrade notes. -## Enterprise Replication Installations +## Enterprise replication installations See the main [upgrading](/vault/docs/upgrading#enterprise-replication-installations) page. diff --git a/website/content/docs/use-cases.mdx b/website/content/docs/use-cases.mdx index 860a1410fc9d..d73693a03bb3 100644 --- a/website/content/docs/use-cases.mdx +++ b/website/content/docs/use-cases.mdx @@ -6,24 +6,24 @@ description: >- are much broader than what we cover. --- -# Use Cases +# Use cases [HashiCorp Vault](/vault/docs/what-is-vault) is an identity-based secrets and encryption management system. Vault validates and authorizes clients (users, machines, apps) before providing them access to secrets or stored sensitive data. This page describes common Vault use cases and provides related resources that can be used to create Vault configurations and workflows. Please note that not all use cases may be listed. -## General Secret Storage +## General secret storage As workloads become more and more ephemeral and short-lived, having long-lived static credentials pose a big security threat vector. What if credentials are accidentally leaked, or an employee leaves with their post it notes that contain the AWS access key, or someone checks their S3 access token to a public GH repo? With Vault, you can generate short-lived, just-in-time credentials that are automatically revoked when their time expires. This means users and security teams do not have to worry about manually revoking or changing these credentials. -### Static Secrets +### Static secrets Credentials can be long-lived and static, where they don't change or are changed infrequently. Vault can store these secrets bedhind its cryptographic barrier, and clients can request them to use in their applications. - Refer to the [Versioned Key/Vault Secrets Engine](/vault/tutorials/secrets-management/versioned-kv) tutorial and learn how a versioned key-value secrets engine protects your static secrets. -### Dynamic Secrets +### Dynamic secrets The key value with secrets storage is the ability to dynamically generate credentials. These credentials are created when clients need them. Vault can also manage the lifecycle of these credentials, including but not limited to, deleting them after a defined period of time. @@ -31,7 +31,7 @@ The key value with secrets storage is the ability to dynamically generate creden In addition to database credential management, Vault can manage your Active Directory accounts, SSH keys, PKI certificates and more. Visit the [Secrets Management](/vault/tutorials/secrets-management) tutorial series to learn more about secrets management using Vault. -## Data Encryption +## Data encryption Many organizations seek solutions to encrypt/decrypt application data within a cloud or multi-datacenter environment; deploying cryptography and maintaining a complex key management infrastructure can be expensive and challenging to develop. Vault provides [encryption as a service](/vault/docs/secrets/transit) with centralized key management to simplify encrypting data in transit and stored across clouds and datacenters. Vault can encrypt/decrypt data stored elsewhere, essentially allowing applications to encrypt their data while storing it in the primary data store. Vault's security team manages and maintains the responsibility of the data encryption within the Vault environment, allowing developers to focus solely on encrypting/decrypting data as needed. @@ -42,7 +42,7 @@ Many organizations seek solutions to encrypt/decrypt application data within a c - For more advanced data protection, refer to the [Advanced Data Protection](/vault/tutorials/adp) tutorial series. Vault's Transform secrets engine handles secure data transformation and tokenization against provided input value. -## Identity-Based Access +## Identity-Based access Organizations need a way to manage identity sprawl with the proliferation of different clouds, services, and systems- all with their identity providers. The risk of compromising an organization's security infrastructure increases as organizations are forced to manage multiple identity management systems as they try to implement solutions to unify a single logical identity across numerous cloud platforms. Different platforms support different methods and constructs for identity, making it difficult to recognize a user or identity across multiple forms of credentials. Vault solves this challenge by using a unified ACL system to broker access to systems and secrets and merges identities across providers. With [identity-based access](/vault/docs/secrets/identity), organizations can leverage any trusted resource identity to regulate and manage system and application access, and authentication across various clouds, systems, and endpoints. @@ -52,7 +52,7 @@ Organizations need a way to manage identity sprawl with the proliferation of dif - Follow the [Policies](/vault/tutorials/policies) tutorial series to learn how Vault enforces role-based access control (RBAC) across multiple cloud environments. -## Key Management +## Key management Working with cloud providers requires that you use their security features, which involve encryption keys issued and stored by the provider in its own key management system (KMS). You may also have a requirement to maintain root of trust and control of the encryption key lifecycle, both within and outside of the cloud. The [Vault Key Management Secrets Engine](/vault/docs/secrets/key-management) provides a consistent workflow for distribution and lifecycle management of cloud provider keys, allowing organizations to maintain centralized control of their keys in Vault while leveraging the cryptographic capabilities native to the KMS providers. diff --git a/website/content/partials/aws-auth-metadata-fix.mdx b/website/content/partials/aws-auth-metadata-fix.mdx index 040277cbe22a..9035bb37e735 100644 --- a/website/content/partials/aws-auth-metadata-fix.mdx +++ b/website/content/partials/aws-auth-metadata-fix.mdx @@ -1,4 +1,4 @@ -## The AWS Auth Engine +## The AWS auth engine Users of the AWS Auth Engine may notice less metadata in their audit logs and associated with the aliases generated by logging in. This is because diff --git a/website/content/partials/aws-auth-metadata-issue.mdx b/website/content/partials/aws-auth-metadata-issue.mdx index eac56d4d450d..b97d9134f070 100644 --- a/website/content/partials/aws-auth-metadata-issue.mdx +++ b/website/content/partials/aws-auth-metadata-issue.mdx @@ -1,4 +1,4 @@ -## The AWS Auth Engine +## The AWS auth engine Users of the AWS Auth Engine should be cautious with this upgrade, because in 1.3.2 we began adding metadata to tokens issued with this method. While the diff --git a/website/content/partials/aws-imds-timeout-upgrade.mdx b/website/content/partials/aws-imds-timeout-upgrade.mdx index 1a119a704bb8..77aac7c06ff9 100644 --- a/website/content/partials/aws-imds-timeout-upgrade.mdx +++ b/website/content/partials/aws-imds-timeout-upgrade.mdx @@ -1,4 +1,4 @@ -## AWS Instance Metadata Timeout +## AWS instance metadata timeout In 1.4.0 Vault started using an updated AWS Go SDK which had support for v2 of the [EC2 instance metadata service][aws-ec2-imdsv2]. However, due to the way the diff --git a/website/content/partials/aws-invalid-header-fix.mdx b/website/content/partials/aws-invalid-header-fix.mdx index 3e59cff76afd..88352c8e1b00 100644 --- a/website/content/partials/aws-invalid-header-fix.mdx +++ b/website/content/partials/aws-invalid-header-fix.mdx @@ -1,4 +1,4 @@ -## AWS IAM Authentication Fixed +## AWS IAM authentication fixed The security updates added in Vault 1.5.1, 1.4.4, 1.3.8, and 1.2.5 included additional header checking during AWS IAM authentication that caused issues for some users. A workaround was diff --git a/website/content/partials/aws-invalid-header.mdx b/website/content/partials/aws-invalid-header.mdx index f9b060f79466..9e2f5aa789d4 100644 --- a/website/content/partials/aws-invalid-header.mdx +++ b/website/content/partials/aws-invalid-header.mdx @@ -1,4 +1,4 @@ -### AWS IAM Authentication +### AWS IAM authentication The security updates added in Vault 1.5.1, 1.4.4, 1.3.8, and 1.2.5 include additional header checking during AWS IAM authentication. The default list of allowed headers doesn't include some that are diff --git a/website/content/partials/aws-sts-issue.mdx b/website/content/partials/aws-sts-issue.mdx index ebe462b974cb..196d9dd5ca15 100644 --- a/website/content/partials/aws-sts-issue.mdx +++ b/website/content/partials/aws-sts-issue.mdx @@ -1,4 +1,4 @@ -## The AWS STS Region Selection +## The AWS STS region selection The AWS Client used in Vault was updated for improved STS performance in 1.3.2 and 1.4.0 [#8161](https://github.com/hashicorp/vault/pull/8161), diff --git a/website/content/partials/builds-without-ui.mdx b/website/content/partials/builds-without-ui.mdx index a5cf8506259c..bdc54123642d 100644 --- a/website/content/partials/builds-without-ui.mdx +++ b/website/content/partials/builds-without-ui.mdx @@ -1,4 +1,4 @@ -### OSS Binaries Lacking Vault UI +### OSS binaries lacking Vault UI OSS binaries of Vault 1.5.1, 1.4.4, 1.3.8, and 1.2.5 were built without the Vault UI. Enterprise binaries are not affected. diff --git a/website/content/partials/consul-dataplane-upgrade-note.mdx b/website/content/partials/consul-dataplane-upgrade-note.mdx index 060e23222f31..5fb5d332b456 100644 --- a/website/content/partials/consul-dataplane-upgrade-note.mdx +++ b/website/content/partials/consul-dataplane-upgrade-note.mdx @@ -1,2 +1,2 @@ -### Consul Dataplane Compatibility +### Consul dataplane compatibility If you are using Consul on Kubernetes, please be aware that upgrading to Consul 1.14.0 will impact Consul [secrets](/vault/docs/secrets/consul), [storage](/vault/docs/configuration/storage/consul), and [service registration](/vault/docs/configuration/service-registration/consul). As of Consul 1.14.0, Consul on Kubernetes uses [Consul Dataplane](/consul/docs/connect/dataplane) by default instead of client agents. Vault does not currently support Consul Dataplane. Please follow the Consul 1.14.0 [upgrade guide](/consul/docs/k8s/upgrade#upgrading-to-consul-dataplane) to ensure that your Consul on Kubernetes deployment continues to use client agents. diff --git a/website/content/partials/enterprise-licenses.mdx b/website/content/partials/enterprise-licenses.mdx index 7a840942c6e2..b4ab6a9b185e 100644 --- a/website/content/partials/enterprise-licenses.mdx +++ b/website/content/partials/enterprise-licenses.mdx @@ -1,4 +1,4 @@ -### Enterprise Licenses +### Enterprise licenses In versions 1.2.6, 1.3.9, 1.4.5, and 1.5.2, the enterprise licenses were not incorporated correctly into the build and we have issued patch releases (x.y.z.1) for enterprise customers containing the diff --git a/website/content/partials/entity-alias-mapping.mdx b/website/content/partials/entity-alias-mapping.mdx index b8b3e4e37a80..650a8fe234ea 100644 --- a/website/content/partials/entity-alias-mapping.mdx +++ b/website/content/partials/entity-alias-mapping.mdx @@ -1,4 +1,4 @@ -## Entity Alias mapping +## Entity alias mapping Previously, an entity in Vault could be mapped to multiple entity aliases on the same authentication backend. This led to a potential security vulnerability (CVE-2021-43998), as ACL policies templated with alias information would match the first diff --git a/website/content/partials/faq/client-count/computing-clients.mdx b/website/content/partials/faq/client-count/computing-clients.mdx index c5b267e95b13..533bba82dfc0 100644 --- a/website/content/partials/faq/client-count/computing-clients.mdx +++ b/website/content/partials/faq/client-count/computing-clients.mdx @@ -1,4 +1,4 @@ -### Can I compute clients for Vault versions before v1.6? ((#before-1-6)) +### Can i compute clients for Vault versions before v1.6? ((#before-1-6)) @include 'alerts/auditor-deprecated.mdx' @@ -9,14 +9,14 @@ to compute and display client count data for Vault v1.3 – v1.5 using the client compute logic available in Vault 1.7. Auditor use with Vault versions older than 1.3 is untested. -### Can I compute KMIP clients for Vault? ((#kmip)) +### Can i compute KMIP clients for Vault? ((#kmip)) **No**. Currently, KMIP clients are not available via the usage metrics UI or client count API. -### Can I get monthly changes for Vault versions older than v1.10? ((#month-to-month)) +### Can i get monthly changes for Vault versions older than v1.10? ((#month-to-month)) **Yes, for Vault v1.8 – v1.10.** diff --git a/website/content/partials/faq/client-count/upgrading.mdx b/website/content/partials/faq/client-count/upgrading.mdx index 7e96480c5af5..1a26d921d603 100644 --- a/website/content/partials/faq/client-count/upgrading.mdx +++ b/website/content/partials/faq/client-count/upgrading.mdx @@ -35,7 +35,7 @@ version of the client count computation logic. | 1.10 | KMIP clients are not provided. | 1.10 | Data on the **Current month** tab does not take the billing period into account. -### What happens to client count when I upgrade? ((#what-happens-at-upgrade)) +### What happens to client count when i upgrade? ((#what-happens-at-upgrade)) **Vault will only reflect the number of active unique clients since the upgrade**. diff --git a/website/content/partials/faq/client-count/usage.mdx b/website/content/partials/faq/client-count/usage.mdx index c0dd80396d79..60201928fdb5 100644 --- a/website/content/partials/faq/client-count/usage.mdx +++ b/website/content/partials/faq/client-count/usage.mdx @@ -68,4 +68,4 @@ for previous months is preserved. You can use the Vault API to [update the client count configuration](/vault/api-docs/system/internal-counters#update-the-client-count-configuration) -and specify your preferred retention period. +and specify your preferred retention period. diff --git a/website/content/partials/kubernetes-supported-versions.mdx b/website/content/partials/kubernetes-supported-versions.mdx index 5b5528839c6d..d1e9e90bca1b 100644 --- a/website/content/partials/kubernetes-supported-versions.mdx +++ b/website/content/partials/kubernetes-supported-versions.mdx @@ -1,4 +1,4 @@ -## Supported Kubernetes Versions +## Supported kubernetes versions The following [Kubernetes minor releases][k8s-releases] are currently supported. The latest version is tested against each Kubernetes version. It may work with diff --git a/website/content/partials/lease-count-quota-upgrade.mdx b/website/content/partials/lease-count-quota-upgrade.mdx index 4e3b10380b51..81a529efec96 100644 --- a/website/content/partials/lease-count-quota-upgrade.mdx +++ b/website/content/partials/lease-count-quota-upgrade.mdx @@ -1,4 +1,4 @@ -### Lease Count Quota Invalidations on DR Secondaries Fixed +### Lease count quota invalidations on DR secondaries fixed Lease count quota invalidation causes DR Secondaries to panic and experience a hard shutdown. This issue exists prior to Vault 1.6.6 and 1.7.4. It is diff --git a/website/content/partials/ocsp-redirect.mdx b/website/content/partials/ocsp-redirect.mdx index e63337cada76..a41c3562edf9 100644 --- a/website/content/partials/ocsp-redirect.mdx +++ b/website/content/partials/ocsp-redirect.mdx @@ -6,6 +6,6 @@ request will not decode as it will not be a properly base64 encoded request. As a workaround, OCSP POST requests can be used which are unaffected. -#### Impacted Versions +#### Impacted versions Affects all current versions of 1.12.x and 1.13.x diff --git a/website/content/partials/perf-standby-token-create-forwarding-failure.mdx b/website/content/partials/perf-standby-token-create-forwarding-failure.mdx index 06846b779b0d..b36f861f33dd 100644 --- a/website/content/partials/perf-standby-token-create-forwarding-failure.mdx +++ b/website/content/partials/perf-standby-token-create-forwarding-failure.mdx @@ -14,6 +14,6 @@ This only happened when all of the following conditions were met: Retrying token creation after the affected token is rejected would work since the entity alias has already been created. -#### Affected Versions +#### Affected versions Affects Vault 1.13.0 to 1.13.3. Fixed in 1.13.4. diff --git a/website/content/partials/pgx-params.mdx b/website/content/partials/pgx-params.mdx index b0a6c8af7dcf..544820a52da3 100644 --- a/website/content/partials/pgx-params.mdx +++ b/website/content/partials/pgx-params.mdx @@ -1,4 +1,4 @@ -### Postgres Library Change +### Postgres library change Vault 1.11+ uses pgx instead of lib/pq for Postgres connections. If you are using parameters like `fallback_application_name` that pgx does not support, you diff --git a/website/content/partials/pki-forwarding-bug.mdx b/website/content/partials/pki-forwarding-bug.mdx index e759d7b324b6..c48a6d8e926b 100644 --- a/website/content/partials/pki-forwarding-bug.mdx +++ b/website/content/partials/pki-forwarding-bug.mdx @@ -1,4 +1,4 @@ -## PKI Certificate Generation Forwarding Regression +## PKI certificate generation forwarding regression A bug introduced in Vault 1.8 causes certificate generation requests to the PKI secrets engine made on a performance secondary node to be forwarded to the cluster's primary node. The resulting certificates are stored on the primary node, diff --git a/website/content/partials/primary-cluster-addr-change.mdx b/website/content/partials/primary-cluster-addr-change.mdx index 4b925b7e22e4..ef9c34e80bcf 100644 --- a/website/content/partials/primary-cluster-addr-change.mdx +++ b/website/content/partials/primary-cluster-addr-change.mdx @@ -1,4 +1,4 @@ -### Primary Cluster Address Change +### Primary cluster address change In Vault 1.4.0-1.4.3, a secondary cluster with a single `primary_cluster_addr` configured will obtain the address of the active node in the primary cluster diff --git a/website/content/partials/raft-large-snapshots.mdx b/website/content/partials/raft-large-snapshots.mdx index d06cf7ea0f36..ccacecf5d63e 100644 --- a/website/content/partials/raft-large-snapshots.mdx +++ b/website/content/partials/raft-large-snapshots.mdx @@ -1,4 +1,4 @@ -### Large Raft Snapshots +### Large raft snapshots Taking and restoring Raft snapshots can exceed Vault's default and recommended timeout settings. The diff --git a/website/content/partials/raft-panic-old-tls-key.mdx b/website/content/partials/raft-panic-old-tls-key.mdx index bda41d22bbd3..43f8160978fd 100644 --- a/website/content/partials/raft-panic-old-tls-key.mdx +++ b/website/content/partials/raft-panic-old-tls-key.mdx @@ -1,4 +1,4 @@ -### Integrated Storage panic related to old TLS key +### Integrated storage panic related to old TLS key Raft in Vault uses its own set of TLS certificates, independent of those that the user controls to protect the API port and those used for replication and clustering. These diff --git a/website/content/partials/raft-retry-join-failure.mdx b/website/content/partials/raft-retry-join-failure.mdx index 47b66912c6b9..cb87e79c6360 100644 --- a/website/content/partials/raft-retry-join-failure.mdx +++ b/website/content/partials/raft-retry-join-failure.mdx @@ -13,7 +13,7 @@ The bug was introduced by commit https://github.com/hashicorp/vault/commit/cc6409222ce246ed72d067debe6ffeb8f62f9dad and first reported in https://github.com/hashicorp/vault/issues/16486. -#### Impacted Versions +#### Impacted versions Affects versions 1.11.1, 1.11.2, 1.10.5, and 1.10.6. Versions prior to these are unaffected. diff --git a/website/content/partials/tokenization-rotation-persistence.mdx b/website/content/partials/tokenization-rotation-persistence.mdx index 25fca2906c56..7cd971a2ee19 100644 --- a/website/content/partials/tokenization-rotation-persistence.mdx +++ b/website/content/partials/tokenization-rotation-persistence.mdx @@ -1,4 +1,4 @@ -### Rotation configuration persistence issue could lose Transform Tokenization key versions +### Rotation configuration persistence issue could lose transform tokenization key versions A rotation performed manually or via automatic time based rotation after restarting or leader change of Vault, where configuration of rotation was @@ -8,7 +8,7 @@ these versions would not be decodeable. It is recommended that customers who have enabled automatic rotation disable it, and other customers avoid key rotation until the upcoming fix. -#### Affected Versions +#### Affected versions This issue affects Vault Enterprise with ADP versions 1.10.x and higher. A fix will be released in Vault 1.11.9, 1.12.5, and 1.13.1. diff --git a/website/content/partials/transform-upgrade.mdx b/website/content/partials/transform-upgrade.mdx index 179eb2cb8a37..fc08e551b28d 100644 --- a/website/content/partials/transform-upgrade.mdx +++ b/website/content/partials/transform-upgrade.mdx @@ -1,4 +1,4 @@ -### Transform Storage Upgrades Fixed +### Transform storage upgrades fixed The Transform Secrets Engine storage upgrade introduced in 1.6.0 introduced malformed configuration for transformations configured earlier than 1.6.0, diff --git a/website/content/partials/update-primary-known-issue.mdx b/website/content/partials/update-primary-known-issue.mdx index e711f06ad837..f1514d808ef6 100644 --- a/website/content/partials/update-primary-known-issue.mdx +++ b/website/content/partials/update-primary-known-issue.mdx @@ -1,64 +1,64 @@ -### API calls to update-primary may lead to data loss ((#update-primary-data-loss)) - -#### Affected versions - -- All current versions of Vault - - - -Look for **Fix a race condition with update-primary that could result in data -loss after a DR failover.** in a future changelog for the resolution. - - - -#### Issue - -The [update-primary](/vault/api-docs/system/replication/replication-performance#update-performance-secondary-s-primary) -endpoint temporarily removes all mount entries except for those that are managed -automatically by vault (e.g. identity mounts). In certain situations, a race -condition between mount table truncation replication repairs may lead to data -loss when updating secondary replication clusters. - -Situations where the race condition may occur: - -- **When the cluster has local data (e.g., PKI certificates, app role secret IDs) - in shared mounts**. - Calling `update-primary` on a performance secondary with local data in shared - mounts may corrupt the merkle tree on the secondary. The secondary still - contains all the previously stored data, but the corruption means that - downstream secondaries will not receive the shared data and will interpret the - update as a request to delete the information. If the downstream secondary is - promoted before the merkle tree is repaired, the newly promoted secondary will - not contain the expected local data. The missing data may be unrecoverable if - the original secondary is is lost or destroyed. -- **When the cluster has an `Allow` paths defined.** - As of Vault 1.0.3.1, startup, unseal, and calling `update-primary` all trigger a - background job that looks at the current mount data and removes invalid entries - based on path filters. When a secondary has `Allow` path filters, the cleanup - code may misfire in the windown of time after update-primary truncats the mount - tables but before the mount tables are rewritten by replication. The cleanup - code deletes data associated with the missing mount entries but does not modify - the merkle tree. Because the merkle tree remains unchanged, replication will not - know that the data is missing and needs to be repaired. - -#### Workaround 1: PR secondary with local data in shared mounts - -Watch for `cleaning key in merkle tree` in the TRACE log immediately after an -update-primary call on a PR secondary to indicate the merkle tree may be -corrupt. Repair the merkle tree by issuing a -[replication reindex request](/vault/api-docs/system/replication#reindex-replication) -to the PR secondary. - -If TRACE logs are no longer available, we recommend pre-emptively reindexing the -PR secondary as a precaution. - -#### Workaround 2: PR secondary with "Allow" path filters - -Watch for `deleted mistakenly stored mount entry from backend` in the INFO log. -Reindex the performance secondary to update the merkle tree with the missing -data and allow replication to disseminate the changes. **You will not be able to -recover local data on shared mounts (e.g., PKI certificates)**. - -If INFO logs are no longer available, query the shared mount in question to -confirm whether your role and configuration data are present on the primary but +### API calls to update-primary may lead to data loss ((#update-primary-data-loss)) + +#### Affected versions + +- All current versions of Vault + + + +Look for **Fix a race condition with update-primary that could result in data +loss after a DR failover.** in a future changelog for the resolution. + + + +#### Issue + +The [update-primary](/vault/api-docs/system/replication/replication-performance#update-performance-secondary-s-primary) +endpoint temporarily removes all mount entries except for those that are managed +automatically by vault (e.g. identity mounts). In certain situations, a race +condition between mount table truncation replication repairs may lead to data +loss when updating secondary replication clusters. + +Situations where the race condition may occur: + +- **When the cluster has local data (e.g., PKI certificates, app role secret IDs) + in shared mounts**. + Calling `update-primary` on a performance secondary with local data in shared + mounts may corrupt the merkle tree on the secondary. The secondary still + contains all the previously stored data, but the corruption means that + downstream secondaries will not receive the shared data and will interpret the + update as a request to delete the information. If the downstream secondary is + promoted before the merkle tree is repaired, the newly promoted secondary will + not contain the expected local data. The missing data may be unrecoverable if + the original secondary is is lost or destroyed. +- **When the cluster has an `Allow` paths defined.** + As of Vault 1.0.3.1, startup, unseal, and calling `update-primary` all trigger a + background job that looks at the current mount data and removes invalid entries + based on path filters. When a secondary has `Allow` path filters, the cleanup + code may misfire in the windown of time after update-primary truncats the mount + tables but before the mount tables are rewritten by replication. The cleanup + code deletes data associated with the missing mount entries but does not modify + the merkle tree. Because the merkle tree remains unchanged, replication will not + know that the data is missing and needs to be repaired. + +#### Workaround 1: PR secondary with local data in shared mounts + +Watch for `cleaning key in merkle tree` in the TRACE log immediately after an +update-primary call on a PR secondary to indicate the merkle tree may be +corrupt. Repair the merkle tree by issuing a +[replication reindex request](/vault/api-docs/system/replication#reindex-replication) +to the PR secondary. + +If TRACE logs are no longer available, we recommend pre-emptively reindexing the +PR secondary as a precaution. + +#### Workaround 2: PR secondary with "Allow" path filters + +Watch for `deleted mistakenly stored mount entry from backend` in the INFO log. +Reindex the performance secondary to update the merkle tree with the missing +data and allow replication to disseminate the changes. **You will not be able to +recover local data on shared mounts (e.g., PKI certificates)**. + +If INFO logs are no longer available, query the shared mount in question to +confirm whether your role and configuration data are present on the primary but missing from the secondary. \ No newline at end of file