We Have Automated scripts that we would like to build and Test on Azure DevOps but our pipeline cannot run our Test Scripts on Azure
We have a Database Service Account that we want to configure on Azure but we don't know how to go about it. Please assist.
Here is a well explained video (by Hassan Habib from Microsoft) on exactly how to run a console app (you create) in an Azure Pipeline that securely gets credentials to immediately do stuff in Azure (https://youtu.be/ht0xhQyF1x4?t=1688)
He basically, in a handful of minutes shows exactly how to:
Link Pipeline Variables to KeyVault Secrets, so when accessed, the variables do a get() from KeyVault and return that value.
Securely links Pipeline Variables to Azure Environment Variables.
As a step in the release pipeline the console app reads the Azure Environment Variables to get credentials to do stuff in Azure.
In his case he created an Azure Resource Group in Azure.
In your case if I’m understanding correctly. You could possibly make a simple console app that runs in the pipeline, that gets creds\connections strings for your database to do whatever in the DB and could possibly test your scripts.
Related
we have azure devops pipelines to build and deploy various projects.
Rccently, we wanted to use the "azureblog file copy" pipeline to copy some files to a blob storage.
This needs write access to the storage account over in azure.
Our administrator says that the pipeline runs as whoever manually runs the pipeline. If this is true, we would have to give all devs and users read/write access to the blog storage, which would be crazy.
I assume he is wrong, and that pipelines run as a specific designated user no matter how they were kicked off. The question is, how to find out what this user is for a given pipeine?
The "edit pipeline" has a security tab near the top, adn this lists a but of "Azure Devops groups", which are presumably groups who have the ability to run the pipelines.
But where is the pipeline user defined?
which user do Azure devops pipelines run as?
It depends on the context in which you are discussing the question.
If you mean inside a pure DevOps service, then I can tell you that the user that the pipeline runs on is not the one who triggers the pipeline (which is the case with native DevOps services by default, unless you install some weird extension or have a problem with the pipeline special design), but this identity:
<Project Name> Build Service Account
'run as someone' is just a property of pipeline run. Pipeline run as 'Build Service Account'(On the DevOps side), If you need a pipeline to download or upload an artifact, you can clearly feel this. If the account mentioned above has no permission, you can't do anything.
If you mean the user's operations based on the Azure side, then I can tell you that for native DevOps service, the 'user' that the pipeline performs operations on the Azure side is not the person who triggers the pipeline. The pipeline of DevOps service consists of multiple tasks, and tasks generally interact with other services through service connection (you can find this in Project settings).
There are many types of service connections. When interacting with services in Azure, this type is generally used:
Azure Resource Manager -> Service principal
When you create a service connection of this type on the DevOps side, Azure will also create an AAD app related to this service connection, and this ADD app corresponds to a service principal in Azure. In Azure, permissions are assigned based on service principals or users, and your DevOps pipeline's operations to Azure are based on this service principal and have nothing to do with anything else in DevOps. On the Azure side, this service principal can be considered as an Azure-side 'avatar' of the tasks of the DevOps pipeline.
If you are interacting with Azure through pure code/pure script, then please follow the logic of the script/code.
Our administrator says that the pipeline runs as whoever manually runs
the pipeline. If this is true, we would have to give all devs and
users read/write access to the blog storage, which would be crazy.
For native DevOps service, of course not. Unless this pipeline has a special design.
I believe the pipeline runs as the "agent". Who the "agent user" is will depend on, first, whether you've chosen a "Microsoft-hosted" or "self-hosted" agent to run your pipeline.
When running pipelines in Azure DevOps that are directly working with Azure Resources you need an Azure Resource Manager service connection. The credentials used to make the service connection are the credentials the pipeline will use when it runs.
You can have your administrator provide you with an Azure AD account that has the permissions you need and then use that Azure AD account to create the service connection for the pipeline. Once you have created the service connection you can use the ResourceID of that connection in place of you azureSubscription.
Here is the link to the Microsoft documentation on creating a service connection.
Here is the link to the Microsoft documentation on the Azure file copy task. To verify you can use the service connection in place of the azureSubscription.
I am trying to wrap up my mind around this process.
I have a SQL Server in azure. This server has a Azure Active Directory Admin enable using an azure group to authenticate using MFA.
Further more, in the same blade, I have enabled the Support only Azure Active Directory Authentication for this server.
Everything works just fine, and I am able to connect to my server by using MFA as I am part of the Active directory.
Now, I am a disaster and most of the time I forget to update my database schema, and when I deploy some tests, everything explodes.
I have been looking around for an automation process to authenticate with azure DevOps and run a sql script every time my release pipeline is triggered.
I came across this documentation
https://learn.microsoft.com/en-us/powershell/module/sqlserver/invoke-sqlcmd?view=sqlserver-ps
Which seems to be just what a need as it has the --InputFile.
but I am having some problems to understand how I can authenticate my release pipeline and perform those changes using an AAD to access the DB without having to expose username and password.
If anyone can help me to understand what its the best approach here iw ill be grateful.
And please if my question is not 100% clear, just let me know and I will explain better
An alternative would be to write a script which will do all the sql queries instead of doing it in pipeline. This way we can using azure ad to authenticate.
Register the sql service to the azure ad then we can get tokens to authenticate the sql queries.
finally run the script in pipeline using command line task
Reference:
how to run script
authenticate using azure ad
we have automated the following steps using azure devops
A Release pipeline which creates a website in azure and the next step which deploys the code, all is well and working so far
The next step that we need to do is create a Azure SQLDB and and an Azure Storage Account in the release pipeline and then configure these values in the appsettings.json file
Questions
Creating the Storage account is the easy part, but how do we get the storage account key back in the pipeline and associate that value in the appsetting.json file ?
Similarly for the SQLDB how do we get the IPAddress and add it in the exclusions list.
and also it you could point us to any documentation on this
how do we get the storage account key back in the pipeline.
You can use the Azure CLI az storage account keys to get storage account keys.
Is there a way to require that Azure Functions be updated through an Azure pipeline, and not someone using the VSCode integration or azure functions core tools CLI?
I don't believe that there is a direct way to restrict deployment by method (AZ CLI, Az Powershell, Azure DevOps, Azure Portal, etc.), as ultimately most everything in Azure goes through REST APIs, ARM templates, etc.
What you can do is to organize your functions into a resource group or groups, to which you limit Contributor/Administrator/Owner access to the service principal associated with your Azure DevOps service connections. Allow other users the ability to read/inspect resources in that group, but only allow the service principal the right to create objects there. You may also need to allow the managed identities greater privileges to operate within that space, but the concept remains the same - limit the autonomy of interactive users in the space where your Azure Functions live.
We need to create and Key Vault and populate it (or generate) with secrets, then reference them as passwords to SQL servers (PaaS) at the next build step. What would be the best approach to do that?
There are many ways to create/update Azure Key Vault, such as Azure PowerShell, Azure CLI, REST API, also there are Azure PowerShell and Azure CLI tasks in VSTS build/release. So do it with Azure PowerShell or Azure CLI.
To create/update the variable in build/release, you can use Logging Command (##vso[task.setvariable]value), then the variable can be used in subsequent task.
On the other hand, if you just want the variable secret, you just need to add a build or release variable and click lock icon to set the variable secret.