Update automation-secure-asset-encryption.md #127787
Conversation
API supports user Identity too User identity used for CMK. https://learn.microsoft.com/en-us/azure/templates/microsoft.automation/2024-10-23/automationaccounts?pivots=deployment-language-terraform
|
@iuriiport : Thanks for your contribution! The author(s) and reviewer(s) have been notified to review your proposed change. |
|
Learn Build status updates of commit 55527a4: ✅ Validation status: passed
For more details, please refer to the build report. |
|
Can you review the proposed changes? Important: When the changes are ready for publication, adding a #label:"aq-pr-triaged" |
There was a problem hiding this comment.
Pull Request Overview
This PR updates documentation to clarify that Azure Automation accounts support both user-assigned and system-assigned managed identities for customer-managed key (CMK) encryption, and revises the explanation of how Azure Firewall and Private Link affect access between Automation accounts and Key Vault.
Key changes:
- Updates identity support to include both user-assigned and system-assigned managed identities
- Clarifies the access restrictions when using Azure Firewall and Private Link with Key Vault
- Corrects terminology from "runbooks" to "Automation Account service" for accuracy
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| Use Azure Key Vault to store customer-managed keys. You can either create your own keys and store them in a key vault, or you can use the Azure Key Vault APIs to generate keys. | ||
|
|
||
| Enabling the Azure Firewall on [Azure Key Vault](/azure/key-vault/general/network-security) blocks access from Azure Automation runbooks for that service. Access will be blocked even when the firewall exception to allow trusted Microsoft services is enabled, as Automation is not a part of the trusted services list. With an enabled firewall, access can only be made by using a Hybrid Runbook Worker and a [virtual network service endpoint](/azure/key-vault/general/overview-vnet-service-endpoints). However, when you enable the Private link for Key Vault, Azure Automation loses access to the Key Vault. Even if you enable a Private link for Hybrid Runbook Worker, it will allow access only to Azure Automation service and not to the Key Vault. | ||
| Enabling the Azure Firewall on [Azure Key Vault](/azure/key-vault/general/network-security) blocks access from Azure Automation Account service and cloud runbooks for that service. Access will be blocked even when the firewall exception to allow trusted Microsoft services is enabled, as Automation is not a part of the trusted services list. With an enabled firewall, access can only be made by using a Hybrid Runbook Worker and a [virtual network service endpoint](/azure/key-vault/general/overview-vnet-service-endpoints). However, when you enable the Private link for Key Vault, Azure Automation service loses access to the Key Vault. Even if you enable a Private link for Automation Account, it will allow access only to Azure Automation Accoiunt service and not from Automation Account sorvice to the Key Vault. |
There was a problem hiding this comment.
Two typos in the sentence: 'Accoiunt' should be 'Account' and 'sorvice' should be 'service'.
| Enabling the Azure Firewall on [Azure Key Vault](/azure/key-vault/general/network-security) blocks access from Azure Automation Account service and cloud runbooks for that service. Access will be blocked even when the firewall exception to allow trusted Microsoft services is enabled, as Automation is not a part of the trusted services list. With an enabled firewall, access can only be made by using a Hybrid Runbook Worker and a [virtual network service endpoint](/azure/key-vault/general/overview-vnet-service-endpoints). However, when you enable the Private link for Key Vault, Azure Automation service loses access to the Key Vault. Even if you enable a Private link for Automation Account, it will allow access only to Azure Automation Accoiunt service and not from Automation Account sorvice to the Key Vault. | |
| Enabling the Azure Firewall on [Azure Key Vault](/azure/key-vault/general/network-security) blocks access from Azure Automation Account service and cloud runbooks for that service. Access will be blocked even when the firewall exception to allow trusted Microsoft services is enabled, as Automation is not a part of the trusted services list. With an enabled firewall, access can only be made by using a Hybrid Runbook Worker and a [virtual network service endpoint](/azure/key-vault/general/overview-vnet-service-endpoints). However, when you enable the Private link for Key Vault, Azure Automation service loses access to the Key Vault. Even if you enable a Private link for Automation Account, it will allow access only to Azure Automation Account service and not from Automation Account service to the Key Vault. |
prmerger-automator
bot
added
the
aq-pr-triaged
|
Adding @tbhavya, the current owner of the service to review. |
|
#assign: @tbhavya |
|
The following users don't have valid GitHub IDs, or are not collaborators on this repo: tbhavya |
Co-authored-by: Copilot <[email protected]>
|
One addition regarding use a key version, could we maybe add some information/note about it being a requirement? |
|
Learn Build status updates of commit 38f512c: ✅ Validation status: passed
For more details, please refer to the build report. |
3 participants
API supports user Identity too.
Also the part regarding Private link and access from Automation account needs clarification.
It mentioned Hybrid Runbook worker, which is not relevant for scenario of Automation account being encrypted using keys from key vault
User identity used for CMK.
https://learn.microsoft.com/en-us/azure/templates/microsoft.automation/2024-10-23/automationaccounts?pivots=deployment-language-terraform