Private Endpoints and Private Link

Lesson: Private Endpoints and Private Link

1. Introduction: Bridging the Gap Between Security and Connectivity

In a cloud-native architecture, services like databases (e.g., Azure SQL, Cosmos DB) or storage accounts are often exposed via public endpoints. While these services are protected by firewalls and authentication, the traffic still traverses the public internet, which introduces potential attack vectors such as data exfiltration or man-in-the-middle attacks.

Azure Private Link and Private Endpoints allow you to access your Azure PaaS (Platform as a Service) resources privately from your Virtual Network (VNet). By using Private Link, you effectively bring the service into your private network, assigning it a private IP address from your VNet’s address space.

Why use Private Endpoints?

• Security: Traffic never leaves the Microsoft backbone network.
• Data Exfiltration Protection: You can restrict access to specific instances of services, preventing users from connecting to unauthorized accounts.
• Simplified Networking: You don't need public IPs or complex firewall rules for your PaaS services.
• Compliance: Meets strict regulatory requirements that mandate data must not traverse the public internet.

2. Core Concepts: The Anatomy of a Private Link

To understand this technology, we must distinguish between two core components:

1. Private Link Service: The technology that enables the private connection. It is the "listener" on the provider side.
2. Private Endpoint: The "network interface" (NIC) created inside your VNet. It represents the specific resource (e.g., a specific SQL database) and is assigned a private IP from your subnet.

Practical Scenario: Securing an Azure Storage Account

Imagine you have a web application in VNet-A that needs to upload files to Storage-Account-X.

1. The Default: The web app reaches out over the public internet to storageaccountx.blob.core.windows.net.
2. The Private Solution:
   • You create a Private Endpoint linked to Storage-Account-X.
   • The endpoint is placed in a dedicated subnet (e.g., snet-private-endpoints).
   • The Storage Account is configured to disable public network access.
   • Your web app now communicates with the Storage Account via the private IP assigned to the Private Endpoint.

3. Implementation: Infrastructure as Code (Terraform)

Using Infrastructure as Code (IaC) is the industry standard for managing Private Endpoints. Below is an example of how to define a Private Endpoint for an Azure Storage Account using Terraform.

# Define the Private Endpoint
resource "azurerm_private_endpoint" "storage_pe" {
  name                = "pe-storage-account"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  subnet_id           = azurerm_subnet.snet_private.id

  private_service_connection {
    name                           = "psc-storage-connection"
    private_connection_resource_id = azurerm_storage_account.storage.id
    is_manual_connection           = false
    subresource_names              = ["blob"]
  }

  # Private DNS Zone integration is crucial for name resolution
  private_dns_zone_group {
    name                 = "dns-zone-group"
    private_dns_zone_ids = [azurerm_private_dns_zone.blob.id]
  }
}

Note: The subresource_names parameter is vital. For Storage, you can specify blob, file, table, or queue, depending on which service you intend to access privately.

4. Best Practices and Common Pitfalls

Best Practices

1. Use Private DNS Zones: When you create a Private Endpoint, the service's FQDN (Fully Qualified Domain Name) stays the same. You must use Azure Private DNS Zones to ensure that when your application resolves myapp.blob.core.windows.net, it receives the private IP rather than the public one.
2. Dedicated Subnet: Always place Private Endpoints in a dedicated subnet. This keeps your routing tables clean and simplifies Network Security Group (NSG) management.
3. Disable Public Access: Once the Private Endpoint is verified, go to the resource settings and set "Public network access" to "Disabled." If you don't do this, the resource remains reachable via its public endpoint.
4. Monitoring: Use Azure Monitor and Network Watcher to track traffic flow to your Private Endpoints.

Common Pitfalls

• DNS Resolution Issues: This is the #1 cause of "connectivity" problems. If your application is still resolving the public IP, check your DNS integration. Ensure your VNet is linked to the Private DNS Zone.
• Ignoring Network Security Groups (NSGs): While Private Endpoints are secure, NSGs can still block traffic to the endpoint. Ensure your NSGs allow the required traffic on the subnet where the Private Endpoint resides.
• Cross-Subscription Connectivity: If your VNet is in a different subscription than the PaaS resource, ensure the Microsoft.Network provider is registered in both subscriptions.
• Forgetting Service Endpoints vs. Private Endpoints: Do not confuse the two. Service Endpoints provide a secure path to the service but still use the public IP. Private Endpoints provide a private IP within your network.

5. Key Takeaways

• Zero Public Exposure: Private Endpoints are the gold standard for securing PaaS resources, effectively removing them from the public internet.
• DNS is Critical: The success of Private Link relies heavily on correct DNS resolution. Always pair your deployment with Azure Private DNS Zones.
• Layered Security: Even with Private Link, maintain a "Defense in Depth" strategy. Continue to use NSGs, Azure Policies, and identity-based access (RBAC) to protect your infrastructure.
• Scalability: Private Endpoints scale well, but monitor your subnet IP address availability, as each endpoint consumes one private IP address from your address space.

By mastering Private Endpoints, you shift your architecture from "perimeter-based security" to "identity and network-centric security," significantly reducing the attack surface of your cloud environment.