Unable to get the service connection for Azure Container Registry in Azure DevOps (Release Pipeline) - azure-devops

I'm trying to deploy the docker container on Azure App Service from Azure DevOps services. I've pushed the docker image to Azure Container Registry. When I try to create the release definition, I could not able to find the service connection for Azure Container Registry. I have created the service connection for ACR but it's not showing up in the list in Azure DevOps portal.
When I selected 'Azure Container Repository' as the source type, the service connection is not visible in the drop down box. I'm using DockerHub as another option. It's displaying the service connection in the list.
The steps I followed to create the service connection for ACR:
Selected Docker Registry from the list.
Selected Azure Container Registry as Registry Type. Provided the subscription ID and the registry from ACR.
Provided the service connection name and saved.
UPDATE
I have created service connection for Azure Resource Manager using managed identity authentication by providing both subscription id and tenant id. I'm trying to use this connection in Artifact settings. I got the below error.
Variable with name endpoint.serviceprincipalid could not be found for the given service connection.
It's failing to pull the docker image from ACR. The logs from App service shows the pull access denied for the repository.
Service Connection problem solved but facing docker permission issue from App service
2020-02-10 12:31:11.781 INFO - Pulling image from Docker hub:
kbdockerregis/kbdockerimage:15
2020-02-10 12:31:14.406 ERROR - DockerApiException: Docker API responded with
status code=NotFound, response={"message":"pull access denied for
kbdockerregis/kbdockerimage, repository does not exist or may require 'docker
login': denied: requested access to the resource is denied"}
2020-02-10 12:31:14.408 ERROR - Image pull failed: Verify docker image
configuration and credentials (if using private repository)
2020-02-10 12:31:14.412 INFO - Stoping site kbapp1 because it failed during
startup.

When I selected 'Azure Container Repository' as the source type, the
service connection is not visible in the drop down box.
For this first issue, this because the api our system used is shown as below while you choosing ACR as release source:
https://dev.azure.com/{org}/{project}/_apis/serviceendpoint/endpoints?type=azurerm
You can see the parameters this api attached is type=azurerm. It only fetched the service connection which type is Azure Resource Manager. But Container Registry does not belong to this.
So, you'd better to create and use a service connection which type is Azure Resource Manager type.
Variable with name endpoint.serviceprincipalid could not be found for
the given service connection.
For this second issue, haven't get too much info from you (like checking stake trace). So based on my known, I'd suggest you changed the type from Managed Identity Authentication to Service Principal Authentication. Then follow this doc to config it.
This is more secure and can authorized firstly.
Service Principal Client id, it is the application id after you create the app in Azure app registrations:
Service principal key:
Stack overflow is a open forum and not secure to share some key info(especially Fiddler trace) which I need and used to investigate from backend. You'd better go here because you could choose Microsoft Only there. If possible, I can go that community and let that community's engineer show it to me. So that I could continue dig into it.

Related

Why is my GCP image failing to deploy to local kubernetes?

I am getting "can't be pulled" when I use Cloud Code plugin in VS code to build and deploy an image to a local Kubernetes cluster. There are no errors being logged on GCP, but locally I'm getting the following:
- deployment/<redacted> failed. Error: container <redacted> is waiting to start: gcr.io/<redacted>/<redacted>:latest#sha256:<redacted> can't be pulled.
If your GCR registry is a private registry then you need to configure your local Kubernetes cluster with an imagePullSecret to use to authenticate to GCR. The general process is to create a service account in your GCP project, and then configure the corresponding service account key file as the pull secret.
There are a variety of tutorials, and this one looks pretty good.
Can you try gcloud auth list and check if you are using the right account? To switch account use gcloud auth login <account>
Also make sure you have the right permission : gcloud permission to pull GCP image
Once these two things are in place then you should be able to pull the image for GCR.

Can't use Managed Service identity (MSI) for App Service deployment with hosted Microsoft agent

We have a release pipeline that is failing with following message:
resource ID for resource type 'Microsoft.Web/Sites' and resource name
'appservicename'. Error: Could not fetch access token for Managed
Service Principal. Please configure Managed Service Identity (MSI) for
virtual machine 'https://aka.ms/azure-msi-docs'. Status code: 400,
status message: Bad Request
We have 2 different service connections:
Azure Resource Manager using service principal authentication
Azure Resource Manager using managed identity authentication
The first one works like a charm. However, because the developer wanted to limit admin access on the Azure AD, he tried creating a managed identity authentication service connection which at first glance, since it allowed us to select the App Service, appeared to indicate it's working, until an actual deployment was triggered and it failed per the error message above.
After numerous searches online, I think this answer may be the clue to why this is failing with the managed identity authentication service connection yet succeeding with the service principal connection just fine.
I just want to confirm, is this truly the case? that a hosted agent doesn't support MSI based authentication, which is what we are using… or has that changed?
We are indeed using Microsoft agent pool.
It doesn't make sense for our app service to use a VM at this time. The use case just isn't applicable for the dashboards we have.
As it is written in the docs:
You are required to use a self-hosted agent on an Azure VM in order to use managed service identity
I assume that it was alway like that. Here we are talking abut MSI assigned to VM which serves as build agent. Not MSI which is identity of App Service. Why? Service Connection is an abstraction which makes easy authentication to your Azure Subscription. So it gives identity to VM and then when your perform some action against your Azure thanks to MSI Azure know that can perform that action. Another aption is authentication via Service Principal, but thi can be done from any VM (inlcuding MS Hosted) because it relies on Client Id and Client secret which is kept in service connections. And MSI have to be assigned to particular VM which cannot be done with MS Hosted agents.

Create Service Connection from Azure DevOps to GCP Artifact Registry

Is there have any tutorials for creating a service account to GCP Artifact Registry?
i have tried this: https://cloud.google.com/architecture/creating-cicd-pipeline-vsts-kubernetes-engine
... but it is using GCP Container Registry
I do not imagine it should be much different but i keep on getting this:
##[error]denied: Permission "artifactregistry.repositories.downloadArtifacts" denied on resource
BUT the service account i created has the permissions needed (albeit those roles are in beta). i even gave it a very elevated role and still getting this.
when i created the service connect i followed these steps from the documentation linked above:
Docker Registry: https://gcr.io/PROJECT_ID, replacing PROJECT_ID with the name of your project (for example, https://gcr.io/azure-pipelines-test-project-12345).
Docker ID: _json_key
Password: Paste the content of azure-pipelines-publisher-oneline.json.
Service connection name: gcr-tutorial
Any advice on this would be appreciated.
I was having the same issue. As #Mexicoder points out the service account needs the ArtifactRegistryWriter permission. In addition, the following wasn't clear to me initially:
The service connection needs to be in the format: https://REGION-docker.pkg.dev/PROJECT-ID (where region is something like 'us-west2')
The repository parameter to the Docker task (Docker#2) needs to be in the form: PROJECT-ID/REPO/IMAGE
I was able to get it working with the documentation for Container Registry.
my issue was with the repository name.
ALSO the main difference when using Artifact Registry is the permission you need to give the IAM service account. Use ArtifactRegistryWriter. StorageAdmin will be useless.

Kubernetes service connections in azure devops w/ AAD bound AKS cluster

Will kubernetes service connections in azure devops work with an AKS cluster that is bound to AAD via openidconnect? Logging into such clusters goes through an openidconnect flow that involves a device login + browser. How is this possible w/ azure devops k8s service connections?
Will kubernetes service connections in azure devops work with an AKS
cluster that is bound to AAD via openidconnect?
Unfortunately to say, no, this does not support until now.
According to your description, what you want to connect with in Azure Devops Kubernetes service connection is Azure Kubernetes service. This means you would select Azure Subscription in Choose authentication. BUT, this connection method is using Service Principal Authentication (SPA) to authenticate, which does not yet supported for the AKS that is bound with AAD auth.
If you connect your AKS cluster as part of your CI/CD deployment in Azure Devops, and attempt to get the cluster credentials. You would get a warning response which inform you to log in since the service principal cannot handle it:
WARNING: To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code *** to authenticate.
You should familiar with this message, it needs you open a browser to login in to complete the device code authentication manually. But this could not be achieve in Azure Devops.
There has a such feature request raised on our forum which request us expand this feature to Support non-interactive login for AAD-integrated clusters. You can vote and comment there to advance the priority of this suggestion ticket. Then it could be considered into the develop plan by our Product Manager as soon as possible.
Though it could not be achieved directly. But there has 2 work around can for you refer now.
The first work around is change the Azure DevOps authenticate itself from AAD client to the server client.
Use az aks get-credentials command and specify the parameter --admin with it. This can help with bypassing the Azure AD auth since it can let you connect and retrieve the admin credentials which can work without Azure AD.
But, I do not recommend this method because subjectively, this method is ignoring the authentication rules set in AAD for security. If you want a quick method to achieve what you want and not too worry about the security, you can try with this.
The second one is using Kubernetes service accounts
You can follow this doc to create a service account. Then in Azure Devops, we could use this service account to communicate with AKS API. Here you also need to consider about the authorized IP address ranges in AKS.
After the service account created successfully, choose Service account in the service connection of Azure Devops:
Server URL: Get it from the AKS instance(API server address) in Azure portal, then do not forget append the https:// before it while you input it into this service connection.
Secret: Generate it by using command:
kubectl get secret -n <name of secret> -o yaml -n service-accounts
See this doc: Deploy Vault on Azure Kubernetes Service (AKS).
Then you can use this service connection in Azure Devops tasks.

Azure Resource Manager Service Connection not connecting

We currently have one DevOps repository, with a functional CI/CD pipeline. We have another website hosted on a different instance (and different region) on Azure. We are trying to use our existing repo to deploy to the other Azure instance, but it is giving is the following message:
Failed to query service connection API: 'https://management.azure.com/subscriptions/c50b0601-a951-446c-b637-afa8d6bb1a1d?api-version=2016-06-01'. Status Code: 'Forbidden', Response from server: '{"error":{"code":"AuthorizationFailed","message":"The client '2317de35-b2c2-4e32-a922-e0d076a429f5' with object id '2317de35-b2c2-4e32-a922-e0d076a429f5' does not have authorization to perform action 'Microsoft.Resources/subscriptions/read' over scope '/subscriptions/c50b0601-a951-446c-b637-afa8d6bb1a1d'."}}'
I have tried all of the recommended trouble-shooting, making sure that the user is in a Global Administrator role and what-not, but still not luck. The secondary Azure subscription that we are hoping to push our builds to is a trial account. I'm not sure if it being a trial account matters.
I came across the same error. It turns out that, as the error message states, the service principal didn't have Read permission over the subscription. So the solution was to go to Azure Portal, select the subscription, select IAM and assign the role Reader to my service principal. Full explanation on here:
https://clydedz.medium.com/connecting-azure-devops-with-azure-46a908e3048f
I have the same problem. There are one repository and two instances of the application on the Azure portal. For the first instance, the subscription Pay-As-You-Go is used, and there were no problems for it when creating the service connection and CI/CD settings. For the second instance, a free subscription is used and when trying to create a new service connection (Azure Resource Manager) I get the same error.
I tried to do it with the permissions of Owner and Contributor
UPD: I was helped by the re-creation of the application in the azure portal
https://learn.microsoft.com/en-ca/azure/active-directory/develop/howto-create-service-principal-portal
Another option would be to save without verification if the Service Principle will not require permissions at the Subscription level. Like for example providing access to a Keyvault.
Check if the service connection for the second instance is correctly added in project settings: