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

[KeyVault] - Add support for Key Rotation #16593

Merged
merged 13 commits into from
Aug 18, 2021
Merged

Conversation

maorleger
Copy link
Member

@maorleger maorleger commented Jul 27, 2021

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.

@ghost ghost added the KeyVault label Jul 27, 2021
): Promise<KeyRotationPolicy | undefined> {
return withTrace("getRotationPolicy", options, async () => {
const policy = await this.client.getKeyRotationPolicy(this.vaultUrl, name);
if (policy.id) {
Copy link
Member Author

@maorleger maorleger Jul 29, 2021

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

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

@check-enforcer
Copy link

check-enforcer bot commented Aug 3, 2021

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:
/check-enforcer evaluate
Typically evaulation only takes a few seconds. If you know that your pull request is not covered by a pipeline and this is expected you can override Check Enforcer using the following command:
/check-enforcer override
Note that using the override command triggers alerts so that follow-up investigations can occur (PRs still need to be approved as normal).

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:
/azp run prepare-pipelines
This will run a pipeline that analyzes the source tree and creates the pipelines necessary to build and validate your pull request. Once the pipeline has been created you can trigger the pipeline using the following comment:
/azp run js - [service] - ci

Copy link
Member

@heaths heaths left a 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.

sdk/keyvault/keyvault-keys/review/keyvault-keys.api.md Outdated Show resolved Hide resolved
sdk/keyvault/keyvault-keys/review/keyvault-keys.api.md Outdated Show resolved Hide resolved
sdk/keyvault/keyvault-keys/review/keyvault-keys.api.md Outdated Show resolved Hide resolved
sdk/keyvault/keyvault-keys/src/index.ts Outdated Show resolved Hide resolved
sdk/keyvault/keyvault-keys/src/index.ts Outdated Show resolved Hide resolved
Copy link
Member

@heaths heaths left a comment

Choose a reason for hiding this comment

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

Better, thank you.

sdk/keyvault/keyvault-keys/review/keyvault-keys.api.md Outdated Show resolved Hide resolved
@maorleger maorleger marked this pull request as ready for review August 4, 2021 20:57
@maorleger maorleger changed the title [KeyVault] - Initial draft of Key Rotation [KeyVault] - Add support for Key Rotation Aug 4, 2021
// @public
export interface KeyRotationLifetimeAction {
action: KeyRotationPolicyAction;
timeAfterCreate?: string;
Copy link
Member

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.

Copy link
Member

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.

Copy link
Member

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

Copy link
Member Author

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

Copy link
Member

Choose a reason for hiding this comment

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

Copy link

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

Copy link
Member Author

@maorleger maorleger Aug 18, 2021

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:

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

cc @AlexGhiondea

Copy link
Contributor

@sadasant sadasant left a 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.
@maorleger
Copy link
Member Author

/azp run js - keyvault-keys - tests

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@maorleger maorleger merged commit 44a435c into Azure:main Aug 18, 2021
@maorleger maorleger deleted the keyvault-rotate branch August 18, 2021 16:43
ckairen pushed a commit to ckairen/azure-sdk-for-js that referenced this pull request Aug 24, 2021
## 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)
maorleger added a commit to maorleger/azure-sdk-for-js that referenced this pull request Aug 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants