Skip to content

Commit

Permalink
docs: add decision record for HashiCorp vault authentication refactor…
Browse files Browse the repository at this point in the history
…ing (#4802)

Co-authored-by: Sascha Isele <[email protected]>
  • Loading branch information
ronjaquensel and SaschaIsele authored Feb 10, 2025
1 parent a17d4ab commit c726579
Show file tree
Hide file tree
Showing 2 changed files with 81 additions and 0 deletions.
Original file line number Diff line number Diff line change
@@ -0,0 +1,80 @@
# HashiCorp Vault authentication refactor

## Decision

We will refactor the HashiCorp Vault implementation to support the usage of different methods of authentication.

## Rationale

The HashiCorp Vault supports multiple different authentication methods, but the current implementation supports
only one and provides no way to customize or exchange authentication methods. The full list of supported
methods can be found in the [HashiCorp Vault Documentation](https://developer.hashicorp.com/vault/docs/auth). Some examples are:

* [Token auth method](https://developer.hashicorp.com/vault/docs/auth/token) (already supported)
* [Kubernetes auth method](https://developer.hashicorp.com/vault/docs/auth/kubernetes)
* [AppRole auth method](https://developer.hashicorp.com/vault/docs/auth/approle)

## Approach

The refactoring will be limited to the `vault-hashicorp` module.

The common denominator among all authentication methods is the ability to provide a `client_token` for
authentication against the vault. Therefore, obtaining this token will be moved to an interface.

```java
@ExtensionPoint
public interface HashicorpVaultTokenProvider {
String vaultToken();
}
```

This interface will be the extension point for downstream projects to introduce different authentication methods by
providing a respective implementation of this interface to the runtime context.
The [token auth method](https://developer.hashicorp.com/vault/docs/auth/token) is already supported by the current implementation and will remain the default
implementation provided through the `HashicorpVaultExtension`.
The respective code will therefore be moved to a class implementing `HashicorpVaultTokenProvider`.

### Services accessing the vault

Any service that needs to access the vault will be refactored to use the `HashicorpVaultTokenProvider` for obtaining
the token. Namely, affected services are:

* `HashicorpVault` (secure key-value store)
* `HashicorpVaultSignatureService` (signing service)
* `HashicorpVaultHealthService` (health check service)

All of these services currently get the token from the `HashicorpVaultSettings`, which will be replaced by a call to
the `HashicorpVaultTokenProvider`.

### HashicorpVaultHealthService

In addition, the `HashicorpVaultHealthService` currently stores the headers for all requests to the vault in a
class variable, which is populated once upon service instantiation. As the token, and thus the headers,
may not be static for all authentication methods, the variable will be removed. Instead, the token will be fetched from
the `HashicorpVaultTokenProvider` and the headers will be generated for every request. The token will therefore be
added as a parameter to the `getHeaders` method.

```java
@NotNull
private Headers getHeaders(String token) {
var headersBuilder = new Headers.Builder().add(VAULT_REQUEST_HEADER, Boolean.toString(true));
headersBuilder.add(VAULT_TOKEN_HEADER, token);
return headersBuilder.build();
}
```

The `HashicorpVaultHealthService` also provides methods for checking whether a token can be renewed as well as for
renewing the token. As these features are not available for all authentication methods, this functionality should be
moved to a different class. This part of the refactoring is already planned anyway for better separation of concerns.

### HashicorpVaultHealthCheck

The `get()` method of `HashicorpVaultHealthCheck` currently returns a merged result, using the response from the
health API and the response to whether the current token can be renewed. After the refactor, it is no longer
guaranteed that token renewal is supported. The second check will therefore be removed from the method, which
then simply returns the result of the health check.

## Further Considerations

This decision record only paves the way to add additional authentication methods in the future. The actual support and
implementation of any additional authentication methods is therefore out of scope of this decision record.
1 change: 1 addition & 0 deletions docs/developer/decision-records/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -73,3 +73,4 @@
- [2025-01-28 Async Protocol Message Process](./2025-01-28-async-protocol-message-processing)
- [2025-02-05 State Machine Retry Processor refactor](./2025-02-05-state-machine-retry-processor-refactor)
- [2025-02-06 Object mutability and copying](./2025-02-06-object_mutability_and_copying)
- [2025-02-06 HashiCorp Vault Authentication Refactor](./2025-02-06-hashicorp-vault-authentication-refactor)

0 comments on commit c726579

Please sign in to comment.