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.
Tokens are the core method for authentication within Vault. Token authentication requires a static token to be provided using the Bootstrap Application Context.
![]() | Note |
|---|---|
Token authentication is the default authentication method. If a token is disclosed an unintended party gains access to Vault and can access secrets for the intended client. |
Example 94.1. bootstrap.yml
spring.cloud.vault: authentication: TOKEN token: 00000000-0000-0000-0000-000000000000
authentication setting this value to TOKEN selects the Token
authentication methodtoken sets the static token to useSee also: Vault Documentation: Tokens
Vault supports AppId
authentication that consists of two hard to guess tokens. The AppId
defaults to spring.application.name that is statically configured.
The second token is the UserId which is a part determined by the application,
usually related to the runtime environment. IP address, Mac address or a
Docker container name are good examples. Spring Cloud Vault Config supports
IP address, Mac address and static UserId’s (e.g. supplied via System properties).
The IP and Mac address are represented as Hex-encoded SHA256 hash.
IP address-based UserId’s use the local host’s IP address.
Example 94.2. bootstrap.yml using SHA256 IP-Address UserId’s
spring.cloud.vault: authentication: APPID app-id: user-id: IP_ADDRESS
authentication setting this value to APPID selects the AppId
authentication methodapp-id-path sets the path of the AppId mount to useuser-id sets the UserId method. Possible values are IP_ADDRESS,
MAC_ADDRESS or a class name implementing a custom AppIdUserIdMechanismThe corresponding command to generate the IP address UserId from a command line is:
$ echo -n 192.168.99.1 | sha256sum
![]() | Note |
|---|---|
Including the line break of |
Mac address-based UserId’s obtain their network device from the
localhost-bound device. The configuration also allows specifying
a network-interface hint to pick the right device. The value of
network-interface is optional and can be either an interface
name or interface index (0-based).
Example 94.3. bootstrap.yml using SHA256 Mac-Address UserId’s
spring.cloud.vault: authentication: APPID app-id: user-id: MAC_ADDRESS network-interface: eth0
network-interface sets network interface to obtain the physical addressThe corresponding command to generate the IP address UserId from a command line is:
$ echo -n 0AFEDE1234AC | sha256sum
![]() | Note |
|---|---|
The Mac address is specified uppercase and without colons.
Including the line break of |
The UserId generation is an open mechanism. You can set
spring.cloud.vault.app-id.user-id to any string and the configured
value will be used as static UserId.
A more advanced approach lets you set spring.cloud.vault.app-id.user-id to a
classname. This class must be on your classpath and must implement
the org.springframework.cloud.vault.AppIdUserIdMechanism interface
and the createUserId method. Spring Cloud Vault will obtain the UserId
by calling createUserId each time it authenticates using AppId to
obtain a token.
Example 94.4. bootstrap.yml
spring.cloud.vault: authentication: APPID app-id: user-id: com.examlple.MyUserIdMechanism
Example 94.5. MyUserIdMechanism.java
public class MyUserIdMechanism implements AppIdUserIdMechanism { @Override public String createUserId() { String userId = ... return userId; } }
See also: Vault Documentation: Using the App ID auth backend
AppRole is intended for machine authentication, like the deprecated (since Vault 0.6.1) Section 94.2, “AppId authentication”. AppRole authentication consists of two hard to guess (secret) tokens: RoleId and SecretId.
Spring Vault supports AppRole authentication by providing either RoleId only or together with a provided SecretId (push or pull mode).
RoleId and optionally SecretId must be provided by configuration, Spring Vault will not look up these or create a custom SecretId.
Example 94.6. bootstrap.yml with AppRole authentication properties
spring.cloud.vault: authentication: APPROLE app-role: role-id: bde2076b-cccb-3cf0-d57e-bca7b1e83a52
role-id sets the RoleId.Example 94.7. bootstrap.yml with all AppRole authentication properties
spring.cloud.vault: authentication: APPROLE app-role: role-id: bde2076b-cccb-3cf0-d57e-bca7b1e83a52 secret-id: 1696536f-1976-73b1-b241-0b4213908d39 app-auth-path: approle
role-id sets the RoleId.secret-id sets the SecretId. SecretId can be omitted if AppRole is configured without requiring SecretId (See bind_secret_id)approle-path sets the path of the approle authentication mount to useSee also: Vault Documentation: Using the AppRole auth backend
The aws-ec2 auth backend provides a secure introduction mechanism for AWS EC2 instances, allowing automated retrieval of a Vault token. Unlike most Vault authentication backends, this backend does not require first-deploying, or provisioning security-sensitive credentials (tokens, username/password, client certificates, etc.). Instead, it treats AWS as a Trusted Third Party and uses the cryptographically signed dynamic metadata information that uniquely represents each EC2 instance.
AWS-EC2 authentication enables nonce by default to follow the Trust On First Use (TOFU) principle. Any unintended party that gains access to the PKCS#7 identity metadata can authenticate against Vault.
During the first login, Spring Cloud Vault generates a nonce that is stored in the auth backend aside the instance Id. Re-authentication requires the same nonce to be sent. Any other party does not have the nonce and can raise an alert in Vault for further investigation.
The nonce is kept in memory and is lost during application restart.
You can configure a static nonce with spring.cloud.vault.aws-ec2.nonce.
AWS-EC2 authentication roles are optional and default to the AMI.
You can configure the authentication role by setting the
spring.cloud.vault.aws-ec2.role property.
Example 94.9. bootstrap.yml with configured role
spring.cloud.vault: authentication: AWS_EC2 aws-ec2: role: application-server
Example 94.10. bootstrap.yml with all AWS EC2 authentication properties
spring.cloud.vault: authentication: AWS_EC2 aws-ec2: role: application-server aws-ec2-path: aws-ec2 identity-document: http://... nonce: my-static-nonce
authentication setting this value to AWS_EC2 selects the AWS EC2
authentication methodrole sets the role name of the AWS EC2 role definitionaws-ec2-path sets the path of the AWS EC2 mount to useidentity-document sets URL of the PKCS#7 AWS EC2 identity documentnonce used for AWS-EC2 authentication. An empty nonce defaults to nonce generationSee also: Vault Documentation: Using the aws-ec2 auth backend
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:
Keystore that contains the client
certificate and the private keyspring.cloud.vault.authentication to CERTExample 94.11. bootstrap.yml
spring.cloud.vault: authentication: CERT ssl: key-store: classpath:keystore.jks key-store-password: changeit cert-auth-path: cert
Cubbyhole authentication uses Vault primitives to provide a secured authentication
workflow. Cubbyhole authentication uses tokens as primary login method.
An ephemeral token is used to obtain a second, login VaultToken from Vault’s
Cubbyhole secret backend. The login token is usually longer-lived and used to
interact with Vault. The login token will be retrieved from a wrapped
response stored at /cubbyhole/response.
Creating a wrapped token
![]() | Note |
|---|---|
Response Wrapping for token creation requires Vault 0.6.0 or higher. |
Example 94.12. Crating and storing tokens
$ vault token-create -wrap-ttl="10m" Key Value --- ----- wrapping_token: 397ccb93-ff6c-b17b-9389-380b01ca2645 wrapping_token_ttl: 0h10m0s wrapping_token_creation_time: 2016-09-18 20:29:48.652957077 +0200 CEST wrapped_accessor: 46b6aebb-187f-932a-26d7-4f3d86a68319
Example 94.13. bootstrap.yml
spring.cloud.vault: authentication: CUBBYHOLE token: 397ccb93-ff6c-b17b-9389-380b01ca2645
See also: