diff --git a/multi/multi__service_registry_configuration.html b/multi/multi__service_registry_configuration.html index ec37d86d..b0fb9734 100644 --- a/multi/multi__service_registry_configuration.html +++ b/multi/multi__service_registry_configuration.html @@ -1,6 +1,6 @@ - 9. Service Registry Configuration
9. Service Registry Configuration
Prev   Next

9. Service Registry Configuration

You can use a DiscoveryClient (such as from Spring Cloud Consul) to locate + 7. Service Registry Configuration

7. Service Registry Configuration
Prev   Next

7. Service Registry Configuration

You can use a DiscoveryClient (such as from Spring Cloud Consul) to locate a Vault server by setting spring.cloud.vault.discovery.enabled=true (default false). The net result of that is that your apps need a bootstrap.yml (or an environment variable) with the appropriate discovery configuration. @@ -14,4 +14,4 @@ need to provide a scheme metadata entry to be set e If no scheme is configured and the service is not exposed as secure service, then configuration defaults to spring.cloud.vault.scheme which is https when it’s not set.

spring.cloud.vault.discovery:
     enabled: true
-    service-id: my-vault-service
Prev   Next
8. Configure PropertySourceLocator behavior Home 10. Vault Client Fail Fast
\ No newline at end of file + service-id: my-vault-service
Prev   Next
6. Configure PropertySourceLocator behavior Home 8. Vault Client Fail Fast
\ No newline at end of file diff --git a/multi/multi_pr01.html b/multi/multi_pr01.html index f133b08b..1d099ff5 100644 --- a/multi/multi_pr01.html +++ b/multi/multi_pr01.html @@ -1,3 +1,3 @@ -
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 +
Prev   Next

© 2016-2019 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/multi/multi_spring-cloud-vault.html b/multi/multi_spring-cloud-vault.html index 84cde1b4..591fec23 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. Azure MSI authentication
3.7. TLS certificate authentication
3.8. Cubbyhole authentication
4. GCP-GCE authentication
5. GCP-IAM authentication
5.1. Kubernetes authentication
6. Secret Backends
6.1. Generic Backend
6.2. Versioned Key-Value Backend
6.3. Consul
6.4. RabbitMQ
6.5. AWS
7. Database backends
7.1. Database
7.2. Apache Cassandra
7.3. MongoDB
7.4. MySQL
7.5. PostgreSQL
8. Configure PropertySourceLocator behavior
9. Service Registry Configuration
10. Vault Client Fail Fast
11. Vault Client SSL configuration
12. 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. GCP-GCE authentication
3.10. GCP-IAM authentication
3.11. 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-lease-renewal.html b/multi/multi_vault-lease-renewal.html index 2515026d..7b7255f8 100644 --- a/multi/multi_vault-lease-renewal.html +++ b/multi/multi_vault-lease-renewal.html @@ -1,6 +1,6 @@ - 12. Lease lifecycle management (renewal and revocation)
12. Lease lifecycle management (renewal and revocation)
Prev   

12. Lease lifecycle management (renewal and revocation)

With every secret, Vault creates a lease: + 10. Lease lifecycle management (renewal and revocation)

10. Lease lifecycle management (renewal and revocation)
Prev   

10. Lease lifecycle management (renewal and revocation)

With every secret, Vault creates a lease: metadata containing information such as a time duration, renewability, and more.

Vault promises that the data will be valid for the given duration, or Time To Live (TTL). Once the lease is expired, Vault can @@ -19,4 +19,4 @@ to false. This is not recommended as leases can exp Spring Cloud Vault cannot longer access Vault or services using generated credentials and valid credentials remain active after application shutdown.

spring.cloud.vault:
-    config.lifecycle.enabled: true

See also: Vault Documentation: Lease, Renew, and Revoke

Prev   
11. Vault Client SSL configuration Home 
\ No newline at end of file + config.lifecycle.enabled: true

See also: Vault Documentation: Lease, Renew, and Revoke

Prev   
9. Vault Client SSL configuration Home 
\ No newline at end of file diff --git a/multi/multi_vault.config.authentication.html b/multi/multi_vault.config.authentication.html index b78c8c0b..1c67b6b0 100644 --- a/multi/multi_vault.config.authentication.html +++ b/multi/multi_vault.config.authentication.html @@ -1,6 +1,6 @@ - 3. Authentication methods
3. Authentication methods
Prev   Next

3. Authentication methods

Different organizations have different requirements for security + 3. Authentication methods

3. Authentication methods
Prev   Next

3. Authentication methods

Different organizations have different requirements for security and authentication. Vault reflects that need by shipping multiple authentication methods. Spring Cloud Vault supports token and AppId authentication.

3.1 Token authentication

Tokens are the core method for authentication within Vault. Token authentication requires a static token to be provided using the @@ -128,7 +128,7 @@ bound to a VM instance.

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 11, Vault Client SSL configuration
  2. Configure a Java Keystore that contains the 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.15. bootstrap.yml

    spring.cloud.vault:
     authentication: CERT
     ssl:
@@ -147,4 +147,53 @@ 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.17. bootstrap.yml

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

    See also:

Prev   Next
2. Client Side Usage Home 4. GCP-GCE authentication
\ No newline at end of file + token: 397ccb93-ff6c-b17b-9389-380b01ca2645

See also:

3.9 GCP-GCE authentication

The gcp +auth backend allows Vault login by using existing GCP (Google Cloud Platform) IAM and GCE credentials.

GCP GCE (Google Compute Engine) authentication creates a signature in the form of a +JSON Web Token (JWT) for a service account. A JWT for a Compute Engine instance +is obtained from the GCE metadata service using Instance identification. +This API creates a JSON Web Token that can be used to confirm the instance identity.

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 GCP as a Trusted Third Party and uses the +cryptographically signed dynamic metadata information that uniquely +represents each GCP service account.

Example 3.18. bootstrap.yml with required GCP-GCE Authentication properties

spring.cloud.vault:
+    authentication: GCP_GCE
+    gcp-gce:
+        role: my-dev-role

Example 3.19. bootstrap.yml with all GCP-GCE Authentication properties

spring.cloud.vault:
+    authentication: GCP_GCE
+    gcp-gce:
+        gcp-path: gcp
+        role: my-dev-role
+        service-account: my-service@projectid.iam.gserviceaccount.com

See also:

3.10 GCP-IAM authentication

The gcp +auth backend allows Vault login by using existing GCP (Google Cloud Platform) IAM and GCE credentials.

GCP IAM authentication creates a signature in the form of a JSON Web Token (JWT) +for a service account. A JWT for a service account is obtained by +calling GCP IAM’s projects.serviceAccounts.signJwt API. The caller authenticates against GCP IAM +and proves thereby its identity. This Vault backend treats GCP as a Trusted Third Party.

IAM credentials can be obtained from either the runtime environment +, specifically the GOOGLE_APPLICATION_CREDENTIALS +environment variable, the Google Compute metadata service, +or supplied externally as e.g. JSON or base64 encoded. +JSON is the preferred form as it carries the project id and +service account identifier required for calling projects.serviceAccounts.signJwt.

Example 3.20. bootstrap.yml with required GCP-IAM Authentication properties

spring.cloud.vault:
+    authentication: GCP_IAM
+    gcp-iam:
+        role: my-dev-role

Example 3.21. bootstrap.yml with all GCP-IAM Authentication properties

spring.cloud.vault:
+    authentication: GCP_IAM
+    gcp-iam:
+        credentials:
+            location: classpath:credentials.json
+            encoded-key: e+KApn0=
+        gcp-path: gcp
+        jwt-validity: 15m
+        project-id: my-project-id
+        role: my-dev-role
+        service-account: my-service@projectid.iam.gserviceaccount.com

GCP IAM authentication requires the Google Cloud Java SDK dependency +(com.google.apis:google-api-services-iam and com.google.auth:google-auth-library-oauth2-http) +as the authentication implementation uses Google APIs for credentials and JWT signing.

[Note]Note

Google credentials require an OAuth 2 token maintaining the token lifecycle. All API +is synchronous therefore, GcpIamAuthentication does not support AuthenticationSteps which is +required for reactive usage.

See also:

3.11 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.22. bootstrap.yml with all Kubernetes authentication properties

spring.cloud.vault:
+    authentication: KUBERNETES
+    kubernetes:
+        role: my-dev-role
+        kubernetes-path: kubernetes
+        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.configurer.html b/multi/multi_vault.config.backends.configurer.html index 1fc6e544..996aa2c4 100644 --- a/multi/multi_vault.config.backends.configurer.html +++ b/multi/multi_vault.config.backends.configurer.html @@ -1,6 +1,6 @@ - 8. Configure PropertySourceLocator behavior
8. Configure PropertySourceLocator behavior
Prev   Next

8. Configure PropertySourceLocator behavior

Spring Cloud Vault uses property-based configuration to create PropertySources + 6. Configure PropertySourceLocator behavior

6. Configure PropertySourceLocator behavior
Prev   Next

6. Configure PropertySourceLocator behavior

Spring Cloud Vault uses property-based configuration to create PropertySources for generic and discovered secret backends.

Discovered backends provide VaultSecretBackendDescriptor beans to describe the configuration state to use secret backend as PropertySource. A SecretBackendMetadataFactory is required to create a SecretBackendMetadata object which contains path, name and property transformation @@ -19,4 +19,4 @@ at least one VaultConfigurer bean. You can however } }

[Note]Note

All customization is required to happen in the bootstrap context. Add your configuration classes to META-INF/spring.factories at org.springframework.cloud.bootstrap.BootstrapConfiguration -in your application.

Prev   Next
7. Database backends Home 9. Service Registry Configuration
\ No newline at end of file +in your application.

Prev   Next
5. Database backends Home 7. Service Registry Configuration
\ 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 be626ec5..d813b881 100644 --- a/multi/multi_vault.config.backends.database-backends.html +++ b/multi/multi_vault.config.backends.database-backends.html @@ -1,15 +1,15 @@ - 7. Database backends
7. Database backends
Prev   Next

7. Database backends

Vault supports several database secret backends to generate database + 5. Database backends

5. Database backends
Prev   Next

5. Database backends

Vault supports several database secret backends to generate database credentials dynamically based on configured roles. This means services that need to access a database no longer need to configure credentials: they can request them from Vault, and use Vault’s leasing -mechanism to more easily roll keys.

Spring Cloud Vault integrates with these backends:

Using a database secret backend requires to enable the +mechanism to more easily roll keys.

Spring Cloud Vault integrates with these backends:

Using a database secret backend requires to enable the backend in the configuration and the spring-cloud-vault-config-databases 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 7.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>
@@ -17,7 +17,7 @@ backend path, e.g. spring.cloud.vault.mysql.role.backend=d
     </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
-JDBC secrets need to be configured separately.
7.1 Database
Spring Cloud Vault can obtain credentials for any database listed at
+JDBC secrets need to be configured separately.
5.1 Database
Spring Cloud Vault can obtain credentials for any database listed at
 https://www.vaultproject.io/api/secret/databases/index.html.
 The integration can be enabled by setting
 spring.cloud.vault.database.enabled=true (default false) and
@@ -34,7 +34,7 @@ You can configure the property names by setting
         role: readonly
         backend: database
         username-property: spring.datasource.username
-        password-property: spring.datasource.username
  • enabled setting this value to true enables the Database backend config usage
  • role sets the role name of the Database role definition
  • backend sets the path of the Database mount to use
  • username-property sets the property name in which the Database username is stored
  • password-property sets the property name in which the Database password is stored

See also: Vault Documentation: Database Secrets backend

7.2 Apache Cassandra

[Note]Note

The cassandra backend has been deprecated in Vault 0.7.1 and + password-property: spring.datasource.username

  • enabled setting this value to true enables the Database backend config usage
  • role sets the role name of the Database role definition
  • backend sets the path of the Database mount to use
  • username-property sets the property name in which the Database username is stored
  • password-property sets the property name in which the Database password is stored

See also: Vault Documentation: Database Secrets backend

5.2 Apache Cassandra

[Note]Note

The cassandra backend has been deprecated in Vault 0.7.1 and it is recommended to use the database backend and mount it as cassandra.

Spring Cloud Vault can obtain credentials for Apache Cassandra. The integration can be enabled by setting spring.cloud.vault.cassandra.enabled=true (default false) and @@ -49,7 +49,7 @@ You can configure the property names by setting role: readonly backend: cassandra username-property: spring.data.cassandra.username - password-property: spring.data.cassandra.username

  • enabled setting this value to true enables the Cassandra backend config usage
  • role sets the role name of the Cassandra role definition
  • backend sets the path of the Cassandra mount to use
  • username-property sets the property name in which the Cassandra username is stored
  • password-property sets the property name in which the Cassandra password is stored

See also: Vault Documentation: Setting up Apache Cassandra with Vault

7.3 MongoDB

[Note]Note

The mongodb backend has been deprecated in Vault 0.7.1 and + password-property: spring.data.cassandra.username

  • enabled setting this value to true enables the Cassandra backend config usage
  • role sets the role name of the Cassandra role definition
  • backend sets the path of the Cassandra mount to use
  • username-property sets the property name in which the Cassandra username is stored
  • password-property sets the property name in which the Cassandra password is stored

See also: Vault Documentation: Setting up Apache Cassandra with Vault

5.3 MongoDB

[Note]Note

The mongodb backend has been deprecated in Vault 0.7.1 and it is recommended to use the database backend and mount it as mongodb.

Spring Cloud Vault can obtain credentials for MongoDB. The integration can be enabled by setting spring.cloud.vault.mongodb.enabled=true (default false) and @@ -64,7 +64,7 @@ You can configure the property names by setting role: readonly backend: mongodb username-property: spring.data.mongodb.username - password-property: spring.data.mongodb.password

  • enabled setting this value to true enables the MongodB backend config usage
  • role sets the role name of the MongoDB role definition
  • backend sets the path of the MongoDB mount to use
  • username-property sets the property name in which the MongoDB username is stored
  • password-property sets the property name in which the MongoDB password is stored

See also: Vault Documentation: Setting up MongoDB with Vault

7.4 MySQL

[Note]Note

The mysql backend has been deprecated in Vault 0.7.1 and + password-property: spring.data.mongodb.password

  • enabled setting this value to true enables the MongodB backend config usage
  • role sets the role name of the MongoDB role definition
  • backend sets the path of the MongoDB mount to use
  • username-property sets the property name in which the MongoDB username is stored
  • password-property sets the property name in which the MongoDB password is stored

See also: Vault Documentation: Setting up MongoDB with Vault

5.4 MySQL

[Note]Note

The mysql backend has been deprecated in Vault 0.7.1 and it is recommended to use the database backend and mount it as mysql. Configuration for spring.cloud.vault.mysql will be removed in a future version.

Spring Cloud Vault can obtain credentials for MySQL. The integration can be enabled by setting @@ -80,7 +80,7 @@ You can configure the property names by setting role: readonly backend: mysql username-property: spring.datasource.username - password-property: spring.datasource.username

  • enabled setting this value to true enables the MySQL backend config usage
  • role sets the role name of the MySQL role definition
  • backend sets the path of the MySQL mount to use
  • username-property sets the property name in which the MySQL username is stored
  • password-property sets the property name in which the MySQL password is stored

See also: Vault Documentation: Setting up MySQL with Vault

7.5 PostgreSQL

[Note]Note

The postgresql backend has been deprecated in Vault 0.7.1 and + password-property: spring.datasource.username

  • enabled setting this value to true enables the MySQL backend config usage
  • role sets the role name of the MySQL role definition
  • backend sets the path of the MySQL mount to use
  • username-property sets the property name in which the MySQL username is stored
  • password-property sets the property name in which the MySQL password is stored

See also: Vault Documentation: Setting up MySQL with Vault

5.5 PostgreSQL

[Note]Note

The postgresql backend has been deprecated in Vault 0.7.1 and it is recommended to use the database backend and mount it as postgresql. Configuration for spring.cloud.vault.postgresql will be removed in a future version.

Spring Cloud Vault can obtain credentials for PostgreSQL. The integration can be enabled by setting @@ -96,4 +96,4 @@ You can configure the property names by setting role: readonly backend: postgresql username-property: spring.datasource.username - password-property: spring.datasource.username

  • enabled setting this value to true enables the PostgreSQL backend config usage
  • role sets the role name of the PostgreSQL role definition
  • backend sets the path of the PostgreSQL mount to use
  • username-property sets the property name in which the PostgreSQL username is stored
  • password-property sets the property name in which the PostgreSQL password is stored

See also: Vault Documentation: Setting up PostgreSQL with Vault

Prev   Next
6. Secret Backends Home 8. Configure PropertySourceLocator behavior
\ No newline at end of file + password-property: spring.datasource.username
  • enabled setting this value to true enables the PostgreSQL backend config usage
  • role sets the role name of the PostgreSQL role definition
  • backend sets the path of the PostgreSQL mount to use
  • username-property sets the property name in which the PostgreSQL username is stored
  • password-property sets the property name in which the PostgreSQL password is stored

See also: Vault Documentation: Setting up PostgreSQL with Vault

Prev   Next
4. Secret Backends Home 6. Configure PropertySourceLocator behavior
\ No newline at end of file diff --git a/multi/multi_vault.config.backends.html b/multi/multi_vault.config.backends.html index 539e6e07..9ccc1b7a 100644 --- a/multi/multi_vault.config.backends.html +++ b/multi/multi_vault.config.backends.html @@ -1,6 +1,6 @@ - 6. Secret Backends
6. Secret Backends
Prev   Next

6. Secret Backends

6.1 Generic Backend

Spring Cloud Vault supports at the basic level the generic secret + 4. Secret Backends

4. Secret Backends
Prev   Next

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. @@ -20,7 +20,7 @@ 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
[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)

6.2 Versioned Key-Value Backend

Spring Cloud Vault supports the versioned Key-Value secret +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. @@ -40,9 +40,9 @@ 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
[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)

6.3 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 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 6.1. pom.xml

<dependencies>
+dependency.
Example 4.1. pom.xml
<dependencies>
     <dependency>
         <groupId>org.springframework.cloud</groupId>
         <artifactId>spring-cloud-vault-config-consul</artifactId>
@@ -58,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
6.4 RabbitMQ
Spring Cloud Vault can obtain credentials for RabbitMQ.
The RabbitMQ integration requires the spring-cloud-vault-config-rabbitmq
-dependency.
Example 6.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>
@@ -77,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
6.5 AWS
Spring Cloud Vault can obtain credentials for AWS.
The AWS integration requires the spring-cloud-vault-config-aws
-dependency.
Example 6.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>
@@ -96,4 +96,4 @@ by setting spring.cloud.vault.aws.access-key-property        role: readonly
         backend: aws
         access-key-property: cloud.aws.credentials.accessKey
-        secret-key-property: cloud.aws.credentials.secretKey
  • enabled setting this value to true enables the AWS backend config usage
  • role sets the role name of the AWS role definition
  • backend sets the path of the AWS mount to use
  • access-key-property sets the property name in which the AWS access key is stored
  • secret-key-property sets the property name in which the AWS secret key is stored
See also: Vault Documentation: Setting up AWS with Vault
Prev   Next
5. GCP-IAM authentication Home 7. Database backends

\ No newline at end of file
+        secret-key-property: cloud.aws.credentials.secretKey
  • enabled setting this value to true enables the AWS backend config usage
  • role sets the role name of the AWS role definition
  • backend sets the path of the AWS mount to use
  • access-key-property sets the property name in which the AWS access key is stored
  • secret-key-property sets the property name in which the AWS secret key is stored

See also: Vault Documentation: Setting up AWS with Vault

Prev   Next
3. Authentication methods Home 5. Database backends
\ No newline at end of file diff --git a/multi/multi_vault.config.fail-fast.html b/multi/multi_vault.config.fail-fast.html index 6c8984f6..6272e366 100644 --- a/multi/multi_vault.config.fail-fast.html +++ b/multi/multi_vault.config.fail-fast.html @@ -1,8 +1,8 @@ - 10. Vault Client Fail Fast
10. Vault Client Fail Fast
Prev   Next

10. Vault Client Fail Fast

In some cases, it may be desirable to fail startup of a service if + 8. Vault Client Fail Fast

8. Vault Client Fail Fast
Prev   Next

8. Vault Client Fail Fast

In some cases, it may be desirable to fail startup of a service if it cannot connect to the Vault Server. If this is the desired behavior, set the bootstrap configuration property spring.cloud.vault.fail-fast=true and the client will halt with an Exception.

spring.cloud.vault:
-    fail-fast: true
Prev   Next
9. Service Registry Configuration Home 11. Vault Client SSL configuration
\ No newline at end of file + fail-fast: true
Prev   Next
7. Service Registry Configuration Home 9. Vault Client SSL configuration
\ No newline at end of file diff --git a/multi/multi_vault.config.ssl.html b/multi/multi_vault.config.ssl.html index d1dcf0b2..b628a1b0 100644 --- a/multi/multi_vault.config.ssl.html +++ b/multi/multi_vault.config.ssl.html @@ -1,6 +1,6 @@ - 11. Vault Client SSL configuration
11. Vault Client SSL configuration
Prev   Next

11. Vault Client SSL configuration

SSL can be configured declaratively by setting various properties. + 9. Vault Client SSL configuration

9. Vault Client SSL configuration
Prev   Next

9. Vault Client SSL configuration

SSL can be configured declaratively by setting various properties. You can set either javax.net.ssl.trustStore to configure JVM-wide SSL settings or spring.cloud.vault.ssl.trust-store to set SSL settings only for Spring Cloud Vault Config.

spring.cloud.vault:
@@ -10,4 +10,4 @@ to set SSL settings only for Spring Cloud Vault Config.
trust-store-password sets the trust-store password
Please note that configuring spring.cloud.vault.ssl.* can be only
 applied when either Apache Http Components or the OkHttp client
-is on your class-path.
Prev   Next
10. Vault Client Fail Fast Home 12. Lease lifecycle management (renewal and revocation)
\ No newline at end of file +is on your class-path.

Prev   Next
8. Vault Client Fail Fast Home 10. Lease lifecycle management (renewal and revocation)
\ No newline at end of file diff --git a/single/spring-cloud-vault.html b/single/spring-cloud-vault.html index 0f6cba21..d6c28c01 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. Azure MSI authentication
3.7. TLS certificate authentication
3.8. Cubbyhole authentication
4. GCP-GCE authentication
5. GCP-IAM authentication
5.1. Kubernetes authentication
6. Secret Backends
6.1. Generic Backend
6.2. Versioned Key-Value Backend
6.3. Consul
6.4. RabbitMQ
6.5. AWS
7. Database backends
7.1. Database
7.2. Apache Cassandra
7.3. MongoDB
7.4. MySQL
7.5. PostgreSQL
8. Configure PropertySourceLocator behavior
9. Service Registry Configuration
10. Vault Client Fail Fast
11. Vault Client SSL configuration
12. 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. GCP-GCE authentication
3.10. GCP-IAM authentication
3.11. 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-2019 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 @@ -225,7 +225,7 @@ bound to a VM instance.

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 11, Vault Client SSL configuration
  2. Configure a Java Keystore that contains the 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.15. bootstrap.yml

    spring.cloud.vault:
     authentication: CERT
     ssl:
@@ -244,7 +244,7 @@ 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.17. bootstrap.yml

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

    See also:

4. GCP-GCE authentication

The gcp + token: 397ccb93-ff6c-b17b-9389-380b01ca2645


See also:

3.9 GCP-GCE authentication

The gcp auth backend allows Vault login by using existing GCP (Google Cloud Platform) IAM and GCE credentials.

GCP GCE (Google Compute Engine) authentication creates a signature in the form of a JSON Web Token (JWT) for a service account. A JWT for a Compute Engine instance is obtained from the GCE metadata service using Instance identification. @@ -253,15 +253,15 @@ does not require first-deploying, or provisioning security-sensitive credentials (tokens, username/password, client certificates, etc.). Instead, it treats GCP as a Trusted Third Party and uses the cryptographically signed dynamic metadata information that uniquely -represents each GCP service account.

Example 4.1. bootstrap.yml with required GCP-GCE Authentication properties

spring.cloud.vault:
+represents each GCP service account.
Example 3.18. bootstrap.yml with required GCP-GCE Authentication properties
spring.cloud.vault:
     authentication: GCP_GCE
     gcp-gce:
-        role: my-dev-role

Example 4.2. bootstrap.yml with all GCP-GCE Authentication properties
spring.cloud.vault:
+        role: my-dev-role

Example 3.19. bootstrap.yml with all GCP-GCE Authentication properties
spring.cloud.vault:
     authentication: GCP_GCE
     gcp-gce:
         gcp-path: gcp
         role: my-dev-role
-        service-account: my-service@projectid.iam.gserviceaccount.com

  • role sets the name of the role against which the login is being attempted.
  • gcp-path sets the path of the GCP mount to use
  • service-account allows overriding the service account Id to a specific value. Defaults to the default service account.
See also:

5. GCP-IAM authentication

The gcp + service-account: my-service@projectid.iam.gserviceaccount.com


  • role sets the name of the role against which the login is being attempted.
  • gcp-path sets the path of the GCP mount to use
  • service-account allows overriding the service account Id to a specific value. Defaults to the default service account.

See also:

3.10 GCP-IAM authentication

The gcp auth backend allows Vault login by using existing GCP (Google Cloud Platform) IAM and GCE credentials.

GCP IAM authentication creates a signature in the form of a JSON Web Token (JWT) for a service account. A JWT for a service account is obtained by calling GCP IAM’s projects.serviceAccounts.signJwt API. The caller authenticates against GCP IAM @@ -270,10 +270,10 @@ and proves thereby its identity. This Vault backend treats GCP as a Trusted Thir environment variable, the Google Compute metadata service, or supplied externally as e.g. JSON or base64 encoded. JSON is the preferred form as it carries the project id and -service account identifier required for calling projects.serviceAccounts.signJwt.

Example 5.1. bootstrap.yml with required GCP-IAM Authentication properties

spring.cloud.vault:
+service account identifier required for calling projects.serviceAccounts.signJwt.
Example 3.20. bootstrap.yml with required GCP-IAM Authentication properties
spring.cloud.vault:
     authentication: GCP_IAM
     gcp-iam:
-        role: my-dev-role

Example 5.2. bootstrap.yml with all GCP-IAM Authentication properties
spring.cloud.vault:
+        role: my-dev-role

Example 3.21. bootstrap.yml with all GCP-IAM Authentication properties
spring.cloud.vault:
     authentication: GCP_IAM
     gcp-iam:
         credentials:
@@ -287,13 +287,13 @@ service account identifier required for calling projects.s
 (com.google.apis:google-api-services-iam and com.google.auth:google-auth-library-oauth2-http)
 as the authentication implementation uses Google APIs for credentials and JWT signing.
[Note]Note
Google credentials require an OAuth 2 token maintaining the token lifecycle. All API
 is synchronous therefore, GcpIamAuthentication does not support AuthenticationSteps which is
-required for reactive usage.
See also:
5.1 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 5.3. bootstrap.yml with all Kubernetes authentication properties
spring.cloud.vault:
+required for reactive usage.

See also:

3.11 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.22. bootstrap.yml with all Kubernetes authentication properties

spring.cloud.vault:
     authentication: KUBERNETES
     kubernetes:
         role: my-dev-role
         kubernetes-path: kubernetes
-        service-account-token-file: /var/run/secrets/kubernetes.io/serviceaccount/token

  • role sets the Role.
  • kubernetes-path sets the path of the Kubernetes mount to use.
  • 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:

6. Secret Backends

6.1 Generic Backend

Spring Cloud Vault supports at the basic level the generic secret + service-account-token-file: /var/run/secrets/kubernetes.io/serviceaccount/token


  • role sets the Role.
  • kubernetes-path sets the path of the Kubernetes mount to use.
  • 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. @@ -313,7 +313,7 @@ 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
[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)

6.2 Versioned Key-Value Backend

Spring Cloud Vault supports the versioned Key-Value secret +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. @@ -333,9 +333,9 @@ 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
[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)

6.3 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 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 6.1. pom.xml

<dependencies>
+dependency.
Example 4.1. pom.xml
<dependencies>
     <dependency>
         <groupId>org.springframework.cloud</groupId>
         <artifactId>spring-cloud-vault-config-consul</artifactId>
@@ -351,8 +351,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
6.4 RabbitMQ
Spring Cloud Vault can obtain credentials for RabbitMQ.
The RabbitMQ integration requires the spring-cloud-vault-config-rabbitmq
-dependency.
Example 6.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>
@@ -370,8 +370,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
6.5 AWS
Spring Cloud Vault can obtain credentials for AWS.
The AWS integration requires the spring-cloud-vault-config-aws
-dependency.
Example 6.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>
@@ -389,16 +389,16 @@ by setting spring.cloud.vault.aws.access-key-property        role: readonly
         backend: aws
         access-key-property: cloud.aws.credentials.accessKey
-        secret-key-property: cloud.aws.credentials.secretKey
  • enabled setting this value to true enables the AWS backend config usage
  • role sets the role name of the AWS role definition
  • backend sets the path of the AWS mount to use
  • access-key-property sets the property name in which the AWS access key is stored
  • secret-key-property sets the property name in which the AWS secret key is stored
See also: Vault Documentation: Setting up AWS with Vault
7. Database backends
Vault supports several database secret backends to generate database
+        secret-key-property: cloud.aws.credentials.secretKey
  • enabled setting this value to true enables the AWS backend config usage
  • role sets the role name of the AWS role definition
  • backend sets the path of the AWS mount to use
  • access-key-property sets the property name in which the AWS access key is stored
  • secret-key-property sets the property name in which the AWS secret key is stored

See also: Vault Documentation: Setting up AWS with Vault

5. Database backends

Vault supports several database secret backends to generate database credentials dynamically based on configured roles. This means services that need to access a database no longer need to configure credentials: they can request them from Vault, and use Vault’s leasing -mechanism to more easily roll keys.

Spring Cloud Vault integrates with these backends:

Using a database secret backend requires to enable the +mechanism to more easily roll keys.

Spring Cloud Vault integrates with these backends:

Using a database secret backend requires to enable the backend in the configuration and the spring-cloud-vault-config-databases 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 7.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>
@@ -406,7 +406,7 @@ backend path, e.g. spring.cloud.vault.mysql.role.backend=d
     </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
-JDBC secrets need to be configured separately.
7.1 Database
Spring Cloud Vault can obtain credentials for any database listed at
+JDBC secrets need to be configured separately.

5.1 Database

Spring Cloud Vault can obtain credentials for any database listed at https://www.vaultproject.io/api/secret/databases/index.html. The integration can be enabled by setting spring.cloud.vault.database.enabled=true (default false) and @@ -423,7 +423,7 @@ You can configure the property names by setting role: readonly backend: database username-property: spring.datasource.username - password-property: spring.datasource.username

  • enabled setting this value to true enables the Database backend config usage
  • role sets the role name of the Database role definition
  • backend sets the path of the Database mount to use
  • username-property sets the property name in which the Database username is stored
  • password-property sets the property name in which the Database password is stored

See also: Vault Documentation: Database Secrets backend

7.2 Apache Cassandra

[Note]Note

The cassandra backend has been deprecated in Vault 0.7.1 and + password-property: spring.datasource.username

  • enabled setting this value to true enables the Database backend config usage
  • role sets the role name of the Database role definition
  • backend sets the path of the Database mount to use
  • username-property sets the property name in which the Database username is stored
  • password-property sets the property name in which the Database password is stored

See also: Vault Documentation: Database Secrets backend

5.2 Apache Cassandra

[Note]Note

The cassandra backend has been deprecated in Vault 0.7.1 and it is recommended to use the database backend and mount it as cassandra.

Spring Cloud Vault can obtain credentials for Apache Cassandra. The integration can be enabled by setting spring.cloud.vault.cassandra.enabled=true (default false) and @@ -438,7 +438,7 @@ You can configure the property names by setting role: readonly backend: cassandra username-property: spring.data.cassandra.username - password-property: spring.data.cassandra.username

  • enabled setting this value to true enables the Cassandra backend config usage
  • role sets the role name of the Cassandra role definition
  • backend sets the path of the Cassandra mount to use
  • username-property sets the property name in which the Cassandra username is stored
  • password-property sets the property name in which the Cassandra password is stored

See also: Vault Documentation: Setting up Apache Cassandra with Vault

7.3 MongoDB

[Note]Note

The mongodb backend has been deprecated in Vault 0.7.1 and + password-property: spring.data.cassandra.username

  • enabled setting this value to true enables the Cassandra backend config usage
  • role sets the role name of the Cassandra role definition
  • backend sets the path of the Cassandra mount to use
  • username-property sets the property name in which the Cassandra username is stored
  • password-property sets the property name in which the Cassandra password is stored

See also: Vault Documentation: Setting up Apache Cassandra with Vault

5.3 MongoDB

[Note]Note

The mongodb backend has been deprecated in Vault 0.7.1 and it is recommended to use the database backend and mount it as mongodb.

Spring Cloud Vault can obtain credentials for MongoDB. The integration can be enabled by setting spring.cloud.vault.mongodb.enabled=true (default false) and @@ -453,7 +453,7 @@ You can configure the property names by setting role: readonly backend: mongodb username-property: spring.data.mongodb.username - password-property: spring.data.mongodb.password

  • enabled setting this value to true enables the MongodB backend config usage
  • role sets the role name of the MongoDB role definition
  • backend sets the path of the MongoDB mount to use
  • username-property sets the property name in which the MongoDB username is stored
  • password-property sets the property name in which the MongoDB password is stored

See also: Vault Documentation: Setting up MongoDB with Vault

7.4 MySQL

[Note]Note

The mysql backend has been deprecated in Vault 0.7.1 and + password-property: spring.data.mongodb.password

  • enabled setting this value to true enables the MongodB backend config usage
  • role sets the role name of the MongoDB role definition
  • backend sets the path of the MongoDB mount to use
  • username-property sets the property name in which the MongoDB username is stored
  • password-property sets the property name in which the MongoDB password is stored

See also: Vault Documentation: Setting up MongoDB with Vault

5.4 MySQL

[Note]Note

The mysql backend has been deprecated in Vault 0.7.1 and it is recommended to use the database backend and mount it as mysql. Configuration for spring.cloud.vault.mysql will be removed in a future version.

Spring Cloud Vault can obtain credentials for MySQL. The integration can be enabled by setting @@ -469,7 +469,7 @@ You can configure the property names by setting role: readonly backend: mysql username-property: spring.datasource.username - password-property: spring.datasource.username

  • enabled setting this value to true enables the MySQL backend config usage
  • role sets the role name of the MySQL role definition
  • backend sets the path of the MySQL mount to use
  • username-property sets the property name in which the MySQL username is stored
  • password-property sets the property name in which the MySQL password is stored

See also: Vault Documentation: Setting up MySQL with Vault

7.5 PostgreSQL

[Note]Note

The postgresql backend has been deprecated in Vault 0.7.1 and + password-property: spring.datasource.username

  • enabled setting this value to true enables the MySQL backend config usage
  • role sets the role name of the MySQL role definition
  • backend sets the path of the MySQL mount to use
  • username-property sets the property name in which the MySQL username is stored
  • password-property sets the property name in which the MySQL password is stored

See also: Vault Documentation: Setting up MySQL with Vault

5.5 PostgreSQL

[Note]Note

The postgresql backend has been deprecated in Vault 0.7.1 and it is recommended to use the database backend and mount it as postgresql. Configuration for spring.cloud.vault.postgresql will be removed in a future version.

Spring Cloud Vault can obtain credentials for PostgreSQL. The integration can be enabled by setting @@ -485,7 +485,7 @@ You can configure the property names by setting role: readonly backend: postgresql username-property: spring.datasource.username - password-property: spring.datasource.username

  • enabled setting this value to true enables the PostgreSQL backend config usage
  • role sets the role name of the PostgreSQL role definition
  • backend sets the path of the PostgreSQL mount to use
  • username-property sets the property name in which the PostgreSQL username is stored
  • password-property sets the property name in which the PostgreSQL password is stored

See also: Vault Documentation: Setting up PostgreSQL with Vault

8. Configure PropertySourceLocator behavior

Spring Cloud Vault uses property-based configuration to create PropertySources + password-property: spring.datasource.username

  • enabled setting this value to true enables the PostgreSQL backend config usage
  • role sets the role name of the PostgreSQL role definition
  • backend sets the path of the PostgreSQL mount to use
  • username-property sets the property name in which the PostgreSQL username is stored
  • password-property sets the property name in which the PostgreSQL password is stored

See also: Vault Documentation: Setting up PostgreSQL with Vault

6. Configure PropertySourceLocator behavior

Spring Cloud Vault uses property-based configuration to create PropertySources for generic and discovered secret backends.

Discovered backends provide VaultSecretBackendDescriptor beans to describe the configuration state to use secret backend as PropertySource. A SecretBackendMetadataFactory is required to create a SecretBackendMetadata object which contains path, name and property transformation @@ -504,7 +504,7 @@ at least one VaultConfigurer bean. You can however } }

[Note]Note

All customization is required to happen in the bootstrap context. Add your configuration classes to META-INF/spring.factories at org.springframework.cloud.bootstrap.BootstrapConfiguration -in your application.

9. Service Registry Configuration

You can use a DiscoveryClient (such as from Spring Cloud Consul) to locate +in your application.

7. Service Registry Configuration

You can use a DiscoveryClient (such as from Spring Cloud Consul) to locate a Vault server by setting spring.cloud.vault.discovery.enabled=true (default false). The net result of that is that your apps need a bootstrap.yml (or an environment variable) with the appropriate discovery configuration. @@ -518,12 +518,12 @@ need to provide a scheme metadata entry to be set e If no scheme is configured and the service is not exposed as secure service, then configuration defaults to spring.cloud.vault.scheme which is https when it’s not set.

spring.cloud.vault.discovery:
     enabled: true
-    service-id: my-vault-service

10. Vault Client Fail Fast

In some cases, it may be desirable to fail startup of a service if + service-id: my-vault-service

8. Vault Client Fail Fast

In some cases, it may be desirable to fail startup of a service if it cannot connect to the Vault Server. If this is the desired behavior, set the bootstrap configuration property spring.cloud.vault.fail-fast=true and the client will halt with an Exception.

spring.cloud.vault:
-    fail-fast: true

11. Vault Client SSL configuration

SSL can be configured declaratively by setting various properties. + fail-fast: true

9. Vault Client SSL configuration

SSL can be configured declaratively by setting various properties. You can set either javax.net.ssl.trustStore to configure JVM-wide SSL settings or spring.cloud.vault.ssl.trust-store to set SSL settings only for Spring Cloud Vault Config.

spring.cloud.vault:
@@ -533,7 +533,7 @@ to set SSL settings only for Spring Cloud Vault Config.
trust-store-password sets the trust-store password
Please note that configuring spring.cloud.vault.ssl.* can be only
 applied when either Apache Http Components or the OkHttp client
-is on your class-path.

12. Lease lifecycle management (renewal and revocation)

With every secret, Vault creates a lease: +is on your class-path.

10. Lease lifecycle management (renewal and revocation)

With every secret, Vault creates a lease: metadata containing information such as a time duration, renewability, and more.

Vault promises that the data will be valid for the given duration, or Time To Live (TTL). Once the lease is expired, Vault can