My company process sensitive data and needs to restrict access to production environment. How do I organize subscriptons and (storage) accounts so that I have separate environments?
I could have completely distinct subscriptions but I want to give some devs the power to deploy on production while others should only have access to development assets.
In my ideal world, I'd add individuals to security groups. Whenever a thw dev wants to deploy on production, he/she would use his/her credentials plus an extra confirmation step, like an otp. This way I'd avoid mistakes but still keep simple users management. Is that possible in azure?
Eventually what you are wanting to do will be possible, and is possible to some degree depending on the resource. As more of the features of Azure make it into the preview portal (portal.azure.com) they are showing up with Role Based Access Controls, which is what you are looking for. Unfortunately, right now not all of the resources are there and some are there without full RBAC baked in (such as storage accounts).
For now, the best bet is to still separate by subscription. If you need developers to have the ability to perform a deployment you can create a script that performs the deployment (using stored PowerShell credentials or secured management certs) and then give the developers the ability to execute the script.
Related
I am a Solution Architect responsible for setting up a project's infrastructure on Azure. The project should be running in multiple environments (dev, staging, prod). As far as I learned the best practice regarding environment separation in Azure is to use Resource Groups. That's what I did.
However, this is where things start getting tricky. Our application will use Azure AD as OAuth Authorization Server. I want to have my AD isolated, like everything else in my infrastructure. I don't want to accidentally modify a production user from the dev environment and for the dev environment, I want to be able to create a ton of test users which I don't want to see in production. So, isolation.
The problem is I don't see any option on how to do this. My first instinct was to create multiple ADs. But when I do that, they actually need to create a completely new tenant for each of these environments. This seems really messy to me. Have to support as many (almost empty) tenants as I want to have environments.
Please, what is the right way how to do this?
Does Azure AD have some kind of support for isolation I require?
Am I missing something?
Note: this question was also asked in MS Q&A.
You're correct that a tenant is equivalent to a directory and a user is either in the directory or it's not. However, using RBAC, you can restrict the permissions on users so that they can't access particular services. It would be good if you separated permissions by subscription which is what a lot of major companies do and that's how they know which workload a subscription handles.
My company developed an Azure Resource Manager-based solution that deploys a set of resources (essentially a Storage, SQL DB and Web App), and it is already implemented as our provisioning process for new customers.
However, we are now studying the best way to perform updates, and one of the hypotheses we are considering is having a specific template that updates the binaries of this application.
The idea is to have a separate template, that only has the web app, an app host and a MSDeploy resource that gets the latest version of our package and reuploads it to that web app.
The only problem I'm seeing with this solution is the ability to handle any changes in configuration that are necessary with newer version of the binaries - we do not want users to have to re-input any parameters they placed for the original deploy (done via a Deploy To Azure button), so, any configurations will have to be performed within the application - the plan is for it to use the Microsoft.WindowsAzure.Management.WebSites library.
The major limitation with using Microsoft.WindowsAzure.Management.WebSites is that you are restricted to authenticating with either a certificate or a service principal. Ideally we would like to find a way for the updates to not need any authentication other than the one you provide when you are deploying the update.
Is there any recommendation of best practices to follow for this kind of scenario?
Thank you.
Link to the equivalent discussion on TechNet
It is possible to update only via ARM templates.
For example connection strings can be added automatically to the application settings even when creating the dependent resources themselves.
Ex. Account storage connection string.
Only first time creation of your web sites will take a bit more time, something like 30 sec.
ARM will not destroy your WebApps if they exist already. it will update only.
If there are no changes, then the deployment is very fast.
If your changes require a new Appsettings parameter, you can enter it in ARM , check in to your repository.
and next deployment will pick up and update the WebApp.
So no need for anyone to log-in and update.
Our final decision was to give up on using ARM exclusively. The Service Principal solution, through the SDK, would allow us to use a Web Job or a Site Extension to perform (automatic or prompted) updates that included configuration changes. However, it would require "too many" privileges - why would a customer trust an application that can, at will, create new resources or update existing ones to increase his Azure bill?
The decision was made to utilize Powershell only for updates - if the customer can see the scripts and authenticate himself, this is not a concern. Sadly, this increases update complexity, but we found it to be a necessary evil.
We are a small company and are still unsure how to start all this azure stuff.
Ok, we are clear on the technicalities like table storage and queues and all the that stuff, what we don't know about at all is how to set up the organization around developing for our developers. Which/how many azure accounts, shared or individual ones.
So far we've done classic windows development, so everyone has his environment, unit tests run either locally or on the build server (after pushing to mercurial or git), deployment from the build server.
The thing is that we want to use Azure not just as a hoster, but the full set, like blob/document/table storage, event hubs, storage queues, ReliableActors and everything. Things we can't do locally.
What's the appropriate way for azure then? There are about 20 to 30 developers and most have the enterprise msdn subscription.
What is a "company or organisation" account for? Should developers have their own accounts? Does DevOps need their passwords for all the bamboo or jenkins build stuff?
I went through this recently and I can share a few tips here since I'm also not aware of a DevOps specific platform to share this on StackExhange.
As far as organizing your subscriptions go look at Azure Pay-As-You-Go Dev/Test Subscriptions link
or Enterprise Dev/Test link if you are an Enterprise Agreement customer. These are aimed at development teams, you get discounted rates since you don't pay for software licenses that are already included in your MSDN subscription.
It is best to use individual developer subscriptions for exploration, POC etc while running your main dev workload in the Dev-Test subscription. It looks tempting to try and save a buck by spreading the work across multiple MSDN subscriptions to use the credits but I wouldn't recommend it. It becomes a pain to manage 20~30 subscriptions and they can run out of credits and things stop working. If you remove the spending limit on all the subscriptions you run the risk of racking up a huge bill accidently if multiple devs leave VMs on or add premium storage to VMs etc.
As far as DevOps go, use RBAC and Azure Active Directory to manage access and certificates for your DevOps tooling, build servers, release management etc don't use individual developer credentials for this.
And I agree with the other comments, get in touch with MS as well, this is just the tip of the iceberg but it will get you started.
We're completely upgrading our production and development environment from co-located boxes to an Azure implementation and we'll be developing using Visual Studio Online. Up until this point our dev has occurred on a Remote Desktop environment where developers were logging into Windows server and developing on that RDP box.
We want to set this up and we have some confusion about the Account types/set up types.
It appears there are two ways to set up our Azure and two ways to set up our developers. We are a MS partner w/ some MSDN licenses and Azure credits.
So for Azure we can use our existing MS accounts and just set up an Azure Pay As You Go (PAYG) subscription. This was suggested to us initially but it seems weird to have the entire companies Azure environment going through an individuals live ID. Then we saw we can sign up as an Organization now and it uses Azure AD. We have not been using Active Directory and we're not sure how much complexity this is going to add to our administration. Is there a discernible difference/benefit to going one way or the other?
Then, when we sign up our developers we can either have everyone sign up with their live ID's (we have MSDN w/ VS Premium credits for all developers) or we can set them up using Active Directory with Work Accounts. Having our credits allotted in work accounts sounds like a good way to control things at first reading, but it also seems a bit more complex. I'm wondering if there is much difference between MSDN accounts signed up w/ live IDs or AD Work Accounts. I can't find a real comparison article or pro/con type of discussion anywhere.
It sounds like you have already figured out the main differences. As an organization, I would suggest signing up for Azure as an organization. You can do that here. This is going to give you the management capabilities for resources typically needed by an organization.
Your developers can continue to use the MSDN subscriptions. As Dylan commented, these are not to be used for production environments. You should consider using these for Dev/Test environments and activating your MSDN benefits. This will save you some money. More on that here.
Visual Studio Online will work with your Work Accounts and again give you more control over managing your online resources. This link describes the sign-up process for both Microsoft Accounts and Work Accounts. And if you scroll down a bit you will find your original question specifically addressed.
Finally, you can also add your Work Account(s) to your existing MSDN subscriptions if you like. This way you (and your developers) can use the same account credentials when accessing Azure Subscriptions. Information on how to do that is available in this link.
Your Work Account subscription should be limited to personnel responsible for managing your "production" environment.
After signing up for Azure as an Organization, you can add users to the directory as described here. You can also add "external" users using their existing Microsoft Accounts. It's just a few dialogs to add a user.
We started using Azure platform. Especially we are having issues in Web Sites platform. How we give different kinds of access to our development team.
Right now the development team could access the production deployment slots.
We need to be able specify the access to the system according to their roles in the organization.
Have your development team use their own subscription for development. That way, they never have access to your production environment. This is something I personally practice and recommend to customers.
This gives you the added benefit of also separating development and QA costs with your production deployment costs. In development, you may choose to use smaller and fewer instances (to control costs). Yet, in production, you may prefer larger and more instances (to meet demand). Having a separate subscription for each enables these options for you.
This is also an approach demonstrated in the Patterns and Practices Guide. It's a little dated and is in the context of Cloud Services (not Websites). But, the overarching principles still apply.
Microsoft has Role-Based Access Control in the roadmap for the new Azure portal but have not committed to any target dates.
If you're using Azure AD to manage Azure access there are some different roles available there.
Edit: Basic RBAC functionality was added to the new Azure Portal back in September.