MicrosoftDocs / azure-docs

Open source documentation of Microsoft Azure
https://docs.microsoft.com/azure
Creative Commons Attribution 4.0 International
10.09k stars 21.14k forks source link

Azure Key Vault firewall blocks Container Registry deployment #61015

Closed rlevchenko closed 3 years ago

rlevchenko commented 3 years ago

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

 "resultDescription": "Client address is not authorized and caller is not a trusted service.\nClient address: 13.69.64.92\nCaller: appid=0799bf0c-a8e6-4a74-aad0-59e343b3c733;oid=f4a4b03f-3ab9-4d8e-971e-2c96b00a268c;iss=https://sts.windows.net/d373cb19-d4db-4f95-aedf-363199c531aa/;xms_mirid=/subscriptions/xxxxx/resourcegroups/KV/providers/Microsoft.ManagedIdentity/userAssignedIdentities/testmi\nVault: xxxx;location=westeurope",
    "correlationId": "82fc3c93-dc86-4480-aa4a-9fc3628b2000",
    "callerIpAddress": "13.69.64.92",

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.

KranthiPakala-MSFT commented 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.

VikasPullagura-MSFT commented 3 years ago

@dlepow Can you please check and add your comments on this doc update request as applicable.

VikasPullagura-MSFT commented 3 years ago

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

rlevchenko commented 3 years ago

@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 :)

VikasPullagura-MSFT commented 3 years ago

@dlepow Can you please add your comments.

rlevchenko commented 3 years ago

@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

yugangw-msft commented 3 years ago

@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:

  1. Keyvault only allows by-pass using system assigned identity
  2. Encrypting registries can only be applied on creating, but system assigned identity is not available yet.

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

rlevchenko commented 3 years ago

@yugangw-msft thanks! and seems like I've found a workaround 2 :)

Insighter2k commented 3 years ago

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