Microsoft Ignite 2019 – Extending Azure Resource Manager (ARM), Azure’s Control Plane

Speakers:

  • Guarav Bhatnagar
  • Evan Hissey

Challenges with Extending Azure

  • As part of my template deployment, I want to …
    • Do some post-configuration to set up my application
    • Ex-Configure DB passwords, etc.
  • Certain services/types/APIs can’t be called from ARM templates
    • Ex – Create AD users, storage tables, calling APIs external to Azure
  • 200+ Azure services – which ones are the right ones for my applications?
    • Which is the rights VM SKU to use?
    • Which would be more cost effective for my company?
  • Integrating my service in Azure
    • New or existing SaaS
    • Service just for my enterprise
    • Easy discovery for Azure customers

What is Extending Azure?

What does this really mean? Magnify the power of Azure platform by enabling customers and partners to easily bring in custom solutions to Azure.

  • Who are you building it for?
    • Own ent3erprise
    • Selected customers
    • All customers?
  • Different options available at your disposal

Deployment Scripts

  • New resource type – Microsfot.Resources/deploymentScripts – can be run directly from your ARM template.
  • Allows running PowerShell/CLI scripts
  • Script can be provided inline or URI
  • Pre or post configuration of ARM resources
    • Ex: configurate Cosmos DB accounts, DB passwords, create certifictes.
  • Fire and forget resource type
    • Configurable auto-deletion of this type – delete? And when?

Demo Service Catalog – Nothing New Here

Goes to Storage Accounts to create one. Names it. Clicks through. It fails at validation. It fails because he does not have permission to create a storage account – a policy prevents creation. He goes to service catalog. There is a managed storage account option there. It’s just managed apps – behind the scenes, a “service provider” subscription is filled with the actual resources, and they are reflected and billed through the “customer” subscription.

Extensibility Questions

  • Organisations want to extend ARM and Azure management to the services they use, both custom and 3rd party built.
  • Partners want to extend their services directly into Azure for their customers. Bring your SaaS into Azure, for example. Or create an API to do some complex task.
  • Managed app developers need to give some control to their customers

You can create custom resource provider custom actions and custom resources. Access from Managed App UI, PowerShell, ARM Template, HTTP Request. Any REST API, Azure Function, and more.

Azure Custom Provider Enables

  • Organisations want to extend Azure management to the service they use, both custom and 3rd party
  • Partners want to extend their services directly into Azure for their customers.
  • Manage app providers want stuff.

Demo

He’s got a managed application for ServiceNow in the Azure Portal. He clicks add to “onboard” resources. This gives the managed app permissions to the resources.

Managed App VS Code extension in private preview now and public version coming soon.

We can see in the VS Code ARM managed app code that one of the actions calls a logic app. We are shown the logic app, which uses a ServiceNow CMDB API call.

New feature: A policy to associate a managed app with an action, e.g. do something when a resource is created.

Customer Needs

  • Operated and managed for them by a 3rd party
  • Simple discovery and acquisition from Azure Marketplace
  • No overhead to begin when consuming complex applications

Partner Needs

  • Enable management out of the box
  • Easy to author
  • Something else

Azure Managed Applications Demo

Partner publishes an app in Managed Applications Center in Marketplace Applications. Can view subscription IDs, resource groups, customer names, version, and even alerts. Creates a new offer/SKU. Adds a new packaged file which is a zip file containing JSON files. Specifies principal ID and permissions for support staff from the partner tenant.

New private preview in December. You can specify custom metering for managed applications. It will appear in the customer bill. You can have up to 18 line items. You can create different tiers of SKUs.

What is a Resource Provider?

Around 220 RPs in Azure, 10% of which are third party. Most powerful mechanism to deliver your service to Azure customers.

Get the benefit of the Azure platofrm native capabilities for your services: RBACK , policy, billing and more.

Why Create an RP?

  • Customers use native Azure services AND partner services
  • Homogeneous experience across services
  • Capability parity across services
  • Custom billing

Build Services for off-Azure resources

  • Leverage Azure Arc and provide capabilities over Azure
  • More

Waste of useful time for customer story sales pitch.

Microsoft Ignite 2019 – Delivering Services Privately in Your VNet with Azure Private Link

Speakers:

  • Narayan Annamalai, Group Program Manager, Microsoft
  • Sumeet Mittal, Senior Program Manager, Microsoft

Private PaaS

We’ve been using Service Endpoint in addition with ACLs on the PaaS services. But this doesn’t provide an IP on the subnet. NSGs still need to allow access to all IPs of that PaaS service, e.g. all storage accounts.

Private Link maps your PaaS service into a subnet via an IP address. A private endpoint is effectively a NIC that connects to an instance of the PaaS.

Data Exfiltration Protection

Only a specific PaaS instance is mapped into your VNet subnet. So only one storage account, for example, joins your subnet via the Private Endpoint.  Trying to by pass this using clever tricks, e.g. DNS, will not work because the packets are dropped – this is data exfiltration protection.

Other clouds map an entire service, e.g. all storage accounts, to an IP address. Azure Private Endpoint maps a specific instance, e.g. a single storage account, to an IP address.

Secure Connectivity From On-Premises

Before:

  • You connect to PaaS via public DNS
  • The name resolves to the service public IP address
  • If VPN/no connection, you route over Internet. If ExpressRoute with Microsoft Peering enabled, you route over the ExpressRoute circuit.

After:

  • You connect to the PaaS service using a new DNS name
  • You route over the network connection (VPN/ER) to the VNet/subnet.
  • You connect to the Private Endpoint private IP address for the instance of the PaaS service.

Not Just For PaaS

Not just a new feature. It’s a new platform ability.

You can build your own services too, behind Standard Tier Load Balancer, and present the services to other VNets/tenants via Azure Private Link.

Private Link is the product. Private Endpoint is how you use it.

There are three kinds of Private Link:

  • PaaS
  • Other partner services (Snowflake)
  • Consume your own services

Simple Example – VM to Storage Account

VM sends a packet to Blob1.core.windows.net. The packet drops to the host SDN. An encapsulation layer adds a routable DIP (data center IP) address and some metadata. The packet travels the backbone network to the storage frontend. It is decapsulated and presented to the destination.

Demo

Creates a storage account. In networking, he has a choice of Public endpoint (all networks), public endpoint (selected networks), private endpoint.

He creates a private endpoint and selects the VNet/subnet. He then integrates with a private Azure DNS zone. It creates a DNS record for the storage account mapping to it’s private IP address in the VNet/subnet.

Into the storage account > Private Endpoint Connection. Tries to connect to the storage account from Internet – no access. He starts up a VM in the same VNet as the storage account private endpoint. He does a nslookup of the storage account’s private DNS name and it resolves to the IP address in the VNet.

In the VM he opens storage explorer and edits a blob. He logs into another VM that is also on the VNet. Browses to the storage blob in Storage Explorer. Opens the previously edited blob and can see the edits.

This storage account is now accessible from the VNet and nowhere else.

Announcements

  • Preview in all regions
    • Storage, ADLSv2, SQL DB, SQL DQW, Customer Own Service
  • Public preview Private Link available for Cosmos DB
    • Resions: uswestcentral, usnorth, uswest

Your Own Services

You can provide or consume your own services via Private Link.

  • Create/convert your existing services into Private Link Service – one API call to convert
  • VNet-Vnet connectivity without worrying about overlapping IP space
  • No regional, teant, subscription, or RBAC restrictions
  • More

Create Private Link Service

Lots of Marketplace scenarios spanning tenants.

  • App behind Std Load Balancer
  • Link service with one button/API call.
  • Mapped to the private IP of the load balancer

Consume Private Link Service

Similar to consuming PaaS:

  • Create a private endpoint
  • Attach to identification from the service provider
  • Done!

Approval Workflow

  1. Service provider creates a service
  2. Service provider creates a private link with Std LB
  3. Service provider shares private link service ID with consumers.
  4. Consumer creates a private endpoint in subnet with the service ID
  5. There is an approval by service provider.
  6. Consumer configures DNS to map to the private endpoint

Key Capabilities

  • Alias: Masks service provider resource IDs with a globally unique readable name. Mapped on the backend. The unique name uses a hash of stuff from service provider and other attributes.
  • Visibility: How to control access to the alias/service, e.g. stop random people DOSing you. You can make a service completely private to approved customers. Or you can make a service private to all Azure customers. Or you can limit visibility to selected subscriptions.
  • Auto-Approval: For huge services, you can avoid manual approvals. You can set audiences in the auto-approval list.
  • NAT-IP: The service provider masks customer IPs using NAT IP.

NAT IP

IP allocated by service provider

Acts as a source IP for inbound packets

Keeps service provider network private

Helps ensure overlapping IPs between source and destination are acceptable

TCP Proxy v2 Support

Service provider says they want to receive the TCP headers and extract the information. This allows you to identify unique customers even though they share a NAT IP on the service provider side: ACL, filter, etc.

Simplified Network Management

  • Predictable IP for configuring your policies
  • Cleaner ACLs on both Azure and on-prem
  • Resource the traffic the way you want
  • Approval workflow based modelling. No RBAC dependency
  • More

Demo

Goes to Private Link Center. Creates a new service and names it/selects region. Chooses the Std Load Balancer in front of the service. Selects up the frontend IP and NAT IP address. Chooses the auto-approval method.  A new Private Link Service resource is created – opens it and we can see the alias – copies it.

Creates a new Private Endpoint in a different subscription. Chooses the option to connect to the Alias ID and adds request text. Selects the VNet/subnet to put the private endpoint into.

In Private Endpoint Connections, the service provider sees the request and can approve/reject it – approves it.

On the consumer side he tries to connect to the private IP address – it’s just NATing RDP to the VMs in the service provider network.

Marketplace Services

  • Create the services
  • Advertise
  • Manage

Microsoft Ignite 2019 – Building and Managing Distributed Micro-Perimeters With Azure Firewall

Speaker: Yair Tor, Principal Program Manager

Azure Firewall

Cloud native stateful firewall as a service. A first among public cloud providers.

  • Central governance of all traffic flows
    • Built in high availability and auto scale
    • Network and application traffic filtering
    • Centralized policy across VNets and subscriptions
  • Complete VNet protection
    • Filter outbound, inbound, spoke-spoke
  • Centralized logging
  • Best for Azure

Key Features

  • Application Rules
  • Fully stateful network rules
  • NAT support
  • Threat Intelligence (GA this week)
  • Monitoring
  • Support for inbound and hybrid connections
  • Network Watcher integration

Azure Firewall Updates

  • Recently released
    • Multiple public IPs GA – up ot 100
    • Availability zones now GA (99.99% SLA)
    • Threat Intelligence based filtering now GA
    • Azure HDInsight (HDI) FQDN tag GA
    • TDS (SQL) FQDN filtering in Preview
  • Sovereign Clouds
    • US Gov
    • China
  • Coming soon: tentative ETA H2 CY 2019
    • FQDN filtering for all ports and protocols
    • Native forced tunnelling support
    • IP groups in Azure Firewall rules – coming to NSG and UDR too.

Azure Firewall Manager – See Previous Post

Preview

  • Central deployment and configuration
  • Automated routing
  • Advanced security with 3rd party SECaaS

Roadmap:

  • Virtual network support – this is the legacy form of Azure Firewall that is not the new Azure vWAN Hub Azure Firewall.
  • Split routing

Public Preview

  • Extend your security edge to Azure with Secured Virtual Hubs.
  • A secured virtual hub is an azure Virtual WAN Hub with associated security and routing policies configured by Azure Firewall Manager.
  • Easily create hub-and-spoke architectures with cloud native security services for traffic governance and protection.
  • Azure Firewall now integrated with Virtual WAN Hubs.
  • Secured virtual hub can be used as a managed central network with no on-prem connectivity.
  • There is no resource called Security Virtual Hub – it’s more of a deployment/concept. If you did a JSON deployment, it would use legacy resources.

Getting Started with Secured Virtual Hubs

One method:

  1. Create your hub and spoke architecture
  2. Select security providers: Done by secured virtual hub creation or by converting a Virtual WaN hub to secure virtual hub.
  3. Create a firewall policy and associate it with your hub: applicable only if using Azure Firewall
  4. Configure route settings on your secured hub to attract traffic: Easily attract traffic to the firewall from the spoke VNets – BGP!

Demo

Network rules are always processed before application rules in Azure Firewall. Inherited policy cannot allow stuff that parent policy denies.

Central Security and Route Policy Management

  • Deploy and configure multiple Azure Firewall instances
  • DevOps optimized hierarchical Azure Firewall Policies
  • Centralized routing configuration

GA Pricing

  • Preview has 50% discount
  • Azure Firewall in secure virtual hubs will be the same price as normal Azure Firewall
  • $100 per policy for policies that are associated with multiple hubs. No cost with policies associated with single hubs.
  • Fixed fee for outbound VPN to SECaaS partners in addition to a VPN scale unit charge.

Microsoft Ignite 2019 – Securing Your Cloud Perimeter With Azure Network Security

  • Speaker: Sinead O’Donvan (Irish, by the accent)

Zero Trust Architecture document

7 pillars:

  • Identity
  • Devices
  • Data
  • Apps
  • Infrastructure
  • Networking – the focus here

Verify explicitly every access control

  • Being on the network is not enough

Use least privilege access

  • IP address is not enough

Assume breach

  • No one is perfectly secure. Identify the breach. Contain the breach. Do your best to stop breaches in the first place.

You cannot claim success:

  • It requires constant improvement.

Network Maturity Model

  • Traditional (most customers)
    • Few network security perimeters and flat open network
    • Minimal threat protection and static filtering
    • Internal traffic is not encrypted
  • Advanced
    • Many ingress/egress cloud micro-perimeters with some micro-segmentation
    • Cloud native filtering and protection for known threats
    • User to app internal traffic is encrypted
  • Optimal
    • Fully distributed ingress/egress cloud micro-perimeters and deeper micro-segmentation
    • ML-based threat protection and filtering with context-based signals
    • All traffic is encrypted

Three Cores of Azure Network Security

  • Segment – prevent lateral movement and data exfiltration
  • Protect – secure network with threat intelligence
  • Connect – embrace distributed connectivity … or face revolt from the users/devs

Deploy securely across DevOps process

Azure Features

  • Azure Firewall
  • Azure WAF
  • Azure Private Link
  • Azure DD0S Protection

Plus:

  • VNets
  • NSGs
  • UDRs
  • Load Balancer

Network Segmentation

3 approaches:

  • Host-based: an agent on the VM implements it
  • Hypervisor: Example, VMware SNX
  • Network controls

Azure Network Segmentation Controls

  • Subscription: RABC, logic isolation for all resources
  • Virtual network: An isolated and highly secure environment to run your VMs and apps. “This is the hero of segmentation”
  • NSG: Enforce and control network traffic security rules that allow or deny network traffic for a VNet or a VM.
  • WAF: Define application specific policies to protect web workloads.
  • Azure Firewall: Create and enforce connectivity policies using application, network and threat intelligence filtering across subscription(s) and VNet(s).

Multi-Level Segmentation

  • Connectivity:
    • Use both public or private IP. Public app interface is public, backend is private.
    • Choose cloud transit approach VNet peering or Virtual WAN.
    • Carefully control routing
  • Infrastructure
    • Segment across subscription, vnet, and subnet boundaries
    • Managed at an org level
  • Application
    • Enable application aware segmentation
    • Easily create micro perimeters
    • Managed at an application level

Azure Firewall Manager (Preview)

  • Central deployment and configuration
    • Deploy and configure multiple Azure Firewall instances
    • Optimized for DevOps with hierarchical policies
  • Automated Routing
    • Easily direct traffic to your secured hub for filtering and logging without UDRs
  • And more

Azure Web Application Firewall

Preview:

  • Microsoft threat intelligence
    • Protect apps against automated attacks
    • Manage good/bad bots with Azure BotManager RuleSet
  • Site and URI patch specific WAF policies
    • Customise WAF policies at regional WAF for finer grained protection at each host/listener or URI path level
  • Geo-filtering on regional WAF
    • Enhanced custom rule matching criterion

MS sees 20/30 DDoS attacks per day.

WAF as a Service

  • Barracuda
  • Radware

Both run in Azure.

Connectivity

It’s time to transform your network.

  • User to app moves to Internet centric connectivity
  • Application to backend resources use private connectivity
  • Redesign your network and network security models to optimize user experience for cloud
  • Continue to extend app delivery models and network security to the edge

Azure Firewall Manager

  • Easily create multiple secured virtual hubs (DMZ Hubs) in Azure
  • Use Azure Firewall or 3rd party security
  • Create global and local policies
  • Easy to set up connectivity
  • Roadmap:
    • Split routing – optimized O365 and Azure public PaaS

CheckPoint CloudGuard Connect will debut soon as a partner extension.

Azure Private Link

Highly secure and private connectivity solution for Azure Platform.

  • Private access from VNet resources, peered networks and on-premises networks
  • In-built data exfiltration protection
  • Predictable private IP addresses for PaaS resources
  • Unified experience across PaaS customer owned and marketplace services

Microsoft taking this very seriously. All new PaaS services “from Spring onwards” must support Private Link.

Azure Bastion

See previous posts on this – it requires more work IMO because it lacks VNet peering support and requires login via the Azure Portal – doesn’t support MSTSC or SSH clients.

Key Takeaways

  • Embrace zero trust network model
  • Segment your network and create micro-perimters with Azure Firewall, NSG, etc
  • Use a defense in depth security strategy with cloud native services
  • Enable WAF and DDoS
  • Explore Azure as your secure Internet edge with Azure Firewall Manager

Microsoft Ignite 2019 – Windows Server on Azure Overview, Lift-and-Shift Migrations for Enterprise Workloads

Speakers:

  • Rob Hindman, Microsoft
  • Elden Christensen, Microsoft

Why Windows + Azure

  • Unmatched security
  • Built-in hybrid
  • Most cost effective
  • Unparalleled innovation and deep trust with enterprises

Weighing Your Options

  • Rehost – lift and shift
  • Refactor, rearchitect or rebuild – modernize/transform

Workloads

Typically dictates your migration options.

Windows Server 2008/R2

Lift-and-shift to Azure offers free extended security updates beyond the normal EOL of Na 14, 2020, by 3 more years (Jan 14, 2023).

You can unlock on-prem server extended support (if you buy it) through the Azure Portal.

Hybrid Benefit

If you have Software Assurance then you can reduce your Windows Server cost (built into the cost of Azure VMs with Windows) with the Azure Hybrid Use Benefit (AHUB).

Workloads

A bunch of eyechart tests that should be downloaded for reference.

S2D with Ultra Disk support “coming soon”.

SLA

You can build HA in infrastructure or app. Focus on App availability – Azure VM SLAs are built on this concept. Other consideration is operational consistency.

Designs

A bunch of designs are shown, including S2D and Storage Spaces clusters. Two Azure options:

  • Premium File Shares (GA) as shared storage
  • Shared Azure Disks (roadmap) as shared cluster disks – witness & CSV https://aka.ms/SharedDiskSignUp Will support Premium SSD and Ultra SSD.

Lessons From The Trenches

Download the slide(s) – lots of details.

  1. You are the operator of Azure VMs and must to updates, backups, etc, and test.
  2. You must practice failure scenarios and have processes to deal with it.
  3. DO not use the VM temporary disk
  4. Do not attempt to convert from Standard to Premium disks during DR site failover – the conversion is not instant.
  5. Large VMs do not compensate for application architecture –sometimes refactoring cannot be avoided
  6. Do not had-code specific VM gallery image names into scripts. Images are retired after two years – use the latest version because it is recently patched.
  7. Use DskSpd and FIO to measure performance as early as possible. Run multiple tests – because Azure Cache will kick in to improve performance. Note that some regions (East US) will perform faster than others.
  8. Use WS2019 to capture Azure host maintenance events in the faulover clustering event logs – 1139, 1140, 1136
  9. S2D on Azure IaaS VM guest clusters can only use 2-way and 3-way mirror reliiency types. S2D caching tiers cannot be used.
  10. Don’t let S2D volumes become 100% full. Expanding when they are full is difficult and requires downtime.
  11. S2D is slower on clouds that enforce VM network QoS
  12. Mirror repair is faster on WS2019.
  13. WS2019 for file server roles, especially the Information Worker workload is better.

 

 

Microsoft Ignite 2019 – Global Transit Network Architectures With Azure Virtual WAN

Speakers:

  • Reshmi Yandapalli (main speaker), Principal Program Manager
  • Ben Peeri, KPMG customer story

Lots more content in the hidden slides in the download.

Scale

Usual stats. Interesting note: a new POP being built almost every day.

Azure WAN: Global Transit Architecture

The Beginning

  • HQ/Bigger Office
  • Branhc office(s)
  • Users
  • Private WAN
  • Shared services

Start with HQ. Users multiply. VLANs multiply. Locations multiply. WAN grows. You grow:

  • Need to simplify network
  • Need ease of use
  • Need operational savings.

Azure Virtual WAN

  • Managed hub & spoke architecture, with hub being Azure and spokes being offices.
  • Public (VPN) and private (ExpressRoute) connectivity.
  • Global Scale:
  • 20 Gbps S2S VPN and 20 Gbps ER = 20 Gbps user VPN
  • 10K users per hub
  • 1000 sites per hub
  • 1 hub per region
  • Transit routing
  • Cloud Network Orchestration
  • Automated large-sale branch/SDWAN CPE connectivity

Connectivity

What if you had many regions – many hubs. And what if you wanted any branch to access any Azure VNet, regardless of local vWAN hub? In other words, connect to a hub, and use the Azure WAN to seamlessly reach the destination. So you build hub/spoke in different Azure regions, each with a vWAN hub. And a branch connects to the closest vWAN hub, and can get to any Azure VNet via transitive routing between vWAN hubs across the Azure WAN.

  • Simplified network
  • Ease of use
  • Operational savings

This is called Global Transit Architecture over Azure Virtual WAN.

Azure Virtual WAN – What’s New

  • Any-to-Any connectivity (Preview, soon GA)
  • ExpressRoute and User VPN GA
  • ExpressRoute encryption
  • Multi-link Azure Path Selection
  • Custom IPsec
  • Connect VNG VPN to Virtual WAN
  • Availble in Gov Cloud & China
  • Azure Firewall integration (Preview) – this is the big announcement IMO
  • Pricing – reduced
  • New partnerships coming soon
    • Arista,
    • Aruba
    • Cisco
    • F5
    • OpenSystems
    • VeroCloud

Global Transit Architecture – A Customer Example

  • 4 regions, 70 countries with 100’s of sites. 34 VNets, 2 ExpressRoute Premium circuits.
  • Challenges: scale issues, routing complexity, ER VNet limits

The before and after architecture diagrams are totally different – after is much more simple.

Azure Virtual WAN Types

Basic:

  • VPN only
    • Branch to Azure
    • Branch to Branch
  • Connect VNet
    • DIY VNet peering, VNet to VNet non-transitive via hub
    • Hubs are not connected

Standard = Basic + Following

  • Stuff

Multi-Link Support in VPN Site

Support dual links of different types/ISPs. Azure sees the link information. The branch partner can do path selection across these links.

Barracuda CloudGen Firewall is the first to support this. You get always-on Azure in the branch.

ExpressRoute

  • GA in Standard Virtual WAN.
  • Up to 20 Gbps aggregate per hub.
  • Private connectivity – requires premium circuit.
  • In Global Reach Location
  • ExpressRoute VPN Interconnect
  • Integrated with Azure Monitor

EXPRESSROUTE + VPN Path Selection

Path selection between ER and VPN. Fortinet can do this.

Customer Story – Ben Peeri, KPMG

No notes here – sales story.

User VPN

  • Available in Standard Virtual WAN
  • Up to 20 Gbps aggregate and 10K users per hub
  • Cloud based secure remote access
    • Works with OpenVON and IKEv2 client
    • Cert based and RADIU authentication
  • Any-to-Any
    • User to branch, user to Azure VNet
  • More

Azure Firewall

  • Firewall in virtual hub
  • Centralized policy and route management
    • VNet to Internet through Azure Firewall
    • Branch to Internet through Azure Firewall
    • Managed through Azure Firewall Manager

Azure MSP Program

Announced in July. Focused on networking. Offerings in Azure Marketplace.

Pricing

  • Connection Unit
    • Site-to-site VPN / ExpressRoute: No reduced
    • User VPN
  • Scale Unit – aggregate throughput
    • 1 VPN scale unit
    • 1 ER scale unit
  • Virtual Hub (Effective CYQ1 2020)
    • Basic vWAN hub: no charge
    • Standard hub
    • Data processing intra region
    • Data processing inter region

Microsoft Ignite 2019 – End-to-End Security for All Your XaaS Resources

Speaker: Yinon Costica

Intelligent Security

  • Identity and access management
  • Threat protection
  • Information protection
  • Cloud security

Threat Actors

Exposure -> Access -> Lateral Movements -> Actions

How Your Teams and Users Work With The Cloud

  • Users use SaaS (sanctioned), apps you build.
  • Developers code apps you build, deploy to IaaS/PaaS (sanctioned).
  • DevOps operate apps you build and IaaS/PaaS (sanctioned).

Plus there is un-sanctioned SaaS/IaaS/PaaS

Where Do Problems Occur?

DevOps:

  • Misconfigured resources
  • Infrastructure vulnerabilities
  • Open network ports

Developers

  • Secret leakage in code
  • App vulnerabilities
  • Open source vulnerabilities

Users:

  • Passwords
  • More

Protect the Infrastructure

Not just VMs. Visibility and protection across all resources and cloud with Azure Security Center.

  • Visibility with Secure Score
  • Avoid misconfigurations with control plane recommendations
  • Patch infrastructure vulnerabilities
  • Close open endpoints using AI powered attack surface reduction controls

Driving Secure Score Through the Organization

AF: I don’t use Secure Score because too many recommendations are wrong and Secure Score changes without infrastructure changes, so a hammer is swung without mistakes.

ASC uses Azure Policy to run an assessment. Driving secure score using governance.

More workloads added to ASC

Didn’t have a chance to note them, but I saw AKS and Key Vault in there.

AKS

  • Protecting the IaaS hosts
  • Protecting the containers

DevOps Good Practices

  1. Good hygiene
  2. Turn on threat protection
  3. Reduce your attack surface
  4. Integrate alerts into your SIEM.
  5. Identify root cause

Shipping Secure Applications

  1. Build secure applications – security is in the pipeline
  2. Protect every layer of the application
  3. Use guidance – best practices, Secure DevOps toolkit.

Securing Your Codebase with GitHub

Understand and secure your software supply chain – very important with opensource. See dependency insights and dependabot. Get automated security alerts and version patches.

And more.

Protect the Usage

Average app uses 1,000 apps.

Cloud App Security. I lost interest here – sorry!

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

Microsoft Ignite 2019  – What’s New In Azure Networking?

Speaker: Yousef Khalidi, CVP Microsoft Azure Networking

Numbers

  • 6 Pbs of capacity in a single region.
  • 30 billion packets/second on the Azure WAN
  • ExpressRoute up to 100 Gbps per circuit
  • 160+ edge locations in addition to the 54 regions bringing the Azure WAN entry points closer to you
  • FPGA hardware provide jitter free networking

Satellite Connectivity

ExpressRoute now supports satellites. Handy for remote or mobile locations, ships, planes, remote mines, oil rigs, etc.

Edge Site

External: customer

Internal: Azure WAN

Features:

  • WAN
  • Azure ExpressRoute POP
  • Front Door, CDN, etc (global services)

Functions of Azure Networks

  • Connect & extend
  • Protect
  • Deliver
  • Monitor

Azure Peering Service Preview

Business quality connectivity to Microsoft clouds.

Connectivity Partners:

  • Local and geo peering tech
  • High capacity peers
  • Optimize Internet traffic routing

A bunch of launch connectivity partners. Looking for more carriers to join.

Azure Virtual WAN

“Completing the screnario”.

GA:

  • ExpressRoute
  • Point to site VPN
  • Path selection from branch

Preview:

  • Hub/any-to-any connectivity – use vWAN as your Internet access point from on-prem.
  • Azure Firewall integration

Cisco SD-WAN partnership with Azure WAN and Office 365.

ExpressRoute

GA:

  • Fast Path
  • ExpressRoute Local – no egress charges
  • Continued expansion of ER locations

Preview:

MACsec encryption:

  • Secures physical links at ExpressRoute sites
  • Bring-your-own-key, store keys in Azure Key Vault
  • Available on ER Direct

ExpressRoute for Satellites

GA.

  • Direct private access to Azure.
  • Connect to Azure from anywhere.
  • 3 partners today: Viasat, SES, Intelsat.

From customer point of view, it looks like normal ExpressRoute.

VPN

High throughput VPN: 10 Gbps GA

  • New gateway SKUs
  • Up to 10 Gbps aggregate
  • Up to 10,000 P2S connections
  • Ikev1 + IKEv2 on VpnGw1-5 GA

VPN Gateway packet capture Preview

Custom IKE traffic scenarios (coming soon)

IPv6

  • Dual stacked for max flexibility.
  • Native IPv6 all the way to the VMs.
  • Private IPv6 addresses for VMs and NICs.

Zero-Trust Networking

A journey with Azure Networking featuring:

  • Azure Firewall
  • WAF
  • Azure Private Link
  • Azure DDos Protection

Private Link Preview

  • Goal is to enable all PaaS services.
  • Built-in data exfiltration protection.
  • Predictable IP for addressing PaaS services.

Azure Firewall Manager

Preview

  • Central deployment and configuration
    • Multiple firewall instances
    • Optimized for devops with hierarchical policies
  • Automated routing
  • Advanced security with 3rd party SECaaS

Roadmap:

  • Virtual network support, split routing

Partnerships to route traffic via Azure WAN to the Internet:

  • zScaler
  • iBoss
  • CheckPoint coming soon

You route from on-prem via Azure WAN, then to partner service to Internet. However, Office 365 should go directly – MS automatically does that.

Azure Bastion is GA

  • RDP/SSH from Azure Portal without NAT rules.
  • No public IPs required.
  • Supports VMs, VMSS, DevTest Labs.

IMO, still not ready for consumption without local SSH/RDP client support.

Azure WAF

Preview:

  • Microsoft Threat Intelligence
    • Protect apps against automated attacjs.
    • Managed good/bad bots with Azure BotManager rule set
  • Site and UDI path specific WAF policies
    • Customise WAF policies at retional WAF for finer grained protection at each host/listener or URL path level
  • Geo-filtering on regional WAF
    • Enhanced custom rule matching criterion includes filtering by country.

Application Gateway

GA

  • Integration with AKS as ingress controller
  • Azure Key Vault integration
  • Enhanced metrics

Coming soon:

  • Wildcard listener
    • No need to create a listener for each domain

Azure Front Door

GA

  • Single or multi-region app and API acceleration
    • Improve HTTP performance and reduce page load times.
  • Load balancing at the edge and fast-failover
    • Build always-on application experiences that fail-fast (safely)
  • Integrated SSL, WAF and DDoS

Azure CDN

GA:

  • Reduced Azure egress pricing
    • Egress is free from storage, compute, media services to Azure CDN from Microsoft.

Preview

  • Easy to use and highly customizable rules engine
    • Few click onboard
    • Use rules engine to customise CDN.

Internet Analyzer Preview

Easily measure and compare end user experience for your application.

  • Cloud migration
  • CDN and app acceleration
  • Perform A/B measurements

Azure Monitor

GA

  • Traffic Analytics – accelerated processing from hours to minutes.
  • Enhanced troubleshooting.

Preview

  • Network Insights – single health console for the entire cloud network

Multi-Edge Edge Compute Demo

There’s an Azure Edge box on stage. It has a SIM and connects via a private LTE connection (MEC). A robot is controlled via the edge box. This is a tech preview at the moment.

BGP with Microsoft Azure Virtual Networks & Firewalls

In this article, I want to explain how important BGP is in Azure networking, even if you do not actually use BGP for routing, and the major role it plays in hub-and-spoke architectures and deployments with a firewall.

What is BGP?

I was never the network guy in an on-premises deployment. Those 3 letters, BGP, were something someone else worried about. But in Azure, the server admin becomes a network admin. Most of my work in Azure is networking now. And that means that the Border Gateway Protocol (BGP) is important to me now.

BGP is a means of propagating routes around a network. It’s a form of advertising or propagation that spreads routes to one or more destinations one hop at a time. If you think about it, BGP is like word-of-mouth.

A network, Subnet A, is a destination. Subnet A advertises a route to itself to a neighbour network, Subnet B. Subnet B advertises to its neighbours, including Subnet C, that it knows how to get to the original subnet, Subnet A. And the propagation continues. A subnet at the far end of the LAN/WAN, Subnet D, knows that there is another subnet far away called Subnet A and that the path to Subnet A is back via the propagating neighbour, Subnet C. Subnet C will then forward the traffic to Subnet B, which in turn sends the traffic to the destination subnet, Subnet A.

Azure and BGP

Whether you use BGP in your on-premises network or not, there will be a pretty high percentage chance that you will use BGP in Azure virtual networking – we’ll get to that in a few moments.

If you create a site-to-site VPN connection, you have the option to integrate your on-premises BGP routing with your Azure virtual network(s). If you use ExpressRoute, you must use BGP. In both cases, BGP routes are propagated from on-premises, informing your Azure virtual network gateway of all the on-premises networks that it can route to over that connection.

But BGP Is Used Without BGP

Let’s say that you are deploying a site-to-site VPN connection to Azure and that you do not use BGP in your configuration. Instead, you create a Local Network Gateway in Azure to define your on-premises networks. The virtual network gateway will load those networks from the Local Network Gateway and know to route across the associated VPN tunnel to get to those destinations.

And here’s where things get interesting. Those routes must get advertised around the virtual network.

If a virtual machine in the virtual network needs to talk to on-premises, it needs to know that the route to that on-premises subnet is via the VNet Gateway in the gateway subnet. So, the route gets propagated out from the gateway subnet.

Let’s scale that situation out a bit to a hub & spoke architecture. We have a site-to-site connection with or without BGP being used. The routes to on-premises are in the VNet Gateway and are propagated out to the subnets in the hub VNet that contains the VNet Gateway. And in turn, the routes are advertised to peered virtual networks (spokes) and their subnets. Now a resource on a subnet in a spoke virtual network has a route to an on-premises virtual network – across the peering connection and to the virtual network gateway.

Note: in this scenario, the hub is sharing the VNet gateway via peering, and the spoke is configured in peering to use the remote VNet gateway.

Bi-Directional

Routing is always a 2-way street. If routes only went one way, then a client could talk to a server, but the server would not be able to talk to the client.

If we have BGP enabled VPN or ExpressRoute, then Azure will propagate routes for the spoke subnets back down through peering and to the VNet Gateway. The VNet Gateway will then propagate those routes back to on-premises.

If you do not have BGP VPN (you are statically setting up on-premises routes in the Local Network Gateway) then you will have to add the address space of each spoke subnet to the on-premises VPN appliance(s) so that they know to route via the tunnel to get to the spokes. The simple way to do that is to plan your Azure networking in advance and have a single supernet (a /16, for example) instead of a long list of smaller subnets (/24s, for example) to configure.

Control & Security

Let’s say that you want to add a firewall to your hub. You want to use this firewall to isolate everything outside of Azure from your hub and spoke architecture, including the on-premises networks. You’ve done some research and found that you need to add a route table and a user-defined route to your hub and spoke subnets, instructing them that the route to on-premises is through the VNet Gateway.

Now you need to do some reading – you need to learn (1) how Azure routing really works (not how you think it works) and (2) how to troubleshoot Azure routing. FYI, I’ve been living in this world non-stop for the last 10 months.

What you will probably have done is configured your spokes with a route to 0.0.0.0/0 via the internal/backend IP address of the firewall. You are assuming that will send all traffic to anywhere via the Firewall. Under the covers, though, routes to on-premises are still propagating from the VNet Gateway to all the subnets in your hub and spoke architecture. If on-premises was 192.168.1.0/24 and your spoke machine wanted to route to on-premises, then the Azure network fabric will compare the destination with the routes that it has in a hidden route table – the only place you can see this is in Effective Routes in a VM NIC Azure resource. You have a UDR for 0.0.0.0/0 via the firewall. That’s a 0-bit match for any destinations in 192.168.1.0/24. If that was the only route in the subnet, then that route would be taken. But we are sending a packet to 192.168.1.x and that is a 24-bit match with the propagated route to 192.1681.0/24. And that’s why the response from the spoke resource will bypass the firewall and go straight to the VNet Gateway (via peering) to get to on-premises. That is not what you expected or wanted!

Note: the eagle-eyed person that understands routing will know that there will be other routes in the subnet, but they are irrelevant in this case and will confuse the explanation.

The following works even if you do not use BGP with a site-to-site VPN!

To solve this problem, we can stop propagation – we can edit the route table resources in the internal Azure subnets (or pre-do this in JSON) and disable BGP route propagation. The result of this is that the routes that the VNet Gateway were pushing out to other subnets will stop being propagated. Now if we viewed the effective routes for a spoke subnet, we’d only see a route to the firewall and the firewall is now responsible for forwarding traffic to on-premises networks to the VNet Gateway.

It is important to understand that this disabling of propagation affects the propagation only in 1 direction. Routes from the VNet Gateway will not be propagated to subnets with propagation disabled. However, ALL subnets will still propagate routes to themselves back to the VNet Gateway – we need on-premises to know that the route to these Azure subnets is still via the Gateway.

More work will be required to get the Gateway Subnet to route via the firewall, but that’s a whole other topic! We’re sticking to BGP and propagation here.

The Firewall and BGP Propagation

Let’s make a mistake, shall we? It will be useful to get a better understanding of the features. We shall add a route table to the firewall subnet and disable BGP route propagation. Now the resource in the spoke subnet wants to send something to an on-premises network. The local subnet route table instructs it to send all traffic to external destinations (0.0.0.0/0) via the firewall. The packets hit the firewall. The firewall tries to send that traffic out and … it has only one route (a simplification) which is to send 0.0.0.0/0 to Internet.

By disabling BGP propagation on the firewall subnet, the firewall no longer knows that the route to on-premises networks is via the virtual network gateway. This is one of those scenarios where people claim that their firewall isn’t logging traffic or flows – in reality, the traffic is bypassing the firewall because they haven’t managed their routing.

The firewall must know that the on-premises networks (a) exist and (b) are routes to via the VNet Gateway. Therefore, BGP propagation must be left enabled on the firewall subnet (the frontend one, if you have a split frontend/backend firewall subnet design).

Not Just Firewalls!

I’m not covering it here, but there are architectures where there might be other subnets that must bypass the firewall to get back to on-premises. In those cases, those subnets must also have BGP propagation left enabled – they must know that the on-premises networks exist and that they should route via the VNet Gateway.