My pipe in bitbucket:
- pipe: microsoft/azure-cli-run:1.0.2
variables:
AZURE_APP_ID: $AZURE_APP_ID
AZURE_PASSWORD: $AZURE_PASSWORD
AZURE_TENANT_ID: $AZURE_TENANT_ID
Where is AZURE_APP_ID? On Azure -> App Services I can see a table with my apps but no application id. And what password is it? I haven't set a password anywhere. And tenant id?
First you need to create an Azure service principal in your azure subscription to enable connecting bitbucket to azure services.
When you create the service principal you will get a set of information after successful creation from which you can extract the app ID and tenant ID. This is via azure CLI.
az ad sp list --show-mine --query '[].{"id":"appId", "tenant":"appOwnerTenantId"}'
This information along with your azure password is what you need to supply to the bitbucket pipeline to enable deployment from your repo to azure.
Related
I'd like to create connection between pipeline in Azure devops and container registry.
Admins created Managed identity for me. I'd like to use that one but there is no way.
According to guide: https://learn.microsoft.com/en-us/azure/devops/pipelines/ecosystems/containers/publish-to-acr?view=azure-devops&tabs=javascript%2Cportal%2Cmsi&fbclid=IwAR2bV28HzRs8v-qTXuo592KU5KxOFnNsOvhxpNx0ZCBYfz2OPnYXWh7rqUs
I should be able to create connection with Authentication type: Managed Service Identity like on below screen:
In my case there is no way so select this option. I can only select Service Principial in Authentication type :
That's not what I want. Why is that? Is it related to lack of some permission? Is it maybe forbidden to connect via azure managed identity in the newest azure devops version?. I would be grateful for the answer.
I tried to reproduce your scenario in my environment and got below results:-
When I tried to Create a Service Connection with docker registry even I did not receive any option to Select Managed Service Identity refer below:-
I went to my Project settings and tried creating a service connection with Azure DevOps Managed Identity like below:-
Alternatively:-
You can create Managed Service Identity separately in Azure DevOps by selecting azure Resource Management tab like below:-
Create a managed Identity for your resource
Set Azure role assignments to the managed identity
Create Service connection for that managed identity like above
Include the service connection in the pipeline like below:-
- task: AzureCLI#2
inputs:
azureSubscription: 'acr12325'
Reference:-
Service connections in Azure Pipelines - Azure Pipelines | Microsoft Learn
I have researched the way to push docker images from gitlab container registry to an azure resource: Pushing Docker image from gitlab-ci to Azure Container Registry
I have also found the documentation to create managed identities (both system-assigned and user-assigned) in the Azure docs
I am missing to connect the dots on how I can use
az login —-identity in a gitlab-ci.ymlfile to access an azure app service. The purpose is to push a docker image from gitlab container registry.
How can I do this?
How do I need to configure the azure app service (identity / access control)?
Are there any security concerns? If yes, is az login —-service-principal a more secure way to do this? Or any other authentication procedure? ssh?
Thank you for your help in advance! 🙏
You can use a GitLab CI Job JWT token to login to Azure from within a CI/CD pipeline without needing to store secrets in a GitLab project. In order to do this, you will also need to configure OpenID Connect (OIDC) for ID federation between GitLab and an Azure service principal. This is recommended by Microsoft for authenticating to Azure from CI/CD services, among other use cases.
Note: Using OIDC as described below will only work if you are using gitlab.com or a publicly reachable GitLab instance. This is because Azure needs to connect to the token issuer for the keys to validate the token. If you are self-hosting GitLab and your instance is not publicly accessible, you can choose a different credential type for step 2.
1. Create a registered app
First, you will need to register an Application in Azure. You can do this by following these instructions to register an application and create a service principal.
After doing this, make note of the values for Application (client) ID and Directory (tenant) ID (found in the application Overview pane). These values will be needed for step 3.
2. Add the federated credentials
Once your app is registered, you can add federated credentials to the application's service principal. In the Azure portal, go to registered apps -> your application. In the sidebar, select Certificates & secrets. Under the Federated credentials tab, click the "Add credential" button
Use the following parameters for the credential configuration:
Federated credential sceanrio: Other issuer
Issuer: your gitlab URL e.g. https://gitlab.example.com
Subject Identifier: The value of the sub claim to match. For example, to allow jobs on the main branch of the contoso/myproject project to use this service principal, use project_path:contoso/myproject:ref_type:branch:ref:main
Name: Any descriptive name for the federated credental (e.g. contoso-myproject-main)
Description: Optional, a description for the federated credential.
Audience: your GitLab URL e.g. https://gitlab.example.com
3. Authenticate to Azure in your job
After the federated credentials are created, you can leverage the CI_JOB_JWT_V2 token in your job to authenticate with Azure. In this example, we'll use the Azure CLI (az login).
azure-cli:
image: mcr.microsoft.com/azure-cli
variables:
AZURE_CLIENT_ID: "YOUR Application Client ID"
AZURE_TENANT_ID: "YOUR TENANT ID"
script:
- az login --tenant $AZURE_TENANT_ID --service-principal -u $AZURE_CLIENT_ID --federated-token $CI_JOB_JWT_V2
# now you are logged into Azure and can take other actions using the CLI
# - az resource list # example
CI_JOB_JWT_V2: Predefined variable
AZURE_CLIENT_ID: The Application (Client) ID of the registered application.
AZURE_TENANT_ID: The ID of the Azure Tenant to login to (can be found in the application overview)
Also, don't forget to grant your registered app appropriate permissions for Azure container registry
I want to create a "Service Connection" using system.accesstoken of Azure devops instead of using "PAT" of the user.
what are the permissions that should be given to system.accesstoken to create a service connection.
I tried giving all the access to "Project Collection Build Service ({OrgName})", "{Project Name} Build Service ({Org Name})" identities. But it did not work.
You need to define role on service connection security tab for Project Collection Build Service (account):
I am looking at this example from the terraform docs for creating an azure group:
resource "azurerm_resource_group" "test" {
name = "testResourceGroup1"
location = "West US"
tags = {
environment = "Production"
}
}
It does not specify the subscription anywhere.
How can I specify the subscription?
For your issue, you know the Terraform deploy the Azure resources through the Azure CLI. And there are four ways to authenticate.
Authenticating to Azure using the Azure CLI
Authenticating to Azure using Managed Service Identity
Authenticating to Azure using a Service Principal and a Client Certificate
Authenticating to Azure using a Service Principal and a Client Secret
If you do not set the tenant Id and subscription Id in the Terraform code, then you must use the first method in default. And you authenticate via the Azure CLI with the account that you log in the Azure CLI. So which subscription you set in the CLI then you use it for your Terraform.
But as the Terraform recommend:
We recommend using either a Service Principal or Managed Service
Identity when running Terraform non-interactively (such as when
running Terraform in a CI server) - and authenticating using the Azure
CLI when running Terraform locally.
So that you could grant the more appropriate permission for the service principal as you want.
Subscription is set when you configure Terraform to log in to Azure. The recommended way is to use an Azure AD service principal and environment variables.
To configure Terraform to use your Azure AD service principal, set the following environment variables, which are then used by the Azure Terraform modules. You can also set the environment if working with an Azure cloud other than Azure public.
ARM_SUBSCRIPTION_ID
ARM_CLIENT_ID
ARM_CLIENT_SECRET
ARM_TENANT_ID
ARM_ENVIRONMENT
Reference
I'm trying to deploy a build to Azure WebApp.
In Azure (http://manage.windowsazure.com) I linked the web app to my Visual Studio Online(VSTS) account.
In VSTS I've created a release definition with a single task (Azure Web App Deployment); the task is configured to use the endpoint defined in the administration module. The service endpoint is configured to use credentials. The credential is using a Microsoft account.
The release is failing with the below error:
2015-12-02T18:17:35.4422685Z AzurePSCmdletsVersion= 0.9.8.1
2015-12-02T18:17:35.5692677Z Get-ServiceEndpoint -Name foo -Context Microsoft.TeamFoundation.DistributedTask.Agent.Worker.Common.TaskContext
2015-12-02T18:19:07.5877546Z Username= ********
2015-12-02T18:19:07.5887893Z azureSubscriptionId= foo-foo-foo-foo-foo
2015-12-02T18:19:07.5907904Z azureSubscriptionName= Pay-As-You-Go
2015-12-02T18:19:07.6278127Z Add-AzureAccount -Credential $psCredential
2015-12-02T18:19:09.7755541Z ##[error]-Credential parameter can only be used with Organization ID credentials. For more information, please refer to http://go.microsoft.com/fwlink/?linkid=331007&clcid=0x409 for more information about the difference between an organizational account and a Microsoft account.
2015-12-02T18:19:09.9664413Z ##[error]There was an error with the Azure credentials used for deployment.
How can I setup the release to use a Microsoft account for Azure credential?
There isn't any way to use a Microsoft Account Credential to connect to Azure from VSO service endpoint for now. You need to use an Organization account. If you don't have one, you can use "Certificate Based" authentication to connect to Azure easily. Click this link to get your subscription file and then paste the certification string in the subscription file into VSO "Management Certificate" area.
Add-AzureAccount cmdlet, uses Azure Active Directory (Azure AD) authentication access tokens and Azure AD uses Organizational Accounts.
Microsoft account credentials, formerly known as LiveIDs will not work in Azure AD authentication scenarios.
This is reported here as a suggestion and by design as of now:
https://github.com/Azure/azure-powershell/issues/477