-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Azure Service Principal with Secret authentication workflow. #5131
Azure Service Principal with Secret authentication workflow. #5131
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
New usage would be simple, without any
but these environment variables need to be passed: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hi @kzych-inpost can you send a screenshot of using azure_ad_token_provider working for your on your proxy server ?
@ishaan-jaff is this good for merge? |
Hopefully, it will be merged soon and then there will no need to refresh the token schedulely anymore when using the model from azure. |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This has a really high risk of moving people away from the more secure OIDC flow, and encouraging them to use static secrets instead of more-secure temporary credentials. I would really want to see #4417 fixed before this is merged in. Also, I really don't like that this is loading way more than the title implies. See this huge list for all the things it's doing: https://learn.microsoft.com/en-us/dotnet/api/azure.identity.defaultazurecredential?view=azure-dotnet I would really want to see this narrowed down to just ClientSecretCredential. And finally, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See comments in #5131 (comment).
I see your point, but there are use-cases (like mine - Service Principal authentication), where classic OIDC flow for user authentication is not what suits one's need. What is more, the authentication method I've proposed also incorporates fetching temporary token (temporary credential mentioned by you), so I believe this method is also quite secure.
Sure, I can do that.
Well, |
To add more context: advantage of this solution is that it passes the responsibility for Azure authentication to Azure SDK. |
import os | ||
from typing import Callable | ||
|
||
from azure.identity import DefaultAzureCredential |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we move the azure.
imports to inside the function. This way it's only required, if this approach is used
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✅
@@ -186,9 +187,16 @@ def set_client(litellm_router_instance: LitellmRouter, model: dict): | |||
f"api_base is required for Azure OpenAI. Set it on your config. Model - {_filtered_model}" | |||
) | |||
azure_ad_token = litellm_params.get("azure_ad_token") | |||
azure_ad_token_provider = None |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we type this correctly, so it's clear what the potential values could be here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✅
@@ -303,6 +315,7 @@ def set_client(litellm_router_instance: LitellmRouter, model: dict): | |||
"azure_endpoint": api_base, | |||
"api_version": api_version, | |||
"azure_ad_token": azure_ad_token, | |||
"azure_ad_token_provider": azure_ad_token_provider, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we add a basic unit test here -
async def test_router_init(): |
with a mock test to make sure there's no future regressions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- OK, should I make another test-function next to this one with mocking environment variables (
AZURE_CLIENT_ID
,AZURE_CLIENT_SECRET
andAZURE_TENANT_ID
)? - The test you mentioned is skipped on my machine (problably due to the missing
pytest-asyncio
plugin andpytest.mark.asyncio
decorator). Is this expected behaviour and this would be executed on CI/CD? - Can't test it locally anyway because I have no
redis
installed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prepared the commit 85a8b9e with environment variables and other prerequisites mocked.
Hi @kzych-inpost looks good - left some comments re: refactoring code + Adding unit tests, before we can merge. thank you for this PR! |
…zure Service Principal with Secret authentication workflow.
How about the change in the documentation indicatiing that this feature is possible? |
…g Azure Service Principal with Secret authentication workflow.
@krrishdholakia all requested changes are already commited :) |
5787754
into
BerriAI:litellm_stable_merge_prs
…5437) * Azure Service Principal with Secret authentication workflow. (#5131) * Implement Azure Service Principal with Secret authentication workflow. * Use `ClientSecretCredential` instead of `DefaultAzureCredential`. * Move imports into the function. * Add type hint for `azure_ad_token_provider`. * Add unit test for router initialization and sample completion using Azure Service Principal with Secret authentication workflow. * Add unit test for router initialization with neither API key nor using Azure Service Principal with Secret authentication workflow. * fix(client_initializtion_utils.py): fix typing + overrides * test: fix linting errors * fix(client_initialization_utils.py): fix client init azure ad token logic * fix(router_client_initialization.py): add flag check for reading azure ad token from environment * test(test_streaming.py): skip end of life bedrock model * test(test_router_client_init.py): add correct flag to test --------- Co-authored-by: kzych-inpost <142029278+kzych-inpost@users.noreply.github.com>
Context
To my best knowledge (version
v1.42.12
), the only way to authentiacate using Service Principal workflow is to provideazure_ad_token
- either hardcoded (token expires though) or providing a path that starts withoidc/
:Why?
However, this workflow does not suit my needs, as it requires
AZURE_FEDERATED_TOKEN_FILE
.My goal is to use Service Principal with Secret workflow.
How?
There is a possibility in
openai
SDK to useazure_ad_token_provider
parameter, which is not used yet in theLiteLLM Proxy
.Relevant issues
Related issue: #4417.
Type
🆕 New Feature
Changes
get_azure_ad_token_provider()
function;set_client()
so it usesget_azure_ad_token_provider()
when necessary.[REQUIRED] Testing - Attach a screenshot of any new tests passing locall
If UI changes, send a screenshot/GIF of working UI fixes