diff --git a/multi/multi_spring-cloud-vault.html b/multi/multi_spring-cloud-vault.html index a6a2b6ad..5c157ee5 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. TLS certificate authentication
3.6. Cubbyhole authentication
4. Secret Backends
4.1. Generic Backend
4.2. Consul
4.3. RabbitMQ
4.4. AWS
5. Database backends
5.1. Apache Cassandra
5.2. MongoDB
5.3. MySQL
5.4. 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. Consul
4.3. RabbitMQ
4.4. AWS
5. Database backends
5.1. Apache Cassandra
5.2. MongoDB
5.3. MySQL
5.4. 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 eb38c56a..a03c3a60 100644 --- a/multi/multi_vault.config.authentication.html +++ b/multi/multi_vault.config.authentication.html @@ -90,24 +90,50 @@ You can configure the authentication role by setting the aws-ec2-path: aws-ec2 identity-document: http://... nonce: my-static-nonce

See also: Vault Documentation: Using the aws-ec2 auth backend

3.5 TLS certificate authentication

The cert auth backend allows authentication using SSL/TLS client +authentication method

  • role sets the name of the role against which the login is being attempted.
  • aws-ec2-path sets the path of the AWS EC2 mount to use
  • identity-document sets URL of the PKCS#7 AWS EC2 identity document
  • nonce used for AWS-EC2 authentication. An empty nonce defaults to nonce generation

    • See also: Vault Documentation: Using the aws auth backend

    3.5 AWS-IAM authentication

    The aws backend provides a secure +authentication mechanism for AWS IAM roles, allowing the automatic authentication with +vault based on the current IAM role of the running application. + 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 AWS as a Trusted Third Party and uses the +4 pieces of information signed by the caller with their IAM credentials + to verify that the caller is indeed using that IAM role.

    The current IAM role the application is running in is automatically calculated. +If you are running your application on AWS ECS then the application +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:
+    authentication: AWS_IAM
+    aws-iam:
+        role: my-dev-role
+        aws-path: aws
+        server-id: some.server.name

    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.11. 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
         key-store-password: changeit
-        cert-auth-path: cert

    See also: Vault Documentation: Using the Cert auth backend

    3.6 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.7 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.12. Crating 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.13. 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:
    Prev   Next
    2. Client Side Usage Home 4. Secret Backends
    \ No newline at end of file + 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:
+    authentication: KUBERNETES
+    kubernetes:
+        role: my-dev-role
+        service-account-token-file: /var/run/secrets/kubernetes.io/serviceaccount/token

    See also:

    Prev   Next
    2. Client Side Usage Home 4. Secret Backends
    \ No newline at end of file diff --git a/multi/multi_vault.config.backends.database-backends.html b/multi/multi_vault.config.backends.database-backends.html index b7036ffd..c4b75401 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 adapting one of the JDBC database properties above. 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 854148f6..5ba1d3a2 100644
--- a/multi/multi_vault.config.backends.html
+++ b/multi/multi_vault.config.backends.html
@@ -22,7 +22,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
    • See also: Vault Documentation: Using the generic secret backend
    4.2 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>
@@ -39,7 +39,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.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>
+dependency.
    Example 4.2. pom.xml
    <dependencies>
     <dependency>
         <groupId>org.springframework.cloud</groupId>
         <artifactId>spring-cloud-vault-config-rabbitmq</artifactId>
@@ -58,7 +58,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.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>
+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 c7a9857c..0ed5c0d5 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. TLS certificate authentication
    3.6. Cubbyhole authentication
    4. Secret Backends
    4.1. Generic Backend
    4.2. Consul
    4.3. RabbitMQ
    4.4. AWS
    5. Database backends
    5.1. Apache Cassandra
    5.2. MongoDB
    5.3. MySQL
    5.4. 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. Consul
    4.3. RabbitMQ
    4.4. AWS
    5. Database backends
    5.1. Apache Cassandra
    5.2. MongoDB
    5.3. MySQL
    5.4. 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
 *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
@@ -188,27 +188,53 @@ You can configure the authentication role by setting the
         aws-ec2-path: aws-ec2
         identity-document: http://...
         nonce: my-static-nonce
    • authentication setting this value to AWS_EC2 selects the AWS EC2
-authentication method
    • role sets the role name of the AWS EC2 role definition
    • aws-ec2-path sets the path of the AWS EC2 mount to use
    • identity-document sets URL of the PKCS#7 AWS EC2 identity document
    • nonce used for AWS-EC2 authentication. An empty nonce defaults to nonce generation
    See also: Vault Documentation: Using the aws-ec2 auth backend
    3.5 TLS certificate authentication
    The cert auth backend allows authentication using SSL/TLS client
+authentication method
  • role sets the name of the role against which the login is being attempted.
  • aws-ec2-path sets the path of the AWS EC2 mount to use
  • identity-document sets URL of the PKCS#7 AWS EC2 identity document
  • nonce used for AWS-EC2 authentication. An empty nonce defaults to nonce generation
    • See also: Vault Documentation: Using the aws auth backend
    3.5 AWS-IAM authentication
    The aws backend provides a secure
+authentication mechanism for AWS IAM roles, allowing the automatic authentication with
+vault based on the current IAM role of the running application.
+ 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 AWS as a Trusted Third Party and uses the
+4 pieces of information signed by the caller with their IAM credentials
+ to verify that the caller is indeed using that IAM role.
    The current IAM role the application is running in is automatically calculated.
+If you are running your application on AWS ECS then the application
+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:
+    authentication: AWS_IAM
+    aws-iam:
+        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
 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.11. 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
         key-store-password: changeit
-        cert-auth-path: cert

    See also: Vault Documentation: Using the Cert auth backend
    3.6 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.7 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.12. Crating 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.13. 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:
    4. Secret Backends
    4.1 Generic Backend
    Spring Cloud Vault supports at the basic level the generic secret
+    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:
+    authentication: KUBERNETES
+    kubernetes:
+        role: my-dev-role
+        service-account-token-file: /var/run/secrets/kubernetes.io/serviceaccount/token

    • role sets the Role.
    • service-account-token-file sets the location of the file containing the Kubernetes Service Account Token. Defaults to /var/run/secrets/kubernetes.io/serviceaccount/token.
    See also:
    4. Secret Backends
    4.1 Generic Backend
    Spring Cloud Vault supports at the basic level the generic secret
 backend. The generic secret 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.
@@ -230,7 +256,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
    • See also: Vault Documentation: Using the generic secret backend
    4.2 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>
@@ -247,7 +273,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.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>
+dependency.
    Example 4.2. pom.xml
    <dependencies>
     <dependency>
         <groupId>org.springframework.cloud</groupId>
         <artifactId>spring-cloud-vault-config-rabbitmq</artifactId>
@@ -266,7 +292,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.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>
+dependency.
    Example 4.3. pom.xml
    <dependencies>
     <dependency>
         <groupId>org.springframework.cloud</groupId>
         <artifactId>spring-cloud-vault-config-aws</artifactId>
@@ -293,7 +319,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 adapting
 one of the JDBC database properties above. 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>