In previous versions of the Semantic Kernel Python, the default fallback authentication mechanism for Azure services like AzureChatCompletion
was DefaultAzureCredential
from the Azure Identity library. This provided a convenient way to authenticate without explicitly passing credentials, especially during development. However, with the latest package version 1.36.0
, this fallback is being removed to encourage more secure and explicit authentication practices. If your code relied on this default behavior, you may encounter errors after updating, and you’ll need to make minor code adjustments to continue using credential-based authentication.
This post explains the reasoning behind this change, the potential issues you might face, and how to update your code accordingly. For more details on Azure authentication options, check out the Azure Identity library documentation.
Why This Change is Required
DefaultAzureCredential
is designed primarily for local development environments, where it simplifies authentication by attempting a chain of common developer credentials (such as Azure CLI, Azure PowerShell, or Visual Studio Code sign-ins) until one succeeds. While this is helpful for quick prototyping, it introduces several risks and limitations in production:
- Unpredictable Behavior: It tries multiple authentication methods in sequence, which can lead to delays, unexpected failures, or reliance on credentials that aren’t consistently available across environments.
- Interactive Authentication Fallback: By default, it can prompt for interactive browser-based login, which is unsuitable for automated, headless production applications running on servers or in cloud environments.
- Security and Best Practices: Production scenarios benefit from explicit, dedicated credentials like managed identities or service principals, which offer better control, auditing, and security. Using a broad fallback like
DefaultAzureCredential
can mask configuration issues and doesn’t align with principles of least privilege.
For these reasons, we recommend using specific credential types tailored to your deployment environment in production to ensure reliability and security.
Changes in the Latest Version and Potential Errors
Starting with the new SDK version, the implicit use of DefaultAzureCredential
as a fallback has been removed. This means that if your code doesn’t explicitly provide an authentication method (such as an API key, AD token, or credential object), initialization will fail.
Users updating to this version who previously relied on the default fallback might see a ServiceInitializationError
with the message: Please provide either api_key, ad_token, ad_token_provider, credential or a client.
This error indicates that the SDK now requires you to explicitly pass one of the supported authentication options during service creation.
This change promotes better coding practices by making authentication explicit, reducing hidden dependencies, and aligning with Azure’s security guidelines.
How to Update Your Code
To resolve this, update your code to pass an explicit authentication method. If you want to continue using a credential-based approach (similar to the old fallback), you can instantiate a specific credential type from the Azure Identity library and pass it to the service constructor.
For example, change from the old implicit fallback:
chat_service = AzureChatCompletion()
To an explicit credential, such as AzureCliCredential
(or any other suitable type like ManagedIdentityCredential
for Azure-hosted apps):
from azure.identity import AzureCliCredential
chat_service = AzureChatCompletion(credential=AzureCliCredential()) # Or use another credential type
Other options include providing an api_key
, ad_token
, ad_token_provider
, or a pre-configured client. Choose the one that best fits your environment.
Remember to import the necessary credential class from azure.identity
and ensure your environment is set up accordingly (e.g., Azure CLI logged in for AzureCliCredential
).
Summary
This update to the Semantic Kernel Python removes the DefaultAzureCredential
fallback to encourage explicit and secure authentication, addressing potential issues in production while maintaining flexibility. By making a small code change, you can avoid initialization errors and align with best practices.
We’re always interested in hearing from you. If you have feedback, questions, or want to discuss further, feel free to reach out to us and the community on the discussion boards on GitHub! We would also love your support—if you’ve enjoyed using Semantic Kernel, give us a star on GitHub.
0 comments
Be the first to start the discussion.