From ee5c29ceb16b64bedfd4a3797c2d66a8a9a4659b Mon Sep 17 00:00:00 2001 From: buildmaster Date: Tue, 24 Apr 2018 14:51:12 +0000 Subject: [PATCH] Sync docs from master to gh-pages --- multi/multi_spring-cloud-vault.html | 2 +- ...ult.config.backends.database-backends.html | 2 +- multi/multi_vault.config.backends.html | 34 +++++++++++++---- single/spring-cloud-vault.html | 38 ++++++++++++++----- 4 files changed, 58 insertions(+), 18 deletions(-) diff --git a/multi/multi_spring-cloud-vault.html b/multi/multi_spring-cloud-vault.html index 3b5056a6..504088b4 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. 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/multi/multi_vault.config.backends.database-backends.html b/multi/multi_vault.config.backends.database-backends.html index 75fab926..5fa0aa62 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 aa5aaa4b..b431c1d9 100644
--- a/multi/multi_vault.config.backends.html
+++ b/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,9 +20,29 @@ 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>
@@ -38,8 +58,8 @@ 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>
@@ -57,8 +77,8 @@ 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>
diff --git a/single/spring-cloud-vault.html b/single/spring-cloud-vault.html
index 250d6813..2e10e3b1 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. 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-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. 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
@@ -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,9 +254,29 @@ 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>
@@ -272,8 +292,8 @@ 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>
@@ -291,8 +311,8 @@ 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>
@@ -319,7 +339,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>