fix: update azure workload identity authentication to use federated t…

[abestel]

…oken directly

Description: (required)

The environment already reads the value of the file, which made the second read with the actual token fail.

Tests Run/Test cases added: (required)

• Description of test case

Type of Change:

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactoring (no functional changes)

[abestel]

This is a bug that appeared in #1408. cc @VisargD and @b4s36t4

[narengogi]

Hey @abestel I'm assuming you're facing an error with using this mode of authentication with cloudflare workers?
I would that you keep the existing support for file path and add the direct token change separately, you can add a check for the workerd environment if required using import { getRuntimeKey } from 'hono/adapter';

[abestel]

Hey @abestel I'm assuming you're facing an error with using this mode of authentication with cloudflare workers? I would that you keep the existing support for file path and add the direct token change separately, you can add a check for the workerd environment if required using import { getRuntimeKey } from 'hono/adapter';

Actually that's not the case, but in the meantime I've thought some more about this case, and the token file should not be read at startup anyway, since the content may change during the application lifecycle.

I simplified the change to avoid reading the content of the file when reading the value of the environment variable.

[narengogi]

@abestel what is the purpose of not reading from the path? in azure deployments the token file is often rotated so reading from the file is required
wdym by

The environment already reads the value of the file, which made the second read with the actual token fail.

[abestel]

@abestel what is the purpose of not reading from the path? in azure deployments the token file is often rotated so reading from the file is required wdym by

The environment already reads the value of the file, which made the second read with the actual token fail.

The token file is read later in the Azure OpenAI implementation, we don’t need to read it at startup. As you’re saying, the token is often rotated, so reading it once at startup is actually a mistake.

What I mean is that the functionality is currently broken because:

• 1/ the content of the file which path is set in the environment variable is read at startup
• 2/ in the Azure OpenAI implementation, we expect a file path to be set in the environment variable, but instead it’s the token value, which is failing because this is not a file path anymore.

I’m not sure why you closed this PR, because the current version of Portkey fails to authenticate using workload identities.