7. Secret Backends
7.1. Key-Value Backend
Spring Cloud Vault supports both Key-Value secret backends, the versioned (v2) and unversioned (v1).
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 determines itself whether a secret is using versioning and maps the path to its appropriate URL.
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
The profiles are determined by the properties:
-
spring.cloud.vault.kv.profiles
-
spring.profiles.active
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).
Spring Cloud Vault adds the data/ context between the mount path and the actual context path depending on whether the mount uses the versioned key-value backend.
|
spring.cloud.vault:
kv:
enabled: true
backend: secret
profile-separator: '/'
default-context: application
application-name: my-app
profiles: local, cloud
-
enabled
setting this value tofalse
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 key-value backend -
profiles
overrides the active profiles for use in the key-value backend -
profile-separator
separates the profile name from the context in property sources with profiles
The key-value secret backend can be operated in versioned (v2) and non-versioned (v1) modes. |
See also:
7.2. Consul
Spring Cloud Vault can obtain credentials for HashiCorp Consul.
The Consul integration requires the spring-cloud-vault-config-consul
dependency.
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-vault-config-consul</artifactId>
<version>3.1.3</version>
</dependency>
</dependencies>
The integration can be enabled by setting
spring.cloud.vault.consul.enabled=true
(default false
) and providing the role name with spring.cloud.vault.consul.role=…
.
The obtained token is stored in spring.cloud.consul.token
so using Spring Cloud Consul can pick up the generated credentials without further configuration.
You can configure the property name by setting spring.cloud.vault.consul.token-property
.
spring.cloud.vault:
consul:
enabled: true
role: readonly
backend: consul
token-property: spring.cloud.consul.token
-
enabled
setting this value totrue
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
7.3. RabbitMQ
Spring Cloud Vault can obtain credentials for RabbitMQ.
The RabbitMQ integration requires the spring-cloud-vault-config-rabbitmq
dependency.
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-vault-config-rabbitmq</artifactId>
<version>3.1.3</version>
</dependency>
</dependencies>
The integration can be enabled by setting
spring.cloud.vault.rabbitmq.enabled=true
(default false
) and providing the role name with spring.cloud.vault.rabbitmq.role=…
.
Username and password are stored in spring.rabbitmq.username
and spring.rabbitmq.password
so using Spring Boot will pick up the generated credentials without further configuration.
You can configure the property names by setting spring.cloud.vault.rabbitmq.username-property
and
spring.cloud.vault.rabbitmq.password-property
.
spring.cloud.vault:
rabbitmq:
enabled: true
role: readonly
backend: rabbitmq
username-property: spring.rabbitmq.username
password-property: spring.rabbitmq.password
-
enabled
setting this value totrue
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
7.4. AWS
Spring Cloud Vault can obtain credentials for AWS.
The AWS integration requires the spring-cloud-vault-config-aws
dependency.
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-vault-config-aws</artifactId>
<version>3.1.3</version>
</dependency>
</dependencies>
The integration can be enabled by setting
spring.cloud.vault.aws=true
(default false
) and providing the role name with spring.cloud.vault.aws.role=…
.
Supported AWS credential Types:
-
iam_user (Defaults)
-
assumed_role (STS)
-
federation_token (STS)
The access key and secret key are stored in cloud.aws.credentials.accessKey
and cloud.aws.credentials.secretKey
. So using Spring Cloud AWS will pick up the generated credentials without further configuration.
You can configure the property names by setting spring.cloud.vault.aws.access-key-property
and
spring.cloud.vault.aws.secret-key-property
.
For STS security token, you can configure the property name by setting spring.cloud.vault.aws.session-token-key-property
. The security token is stored under cloud.aws.credentials.sessionToken
(defaults).
Example: iam_user
spring.cloud.vault:
aws:
enabled: true
role: readonly
backend: aws
access-key-property: cloud.aws.credentials.accessKey
secret-key-property: cloud.aws.credentials.secretKey
Example: assumed_role (STS)
spring.cloud.vault:
aws:
enabled: true
role: sts-vault-role
backend: aws
credential-type: assumed_role
access-key-property: cloud.aws.credentials.accessKey
secret-key-property: cloud.aws.credentials.secretKey
session-token-key-property: cloud.aws.credentials.sessionToken
ttl: 3600s
role-arn: arn:aws:iam::${AWS_ACCOUNT}:role/sts-app-role
-
enabled
setting this value totrue
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 -
session-token-key-property
sets the property name in which the AWS STS security token is stored. -
credential-type
sets the aws credential type to use for this backend. Defaults toiam_user
-
ttl
sets the ttl for the STS token when usingassumed_role
orfederation_token
. Defaults to the ttl specified by the vault role. Min/Max values are also limited to what AWS would support for STS. -
role-arn
sets the IAM role to assume if more than one are configured for the vault role when usingassumed_role
.