From 0adbe03d2aca0876a170afdccd177259e7cead7f Mon Sep 17 00:00:00 2001 From: buildmaster Date: Mon, 23 Jul 2018 06:23:39 +0000 Subject: [PATCH] Sync docs from 2.0.x to gh-pages --- 2.0.x/images/callouts/1.png | Bin 0 -> 329 bytes 2.0.x/images/callouts/2.png | Bin 0 -> 353 bytes 2.0.x/images/callouts/3.png | Bin 0 -> 350 bytes 2.0.x/index.html | 2 +- 2.0.x/multi/images/callouts/1.png | Bin 0 -> 329 bytes 2.0.x/multi/images/callouts/2.png | Bin 0 -> 353 bytes 2.0.x/multi/images/callouts/3.png | Bin 0 -> 350 bytes 2.0.x/multi/multi__client_side_usage.html | 4 +- 2.0.x/multi/multi_pr01.html | 2 +- 2.0.x/multi/multi_spring-cloud-vault.html | 2 +- .../multi_vault.config.authentication.html | 26 +++--- ...ult.config.backends.database-backends.html | 4 +- 2.0.x/multi/multi_vault.config.backends.html | 40 ++++++--- 2.0.x/single/images/callouts/1.png | Bin 0 -> 329 bytes 2.0.x/single/images/callouts/2.png | Bin 0 -> 353 bytes 2.0.x/single/images/callouts/3.png | Bin 0 -> 350 bytes 2.0.x/single/spring-cloud-vault.html | 76 +++++++++++------- 17 files changed, 98 insertions(+), 58 deletions(-) create mode 100644 2.0.x/images/callouts/1.png create mode 100644 2.0.x/images/callouts/2.png create mode 100644 2.0.x/images/callouts/3.png create mode 100644 2.0.x/multi/images/callouts/1.png create mode 100644 2.0.x/multi/images/callouts/2.png create mode 100644 2.0.x/multi/images/callouts/3.png create mode 100644 2.0.x/single/images/callouts/1.png create mode 100644 2.0.x/single/images/callouts/2.png create mode 100644 2.0.x/single/images/callouts/3.png diff --git a/2.0.x/images/callouts/1.png b/2.0.x/images/callouts/1.png new file mode 100644 index 0000000000000000000000000000000000000000..7d473430b7bec514f7de12f5769fe7c5859e8c5d GIT binary patch literal 329 zcmeAS@N?(olHy`uVBq!ia0vp^JRr;gBp8b2n5}^nQC}X^4DKU-G|w_t}fLBA)Suv#nrW z!^h2QnY_`l!BOq-UXEX{m2up>JTQkX)2m zTvF+fTUlI^nXH#utd~++ke^qgmzgTe~DWM4ffP81J literal 0 HcmV?d00001 diff --git a/2.0.x/images/callouts/2.png b/2.0.x/images/callouts/2.png new file mode 100644 index 0000000000000000000000000000000000000000..5d09341b2f6d2ea2d1d5dad5d980f14b4b05dfd2 GIT binary patch literal 353 zcmeAS@N?(olHy`uVBq!ia0vp^JRr;gBp8b2n5}^nQxaY7e*=hH)_rZeB4|imU1$R#1`!P>&$poQl;nzm}mD5ZFopaX|GsS%q*{P~< z;WtmO%lhToBL0i}yfkaOt?EN=nkLNGuU`ywhI5H)L`iUdT1k0gQ7VIjhO(w-Zen_> zZ(@38a<+nro{^q~f~BRtfrY+-p+a&|W^qZSLvCepNoKNMYO!8QX+eHoiC%Jk?!;Y+ zJAlS%fsM;d&r2*R1)67JkeZlkYGj#gX_9E3W@4U_nw*@Ln38B@k(iuhnUeN2eF0kK0(Y1u|9Rc(19XFPiEBhjaDG}zd16s2gM)^$re|(qda7?? zdS-IAf{C7yo`r&?rM`iMzJZ}aa#3b+Nu@(>WpPPnvR-PjUP@^}eqM=Qa(?c_U5Yz^ z#%Y0#%S_KpEGY$=XJL?(l#*ybuErX#^g`ttQfwn
-

2.0.0.BUILD-SNAPSHOT

+

2.0.1.BUILD-SNAPSHOT

diff --git a/2.0.x/multi/images/callouts/1.png b/2.0.x/multi/images/callouts/1.png new file mode 100644 index 0000000000000000000000000000000000000000..7d473430b7bec514f7de12f5769fe7c5859e8c5d GIT binary patch literal 329 zcmeAS@N?(olHy`uVBq!ia0vp^JRr;gBp8b2n5}^nQC}X^4DKU-G|w_t}fLBA)Suv#nrW z!^h2QnY_`l!BOq-UXEX{m2up>JTQkX)2m zTvF+fTUlI^nXH#utd~++ke^qgmzgTe~DWM4ffP81J literal 0 HcmV?d00001 diff --git a/2.0.x/multi/images/callouts/2.png b/2.0.x/multi/images/callouts/2.png new file mode 100644 index 0000000000000000000000000000000000000000..5d09341b2f6d2ea2d1d5dad5d980f14b4b05dfd2 GIT binary patch literal 353 zcmeAS@N?(olHy`uVBq!ia0vp^JRr;gBp8b2n5}^nQxaY7e*=hH)_rZeB4|imU1$R#1`!P>&$poQl;nzm}mD5ZFopaX|GsS%q*{P~< z;WtmO%lhToBL0i}yfkaOt?EN=nkLNGuU`ywhI5H)L`iUdT1k0gQ7VIjhO(w-Zen_> zZ(@38a<+nro{^q~f~BRtfrY+-p+a&|W^qZSLvCepNoKNMYO!8QX+eHoiC%Jk?!;Y+ zJAlS%fsM;d&r2*R1)67JkeZlkYGj#gX_9E3W@4U_nw*@Ln38B@k(iuhnUeN2eF0kK0(Y1u|9Rc(19XFPiEBhjaDG}zd16s2gM)^$re|(qda7?? zdS-IAf{C7yo`r&?rM`iMzJZ}aa#3b+Nu@(>WpPPnvR-PjUP@^}eqM=Qa(?c_U5Yz^ z#%Y0#%S_KpEGY$=XJL?(l#*ybuErX#^g`ttQfwnspring-cloud-vault-config the test cases). Example Maven configuration:

Example 2.1. pom.xml

<parent>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-parent</artifactId>
-    <version>1.5.4.RELEASE</version>
+    <version>2.0.0.RELEASE</version>
     <relativePath /> <!-- lookup parent from repository -->
 </parent>
 
@@ -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.0.BUILD-SNAPSHOT</version>
+        <version>2.0.1.BUILD-SNAPSHOT</version>
     </dependency>
     <dependency>
         <groupId>org.springframework.boot</groupId>
diff --git a/2.0.x/multi/multi_pr01.html b/2.0.x/multi/multi_pr01.html
index 7fad193c..a1d87121 100644
--- a/2.0.x/multi/multi_pr01.html
+++ b/2.0.x/multi/multi_pr01.html
@@ -1,3 +1,3 @@
 
       
-   
Prev   Next
© 2016-2017 The original authors.
[Note]Note
Copies of this document may be made for your own use and for distribution to others, provided that you do not charge any fee for such copies and further provided that each copy contains this Copyright Notice, whether distributed in print or electronically.
Spring Cloud Vault Config provides client-side support for externalized configuration in a distributed system. With HashiCorp’s Vault you have a central place to manage external secret properties for applications across all environments. Vault can manage static and dynamic secrets such as username/password for remote applications/resources and provide credentials for external services such as MySQL, PostgreSQL, Apache Cassandra, MongoDB, Consul, AWS and more.
Prev   Next
Spring Cloud Vault Home 1. Quick Start

\ No newline at end of file
+   
Prev   Next
© 2016-2018 The original authors.
[Note]Note
Copies of this document may be made for your own use and for distribution to others, provided that you do not charge any fee for such copies and further provided that each copy contains this Copyright Notice, whether distributed in print or electronically.
Spring Cloud Vault Config provides client-side support for externalized configuration in a distributed system. With HashiCorp’s Vault you have a central place to manage external secret properties for applications across all environments. Vault can manage static and dynamic secrets such as username/password for remote applications/resources and provide credentials for external services such as MySQL, PostgreSQL, Apache Cassandra, MongoDB, Consul, AWS and more.
Prev   Next
Spring Cloud Vault Home 1. Quick Start

\ No newline at end of file
diff --git a/2.0.x/multi/multi_spring-cloud-vault.html b/2.0.x/multi/multi_spring-cloud-vault.html
index 3b5056a6..504088b4 100644
--- a/2.0.x/multi/multi_spring-cloud-vault.html
+++ b/2.0.x/multi/multi_spring-cloud-vault.html
@@ -1,3 +1,3 @@
 
       
-   Spring Cloud Vault
Spring Cloud Vault
   Next
Spring Cloud Vault
Table of Contents
1. Quick Start
2. Client Side Usage
2.1. Authentication
3. Authentication methods
3.1. Token authentication
3.2. AppId authentication
3.2.1. Custom UserId
3.3. AppRole authentication
3.4. AWS-EC2 authentication
3.5. AWS-IAM authentication
3.6. TLS certificate authentication
3.7. Cubbyhole authentication
3.8. Kubernetes authentication
4. Secret Backends
4.1. Generic Backend
4.2. Consul
4.3. RabbitMQ
4.4. AWS
5. Database backends
5.1. Database
5.2. Apache Cassandra
5.3. MongoDB
5.4. MySQL
5.5. PostgreSQL
6. Configure PropertySourceLocator behavior
7. Service Registry Configuration
8. Vault Client Fail Fast
9. Vault Client SSL configuration
10. Lease lifecycle management (renewal and revocation)
   Next
   

\ No newline at end of file
+   Spring Cloud Vault
Spring Cloud Vault
   Next
Spring Cloud Vault
Table of Contents
1. Quick Start
2. Client Side Usage
2.1. Authentication
3. Authentication methods
3.1. Token authentication
3.2. AppId authentication
3.2.1. Custom UserId
3.3. AppRole authentication
3.4. AWS-EC2 authentication
3.5. AWS-IAM authentication
3.6. TLS certificate authentication
3.7. Cubbyhole authentication
3.8. Kubernetes authentication
4. Secret Backends
4.1. Generic Backend
4.2. Versioned Key-Value Backend
4.3. Consul
4.4. RabbitMQ
4.5. AWS
5. Database backends
5.1. Database
5.2. Apache Cassandra
5.3. MongoDB
5.4. MySQL
5.5. PostgreSQL
6. Configure PropertySourceLocator behavior
7. Service Registry Configuration
8. Vault Client Fail Fast
9. Vault Client SSL configuration
10. Lease lifecycle management (renewal and revocation)
   Next
   

\ No newline at end of file
diff --git a/2.0.x/multi/multi_vault.config.authentication.html b/2.0.x/multi/multi_vault.config.authentication.html
index a03c3a60..84357e54 100644
--- a/2.0.x/multi/multi_vault.config.authentication.html
+++ b/2.0.x/multi/multi_vault.config.authentication.html
@@ -51,17 +51,17 @@ obtain a token.
}
 }

See also: Vault Documentation: Using the App ID auth backend

3.3 AppRole authentication

AppRole is intended for machine authentication, like the deprecated (since Vault 0.6.1) Section 3.2, “AppId authentication”. -AppRole authentication consists of two hard to guess (secret) tokens: RoleId and SecretId.

Spring Vault supports AppRole authentication by providing either RoleId only -or together with a provided SecretId (push or pull mode).

RoleId and optionally SecretId must be provided by configuration, +AppRole authentication consists of two hard to guess (secret) tokens: RoleId and SecretId.

Spring Vault supports various AppRole scenarios (push/pull mode and wrapped).

RoleId and optionally SecretId must be provided by configuration, 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

  • role-id sets the RoleId.

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
         secret-id: 1696536f-1976-73b1-b241-0b4213908d39
-        app-auth-path: approle

  • role-id sets the RoleId.
  • secret-id sets the SecretId. SecretId can be omitted if AppRole is configured without requiring SecretId (See bind_secret_id)
  • approle-path sets the path of the approle authentication mount to use

See also: Vault Documentation: Using the AppRole auth backend

3.4 AWS-EC2 authentication

The aws-ec2 + role: my-role + app-role-path: approle


  • role-id sets the RoleId.
  • secret-id sets the SecretId. SecretId can be omitted if AppRole is configured without requiring SecretId (See bind_secret_id).
  • role: sets the AppRole name for pull mode.
  • app-role-path sets the path of the approle authentication mount to use.

See also: Vault Documentation: Using the AppRole auth backend

3.4 AWS-EC2 authentication

The aws-ec2 auth backend provides a secure introduction mechanism for AWS EC2 instances, allowing automated retrieval of a Vault token. Unlike most Vault authentication backends, this backend @@ -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/2.0.x/multi/multi_vault.config.backends.database-backends.html b/2.0.x/multi/multi_vault.config.backends.database-backends.html
index 4056a981..04db0553 100644
--- a/2.0.x/multi/multi_vault.config.backends.database-backends.html
+++ b/2.0.x/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.0.BUILD-SNAPSHOT</version>
+        <version>2.0.1.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/2.0.x/multi/multi_vault.config.backends.html b/2.0.x/multi/multi_vault.config.backends.html
index 3b67bf73..a3e1117a 100644
--- a/2.0.x/multi/multi_vault.config.backends.html
+++ b/2.0.x/multi/multi_vault.config.backends.html
@@ -9,7 +9,7 @@ and a default context name (application) in combina
 profiles.
    /secret/{application}/{profile}
 /secret/{application}
 /secret/{default-context}/{profile}
-/secret/{default-context}
    The application name is determined by the properties:
    • spring.cloud.vault.generic.application-name
    • spring.cloud.vault.application-name
    • spring.application.name
    Secrets can be obtained from other folders within the generic backend by adding their
+/secret/{default-context}
    The application name is determined by the properties:
    • spring.cloud.vault.generic.application-name
    • spring.cloud.vault.application-name
    • spring.application.name
    Secrets can be obtained from other contexts within the generic backend by adding their
 paths to the application name, separated by commas. For example, given the application
 name usefulapp,mysql1,projectx/aws, each of these folders will be used:
    • /secret/usefulapp
    • /secret/mysql1
    • /secret/projectx/aws
    Spring Cloud Vault adds all active profiles to the list of possible context paths.
 No active profiles will skip accessing contexts with a profile name.
    Properties are exposed like they are stored (i.e. without additional prefixes).
    spring.cloud.vault:
@@ -20,13 +20,33 @@ No active profiles will skip accessing contexts with a profile name.
    Prope
         default-context: application
         application-name: my-app
    • enabled setting this value to false disables the secret backend
 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
    See also: Vault Documentation: Using the generic secret backend
    4.2 Consul
    Spring Cloud Vault can obtain credentials for HashiCorp Consul.
+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 1 (generic secret backend)
    4.2 Versioned Key-Value Backend
    Spring Cloud Vault supports the versioned Key-Value secret
+backend. The key-value backend allows storage of arbitrary
+values as key-value store. A single context can store one or many
+key-value tuples. Contexts can be organized hierarchically.
+Spring Cloud Vault allows using the Application name
+and a default context name (application) in combination with active
+profiles.
    /secret/{application}/{profile}
+/secret/{application}
+/secret/{default-context}/{profile}
+/secret/{default-context}
    The application name is determined by the properties:
    • spring.cloud.vault.kv.application-name
    • spring.cloud.vault.application-name
    • spring.application.name
    Secrets can be obtained from other contexts within the key-value backend by adding their
+paths to the application name, separated by commas. For example, given the application
+name usefulapp,mysql1,projectx/aws, each of these folders will be used:
    • /secret/usefulapp
    • /secret/mysql1
    • /secret/projectx/aws
    Spring Cloud Vault adds all active profiles to the list of possible context paths.
+No active profiles will skip accessing contexts with a profile name.
    Properties are exposed like they are stored (i.e. without additional prefixes).
    [Note]Note
    Spring Cloud Vault adds the data/ context between the mount path and the actual context path.
    spring.cloud.vault:
+    kv:
+        enabled: true
+        backend: secret
+        profile-separator: '/'
+        default-context: application
+        application-name: my-app
    • enabled setting this value to false disables the secret backend
+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.0.BUILD-SNAPSHOT</version>
+        <version>2.0.1.BUILD-SNAPSHOT</version>
     </dependency>
 </dependencies>

    The integration can be enabled by setting
 spring.cloud.vault.consul.enabled=true (default false) and
@@ -38,12 +58,12 @@ the property name by setting spring.cloud.vault.consul.tok
         enabled: true
         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.3 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>
+        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>
         <groupId>org.springframework.cloud</groupId>
         <artifactId>spring-cloud-vault-config-rabbitmq</artifactId>
-        <version>2.0.0.BUILD-SNAPSHOT</version>
+        <version>2.0.1.BUILD-SNAPSHOT</version>
     </dependency>
 </dependencies>

    The integration can be enabled by setting
 spring.cloud.vault.rabbitmq.enabled=true (default false)
@@ -57,12 +77,12 @@ by setting spring.cloud.vault.rabbitmq.username-property        role: readonly
         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.4 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>
+        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>
         <groupId>org.springframework.cloud</groupId>
         <artifactId>spring-cloud-vault-config-aws</artifactId>
-        <version>2.0.0.BUILD-SNAPSHOT</version>
+        <version>2.0.1.BUILD-SNAPSHOT</version>
     </dependency>
 </dependencies>

    The integration can be enabled by setting
 spring.cloud.vault.aws=true (default false)
diff --git a/2.0.x/single/images/callouts/1.png b/2.0.x/single/images/callouts/1.png
new file mode 100644
index 0000000000000000000000000000000000000000..7d473430b7bec514f7de12f5769fe7c5859e8c5d
GIT binary patch
literal 329
zcmeAS@N?(olHy`uVBq!ia0vp^JRr;gBp8b2n5}^nQC}X^4DKU-G|w_t}fLBA)Suv#nrW
z!^h2QnY_`l!BOq-UXEX{m2up>JTQkX)2m
zTvF+fTUlI^nXH#utd~++ke^qgmzgTe~DWM4ffP81J

literal 0
HcmV?d00001

diff --git a/2.0.x/single/images/callouts/2.png b/2.0.x/single/images/callouts/2.png
new file mode 100644
index 0000000000000000000000000000000000000000..5d09341b2f6d2ea2d1d5dad5d980f14b4b05dfd2
GIT binary patch
literal 353
zcmeAS@N?(olHy`uVBq!ia0vp^JRr;gBp8b2n5}^nQxaY7e*=hH)_rZeB4|imU1$R#1`!P>&$poQl;nzm}mD5ZFopaX|GsS%q*{P~<
z;WtmO%lhToBL0i}yfkaOt?EN=nkLNGuU`ywhI5H)L`iUdT1k0gQ7VIjhO(w-Zen_>
zZ(@38a<+nro{^q~f~BRtfrY+-p+a&|W^qZSLvCepNoKNMYO!8QX+eHoiC%Jk?!;Y+
zJAlS%fsM;d&r2*R1)67JkeZlkYGj#gX_9E3W@4U_nw*@Ln38B@k(iuhnUeN2eF0kK0(Y1u|9Rc(19XFPiEBhjaDG}zd16s2gM)^$re|(qda7??
zdS-IAf{C7yo`r&?rM`iMzJZ}aa#3b+Nu@(>WpPPnvR-PjUP@^}eqM=Qa(?c_U5Yz^
z#%Y0#%S_KpEGY$=XJL?(l#*ybuErX#^g`ttQfwn
       
-   Spring Cloud Vault
    Spring Cloud Vault
    Table of Contents
    1. Quick Start
    2. Client Side Usage
    2.1. Authentication
    3. Authentication methods
    3.1. Token authentication
    3.2. AppId authentication
    3.2.1. Custom UserId
    3.3. AppRole authentication
    3.4. AWS-EC2 authentication
    3.5. AWS-IAM authentication
    3.6. TLS certificate authentication
    3.7. Cubbyhole authentication
    3.8. Kubernetes authentication
    4. Secret Backends
    4.1. Generic Backend
    4.2. Consul
    4.3. RabbitMQ
    4.4. AWS
    5. Database backends
    5.1. Database
    5.2. Apache Cassandra
    5.3. MongoDB
    5.4. MySQL
    5.5. PostgreSQL
    6. Configure PropertySourceLocator behavior
    7. Service Registry Configuration
    8. Vault Client Fail Fast
    9. Vault Client SSL configuration
    10. Lease lifecycle management (renewal and revocation)
    © 2016-2017 The original authors.
    [Note]Note
    Copies of this document may be made for your own use and for distribution to others, provided that you do not charge any fee for such copies and further provided that each copy contains this Copyright Notice, whether distributed in print or electronically.
    Spring Cloud Vault Config provides client-side support for externalized configuration in a distributed system. With HashiCorp’s Vault you have a central place to manage external secret properties for applications across all environments. Vault can manage static and dynamic secrets such as username/password for remote applications/resources and provide credentials for external services such as MySQL, PostgreSQL, Apache Cassandra, MongoDB, Consul, AWS and more.
    1. Quick Start
    Prerequisites
    To get started with Vault and this guide you need a
+   Spring Cloud Vault
    Spring Cloud Vault
    Table of Contents
    1. Quick Start
    2. Client Side Usage
    2.1. Authentication
    3. Authentication methods
    3.1. Token authentication
    3.2. AppId authentication
    3.2.1. Custom UserId
    3.3. AppRole authentication
    3.4. AWS-EC2 authentication
    3.5. AWS-IAM authentication
    3.6. TLS certificate authentication
    3.7. Cubbyhole authentication
    3.8. Kubernetes authentication
    4. Secret Backends
    4.1. Generic Backend
    4.2. Versioned Key-Value Backend
    4.3. Consul
    4.4. RabbitMQ
    4.5. AWS
    5. Database backends
    5.1. Database
    5.2. Apache Cassandra
    5.3. MongoDB
    5.4. MySQL
    5.5. PostgreSQL
    6. Configure PropertySourceLocator behavior
    7. Service Registry Configuration
    8. Vault Client Fail Fast
    9. Vault Client SSL configuration
    10. Lease lifecycle management (renewal and revocation)
    © 2016-2018 The original authors.
    [Note]Note
    Copies of this document may be made for your own use and for distribution to others, provided that you do not charge any fee for such copies and further provided that each copy contains this Copyright Notice, whether distributed in print or electronically.
    Spring Cloud Vault Config provides client-side support for externalized configuration in a distributed system. With HashiCorp’s Vault you have a central place to manage external secret properties for applications across all environments. Vault can manage static and dynamic secrets such as username/password for remote applications/resources and provide credentials for external services such as MySQL, PostgreSQL, Apache Cassandra, MongoDB, Consul, AWS and more.
    1. Quick Start
    Prerequisites
    To get started with Vault and this guide you need a
 *NIX-like operating systems that provides:
    • wget, openssl and unzip
    • at least Java 7 and a properly configured JAVA_HOME environment variable
    Install Vault
    $ src/test/bash/install_vault.sh
    Create SSL certificates for Vault
    $ src/test/bash/create_certificates.sh
    [Note]Note
    create_certificates.sh creates certificates in work/ca and a JKS truststore work/keystore.jks. If you want to run Spring Cloud Vault using this quickstart guide you need to configure the truststore the spring.cloud.vault.ssl.trust-store property to file:work/keystore.jks.
    Start Vault server
    $ src/test/bash/local_run_vault.sh
    Vault is started listening on 0.0.0.0:8200 using the inmem storage and
 https.
 Vault is sealed and not initialized when starting up.
    [Note]Note
    If you want to run tests, leave Vault uninitialized. The tests will
@@ -39,7 +39,7 @@ Boot application that depends on spring-cloud-vault-config
 the test cases). Example Maven configuration:
    Example 2.1. pom.xml
    <parent>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-parent</artifactId>
-    <version>1.5.4.RELEASE</version>
+    <version>2.0.0.RELEASE</version>
     <relativePath /> <!-- lookup parent from repository -->
 </parent>
 
@@ -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.0.BUILD-SNAPSHOT</version>
+        <version>2.0.1.BUILD-SNAPSHOT</version>
     </dependency>
     <dependency>
         <groupId>org.springframework.boot</groupId>
@@ -149,17 +149,17 @@ obtain a token.
    }
 }

    See also: Vault Documentation: Using the App ID auth backend
    3.3 AppRole authentication
    AppRole is intended for machine
 authentication, like the deprecated (since Vault 0.6.1) Section 3.2, “AppId authentication”.
-AppRole authentication consists of two hard to guess (secret) tokens: RoleId and SecretId.
    Spring Vault supports AppRole authentication by providing either RoleId only
-or together with a provided SecretId (push or pull mode).
    RoleId and optionally SecretId must be provided by configuration,
+AppRole authentication consists of two hard to guess (secret) tokens: RoleId and SecretId.
    Spring Vault supports various AppRole scenarios (push/pull mode and wrapped).
    RoleId and optionally SecretId must be provided by configuration,
 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

    • role-id sets the RoleId.
    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
         secret-id: 1696536f-1976-73b1-b241-0b4213908d39
-        app-auth-path: approle

    • role-id sets the RoleId.
    • secret-id sets the SecretId. SecretId can be omitted if AppRole is configured without requiring SecretId (See bind_secret_id)
    • approle-path sets the path of the approle authentication mount to use
    See also: Vault Documentation: Using the AppRole auth backend
    3.4 AWS-EC2 authentication
    The aws-ec2
+        role: my-role
+        app-role-path: approle

    • role-id sets the RoleId.
    • secret-id sets the SecretId. SecretId can be omitted if AppRole is configured without requiring SecretId (See bind_secret_id).
    • role: sets the AppRole name for pull mode.
    • app-role-path sets the path of the approle authentication mount to use.
    See also: Vault Documentation: Using the AppRole auth backend
    3.4 AWS-EC2 authentication
    The aws-ec2
 auth backend provides a secure introduction mechanism
 for AWS EC2 instances, allowing automated retrieval of a Vault
 token. Unlike most Vault authentication backends, this backend
@@ -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
@@ -243,7 +243,7 @@ and a default context name (application) in combina
 profiles.
    /secret/{application}/{profile}
 /secret/{application}
 /secret/{default-context}/{profile}
-/secret/{default-context}
    The application name is determined by the properties:
    • spring.cloud.vault.generic.application-name
    • spring.cloud.vault.application-name
    • spring.application.name
    Secrets can be obtained from other folders within the generic backend by adding their
+/secret/{default-context}
    The application name is determined by the properties:
    • spring.cloud.vault.generic.application-name
    • spring.cloud.vault.application-name
    • spring.application.name
    Secrets can be obtained from other contexts within the generic backend by adding their
 paths to the application name, separated by commas. For example, given the application
 name usefulapp,mysql1,projectx/aws, each of these folders will be used:
    • /secret/usefulapp
    • /secret/mysql1
    • /secret/projectx/aws
    Spring Cloud Vault adds all active profiles to the list of possible context paths.
 No active profiles will skip accessing contexts with a profile name.
    Properties are exposed like they are stored (i.e. without additional prefixes).
    spring.cloud.vault:
@@ -254,13 +254,33 @@ No active profiles will skip accessing contexts with a profile name.
    Prope
         default-context: application
         application-name: my-app
    • enabled setting this value to false disables the secret backend
 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
    See also: Vault Documentation: Using the generic secret backend
    4.2 Consul
    Spring Cloud Vault can obtain credentials for HashiCorp Consul.
+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 1 (generic secret backend)
    4.2 Versioned Key-Value Backend
    Spring Cloud Vault supports the versioned Key-Value secret
+backend. The key-value backend allows storage of arbitrary
+values as key-value store. A single context can store one or many
+key-value tuples. Contexts can be organized hierarchically.
+Spring Cloud Vault allows using the Application name
+and a default context name (application) in combination with active
+profiles.
    /secret/{application}/{profile}
+/secret/{application}
+/secret/{default-context}/{profile}
+/secret/{default-context}
    The application name is determined by the properties:
    • spring.cloud.vault.kv.application-name
    • spring.cloud.vault.application-name
    • spring.application.name
    Secrets can be obtained from other contexts within the key-value backend by adding their
+paths to the application name, separated by commas. For example, given the application
+name usefulapp,mysql1,projectx/aws, each of these folders will be used:
    • /secret/usefulapp
    • /secret/mysql1
    • /secret/projectx/aws
    Spring Cloud Vault adds all active profiles to the list of possible context paths.
+No active profiles will skip accessing contexts with a profile name.
    Properties are exposed like they are stored (i.e. without additional prefixes).
    [Note]Note
    Spring Cloud Vault adds the data/ context between the mount path and the actual context path.
    spring.cloud.vault:
+    kv:
+        enabled: true
+        backend: secret
+        profile-separator: '/'
+        default-context: application
+        application-name: my-app
    • enabled setting this value to false disables the secret backend
+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.0.BUILD-SNAPSHOT</version>
+        <version>2.0.1.BUILD-SNAPSHOT</version>
     </dependency>
 </dependencies>

    The integration can be enabled by setting
 spring.cloud.vault.consul.enabled=true (default false) and
@@ -272,12 +292,12 @@ the property name by setting spring.cloud.vault.consul.tok
         enabled: true
         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.3 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>
+        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>
         <groupId>org.springframework.cloud</groupId>
         <artifactId>spring-cloud-vault-config-rabbitmq</artifactId>
-        <version>2.0.0.BUILD-SNAPSHOT</version>
+        <version>2.0.1.BUILD-SNAPSHOT</version>
     </dependency>
 </dependencies>

    The integration can be enabled by setting
 spring.cloud.vault.rabbitmq.enabled=true (default false)
@@ -291,12 +311,12 @@ by setting spring.cloud.vault.rabbitmq.username-property        role: readonly
         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.4 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>
+        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>
         <groupId>org.springframework.cloud</groupId>
         <artifactId>spring-cloud-vault-config-aws</artifactId>
-        <version>2.0.0.BUILD-SNAPSHOT</version>
+        <version>2.0.1.BUILD-SNAPSHOT</version>
     </dependency>
 </dependencies>

    The integration can be enabled by setting
 spring.cloud.vault.aws=true (default false)
@@ -319,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.0.BUILD-SNAPSHOT</version>
+        <version>2.0.1.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