Shulou(Shulou.com)06/02 Report--

A common challenge that needs to be addressed when building cloud applications is how to manage the credentials in the code for cloud service authentication. Protecting these credentials is an important task. Ideally, these credentials will never appear on the developer's workstation and will not be checked into the source code management system. Although Azure Key Vault can be used to securely store credentials, secrets, and other keys, the code needs to be authenticated by Key Vault to retrieve them.

The Azure resource managed identity feature in Azure Active Directory (Azure AD) can solve this problem. This feature provides an automatic managed identity in Azure AD for Azure services. You can use this identity to prove identity to any service that supports Azure AD authentication, including Key Vault, without putting any credentials in the code.

How the Azure resource hosting identity works:

There are two types of managed identities:

The system assignment managed identity is enabled directly on the Azure service instance. When identity is enabled, Azure creates the identity of the instance in the Azure AD tenant that is subscribed to the instance. After the identity is created, the system pre-allocates the credentials to the instance. The life cycle of the system allocation identity is directly bound to the Azure service instance on which it is enabled. If the instance is deleted, Azure automatically cleans up the credentials and identity in the Azure AD.

The user assignment managed identity is created as a separate Azure resource. During the creation process, Azure creates an identity among the Azure AD tenants trusted by the subscription being used. After you create an identity, you can assign the identity to one or more Azure service instances. The life cycle of the user assignment identity is managed separately from the life cycle of the Azure service instance to which it is assigned.

The following figure shows how the managed service identity works with the Azure virtual machine (VM):

The system assigns how the managed identity works with Azure VM:

1. Azure Explorer received a request to enable system allocation of managed identities on VM.

2. Azure Explorer creates a service principal corresponding to the VM identity in Azure AD. The service principal is created in the Azure AD tenant trusted by this subscription.

3. Azure Explorer configures the identity on VM: updates the Azure instance metadata service identity endpoint with the service principal client ID and certificate.

4. After VM is identified, grant VM access to Azure resources based on the service principal information. To invoke Azure Explorer, use role-based access control (RBAC) in Azure AD to assign the appropriate role to the VM service principal. To call Key Vault, grant code access to a specific secret or key in Key Vault.

5. Code running on VM can request a token from one endpoint that can only be accessed from VM (the other has been deprecated):

Azure instance metadata Service identity Endpoint (recommended): http://169.254.169.254/metadata/identity/oauth3/token

The resource parameter specifies the service to which you want to send the token. To authenticate to Azure Explorer, use resource= https://management.azure.com/.

The API version parameter specifies the IMDS version, please use api-version=2018-02-01 or later.

6. Azure AD is called to request an access token using the client ID and certificate configured in step 3 (specified in step 5). Azure AD returns the JSON Web token (JWT) access token.

7. The code sends an access token when calling a service that supports Azure AD authentication.

How the user assigns managed identity to work with Azure VM:

1. Azure Explorer receives a request to create a user to assign a managed identity.

2. Azure Explorer creates a service principal in Azure AD that corresponds to the managed identity assigned by the user. The service principal is created in the Azure AD tenant trusted by this subscription.

3. Azure Explorer received a request to configure the user assignment managed identity on VM: update the Azure instance metadata service identity endpoint with the user assignment managed identity service principal ID and certificate.

4. After you create a user to assign a managed identity, grant the identity access to the Azure resource based on the service principal information. To invoke Azure Explorer, use RBAC in Azure AD to assign the appropriate role to the user's identified service principal. To call Key Vault, grant code access to a specific secret or key in Key Vault.

5. Code running on VM can request a token from one endpoint that can only be accessed from VM (the other has been deprecated):

Azure instance metadata Service identity Endpoint (recommended): http://169.254.169.254/metadata/identity/oauth3/token

The resource parameter specifies the service to which you want to send the token. To authenticate to Azure Explorer, use resource= https://management.azure.com/.

The API version parameter specifies the IMDS version, please use api-version=2018-02-01 or later.

6. Azure AD is called to request an access token using the client ID and certificate configured in step 3 (specified in step 5). Azure AD returns the JSON Web token (JWT) access token.

7. The code sends an access token when calling a service that supports Azure AD authentication.

=

Here is a brief description of how to use a Windows virtual machine with the system-assigned managed identity enabled to access the Azure explorer API

Click access Control under the resource group, and then add a role assignment

Select a role and assign access to the virtual machine

Then log in to the virtual machine, open powershell, and execute the following command. Using Invoke-WebRequest cmdlet, make a request to the locally managed identity of the Azure resource endpoint to obtain an access token for Azure Explorer.

$response = Invoke-WebRequest-Uri 'http://169.254.169.254/metadata/identity/oauth3/token?api-version=2018-02-01&resource=https://management.azure.com/'-Method GET-Headers @ {Metadata= "true"}

Next, the complete response is extracted and stored in the $response object in the form of a JavaScript object representation (JSON) format string.

1. $content = $response.Content | ConvertFrom-Json

The access token is then extracted from the response.

1. $ArmToken = $content.access_token

Finally, invoke Azure Explorer with an access token. In this example, we also use Invoke-WebRequest cmdlet to invoke Azure Explorer and include the access token in the authorization header.

(Invoke-WebRequest-Uri https://management.azure.com/subscriptions//resourceGroups/?api-version=2016-06-01-Method GET-ContentType "application/json"-Headers @ {Authorization = "Bearer $ArmToken"}) .content

Information about the resource group is displayed after the command is executed.

In order to verify permissions, we ask for information from other resource groups, which will prompt you that you do not have permission to read.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.