Kubernetes auth method for Hashicorp Vault

[saschaisele-zf]

Kubernetes auth method for Hashicorp Vault

This proposal aims to introduce the Kubernetes auth method (based on the Kubernetes Service Account token) to the Hashicorp Vault extension of the EDC.

Use-Case

Easy Provisioning

The authentication through a Kubernetes Service Account enables easy and automatic provisioning of new applications/services/components.
Components and their Service accounts will automatically receive certain roles and policies within Hashicorp Vault.
In this way, no manual configuration like token creation is needed any longer.

Easy Administration

Using the Kubernetes auth method, it is possible to do authentication exclusively through Kubernetes and you no longer have to interact with Hashicorp Vault, once the initial setup is complete.
This means that there no longer is any need to create and manage a token in Hashicorp Vault for each Component that uses it.
A Kubernetes Service account will suffice instead.

Affected Areas

Hashicorp Vault extension

Solution Proposal

Refactoring

To enable the addition of an alternative authentication mechanism, first the existing Token authentication has to be refactored.
For this, the authentication functionality is removed from the HashicorpVaultClient.java class.
A new interface called HashicorpVaultAuth.java is introduced, which will be the base for the authentication specific implementations.
The interface is then implemented in the classes HashicorpVaultAuthToken.java and HashicorpVaultAuthKubernetes.java.

Kubernetes auth method

The Kubernetes auth method is done with the help of the Hashicorp Vault API.
An HTTP request is built and then sent to the API for authentication.

Configuration and selection of Authentication

The already existing Configuration in HashicorpVaultSettings.java is extended.
A new setting called edc.vault.hashicorp.auth.method is introduced, which governs the selection of the authentication method.
By default, the existing token authentication is used to avoid breaking changes.

[jimmarino]

@saschaisele-zf Can you please provide a Decision Record specifically covering the changes first? To clarify, prior to the PR once the discussion resolves.

[saschaisele-zf]

Since this is a bigger change, a decision record would be sensible, yes.

[paullatzelsperger]

IMO this decision record should also outline an approach how to test this

[florianrusch-zf]

Would it be enough for you to describe how to test it, or do we need an automatic integration test for it? Because this would require some more efforts as we would need a k8s runtime.

[jimmarino]

Any such feature would need both unit and integration testing. My concern is achieving this in a lightweight and reliable fashion.

[paullatzelsperger]

to make it clear: yes, this absolutely has to be integration-tested. How else would we guard against regression, e.g. a changing Kubernetes API? If you're not already doing this, then you have some tech-debt to catch up on.

The decision-record obviously does not have to already bring the implementation of the test, but it should outline a plan.

An implementation PR will not survive without proper testing.

[florianrusch-zf]

FYI: we are already using this feature in our ZF EDCs for almost one year without any problems. Therefore, we are also able to provide the implementation quite fast. 😉

[paullatzelsperger]

#4375 (reply in thread)

to gauge whether the proposed implementation fits well with EDC paradigms, a decision-record is in required, at least for substantial changes.

[nitin-vavdiya]

Hi
Are there any plans to include this implementation in the upcoming release?
Ref: #4419