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