Hashicorp Vault folder configuration

[saschaisele-zf]

Hashicorp Vault folder configuration

This proposal aims to introduce the possibility to configure dedicated folders inside Hashicorp Vault as secret storage.

Use-Case

Administration

Having the option to sort the relevant secrets for multiple EDC instances in folders, enables an orderly structure inside Hashicorp Vault.

In this way, administration is made easier and less frustrating.

Security

If you are using multiple instances of the EDC and/or other applications/services/components together with a single Hashicorp Vault instance, it is undesirable to have all the secrets accessible to everyone.

With the possibility to configure a folder for each EDC, every instance of the EDC can be separated in what secrets it can access.

This increases security.

Affected Areas

Hashicorp Vault extension

Solution Proposal

Introduce the optional configuration value edc.vault.hashicorp.folder.

If this value is set, the method getSecretUrl inside HashicorpVaultClient.java adds the folder to the URL that is generated.

With this, all operations will happen in the files of the folder instead.

[paullatzelsperger]

could we just re-use edc.vault.hashicorp.api.secret.path? by default that is /v1/secrets, but it sounds like folders could just be appended to that.

With the possibility to configure a folder for each EDC, every instance of the EDC can be separated in what secrets it can access.

this only increases security if the individual tokens are constrained to their respective paths ofc.

[saschaisele-zf]

The problem with using the edc.vault.hashicorp.api.secret.path is that the folder path would then be before the entry type (data/metadata).

[paullatzelsperger]

not exactly sure what you mean tbh. could you give an example?

[saschaisele-zf]

It is about how the path is built in getSecretUrl, namely in the builder of the return value.

  private HttpUrl getSecretUrl(String key, String entryType) {
      key = URLEncoder.encode(key, StandardCharsets.UTF_8);

      // restore '/' characters to allow subdirectories
      key = key.replace("%2F", "/");

      var vaultApiPath = settings.secretPath();

      return settings.url()
              .newBuilder()
              .addPathSegments(PathUtil.trimLeadingOrEndingSlash(vaultApiPath))
              .addPathSegment(entryType)
              .addPathSegments(key)
              .build();
  }

Appending the folder in edc.vault.hashicorp.api.secret.path will lead to it getting appended before .addPathSegment(entryType).

While the desired implementation would look something like this.

  private HttpUrl getSecretUrl(String key, String entryType) {
      key = URLEncoder.encode(key, StandardCharsets.UTF_8);

      // restore '/' characters to allow subdirectories
      key = key.replace("%2F", "/");

      var vaultApiPath = settings.secretPath();

      return settings.url()
              .newBuilder()
              .addPathSegments(PathUtil.trimLeadingOrEndingSlash(vaultApiPath))
              .addPathSegment(entryType)
              .addPathSegments(PathUtil.trimLeadingOrEndingSlash(secretFolderPath))
              .addPathSegments(key)
              .build();
  }

The desired path structure is:

<api-base-url>/<entry-type>/<path-2-secret>
- api-base-url: /v1/secrets
- entry-type: data or metadata
- path-2-secret: some-folder/other-folder/my-secret

[paullatzelsperger]

ah i see what you mean. so the path would be /v1/secret/some/custom/folder/metadata (incorrect) instead of /v1/secret/data/some/custom/folder (correct) right?

[saschaisele-zf]

yes, correct

[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]

its not about implementation speed, its not even about whether we want this feature or not (i think we do), its about how to best implement it.

[florianrusch-zf]

I'm totally with you 😉 Just wanted to mention it because @saschaisele-zf had forgotten. Of course, we'll make sure to coordinate the changes first and follow the contribution guidelines! I just wanted to let you know, that we already have a base, so we don't have to start from scratch. We're also happy to adapt the existing code according to the requirements so that it suits everyone 😉

I just wanted to make it clear that this is more of a contribution than just a simple feature request. 🙂