I am trying to make my deployments more safe by having credentials information in a separate file and not pushing it to GitHub. The problem is that I have synced the repo with Azure enabling continuous development.
Because the config file is ignored, when the Azure App seeks for the code from GitHub, it cannot find the config file and therefore not being able to read the information.
How can I overcome this? Thanks.
I'll recommend you to look into Azure DevOps. (Free for up to 5 users)
It will give you the opportunity to manage your deployments using pipelines. You don't need to host your code in the Azure DevOps Git. You are free to keep using GitHub for source control.
I'm not a big fan of the built-in "Deployment Center" inside the Azure Services like an "App Service". You will be very limited in customization compared to a Pipeline.
For keeping secrets secure in deployment. You can make use of Key Vault References.
https://learn.microsoft.com/en-us/azure/app-service/app-service-key-vault-references
Related
I am trying to determine how to backup the online ADO account that I created on Microsoft's servers so that I can restore it on my own physical server. I have a few projects already started along with work items, repositories, pipeline jobs and NuGet artifacts already in place. It would take quite a while to rebuild the projects manually, not impossible, just not desirable.
I have looked and have not found any resource as to how to perform this or if it is even possible. Any help from someone who knows would be greatly appreciated!
Currently there is available extension: Azure DevOps Migration Tools, which allow you to migrate Teams, Work Items, Plans & Suits, and Shared Queries, & Pipelines from one Project to another in Azure DevOps/TFS both within the same Organization, and between Organizations. See: https://nkdagility.github.io/azure-devops-migration-tools/ for latest guidance.
In addition, for repositories, there is no such extensions, you could try to clone an existing Git repo and then push it to a new remote repo server.
BTW, you could use Rest APIs: Artifact Details to get artifacts and then publish them to new feed on Azure DevOps Server.
I'm working on an asp.net core project and I'm trying to figure out how to keep my source and my pipelines 100% secret free.
I've got a VM running the azure agent and an azure dev ops pipelines for build and release.
If i delete the site on the VM, the release pipeline will auto-magically recreate it for me and deploy the latest build.
Super cool.
Now I read up on best practices for configuring a .Net core app and I found this article: https://www.humankode.com/asp-net-core/asp-net-core-configuration-best-practices-for-keeping-secrets-out-of-source-control
So its a bad idea to keep secrets in code, that makes perfect sense.
But if i apply the same security principals to Yaml, then surely I shouldn't place secrets in my pipelines either.
But I need the pipelines to be able to just recreate the site from scratch and it should just work. Somehow the site needs to know where its default sql connection is, or it needs to have a key to the azure app config service. I shouldn't have to log onto the VM and create an appsettings.json manually after every release!
So whatever the site needs to operate needs to be included in the pipeline, therefore some artifact, or included in the code.
I've googled for days, but I can't seem to find any info on how to fully automate this.
I've considered creating a custom configuration provider that reads from the actual VM registry, but that feels wrong too.
I basically need a config option that is NOT hosted in the site itself. So i set it up once on the VM and never again.
The approach that Lex Li lists in the comments is the Microsoft recommended way of securing "secrets" in pipelines.
Ben Smith's answer in my opinion is just as good, maybe slightly less secure.
I use this approach in our organization. All of our release pipelines do the final configuration transformation with the appropriate settings based on the environment they are being deployed to.
i.e db connections are transformed at the dev, test and UAT and production deployment stages.
I keep the relevant secrets in the pipeline variables as protected secrets. I do this for 2 reasons:
Only a select number of trusted personnel have access to the release pipeline definitions.
Even if someone does have access to those definitions - you cannot see a secured variable. Even you you "undo the padlock" on the variable tab - you cannot see what the setting is.
Our actual secrets are then stored in our enterprise secret vault.
Using the Azure Key Vault is definitely a good approach. However we already have a centralized place to keep our stuff; I don't want it in 3 spots.
I would be remiss to not include Variable Groups as part of the pipeline process. Same concept as the build / release variables - the difference is you can now share them in one spot.
These are all opinions of course. This is just one way of doing this; which I feel is a pretty good balance of security and flexibility.
In addition to the suggestions in your questions comments, you can also store secrets in the pipeline "Variables" section.
In here you can add variables and then mark them as secret by selecting "Keep this value secret". Once you've saved a secret its value is then obfuscated i.e. you can make use of it but you can no long see its original value within Azure Devops (which admittedly can be rather frustrating if you want to revisit the variable to check it!).
You can then reference the secret variable in your pipeline YAML using the syntax:
$(variable-name)
So this approach keeps secrets safe within Azure Devops until they need to be resolved by the pipeline YAML script.
I have used this documentation to setup continuous deployment on Azure functions with git-hub. Now I have successfully setup git-hub repository in Azure function for continuous deployment.
I am able to see APP settings in local.settings.json file. But I want to know how to configure Connection strings (SQL Connection strings) in continuous deployment.
You want to keep your sensitive data out of your source code repository. That being said, app.settings.json of any kind is not an option.
You have several options there. Two mostly used are either Azure Vault or Azure AppSettings where you can set key/value pairs which are then available to your app either through settings (merged with other settings) or through environment variables.
I use second approach with env variables access to AppSettings.
This link might help:
https://www.hanselman.com/blog/BestPracticesForPrivateConfigDataAndConnectionStringsInConfigurationInASPNETAndAzure.aspx
The documentation that you've referred to is sort of a "quick and easy" continuous deployment option for Functions that gets you up and running quickly. It's not ideal for a production environment though, as you've discovered there is no way to parameterize your app settings. In order to build a proper build/release pipeline you'll need to move away from the direct Git integration and use something like VSTS which you can configure properly against multiple environments including the ability to set AppSettings and ConnectionStrings properly. Based on the approach you've taken currently, your only option is to go into the Azure Portal and manually configure AppSetting and ConnectionStrings in your function app directly.
This blog post covers a lot on the topic and shows one approach for accomplishing what you're after:
https://blogs.msdn.microsoft.com/visualstudioalmrangers/2017/10/04/azure-function-ci-cd-devops-pipeline/?utm_source=vs_developer_news&utm_medium=referral
Configuring a complete CI/CD pipeline is a bit involved (as you'll be able to see from the link) so there's no easy answer that can fit right into a StackOverflow post. I highly recommend that you read through that and do some more research on Google around the VSTS and Functions integrations.
What I want to accomplish:
I want to deploy an Azure Cloud Service via Release Management. I managed to get this working by following the steps outlined in this post. In the post the Azure publishsettings file is added to the project and used in Release Management to deploy the Azure package to a Cloud Service. So far so good.
What is the issue:
The Azure publishsettings file will also contain information about the production environment. I don't want that information to be available to all the developers and therefor I would like to have a more secure alternative.
What did I try:
I created a custom action which takes 3 arguments: subscription id, subscription name and certificate key. This way the Azure information stays in Release Management and can be passed to a script. This didn't work because the action is not shown in the Release Template Toolbox.
What is my question:
What is the best way to pass Azure credentials to a deployment script via Release Management on a secure manner?
We have a solution for Build today that will work for RM in the future.
Publish Settings file is an important one with which anybody can get access to certain activities. And once how ever the way you pass on the publish settings file, it can be misused (if tried).
So along with the publish settings file, you need to add a bit of process to the deployment like -
Inactive or remove the management certificate which will in turn invalidate the given publish settings and anyone should request for a new set of publish settings file before they actually start any release procedures.
Even though it adds a rough edge to your smooth flow of deployment process, as it is a live or production system, it is always better to tight the process and make it idiot proof.
We have a VSO repository with multiple sites in the same solution. We want to be able to deploy our sites independently of each other to Azure with continuous delivery. Right now the first site alphabetically is deployed to all our sites which of course is not desirable.
Is this possible to achieve?
I have tried to set the Project key to the correct csproj in App Settings like suggested here: https://github.com/projectkudu/kudu/wiki/Customizing-deployments without any success. Maybe Kudu is not used for VSO?
Any help would be greatly appreciated!
You should move away from trying to do this in a build, especially if you want that level of control.
You have Release Management Online provided with your VSO account and can use the Release Management client to configure your releases.
I believe that you can right-click on your Build and have an appropriate starter release template created when configured.
http://nakedalm.com/create-release-management-pipeline-professional-developers/
Here is an example of and end to end deployment with a web app. Deploying to Azure with RM is Childs play...