Hello, and welcome to this Azure Governance for ISVs recording on
Policies, Initiatives, and Blueprints. I'm Mike Bazarewsky, and I'm going to be your presenter
for this session.
This is the second in a number of ISV-oriented governance sessions.
The first one covers options for organizing resources in an Azure deployment.
This one is going to cover how you're deploying resources in a secure, compliant way.
The third session is an ISV-targeted summary of these topics.
I'm going to start with Resource Locks, then move on to Azure Policy and Azure Initiatives,
and finish with Azure Blueprints; all of these capabilities are related to
controlling resources in ways beyond what Role-Based Access Control, or RBAC, allows.
Coming in to this session, I'm assuming you're an ISV that has some basic knowledge of
organizing resources around Azure - subscriptions, resource groups, and so on.
If you don't, you'll want to review that session first.
I’m also assuming you have some basic knowledge of Azure Active Directory - Azure AD -
and how Azure does Role-Based Access Control.
If you don’t have that knowledge right now, a little of what I’m going to talk about
won’t necessarily make sense to you yet, but that’s okay; you’ll still be able to understand
most of what I’m presenting, and you can learn about Azure AD at your leisure.
You can find all of the reference links from this session at https://aka.ms/GovernanceReference.
That will include all of the documentation and learning links that I present in this session.
So, let's begin. When deploying using ARM,
you have the ability to control permissions through role-based access control, or “RBAC”.
However, it’s not uncommon to have resources that a user has permission to change or delete,
but should have an extra bit of protection.
For example, you may have a production resource group that, generally speaking,
shouldn’t be deleted or changed, even by a resource owner, because they are production.
Resource locks are one capability offered by ARM to add extra restrictions
on top of what RBAC brings.
Resource locks add the ability to place advisory restrictions on changing the
configuration of a resource or resource group in ARM,
or on deleting the resource or resource group.
By default, an Owner or User Access Administrator can add or remove locks
from a resource or resource group.
These are advisory restrictions, because a determined administrator
with appropriate permissions can remove the lock, then perform the
change or delete activity.
However, the idea is that this extra step prevents accidental changes from occurring.
You can also use resource locks as a form of "last ditch documentation."
Let's examine what I mean by that.
For this demonstration, I'm going to use the "LockDemonstration" resource group -
one I created for this purpose - and my goal is to delete this resource group.
I'm going to start by selecting "Access Control (IAM)" blade,
and underneath "My access", I'm going to select "View my access",
and the system indicates that I'm a member of the "Service Administrator" role,
and that that role has full access to all resources in the subscription.
"Full access" means I should be able to delete this resource group.
So switching back to the "Overview" blade, I'll select "Delete resource group",
type in the name of the resource group to validate that I really intend to perform
this delete action, and then select the "Delete" button,
and the notification comes up that indicates the resource group is locked, and my delete failed.
Underneath "Settings", if I open the "Locks" blade,
the system indicates I have one lock on this resource group.
That lock is named "ProductionProtection", with a lock type of "Delete",
a scope of "LockDemonstration",
and notes that indicate "This resource group supports the production Contoso
Financials web site."
So, that's why I couldn't perform my delete action, even though role-based access control
says I could - because the lock overrides that.
However, I have permissions to delete the lock, if I really want to do that,
and in this case, I do, so I'm going to delete that lock, and then, switching back
to the "Overview" blade, I'll again select "Delete resource group",
enter "LockDemonstration" for the name, and select "Delete",
and this time the delete succeeds, because I do have permissions to perform the delete,
and there's no longer a lock preventing me from doing so.
Microsoft Learn has a lesson on using locks,
and the documentation in Microsoft Docs includes information on some of the
non-obvious side effects of locks. You can review both of those at your leisure.
Moving on now, as presented, resource locks can prevent updates as a general concept,
but do so in a very broad, non-specific way.
However, there are times someone may have permission to deploy
or update resources, but you'd like to control specific details
of the deployment or updates for business reasons.
There's where Azure Policy comes in. Azure Policy is sometimes
referred to as "guardrails for ARM". RBAC controls the actions that can be taken,
while Policy controls the details of the actions - the parameters.
For example, you might assign a policy that only permits specific virtual machine sizes
to be deployed, as a cost-containment choice. Or, you might have a policy only allowing
specific regions to be used as deployment targets,
as a data containment or cost containment measure.
Policy can be used just to audit resources as well, reporting on resources that are not compliant
without blocking those resources from being created.
This can be useful when working with existing resources in an environment.
Policy can be assigned at the management group level, the subscription level,
the resource group level, or the resource level, and will be inherited from the assigned level
down to any child resources. I should note that the Portal doesn't allow assignment
at the individual resource level at this time, but you can do so
programmatically or at the command line.
Policy is usually deployed through Initiatives.
Initiatives are collections of policies that relate back to specific business goals,
such as "Control virtual machine deployment", with a policy for size restrictions,
a policy for region restrictions, and so on, or
"Require workload encryption", with a policy for SQL Server encryption,
a policy for Azure Disk Encryption in virtual machines, and so on.
The idea here is that initiatives represent the business requirements,
while policies are used to implement the technical details of the business requirements.
Microsoft ships a number of pre-defined initiatives and policies
based on common compliance regimes and business needs.
You can assign those directly, or use them as a basis for your own custom policies and initiatives.
Let's examine a sample initiative policy assignment and the result.
Here we have the Azure Portal Policy view. Under "Authoring", I'll select "Definitions",
This will list all the policies and initiatives my Azure environment is aware of,
both assigned and unassigned. To help focus the demo, I'm going to drop down the
"Definition type" and choose "Initiative", then change the "Type" to "Built-in".
There's many examples here of pre-defined initiatives. For example,
there's one for PCI compliance, and one for ISO 27001, 2013 edition.
Some of these, like HITRUST/HIPAA and NIST SP 800-53 revision 4,
cover a large number of policies. The NIST example has hundreds of policies
to help you deploy in a compliant fashion. It's important to remember
that compliance in a cloud environment is a shared responsibility.
These initiatives and policies can help you with portions you are responsible for.
I will now change my type to "Custom",
and that will list a relatively simple custom initiative I created for this demo. When I select
it shows three custom policies I created based on shipped sample policies.
These policies restrict the regions allowed for a resource group and a resource
as well as the virtual machine sizes that are allowed.
I deployed these policies and this initiative through an ARM template.
The commands here include the ability to be able to assign the
initiative, which I'm going to do now.
I'm asked at what scope to apply the initiative to - the Portal exposes
subscription and resource group levels, but as mentioned earlier, you can also assign
to the management group and individual resource levels as well.
I can also exclude specific resources.
On the "Parameters" tab, I can fill in whatever parameters are requested by the initiative
to customize the application of the initiative.
In this case, I'm going to supply a list of allowed regions,
And a list of allowed virtual machines SKUs, or sizes.
These need to be entered as JSON arrays.
And then on the "Remediation" tab, I can specify an identity to use for modifying
non-compliant resources, if desired. For this demo, I'm not going to worry about that.
Finally, I can review and create the assignment.
This will take just a short time. Notice that the notification indicates the assignment
may take up to thirty minutes to be active. I previously assigned the same initiative
with the same parameters so I can demo the results without waiting.
So let's try to violate the policies. I'm going to try to create a resource group in a disallowed region.
The only regions I allowed in the initiative assignment were "East US" and "West US",
so any other region should fail. I'll select "South Central US",
"Review + Create", and "Create", and almost immediately I receive an error message
indicating "Failed to created the resource group". Under "View error details",
the text indicates "Resource was disallowed by policy"
and the "Raw Error" tab explains the details of the policy violation.
Let's confirm that it was an initiative assignment that caused that failure.
I'm going to go back to Policy, and under "Authoring", "Assignments",
in the ellipsis menu, I'm going to select "Delete assignment". I'm going to do that
both for the one I just did in front of you and for the one that I did earlier today.
Now, this is a very quick operation as well, and generally you don't have the delay with
removing a policy assignment or initiative assignment that you have with assigning
in the first place. So let's try to create the resource group again...
And I will call this "WillItFail", and I'll place it in South Central US.
And "Create", and that time the resource group created successfully.
Azure Policy and Initiatives can not only block requests; they can also modify requests,
but allow them to continue. For example, if a business rule states that
all resources must have environment and project tags,
you might decide to automatically add those tags with default values if the tags are not present.
When an ARM request does not meet the policy requirements,
Azure will automatically add the appropriate tags.
Generally, as an ISV, you’ll be looking at using Azure Policy and Azure Initiatives the same way
a standard enterprise customer would, to control details of the acceptable requests
against your environment. However, if you’re publishing to the Marketplace
either a Managed App or Virtual Machine offering, it’s important to remember those
offers are deployed to the customer’s environment. This means that your
application’s resources will be impacted by any policy and initiatives assigned to the customer's
environment if they are at an applicable scope
(management group, subscription, or resource group.)
Your support staff need to be prepared to handle failures caused by policy restrictions.
The Azure Activity Log will indicate that the failure was caused by a Policy concern.
The Activity Log is covered in the ISV session around logging and monitoring.
There are three Microsoft Learn modules specific to Azure Policy and Azure Initiatives
that you might find helpful to understanding this topic more.
The first is on defining Azure Policy, the second is on implementing Azure Policy,
and the third is on defining Azure Initiatives.
Another governance concept, one that targets larger deployments,
and broader compliance needs, is a feature called Azure Blueprints.
Azure Blueprints enable cloud architects and central information technology groups
to define a repeatable set of Azure resources that implement and adhere
to an organization’s standards, patterns, and requirements.
Azure Blueprints makes it possible for development teams to rapidly build and
stand up new environments with a built-in set of components,
such as networking, in a way that ensures consistency,
speeding up development and delivery. Blueprints are a declarative way
to orchestrate the deployment of various ARM templates and other artifacts such as:
Role Assignments, Policy Assignments, and Resource Groups.
As an ISV, you might use Blueprints to quickly deploy QA environments,
or, for a virtual machine offer, you might publish samples that reference
your virtual machine image with other likely resources deployed in parallel.
Microsoft has created sample blueprints that reference specific compliance regimes
that can help you deploy resources in a compliant way.
On the Azure Portal, in the Blueprints view, if I select "Create" a Blueprint,
I get a list of samples that have been created to help you with this work.
For example, there is an ISO 27001 set of controls...
there's also a NIST publication 800-171 revision 2,
and 800-53 revision 4, as well as PCI-DSS. All of these are available to you to build your own
Blueprints with these as a template or starting point for deploying resources
matching these particular compliance regimes.
And with that, I’ve reached the end of this governance session about concepts
for basic compliance, from an ISV point of view.
Other sessions include one on organizing resources in Azure,
and an all-up ISV summary session on governance topics.
I hope you found this helpful. Remember, you can find the reference links
at https://aka.ms/GovernanceReference. Thank you for watching,
and I hope this helps you invent with purpose on Microsoft Azure!