Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hashicorp Vault Token Renewal Initialization Failure #4508

Open
drcgjung opened this issue Sep 27, 2024 · 0 comments
Open

Hashicorp Vault Token Renewal Initialization Failure #4508

drcgjung opened this issue Sep 27, 2024 · 0 comments
Labels
triage all new issues awaiting classification

Comments

@drcgjung
Copy link
Contributor

Bug Report

Describe the Bug

Starting TX EDC 0.8.0-RC3 in a local environment (based on EDC 0.10.0-20240918-SNAPSHOT, hence main) outputs a hashicorp vault warning both in control-plane and data-plane images when using a static EDC_VAULT_HASHICORP_TOKEN from the environment

Expected Behavior

No Warning, token refresh should work.

Observed Behavior

WARNING 2024-09-27T14:06:12.663937303 [Hashicorp Vault] Initial token look up failed with reason: Failed to look up token with reason: Unexpected character ('<' (code 60)): expected a valid value (JSON String, Number, Array, Object or token 'null', 'true' or 'false') at [Source: REDACTED (StreamReadFeature.INCLUDE_SOURCE_IN_LOCATION disabled); line: 1, column: 1]

Since the initial token lookup failed, the guess is that also the refresh does not work.

Steps to Reproduce

Steps to reproduce the behavior:

  1. Run a local vault with a preconfigured token
  2. configure a tractus-x image (also tested with TX EDC 0.7.4 --> EDC 0.7.2 - same problem) against the vault using that token in EDC_VAULT_HASHICORP_TOKEN
  3. start the image and log at the log

Context Information

  • EDC main/0.10.0-20240918-SNAPSHOT inside of TX EDC 0.8.0-RC3
  • hashicorp/vault:latest as the vault implementation
  • OS: MacOS, Orbstack with linux/amd64 rosetta emulation

Detailed Description

The culprit seems to lie in the HashiCorpVaultClient#isTokenRenewable method

especially when compared to the renewToken implementation

The TOKEN_LOOK_UP_SELF_PATH is encoded as "v1%2Fauth%2Ftoken%2Flookup-self" and appended to the vault url.
A call is then made to (local cluster sample) "http://vault:8201/v1%2Fauth%2Ftoken%2Flookup-self". The default hashicorp/vault:latest image answers with "200 OK" from a redirection to "http://vault:8201/ui" and the content will be html, not the expected json response (which shows the seen parsing error/warning).

Possible Implementation

Instead of

        var uri = settings.url()
                .newBuilder()
                .addPathSegment(TOKEN_LOOK_UP_SELF_PATH)
                .build();

it rather should be

        var uri = settings.url()
                .newBuilder()
                .addPathSegments(TOKEN_LOOK_UP_SELF_PATH)
                .build();

to split the TOKEN_LOOK_UP_SELF_PATH before encoding only the remaining individual segments and not encoding the TOKEN_LOOK_UP_SELF_PATH as a whole.

@github-actions github-actions bot added the triage all new issues awaiting classification label Sep 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triage all new issues awaiting classification
Projects
None yet
Development

No branches or pull requests

1 participant