Closed rlevchenko closed 3 years ago
@rlevchenko Thank you for reaching out and bringing this to our notice. At this time we are reviewing the feedback and will provide an update as appropriate.
@dlepow Can you please check and add your comments on this doc update request as applicable.
@PCNZ The feedback on improving this document to incorporate more information on how to store a customer-managed key for a registry when the KV firewall is enabled as documented here is shared with the content team.
Doc author is working on updating this document which will address this feedback.
Linking similar issue #61064
Closing this issue for now are the document will updated soon.
@VikasPullagura-MSFT Any deadlines? Will we be able to switch seamlessly from SMK to CMK after ACR deployment? I just don't have time waiting for any docs updates, honestly :)
@dlepow Can you please add your comments.
@dlepow @VikasPullagura-MSFT FYI now I'm using ACR and Key Vault with whitelisted CR region specific IP ranges . Looks like it's working..not sure about support state
@rlevchenko, right now, to encrypt registry using keys from a vault behind VNET, the workaround still stands till we roll out improvements in future. 2 reasons:
The roadmaps are: a. Key vault should support by-pass through user assigned identities. b. ACR support encryption on existing registries, so called migration.
Please let me know if you have any other questions
@yugangw-msft thanks! and seems like I've found a workaround 2 :)
Hi everyone,
just asking if I have to use this workaround like written in the "Advanced scenarios" or will there be soon an update and support for user assigned managed identity out of the box (see @yugangw-msft point 1)
Kind regards
If you have Azure Key Vault with firewall enabled (private endpoints + selected networks + allow azure services) and trying to add Container Registry with customer-managed keys, you are getting the following error during the deployment:
Failed to access KeyId 'https://xxx.vault.azure.net/keys/dfddd/1e355bccxxxab8ea6957'. Verify that identity '0799bf0c-a8e6-4a74-aad0-59exx3c733' has 'Get, Wrap Key, Unwrap Key' permission on key 'https://xxs.vault.azure.net/keys/dfddd/1e355bccc18f476285b46b3ab8ea6957'. For more information on bring your own key, please visit 'https://aka.ms/acr/cmk'. Click here for details
Reason is quite simple (found this in logs):
Workaround is obvious.
The question is also simple...WHY? Why the Azure Key Vault is blocking IP from MSFT range (range belongs to Container Registry service, trusted service..bypass enabled)? I think it shouldn't work in such way. Or, update the docs with "add the following IP range beforehand..." (not applicable for zero-trust scenarios though)
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.