<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Networking on imds.foo</title><link>https://imds.foo/tags/networking/</link><description>Recent content in Networking on imds.foo</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sat, 29 Aug 2026 15:11:01 +0200</lastBuildDate><atom:link href="https://imds.foo/tags/networking/index.xml" rel="self" type="application/rss+xml"/><item><title>Private Endpoints for Azure Storage: closing the public front door</title><link>https://imds.foo/posts/private-endpoints-storage/</link><pubDate>Wed, 12 Aug 2026 00:00:00 +0000</pubDate><guid>https://imds.foo/posts/private-endpoints-storage/</guid><description>&lt;h2 id="the-problem"&gt;the problem&lt;/h2&gt;&#10;&lt;p&gt;Every storage account you create ships with a public endpoint. Firewall rules and &amp;ldquo;selected networks&amp;rdquo; narrow who can reach it, but the endpoint itself stays on the internet, resolvable and probeable. For anything holding regulated data, the cleaner answer is to remove the public path entirely and reach the account over a private endpoint inside your VNet.&lt;/p&gt;&#10;&lt;p&gt;The switch sounds trivial. It isn&amp;rsquo;t, because the moment you flip &lt;code&gt;publicNetworkAccess&lt;/code&gt; to &lt;code&gt;Disabled&lt;/code&gt;, every client that still resolves the public IP breaks — including your own pipelines.&lt;/p&gt;</description></item></channel></rss>