1. Automation of your Azure Governance Methods
Michael O’Leary

2. Why speak about Governance?
There are many “gotchas” after the initial excitement of deployment
Costs, tagging
Compliance, reporting, logging, and auditing
Network security, RBAC
Automation, Day-2 operations, maintenance and troubleshooting
Decommission and/or constant clean-up of your environment.
I spend a lot of time
Cleaning up, and then wishing I had rules in place to begin with
Researching how to do things after an initiative is decided on
Structuring the unstructured.

3. What makes up Governance?
Architecture decisions
Subscriptions, billing, VNET’s, deployment methods, allowed resources
Management decisions
Permissions, workloads planed for migration, your IT roadmap
Today I’ll cover just a few resources to help
Tags
Service Principals
Resource Group and Subscription Architecture
RBAC and custom roles
Resource Policies

4. Before we begin, some context
Once you get to production, you should be using automation of some kind.
We are still looking for the perfect “cloud broker tool” to solve our problems
We use ARM templates to deploy wherever possible.
We use TFS for source control.
We use TFS RM for Release Management where possible.
We use vRO as an automation point, mostly accessing Azure via REST and Powershell.
We use vRA as a user “self service portal”. I.e., an end user should never see the Azure portal.

5. 3rd party tools to automate AzurE

6. Tags
Tags are a logical way to group resources. Especially useful for billing, reporting, management, etc
Best practices at my workplace for structured use of tags:
Start with a tagging guide
Minimize number of mandatory tag
Tag via automation, never ad-hoc
Enforce via Resource Policies
Best practices:
We have 2 mandatory tags for all resources: Environment (PRD, DEV, UAT, etc), and Application. From this I can get everything else from our CMDB.
We have a special requirement for VDI machines. Cost Center. We have a defined list of cost centers available in our automation.
Optional tags come after this.
Tags are enforced by policy. Right now we are in audit mode, but will be in enforcement mode soon.

10. Service Principals A Service Principal represents the instance of an application in Azure AD.
Like a service account in Windows, a SP is used for automation tasks
I’ve used SP’s in these examples because
I authenticate to AzureAD via ADFS (no password sync)
I need a “service account” to log into Azure RM programmatically
When to use a Service Principal
When you need to access an Azure resource programmatically
When you need an exception from your organizations 2FA policy
Don’t store the client key, recreate it.
Service Principal vs User in AAD
SP can have multiple secret keys (vs 1 password)
Secrets can have expiration date
Better for locked down, programmatic access

11. Subscriptions and Resource Groups
We have chosen the model of 1 “production” Subscription
We have an Enterprise Agreement
We need a DevTest subscription
We do have some outside projects with a non-governed EA subscription
Resource Groups
“Management unit” of resources for deployments.
We have a naming convention of <region>-<app>-rg
No nesting of RG’s

12. RBAC Avoid assigning roles at the Subscription level
Use least-privilege access, at RG level
Inheritance applies, cannot break inheritance
Assign roles to
Service Principals where possible, to be used by automation
AD groups, not users.
We have used custom RoleDefinitions for
RG creation and management
Resource Policy management
Some SQL roles where a service is global and we cannot apply RBAC at the RG level
I currently use Powershell to report to compliance department on RBAC
I have not found an easy graphical dashboard for compliance users.

13. RBAC (continued) A RoleDefinition is a set of actions
A RoleAssignment is the marriage of
A RoleDefinition
A principal (AAD user, group, or SP)
A scope at which it’s applied
Today I have about 5 custom roles, otherwise I use default roles.
All of my custom roles are at the subscription level.
I try to manage RBAC with automation
I try to report on RBAC with automation
Example: Creating and managing RG’s

14. Resource Policies
Policies focus on resource properties during deployment and for already existing resources
Resource Policy is made up by a
Policy Definition (and Initiative Definition)
Scope (and notScope)
Policy Assignment
Real world examples:
No public IP addresses except in the RG I specify
Resource type blacklist / whitelist
Tagging (audit or enforcement)
Azure Policy is a service in Azure that you use to create, assign and, manage policy definitions. Policy definitions enforce different rules and actions over your resources, so those resources stay compliant with your corporate standards and service level agreements.
Best example I can think to for oversight / governance.
How is it different from RBAC?
There are a few key differences between policy and role-based access control (RBAC). RBAC focuses on user actions at different scopes. For example, you might be added to the contributor role for a resource group at the desired scope. The role allows you to make changes to that resource group. Policy focuses on resource properties during deployment and for already existing resources. For example, through policies, you can control the types of resources that can be provisioned. Or, you can restrict the locations in which the resources can be provisioned. Unlike RBAC, policy is a default allow and explicit deny system.
To use policies, you must be authenticated through RBAC. Specifically, your account needs the:
Microsoft.Authorization/policydefinitions/write permission to define a policy.
Microsoft.Authorization/policyassignments/write permission to assign a policy.
Microsoft.Authorization/policySetDefinitions/write permission to define an initiative.
Microsoft.Authorization/policyassignments/write permission to assign an initiative.
These permissions are not included in the Contributor role.
Policy definition
Every policy definition has conditions under which it is enforced. And, it has an accompanying action that takes place if the conditions are met.
In Azure Policy, we offer some built-in policies that are available to you by default. For example:
Require SQL Server 12.0: This policy definition has conditions/rules to ensure that all SQL servers use version Its action is to deny all servers that do not meet these criteria.
Allowed Storage Account SKUs: This policy definition has a set of conditions/rules that determine if a storage account that is being deployed is within a set of SKU sizes. Its action is to deny all servers that do not adhere to the set of defined SKU sizes.
Allowed Resource Type: This policy definition has a set of conditions/rules to specify the resource types that your organization can deploy. Its action is to deny all resources that are not part of this defined list.
Allowed Locations: This policy enables you to restrict the locations that your organization can specify when deploying resources. Its action is used to enforce your geo-compliance requirements.
Allowed Virtual Machine SKUs: This policy enables you to specify a set of virtual machine SKUs that your organization can deploy.
Apply tag and its default value: This policy applies a required tag and its default value, if it is not specified by the user.
Enforce tag and its value: This policy enforces a required tag and its value to a resource.
Not allowed resource types: This policy enables you to specify the resource types that your organization cannot deploy.
You can assign any of these policies through the Azure portal, PowerShell, or Azure CLI. After you make changes to a policy definition, policy reevaluation happens about once an hour.
To learn more about the structures of policy definitions, look at this article - Policy Definition Structure.

15. Resource Policies (Continued)
New and improved dashboard area called Azure Policy
Limitations today
Eg. If tag A exists, tag B must exist too
Eg. If it’s a SQL server, I want it to have these firewall rules, otherwise none
Solution: run scripts to audit your environment for logic that is not provided by policies
Best practices
Start with audit affect, move to deny affect
Audit your policy compliance if you enforced it after day 0
Automate
Keep policies in source control.
Apply your policy using a principal with permissions to do only that.

17. Stitching it all together:
We can now marry the preceding concepts together with automated release:
We have a Resource Policy that requires Tags
We want to store the PolicyDefinition in source control (TFS) in JSON format
We want to deploy to Azure with automated release tools (TFS RM)
We want TFS to login to Azure with a ServicePrincipal
We want that SP to have only the permissions it requires to apply policy (Custom Role with RBAC defined)
We want to apply the RP at a given scope (at my work, it’s the subscription level)