[TestResources] Doc Updates and Revisions for External Use #1983
Conversation
jsquire
added
EngSys
jsquire
force-pushed
the
testresources/params
branch
from
6b0cb4f
to
6292d2f
Compare
|
The following pipelines have been queued for testing: |
jsquire
force-pushed
the
testresources/params
branch
from
6292d2f
to
1a3ac6f
Compare
|
The following pipelines have been queued for testing: |
There was a problem hiding this comment.
Discussed offline. Let's proceed through the pipeline and create the per-language repo PRs. After that - maybe across a sampling of language/service combinations - run live pipelines across the following services at least:
- Storage
- Event Hubs
- Key Vault
I'll do a manual run with Key Vault as well since I was about to anyway to record some new test cases.
|
Key Vault's test-resources-post.ps1 is currently broken because we set the TestApplicationOid as the initial Managed HSM owner, which is a hardened security feature. This needs to include the provisioner as well because the post script needs to activate the domain. We either log in as the test application, or we add the Provisioner* properties to the I might also be able to work around this with a pre-script that adds values to |
What's involved with activating the domain? If we assign the provisioner (either SP or the interactive user) as the initial owner and the post- script is running in the context of the same provisioner, would that work or is there something that needs to be done with the provisioner's identifying information? If I'm reading the docs correctly, if we execute the My assumption here is that we're running the pre- and post- scripts in the same context as |
An alternate thought: If we continue to assign the test application as the administrator of the HSM, couldn't we have the post- script log into the test app, authorize the HSM, and then restore the calling context? The test application will have |
L592, changed |
|
Right - everything during this script is now run as the provisioner (explicit or current context), which is fine. The problem was that the Key Vault test-resources.json and test-resources-post.ps1 assumed the test application likely was that provisioner. Not sure, now that I've run into this problem after your (perfectly fine) changes, how it was working during live test runs by the CI which presumably passed different contexts. Or maybe it didn't. @benbp? |
|
@heaths not quite sure what you are asking, but CI uses the same SP values for test application and provisioner. |
|
@benbp thanks, that explains it. Test app and provisioner were assumed to be the same, but that's no longer true (which is a good change, I agree). |
Necessary after Azure/azure-sdk-tools#1983 is merged.
|
The following pipelines have been queued for testing: |
The focus of these changes is to revise the script to better support use by external contributors and others outside of the Azure SDK ecosystem and without access to the Microsoft AAD Tenant. Changes include: - Creation of a new Test Application service principal is now possible from a non-Microsoft AAD tenant. - When a new Test Application principal is created, the principle of least privilege is now applied; the new Test Application is granted ownership of the resource group associated with the test resources and no longer has access to any other resources in the subscription. - If an existing Test Application principal is specified, it will be assigned ownership of the resource group created. This supports using a Test Application principal without privileges at the subscription-level. - When no provisioner is specified, the script is now executed in the context of the caller rather than the Test Application principal. This supports using a Test Application principal that has restricted privileges and better aligns to the purpose of the Test Application principal. - The `$TestApplicationOid` is now explicitly bound at the time a new Test Application principal is created rather than having to query for it later. - Common error scenarios resulting from lack of permissions now provide messaging with more context of why the failure occurred and suggest remediation. - Added new examples to illustrate the common call patterns needed by external contributors running the script, outside of the Microsoft tenant and Azure SDK ecosystem. - Documentation has been enhanced with additional context to detail the permissions and roles assigned by the script. - Added documentation details for Bicep template use.
Key Vault needs this to deploy Managed HSMs. There's a corresponding change necessary in test-resources.json I'll roll out across languages.
jsquire
force-pushed
the
testresources/params
branch
from
80ae4d5
to
0695961
Compare
|
The following pipelines have been queued for testing: |
If there weren't typos, nobody would believe that I wrote it. 😄 |
|
The following pipelines have been queued for testing: |
Would've been funnier if you misspelled your commit title. |
|
Hello @azure-sdk! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
|
/check-enforcer evaluate |
ghost
merged commit Necessary after Azure/azure-sdk-tools#1983 is merged.
Summary
The focus of these changes is to revise the script to better support use by external contributors and others outside of the Azure SDK ecosystem and without access to the Microsoft AAD Tenant.
Details
Creation of a new Test Application service principal is now possible from a non-Microsoft AAD tenant.
When a new Test Application principal is created, the principle of least privilege is now applied; the new Test Application is granted ownership of the resource group associated with the test resources and no longer has access to any other resources in the subscription.
If an existing Test Application principal is specified, it will be assigned ownership of the resource group created. This supports using a Test Application principal without privileges at the subscription-level.
When no provisioner is specified, the script is now executed in the context of the caller rather than the Test Application principal. This supports using a Test Application principal that has restricted privileges and better aligns to the purpose of the Test Application principal.
The
$TestApplicationOidis now explicitly bound at the time a new Test Application principal is created rather than having to query for it later.The Object Id of the provisioner, either the specified
$ProvisionerApplicationIdor the interactive user, is now passed to the template as part of the deployment parameters.Common error scenarios resulting from lack of permissions now provide messaging with more context of why the failure occurred and suggest remediation.
Added new examples to illustrate the common call patterns needed by external contributors running the script outside of the Microsoft tenant and Azure SDK ecosystem.
Documentation has been enhanced with additional context to detail the permissions and roles assigned by the script.
Added documentation details for Bicep template use.