Answers: <p>There is a balancing act here between the simplicity and maintainability of your solution, and how auditable creating separate service principals or users for each of your external customers.  I suspect only you can actually decide which is the best practice in your specific legal and regulatory situation.</p>
  
  <p>On the <strong>side of having a single Service Principal</strong> with multiple passwords, there is a minimal amount of configuration required and other than perhaps limitations imposed by Microsoft on the number of authentications per second or the number of passwords that can be created for a Service Principal it should work quite nicely.  The downside is your <a href="https://docs.microsoft.com/en-us/azure/container-registry/container-registry-diagnostics-audit-logs" rel="nofollow noreferrer">resource logs</a> won't give you any information about who pulls images, you will have some logs about issuing a short-lived password, but you can't prove that's related to a <code>docker login</code>.</p>
  
  <p>On the side of <strong>creating a Service Principal per client</strong> means your <a href="https://docs.microsoft.com/en-us/azure/container-registry/container-registry-diagnostics-audit-logs" rel="nofollow noreferrer">resource logs</a> will tell you who pulls images.  However, you will need to automate the creation and maintenance of those Service Principals to account for clients joining and leaving.</p>
  
  <p><strong><em>Why</em></strong> does it matter? it may not for you, however if one of your customer's machines was compromised and the images leaked onto the internet you may want to hold one of the customers to account.</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-11-07T20:57:41.033Z
Answers: 2019-11-07T20:57:41.033Z
Answers: Richard Slater
Body: <p>I'm using Azure Container Registry for private Docker images. I want to let around 500 customers pull images and use the Docker V2 HTTP API to read metadata.</p>
  
  <p>Service Principals are one way to go about this. My plan is to create a single Service Principal, and grant it the <code>AcrPull</code> role on the Azure Container Registry. I'd then create a time-limited password credential for each customer.</p>
  
  <p>The customer flow would be something like:</p>
  
  <ol>
  <li>Authenticate using the Service Principal client secret, to get an Azure AD Access Token</li>
  <li>Hit the Azure Container Registry OAuth token endpoint, swapping the AAD Access Token for an ACR Access Token and Refresh Token</li>
  <li>You can now use <code>docker login</code> using the ACR Refresh Token as the password</li>
  <li>You can also access the ACR HTTP API using the ACR token</li>
  </ol>
  
  <p>These steps are not carried out manually, but by automatic scripts running on customer's servers.</p>
  
  <p>After much research (Microsoft's docs here are not great), this approach seems to work as expected.</p>
  
  <p>Is using a Service Principal the "idiomatic" way to approach this? Are there any benefits to creating an individual Service Principal for each customer? </p>
  
Tags: <azure><security><architecture><permissions>
Title: Provide customers with access to Azure Container Registry
UserDisplayName: Cocowalla
ThreadText: # Provide customers with access to Azure Container Registry
  
  (Asked by: username_0 on 2019-10-05)
  
  I'm using Azure Container Registry for private Docker images. I want to let around 500 customers pull images and use the Docker V2 HTTP API to read metadata.
  
  Service Principals are one way to go about this. My plan is to create a single Service Principal, and grant it the `AcrPull` role on the Azure Container Registry. I'd then create a time-limited password credential for each customer.
  
  The customer flow would be something like:
  
  1. Authenticate using the Service Principal client secret, to get an Azure AD Access Token
  2. Hit the Azure Container Registry OAuth token endpoint, swapping the AAD Access Token for an ACR Access Token and Refresh Token
  3. You can now use `docker login` using the ACR Refresh Token as the password
  4. You can also access the ACR HTTP API using the ACR token
  
  These steps are not carried out manually, but by automatic scripts running on customer's servers.
  
  After much research (Microsoft's docs here are not great), this approach seems to work as expected.
  
  Is using a Service Principal the "idiomatic" way to approach this? Are there any benefits to creating an individual Service Principal for each customer?
  
  **Tags:** azure, security, architecture, permissions
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2019-11-07. Score: 1
  
  There is a balancing act here between the simplicity and maintainability of your solution, and how auditable creating separate service principals or users for each of your external customers. I suspect only you can actually decide which is the best practice in your specific legal and regulatory situation.
  
  On the **side of having a single Service Principal** with multiple passwords, there is a minimal amount of configuration required and other than perhaps limitations imposed by Microsoft on the number of authentications per second or the number of passwords that can be created for a Service Principal it should work quite nicely. The downside is your [resource logs](https://docs.microsoft.com/en-us/azure/container-registry/container-registry-diagnostics-audit-logs) won't give you any information about who pulls images, you will have some logs about issuing a short-lived password, but you can't prove that's related to a `docker login`.
  
  On the side of **creating a Service Principal per client** means your [resource logs](https://docs.microsoft.com/en-us/azure/container-registry/container-registry-diagnostics-audit-logs) will tell you who pulls images. However, you will need to automate the creation and maintenance of those Service Principals to account for clients joining and leaving.
  
  ***Why*** does it matter? it may not for you, however if one of your customer's machines was compromised and the images leaked onto the internet you may want to hold one of the customers to account.
  
  
  ---
  
  