-
Notifications
You must be signed in to change notification settings - Fork 1.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
[KeyVault] - Add support for Key Rotation #16593
Conversation
): Promise<KeyRotationPolicy | undefined> { | ||
return withTrace("getRotationPolicy", options, async () => { | ||
const policy = await this.client.getKeyRotationPolicy(this.vaultUrl, name); | ||
if (policy.id) { |
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 did ask the service team about what's expected here. Right now, this will return
{ id: undefined, lifetimeActions: [], attributes: null }
And I wonder if it should 404 or 204 with no content. Depending on what the service team responds with we can decide what the client library should do. But for now, I made the decision to return undefined in that case.
@@ -35,3 +35,16 @@ directive: | |||
transform: > | |||
$["x-ms-client-name"] = "authenticationTag" | |||
``` | |||
|
|||
### Update swagger enum values for LifetimeActionsType to reflect what the service actually returns |
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.
Calling out this change - I wanted to unblock myself but we do have a thread going to make the enum values lowercase if possible, or at least update the x-ms-enum swagger to reflect what the service actually returns
This pull request is protected by Check Enforcer. What is Check Enforcer?Check Enforcer helps ensure all pull requests are covered by at least one check-run (typically an Azure Pipeline). When all check-runs associated with this pull request pass then Check Enforcer itself will pass. Why am I getting this message?You are getting this message because Check Enforcer did not detect any check-runs being associated with this pull request within five minutes. This may indicate that your pull request is not covered by any pipelines and so Check Enforcer is correctly blocking the pull request being merged. What should I do now?If the check-enforcer check-run is not passing and all other check-runs associated with this PR are passing (excluding license-cla) then you could try telling Check Enforcer to evaluate your pull request again. You can do this by adding a comment to this pull request as follows: What if I am onboarding a new service?Often, new services do not have validation pipelines associated with them, in order to bootstrap pipelines for a new service, you can issue the following command as a pull request comment: |
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 more closely match what we do for certificates for consistency. It may be good to leave the "KeyRotationPolicy" prefix to disambiguate, but the design is currently very different from certificates and could be made a little closer. After all, the service team was effectively porting the feature from certs to keys.
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.
Better, thank you.
f2bb3db
to
8e33c13
Compare
// @public | ||
export interface KeyRotationLifetimeAction { | ||
action: KeyRotationPolicyAction; | ||
timeAfterCreate?: string; |
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 see these names match the swagger, which is probably fine. There's not quite the analog to our certificate's LifetimeActions
that use a date; however, I would suggest a swagger change that these use the ISO 8601 duration format, which is very different than ISO 8601 date formats used elsewhere in this and many other SDKs.
That said, I think for idiomatic reasons we should consider various languages' / frameworks' TimeSpan
(.NET) structs; though, I believe @JeffreyRichter had some problem with this as far as Go goes. At the very least, we'll want to document our APIs that this is the ISO 8601 duration format e.g., "P90D" for 90 days, and probably even link to it.
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.
Swagger should not have any 8601 string durations in it. We want number in units (seconds, minutes, hours). How this number is represented in various programming languages is fine; .NET can use a Timespan initialized from the number in the proper units. FYI: Go has a time.Duration type too but it is just a thin wrapper over an integer.
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.
To Jeffrey's point (sorry - I was misremembering his concern was about the swagger, not the SDK), certificates already has a precedent of requiring a number of days: days_before_expiry
(though, should be camelCase - this was before my time).
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.
Thank you for the feedback! @jlichwa - certificates swagger already uses numbers to represent triggers for certificate policy - is this something we can model similarly for key rotation policies?
Right now the keys swagger defines timeAfterCreate and timeBeforeExpiry as strings representing durations - is that something that can be changed to number in units like we do in certificates?
Thanks in advance
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.
/cc @herveyw-msft
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 purposely deviated from Certificates which were defined long time ago and we did want to repeat same mistakes. Keys model is more flexible with ability to easily define time span in any units (initially we just support years, months, days but later we may extend it to hours, minutes....
Engineers found that ISO 8601 is a standard for TimeSpan - we same in Service BUS https://docs.microsoft.com/en-us/rest/api/servicebus/preview/queues/get#sbqueue
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 does look like we have some precedence for using durations. At least in JS we have autoDeleteOnIdle
in service bus and monitor query's timespan
parameter; however, we should address @JeffreyRichter's guidance. So I propose:
- Merging this PR once we have support for
rotate
permission in arm template (so that we can run live tests against the service) edit: it might already be supported, I will check today - Setting aside some time next week (week of 8/23) when folks are back in the office to discuss the guidelines here - I'd love to get to resolution specifically for Key Rotation and I'll make issues based on the outcome. I can schedule something for next week
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.
Looks clean from the code perspective! Make sure to get the Key Vault crew aligned on the public API.
- sort package.json new import - rename the options interfaces to match the method name - remove the @returns from js-doc. I like @returns, but its inconsistent with our other methods - remove the "erros when fetching deleted key" test - deleting keys is too long an operation, making this an expensive test of service side. We already have a errors when fetching non-existent key.
4f51cdf
to
637ffed
Compare
/azp run js - keyvault-keys - tests |
Azure Pipelines successfully started running 1 pipeline(s). |
## What - Add `getKeyRotationPolicy`, `rotateKey`, and `updateKeyRotationPolicy` to KeyClient - Model Key Rotation policy similarly to Certificate Policy - Add `rotate` permission to the arm template when deploying keyvault ## Why As part of 7.3 the KV crew is adding support for Key Rotation which we will need to model in our SDK. It is currently in preview but is planned for 7.3. As such, we have a few methods to model here: - Updating a key's rotation policy - Fetching a key's rotation policy - Rotating a key on-demand which will create a new version of the key In addition, since it requires the `/keys/rotate` permission, we need to add that to the list of permissions in our test resources. ## Callout As of 8/18/21 the model for rotation policy contains ISO8601 durations which we are modeling as string similar to our other libraries. That might change at the swagger level or it might change at the SDK level in the near future (decision TBD)
This reverts commit 44a435c.
What
getKeyRotationPolicy
,rotateKey
, andupdateKeyRotationPolicy
to KeyClientrotate
permission to the arm template when deploying keyvaultWhy
As part of 7.3 the KV crew is adding support for Key Rotation which we will need to model in our SDK. It is currently in preview
but is planned for 7.3. As such, we have a few methods to model here:
In addition, since it requires the
/keys/rotate
permission, we need to add that to the list of permissions in our test resources.