Open ElvenSpellmaker opened 2 years ago
dingmeng-xue
commented
2 years ago @ElvenSpellmaker , do you know base image of non-working environment? Could you help check version of Linux distro? We are not familiar to vsts_azpcontainer. Please share us how you use it in ADO. We will try to reproduce it.
ElvenSpellmaker
commented
2 years ago @ElvenSpellmaker , do you know base image of non-working environment? Could you help check version of Linux distro? We are not familiar to vsts_azpcontainer. Please share us how you use it in ADO. We will try to reproduce it.
Hi there, AzDo runs the container and then injects its own user into the container and runs the tasks under that user.
This is roughly how it's used in AzDo in the Pipeline:
containers:
- container: az_pwsh
image: mcr.microsoft.com/azure-powershell:latest
...
pool:
vmImage: 'ubuntu-20.04'
...
- job: AzCommandsToRun
container: az_pwshAnd then it's called via a task:
- task: PowerShell@2
displayName: "Login: Azure CLI"
inputs:
filePath: "${{ parameters.pipeline_scripts_directory }}/Azure/set-pwsh-az-context.ps1"
arguments: >
-clientID '${{ parameters.azureClientID }}'
-clientSecret '${{ parameters.azureClientSecret }}'
-tentantID '${{ parameters.azureTenantID }}'
-subscriptionID '${{ parameters.azureSubscriptionID }}'I hope that helps a bit
KANNIBALAMK
commented
2 years ago Hi
I don't want to pass the ClientId/SecretID as parameters. Want to get it dynamically while deploying through CI CD. How to achieve it?
dingmeng-xue
commented
2 years ago @ElvenSpellmaker , My understanding is task PowerShell still runs on agent pool image ubuntu-20.04. Please install Azure PowerShell module at first. You also can leverage another ADO task AzurePowerShell which will handle authentication Connect-AzAccount internally.
ElvenSpellmaker
commented
2 years ago @dingmeng-xue Not quite as the job is run under the container:
- job: AzCommandsToRun
container: az_pwshThis means Azure DevOps will inject its own node into the container and run the tasks in this case PowerShell@2 within the container.
As the module moved to root between the two SHAs listed it can't be accessed any more by the non-root user.
dingmeng-xue
commented
2 years ago @KANNIBALAMK , 2 choices in my mind if you are using Azure DevOps
You need to create a service connection to target subscription, and then create a task AzurePowerShell with that connection. Task will help you to handle authentication. You only need to add azure powershell cmdlet to do operations on Azure.
Define appid and secret as pipeline variable. and use them in your script. Here is one example https://github.com/Azure/azure-powershell/blob/76c8995ba80e5976d421003be1922490e0de1261/.azure-pipelines/util/smoke-test-steps.yml#L94. We use it to do smoke test in ADO pipeline.
Description
Azure DevOps uses the
vsts_azpcontaineruser which it directly injects into the container at run-time.This breaks the build as the module seems to have moved from
/usr/local/share/powershell/Modulesto/root/.local/share/powershell/Moduleswhich obviously can't be accessed by non-root users.The container that works:
The container that doesn't:
As you'll see the location, of the module has moved which breaks non-root users such as those injected by Azure DevOps:
This appears similar to #18928 but I'm not sure it it's the same cause.
SHA of an image that worked and didn't: ✅:
sha256:163586739f74a02282a4c2b7f12805b596d6ada983a0ff729196af18ec8c823a❌:sha256:d7da797d627a135b31acb15329c8a949f06caa963e7c99fc04e63b70d839df75Issue script & Debug output
set-pwsh-az-context.ps1:The
Import-Module -Name Azwas added to see if trying to import it would work, but it doesn't as the user doesn't have access to/rootwhere the module now resides.Environment data
Tag was
latestwhich is how we noticed the problem, the SHA that doesn't work is:sha256:d7da797d627a135b31acb15329c8a949f06caa963e7c99fc04e63b70d839df75Module versions
Error output