[Keyvault] ManagedHsm NetworkRuleSet Support #28602
Conversation
| Thanks for your contribution! The pull request validation has started. Please revisit this comment for updated status. |
There was a problem hiding this comment.
Pull Request Overview
This PR updates the Azure KeyVault Management SDK to use API specification version 2025-05-01, enabling support for NetworkRuleSet functionality in ManagedHsm. The change involves updating the AutoRest generation configuration to point to the newer API specification files.
- Updates API specification version from 2024-11-01 to 2025-05-01
- Updates the commit hash reference for the Azure REST API specifications
- Maintains the same input files (common.json, keyvault.json, managedHsm.json) but from the newer API version
|
Converting to draft as it looks not ready for review yet |
notyashhh
force-pushed
the
yash/keyvault-mhsm
branch
from
2fd6ff3 to
94009a1
Compare
src/KeyVault/KeyVault/help/Update-AzKeyVaultManagedHsmNetworkRuleSet.md
Outdated
Show resolved
Hide resolved
src/KeyVault/KeyVault/help/Remove-AzKeyVaultManagedHsmNetworkRule.md
Outdated
Show resolved
Hide resolved
src/KeyVault/KeyVault/help/Add-AzKeyVaultManagedHsmNetworkRule.md
Outdated
Show resolved
Hide resolved
src/KeyVault/KeyVault/Commands/VirtualNetworkRuleSet/ManagedHsm/ManagedHsmNetworkRuleSetBase.cs
Show resolved
Hide resolved
…uleSet.md Co-authored-by: Copilot <[email protected]>
…ule.md Co-authored-by: Copilot <[email protected]>
Co-authored-by: Copilot <[email protected]>
| Assert-AreEqual $false $actual.EnabledForDeployment | ||
| # Default Access Policy is not set by Service Principal | ||
| Assert-AreEqual 0 @($actual.AccessPolicies).Count | ||
| Assert-AreEqual 1 @($actual.AccessPolicies).Count |
There was a problem hiding this comment.
This is actually caused by a feature in the test framework to support recording test cases with user account instead of service account, in which case the command won't add default access policy, so the result is 0. So it's not that the test cases are incorrect, it's just an unfixed behavior.
There was a problem hiding this comment.
Makes sense! In that case should we leave this as 1? (Since from now on, it will use the user account)
There was a problem hiding this comment.
I love that you covered both e2e and unit tests.
| ```powershell | ||
| Add-AzKeyVaultManagedHsmNetworkRule -Name $myHsm -ResourceGroupName $myRg -IpAddressRange 203.0.113.0/24,198.51.100.10/32 -PassThru | ||
| ``` | ||
|
|
||
| ```output | ||
| Name Resource Group Name Location SKU ProvisioningState Security Domain ActivationStatus | ||
| ---- ------------------- -------- --- ----------------- -------------------------------- | ||
| mhsm1814428918 kv-mhsm-rg eastus StandardB1 Succeeded NotActivated | ||
| $hsm.OriginalManagedHsm.Properties.NetworkAcls | ||
| Bypass : AzureServices | ||
| DefaultAction : Deny | ||
| IPRules : {203.0.113.0/24, 198.51.100.10/32} | ||
| ServiceTags : {} | ||
| VirtualNetworkRules : {} | ||
| ``` |
There was a problem hiding this comment.
Nit: move $hsm.OriginalManagedHsm.Properties.NetworkAcls into the ```powershell block because the idea is to split the input and output so that user can simply copy paste the input and easily replicate the example
This applies to multiple examples in the PR
3 participants
Description
Mandatory Checklist
Please choose the target release of Azure PowerShell. (⚠️ Target release is a different concept from API readiness. Please click below links for details.)
Check this box to confirm: I have read the Submitting Changes section of
CONTRIBUTING.mdand reviewed the following information:ChangeLog.mdfile(s) appropriatelysrc/{{SERVICE}}/{{SERVICE}}/ChangeLog.md.## Upcoming Releaseheader in the past tense.ChangeLog.mdif no new release is required, such as fixing test case only.