Vault login ommited and going straight to test

[lcx]

Bug Description

I have been playing with hashicorp vault in the past weeks and had no idea why I currently kept getting error 400 when trying to connect to the vault even though using curl has no issues.
I am using AppRole login and checking the nginx logfile of the hashicorp server showed me only a GET to /v1/auth/token/lookup-self without the prior login using POST /v1/auth/approle/login

To better understand what is going on I added some debug lines in the vault.js and injected that into the docker container and logs confirmed that test() is called directly before doConnect() in packages/cli/src/modules/external-secrets.ee/providers/vault.ts

Switch from appRole to Token login also resulted with the same issue that the test() -> GET to /v1/auth/token/lookup-self is called without an prior authentication resulting in an empty currentToken.

To Reproduce

Good question. I would have to retry to set up the whole thing from scratch. Get it running with hashicorp, bring the whole thing somehow in an error state, edit the cofinguration again with knowing working data and it should trigger the error.

Expected behavior

Changes to the credentials for the vault should first try a reconnect.

Debug Info

I (or rather Claude) added a small workaround in test to trigger the reconnect if the currentToken is not set.
This solved the issue finally, test was triggered (before doConnect) due to the empty currentToken.
I replaced the test() in this file: https://github.com/n8n-io/n8n/blob/master/packages/cli/src/modules/external-secrets.ee/providers/vault.ts

The resulting JS looks like this:

async test() {
        this.logger.debug('[Test Debug] test() called');
        
        // If no token is set, we need to authenticate first
        if (!__classPrivateFieldGet(this, _VaultProvider_currentToken, "f")) {
            this.logger.debug('[Test Debug] No token set, attempting authentication');
            if (this.settings.authMethod === 'token') {
                __classPrivateFieldSet(this, _VaultProvider_currentToken, this.settings.token, "f");
            } else if (this.settings.authMethod === 'usernameAndPassword') {
                __classPrivateFieldSet(this, _VaultProvider_currentToken, await this.authUsernameAndPassword(this.settings.username, this.settings.password), "f");
            } else if (this.settings.authMethod === 'appRole') {
                __classPrivateFieldSet(this, _VaultProvider_currentToken, await this.authAppRole(this.settings.roleId, this.settings.secretId), "f");
            }
            if (!__classPrivateFieldGet(this, _VaultProvider_currentToken, "f")) {
                return [false, 'Authentication failed'];
            }
        }
        
        try {
            const [token, tokenResp] = await this.getTokenInfo();
            if (token === null) {
                this.logger.debug(`[Test Debug] Token is null, response status: ${tokenResp.status}`);
                if (tokenResp.status === 404) {
                    return [false, 'Could not find auth path. Try adding /v1/ to the end of your base URL.'];
                }
                return [false, 'Invalid credentials'];
            }
            const resp = await __classPrivateFieldGet(this, _VaultProvider_http, "f").request({
                method: 'GET',
                url: 'sys/mounts',
                responseType: 'json',
                validateStatus: () => true,
            });
            if (resp.status === 403) {
                return [
                    false,
                    "Couldn't list mounts. Please give these credentials 'read' access to sys/mounts.",
                ];
            }
            else if (resp.status !== 200) {
                return [
                    false,
                    "Couldn't list mounts but wasn't a permissions issue. Please consult your Vault admin.",
                ];
            }
            return [true];
        }
        catch (e) {
            this.logger.error(`[Test Debug] Exception caught: ${e}`);
            if (axios_1.default.isAxiosError(e)) {
                this.logger.error(`[Test Debug] Axios error - code: ${e.code}, message: ${e.message}`);
                if (e.code === 'ECONNREFUSED') {
                    return [
                        false,
                        'Connection refused. Please check the host and port of the server are correct.',
                    ];
                }
            }
            return [false];
        }
    }

after a successful connect it continues to work even when the workaround is removed.

this should be the workaround to the .ts file.

async test(): Promise<[boolean] | [boolean, string]> {
  // If no token is set, we need to authenticate first
  if (!this.#currentToken) {
    if (this.settings.authMethod === 'token') {
      this.#currentToken = this.settings.token;
    } else if (this.settings.authMethod === 'usernameAndPassword') {
      this.#currentToken = await this.authUsernameAndPassword(
        this.settings.username,
        this.settings.password,
      );
    } else if (this.settings.authMethod === 'appRole') {
      this.#currentToken = await this.authAppRole(
        this.settings.roleId,
        this.settings.secretId,
      );
    }
    if (!this.#currentToken) {
      return [false, 'Authentication failed'];
    }
  }

Operating System

docker

n8n Version

2.2.3

Node.js Version

?

Database

PostgreSQL

Execution mode

main (default)

Hosting

self hosted

[n8n-assistant]

Hey @lcx,

Thank you for reaching out! We’ve received your issue and are looking into it. To help us track this internally, we’ve created a Linear ticket with the reference: "GHC-6216".

We’ll keep you updated as we make progress, but if you have any additional details or context to share, feel free to add them here - it’s always helpful!

Thanks for your patience and for bringing this to our attention.

---

For INTERNAL use only: GHC-6216

[Joffcom]

Hey @lcx

As a quick test can you try using the root token just to see if that works?

Can you also confirm which license you are using? If you are on an enterprise license you will have a support plan with an SLA which could be a better option for this.

[lcx]

I have the enterprise license due to the ambassador program. It’s not critical to get support involved but do think this could happen to enterprise clients if they run into the same constellation.

Not sure I tried the root token, but I did try the token that was created with the appRole login with the same result.
The initial setup worked without issue (this was pre upgrading to v2) I turned off the external secrets, recreated my vault installation and wanted to provide the new appRole credentials and ran into this.
I would probably have to recreate the vault to be able to reproduce this.

[Joffcom]

Hey @lcx,

When you created the approle did you set any TTY values for it? I have quickly tested a vault service I have been running for a while and created an approle, userpass and token test which all use different policies to see if it changes between them and for me on 1.x and 2.x I am able to edit the credentials and hit save then reload the secrets to get the ones that apply to the credential I am using.

We might need more details on this one so we can try and reproduce and fix it, One thing it could be is if I input the incorrect vault URL so https://my-vault.mydomain.com it will throw a 400 error with a request failure but if I use https://my-vault.mydomain.com/v1 it always works. Is it possible that the issue was with the URL being used?

Can you also share the Vault version you are using? My test vault is currently using 1.21.1 which I think was from late last year.

[lcx]

Yes I created the appRole with a TTL (using openBao instead of hashicorp vault but that's so far compatible)

bao write auth/approle/role/n8n-dev \
  token_policies="n8n-dev-policy" \
  token_ttl=1h \
  token_max_ttl=4h \
  secret_id_ttl=0 \
  secret_id_num_uses=0

But to give more context, I had it successfull connected during christmas holidays. I then disabled, setup my vault from scratch, entered the new credentials and here it instantly tried to hit the /v1/auth/token/lookup-self api.

Let me just try to setup a test env with a vault and a fresh n8n and try to reproduce from scratch.

[lcx]

I've set up a fresh 2.2.4 and tried to connect it to my existing vault.
In the attached screenshot you can see that the GET to /v1/auth/token/lookup-self is the only thing coming from n8n, this should however (as far as I know) only be done after the login with the token that was created from the appRole authentication.

Will now recheck this with 1.x version of n8n just to confirm. Makes no sense that the fresh setup worked two weeks ago.

[lcx]

the issue does not happen with n8n v1.x
Here it also tries the lookup-self, gets a 403 because of missing token, then executes the login and after that it fetches everything it needs and everything works first try.

If it's any help, I am on the n8n slack in the experts + ambassador channel and can create you an appRole on my vault to try this.

[v-karbovnichy]

probably this is related: #24057