We have enabled a CI/CD pipeline using azure pipeline. Whenever someone check in to the master, the build should happen and deployment should follow. I wanted to understand how can I disallow someone to deploy to azure function web app from local visual studio
You could use RBAC Rules which may require a lot of config work.
Once you have CI/CD pipeline enabled, setting up RBAC(Role Based Access Control) helps to prevent users from getting the publishing profile, setting deployment credentials etc.,
There will definitely be some config work involved in doing this because you would have to only allow permission to one user so that user could set up the service principal connection between azure and DevOps but also prevent users from creating a deployment user.
Related
Long time lurker, first-time question so apologies if I do this wrong.
I have successfully used the following to create a continuous deployment pipeline in Azure DevOps:
Composer CICD Pipeline Sample
However, I would like to use additional pipeline variables to insert into the appsettings.json file: such as additional API keys and the ApplicationInsights connectionString.
Does anyone have experience of doing this or can someone point me in the right direction?
Google has shone no light on this and unfortunately, I have found the botframework documentation to be lacking.
Azure deployments by the pipeline you reference do not use the appsettings.json file. Those settings are ignored.
The pipeline installs pipeline variable values in Azure as App Service Configuration Application Settings using the task "Configure App Service Settings". You might start there.
I am using Cloud Run Continuous Deployment to watch a github repo & build the project upon a push to the production branch. Instead of specifying a Dockerfile, I am letting Google Cloud Buildpacks do all the work, since my codebase is written in Node.js.
I haven't yet been able to run a functional deployment due to the service account running into some permissions errors, but once I get past those, I am wondering how I would be able to initialize the firebase admin SDK inside the build. In my dev code, I have a service account JSON file and initialize the admin SDK using that file, but I don't know if this possible in the cloud build. If I can't upload private files to the cloud build, am I able to use the service account that creates the build to initialize the admin sdk? Is there another way to initialize the admin app in the build, such as using env variables? For reference, I am only using the admin sdk to read and write to our firestore database.
I am planning to build an enterprise application using aws lambda and serverless framework.
I want to separate the dev, test and prod environments and I am planning to use AWS Parameter store for it.
I don't want my production environment configuration be exposed to developers. If the developer runs the command serverless offline -s production start then the production configuration should not be obtained.
It should be obtained only when the serverless function has been successfully deployed to aws lambda.
Here are few considerations based on your question:
To have different environments on Serverless framework you have to set up the stage. This value can be passed as a parameter when executing sls commands.
If you are keeping your code in a repo, the developers will have access to all the configurations. If this is really important, you could keep the production configuration in a diff repo where only very specific people will have access to it, and then you make a reference to in in your serverless.yml. Ex:
custom: ${file(./config/${opt:stage, 'dev'}.json)} and then in your config folder you create the prod.json file, but pointing to the real one of the new repo you created. Note: this would make your project harder to maintain.
Considering you don't want your developers to execute your production environment locally. You can use the global variable of serverless offline to block the execution. You could also inform then to not do so.
Here is what should be a good practice and solution based on your problem:
Considering you have a production environment you want to isolate from a given group in your company, you should create VPC's and configure their resources access, accordingly.
Then you create users to have diff access. When your developer try to execute the code accessing a resource (dynamoDB for example) in a VPC they don't have access, they will be blocked.
AWS configure to define which user will execute the SLS command.
Your development team will still have access to your configuration file.
Note: In this case the person/group with access to the production VPC will have to do the deploy.
If the answer does not suffice, could you please reinforce which type of resource(s) are sensitive across your Serverless project? I am taking for granted it is the DB as it is the most common scenario.
We have all our repositories in Bitbucket and I'm trying to set up a continuous intergration services to Azure DevOps that would build the project after each push.
We have created a dedicated user account for Bitbucket repositories that has real-only access to all repositories.
However, creating a CI webhook trigger from Bitbucket to Azure Devops requires admin access to repositories. We do not want to give that level of access to CI user account.
I could add the webhook to Bitbucket repository manually, but I'm missing the URL to which the webhook should post the trigger.
The url is something like https://dev.azure.com/myorganization/_apis/public/hooks/externalEvents?publisherId ...
I think it's called deployment trigger url but I cannot find it anywhere. Does the new Azure DevOps support manually adding webhooks or do we have to do it manually somehow?
I'm in the same boat with you all. I don't want to give my CI account "Admin" rights to ANY repo.
My workaround so far has been to give the CI account temporary access in order to create the webhook when the pipeline is first saved, then downgrade it after the webhook has been created, knowing that any changes will require another temporary permission elevation.
FWIW, the webhook URL that is used is this:
https://[REDACTED].visualstudio.com/_apis/public/hooks/externalEvents?publisherId=bitbucket&channelId=[REDACTED]&api-version=5.1-preview
As you can see, we are kind of in an understandable Catch-22 here, because we could conceivably create the pipeline and get that channelId to use to manually create the webhook in Bitbucket, but can't even SAVE a pipeline without repo Admin rights, so we can't get the channelId.
I wish there was a way to disable the webhook creation so we could manually create it on the Bitbucket side.
I know that this has been a long time since it was asked, but recently I was faced with the exact same issue and I thought I should add this here for anyone struggling to find out where these URLs are coming from.
I was seeing in Bitbucket two webhooks in the format https://dev.azure.com/[myorganization]/_apis/public/hooks/externalEvents?publisherId=... and I was trying to figure out how these were created in the first place.
As it turns out, when you create a new Bitbucket Pipeline in Azure and you select a repository for this pipeline, Azure automatically creates these webhooks for us in Bitbucket! In other words, it doesn't seem to be a way to deduce these URLs from anywhere, but rather they are created by Azure upon creation of the Pipeline, as well as they are deleted by Azure once you delete the Pipeline from Azure!.
I'm trying to setup continuous deployment via the Aure Portal.
When doing this via the VSTS account (let's call it "VSTS Account A") which is owned by the same account owner as Azure, everything works fine.
In this case I'm trying to configure continuous deploymenet from source code held in another VSTS account (let's go with Account B).
The Azure account owner is not the Account B owner but is an admin (member of Organization Administrators) for Account B. The owner is also listed explicitly as a member of at least one project within Account B.
The problem is that when it commes to configuring "Deployment source" within the app service section, Account B is not listed as an option to choose from.
I've followed various links (e.g. part 4 of this page) about linking the VSTS account with an Azure account but still no joy. There are a couple of problems here:
The Azure classic portal has a New button within the Visual Studio Team Services section but when I choose Link To Existing, I get the following message:
Make sure you’re the account owner. If you are, maybe your account is
linked to another Azure subscription or connected to another Azure
Active Directory
Account B is not linked to another Azure Subscription or Azure AD.
The new portal doesn't even have an option to attempt to link a different account, plus the menu link says "Team Services Account Preview" so whether the Preview status has something to do with it, I don't know.
I'd have thought this would be a relatively common use case, has anyone had any joy setting up something similar?
I was finally able to choose the relevant account by making the VSTS principal a co-admin in the Azure account which contains the web app, signing in as that user and changing the directory to use from the the user dropdown menu (top-right). Note, the user account in question is already an administrator for a different Azure account, just to complicate matters further. I only had the option to change the directory once the user was a member of multiple directories.
So I finally got it configured and committing code to the specified branch was triggering a deploy. However, it transpires that setting up continuous deployment from within Azure gives you limited scope and I got constant errors which were not straightforward to fix.
I ended up getting it working properly by following these instructions:
Build: https://www.visualstudio.com/en-us/docs/build/apps/aspnet/ci/build-aspnet-4
Deploy: https://www.visualstudio.com/en-us/docs/build/apps/cd/deploy-webdeploy-webapps
Configuring it all from within VSO gives you a lot more clarity about what's actually happening.
When doing the initial setup, I had to go through an authentication step with the Azure account I was trying to deploy to and that process launches a pop-up window which was getting blocked so I missed it at first.
The initial build and deploy were fine but I was getting a build error when being triggered from a code commmit. This is because the Build Definition --> Variables --> BuildConfiguration value was set back to Release even though I set it to the correct value for my project when doing the initial configuration. Once I updated that, the next commit triggered the build which in turn created the artifact which in turn triggered the deploy which went through fine.
Googler from the future here, I had the same problem and came across a really good article called "DevOps: Connecting VSTS to Azure by Ken Muse" enter link description here
This worked like a charm for me from the first try!