Azure Private Endpoint on Brewed in the Cloud by Chris Hailes

Private Endpoint Doesn’t Save You from DNS

Thu, 11 Jun 2026 00:00:00 +1000

When teams talk about securing Azure PaaS with Private Endpoint, the conversation usually settles on the network path.

The service now has a private IP. Traffic stays off the internet. Exposure is reduced. Everyone breathes a bit easier.

That is not wrong. It is just incomplete.

A Private Endpoint changes how traffic reaches a service, but it does not, by itself, guarantee that the client is reaching the right service. In most real deployments, that decision still rides on DNS. The path may be private, but the destination is still selected by name resolution.

That changes something you design, deploy, and operate straight away: a Private Endpoint gives you a private transport path, not destination integrity.

The Mental Model

The common assumption is simple:

“We replaced the public endpoint with a private one, so the connectivity risk is mostly solved.”

That assumption holds only if you treat connectivity as a pure routing problem. Most workloads do not connect to abstract network paths. They connect to service names. If the wrong system answers the naming question, the network can still do exactly what it was configured to do while the application reaches the wrong destination, fails unexpectedly, or inherits trust from systems its owners never intended to rely on.

Treating Private Endpoint as the security boundary while treating DNS as background plumbing is a category error.

A private IP narrows exposure. It does not remove the need to trust the path that tells clients where that IP should be.

How It Really Works

Private Endpoint consumption feels clean because the application often keeps using a familiar service name. DNS simply returns a private address instead of a public one, and the application connects as normal.

That convenience hides an important dependency chain:

The client must query the intended resolver.
That resolver must use the intended zones and records.
The returned answer must identify the intended Private Endpoint.
No intermediate control should override that answer unexpectedly.
The service-layer connection must still validate against the expected service identity.

The critical point is that Private Endpoint secures reachability to a private destination. DNS still participates in deciding which destination that is.

That distinction matters because different DNS failures lead to different outcomes:

some failures break access entirely
some send clients to an unexpected private target
some change which administrative domain effectively controls service targeting
some create confusing partial outages that look like network or platform faults

Not all of those outcomes are compromise. That is exactly why this gets missed. Engineers often reserve the word “security” for direct unauthorised access, when in practice loss of destination control is already a security-relevant condition.

A Simple Trust Map

flowchart LR A[Application workload] --> B[Configured DNS resolver] B --> C[Private DNS authority or delegated resolution path] C --> D[Private Endpoint IP] D --> E[Azure service via Private Link] X[DNS admin influence] Y[Resolver path drift] Z[Incorrect or stale record] X -. changes authority .-> C Y -. changes dependency .-> B Z -. changes target selection .-> D

This is the part many designs flatten into “internal DNS”.

From a threat-model perspective, that is too coarse. The question is not just whether the answer is private. The question is who can influence the answer, and therefore influence where trusted traffic goes.

Where the Attack Surface Actually Appears

Private DNS becomes part of the trust boundary

Once a workload depends on private DNS records to reach a Private Endpoint-backed service, those records stop being neutral support objects. They become part of the application’s effective trust boundary.

That is the shift many teams miss.

A private DNS zone, a linked resolution path, or an override record may look operationally harmless because none of them move packets by themselves. But they can still influence service targeting. In a Private Endpoint architecture, that means they can influence which private destination a workload treats as authoritative.

That does not mean every DNS issue enables interception or data theft. Often it does not. But it absolutely can:

deny access to a required service
redirect clients towards an unintended private destination
shift effective control of service targeting into another administrative domain
create persistent failure modes that survive application redeployments and network reviews

That is enough to treat DNS as attack surface rather than plumbing.

Shared DNS paths broaden trust beyond the VNet

This is where the comforting subnet diagram starts to mislead.

A workload may sit in an isolated landing zone, use a locked-down subnet, and connect only to Private Endpoints. On paper, that looks tightly contained. But if name resolution depends on shared DNS services, central platform teams, hybrid resolvers, or external administrative paths, then the workload’s connectivity trust extends beyond its own network boundary.

In other words, the VNet does not fully describe who influences where that workload goes.

That matters in larger Azure estates because teams often assume Private Endpoint localises risk to the consuming network. In practice, DNS can reintroduce shared dependencies in ways the network design no longer makes obvious.

DNS risk is persistent, not a day-0 problem

Private Endpoint risk is often discussed as a provisioning concern: the endpoint is created, the record exists, the application connects, done.

That is the wrong lifecycle.

DNS is mutable by design. Records change. Zones move. Links are added. Resolver paths are centralised, migrated, inherited, or quietly overridden. Organisationally, ownership drifts even when infrastructure diagrams do not.

That means the DNS risk attached to a Private Endpoint is not limited to initial deployment quality. It persists as long as the workload depends on that resolution path. An attacker, careless change, or platform-side drift does not need to touch the application subnet or the Private Endpoint NIC to change runtime behaviour.

Real-World Impact

Design review needs a different question

During design review, the question is no longer just:

“Does this workload use a Private Endpoint?”

It also needs to be:

“Who can change where this workload believes that service lives?”

That is a materially different architecture question.

It forces you to examine DNS ownership, zone authority, resolver dependencies, and shared platform controls as part of application connectivity trust. If those controls sit outside the workload’s intended trust boundary, then part of the workload’s security posture sits outside that boundary too.

Shared services can quietly centralise influence

Centralised DNS often looks like operational maturity. Sometimes it is. But it also centralises the ability to change service targeting for many workloads at once.

That does not automatically make centralisation wrong. It does mean the blast radius is architectural, not just administrative.

If a central DNS path influences resolution for Private Endpoint-backed services across multiple landing zones, then one change path may affect systems that otherwise look isolated in network diagrams. For technical decision makers, that should change how DNS authority is classified. For operators, it should change which dependencies get examined first when failures appear inconsistent.

Incident response assumptions need tightening

In incident triage, “it resolved to a private IP” should not be treated as proof that the workload reached the intended service.

That assumption is too weak for Private Endpoint architectures.

A private answer may still be stale, unintended, inherited from the wrong resolution path, or aligned to the wrong environment. If teams use “private IP observed” as a proxy for “trustworthy destination confirmed”, they will misdiagnose issues and overlook one of the most important control dependencies in the path.

This is where the article’s thesis stops being theoretical. It changes how you investigate outages, dependency failures, and unexplained behaviour in supposedly isolated environments.

A Behavioural Example

Consider an application that retrieves secrets from Azure Key Vault through a Private Endpoint.

The application team has done the expected things. Public network access is restricted. The consuming subnet can reach the Private Endpoint. Egress is tightly controlled. On a network diagram, the design looks sound.

But the vault name resolves through a shared DNS path outside the application team’s direct control.

A later change in that path does not need to alter routes, firewall rules, or the Private Endpoint itself to affect the application. It only needs to alter where the application believes the vault lives. The likely outcome is not dramatic movie-style interception. More often it is failed access, wrong-environment targeting, or a dependency outage that presents like an Azure networking issue even though the transport path is doing exactly what it was told.

That is the operational trap: the application team can lose effective control of service targeting without any visible network change in its own subscription.

Gotchas & Edge Cases

“Private” is not the same as “correct”

A private IP answer only tells you something about address scope. It does not prove the answer came from the intended authority or points to the intended service instance.

DNS influence is easy to hide inside legitimate administration

A malicious route change often looks suspicious. A DNS record change may look like normal infrastructure maintenance, especially in shared services environments.

Network isolation can disguise naming dependency

The more locked down the packet path becomes, the easier it is for teams to assume the remaining dependencies are benign. In Private Endpoint architectures, that assumption gets dangerous quickly.

Service-layer controls still matter

DNS influence does not automatically equal successful compromise. Authentication, authorisation, and certificate validation still shape the final outcome. But they do not make DNS irrelevant; they define how far a bad DNS outcome can propagate.

Best Practices

Treat DNS authority as part of connectivity security

If DNS determines which private destination a workload reaches, then DNS authority is not ancillary. It is part of the workload’s effective connectivity security model.

Review change authority, not just network reachability

Packet path reviews are not enough. You also need to understand who can change resolver behaviour, zone data, or other name-resolution dependencies that alter target selection.

Classify shared DNS services by blast radius

A shared resolver or private DNS authority serving multiple Private Endpoint consumers is a multi-system trust dependency. Treat it accordingly.

Separate private transport from trusted destination in your thinking

A packet can stay on a private path and still fail to reach the intended service. Those are different properties, and mature designs treat them separately.

🍺

Brewed Insight: Private Endpoint reduces exposure, but DNS still decides where trust lands. If you model Private Endpoint as the boundary and DNS as plumbing, you are securing the road while outsourcing the destination.

Learn More

Private Endpoint Control Planes: Private Reachability Isn’t Trusted Reachability

Tue, 09 Jun 2026 00:00:00 +1000

You can take a sensitive service off the public internet, pin it behind a Private Endpoint, and come away feeling like the trust problem is mostly solved.

That feeling is exactly where the trouble starts.

Private Endpoints can reduce exposure. They can narrow the network paths that reach a service. But they do not prove that the environments consuming that service privately are legitimate, or that the administrative chain which created that private path deserves trust.

The real design error is not exposing a service privately. It is assuming that any environment able to consume it privately has therefore earned trust.

That is a control-plane problem, not a networking success story.

The Mental Model

The common assumption is simple:

If a service is only reachable through a Private Endpoint, then access is effectively trusted because it is no longer public.

That assumption compresses two different questions into one:

how traffic reaches the service;
whether the thing reaching it should be trusted.

Private Endpoints only answer the first one.

They change the path. They do not validate the consumer, the administrators who created the path, or the approval decisions that allowed it to exist. The private IP is not the trust boundary. It is the output of a series of management decisions.

So the useful shift in mental model is this:

private connectivity is a routing property
trusted connectivity is an authority decision
Private Endpoints affect the first one, not the second

The moment a team treats private reachability as evidence that a consumer environment has been legitimately trusted, they stop inspecting the layer where trust was actually granted.

How It Really Works

Private Endpoint is usually discussed as if it were a networking feature with some management overhead attached.

That framing is backwards.

It is a control-plane object that creates a private data-plane path.

That path exists only because a chain of administrative decisions makes it exist:

a Private Endpoint resource is created;
it is placed in a subnet within a virtual network;
it references a specific Private Link-capable subresource;
a connection request is raised and allowed through the target service’s approval model;
DNS then enables clients to use that private path.

By the time packets flow, the trust decisions have already happened.

Approval is a trust decision

Approval is often treated as a minor workflow event. It is not. It is the point at which a service owner, delegated operator, or service-specific approval path allows a particular consumer environment to establish private reachability.

That is a trust decision.

It is also one of the reasons Private Endpoint can be over-trusted architecturally. The assurance conveyed by a successful private connection is not perfectly uniform across Azure services or ownership models. Teams generalise from one service pattern to another, see a working private path, and assume it carries the same trust meaning everywhere. It does not.

If your architecture treats “connected privately” as if it implied a consistent trust posture across services, you are relying on a certainty the platform does not actually provide.

A Private Endpoint is a separate Azure resource. It can live in a different resource group, subscription, or operating domain from the service it connects to.

That is not just an implementation detail. It means the protected service and the private path to it can have different lifecycle owners, different administrative scopes, and different review habits.

This is the point many reviews miss: hardening the service does not tell you enough if someone else can still instantiate and retain private reachability to it.

Administrative separation is not trusted separation

Subscriptions and resource groups are useful operational boundaries. They are not evidence of trustworthy separation by themselves.

If the same administrators, inherited permissions, or approval practices can still bridge those scopes through management actions, then the boundary is structural, not trustworthy.

This is the design mistake that shows up repeatedly in Azure estates: teams see separate subscriptions and infer separate trust. In reality, they have reviewed layout, not authority.

Trust Flow, Not Just Packet Flow

The control-plane risk is easier to see when the trust relationships are explicit.

flowchart LR A[Identity with Private Endpoint management access] --> B[Create or modify Private Endpoint] B --> C[Consumer VNet and subnet placement] B --> D[Connection request to target resource] D --> E[Service-specific approval path] E --> F[Private connectivity established] F --> G[Private DNS mapping] G --> H[Client workload uses private path] I[Platform admin] --> C J[DNS admin] --> G

The interesting part is not where the packets flow. It is where trust gets asserted:

the identity allowed to create the endpoint;
the team controlling the subnet where it lands;
the approval path for the target resource;
the DNS authority that makes the path usable.

If those actors sit in different places, with different review standards, then “internal-only access” is really the product of several loosely connected trust decisions.

Real-World Impact

This changes how you should interpret private connectivity in production.

Private access does not prove the consumer was ever properly vouched for

A service may be reachable only over Private Endpoint and still be exposed to environments that were never meaningfully validated as legitimate consumers.

That is the central operational mistake: teams use private reachability as a proxy for consumer legitimacy.

The path is private. The trust judgement behind it may be weak, inherited, stale, or simply assumed.

Service owners can lose control of access without changing the service

If endpoint creation, subnet placement, approval, and DNS are controlled by different operating groups, then access can expand without the target service configuration changing in any obvious way.

That means a service can look hardened while the practical conditions of who can reach it are being altered elsewhere.

Drift preserves trust long after intent disappears

A stale Private Endpoint is not just a clean-up problem. It can preserve private access from an environment that has been retired, repurposed, handed to another team, or no longer deserves the implied trust of a live private path.

Most control-plane risk does not arrive dramatically. It lingers.

How would this change something I design, deploy, or operate?

It should change your review posture.

Do not stop at “is this service private?” Ask which identities, teams, and approval paths can create or preserve private reachability to it. If the answer depends on administrative sprawl, inherited control, or assumptions about what “internal” means, then the architecture is trusting more than it intends.

Abuse Scenarios That Matter

The risk is not endpoint creation in isolation. The risk appears when endpoint creation, placement into a reachable network, service approval, and usable name resolution combine into a private path that looks legitimate simply because it works.

A consumer environment gains a private path it was never meant to have

An operator creates a Private Endpoint into a subnet already reachable by workloads they control. The target service connection is then approved through a weak or overly routine process, and the necessary DNS conditions are in place for those workloads to resolve the service privately.

Nothing has become public. But a new trusted-looking path now exists from an environment nobody properly vouched for.

Approval becomes habit instead of judgement

A team responsible for approving Private Endpoint connections sees requests from “internal” subscriptions and treats them as normal by default. The endpoint is private, the naming looks familiar, and the approval goes through without a real question being asked about whether that consumer environment should have reachability at all.

That is not a tooling problem. It is trust being inferred from private placement.

Old environments retain private access by inertia

An application is migrated or retired, but the Private Endpoint remains, DNS still resolves, and the consumer network is still reachable. The original service owner assumes the old path was cleaned up. The platform team assumes the service owner still needs it.

No one is actively deciding to trust the path. The trust simply never got revoked.

Implementation Example

This is not a deployment guide, but the resource shape is useful because it exposes where the control-plane split actually lives.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


resource pe 'Microsoft.Network/privateEndpoints@2023-09-01' = {
 name: 'pe-app-sql-prod'
 location: resourceGroup().location
 properties: {
 subnet: {
 id: '/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-network-prod/providers/Microsoft.Network/virtualNetworks/vnet-hub-prod/subnets/snet-private-endpoints'
 }
 privateLinkServiceConnections: [
 {
 name: 'sqlConnection'
 properties: {
 privateLinkServiceId: '/subscriptions/11111111-1111-1111-1111-111111111111/resourceGroups/rg-data-prod/providers/Microsoft.Sql/servers/sql-prod-01'
 groupIds: [
 'sqlServer'
 ]
 requestMessage: 'Prod application connectivity'
 }
 }
 ]
 }
}

The useful part is not the syntax. It is what the object tells you:

the endpoint lives in its own management scope;
the subnet is controlled separately;
the target service may sit under different ownership;
the connection request is a trust event before it is a traffic path.

That is why “the service is private” is not enough. The service may be private while the authority to create private reachability sits in a different part of the estate entirely.

You can also inspect Private Endpoint connection state directly:

1
2
3


az network private-endpoint-connection list \
 --id "/subscriptions/11111111-1111-1111-1111-111111111111/resourceGroups/rg-data-prod/providers/Microsoft.Sql/servers/sql-prod-01" \
 --query "[].{name:name,status:properties.privateLinkServiceConnectionState.status,description:properties.privateLinkServiceConnectionState.description}"

The command matters less than the discipline behind it. If you are not looking at which consumers have private connectivity to a service, you are trusting historical approvals more than current intent.

Gotchas & Edge Cases

Working connectivity can disguise poor trust decisions

Once a name resolves privately and the application works, the path starts to feel legitimate by default. But functional connectivity is not proof that the consumer environment was ever supposed to be trusted.

Inconsistent service behaviour creates false assumptions

Private Endpoint approval and ownership patterns vary across Azure services. The risk is not just operational complexity. It is that teams assume a consistent trust model where none exists.

Persistence is often the bigger problem than deletion

Accidental deletion creates incidents, so it gets attention. Quietly persistent connectivity is often more dangerous because it preserves trust without forcing anyone to rejustify it.

Best Practices

This is not a role design or privileged workflow post, so I will stay out of RBAC mechanics. The practical design implications are still clear.

Treat Private Endpoint creation as a security-relevant action

Creating a Private Endpoint can extend private reachability to a sensitive service without changing the service configuration itself. That alone makes it worth treating as more than routine network plumbing.

Review private consumers, not just protected services

A service review is incomplete if it asks only how the service is protected and never asks who can privately attach to it.

Treat subscription boundaries as operational structure, not proof of trust

If the same management actors can still bridge those boundaries, then the separation may be useful administratively while meaningless from a trust perspective.

Make one question unavoidable in design review

For any sensitive service exposed through Private Endpoint, ask:

Which identities, teams, and approval paths can create, approve, or preserve private reachability to this service, and why should that imply trust in the consuming environment?

If that question is difficult to answer, the trust model is weaker than the network diagram suggests.

Design lifecycle ownership into the path itself

Private connectivity should have a clear owner, reason for existence, and review trigger. Otherwise, it becomes part of the environment’s inherited internal attack surface.

🍺

Brewed Insight: Private Endpoints are good at making traffic private. They are useless as proof that the private consumer has earned trust. Once private reachability gets mistaken for trusted reachability, the control plane becomes the part of the attack surface nobody is watching.

Learn More

Why “Private” Does Not Mean “Secure”

Thu, 04 Jun 2026 00:00:00 +1000

Private Endpoint has a branding problem.

The word private lands in architecture discussions like a shortcut for safe. Public access is removed, the service gets a private IP, and somewhere between design review and production rollout, reduced exposure gets mistaken for established trust.

That is the mistake.

A private endpoint is useful. Often very useful. But if your security posture improves mainly because you made something harder to reach from the internet, you have changed exposure, not proven safety. You have narrowed the path, not validated the caller, the dependency chain, or the operational control around it.

Private Endpoint reduces exposure; it does not create trust.

That is the lens for this post.

The Mental Model

The failure usually starts with a quiet assumption:

If a resource is reachable only over private connectivity, it is now a trusted internal service.

That assumption sounds reasonable because private addressing still carries a lot of inherited meaning. It feels contained. Managed. Ours.

In Azure, that is a dangerous shortcut.

Private Endpoint changes where traffic can come from. It does not answer whether the source is legitimate, whether the network path is well governed, whether DNS is correct, or whether the service is being reached by something already compromised.

The deeper problem is not technical misunderstanding. It is classification.

When teams treat Private Endpoint as a security control in its own right, they start making downstream design decisions as though network privateness is evidence of trust. That is where architecture drifts:

internal paths become loosely trusted
segmentation becomes harder to justify
DNS gets treated as plumbing instead of a security dependency
control-plane permissions become more powerful than the design admits
monitoring gets weaker because “private” has already been mentally filed under “safe”

That is why this is more than semantics. Misclassifying the control changes the system built around it.

How It Really Works

Private Endpoint gives an Azure service a private IP in your virtual network through Azure Private Link. That changes the reachability path to the service.

It does not make the service inherently trustworthy. It does not validate the caller. It does not harden the data path on its own. It does not replace authentication, authorisation, encryption, governance, or operational verification.

What it does do is narrow the set of places from which the service can be reached.

That matters. Exposure reduction is real. Internet-wide scanning, casual probing, and broad unsolicited connectivity become less relevant when access is forced through private network paths. That is a legitimate security improvement.

But it is still only one kind of improvement.

The mistake is turning this:

Fewer things can reach the service

into this:

Things that can reach the service are now trustworthy

Those are completely different claims.

A more accurate model is:

Private Endpoint is an exposure-reduction mechanism
It is not a trust mechanism
It is not a security boundary
It should not be treated as a compensating control for weak architecture elsewhere

That last point matters most. The architectural mistake is not deploying Private Endpoint. The mistake is using it to justify trust decisions it was never designed to support.

Private Endpoint as Part of the Attack Surface

If you are threat modelling properly, a Private Endpoint should be treated as part of the internal attack surface.

That means the question is not “is this service private now?”

It is closer to:

which networks can route to it?
which systems can resolve its name?
which workloads can reach it after compromise?
which teams or automation can create, approve, or modify the connection path?
which changes to DNS or endpoint lifecycle would silently alter trust assumptions?
which telemetry would tell us the endpoint is being used in a way we did not intend?

That is a very different posture from “public access disabled, job done”.

The dependency chain is the story

flowchart LR A[Workload or User] --> B[DNS Resolution] B --> C[Routing to Private IP] C --> D[Private Endpoint] D --> E[Private Link Mapping] E --> F[Azure Service] G[Peering / Hybrid Connectivity] --> C H[RBAC / Policy / Approval Workflow] --> D I[Private DNS Zone Links / Forwarders] --> B J[Monitoring / Logs / Alerts] --> D style D fill:#d9edf7,stroke:#31708f,stroke-width:2px style B fill:#fcf8e3,stroke:#8a6d3b,stroke-width:1px style H fill:#f2dede,stroke:#a94442,stroke-width:1px style I fill:#f2dede,stroke:#a94442,stroke-width:1px

Private Endpoint is only one component in a chain that includes name resolution, network pathing, control-plane permissions, and ongoing operational ownership.

An attacker does not need to defeat Private Link itself. They need one viable path through the surrounding system.

That is why calling Private Endpoint a security control is too generous. It encourages the wrong mental model about where assurance actually comes from.

Real-World Impact

This changes design and operations in some concrete ways.

1. A compromised internal workload can still use the private path

A storage account or Key Vault behind a Private Endpoint is still reachable by any compromised workload that can route and resolve to it.

If you mentally classified the endpoint as “secure because private”, you are more likely to have under-invested in segmentation, workload isolation, or internal traffic scrutiny. The attacker does not need public ingress. They just need to land somewhere that already sits inside the allowed path.

This is the most common failure of the “private equals safe” assumption: the service is no longer internet-facing, but it is still entirely usable from the wrong place for the wrong reason.

That should change how you design. A Private Endpoint should be treated as a sensitive internal destination, not a trustworthy one.

2. DNS becomes a security dependency, not just a networking detail

Private Endpoint increases your reliance on private DNS zones, forwarding rules, resolver paths, and link governance.

That is not background plumbing. It is part of the trust path.

If DNS ownership is fragmented, forwarding is inconsistent, or zone links are changed without proper control, the architecture can drift without most teams noticing. The service still looks private. The assumptions around how it is resolved and reached may no longer be true.

This should change how you operate. Name resolution for private services needs explicit ownership, change discipline, and verification. If your design depends on DNS but your operating model treats it as somebody else’s problem, you do not have a complete security design.

3. Control-plane permissions can silently reshape trust

The endpoint itself is a data-plane object, but the trust around it is heavily influenced by control-plane actions.

Who can:

create a private endpoint
approve a connection
link or unlink private DNS zones
alter policy exemptions
move workloads into reachable network segments
change routing or forwarding behaviour

Those permissions matter because they can alter who reaches what, and how, without changing the application code or the service itself.

If Private Endpoint is treated as a security control, teams often stop short of asking who can mutate the control surface around it. That creates false assurance. The path is private, but the governance over the path may still be loose.

This should change what you review in design governance. The security question is not just “does this use Private Endpoint?” but “who can change the path, resolution, and approval model around it?”

How would this change something I design, deploy, or operate?

It changes the classification.

I would not treat Private Endpoint as a control that establishes trust. I would treat it as an exposure-reduction mechanism that still sits inside a broader system of trust decisions.

That means:

designing internal reachability as something to constrain, not automatically trust
treating private DNS as part of the security architecture
reviewing control-plane permissions as part of endpoint risk
monitoring private-only service access as potentially high-signal, not low-risk
refusing to let “it’s private” close a design discussion that should still include governance and failure modes

If the design review ends at “public access disabled”, it has ended too early.

Implementation Example: Verify the Dependency Surface, Not Just the Endpoint

The useful operational question is rarely “does a Private Endpoint exist?”

It is more often “what trust and dependency surface now exists because it does?”

A simple example is enumerating endpoint state and DNS relationships so they can be reviewed as part of operational governance rather than assumed to be correct.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# List private endpoints in a subscription with key governance context
az network private-endpoint list \
 --query "[].{
 name:name,
 resourceGroup:resourceGroup,
 location:location,
 subnet:id,
 connections:privateLinkServiceConnections[].privateLinkServiceId,
 nics:networkInterfaces[].id,
 provisioningState:provisioningState
 }" \
 -o table

# List Private DNS zone links for review
az network private-dns link vnet list \
 --resource-group <dns-rg> \
 --zone-name <private-zone-name> \
 -o table

This is not presented as a deployment step. It is a reminder that the operational surface includes more than the endpoint object itself. If you cannot quickly identify which endpoints exist, which networks they live in, and how DNS is linked around them, you are relying on privateness more than you are governing it.

Gotchas & Edge Cases

Private-only can reduce visibility if teams are not deliberate

Some organisations monitor internet-facing services heavily and assume private paths are lower risk. That can create a blind spot where the more sensitive destination gets less scrutiny simply because it is no longer public.

“Internal” often spans more than one trust domain

Peering, hub-and-spoke topologies, hybrid connectivity, and shared platform services can all widen effective reachability. If your architecture talks about “the internal network” as though it were one trust zone, you are already abstracting away the problem.

Exposure reduction can still be the right call

None of this is an argument against Private Endpoint. Reducing public exposure is often sensible and worthwhile. The warning is about over-claiming what that decision buys you.

Best Practices

Treat Private Endpoint as exposure reduction, not trust establishment
Model private DNS as a security dependency with explicit ownership
Review which internal networks and workloads can actually reach private endpoints
Include control-plane permissions and approval paths in the threat model
Monitor access to private-only services as part of your internal attack surface
Challenge any design language that treats “private” as equivalent to “trusted”

🍺

Brewed Insight: Private Endpoint is valuable precisely because it reduces exposure. The trouble starts when that benefit gets inflated into a trust claim. Once “private” becomes shorthand for “safe”, the rest of the architecture starts inheriting confidence it never earned.

Azure Private Endpoint on Brewed in the Cloud by Chris Hailes

Private Endpoint Doesn’t Save You from DNS

The Mental Model

How It Really Works

A Simple Trust Map

Where the Attack Surface Actually Appears

Private DNS becomes part of the trust boundary

Shared DNS paths broaden trust beyond the VNet

DNS risk is persistent, not a day-0 problem

Real-World Impact

Design review needs a different question

Shared services can quietly centralise influence

Incident response assumptions need tightening

A Behavioural Example

Gotchas & Edge Cases

“Private” is not the same as “correct”

DNS influence is easy to hide inside legitimate administration

Network isolation can disguise naming dependency

Service-layer controls still matter

Best Practices

Treat DNS authority as part of connectivity security

Review change authority, not just network reachability

Classify shared DNS services by blast radius

Separate private transport from trusted destination in your thinking

Learn More

Private Endpoint Control Planes: Private Reachability Isn’t Trusted Reachability

The Mental Model

How It Really Works

Approval is a trust decision

The endpoint and the service do not share the same ownership story

Administrative separation is not trusted separation

Trust Flow, Not Just Packet Flow

Real-World Impact

Private access does not prove the consumer was ever properly vouched for

Service owners can lose control of access without changing the service

Drift preserves trust long after intent disappears

How would this change something I design, deploy, or operate?

Abuse Scenarios That Matter

A consumer environment gains a private path it was never meant to have

Approval becomes habit instead of judgement

Old environments retain private access by inertia

Implementation Example

Gotchas & Edge Cases

Working connectivity can disguise poor trust decisions

Inconsistent service behaviour creates false assumptions

Persistence is often the bigger problem than deletion

Best Practices

Treat Private Endpoint creation as a security-relevant action

Review private consumers, not just protected services

Treat subscription boundaries as operational structure, not proof of trust

Make one question unavoidable in design review

Design lifecycle ownership into the path itself

Learn More

Why “Private” Does Not Mean “Secure”

The Mental Model

How It Really Works

Private Endpoint as Part of the Attack Surface

The dependency chain is the story

Real-World Impact

1. A compromised internal workload can still use the private path

2. DNS becomes a security dependency, not just a networking detail

3. Control-plane permissions can silently reshape trust

How would this change something I design, deploy, or operate?

Implementation Example: Verify the Dependency Surface, Not Just the Endpoint

Gotchas & Edge Cases

Private-only can reduce visibility if teams are not deliberate

“Internal” often spans more than one trust domain

Exposure reduction can still be the right call

Best Practices

Learn More