From d8749d4ef1529115edc455189bea962d97bd87fa Mon Sep 17 00:00:00 2001 From: buildmaster Date: Fri, 9 Nov 2018 07:58:56 +0000 Subject: [PATCH] Sync docs from master to gh-pages --- multi/multi_spring-cloud-vault.html | 2 +- multi/multi_vault.config.authentication.html | 30 ++++++++++---- ...ult.config.backends.database-backends.html | 2 +- multi/multi_vault.config.backends.html | 6 +-- single/spring-cloud-vault.html | 40 +++++++++++++------ 5 files changed, 56 insertions(+), 24 deletions(-) diff --git a/multi/multi_spring-cloud-vault.html b/multi/multi_spring-cloud-vault.html index 40471067..7ac37601 100644 --- a/multi/multi_spring-cloud-vault.html +++ b/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. 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 + 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. Azure MSI authentication
3.7. TLS certificate authentication
3.8. Cubbyhole authentication
3.9. 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/multi/multi_vault.config.authentication.html b/multi/multi_vault.config.authentication.html index 200e9764..a5bd8056 100644 --- a/multi/multi_vault.config.authentication.html +++ b/multi/multi_vault.config.authentication.html @@ -111,28 +111,44 @@ the friendly name the current IAM role.

role: my-dev-role aws-path: aws 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 +as the authentication implementation uses AWS SDK types for credentials and request signing.

See also: Vault Documentation: Using the aws auth backend

3.6 Azure MSI authentication

The azure +auth backend provides a secure introduction mechanism +for Azure VM instances, allowing automated retrieval of a Vault +token. Unlike most Vault authentication backends, this backend +does not require first-deploying, or provisioning security-sensitive +credentials (tokens, username/password, client certificates, etc.). +Instead, it treats Azure as a Trusted Third Party and uses the +managed service identity and instance metadata information that can be +bound to a VM instance.

Example 3.13. bootstrap.yml with required Azure Authentication properties

spring.cloud.vault:
+    authentication: AZURE_MSI
+    azure-msi:
+        role: my-dev-role

Example 3.14. bootstrap.yml with all Azure Authentication properties

spring.cloud.vault:
+    authentication: AZURE_MSI
+    azure-msi:
+        role: my-dev-role
+        azure-path: aws

  • role sets the name of the role against which the login is being attempted.
  • azure-path sets the path of the Azure mount to use

Azure MSI authentication fetches environmental details about the virtual machine +(subscription Id, resource group, VM name) from the instance metadata service.

See also: Vault Documentation: Using the azure auth backend

3.7 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.15. bootstrap.yml

    spring.cloud.vault:
     authentication: CERT
     ssl:
         key-store: classpath:keystore.jks
         key-store-password: changeit
-        cert-auth-path: cert

    See also: Vault Documentation: Using the Cert auth backend

    3.7 Cubbyhole authentication

    Cubbyhole authentication uses Vault primitives to provide a secured authentication + cert-auth-path: cert


    See also: Vault Documentation: Using the Cert auth backend

    3.8 Cubbyhole authentication

    Cubbyhole authentication uses Vault primitives to provide a secured authentication 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.16. 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.17. 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:
+    token: 397ccb93-ff6c-b17b-9389-380b01ca2645

    See also:

    3.9 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.18. 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 911ac93d..b5793a3f 100644
--- a/multi/multi_vault.config.backends.database-backends.html
+++ b/multi/multi_vault.config.backends.database-backends.html
@@ -9,7 +9,7 @@ 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>
diff --git a/multi/multi_vault.config.backends.html b/multi/multi_vault.config.backends.html
index 12c4891b..7bd36347 100644
--- a/multi/multi_vault.config.backends.html
+++ b/multi/multi_vault.config.backends.html
@@ -42,7 +42,7 @@ 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>
@@ -59,7 +59,7 @@ 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>
@@ -78,7 +78,7 @@ 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>
diff --git a/single/spring-cloud-vault.html b/single/spring-cloud-vault.html
index 507db041..47929ee6 100644
--- a/single/spring-cloud-vault.html
+++ b/single/spring-cloud-vault.html
@@ -1,6 +1,6 @@
 
       
-   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
+   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. Azure MSI authentication
    3.7. TLS certificate authentication
    3.8. Cubbyhole authentication
    3.9. 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
@@ -208,28 +208,44 @@ the friendly name the current IAM role.
            role: my-dev-role
         aws-path: aws
         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
+as the authentication implementation uses AWS SDK types for credentials and request signing.
    See also: Vault Documentation: Using the aws auth backend
    3.6 Azure MSI authentication
    The azure
+auth backend provides a secure introduction mechanism
+for Azure VM instances, allowing automated retrieval of a Vault
+token. Unlike most Vault authentication backends, this backend
+does not require first-deploying, or provisioning security-sensitive
+credentials (tokens, username/password, client certificates, etc.).
+Instead, it treats Azure as a Trusted Third Party and uses the
+managed service identity and instance metadata information that can be
+bound to a VM instance.
    Example 3.13. bootstrap.yml with required Azure Authentication properties
    spring.cloud.vault:
+    authentication: AZURE_MSI
+    azure-msi:
+        role: my-dev-role

    Example 3.14. bootstrap.yml with all Azure Authentication properties
    spring.cloud.vault:
+    authentication: AZURE_MSI
+    azure-msi:
+        role: my-dev-role
+        azure-path: aws

    • role sets the name of the role against which the login is being attempted.
    • azure-path sets the path of the Azure mount to use
    Azure MSI authentication fetches environmental details about the virtual machine
+(subscription Id, resource group, VM name) from the instance metadata service.
    See also: Vault Documentation: Using the azure auth backend
    3.7 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.15. bootstrap.yml
    spring.cloud.vault:
     authentication: CERT
     ssl:
         key-store: classpath:keystore.jks
         key-store-password: changeit
-        cert-auth-path: cert

    See also: Vault Documentation: Using the Cert auth backend
    3.7 Cubbyhole authentication
    Cubbyhole authentication uses Vault primitives to provide a secured authentication
+        cert-auth-path: cert

    See also: Vault Documentation: Using the Cert auth backend
    3.8 Cubbyhole authentication
    Cubbyhole authentication uses Vault primitives to provide a secured authentication
 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.16. 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.17. 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:
+    token: 397ccb93-ff6c-b17b-9389-380b01ca2645

    See also:
    3.9 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.18. bootstrap.yml with all Kubernetes authentication properties
    spring.cloud.vault:
     authentication: KUBERNETES
     kubernetes:
         role: my-dev-role
@@ -276,7 +292,7 @@ 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>
@@ -293,7 +309,7 @@ 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>
@@ -312,7 +328,7 @@ 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>
@@ -339,7 +355,7 @@ 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>