Forum Discussion
Public Azure Container Registry: what is default access?
We have just created an ACR, and we want to pull images from the registry to an Azure Container App using RBAC/ managed identity. We chose to make the registry public with the choice of the Basic pricing plan. In other words: the firewall is not enabled. We can not access the Registry URL from a browser, how can we make sure that no one can access the content (containers) in the registry without explicit access granted?
I mean: it is OK that the registry is public, as in pingable, or as in there is a door on street level, but is the door locked by default?
When you create a Public Azure Container Registry (ACR), it means that the registry is accessible over the internet, but it doesn't automatically mean that everyone can access the content (images, artifacts) stored within the registry without proper authentication and authorization.
Even though your ACR is public and the firewall is not enabled, Azure still enforces authentication and authorization to access the content within the ACR. Here's how access is managed in a nutshell:
1. Authentication: Users or services need to authenticate to interact with the ACR. This can be done using various methods, such as Azure Active Directory (AAD) integration, admin accounts (not recommended for production), or managed identities for Azure resources.
2. Authorization: After authentication, what the user or service can do (read, write, delete) is determined by their role assignments. Azure uses Role-Based Access Control (RBAC) to manage these permissions. There are several built-in roles for ACR, like AcrPull (pull images), AcrPush (push and pull images), and Owner (full access).
Since you want to pull images from the registry to an Azure Container App using RBAC/managed identity, you should assign the appropriate RBAC role to the managed identity. Typically, the AcrPull role is enough if you just need to pull images. Here's how you can secure your ACR:
⦁ Assign Roles: Assign the AcrPull role to the managed identity associated with your Azure Container App. This allows the app to pull images from the ACR without granting broader access.
⦁ Access Reviews: Regularly review who has access to your ACR and what permissions they have. Remove unnecessary permissions to minimize potential attack vectors.
⦁ Monitor Logs: Use Azure Monitor to keep an eye on the activities in your ACR. This can help you detect any unauthorized access attempts.
Regarding the analogy of the door on street level: Yes, the door is there, and it's visible, but it's locked by default. Only those with the correct key (in this case, proper authentication and authorization) can open the door and access the contents.
To directly address your concern about accessing the Registry URL from a browser: It's expected that you cannot access the registry's content via a browser without proper authentication. Even though the endpoint is public, you need to use the Azure CLI, Docker CLI, or another appropriate client, along with proper authentication, to access the registry contents.
When you create a Public Azure Container Registry (ACR), it means that the registry is accessible over the internet, but it doesn't automatically mean that everyone can access the content (images, artifacts) stored within the registry without proper authentication and authorization.
Even though your ACR is public and the firewall is not enabled, Azure still enforces authentication and authorization to access the content within the ACR. Here's how access is managed in a nutshell:
1. Authentication: Users or services need to authenticate to interact with the ACR. This can be done using various methods, such as Azure Active Directory (AAD) integration, admin accounts (not recommended for production), or managed identities for Azure resources.
2. Authorization: After authentication, what the user or service can do (read, write, delete) is determined by their role assignments. Azure uses Role-Based Access Control (RBAC) to manage these permissions. There are several built-in roles for ACR, like AcrPull (pull images), AcrPush (push and pull images), and Owner (full access).
Since you want to pull images from the registry to an Azure Container App using RBAC/managed identity, you should assign the appropriate RBAC role to the managed identity. Typically, the AcrPull role is enough if you just need to pull images. Here's how you can secure your ACR:
⦁ Assign Roles: Assign the AcrPull role to the managed identity associated with your Azure Container App. This allows the app to pull images from the ACR without granting broader access.
⦁ Access Reviews: Regularly review who has access to your ACR and what permissions they have. Remove unnecessary permissions to minimize potential attack vectors.
⦁ Monitor Logs: Use Azure Monitor to keep an eye on the activities in your ACR. This can help you detect any unauthorized access attempts.
Regarding the analogy of the door on street level: Yes, the door is there, and it's visible, but it's locked by default. Only those with the correct key (in this case, proper authentication and authorization) can open the door and access the contents.
To directly address your concern about accessing the Registry URL from a browser: It's expected that you cannot access the registry's content via a browser without proper authentication. Even though the endpoint is public, you need to use the Azure CLI, Docker CLI, or another appropriate client, along with proper authentication, to access the registry contents.
