Skip main navigation

New offer! Get 30% off one whole year of Unlimited learning. Subscribe for just £249.99 £174.99. New subscribers only T&Cs apply

Find out more
Home / IT & Computer Science / AWS / Microsoft Future Ready: DevOps Development, Implementation and Azure Automation / Azure Automation Accounts and Security

Azure Automation Accounts and Security

.
View transcript
17.3
So a lot of talking– let’s go into a demo. What we’ll look at in the demo is an introduction to creating Azure Automation Account and, while we’re at it, discuss some of the best practises when creating Azure Automation Account. And then we’ll do a whistle tour of some of the features of Azure Automation. All right, so let’s get started. All right, so we’re in the Azure portal now. If you don’t have an Azure portal, if you don’t have an Azure subscription already, you can sign up for the free subscription on azure.com. Now I’m using a subscription here. Logged in with my ID.
57
As you can see, I’ve got access to multiple directories, but I’m just going to use this training directory that I’ve created. So as you come into the portal, you would see on the left there you have a section for more services. Click on this section and search for automation. And if that’s something that you’re going to be accessing quite a bit, then it might be worth marking it as Favourite, in which case it starts to show up on the left panel. So let’s go into the automation account. Now I’ve got a bunch of automation accounts that I’m already using, and you might find in your organisation that automation accounts are already in play.
93.2
Now what you have to remember is automation accounts are really subscription limited. So within the subscription, I create an automation account. I can only use it to access the resources within the subscription. The other thing you need to remember is that there is a limit of 30 automation accounts in every subscription. So if you wanted to create 31, well, you need to create the other one in another subscription. The automation accounts are, in a way, giving you the ability to programmatically access the Azure resources. And that means if you accidentally gave that access away to someone else, then they would pretty much have access to all the resources within you Azure subscription.
136.7
And it’s because of this reason that in order to create an Azure automation account, you need to be a subscription administrator. You don’t need to be a subscription administrator to run the Azure automation account, but just the process of creating the Azure automation account needs to be carried out by a subscription administrator. Now since I’m the administrator for this subscription, I’m simply going to go in and click the Add button. While you could call the Azure automation account anything– how about calling it Joe had a good day? But when you come back to this automation account in a month’s time, it’s not going to mean anything to you.
172.7
So what I would recommend is following an approach which is easy on someone else using it or just on you as you come back in a few months time trying to figure out why the automation account was created. So for this demo, I’m going to call it ISE training 08. Now another thing that I kind of asked people to use in their naming convention is the location that they’re creating the Azure automation account in. And the benefit of doing that is the automation account that you’re creating should be used to automate the resources that are within the same location where their automation account is.
206
There is nothing stopping you from using an automation account which is in location A to work with resources that are in location B, but you may notice latency. And why take that latency challenge up when you can always create an Azure automation account in the same location? So in this case, I’m creating the automation account in West Europe. I’m going to have that reflected in the name. And then just in the end, put the name auto. And I’m going to create this automation account and its own resource group, and I’m going to postfix that with the keyword RG, West Europe. Now you see an option here Create Azure Run As Account.
243.2
You don’t necessarily need to create a run as account. If you’re going to use Azure automation to run IT operation processes by creating run [INAUDIBLE] that do not need to interact with the Azure infrastructure, then you could choose this option as no. In which case, no run as or programmatic access to Azure resources gets provisioned as part of the Azure automation account. But in this case, we’re going to create some scripts that will interact with Azure resources. So I’m going to turn this option as yes. OK, well, let’s click the golden button and wait for the Azure automation account to provision.
284.4
As I get redirected back to the screen, you can see in the notification section that I get a message telling me that the deployment for this process has started. I can click on the notification icon there and keep up to date on the status changes as the account gets provisioned. Meanwhile, I’ll just click Refresh, and we can see that it’s starting to show up in the automation account list. I also see the notification that the deployment of this account is completed now. So let’s click on it and go through some of the settings of the automation account. As you can see in the Essential section here, the automation account has been created in its own resource group.
326
It’s not fixed in the sense if you wanted to come back to it later and decide to move the automation account in another resource group, then you can do that right from within the Azure portal and don’t need to go to PowerShell to do it. Simply select an alternate resource group, and you can move it into the other resource group. You see some other information as to what location it’s deployed in, what subscription it lives in, who created it, when it was last modified. Scrolling down to the property section, you will see the same set of information. Now I want to show you the Run as Accounts section under the Account Settings.
363.1
As you can see, the Run as Account has been provisioned both for Azure Resource Manager as well as Azure Classic. In your organisation. If you are still using the Azure Classic as in the Azure Service Manager– Azure V1, as it’s also called– and you have some assets there that you want to automate, then you can use this Run As Account to integrate into the classic portal to do your automation. Let’s click on the Azure Run As Account. What you see here is that a certificate has been provisioned. And it’s this certificate that authenticate with the rest of the Azure resources when it’s interacting with them.
399.5
Now this certificate has an expiry date, and that’s just so that you don’t end up creating an account and forgetting about it and someone misusing that certificate. The renewal process is fairly straightforward. You get notified before the certificate expires, and you can come back and renew it right from within here. The other thing as a best practise that I would advise is when you create an automation account that you lock down the set of people that have access to it. And the benefit of having the automation account within the portal is that you have access to the R back roles, the resource– the R back roles allow you to set up the permissions on who can access these automation accounts.
440.4
At the same time, you also have permissions available within Azure Automation to say which resources it can operate in. So say, for example, if you only wanted to give it permission to certain resource groups which are in dev or in test, then you can optionally do that as well. The one thing that I would advise is under the Settings section, you have locks. So once you reach a point with your automation account where you have created scripts that you don’t anticipate will change, then you could add a delete lock.
477.5
Let’s see what this does. So I’m going to add a delete lock and click OK. If I come back here and click the automation account– and bear in mind, I’m the subscription administrator– and click Delete, then it queues a request for deletion. But that deletion request fails. Now if I tell you that you’re going to accidentally delete your Azure Automation account or any of the assets you create within Azure, you might giggle a little bit, but this happens all the time where administrators have way too much permission, and in an effort to clean stuff up, you accidentally end up deleting stuff that you didn’t mean to.
518.4
So putting a lock on your Azure automation is a good way of protecting it accidentally being modified. So we’re going to go back into the Azure automation account, remove the lock, and look at a few more settings.
535.8
So just click here, delete the lock. Now the account, when it gets provisioned the first time, gets provisioned as part of the free usage tier. And in the freemium model, you get about 500 job minutes free. What that means is every time you run a run book from within Azure automation, you get up to 500 minutes of free usage for execution of those run books. You also get about five free nodes that can be associated to the DSE pull server. But once you exhaust that and you want to use it for more enterprise reasons, you can obviously come in and change the pricing tier.
575.8
I’m going to use the basic tier in my demos because as you can see, I’ve clearly exceeded the limit for this month. The other thing to highlight here is keys. As you can see here, I have got a primary key, a secondary key, and a URL. So if I wanted to use Azure automation from outside the Azure portal, as long as I had access to this full URL, as long as the primary access key, I could trigger Azure automation from outside Azure portal as well. So you would find in organisations that someone creates an automation account, and it starts to work really well for them. And then they want to create it for other business units or other projects.
621.1
Then someone has to do it manually. But the benefit of doing this from the Azure portal is once you provision an Azure automation account, the automation script gets self-generated for you. So if I click on Automation Script, you will be able to see that the PowerShell command to spin up a new instance of Azure automation has been created for me. So I could just take this, refactor it a little bit, maybe parametrize it further, and then I could just run this from PowerShell to create more Azure automation accounts for myself. OK, one more thing I would like to show you here is source control integration. Now we’re talking about this DevOps way of working, right?
664
And if you’re creating automation that’s not backed by a version control, then it’s not really DevOps. And in that spirit, Azure automation integrates with GitHub, which is a very famous Git hosting solution. So if you click on source control and you click on Choose Source, you see there is an option to integrate with GitHub. So in this case here, I’ve got a GitHub repository that I own, and it’s got some run books in it that I’ve created in the past. If I just wanted to integrate this pre-existing repository that has run books with my Azure automation account, then I could just do that by going into Azure automation, clicking on GitHub, and then authorising.
713.6
In the process of authorising behind the scenes, an Oauth token gets generated using the same ID that I’m logged in into GitHub all happening seamlessly in the background. You don’t need to generate tokens and save them and key them in yourself. Then it gives me the option of selecting the exact repository that I want, the branch. And the benefit is you might be creating your automation in one branch. And now you might want to make some changes to it. So you may create another branch to do the changes. But all the automation that exists in the original branch that is connected to Azure automation does not get impacted as you are experimenting with new features in a separate branch.
751.9
So come back here, and then it says, what path does it need to look for? Now I’ve got a folder path here. I can key it in and click OK.
764.5
At this point, as I click OK, it’s behind the scenes. It’s going to integrate with GitHub, pull down all my PowerShell run books, and make them available in the run books section within Azure Portal. Right, so we had a quick walk through of the Azure Portal. We talked about some of the best practises, some of the limits, the level where the Azure automation resides, and some of the best practises in setting it up. We also looked at some of the settings, and the important thing is integration with source control.

The previous step gave you an overview of what Azure Automation is and how it enables and accelerates DevOps.

Let’s take Azure Automation one step further. You will now learn how to create an Azure Automation Account and set up Automation Security.

Creating an Automation Account

To start using the Microsoft Azure Automation service, you must first create an Automation account from within the Azure portal. Automation accounts are like Azure Storage accounts in that they serve as a container to store the Automation artefacts.

Want to keep
learning?

This content is taken from
CloudSwyft Global Systems, Inc. online course,

Microsoft Future Ready: DevOps Development, Implementation and Azure Automation

View Course

These artefacts could be a container for all your runbooks, runbook executions (jobs), and the assets on which your runbooks depend.

An Automation account gives you access to manage all Azure resources via an application program interface (API). To safeguard this, the Automation account creation requires subscription-owner access.

To use Azure Automation, you will need at least one Azure Automation account. However, it’s recommended that you create multiple automation accounts to segregate and limit the scope of access to minimise any risk to your estate.

For example, you might use one account for development, another for production, and another for your on-premises environment. You can have up to 30 Automation accounts.

Automation Security

When you create an Automation account, it’s important that you lock down the set of people that have access to it. The benefit of having an Automation account within the Azure Portal is that you have access to Role-Based Access Control functionality.

Role-Based Access Control

Role-Based Access Control (RBAC) allows you to control access to and monitor Microsoft Azure Automation accounts to ensure that resources aren’t wasted on poorly written automation solutions. With RBAC, you can limit both the scope (resources) and the permissions (roles) that users are given. You’ll use these roles to control access to Automation resources.

Each Azure subscription is associated with one Azure Active Directory (AD). Users, groups, and applications from that directory can manage resources in the Azure subscription. You can assign access rights by using the Azure portal, Azure command-line tools, and Azure Management APIs.

You can grant access by assigning the appropriate RBAC role to users, groups, and applications at a certain scope. The scope of a role assignment can be a subscription, a resource group, or a single resource. A role assigned at a parent scope also grants access to the ‘children’ contained within it.

The RBAC role that you assign dictates what resources the user, group, or application can manage within that scope. Some typical roles include:

  • Owner. An owner can do anything, such as create objects, delete objects, modify things, and assign permissions to other users.
  • Contributor. A contributor can do everything except modify permissions. A contributor cannot grant someone access to something but can create runbooks, execute them, and run them.
  • Reader. A reader is a view-only administrator. Readers can view everything but cannot change anything.
  • Automation operator. An Automation operator can perform tasks that are involved in the operation of an Automation account such as starting and stopping runbooks, but an operator cannot add new runbooks, modify runbooks, modify credentials, or grant permissions.
  • User access administrator. A user access administrator can’t do anything to the Automation objects but can grant and revoke permissions.

For more information on Azure role definitions, see RBAC Built-In Roles. For a detailed explanation of specific actions that can be performed by each role, see RBAC in Automation.

Service Principals

A service principal is a local representation of your application in Active Directory. It contains the role assignment. As part of using Azure Automation runbooks to help operationalise Azure subscriptions, runbooks need to securely authenticate to Azure with a minimum of administration overhead.

As a best practice, authentication solutions usually entail using certificates to authenticate an Azure AD service principal that has been granted the relevant RBAC permissions to manage the Azure subscription.

To configure certificate-based authentication with Azure AD service principals from within Azure Automation PowerShell Workflow runbooks, see this tutorial.

Want to keep learning?

This content is taken from CloudSwyft Global Systems, Inc. online course
Microsoft Future Ready: DevOps Development, Implementation and Azure Automation
View Course
See other articles from this course
This article is from the online course:

Microsoft Future Ready: DevOps Development, Implementation and Azure Automation

Created by
Join Now
This article is from the free online

Microsoft Future Ready: DevOps Development, Implementation and Azure Automation

Created by
Join Now
FutureLearn - Learning For Life

Reach your personal and professional goals

Unlock access to hundreds of expert online courses and degrees from top universities and educators to gain accredited qualifications and professional CV-building certificates.

Join over 18 million learners to launch, switch or build upon your career, all at your own pace, across a wide range of topic areas.

Start Learning now

Register to receive updates

  • Create an account to receive our newsletter, course recommendations and promotions.

    Register for free