-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Add AzureNamedKeyCredential #17548
Add AzureNamedKeyCredential #17548
Conversation
The code looks good. Please talk to Johan & Anna for the architect perspective feedback. |
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.
LGTM
Co-authored-by: swathipil <76007337+swathipil@users.noreply.github.com>
""" | ||
return self._key | ||
|
||
def update(self, name, key): |
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.
Do we have scenarios where you want to update/change the name of the key?
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.
I think one scenario could be that users want to use a new share access policy which has new name and key.
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 user update key only?
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.
technically - they are allowed to provide the same name - but they must provide a name
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.
I think the most common scenario is the name is fixed after creation, but user may modify the key value?
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.
@yunhaoling any thoughts on this?
If we know that users may normally not modify the name, I'll incline towards making name kwarg only
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.
actually on second thought, i think we should let this be - as much as i like kwargs, it doesn't seem like they'll grow later in this case.
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.
also, if the user thinks they wont need to change name for their use case, AzureKeyCredential serves their purpose
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.
...unless they need to initially specify the name?
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.
hmm, right - still doesn't change tht kwargs would not grow in this case - so will stick to it
""" | ||
if not isinstance(name, six.string_types) or not isinstance(key, six.string_types): | ||
raise TypeError("Both name and key must be Strings.") | ||
self._name = name |
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.
The reason for a single update method rather than two read/write properties is (per my understanding) to make the assignment atomic. This is not an atomic assignment. Is there a specific reason we have an non-atomic update
method?
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.
How common user creates an AzureNamedKeyCredential then modify the name?
It seems to me maybe
def update(self, key, **kwarg):
makes more sense?
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.
the update
method is to
- be consistent with other creds in python (aka AzureKeyCredential)
- be consistent with other languages when it comes to
AzureNamedKeyCredential
should we have two read/write properties instead of an update method?
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.
No. The reason for the update method is to be atomic. You cannot do that unless you expect callers to lock the instance when reading values.
def __init__(self, credential, **kwargs): # pylint: disable=unused-argument | ||
# type: (AzureNamedKeyCredential, **Any) -> None | ||
super(AzureNamedKeyCredentialPolicy, self).__init__() | ||
self._key = credential.key |
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.
What happens when a client is created with a given NamedKeyCredential
and later call update
on the NamedKeyCredential? The whole reason for the update method is to be able to roll the key.
Individual attributes cannot be updated. | ||
""" | ||
if not isinstance(name, six.string_types) or not isinstance(key, six.string_types): | ||
raise TypeError("Both name and key must be Strings.") |
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.
why Strings (with capital S)?
self._credential = AzureNamedKey(name, key) | ||
|
||
@property | ||
def credential(self): |
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.
It feels odd to have a credential property on a credential object. Is this the right name?
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.
changed to named_key
:type credential: ~azure.core.credentials.AzureNamedKeyCredential | ||
:raises: ValueError or TypeError | ||
""" | ||
def __init__(self, credential, name, **kwargs): # pylint: disable=unused-argument |
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.
Who is consuming the name of the AzureNamedKeyCredential
?
sdk/core/azure-core/azure/core/pipeline/policies/_authentication.py
Outdated
Show resolved
Hide resolved
sdk/core/azure-core/CHANGELOG.md
Outdated
|
||
### New Features | ||
|
||
- Added `azure.core.credentials.AzureNamedKeyCredential` credential and its respective policy #17548. |
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.
I don't see the policy in your PR?
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.
updted the change log
""" | ||
return self._key | ||
|
||
def update(self, name, key): |
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.
...unless they need to initially specify the name?
|
||
cred.update("newname", "newkey") | ||
assert cred.named_key.name == "newname" | ||
assert cred.named_key.key == "newkey" |
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.
We should have a test to make sure that we are returning a tuple as well...
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.
added - for clarification, we don't really return a tuple, we update the cred with a new tuple
Feature/cplat 2021 10 01 (Azure#17548) * Feature/cplat 2021 10 03 (Azure#16512) * update new api version branch with base * change 2021-10-03 to 2021-10-01 * Update readme.md * fix folder structure * add community gallery * Feature/cplat 2021 10 03 (Azure#16512) * update new api version branch with base * change 2021-10-03 to 2021-10-01 * Update readme.md * fix folder structure * add community gallery * remove sharedGallery and communityGallery * Gallery 10-01 change (community gallery, CVM) (Azure#16824) * add new api version 2020-09-30 for gallery.json * add support for api change, sharing profile related * update, change post to patch * fix model validation error * fix typo * add shared gallery api * update * fix typo * update * update * update * chagne new api version to preview * update readme.md and nit * remove some required field and make groups readonly * add swagger support for Grace's and Tim's work * error fix * error fix * change api version name to 2020-09-30 withour 'preview' * update * fix typo * address pr comment * set modelAsString to true for gallery sharing-related enum * update, fix merge * remove duplicate entry * shared gallery, change id to identifier.uniqueId * fix typo * update, remove x-ms-azure-resource for shared gallery * change name of Permissions to avoid SDK code build error * update * add new line * correct reset * update * save * update * fix * update * update * update * resolve CI error * update * Edge zone (Azure#17097) * added target extended locations to the caps gallery schema and added an example file * fixed a comma * Update readme.md * Rename specification/compute/resource-manager/Microsoft.Compute/stable/2021-10-01/gallery/CreateOrUpdateASimpleGalleryImageVersionWithTargetExtendedLocations.json to specification/compute/resource-manager/Microsoft.Compute/stable/2021-10-01/examples/gallery/CreateOrUpdateASimpleGalleryImageVersionWithTargetExtendedLocations.json * Update readme.md * update * address comment * resolve CI Co-authored-by: Andrew Sager <asager@microsoft.com> Co-authored-by: Theodore Chang <thchan@microsoft.com> * save (Azure#17600) Co-authored-by: kangsun-ctrl <69279251+kangsun-ctrl@users.noreply.github.com> Co-authored-by: Andrew Sager <asager@microsoft.com>
Fixes #17368
Summary
When using a shared key for authorization, some services require that the name of the key be used as a component of the algorithm to form the authorization token. For these cases,
AzureKeyCredential
andAzureSasCredential
aren't adequate as they track only a single value. A new credential type,AzureNamedKeyCredential
has been approved to address this gap.Goals
Offer a token credential suitable for working with any service needing a named key that follows patterns established by the other credential types offered in
Azure.Core
andAzure.Identity
.Developers should be able to construct the credential by providing a string-based name and key.
Developers should be able to update the name and key after construction to support rolling credentials or using a new access policy. Updating credential information should be done in-place and not require creating a new credential instance.
Developers should be able to read the name of they key, in order to support caching within an application so that it can be easily identified when updates are needed.
The Azure SDKs should be able to read the name and key, ensuring they reflect the most current values.
Support updates and reads concurrently with consistent behavior. Developers should be able to update the credential at any time without concern for whether the SDK is reading from it.
Non-Goals
Providing a friendly and discoverable means for developers to read the key from the credential; it is preferable to hide the key or discourage use.
Allowing the name or key to be updated independently; both elements will be required when updating a credential.
Success Criteria
An
AzureNamedKeyCredential
type has been implemented, following language guidelines and idioms.The tests necessary for its validation have been created and pass reliably.
The existing test suite continues to produce deterministic results and pass reliably.