diff --git a/multi/multi__client_side_usage.html b/multi/multi__client_side_usage.html index 13254c88..67aac053 100644 --- a/multi/multi__client_side_usage.html +++ b/multi/multi__client_side_usage.html @@ -13,7 +13,7 @@ the test cases). Example Maven configuration:

<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-vault-config</artifactId> - <version>2.0.1.BUILD-SNAPSHOT</version> + <version>2.1.0.BUILD-SNAPSHOT</version> </dependency> <dependency> <groupId>org.springframework.boot</groupId> diff --git a/multi/multi_vault.config.authentication.html b/multi/multi_vault.config.authentication.html index d562e68d..84357e54 100644 --- a/multi/multi_vault.config.authentication.html +++ b/multi/multi_vault.config.authentication.html @@ -55,7 +55,7 @@ AppRole authentication consists of two hard to guess (secret) tokens: RoleId and Spring Vault will not look up these or create a custom SecretId.

Example 3.6. bootstrap.yml with AppRole authentication properties

spring.cloud.vault:
     authentication: APPROLE
     app-role:
-        role-id: bde2076b-cccb-3cf0-d57e-bca7b1e83a52

The following scenarios are supported along the required configuration details:

Table 3.1. Configuration

Method

RoleId

SecretId

RoleName

Token

Provided RoleId/SecretId

Provided

Provided

  

Provided RoleId without SecretId

Provided

   

Provided RoleId, Pull SecretId

Provided

Provided

Provided

Provided

Pull RoleId, provided SecretId

 

Provided

Provided

Provided

Full Pull Mode

  

Provided

Provided

Wrapped

   

Provided

Wrapped RoleId, provided SecretId

Provided

  

Provided

Provided RoleId, wrapped SecretId

 

Provided

 

Provided


Table 3.2. Pull/Push/Wrapped Matrix

RoleId

SecretId

Supported

Provided

Provided

✅

Provided

Pull

✅

Provided

Wrapped

✅

Provided

Absent

✅

Pull

Provided

✅

Pull

Pull

✅

Pull

Wrapped

❌

Pull

Absent

❌

Wrapped

Provided

✅

Wrapped

Pull

❌

Wrapped

Wrapped

✅

Wrapped

Absent

❌


[Note]Note

You can use still all combinations of push/pull/wrapped modes by providing a configured AppRoleAuthentication bean within the boostrap context. Spring Cloud Vault cannot derive all possible AppRole combinations from the configuration properties.

Example 3.7. bootstrap.yml with all AppRole authentication properties

spring.cloud.vault:
+        role-id: bde2076b-cccb-3cf0-d57e-bca7b1e83a52

The following scenarios are supported along the required configuration details:

Table 3.1. Configuration

Method

RoleId

SecretId

RoleName

Token

Provided RoleId/SecretId

Provided

Provided

  

Provided RoleId without SecretId

Provided

   

Provided RoleId, Pull SecretId

Provided

Provided

Provided

Provided

Pull RoleId, provided SecretId

 

Provided

Provided

Provided

Full Pull Mode

  

Provided

Provided

Wrapped

   

Provided

Wrapped RoleId, provided SecretId

Provided

  

Provided

Provided RoleId, wrapped SecretId

 

Provided

 

Provided


Table 3.2. Pull/Push/Wrapped Matrix

RoleId

SecretId

Supported

Provided

Provided

✅

Provided

Pull

✅

Provided

Wrapped

✅

Provided

Absent

✅

Pull

Provided

✅

Pull

Pull

✅

Pull

Wrapped

❌

Pull

Absent

❌

Wrapped

Provided

✅

Wrapped

Pull

❌

Wrapped

Wrapped

✅

Wrapped

Absent

❌


[Note]Note

You can use still all combinations of push/pull/wrapped modes by providing a configured AppRoleAuthentication bean within the bootstrap context. Spring Cloud Vault cannot derive all possible AppRole combinations from the configuration properties.

[Important]Important

AppRole authentication is limited to simple pull mode using reactive infrastructure. Full pull mode is not yet supported. Using Spring Cloud Vault with the Spring WebFlux stack enables Vault’s reactive auto-configuration which can be disabled by setting spring.cloud.vault.reactive.enabled=false.

Example 3.7. bootstrap.yml with all AppRole authentication properties

spring.cloud.vault:
     authentication: APPROLE
     app-role:
         role-id: bde2076b-cccb-3cf0-d57e-bca7b1e83a52
@@ -69,7 +69,7 @@ does not require first-deploying, or provisioning security-sensitive
 credentials (tokens, username/password, client certificates, etc.).
 Instead, it treats AWS as a Trusted Third Party and uses the
 cryptographically signed dynamic metadata information that uniquely
-represents each EC2 instance.
Example 3.8. bootstrap.yml using AWS-EC2 Authentication
spring.cloud.vault:
+represents each EC2 instance.
Example 3.8. bootstrap.yml using AWS-EC2 Authentication
spring.cloud.vault:
     authentication: AWS_EC2

AWS-EC2 authentication enables nonce by default to follow
 the Trust On First Use (TOFU) principle. Any unintended party that
 gains access to the PKCS#7 identity metadata can authenticate
@@ -80,10 +80,10 @@ party does not have the nonce and can raise an alert in Vault for
 further investigation.
The nonce is kept in memory and is lost during application restart.
 You can configure a static nonce with spring.cloud.vault.aws-ec2.nonce.
AWS-EC2 authentication roles are optional and default to the AMI.
 You can configure the authentication role by setting the
-spring.cloud.vault.aws-ec2.role property.
Example 3.9. bootstrap.yml with configured role
spring.cloud.vault:
+spring.cloud.vault.aws-ec2.role property.
Example 3.9. bootstrap.yml with configured role
spring.cloud.vault:
     authentication: AWS_EC2
     aws-ec2:
-        role: application-server

Example 3.10. bootstrap.yml with all AWS EC2 authentication properties
spring.cloud.vault:
+        role: application-server

Example 3.10. bootstrap.yml with all AWS EC2 authentication properties
spring.cloud.vault:
     authentication: AWS_EC2
     aws-ec2:
         role: application-server
@@ -104,8 +104,8 @@ will use the IAM role assigned to the ECS task of the running container.
 If you are running your application naked on top of an EC2 instance then
 the IAM role used will be the one assigned to the EC2 instance.
When using the AWS-IAM authentication you must create a role in Vault
 and assign it to your IAM role. An empty role defaults to
-the friendly name the current IAM role.
Example 3.11. bootstrap.yml with required AWS-IAM Authentication properties
spring.cloud.vault:
-    authentication: AWS_IAM

Example 3.12. bootstrap.yml with all AWS-IAM Authentication properties
spring.cloud.vault:
+the friendly name the current IAM role.
Example 3.11. bootstrap.yml with required AWS-IAM Authentication properties
spring.cloud.vault:
+    authentication: AWS_IAM

Example 3.12. bootstrap.yml with all AWS-IAM Authentication properties
spring.cloud.vault:
     authentication: AWS_IAM
     aws-iam:
         role: my-dev-role
@@ -113,7 +113,7 @@ the friendly name the current IAM role.
        server-id: some.server.name

  • role sets the name of the role against which the login is being attempted. This should be bound to your IAM role. If one is not supplied then the friendly name of the current IAM user will be used as the vault role.
  • aws-path sets the path of the AWS mount to use
  • server-id sets the value to use for the X-Vault-AWS-IAM-Server-ID header preventing certain types of replay attacks.
AWS-IAM requires the AWS Java SDK dependency (com.amazonaws:aws-java-sdk-core)
 as the authentication implementation uses AWS SDK types for credentials and request signing.
See also: Vault Documentation: Using the aws auth backend
3.6 TLS certificate authentication
The cert auth backend allows authentication using SSL/TLS client
 certificates that are either signed by a CA or self-signed.
To enable cert authentication you need to:
  1. Use SSL, see Chapter 9, Vault Client SSL configuration
  2. Configure a Java Keystore that contains the client
-certificate and the private key
  3. Set the spring.cloud.vault.authentication to CERT
Example 3.13. bootstrap.yml
spring.cloud.vault:
+certificate and the private key
  • Set the spring.cloud.vault.authentication to CERT
    • Example 3.13. bootstrap.yml
    spring.cloud.vault:
     authentication: CERT
     ssl:
         key-store: classpath:keystore.jks
@@ -123,16 +123,16 @@ workflow. Cubbyhole authentication uses tokens as primary login method.
 An ephemeral token is used to obtain a second, login VaultToken from Vault’s
 Cubbyhole secret backend. The login token is usually longer-lived and used to
 interact with Vault. The login token will be retrieved from a wrapped
-response stored at /cubbyhole/response.
    Creating a wrapped token
    [Note]Note
    Response Wrapping for token creation requires Vault 0.6.0 or higher.
    Example 3.14. Creating and storing tokens
    $ vault token-create -wrap-ttl="10m"
+response stored at /cubbyhole/response.
    Creating a wrapped token
    [Note]Note
    Response Wrapping for token creation requires Vault 0.6.0 or higher.
    Example 3.14. Creating and storing tokens
    $ vault token-create -wrap-ttl="10m"
 Key                            Value
 ---                            -----
 wrapping_token:                397ccb93-ff6c-b17b-9389-380b01ca2645
 wrapping_token_ttl:            0h10m0s
 wrapping_token_creation_time:  2016-09-18 20:29:48.652957077 +0200 CEST
-wrapped_accessor:              46b6aebb-187f-932a-26d7-4f3d86a68319

    Example 3.15. bootstrap.yml
    spring.cloud.vault:
+wrapped_accessor:              46b6aebb-187f-932a-26d7-4f3d86a68319

    Example 3.15. bootstrap.yml
    spring.cloud.vault:
     authentication: CUBBYHOLE
     token: 397ccb93-ff6c-b17b-9389-380b01ca2645

    See also:
    3.8 Kubernetes authentication
    Kubernetes authentication mechanism (since Vault 0.8.3) allows to authenticate with Vault using a Kubernetes Service Account Token.
-The authentication is role based and the role is bound to a service account name and a namespace.
    A file containing a JWT token for a pod’s service account is automatically mounted at /var/run/secrets/kubernetes.io/serviceaccount/token.
    Example 3.16. bootstrap.yml with all Kubernetes authentication properties
    spring.cloud.vault:
+The authentication is role based and the role is bound to a service account name and a namespace.
    A file containing a JWT token for a pod’s service account is automatically mounted at /var/run/secrets/kubernetes.io/serviceaccount/token.
    Example 3.16. bootstrap.yml with all Kubernetes authentication properties
    spring.cloud.vault:
     authentication: KUBERNETES
     kubernetes:
         role: my-dev-role
diff --git a/multi/multi_vault.config.backends.database-backends.html b/multi/multi_vault.config.backends.database-backends.html
index 62014206..18b6c9b3 100644
--- a/multi/multi_vault.config.backends.database-backends.html
+++ b/multi/multi_vault.config.backends.database-backends.html
@@ -9,11 +9,11 @@ backend in the configuration and the spring-cloud-vault-co
 dependency.
    Vault ships since 0.7.1 with a dedicated database secret backend that allows
 database integration via plugins. You can use that specific backend by using the
 generic database backend. Make sure to specify the appropriate
-backend path, e.g. spring.cloud.vault.mysql.role.backend=database.
    Example 5.1. pom.xml
    <dependencies>
+backend path, e.g. spring.cloud.vault.mysql.role.backend=database.
    Example 5.1. pom.xml
    <dependencies>
     <dependency>
         <groupId>org.springframework.cloud</groupId>
         <artifactId>spring-cloud-vault-config-databases</artifactId>
-        <version>2.0.1.BUILD-SNAPSHOT</version>
+        <version>2.1.0.BUILD-SNAPSHOT</version>
     </dependency>
 </dependencies>

    [Note]Note
    Enabling multiple JDBC-compliant databases will generate credentials
 and store them by default in the same property keys hence property names for
diff --git a/multi/multi_vault.config.backends.html b/multi/multi_vault.config.backends.html
index 300ce1ea..01aca5fd 100644
--- a/multi/multi_vault.config.backends.html
+++ b/multi/multi_vault.config.backends.html
@@ -42,11 +42,11 @@ No active profiles will skip accessing contexts with a profile name.
    Prope
 config usage
  • backend sets the path of the secret mount to use
  • default-context sets the context name used by all applications
  • application-name overrides the application name for use in the generic backend
  • profile-separator separates the profile name from the context in
 property sources with profiles
    • [Note]Note
    The key-value secret backend can be operated in versioned (v2) and non-versioned (v1) modes. Depending on the mode of operation, a different API is required to access secrets. Make sure to enable generic secret backend usage for non-versioned key-value backends and kv secret backend usage for versioned key-value backends.
    See also: Vault Documentation: Using the KV Secrets Engine - Version 2 (versioned key-value backend)
    4.3 Consul
    Spring Cloud Vault can obtain credentials for HashiCorp Consul.
 The Consul integration requires the spring-cloud-vault-config-consul
-dependency.
    Example 4.1. pom.xml
    <dependencies>
+dependency.
    Example 4.1. pom.xml
    <dependencies>
     <dependency>
         <groupId>org.springframework.cloud</groupId>
         <artifactId>spring-cloud-vault-config-consul</artifactId>
-        <version>2.0.1.BUILD-SNAPSHOT</version>
+        <version>2.1.0.BUILD-SNAPSHOT</version>
     </dependency>
 </dependencies>

    The integration can be enabled by setting
 spring.cloud.vault.consul.enabled=true (default false) and
@@ -59,11 +59,11 @@ the property name by setting spring.cloud.vault.consul.tok
         role: readonly
         backend: consul
         token-property: spring.cloud.consul.token
    • enabled setting this value to true enables the Consul backend config usage
    • role sets the role name of the Consul role definition
    • backend sets the path of the Consul mount to use
    • token-property sets the property name in which the Consul ACL token is stored
    See also: Vault Documentation: Setting up Consul with Vault
    4.4 RabbitMQ
    Spring Cloud Vault can obtain credentials for RabbitMQ.
    The RabbitMQ integration requires the spring-cloud-vault-config-rabbitmq
-dependency.
    Example 4.2. pom.xml
    <dependencies>
+dependency.
    Example 4.2. pom.xml
    <dependencies>
     <dependency>
         <groupId>org.springframework.cloud</groupId>
         <artifactId>spring-cloud-vault-config-rabbitmq</artifactId>
-        <version>2.0.1.BUILD-SNAPSHOT</version>
+        <version>2.1.0.BUILD-SNAPSHOT</version>
     </dependency>
 </dependencies>

    The integration can be enabled by setting
 spring.cloud.vault.rabbitmq.enabled=true (default false)
@@ -78,11 +78,11 @@ by setting spring.cloud.vault.rabbitmq.username-property        backend: rabbitmq
         username-property: spring.rabbitmq.username
         password-property: spring.rabbitmq.password
    • enabled setting this value to true enables the RabbitMQ backend config usage
    • role sets the role name of the RabbitMQ role definition
    • backend sets the path of the RabbitMQ mount to use
    • username-property sets the property name in which the RabbitMQ username is stored
    • password-property sets the property name in which the RabbitMQ password is stored
    See also: Vault Documentation: Setting up RabbitMQ with Vault
    4.5 AWS
    Spring Cloud Vault can obtain credentials for AWS.
    The AWS integration requires the spring-cloud-vault-config-aws
-dependency.
    Example 4.3. pom.xml
    <dependencies>
+dependency.
    Example 4.3. pom.xml
    <dependencies>
     <dependency>
         <groupId>org.springframework.cloud</groupId>
         <artifactId>spring-cloud-vault-config-aws</artifactId>
-        <version>2.0.1.BUILD-SNAPSHOT</version>
+        <version>2.1.0.BUILD-SNAPSHOT</version>
     </dependency>
 </dependencies>

    The integration can be enabled by setting
 spring.cloud.vault.aws=true (default false)
diff --git a/single/spring-cloud-vault.html b/single/spring-cloud-vault.html
index a179f0cb..37238832 100644
--- a/single/spring-cloud-vault.html
+++ b/single/spring-cloud-vault.html
@@ -47,7 +47,7 @@ the test cases). Example Maven configuration:
    <dependency>
         <groupId>org.springframework.cloud</groupId>
         <artifactId>spring-cloud-starter-vault-config</artifactId>
-        <version>2.0.1.BUILD-SNAPSHOT</version>
+        <version>2.1.0.BUILD-SNAPSHOT</version>
     </dependency>
     <dependency>
         <groupId>org.springframework.boot</groupId>
@@ -153,7 +153,7 @@ AppRole authentication consists of two hard to guess (secret) tokens: RoleId and
 Spring Vault will not look up these or create a custom SecretId.
    Example 3.6. bootstrap.yml with AppRole authentication properties
    spring.cloud.vault:
     authentication: APPROLE
     app-role:
-        role-id: bde2076b-cccb-3cf0-d57e-bca7b1e83a52

    The following scenarios are supported along the required configuration details:
    Table 3.1. Configuration
    Method
    RoleId
    SecretId
    RoleName
    Token
    Provided RoleId/SecretId
    Provided
    Provided
    		  
    Provided RoleId without SecretId
    Provided
    		   
    Provided RoleId, Pull SecretId
    Provided
    Provided
    Provided
    Provided
    Pull RoleId, provided SecretId
    		 
    Provided
    Provided
    Provided
    Full Pull Mode
    		  
    Provided
    Provided
    Wrapped
    		   
    Provided
    Wrapped RoleId, provided SecretId
    Provided
    		  
    Provided
    Provided RoleId, wrapped SecretId
    		 
    Provided
    		 
    Provided

    Table 3.2. Pull/Push/Wrapped Matrix
    RoleId
    SecretId
    Supported
    Provided
    Provided
    ✅
    Provided
    Pull
    ✅
    Provided
    Wrapped
    ✅
    Provided
    Absent
    ✅
    Pull
    Provided
    ✅
    Pull
    Pull
    ✅
    Pull
    Wrapped
    ❌
    Pull
    Absent
    ❌
    Wrapped
    Provided
    ✅
    Wrapped
    Pull
    ❌
    Wrapped
    Wrapped
    ✅
    Wrapped
    Absent
    ❌

    [Note]Note
    You can use still all combinations of push/pull/wrapped modes by providing a configured AppRoleAuthentication bean within the boostrap context. Spring Cloud Vault cannot derive all possible AppRole combinations from the configuration properties.
    Example 3.7. bootstrap.yml with all AppRole authentication properties
    spring.cloud.vault:
+        role-id: bde2076b-cccb-3cf0-d57e-bca7b1e83a52

    The following scenarios are supported along the required configuration details:
    Table 3.1. Configuration
    Method
    RoleId
    SecretId
    RoleName
    Token
    Provided RoleId/SecretId
    Provided
    Provided
    		  
    Provided RoleId without SecretId
    Provided
    		   
    Provided RoleId, Pull SecretId
    Provided
    Provided
    Provided
    Provided
    Pull RoleId, provided SecretId
    		 
    Provided
    Provided
    Provided
    Full Pull Mode
    		  
    Provided
    Provided
    Wrapped
    		   
    Provided
    Wrapped RoleId, provided SecretId
    Provided
    		  
    Provided
    Provided RoleId, wrapped SecretId
    		 
    Provided
    		 
    Provided

    Table 3.2. Pull/Push/Wrapped Matrix
    RoleId
    SecretId
    Supported
    Provided
    Provided
    ✅
    Provided
    Pull
    ✅
    Provided
    Wrapped
    ✅
    Provided
    Absent
    ✅
    Pull
    Provided
    ✅
    Pull
    Pull
    ✅
    Pull
    Wrapped
    ❌
    Pull
    Absent
    ❌
    Wrapped
    Provided
    ✅
    Wrapped
    Pull
    ❌
    Wrapped
    Wrapped
    ✅
    Wrapped
    Absent
    ❌

    [Note]Note
    You can use still all combinations of push/pull/wrapped modes by providing a configured AppRoleAuthentication bean within the bootstrap context. Spring Cloud Vault cannot derive all possible AppRole combinations from the configuration properties.
    [Important]Important
    AppRole authentication is limited to simple pull mode using reactive infrastructure. Full pull mode is not yet supported. Using Spring Cloud Vault with the Spring WebFlux stack enables Vault’s reactive auto-configuration which can be disabled by setting spring.cloud.vault.reactive.enabled=false.
    Example 3.7. bootstrap.yml with all AppRole authentication properties
    spring.cloud.vault:
     authentication: APPROLE
     app-role:
         role-id: bde2076b-cccb-3cf0-d57e-bca7b1e83a52
@@ -167,7 +167,7 @@ does not require first-deploying, or provisioning security-sensitive
 credentials (tokens, username/password, client certificates, etc.).
 Instead, it treats AWS as a Trusted Third Party and uses the
 cryptographically signed dynamic metadata information that uniquely
-represents each EC2 instance.
    Example 3.8. bootstrap.yml using AWS-EC2 Authentication
    spring.cloud.vault:
+represents each EC2 instance.
    Example 3.8. bootstrap.yml using AWS-EC2 Authentication
    spring.cloud.vault:
     authentication: AWS_EC2

    AWS-EC2 authentication enables nonce by default to follow
 the Trust On First Use (TOFU) principle. Any unintended party that
 gains access to the PKCS#7 identity metadata can authenticate
@@ -178,10 +178,10 @@ party does not have the nonce and can raise an alert in Vault for
 further investigation.
    The nonce is kept in memory and is lost during application restart.
 You can configure a static nonce with spring.cloud.vault.aws-ec2.nonce.
    AWS-EC2 authentication roles are optional and default to the AMI.
 You can configure the authentication role by setting the
-spring.cloud.vault.aws-ec2.role property.
    Example 3.9. bootstrap.yml with configured role
    spring.cloud.vault:
+spring.cloud.vault.aws-ec2.role property.
    Example 3.9. bootstrap.yml with configured role
    spring.cloud.vault:
     authentication: AWS_EC2
     aws-ec2:
-        role: application-server

    Example 3.10. bootstrap.yml with all AWS EC2 authentication properties
    spring.cloud.vault:
+        role: application-server

    Example 3.10. bootstrap.yml with all AWS EC2 authentication properties
    spring.cloud.vault:
     authentication: AWS_EC2
     aws-ec2:
         role: application-server
@@ -202,8 +202,8 @@ will use the IAM role assigned to the ECS task of the running container.
 If you are running your application naked on top of an EC2 instance then
 the IAM role used will be the one assigned to the EC2 instance.
    When using the AWS-IAM authentication you must create a role in Vault
 and assign it to your IAM role. An empty role defaults to
-the friendly name the current IAM role.
    Example 3.11. bootstrap.yml with required AWS-IAM Authentication properties
    spring.cloud.vault:
-    authentication: AWS_IAM

    Example 3.12. bootstrap.yml with all AWS-IAM Authentication properties
    spring.cloud.vault:
+the friendly name the current IAM role.
    Example 3.11. bootstrap.yml with required AWS-IAM Authentication properties
    spring.cloud.vault:
+    authentication: AWS_IAM

    Example 3.12. bootstrap.yml with all AWS-IAM Authentication properties
    spring.cloud.vault:
     authentication: AWS_IAM
     aws-iam:
         role: my-dev-role
@@ -211,7 +211,7 @@ the friendly name the current IAM role.
            server-id: some.server.name

    • role sets the name of the role against which the login is being attempted. This should be bound to your IAM role. If one is not supplied then the friendly name of the current IAM user will be used as the vault role.
    • aws-path sets the path of the AWS mount to use
    • server-id sets the value to use for the X-Vault-AWS-IAM-Server-ID header preventing certain types of replay attacks.
    AWS-IAM requires the AWS Java SDK dependency (com.amazonaws:aws-java-sdk-core)
 as the authentication implementation uses AWS SDK types for credentials and request signing.
    See also: Vault Documentation: Using the aws auth backend
    3.6 TLS certificate authentication
    The cert auth backend allows authentication using SSL/TLS client
 certificates that are either signed by a CA or self-signed.
    To enable cert authentication you need to:
    1. Use SSL, see Chapter 9, Vault Client SSL configuration
    2. Configure a Java Keystore that contains the client
-certificate and the private key
    3. Set the spring.cloud.vault.authentication to CERT
    Example 3.13. bootstrap.yml
    spring.cloud.vault:
+certificate and the private key
  • Set the spring.cloud.vault.authentication to CERT
    • Example 3.13. bootstrap.yml
    spring.cloud.vault:
     authentication: CERT
     ssl:
         key-store: classpath:keystore.jks
@@ -221,16 +221,16 @@ workflow. Cubbyhole authentication uses tokens as primary login method.
 An ephemeral token is used to obtain a second, login VaultToken from Vault’s
 Cubbyhole secret backend. The login token is usually longer-lived and used to
 interact with Vault. The login token will be retrieved from a wrapped
-response stored at /cubbyhole/response.
    Creating a wrapped token
    [Note]Note
    Response Wrapping for token creation requires Vault 0.6.0 or higher.
    Example 3.14. Creating and storing tokens
    $ vault token-create -wrap-ttl="10m"
+response stored at /cubbyhole/response.
    Creating a wrapped token
    [Note]Note
    Response Wrapping for token creation requires Vault 0.6.0 or higher.
    Example 3.14. Creating and storing tokens
    $ vault token-create -wrap-ttl="10m"
 Key                            Value
 ---                            -----
 wrapping_token:                397ccb93-ff6c-b17b-9389-380b01ca2645
 wrapping_token_ttl:            0h10m0s
 wrapping_token_creation_time:  2016-09-18 20:29:48.652957077 +0200 CEST
-wrapped_accessor:              46b6aebb-187f-932a-26d7-4f3d86a68319

    Example 3.15. bootstrap.yml
    spring.cloud.vault:
+wrapped_accessor:              46b6aebb-187f-932a-26d7-4f3d86a68319

    Example 3.15. bootstrap.yml
    spring.cloud.vault:
     authentication: CUBBYHOLE
     token: 397ccb93-ff6c-b17b-9389-380b01ca2645

    See also:
    3.8 Kubernetes authentication
    Kubernetes authentication mechanism (since Vault 0.8.3) allows to authenticate with Vault using a Kubernetes Service Account Token.
-The authentication is role based and the role is bound to a service account name and a namespace.
    A file containing a JWT token for a pod’s service account is automatically mounted at /var/run/secrets/kubernetes.io/serviceaccount/token.
    Example 3.16. bootstrap.yml with all Kubernetes authentication properties
    spring.cloud.vault:
+The authentication is role based and the role is bound to a service account name and a namespace.
    A file containing a JWT token for a pod’s service account is automatically mounted at /var/run/secrets/kubernetes.io/serviceaccount/token.
    Example 3.16. bootstrap.yml with all Kubernetes authentication properties
    spring.cloud.vault:
     authentication: KUBERNETES
     kubernetes:
         role: my-dev-role
@@ -276,11 +276,11 @@ No active profiles will skip accessing contexts with a profile name.
    Prope
 config usage
  • backend sets the path of the secret mount to use
  • default-context sets the context name used by all applications
  • application-name overrides the application name for use in the generic backend
  • profile-separator separates the profile name from the context in
 property sources with profiles
    • [Note]Note
    The key-value secret backend can be operated in versioned (v2) and non-versioned (v1) modes. Depending on the mode of operation, a different API is required to access secrets. Make sure to enable generic secret backend usage for non-versioned key-value backends and kv secret backend usage for versioned key-value backends.
    See also: Vault Documentation: Using the KV Secrets Engine - Version 2 (versioned key-value backend)
    4.3 Consul
    Spring Cloud Vault can obtain credentials for HashiCorp Consul.
 The Consul integration requires the spring-cloud-vault-config-consul
-dependency.
    Example 4.1. pom.xml
    <dependencies>
+dependency.
    Example 4.1. pom.xml
    <dependencies>
     <dependency>
         <groupId>org.springframework.cloud</groupId>
         <artifactId>spring-cloud-vault-config-consul</artifactId>
-        <version>2.0.1.BUILD-SNAPSHOT</version>
+        <version>2.1.0.BUILD-SNAPSHOT</version>
     </dependency>
 </dependencies>

    The integration can be enabled by setting
 spring.cloud.vault.consul.enabled=true (default false) and
@@ -293,11 +293,11 @@ the property name by setting spring.cloud.vault.consul.tok
         role: readonly
         backend: consul
         token-property: spring.cloud.consul.token
    • enabled setting this value to true enables the Consul backend config usage
    • role sets the role name of the Consul role definition
    • backend sets the path of the Consul mount to use
    • token-property sets the property name in which the Consul ACL token is stored
    See also: Vault Documentation: Setting up Consul with Vault
    4.4 RabbitMQ
    Spring Cloud Vault can obtain credentials for RabbitMQ.
    The RabbitMQ integration requires the spring-cloud-vault-config-rabbitmq
-dependency.
    Example 4.2. pom.xml
    <dependencies>
+dependency.
    Example 4.2. pom.xml
    <dependencies>
     <dependency>
         <groupId>org.springframework.cloud</groupId>
         <artifactId>spring-cloud-vault-config-rabbitmq</artifactId>
-        <version>2.0.1.BUILD-SNAPSHOT</version>
+        <version>2.1.0.BUILD-SNAPSHOT</version>
     </dependency>
 </dependencies>

    The integration can be enabled by setting
 spring.cloud.vault.rabbitmq.enabled=true (default false)
@@ -312,11 +312,11 @@ by setting spring.cloud.vault.rabbitmq.username-property        backend: rabbitmq
         username-property: spring.rabbitmq.username
         password-property: spring.rabbitmq.password
    • enabled setting this value to true enables the RabbitMQ backend config usage
    • role sets the role name of the RabbitMQ role definition
    • backend sets the path of the RabbitMQ mount to use
    • username-property sets the property name in which the RabbitMQ username is stored
    • password-property sets the property name in which the RabbitMQ password is stored
    See also: Vault Documentation: Setting up RabbitMQ with Vault
    4.5 AWS
    Spring Cloud Vault can obtain credentials for AWS.
    The AWS integration requires the spring-cloud-vault-config-aws
-dependency.
    Example 4.3. pom.xml
    <dependencies>
+dependency.
    Example 4.3. pom.xml
    <dependencies>
     <dependency>
         <groupId>org.springframework.cloud</groupId>
         <artifactId>spring-cloud-vault-config-aws</artifactId>
-        <version>2.0.1.BUILD-SNAPSHOT</version>
+        <version>2.1.0.BUILD-SNAPSHOT</version>
     </dependency>
 </dependencies>

    The integration can be enabled by setting
 spring.cloud.vault.aws=true (default false)
@@ -339,11 +339,11 @@ backend in the configuration and the spring-cloud-vault-co
 dependency.
    Vault ships since 0.7.1 with a dedicated database secret backend that allows
 database integration via plugins. You can use that specific backend by using the
 generic database backend. Make sure to specify the appropriate
-backend path, e.g. spring.cloud.vault.mysql.role.backend=database.
    Example 5.1. pom.xml
    <dependencies>
+backend path, e.g. spring.cloud.vault.mysql.role.backend=database.
    Example 5.1. pom.xml
    <dependencies>
     <dependency>
         <groupId>org.springframework.cloud</groupId>
         <artifactId>spring-cloud-vault-config-databases</artifactId>
-        <version>2.0.1.BUILD-SNAPSHOT</version>
+        <version>2.1.0.BUILD-SNAPSHOT</version>
     </dependency>
 </dependencies>

    [Note]Note
    Enabling multiple JDBC-compliant databases will generate credentials
 and store them by default in the same property keys hence property names for
diff --git a/spring-cloud-vault.html b/spring-cloud-vault.html
index 09e5856f..419ea5cf 100644
--- a/spring-cloud-vault.html
+++ b/spring-cloud-vault.html
@@ -90,7 +90,7 @@ $(addBlockSwitches);
 
    
 
    
 
    
-
    2.0.1.BUILD-SNAPSHOT
    
+
    2.1.0.BUILD-SNAPSHOT