I’m Presenting Two Sessions At NIC 20/20 Vision in Oslo

I will be presenting two Azure sessions at the (NICCONF) NIC 20/20 Vision conference in Oslo on February 6th.

The content I’m presenting on is inspired by the work I have been doing with Innofactor Norway for customers in Norway. So it will be kind of cool to stand (once again) on a stage in Oslo and share what I’ve learned. I have two sessions on the afternoon of the 6th.

Secure Azure Network Architecture

Azure networking & security has become my focus area. I enjoy the organic nature of how Azure’s software-defined networking functions. I enjoy the scale, the possibilities, and the variety of options. And most of all, I appreciate how the near-universally overlooked fundamentals play a bigger role in network security than people realise. It’s a huge area to cover, but I will do my best in the hour that I have:

This session will walk you through the components of Azure network security, and how to architect a secure network for Azure virtual machines or platform services, including VNets, network security groups, routing tables, VNet peering, web application gateway, DDoS protection, and firewall appliances.

Auditing Azure – Compliance, Oversight, Governance, and Protection

An important part of governance is recording what is going on in Azure and being able to retain, query, and report on that data. This is an area I had a cool solution for this time last year, but Microsoft blew that up. Recently I revisited this space and found cool new things that I could do. And in preparing for this session, I found more stuff that I could talk about. I’ve enjoyed preparing this session and it has contributed back to my work. This session is late in the day for most Norwegians, but I hope that attendees stick around.

Auditing isn’t the most glamorous subject, but in a self-service environment, it becomes important to protect assets, the company, and even your job. In this session, you’ll learn how Azure provides auditing functionality that you can query, report on, and store securely for as long as you need it in cost-efficient ways.

Hopefully, I will see some of you there at the event!

Microsoft Ignite 2019 – Top 10 Azure Governance and Adoption Best Practices

Speaker: Nathan Lasnoski, Concurrency, MVP

Prepare & Execute

Picture of a tri-athlete. Riding on perfect smooth surface with perfect picture with hands off the brakes. The person is prepared – set up well. Azure operators & devs should be like this. Ready, confident, and on a smooth road with a great experience with no sudden stops.

Preface – Getting Started

Cloud Maturity Curve.

  • Legacy: On-prem, business not enabling. IT is a blocker to innovation.
  • Legacy +: IT stagnant. Scattered cloud across the business.
  • Platform: Target today – operationalized loud. Goverened.
  • Product:
  • Innovation
  • Fusion: Technology fully business integrated.

What is an “Azure Environment”?

  • Operated by the corporation
    • Runs with standards, policies, controls
  • Diverse workload enablement, powers innovation
    • Servers, containers, serverless, PaaS, AI, digital ledger
  • Stakeholder management
    • Delegated to targeted teams, under corporate oversight
  • Representative of technology investments
    • Areas like cost should relate to intended investment areas/business value. IT is not the bucket of all IT spend – Those spending should care about the things they pay for.

Number 1 – Employee Organizational Change and Operations

Transformation of organization, tied to DevOps

  • Increased multi-skill frameworks
  • Emphasis on code, repeatability, automation

New products/projects made up of:

  • Cloud architecture & operations
  • Innovation and business enablement
  • Application and Product DevOps Teams
  • Security

Number 2 – Define an operational and leave adoption strategy

High level view of a cloud program – diagram in the slides.

  • Define an iterative cloud program whith a MVP motion on operations
    • OPERATIONAL STANDARDS, PROVISIONING PROCESS, WIKI, MOTIONS
  • Be careful about overreaching – Corporation has a bad relationship with IT.

Number 3- Be a Blueprint That is Manageable

A structure of management groups and subscriptions, with limited resource groups.

Left-hand IT, Right-side business. Top – management groups, bottom – IT. Why split corp IT and business areas should be in different subscriptions/management groups.

Using 1 overloaded sub is BAD, even is MS people recommend it (AGREED!). RBAC, cost-management, quotas, etc.

Number 4 – Approaches for provisioning short-term and long-term

Using a portal for provisioning. It’s a manual process. Azure Portal, ServiceNow, whatever – minimise their usage. Problem with portals is that all the old manual problems of on-prem follow to the cloud. No documentation on config. No repeatability. No change control.

Source Code Release (Azure DevOps) > Control Plane (ARM, Policy) > Deployment.

Subscriptions should be read-only. Only time you use the portal to deploy/config should be sandboxes. Enterprise deployments should be done as code:

  • ARM
  • Script
  • Program code

This includes 3rd party stuff you put in VMs.

This is the right way to start. And it prepares you for PaaS, e.g. AKS, App Services, etc.

Number 5 – Define Structures for Naming and Tagging

You cannot work in the cloud long-term without this.

Critical tags:

  • Owning team
  • Business unit
  • Application Name
  • Classification (security)
  • Environment moniker (dev, test, production, etc)
  • Cost Center

Number 6 – Recovery and re-deployment approaches

  • Assume re-deployment at every level, especially corp-IT.
    • The Corp IT infrastructure is code too, store it in a code repository
    • Build based on release management pipeline
  • Re-deployability such as AKS
    • Re-deployable app environments
      • AKS
      • App Services
      • Data services
      • Functions
      • OAM, RUDR, DAPR

Number 7 – Adapt Security Controls For The Cloud

Movement to vertical network design. On-prem IT is flat and horizontal and things talk directly to things. In the cloud, direct connections should be limited with micro-segmentation – see previous blog posts.

This is easier to do in the cloud, and it should be done during migration and new-builds. According to Nathan, it’s one of the reasons to migrate to the cloud at all!

Use Azure Security Center to assess the environment and monitor it from a security perspective. Leverage automated responses to react, e.g. playbooks in Azure Sentinel. Use custom policies to audit Azure too.

Admin accounts:

  • Segment addresses – don’t use admin email accounts for Azure accounts.
  • Limit owner rights. Contributor at most. Read-only ideally in production.
  • Use PIM (AAD P5) to limit access but require rights escalation for admins. Consider approval.
  • Use MFA. Less than 8% of Azure tenants have MFA enabled.

RBAC applied to applications

  • Teams only get access to necessary RGs/subscriptions.
  • Admin owner credentials are different than application credentials
  • Deployments are encouraged to be automated from source code.

Number 8 – Monitoring responsibilities change as application owners take more responsibility

  • Corp IT is responsible for “cloud IT”.
    • Standards policies, connectity – not just things that go bump in the night
    • Ensures governance is applied, monitors for aggregate issues
  • Security might be a separate group
    • Measuring security compliance, reacting to incidents
    • Runs against playbooks but moving declaratively
  • Application teams
    • Own operational monitoring and reacting to their services
    • DevOps teams operating stuff

Azure Monitor/Logs provides data access via resources now that reflects RBAC to resources.

Number 9 – What do I do with my CMDB and how does it change?

  • Original function of the CMDB was to contain configuration data
  • Modern environment is quarriable platform, declarative config, DevOps

Resource Graph and DevOps can be your living always correct CMDB.

Number 10 – Building a methodology for cost reviews and organizational discipline

  • Tags are critical to cost analysis
    • Use policy enforced tagging regimes
    • Apply tags as needed for accounting purposes
  • Be able to judge costs on:
    • Owner
    • Business unit
    • Application
    • Technology
    • Dev/Prod/QU
  • Options:
    • Azure Cost Management
    • Custom PowerBI

Controlling Costs:

  • Setting budgets
  • Analysis and improvement
  • Limit high spenders
  • Optimize sizing
  • Cost management team should pay for itself.

Microsoft Ignite 2019 – Deep Dive on Azure Governance

Observe and Identify Gaps

  • Regulatory compliance requirements
  • News, blogs, industry expectations
  • Bet practice guidelines
  • Internal teams’ recommendation
  • Built-in policies and GitHub policies
  • And so on

Authoring Custom Policy

Can I use policy for this?

  • Resource configurations
  • Azure resources and (selectively) objects within the resource
  • Auto-generation of aliases – Aliases abstract API versions.
  • Resource type for compliance state

Resource Property Alias

  • 95% coverage for all resource properties.
  • If there is a swagger API then there should be an alias
  • If not – open a support case

Authoring a Custom Policy

4 basic steps:

  • Determine resource properties
  • Find alias
    • The ese first two in VS Code extension
  • And 3 other steps 😊

Browse resources in VS Code. Find the property alias. Copy/paste into new policy definition.

Test The Policy

Enforcement:

  • PUT & PATCH

Compliance Assessment

  • Property is compliance, is non-compliance, or doesn’t exist

Enforcement mode setting (recently introduced):

  • Quick what-if testing (coming, January I think) test the result before you roll out the remediation.

Policy-as-code Demo

Shows a released DevOps pipeline.

  1. Create Initiative
  2. Create Initiative
  3. Test Assignment
  4. Deploy (Enforcement Mode set to enabled)

https://aka.ms/policyscripts

Assess Compliance

  • Azure Portal compliance experience
  • Policy Insights API for summary and raw data
  • Export compliance data (coming), e.g. Power BI – they are doing usability studies at Ignite this week.

Road Ahead For Azure Policy

  • Regulatory compliance
  • Multi-tenancy support with Azure Lighthouse
  • Authoring and language improvement
  • And more

Policy for Objects within a Resource

Announcing Key Vault preview. Demo shows ability to control child objects in the Key Vault resource.

And something for AKS engine – slide moved too quick. Demo shows assessment of pods inside an AKS cluster. Enables control of source images. Trying to deploy an unauthorised image to a pod fails because of the policy.

Organizing Resources with Resource Graph

At scale:

  • Management Group: hierarchy. Define hierarchical organization
  • Tag: Metadata. Apply tags as metadata to logically organize resources into a taxonomy
  • Resource graph: Visibility. Query, explore, and analyse cloud resources at scale

Why Resource Graph

Scale. A query of large number of resource will require a complex query via ARM. That query fans out to resource providers and it just doesn’t scale because of performance – available capacity and quota limits.

Resource Graph sends the query to ARM which then makes ONE call to the ARG. ARG is like a big cache of all your resources. Any time that there is a change, that change is notified to ARG very quickly.

ARG – What’s New

Resource Group/Subscription Support

  • Stored in ResourceContainers table
    • Resources/subscriptions
    • Resources/subscriptions/resourcegroups
  • Resources is default table for all existing resources

Join Support

Supported flavours:

  • Leftouter
  • Innter
  • Innerunique

New operators:

  • Union
  • mvexpand – expand an array/collection property

Support For Shared Queries

Save the queries into Graph Explorer.

Save query:

  • Priavete query
  • Shared (Microsoft.resourcegraph/queries ARM resource)
    • Saved to RG
    • Subject to RBAC

Road Ahead For ARG

  • Support for management groups
  • Support for more dimensions
  • Support for more resource properties, e.g. VM power state

Visibility To Resource Changes

Change History went into public preview earlier this year. Build on resource graph – already constantly informed about changes to resources. They take snapshots, identify the differences, and report on those changes. This is available in all regions and is free because it’s built on already existing functionality in ARG.

What’s New

  • Support for create/delete changes
  • Support for change types
  • Support for property breakdown
  • Support for change category

Road Ahead

  • At scale – ability to query across resource containers
  • Notifications – subscribe to notifications on resources
  • Correlating “who” – Ability to correlate a change with the user or ID that performed the call

Azure Management Groups

Microsoft has created a new administrative model for organisations that have many Azure subscriptions called Management Groups. With this feature, you can delegate permissions and deploy Azure Policy (governance) to lots of subscriptions at once.

The contents of this post are currently in preview and will definitely change at some point. Think of this post as a means of understanding the concepts rather than being a dummy’s guide to mouse clicking. Also, there are problems with the preview release at the time of writing – please read Microsoft’s original article before trying this out.

Note: Microsoft partners working with lots of customers, each in their own tenant, won’t find this feature useful. But larger organisations with many subscriptions will.

The idea is that you can create a management/policy hierarchy for subscriptions, as shown in this diagram from Microsoft:

tree

The hierarchy:

  • Can contain up to 10,000 subscriptions in a single tenant.
  • It can span EA, CSP, MOSP, etc, as long as the subscriptions are attached to a single tenant.
  • There can be up to 6 levels of groups, not including the root (tenant) and the subscription.
  • A management group can have a single parent, but a parent can have many children.

Permissions

The tenant has a default root management group, under which all other management groups will be placed. Tenant = Azure AD so we see a cross-over from Azure to Azure AD administration here. By default, the Directory Administrator needs to elevate themselves to manage the default group. You can do this by opening the Azure Portal, browsing to Azure Active Directory > Properties, and setting Global Admin Can Manage Azure Subscriptions And Management Groups to Yes:

image

Now you have what it takes to configure management groups.

Administration

Allegedly today we can use Azure CLI or PowerShell to create/configure management groups, but I have not been able to from my PC (updated today) or from Azure Cloud Shell. However, the Azure Portal can be used. You’ll find Management Groups under All Services.

Creating a management group is easy; simply click New Management Group and give the new group a unique ID and name.

image

Here I have created a pair of management groups underneath the root:

image

To create a child management group, open the parent and click New Management Group:

image

I can repeat this as required to build up a hierarchy that matches my/your required administration delegation/policy model. How I’ve done it here isn’t probably how you’d do it.

image

This is what the contents of the Lab management group look like:

image

Delegating Permissions

In the old model, before management groups, permissions to subscriptions were created at the subscription level, leading to lots of repetitive work for large organisations with lots of subscriptions.

With management groups we can do this work once in the management group hierarchy, and then add subscriptions to the correct locations to pick up the delegations.

The “how” of managing the settings, memberships and permissions of a management group is not obvious. The buttons for managing a management group are hidden behind a “Details” link – not a button! See below:

image

Once you click Details, the controls for configuring the settings and subscription memberships of a management group are revealed in a new, otherwise hidden, blade:

image

Universal permissions should be assigned at the top level management group(s). For example, if I click Access Control (IAM) in the settings of the root management group, I can grant permissions to the root management group and, thanks to inheritance, I have implicitly granted permissions to all Azure subscriptions in my hierarchy. So a central Azure admin team would be granted rights at the default root management group, a division admin might be granted rights on a mid-level management group, and a dev might be given rights at a bottom-level management group.

Once you are in Details (settings) for a management group, click on Access Control (IAM) and you can grant permissions here. The users/groups are pulled from your Azure AD (tenant). As usual, users should be added to groups, and permissions should be assigned to well-named groups – I like the format of <management group name>-<role> for the group names.

image

Azure Policy

You can create a new Azure Policy and save it to a management group. Microsoft recommends that custom policy definitions are saved at a level higher than what you intend to assign it. The safe approach might be to save your custom policy definitions and initiative definitions at the root management group, and then assign them wherever they are required. Note that, just like permissions, any assigned initiative (recommended for easier ownership) or policy (not recommended due to ownership scaling issues) will be inherited. So if my organization requires Security Center to be enabled and OMS agents to be deployed for every VM, I can create a single initiative, stored at the root management group, and assign it to the root management group, and every VM in every subscription in the management group hierarchy will pick up this set of policies.

Here’s an example of where you can select a management group, subscription, or resource group as the target of an initiative definition assignment in Azure Policy:

image

Adding Subscriptions

Right now, we have a hierarchy but it’s useless because it does not contain any subscriptions. THE SUBSCRIPTIONS MUST COME FROM THE CURRENT TENANT.

Be careful before you do this! The delegated permissions and policies of the hierarchy will be applied to your subscriptions, and this might break existing deployments, administrative models, or governance policies. Be sure to build this stuff up in the management group hierarchy first.

To add a subscription, browse to & open the management group that the subscription will be a part of – a subscription can only be in a single management group, but it will inherit from parent management groups.

Click Add Existing to add a subscription as a member of this management group. This is also how you can convert an existing management group into a child of this management group. A pop-up blade appears. You can select the member object type (subscription or another management group). In this case, I selected a subscription.

image

The subscription will be registered in the management group hierarchy.

image

Wrap-Up

And that’s management groups. Don’t waste your time with them if:

  • You’re a Microsoft partner looking for a delegation model with customer’s tenants/subscriptions because it just cannot be done.
  • You have only a single subscription – just do your work at the subscription level unless you want to scale to lots of subscriptions later.

If you have a complex organisation with lots of subscriptions in a single tenant, then management groups will be of huge value for setting up your RBAC model and Azure Policy governance at the organisational and subscription levels.

Did you Find This Post Useful?

If you found this information useful, then imagine what 2 days of training might mean to you. I’m delivering a 2-day course in London on July 5-6, teaching newbies and experienced Azure admins about Azure Infrastructure. There’ll be lots of in-depth information, covering the foundations, best practices, troubleshooting, and advanced configurations. You can learn more here.