Skip to content
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

Merged
merged 19 commits into from
Apr 25, 2021
Merged

Add AzureNamedKeyCredential #17548

merged 19 commits into from
Apr 25, 2021

Conversation

rakshith91
Copy link
Contributor

@rakshith91 rakshith91 commented Mar 24, 2021

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 and AzureSasCredential 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 and Azure.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.

@xiangyan99
Copy link
Member

The code looks good.

Please talk to Johan & Anna for the architect perspective feedback.

@rakshith91 rakshith91 requested a review from annatisch March 24, 2021 23:00
Copy link
Member

@swathipil swathipil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

sdk/core/azure-core/CHANGELOG.md Show resolved Hide resolved
Co-authored-by: swathipil <76007337+swathipil@users.noreply.github.com>
"""
return self._key

def update(self, name, key):
Copy link
Member

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?

Copy link
Contributor

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.

Copy link
Member

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?

Copy link
Contributor Author

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

Copy link
Member

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?

Copy link
Contributor Author

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

Copy link
Contributor Author

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.

Copy link
Contributor Author

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

Copy link
Member

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?

Copy link
Contributor Author

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
Copy link
Member

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?

Copy link
Member

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?

@johanste

Copy link
Contributor Author

@rakshith91 rakshith91 Mar 29, 2021

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

  1. be consistent with other creds in python (aka AzureKeyCredential)
  2. be consistent with other languages when it comes to AzureNamedKeyCredential

should we have two read/write properties instead of an update method?

Copy link
Member

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
Copy link
Member

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.")
Copy link
Member

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):
Copy link
Member

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?

Copy link
Contributor Author

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
Copy link
Member

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?


### New Features

- Added `azure.core.credentials.AzureNamedKeyCredential` credential and its respective policy #17548.
Copy link
Member

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updted the change log

@rakshith91 rakshith91 closed this Apr 20, 2021
@rakshith91 rakshith91 reopened this Apr 20, 2021
"""
return self._key

def update(self, name, key):
Copy link
Member

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"
Copy link
Member

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...

Copy link
Contributor Author

@rakshith91 rakshith91 Apr 25, 2021

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

@rakshith91 rakshith91 merged commit 844e16d into Azure:master Apr 25, 2021
@yunhaoling yunhaoling mentioned this pull request Apr 26, 2021
openapi-sdkautomation bot pushed a commit to AzureSDKAutomation/azure-sdk-for-python that referenced this pull request Feb 9, 2022
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Azure.Core: AzureNamedKeyCredential
5 participants