Sunday, April 30, 2017

The case for multiple Azure Automation Accounts

Most of my recent work has, in some way, involved the use of the Azure Automation service.  It is a pretty versatile service that can be used for a lot of IT automation needs.  As I start to use Azure Automation in more complicated scenarios, I have run into some security considerations that has got me wondering if the right approach is to have multiple Automation accounts in a given environment.  The goal of this post is to discuss this a bit further.

In Azure automation, there are three "integration" points where security might come up as an issue.  The first is governing who has access to the particular automation account.  Microsoft has come up with a set of user roles that can help control access to the account itself.  Of course, you can always make use of azure custom roles to make further customization to the granularity.  The second is around the credential/secret access that the automation account has been setup with.  These elements are configured within an account and every runbook in the account could, in theory, access those resources.  The third is in the use of hybrid workers.  Workers are configured at the account level, and then, can be selected as the run destination for a given runbook.

Take the following scenario as an example.

I would like to execute startup/shutdown scripts across multiple environments (say dev/test/prod) and have them run by users as required. 

Working through the above defined integration points, the first point to consider would be that of user security.  At some point, someone has to be the owner of the Automation Account, and thus, that owner would effectively have access to all resources within it.  This goes the same even if RBAC is used (out of the box).  Users with the automation operator role would still have access to run all runbooks in the account regardless of the environment it is targeting, or that they actually have authority over.

Moving to the second point, run-as accounts are configured at the Automation account level.  Run-as accounts have no granular permissions and therefore can be accessed by any runbook.  While you can control who can author a runbook, you can't control what run-as accounts the runbook uses.  Further, you can enforce user security on this.  In an ideal state, a runbook could accept a run-as account as a parameter and then ensure that the user actually has access to use that account.  Permissions in Azure automation are not that granular.

The third aspect, hybrid worker, generally only comes into play when you are executing activities that require network access to the operating system itself.  When you setup a hybrid worker, you essentially get another prompt when running the runbook, requesting "where" you would like to execute the particular runbook.  Once again, there is no user level security here.  Everyone who can run a runbook can also select the hybrid worker group to run on.  Further, you cannot actually configure a runbook to ONLY run on a particular destination (unless you use a webhook or schedule).  So, even users with only the "automation operator role" can still run runbooks where they are not supposed to.

So what is the solution? When I first setup the build/release management in VSTS online, I was amazed at the amount of permissions, etc, you need to grant to make something even somewhat useable.  You could run into the scenario where you had access to run a build on a project, but no access to any agents to actually execute the build on.  Credentials could be stored as part of a release line, but not used by any other release lines. Permissions to view those could be granted only to the people that needed them.  To be honest, it seemed tedious, but in retrospect, that is the level of granularity that was required in order to truly make the system multi-tenant.

From an azure automation perspective, I feel like the easiest solution is to create multiple automation accounts.  One per environment that it is targeting.  Then grant permissions to the automation account as required for the people that need it.  Keeping runbooks in sync between environments is frustrating, but the integration is coming along with github and VSTS that will make things easier.  While I still feel a VSTS approach is better off in the long run, multiple automation accounts seems to solve the problem at an environment level quite nicely.