最近インフラ周りの設定を復習しているので、完全に自分用のメモです。
Private Endpoint
Storage AccountやSQL Databaseなど通常Private IPを持たないAzureリソースに対して、Network Interfaceを付与し、VNetに接続させる。併せて外部からのアクセスを禁止し、インターネットから隠蔽する。
これにより、主な特徴として
- Private Endpointを有効にしたリソースはInternetからアクセスできなくなる
- 接続元、接続先はPrivate IP経由になる
昔はNSGを無視するという仕様があったが、いつの間にかGAになっていたようだ。でもデフォルトOFFなので気を付ける必要はありそう。
Private Endpointの名前解決
Private Endpointのよいところは、接続先のURLはそのままPublic（図のazsql1.database.windows.net）のものが使える。なので最初はPublic IPでつないでたが後からPrivate Endpoint経由に変更した場合でもURLに変更は入らない。
通常はこのURLはPublic IPを参照しているのだが、Private Endpointを作成するとそれが自動的にPrivate IPを参照するようになる。そのためのPrivate Endpointを利用する場合は一緒にPrivate DNSがデプロイするのが通常の流れ。
168.63.129.16はAzureが提供しているAzure上のリソースの名前解決のDNSとのこと。
Hybrid環境やVNet Peeringしている環境でも利用が可能
設定
SQL Server > SQL Databaseを作成。
SQL Database > NetworkingでPrivate Endpointを作成。
"Integrate with private DNS zone?"に対してYesにしてPrivate DNS Zoneを合わせてデプロイする。
Sql ServerにPrivate EndpointができてApproveされている。ここはPrivate Endpointを作成したユーザーがRBAC的にApproveする権限（Owner, Contributor, Network Administrator）があれば自動的にApproveされる。
Private Endpointの設定をみるとFQDNが振られている。Private Endpointがあり、Private DNS Zoneにより解決されていることがわかる。
Private Endpointが関連付けられているNICを見る。
Private DNS Zoneも。
VnetにいるVMがあればnslookupで解決できる。
nslookup sqlsv-sima001.database.windows.net
Private EndpointをSubscription・Regionまたぎで利用する
Private EndpointはRegion、Azure AD TenantやSubscriptionをまたいでも通信可能。
ADTenant、Subscriptionまたぎの場合は、Private Endpointを利用する側のSubscriptionでPrivate Link Centerから個別に作成する。
通常自分のディレクトリのリソースであればドロップダウンから簡単に選択できるのだが。
このResourceの画面で"Connect to an Azure resource by resource ID or alias"というのを選択したうえで、提供元から教えてもらった接続情報を入力することになる。
リソースIDやAliasで指定する。リソースIDは通常リソースのOverviewのJSON Viewから見ることができる。ただし、リソースIDはSubscriptionが入っているので、外部に提供する場合はできるだけAliasを利用することを推奨される。
また、この場合だとPrivate DNS Zoneを一緒に作成することができないので、そこはPrivate Endpointを利用する側で独自にPrivate DNS Zoneを作成する必要がある。Private EndpointのIPに対してAレコードを追加することになる。
クロステナント、サブスクリプションは自分では確かめられなかったけど、こちらにすごくわかりやすい記事があったので、参考で掲載する。
Private Endpointを2つ持ちVNETを跨ぐリソースを作成する
詳しくは以下リンクを参考にしてほしいが、Private Endpointは実は1リソースに2つ作成し、VNETをまたぐことができる。
利用ケースとしては以下のリンクの補足のように左が利用側、右が提供側と別れている場合だろう（図お借りします）。
図のようなケースでは利用者端末からStorage Accountを①Private Endpoint経由でStorage Account Explorerのようなツールを介して直接触りたい、かつ②アプリ経由でも利用したいというような特殊な要件の場合が想定される。
ただし、注意点としてResource Groupが2つ、Private DNS Zoneも2つ、Aレコードもそれぞれで設定という形になってしまう。
直接的な原因としては、1つのResource Groupに同じ名前のPrivate DNS Zoneを2つ立てられず、また1つのPrivate DNS Zoneも同じ名前でAレコードを2つ設定できないからだ。
なので以下の構成になる。
- ResourceGroupA
- VNetA
- hoge.privatelink.blob.core.windows.net(VNetAとリンク)
- Aレコード：hoge 10.0.0.1(VNetAのIPレンジ)
- ResourceGroupB
- VNetB
- hoge.privatelink.blob.core.windows.net(VNetBとリンク)
- Aレコード：hoge 10.0.1.1(VNetBのIPレンジ)
Resource Group単位で分けなくてはいけないというのがイけていない気がするがそういうものらしい。というのも上記の図では元々Resource Groupを用途単位できれいに分けていたから大きな問題ではない。ただ、1 Resource Groupで2つVNetを作成してしまった場合等だとPrivate DNS Zoneだけ入っているResource Groupを作らざるを得なくなり、その場合ナニコレ？となる可能性が高い。
こういう場合の解決策は3つか。
- おとなしくResource Groupを分ける
- Subscriptionレベルで提供と利用を分ける
Resource Groupレベルで分ける必要があるならいっそのことSubscriptionから分けてしまえばいいという発想。そうすれば1 Subscription 1 につき1 Resource Groupで収まる。ただし管理工数が増えるし影響も大きい。
- Private Link Serviceを使う
これは利用ケースによって使えない場合もあるが、利用側と提供側という考えであればPrivate Link Serviceがその用途に適しているケースもあるかもしれない。（本記事の後半参照。）
Private Link
違いに関してはいろんな記事があるがイマイチよくわからない。
Azure Private Link を使用すると、お使いの仮想ネットワーク内のプライベート エンドポイント経由で Azure PaaS サービス (Azure Storage、SQL Database など) と Azure でホストされている顧客所有の、またはパートナー サービスにアクセスできます。
、、、それってPrivate Endpointのことじゃないですか？
なのでPrivate LinkとPrivate Endpointの違いについてPerplexityに質問してみた。
Azure Private LinkとAzure Private Endpointは、Azureのネットワークサービスにおける異なるコンポーネントですが、密接に関連しています。
Azure Private Link
Azure Private Linkは、Azureの仮想ネットワーク（VNet）からAzure PaaSサービスや独自のサービスに対してプライベート接続を提供するサービスです。これにより、インターネットを経由せずに、Azureのバックボーンネットワークを通じて安全に通信が行われます。Azure Private Linkは、複数のVNet内のプライベートエンドポイントを接続することが可能で、異なるAzureサブスクリプション間でも接続ができます。
Azure Private Endpoint
Azure Private Endpointは、Azure Private Linkを利用するためのネットワークインターフェイスで、仮想ネットワーク内のプライベートIPアドレスを使用します。これにより、Azureのサービスに対して非公開で安全に接続することができます。プライベートエンドポイントは、特定のAzureサービスや独自のサービスに対してのみアクセスを許可するため、セキュリティが向上します。
主な違い
- 目的と機能: Azure Private Linkは、プライベート接続を提供するサービス全体の仕組みであり、Azure Private Endpointはその仕組みを実現するための具体的なネットワークインターフェイスです。
- 接続の範囲: Private Linkは、複数のVNetやサブスクリプション間での接続を可能にするのに対し、Private Endpointは特定のリソースへのアクセスを制限します。
- 利用シナリオ: Private Endpointは、オンプレミスやリモートのVNetからのアクセスにも利用でき、より細かいアクセス制御が可能です。
Private Endpointは個々のリソース（Storage Account等）に対してNICを割り振りVNetに結び付けること。Private Endpointは具体的なResource。
それに対して、Private Linkとは、すごくざっくりいうとPrivate Endpoint、Private Link Serviceが利用している技術、裏のサービスを指す、らしい。かつ、色々ぐぐっていたところ、Private Linkと下のPrivate Link Serviceを同一のものと扱っているような記事も見かけた。
（この辺調べてもマジでよくわかってないので、バシッとわかるような説明ご存じでしたら誰か教えてください。。。）
Private Link Service
さて次はあまり聞かないPrivate Link Service。すごくまとまっている記事があったので、感謝しつつリンクを貼る。
Private Link Serviceというのがあり、それは以下のようにPrivate Linkを使うための仕組み？を意味する。Private LinkをPrivate Endpointと紐づけるのはMappingと呼ぶ。
Azure Private Link サービスは、Azure Private Link を使用する独自のサービスに対する参照です。 Azure Standard Load Balancer の背後で実行されている自分のサービスで Private Link アクセスを有効にすると、自分のサービスのコンシューマーがそのサービスに対して独自の VNet からプライベートにアクセスできるようになります。
以下の図によると、ユースケースとして、以下のような状況が想定される。
- Vnetが分割されていて、左のVNetから右のVNetのリソースを利用したい
- ただし、VNetピアリングする程の仲ではなく、純粋にサービスを利用/提供だけの仲
- なので、左のVNetをConsumer、右のVNetをProviderと呼ぶ
ちなみにVNetのIPレンジが重複していても接続OK。
Consumer NetworkからProvider NetworkにアクセスするのにPrivate LinkとStandard Load Balancerが利用されている。VNet、リージョン、テナント、サブスクリプション跨ぎなど色々なケースで使える。
ConsumerとProviderの両方で提供と呼び出しの設定が必要になるを行う。
- Provider側はPrivate Link ServiceとLoad Balancer経由で自分のエンドポイントをVNetの外に対して提供する
- Consumer側は自分のVNet内にPrivate Endpointを作成し、Private Linkにマッピングする
ちなみに、Internal Load BalancerのほかにApplication GatewayでPrivate Link Serviceするパターンも可能。なので、Application Gatewayの裏にVMでなくWeb Appsを配置することも可能。
実際の設定はこちら参照。感謝。
設定
- 消費側：
- VNet：vnet-consumer（アドレス範囲：10.0.0.0/24）
- Subnet：consumer subnet：10.0.1.0/27
- Private Endpoint：pep-consumer
- 提供側：
- VNet：vnet-provider（アドレス範囲：10.0.1.0/24）
- Subnet：web subnet：10.0.1.0/27
- Load Balancer：load-balancer
- VM：vm1
- Private Link Service：private-link-service
提供側であるprovider側にLoad Balancer作成
provider側にPrivate Link Serviceを作成
Private Link ServiceをLoad Balancerに紐づける
Private Link Serviceの可視性の設定。Private Link ServiceはSubscriptionまたぎなどもできるため、どのように見せるかを設定できる。Restrict by subscriptionを選択すると、呼び出し可能なSubscriptionを入力できる。
- ①RBACでPrivate Linkに権限がある人が利用できる
- ②サブスクリプションを指定し、そのサブスクリプションに権限がある人が利用できる
- ③Private Link Serviceの名前さえ知っていれば利用できる（→これが一番緩い）
Private Link Serviceができているのが見える。
Consumer側でPrivate Link ServiceにPrivate Endpointをマッピング
さっきの可視性で①を選んだ場合、同じテナント内であればPrivate Link Serviceを選択できる。
②か③を選んだ場合、ResourceIDかAliasで指定する。
ちなみにAliasPrivate Link ServiceであればAliasはOverviewから見れる。
ホスト名で名前解決できるようにConsumer側にPrivate DNS Zoneを作成する
これでconsumer側からFQDNでアクセスできるようになる。
Private Link Serviceの実例 - Azure Front Door
実際にPrivate Link Serviceが使われている実例として、Azure Front Doorがある。Front DoorからバックエンドのWeb AppsへPrivate Endpoint経由でつなげたい場合など。
具体的な設定手順などは別記事で昔書いたので以下を参照してほしいのだが、Front DoorがPremium SKUの場合、バックエンドのOriginであるWeb Appsを選択する際にPrivate Link Serviceを有効にすることができる。
これを使うと、Web Apps側で事前にPrivate Endpointを作成せずとも、自動的にWeb Apps側にPrivate Endpointを作成して管理してくれるようになる。Private EndpointもPrivate DNS Zoneなどもリソースとしては表示されず、自動的に管理されるようになる。
正直だからなんだという感じではある。Private Link Serviceとか言ってユーザーを混乱させているが、自動的にPrivate Endpointを作成しているだけではないか、と思うのだがこれいかに。
ちなみに、Application Gatewayなどの場合だと、Private Link Serviceはない。Web Apps側でPrivate Endpointをあらかじめ自分で作成して、Application Gatewayから参照する際にWeb Appsを選択すれば自動的にPrivate Endpointが利用される感じになる。、、、あれ、こっちのほうがわかりやすくないですかね？
VNet Integration
ちなみに、本記事の対象外ではあるけど、今までのPrivate EndpointがInbound Trafficの制限の技術だとすれば、Outbound Trafficの技術は別にある。
App Serviceを例に以下2点を記載する。
- ①Vnet Integration
- ②Gateway Required VNet Integration
(Regional) VNet Integration
VNet Integrationは原則として通信元のApp Serviceからの送信がVNetを経由するようになる。
もし送信元、送信先が同じRegionであれば単純なVNet Integrationで済む。VNetに専用のDelegated Subnetを作成し、そこに対してApp Serviceを統合させる。
ちなみにこのSubnetの最小IP数には注意が必要。Web Apps側でスケールする数による。1つWorkerが増えればIPも1つ消費される。またスケールアップした場合は古いものを残して、新しいものを立ち上げ、そして古いものを削除するので、想定Worker数の2倍が基準になる。
Gateway Required VNet Integration
もし送信元と送信先が異なるRegionであるならばGatewayと送信先では専用のGateway Subnetが必要になる。これは仕組み的にはP2S VPNになってしまうので手間もコストも大掛かり感が出てくる。
