AD Service Principal for Azure Container Registry from Azure Batch container configuration? - powershell

I am trying to use Docker images from an Azure Container Registry as tasks in Azure Batch. In the Docker CLI, I can authenticate to the ACR using an Active Directory Service Principal's credentials, with the application ID as the username and the key as the password, as per the ACR documentation.
When I attempt to use the web portal to manually enter those credentials in the a new pool VM container registry settings, I receive the following error on submission:
The value provided for one of the properties in the request body is invalid.
The maximum length of user name that can be specified on a containerRegistry is 20
If I use the AzureRm.Batch Powershell module cmdlets, the pool is created however the containerRegistry and containerImages properties are null.
Can this AD SP authentication method be used with Azure Batch VM container registration configuration? Do I need to use a specific SDK to accomplish this?

This was fixed on March 16th, 2018.

Related

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.

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

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.

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.

Get client id and client secret from Service connection in release step

In the Azure DevOps portal I created a Service connection for Azure RM. It works correctly. Now I want to get client Id and client secret in release step (by using PowerShell) when I'm authenticated with this Service connection. Is it possible?
You can use the Get-AzureAdApplicationPasswordCredential cmdlet to get the password credential for an application.
Here is the offical documentation. https://learn.microsoft.com/en-us/powershell/module/azuread/get-azureadapplicationpasswordcredential?view=azureadps-2.0

Deploying Service Fabric secured by Azure Active Directory from PowerShell

I am trying to publish to a service fabric cluster secured using Azure Active Directory from PowerShell calling Deploy-FabricApplication.ps1 as part of a TeamCity build configuration.
I have been unable to find how you provide credentials in this situation.
I did notice in Deploy-FabricApplication.ps1 that there is a SecurityToken parameter for Active Directory.
Is this what you need to pass to authenticate, and if so how can you generate the security token within PowerShell?
I have set up a user within my Azure Active Directory for TeamCity that I am hopping to authenticate as.
The token can be acquired by making use of the Active Directory Authentication Library (ADAL), specifically by calling the method AcquireToken in Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext.
A good example of this being used can be seen in the code for the VSTS Service Fabric Deploy task at: https://github.com/Microsoft/vsts-tasks/blob/master/Tasks/ServiceFabricDeploy/utilities.ps1.
There's a function in that file called Get-AadSecurityToken which shows the call to the AuthenticationContext.AcquireToken method.
You need to ensure that you have both the cluster app ID and the client app ID. Both of these are retrievable from the cluster by calling Connect-ServiceFabricCluster with the -GetMetadata switch (this is also done in the Get-AadSecurityToken function).