Azure Container Registry

Here's a tutorial guide on how to generate service account key in Azure Container Registry :

https://learn.microsoft.com/en-us/azure/container-registry/container-registry-authentication?tabs=azure-cli

NOTE: In Salad Portal, we are only going to get and make use of Username and Password from any of the listed three authentication method from Azure and here are the links their official documentation for each of the authentication methods blow including their pros and cons.

Azure AD Service Principal:

Link to guide : https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal

Pros:

1. Better security: Service principal allows for more secure authentication than using a shared user account.
2. Granular Access Control: You can assign specific permissions to the service principal, ensuring it has only the access it needs and nothing more.
3. Automating access management: Service principal is a great way to automate authentication and authorization to access Azure resources using code or scripts.

Cons:

1. Complexity: The service principal requires additional configuration steps, which can be challenging for inexperienced users.
2. Lack of visibility: Unlike a user account, it can be more difficult to track which service principal is accessing which resources.
3. Additional maintenance: Managing the lifecycle of a service principal can add to the overall management burden of the application.

Admin User:

This authencation method refers to a user account that has been granted administrative privileges in an Azure subscription or resource group. Admin Users are able to perform administrative tasks such as creating and managing resources, setting permissions and access policies, and configuring settings that affect the entire subscription or resource group.

Link to guide: https://docs.microsoft.com/en-us/azure/role-based-access-control/role-assignments-portal

Pros:

1. Easy to generate: Admin users can be created and granted access quickly and easily.
2. Broad Access: Admin users have access to all resources within an account, which can be useful for managing multiple resources.
3. Flexible: Admin users can be granted temporary access as needed and then removed when no longer required.

Cons:

1. Security Risks: Admin users pose a greater security risk as they have unrestricted access to all resources within an account.
2. Lack of Granular Control: Admin users can’t be assigned granular permissions, which can lead to overprivileged access( i.e Admins may have too much access because they can't be given specific permissions leading to security risks)
3. Difficult to Audit: Because admin users have access to all resources, it can be challenging to track their activity and audit their actions.

Repository-Scoped Access Token:

To create a repository-scoped access token in Azure, you'll need to follow the steps outlined in the guide you linked to, which involves creating a personal access token in GitHub, then using that token to authenticate with Azure.

Link to guide : https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token

Pros:

1. Specific Access: Repository-scoped access tokens can be scoped to specific repositories, ensuring that only the necessary resources are accessed.
2. Enhance Security: Tokens can be revoked at any time, providing an additional layer of security in case of a breach or unauthorized access.
3. No impact on users: Repository-scoped access tokens can be used to provide access without the need for user accounts.

Cons:

1. Requires Enterprise Plan: This method requires an enterprise plan, which can be a barrier for smaller organizations or individuals.
2. Limited scope: Repository-scoped access tokens are limited to the resources they are scoped to and can’t be used to access other resources.
3. Complexity: Managing access tokens can be complex and require additional configuration and management steps.

Note: The Azure AD Service Principal documentation is for Azure AD, but the same concept applies to other Azure services such as Azure Container Registry.

Now, Let's deploy the created token from any of the above options to salad portal as private registry:

• Go to http://portal.salad.com and "Create Organization"

• Select the Created Organisation.
  We are using "Salad Technologies"

• Create New Project

• Select Project "Demo"

• Create New Container Group

• Select "Private" and give the container a prefereable name e.g test then assign and choose Azure for your Private Registry Provider

• Select and input your Username and Password generated from Azure container registry

Here is a guide on how to generate service account key in Azure container registry :
https://learn.microsoft.com/en-us/azure/container-registry/container-registry-authentication?tabs=azure-cli

Below is an example of a username and password for a service principal's application (client) ID and client secret:
Username: abc12345-6789-0abc-def1-abcdef123456
Password: XyZ987!6A#bCdEfG

Note: The above example is just a placeholder and is not a valid client ID or client secret. Service principals should be created and managed securely in accordance with the security best practices of your organization. Additionally, client secrets should be treated with the same level of security as passwords, as they can be used to access sensitive data and resources.

Registry admin or access token authentication credentials can be used in place of a service account key.

• Select Review & Deploy

• Deploy Container Groups

• Congratulations! Your Container should now be running.

• Review and see the status which is successfully " Running"