168.63.129.16 は Microsoft が保有するパブリック IP アドレスであり、Azure データーセンター上でのみ利用している仮想 IP アドレスです。
この 168.63.129.16 は Azure データーセンターのホスト サーバー (物理サーバー) 上で動作する IP アドレスとして割り当てられていて、パブリック インターネット上には公開されていないため Azure データーセンター上のリソース以外からは接続ができません。
仮想マシンなど Azure データーセンター上のリソースが正常に稼働するためのエンドポイントでもあるため、NSG やルート テーブル (UDR) で 168.63.129.16 を制御することは出来ず、仮想マシン上の OS 上でも制御しないことを強く推奨しています。
注意
NSG では 168.63.129.16 に対する制御はできないと記載しましたが、AzurePlatformDNS や AzureLoadBalancer のサービスタグを利用することで、168.63.129.16 に関する通信の一部を NSG で制御可能です。
ただし、意図しない動作を回避するためにも原則制御しないことを強く推奨します。
168.63.129.16 は Azure 上の名前解決 のための再帰的リゾルバー (フルサービス リゾルバー) の機能を提供しています。下記の用途で利用いただけます。
・インターネット上のドメインに対する名前解決
・プライベート DNS ゾーン の名前解決
・同一仮想ネットワーク上のホスト名での名前解決
この 168.63.129.16 の DNS 機能は、Azure ポータルであれば仮想ネットワークの DNS 設定における既定値である “既定 (Azure 提供)” で利用でき、明示的に 168.63.129.16 を指定する必要はありません。
また、冗長構成を意識いただくことなく、Azure 基盤内で既定で冗長化されています。
仮想ネットワークの DNS の観点で、168.63.129.16 を参照することは必須要件ではなく、仮想ネットワークや仮想マシンの仮想 NIC の DNS サーバーの設定として、任意の DNS サーバーを指定可能です。
Azure では任意の DNS サーバーを指定する構成をカスタム DNS サーバーと呼んでおり、仮想ネットワーク上のカスタム DNS サーバーでよくあるお問い合わせについては こちら をご確認ください。
注意
168.63.129.16 が提供するホスト名での名前解決は、同一の仮想ネットワークに限定されています。
例えば 2 つの仮想ネットワークでピアリング接続をしている構成では、ピアリング先のリソースをホスト名で名前解決することは出来ません。
168.63.129.16 の DNS サーバーは、Azure データーセンター上のリソースからのみ DNS クエリを受け付け可能な為、ExpressRoute や VPN で接続されたオンプレミスから 168.63.129.16 を DNS サーバーとして参照できません。
プライベート DNS ゾーンをオンプレミスから参照させたい場合や、ハブ&スポーク構成の仮想ネットワークにおいてハブの仮想ネットワークのプライベート DNS ゾーンを参照させたい場合など、Azure 上に DNS プロキシに該当する機能が必要です。
この DNS プロキシは、Azure であれば現在下記の構成案があります。
・Azure DNS Private Resolver を利用する
・Azure Firewall の DNS プロキシ機能を有効化する
・仮想マシン上に DNS サーバーを構成する
それぞれの特徴としては下記があります。
Azure DNS Private Resolver は、仮想ネットワークのサブネット上に、DNS クエリを受け付ける受信エンドポイントを構成します。
受信エンドポイントの IP アドレスは仮想ネットワーク上の IP アドレスとなり、IP レイヤーで疎通性があればオンプレミスからも DNS クエリを受け付けることができます。既定で高可用性/ゾーン冗長構成のマネージド サービスであるため、運用コストが削減できます。
168.63.129.16 の DNS サーバーは条件付き転送などカスタマイズ機能がありませんでしたが、Azure DNS Private Resolver であれば送信エンドポイントと転送ルールを構成することで条件付き転送も利用できます。
Azure Firewall は仮想ネットワーク上でデプロイ可能なファイアウォール アプライアンスですが、DNS クエリを受け付ける DNS プロキシ の機能があります。
Azure Firewall が参照する DNS サーバーは仮想ネットワークのカスタム DNS サーバーとは連動しておらず、既定で 168.63.129.16 を参照します。Azure Firewall の DNS サーバーの設定で任意の DNS サーバーを参照するように構成変更可能です。
既に Azure Firewall をご利用いただいており、条件付き転送が不要であれば DNS プロキシとしてご利用いただけますが、DNS プロキシの機能のみをご利用いただく場合は Azure DNS Private Resolver よりも高額です。
Azure 上の DNS プロキシとしては、仮想マシン上に DNS サーバー (Windows サーバーや BIND など) を構成いただき、フォワーダー先として 168.63.129.16 を指定いただく構成も考えられます。
仮想マシン上の構成となるため、DNS サーバーの構成及び運用はお客様のご対応範囲となり、Azure サポートではご支援できかねる点はご留意ください。
DNS プロキシをオンプレミスから参照する構成イメージとしては、プライベート エンドポイントのドキュメント に Azure DNS Private Resolver をベースとした構成例があります。
必要に応じて Azure Firewall や仮想マシン上の DNS サーバーと置き換えてください。
注意
オンプレミスの DNS サーバーから Azure 上の DNS プロキシを参照する構成で、プライベート エンドポイントに関連するドメインを条件付きフォワーダーで指定する時、指定するドメイン ゾーンは対象 Azure PaaS の パブリック DNS ゾーンを指定することを推奨しています。
プライベート エンドポイントで利用される privatelink サブドメインの DNS ゾーンだけ条件付きフォワーダーで転送した場合、オンプレミスの DNS サーバーの動作によっては意図した名前解決とならない場合があります。
168.63.129.16 の DNS 機能に関して、Azure サポートによくお問い合わせいただく内容についてご案内します。仮想ネットワーク上のカスタム DNS サーバーでよくあるお問い合わせについては こちら をご確認ください。
1 台の仮想マシンから 1 秒あたりに送信可能な DNS クエリの数 (QPS) は 1000 という Azure 上の制限内 であれば、168.63.129.16 は DNS サーバーとして DNS クエリを処理可能です。
言い換えますと、仮想マシン上の DNS サーバー、または Azure Firewall を経由して 168.63.129.16 に対する 1000 QPS 以上の DNS クエリは失敗する可能性があります。
なお、Azure DNS Private Resolver はエンドポイント毎に 10,000 QPS が上限です。
考えられる要因として、仮想ネットワークの DNS サーバーの設定が変更されてカスタム DNS サーバーを参照する構成になったことが考えられます。
仮想マシンが 168.63.129.16 を参照している構成では、ホスト名で名前解決をした際、Azure 基盤が内部 DNS サフィックス (.internal.cloudapp.net) を自動で付与します。
この動作により仮想マシン上でホスト名だけで名前解決ができます。
仮想マシンが 168.63.129.16 を参照しない構成 (カスタム DNS サーバー構成) に変更された場合、Azure 基盤の内部 DNS サフィックス (.internal.cloudapp.net) の自動付与の機能が停止されるため、仮想マシンはホスト名で名前解決ができなくなります。
考えられる要因として、同一のコンピューター名を持つ仮想マシンを 1 つの仮想ネットワーク上に複数展開したことが挙げられます。
仮想マシンが展開されたとき、Azure 基盤では内部 DNS サフィックス (.internal.cloudapp.net) に仮想マシンのコンピューター名をホスト名とした DNS レコード情報を追加します。
仮想マシンのバックアップなどでバックアップ先を同一の仮想ネットワークにした場合、Azure 基盤は仮想マシンの展開時に DNS レコード情報を更新します。
この動作により、ホスト名に対する名前解決の結果が、後からデプロイされた仮想マシンの IP アドレスと紐づけられることで、ホスト名に対する名前解決の結果が変更されます。
もし、仮想マシン間の名前解決をホスト名のみで実施されており、仮想マシンのバックアップなどを実施される場合は、別の仮想ネットワーク上にデプロイいただくなどのご対応を実施願います。
仮想マシンが 168.63.129.16 を DNS サーバーとして参照しないカスタム DNS サーバー構成では、Azure 基盤は既定の内部 DNS サフィックス (.internal.cloudapp.net) ではなく、機能を持たないプレース ホルダー (reddog.microsoft.com) が付与されます。
この reddog.microsoft.com プレフィックスを削除または上書きされても仮想マシンの動作上は影響ありません。
現状 168.63.129.16 の DNS ログを Azure ユーザーが確認する方法はございません。
Azure サポート担当にご依頼いただければ該当ログの調査支援が可能ですが、ログの調査をするには対象の FQDN と調査対象の時刻を可能な限り具体的にご提示願います。
なお、Azure 既定の DNS のログは、30 日程度でローテーションされ、過去のログは参照できない点はご留意ください。
現状 168.63.129.16 において DNSSEC はサポートされていません。
今後の機能追加として検討されているため、今後の機能追加にご期待いただければと存じます。
以上、ご参考になれば幸いです。
]]>Azure ゲートウェイサービスでは以前からお客様よりメンテナンスのコントロールについてご要望をいただいておりました。
2023 年 11 月よりプレビュー中の機能とはなりますが、メンテナンスコントロールのための機能が実装されましたのでご紹介させていただきます。
VGW ではサービスを健全に保つため、月に数回のメンテナンスを実施しており、定期メンテナンスは大きく以下の 3 種類に分類されます。
ゲートウェイ機能を提供しているソフトウェアのアップグレードの他、一般的な VM と同様の IaaS サービス基盤上で動作しているため、
ホストで稼働するソフトウェアアップグレードやホスト、上位ネットワーク装置などハードウェアの更新などの作業を行います。
一般的にこれらは Azure サービス基盤上で自動化された作業で、冗長性を考慮し、数千、数万のリソースに対し、順次、更新を適用いたします。
定期メンテナンスでは極力お客様サービスに影響が発生しないように、ExressRoute ゲートウェイではトラフィックを迂回した上で実施するなどの対処を行っております。しかしながら現状、実行時に多少の通信遅延の増加、パケットロスが検出されることがあります。また VPNGW では VPN 接続で再接続が必要になることがあります。
本機能を設定することで、 VGW リソース毎に定期メンテナンスを実行するためのメンテナンスウィンドウを指定することができます。トラフィックの少ない時間帯、営業時間外にメンテナンスウィンドウを設定いただくことにより、サービス影響を極力避けた運用が可能となります。この機能を用いても、上記の 3 種類のメンテナンスの中の “1. ゲートウェイ機能を提供するソフトウェア メンテナンス” のみの制御となりますので、全メンテナンスを制御できるわけではございませんのでご注意ください。
( VGW は共有リソース上で稼働しているため、ホスト基盤、ハードウェアメンテナンスについては本機能の制御対象外となります )
対象可能な VGW の種類は下記となります。
現時点では Virtual WAN Point-to-Site GW, VirtualWAN 仮想ハブルータついては未対応です
設定方法詳細については以下ドキュメントご参照ください。
*ご参考: VPN Gateway にお客様が管理するゲートウェイ メンテナンスを構成する (プレビュー)
*ご参考: ExpressRoute にお客様が管理するゲートウェイ メンテナンスを構成する (プレビュー)
仮想ネットワーク ゲートウェイにお客様が管理するメンテナンスを構成する - Azure VPN Gateway | Microsoft Learn
重要な設定項目としてメンテナンスウィンドウ スケジュールを指定する箇所がありますが、直観的にわかりにくいため、設定例とその動作について以下例を挙げて説明いたします。
スケジュールの設定例
“スケジュールの追加” を選択することで、メンテナンスウィンドウの開始時刻と許容するメンテナンス期間を設定します。
※メンテナンス期間の最小値は 5 時間で、それ以下を設定することはできません。
メンテナンス構成設定を追加した日時 1/1 9:00
1/31 に計画メンテナンスがある場合
メンテナンスウィンドウ設定に従い、 1/31 5:00 ~ 10:00 の間にメンテナンスが発生します
メンテナンス構成設定を追加した日時 1/1 9:00
2/10 に計画メンテナンスがある場合、メンテナンスウィンドウ設定に従い、 2/10 5:00 ~ 10:00 の間にメンテナンスが発生します
メンテナンス構成設定を追加した日時 1/1 9:00
1/15 に計画メンテナンスがある場合、メンテナンス構成設定は働かず、元々の計画メンテナンスの予定通り 1/15 にメンテナンスが実行されます
VirtualWAN 仮想ハブルータ, P2S GW, Application Gateway, Azure Firewall への対応時期は未定です
]]>メールに記載されておりますとおり、セキュリティとコンプライアンスの観点からレガシー TLS 1.0/1.1 は既知の脆弱性が存在しており、Azure 上のマネージド サービス全般におきまして、2024 年 10 月 31 日以降は TLS 1.2 以上の接続が必須となるよう変更されるものです。
TLS(Transport Layer Security)は、インターネット上でデータを安全に送受信するための暗号化する仕組みとして、主に TLS 1.0, TLS 1.1、TLS 1.2 及び TLS 1.3 バージョンが存在していますが、RFC 8996 により、セキュリティ脆弱性の原因で、TLS 1.0 及び TLS 1.1 の使用は既に廃止されています。Azure サービスでは、互換性の理由で TLS 1.0 及び TLS 1.1 が引き続き動作できますが、早めに TLS 1.2 以降のバージョンへ移行するのは強く推奨しております。
TLS のバージョンはお客様の IaaS 上の仮想マシン OS の設定、ならびにクライアント OS に依存します。こちらの設定確認をし、TLS 1.2 以上を使用できる状態としていただくことで、自動的に TLS の最上位バージョンでの接続を試みることとなります。
こちらの公開ドキュメントの記載通り、Windows 8/Windows Server 2012 以降では、既に TLS 1.2 をサポートしているため、基本的にご対応頂く必要はありません。
また、特定の TLS バージョンを有効化/無効化されたい場合は、こちらの記事の通りご対応ください。
Windows 2008/ Windows 7 などのレガシー OS でも更新プログラムを適用することで技術的には TLS 1.2 を使えるようになります。ただし、サポートの提供が終了している OS の場合には、TLS 1.2 を利用できるようになる更新プログラムの適用にかかわらず、技術的なご支援を Microsoft サポートからお届けすることはできません。自己責任の範疇でご利用ください。
参考として、Android など他のクライアント対応状況はこちらの公開ドキュメントに開示されています。
最新バージョンの各ブラウザでは、基本的に TLS 1.2 以降のバージョンが有効化されているため、ご対応頂く必要はありませんが、
特定の TLS バージョンを有効化/無効化されたい場合は、各ブラウザ観点でご確認頂く必要がございます。
Edgeの場合はこちらの記事の通り対応できます。
上記以外に、Java などプログラミング言語でお客様が開発したアプリケーションで Azure サービスへ接続する場合は、Windows OS の TLS レジストリ設定を参照せず、独自の設定通り接続する場合がありますので、お客様側にアプリケーション観点で TLS の通信バージョンご確認及びご対応頂く必要があります。
こちらのような外部の TLS チェッカー ツールをご活用いただき、想定されるクライアントからアクセスをして TLS バージョンを確認いただくということも有効です。
以下にて Azure Network 製品の対応状況、及びお客様に推奨なアクションをご紹介致します。
もしご確認されたい製品が入っていなく、個別にご確認されたい場合は、各製品に対してサポート リクエストを起票してください。
警告
以下各製品の部分に案内する対処目処はあくまで目途であり、実際には日程が多少前後する可能性があります。予めご了承ください。
Application Gateway では、SSL ポリシーを選択することで、クライアントが Application Gateway へ接続する際の最小 TLS バージョン(1.0 から 1.3 まで)を設定できます。
現時点では、Application Gateway は2024 年 10 月 31 日以降にも引き続き TLS1.0 から TLS1.3 をサポートしており、TLS1.2 以下のバージョンをサポートしなくなる予定はございません。
ただし、こちらの公開ドキュメントの記載通り、セキュリティ強化のためには TLS1.2 のご利用を推奨いたします。
注意
Application Gateway でのセキュリティを強化するために、TLS プロトコルの最小バージョンとして TLS 1.2 を使用することをお勧めします。
下図の通り、Azure ポータル → 対象 Application Gateway → 「リスナー」のタブにて、 「選択した SSL ポリシー」の「変更」ボタンをクリックし、「 SSL ポリシーの変更」より設定できます。
また、Application Gateway SKU v2 の場合は、こちらの手順通り、リスナー毎に異なる TLS バージョンを設定することも可能です。
こちらの公開ドキュメントの記載通り、Application Gateway がバックエンド サーバーへ通信する際に TLS 1.0, 1.1, 1.2 をサポートしております。
バックエンド サーバーへの接続は、常に最小でプロトコル TLS v1.0、最大で TLS v1.2 までです。 そのため、バックエンド サーバーとのセキュリティで保護された接続を確立するには、TLS バージョン 1.0、1.1、1.2 のみがサポートされます。
具体的な TLS バージョンの選定は接続先のバックエンド サーバーに依存するため、もし最小 TLS バージョンを 1.2 に指定したい場合は、Application Gateway ではなく、バックエンド サーバー側の TLS 設定に対応して頂く必要があります。
Azure Firewall では、TLS バージョンが関わる部分は TLS インスペクションのみとなります。アプリケーション ルール、ネットワーク ルール、及び DNAT ルールで通信を許可する場合は本通知の対象外となります。
TLS インスペクション機能を使用する場合は、こちらの公開ドキュメントの記載通り、現状及び 2024 年 10 月 31 日以降にも TLS1.0 及び TLS1.1 は互換性のために引き続き動作する予定ですが、早めに TLS 1.2 に移行することを強く推奨します。
ヒント
TLS 1.0 と 1.1 は非推奨になっていて、サポートされません。 TLS 1.0 と 1.1 のバージョンの TLS/SSL (Secure Sockets Layer) は脆弱であることが確認されています。現在、これらは下位互換性を維持するために使用可能ですが、推奨されていません。 できるだけ早く TLS 1.2 に移行してください。
また、現状の TLS インスペクション機能では TLS1.3 をサポートしておりませんが、2024 年 3 月頃にサポートする予定です。
こちらの公開ドキュメントの記載通り、 Front Door ではカスタム ドメインを利用する場合は、最小 TLS バージョンを 1.0 または 1.2 を選択できます。
Azure Front Door では、TLS プロトコルの 4 つのバージョン (TLS バージョン 1.0、1.1、1.2、1.3) がサポートされています。 2019 年 9 月以降に作成されたすべての Azure Front Door プロファイルでは、TLS 1.3 が有効になっている既定の最小値として TLS 1.2 が使用されますが、TLS 1.0 と TLS 1.1 は下位互換性のために引き続きサポートされています。
Front Door では 2024 年 10 月 31 日以降も引き続き TLS 1.0 から TLS 1.3 まで利用できますが、セキュリティ強化のためには TLS 1.2 以上のご利用を推奨いたします。
Private Link Service と Private Endpoint のサービスでは、TLS プロトコルは終端しません。
Private Link Service と Private Endpoint を利用した通信の場合には、クライアントとサーバーの通信上の両端で TLS ネゴシエーションが実施されます。クライアントおよびサーバーとなるサービスの観点でご確認頂く必要があります。
Bastion はお客様側で証明書の管理運用を意識する必要のないサービスとして、以下の公開ドキュメントの記載通り、 TLS 1.2 のみをサポートしておりますので、お客様側の対処が不要です。
Bastion では、TLS 1.2 がサポートされています。 以前の TLS バージョンはサポートされません。
こちらの公開ドキュメントの説明通り、TrafficManager は DNS レベルで動作する負荷分散サービスとして、クライアントからの通信は TrafficManager を経由しませんので、本通知の対象外となります。
こちらの公開ドキュメント記載通り、Azure Load Balancer では、TLS 接続を終端せずにバックエンド サーバーへ転送する動作となりますので、本通知の対象外となります。
今回は、Application Gateway 経由で Web サイトへアクセスしている際に、Application Gateway からの HTTP 応答でエラーが発生した場合の原因や調査方法などについてご紹介させていただき、特にお客様よりお問い合わせをいただく機会が多い 500 番台の HTTP 応答について、お客様が問題判別を行う際の参考にしていただくことを目的としております。(なお、V1 SKU は廃止となることが発表されておりますので、当ブログの対象外とさせていただいております。)
Application Gateway からは、状況に応じて、様々な HTTP 応答コードが返されます。
Application Gateway の HTTP 応答コード
HTTP 応答コードの確認方法ですが、Azure ポータルより、関連するメトリックを参照することが可能です。
Application Gateway メトリック
ヒント
メトリックを確認する際には、上流側 (Up Stream = データ配信側 = バックエンド側) から先に確認してください。(下に記載した各項目は、上流から順に並べています)
このメトリックは、正常性プローブによって異常であると判定されたバックエンドの数を表します。バックエンド プールごとにフィルター処理を行って、特定のバックエンド プールの異常なホストの数を表示することも可能です。Application Gateway が バックエンド プールにリクエストを転送するためには、該当のバックエンド プールへの正常性プローブが成功している必要があります。もし、想定外の「異常なホスト」が発生している場合には、下のリンク先を参照し、該当のバックエンド サーバーへの正常性プローブが成功するよう、問題判別を行ってください。
Application Gateway のバックエンドの正常性に関する問題のトラブルシューティング
バックエンド サーバーから Application Gateway に返された HTTP 応答コードの数を表します。(Application Gateway によって生成された HTTP 応答コードは含まれません。) HTTP 応答コードの分布をさらに分類し、2xx、3xx、4xx、5xx のカテゴリで応答を表示できます。Application Gateway は、基本的には、バックエンド サーバーによって返された HTTP 応答コードをクライアントに転送しますので、バックエンド サーバーが想定外の HTTP 応答コードを返している場合には、バックエンド サーバー側にて問題判別を行ってください。
Application Gateway からクライアントに返された HTTP 応答コードの数を表します。応答状態コードの分布をさらに分類し、2xx、3xx、4xx、5xx のカテゴリで応答を表示できます。
Application Gateway が 5xx サーバー エラーコードで処理した要求の数です。これには、Application Gateway から生成された 5xx コードと、バックエンドから生成された 5xx のコードが含まれます。
要求の数をさらにフィルター処理することで、各々のまたは特定のバックエンド プール http 設定の組み合わせごとに数を表示できます。
ヒント
上記のメトリックにて、バックエンド サーバーもしくは Application Gateway にて、どのような HTTP 応答コードを返しているかを確認した後に、下の HTTP 応答コード毎の発生原因 / 問題判別方法 に進んでください。
また HTTP 応答コードは、「診断ログ」にてアクセス ログを有効化することにより確認することも可能です。
500 から 599 の HTTP 応答コードは、クライアントからの要求の実行中に Application Gateway または バックエンド サーバーにおいて問題が発生したことを示しています。
Application Gateway が 502 エラーを返す理由はいくつかありますが、まずは前述のように、正常性プローブが成功しているかどうか確認してください。502 エラーは、お客様からのお問い合わせが最も多いエラーですが、前述のように Application Gateway から バックエンド プールへの正常性プローブが失敗しているため、発生しているケースが多く見受けられます。
Application Gateway のバックエンドの正常性に関する問題のトラブルシューティング
また、502 エラーの原因といたしましては、下記などもあげられます。
502 エラーにつきましては、過去にもブログにて取り上げておりますので、下のリンク先もご参照いただければと思います。
Application Gateway における 502 Error について
Application Gateway の散発的な 502 エラー
バックエンド サーバーからの応答時間が、「要求のタイムアウト」値 (既定値 : 20 秒) を超えた場合には、HTTP 504 エラーが発生します。問題判別の方法としては、
この応答コードは、Application Gateway の内部でエラーが発生したことを示すものです。このコードが表示された場合は、サポート リクエストを起票してください。
重要
サポート リクエスト起票の際には、下記の情報を添えてお問い合わせいただければと思います。
・問題発生日時 (mm/dd hh:mm:ss)
・Application Gateway のリソース ID
・クライアントの情報 (パブリック IP アドレス等、仮想マシンの場合は リソース ID)
・アクセスした URL
・HTTP 応答コード
・お客様にて行った問題判別の内容や確認の結果 (例 : バックエンド サーバーのログの確認結果等)
・問題発生の前後にて Application Gateway やバックエンド サーバーにて行った設定変更内容 (もしあれば)
当ブログが、お客様よりお問い合わせをいただくことが多い 500 番台の HTTP 応答が発生した場合に、お客様にて問題判別を行う際の手助けになりましたら、幸いです。
]]>まず前提として、Azure Firewall の観点では、Azure Firewall が参照する中間 CA 証明書によって、TLS 検査を行うためのサーバー証明書が作成できるのであれば、中間 CA 証明書を発行した CA の種別は問いません。
Azure Firewall Premium の TLS 検査を適切に構成するには、有効な中間 CA 証明書を用意し、それを Azure Key Vault に格納する必要があります。
上記で抜粋した 有効な中間 CA 証明書
に関しまして、Azure Firewall の TLS 検査に必要な中間 CA 証明書の要件は下記のドキュメントの通りとなります。
こちらの要件を満たした中間 CA 証明書であれば、どの CA から発行されたものであっても、検証環境 / 運用環境を問わずご使用いただくことが可能です。
・Key Vault シークレットとしてデプロイする場合、証明書と秘密キーを使用するパスワードレス PFX (PKCS12) を使用する必要があります。
・PEM 証明書はサポートされていません。
・単一の証明書でなければならず、証明書チェーン全体を含めることはできません。
・今後 1 年間有効でなければなりません。
・最小サイズが 4096 バイトである RSA 秘密キーでなければなりません。
・KeyCertSign フラグによって Critical とマーク付けされた KeyUsage 拡張が必要です (RFC 5280、4.2.1.3 Key Usage)。
・Critical とマーク付けされた BasicConstraints 拡張が必要です (RFC 5280、4.2.1.9 Basic Constraints)。
・CA フラグが TRUE に設定されている必要があります。
・パスの長さは 1 以上でなければなりません。
・証明書はエクスポートできる必要があります。
こちら のドキュメントに記載の通り、TLS 検査で使用可能な中間 CA 証明書は下記の 3 つの方法で作成していただけます。
以下の表は 3 つの方法の簡単な比較表となります。
下記にそれぞれの生成方法についての詳細をご説明いたします。
エンタープライズ PKI としては「エンタープライズ CA」と「スタンドアロン CA」が存在します。
**参考: グループ ポリシーを使用してクライアント コンピューターに証明書を配布する
プライベート エンドポイントは主に Azure PaaS に対して、仮想ネットワーク上のアドレス空間のプライベート IP アドレスを用いて接続を提供するサービスです。
プライベート エンドポイントをご利用いただけば、Azure PaaS に対して、ExpressRoute や VPN で接続されたオンプレミスからもインターネット経由ではなく仮想ネットワーク経由で接続が可能です。
またこのブログでは紹介しませんが、Azure Load Balancer に対して適用できる Private Link Service をご利用いただけば、アドレス空間が重複した仮想ネットワーク間でも接続が可能です。
類似機能のプライベート エンドポイントとサービス エンドポイントの違いについては、別のブログ で紹介していますのでご参照いただければと思います。
Azure PaaS は基本的にパブリック インターネットからの接続を前提としています。また、ほとんどの Azure PaaS がマルチテナント構成となり、ご利用時に接続する際は、対象の Azure PaaS に該当する FQDN で接続します。
プライベート エンドポイントは仮想ネットワーク上にエンドポイントを構成することで、Azure PaaS にプライベート IP アドレスで接続する機能を提供していますが、クライアントが接続する際の FQDN は変わりません。
プライベート エンドポイントは、あくまで Azure PaaS への接続点を仮想ネットワーク上に構成するものであり、Azure PaaS へのプライベート接続は DNS レイヤーのルーティングで実現しています。
この時、DNS レイヤーのルーティングを privatelink サブドメインが付与された FQDN を用いて実施します。
つまり、プライベート エンドポイントをご利用いただく上で、DNS レイヤーの構成が大変重要な要素になります。
Azure PaaS のプライベート エンドポイントを有効化することで、具体的にどのような変化が発生するのかをご紹介します。
ここでは東日本リージョンの Azure Blob Storage の FQDN (jpaztechpeblog.blob.core.windows.net) の DNS レコードの遷移をご紹介します。
なお説明の便宜上、dig コマンドで応答された ANSWER SECTION の表示を基にご紹介します。
まず、プライベート エンドポイントが有効化されていない Azure Blob Storage の FQDN を名前解決した時、下記のような DNS レコードが応答されます。下記の応答結果から、Azure Blob Storage に接続時の FQDN が、Azure Blob Storage のエンドポイントに CNAME レコードで変換され、その後 A レコードでパブリック IP アドレスが応答されることが確認できます。
jpaztechpeblog.blob.core.windows.net. 60 IN CNAME blob.tyo20prdstr07a.store.core.windows.net.
blob.tyo20prdstr07a.store.core.windows.net. 60 IN A 20.60.248.65
次に、Azure Blob Storage に対して、プライベート エンドポイントを有効化した時の DNS レコードの応答を確認します。
下記の応答結果から、プライベート エンドポイントが有効化された後に、privatelink サブドメインが付与された FQDN が追加されたことが確認できます。
jpaztechpeblog.blob.core.windows.net. 60 IN CNAME jpaztechpeblog.privatelink.blob.core.windows.net.
jpaztechpeblog.privatelink.blob.core.windows.net. 60 IN CNAME blob.tyo20prdstr07a.store.core.windows.net.
blob.tyo20prdstr07a.store.core.windows.net. 60 IN A 20.60.248.65
上記の DNS レコードの遷移や応答結果は、ご利用いただくリージョンや各 Azure PaaS によっては細部が異なりますが、基本的には上記の例が大多数となっています。
各 Azure PaaS の FQDN がどのように遷移するかはプライベート エンドポイントの公開情報 でご紹介しています。
なお、Azure PaaS によってはすべてのユーザーに同一の FQDN でエンドポイントを提供している下記のようなサービスもあり、この場合既定で privatelink サブドメインが付与されています。
・Azure Virtual Desktop : rdweb.wvd.microsoft.com /
・Azure Synapse : web.azuresynapse.net
・Azure Data Factory : adf.azure.com
Azure PaaS への接続をパブリック エンドポイントからプライベート エンドポイントに切り替えるには、DNS レイヤーの構成が重要になります。
この DNS レイヤーのルーティングについてご紹介します。
ここでは Azure の仮想ネットワーク上に仮想マシンをデプロイし、Azure Blob Storage に接続するシナリオを例に挙げて、DNS ルーティングについて説明します。
通常の Azure Blob Storage に接続する場合、下記の構成図のように接続時の FQDN に対してパブリック IP アドレスが応答され、クライアントは該当のパブリック IP アドレスに接続を試行します。
プライベート エンドポイントを有効化した際に、既定の設定では対象の Azure PaaS に対応するプライベート DNS ゾーンが構成されます。プライベート DNS ゾーンは仮想ネットワークとリンクすることで、Azure 既定の DNS (168.63.129.16) を参照しているクライアントに、構成したゾーンの DNS レコードを応答するサービスです。
Azure Blob Storage の場合、privatelink.blob.core.windows.net が該当ゾーンとしてデプロイされ、対象のホスト名に対して設定された A レコードが応答されます。これにより、仮想マシンはプライベート エンドポイントに対して Azure Blob Storage の FQDN の接続を試行します。
このように、プライベート DNS ゾーンを用いて privatelink サブドメインの DNS レコードをオーバーライドすることで、DNS ルーティングを実現します。
なお、プライベート エンドポイントの利用にあたり、プライベート DNS ゾーンの利用は必須ではありません。DNS レコードのオーバーライドができれば hosts ファイル、カスタム DNS、オンプレミスの DNS などでも DNS ルーティングが実現可能です。
例えば、仮想マシンの OS 上の hosts ファイルで、接続先の FQDN に対して、プライベート エンドポイントの IP アドレスを指定することでも構成可能です。
以上がプライベート エンドポイントの仕組みとなります。実際にご利用いただく中で、よくお問い合わせいただく内容や情報採取については、こちら をご覧ください。
以上、ご参考になれば幸いです。
]]>プライベート エンドポイントをご利用いただく上で、DNS レイヤーの構成がポイントになる点について、こちらでご紹介しました。
今回は実際に構成する上でのよくあるトラブル事例や、Azure サポートにお問い合わせいただく際に情報提供いただきたい事項などを纏めました。
プライベート エンドポイントのトラブルシューティングでは、DNS 構成を確認するために、クライアントの名前解決の状況を確認することが重要です。
そのため、Azure サポート担当にお問い合わせ時に下記の点について情報提供いただけると幸いです。
・接続元のクライアント情報
・接続先のプライベート エンドポイントのリソース情報
・接続経路
・接続元クライアントの DNS 構成
・接続元クライアントの名前解決の状況
上記についてそれぞれ補足致します。
・接続元クライアント情報
接続元クライアントが Azure 仮想マシンなど Azure 上のリソースであれば、該当の Azure リソース ID をご提供ください。
もしオンプレミス上の機器が接続元クライアントとなる場合、オンプレミスである旨と接続元クライアントの IP アドレスをご提供ください。
・接続先のプライベート エンドポイントのリソース情報
お問合せ時に対象のプライベート エンドポイントのリソースを選択可能な場合は、選択いただければ Azure サポート担当は対象のリソース情報を確認できます。
対象のプライベート エンドポイントのリソースを選択してお問い合わせが難しい場合、プライベート エンドポイントのリソース ID をご提供ください。
・接続経路
想定されている接続元クライアントからプライベート エンドポイントの接続経路についてご提供ください。
例えばオンプレミスからの接続の場合は ExpressRoute をご利用いただいている旨や、Azure Firewall で通信制御をされている、プロキシ サーバーをご利用いただいているなどの情報をご提供いただけると幸いです。
・接続元クライアントの DNS 構成
DNS 構成として hosts、オンプレミスの DNS サーバー、Azure DNS Private Resolver 、カスタム DNS など複数の構成方法がありますが、接続元クライアントのご状況に合わせて情報をご提供ください。
例えば、hosts で制御している場合は該当の hosts ファイルも併せてご提供いただけると幸いです。
接続元クライアントがオンプレミスの DNS サーバーを参照している場合、オンプレミスの DNS サーバーから Azure へのクエリ転送設定 (フォワーダー・条件付きフォワーダー) の状況も併せてご提供ください。
また、Azure DNS Private Resolver をご利用いただいている場合は、リソース ID をご提供ください。
・接続元クライアントの名前解決の状況
接続元クライアントの名前解決の確認方法はクライアントの実行環境によって異なります。
Azure サポート担当での調査では、下記の情報の提供をお願いする場合がありますため、事前にご提供いただけると幸いです。
(お客様の環境に沿って FQDN をご変更ください。)
・ <推奨> PowerShell
1 | Get-Date -Format "yyyy/MM/dd HH:mm:ss K" |
・ dig (Linux)
1 | date -u |
なお、パブリック インターネット上で名前解決の状況を確認する場合は、https://digwebinterface.com/ などでカスタマイズしたクエリが実行可能です。
プライベート エンドポイントに関して、よくお問い合わせいただく内容について下記の通りお伝えいたします。
プライベート エンドポイントの IP アドレスは動的・静的での割り当てが選択できます。
動的の割り当ての場合、プライベート エンドポイントをデプロイする対象サブネットのプレフィックスの範囲内で、基本的に若番から割り当てがされます。
静的の割り当ての場合、対象サブネットの範囲で任意の IP アドレスを指定可能です。
動的の割り当てを選択された場合でも、プライベート エンドポイントのリソースを削除しない限り、一度割り当てられた IP アドレスは変わりません。
プライベート DNS ゾーンに適切な DNS レコードを設定したにも関わらず、名前解決ができない場合は下記の理由が考えられます。
A プライベート DNS ゾーンが、クライアントが存在する仮想ネットワークとリンク設定されていない。
B プライベート DNS ゾーンが参照されない構成になっている。
C プライベート DNS ゾーン上に必要な DNS レコードが存在していない。
A
プライベート DNS ゾーンは、リンクされた仮想ネットワーク上のリソースに対して、登録されたゾーン上の DNS レコードに関して名前解決を提供します。そのため、プライベート DNS ゾーンのリソースから対象の仮想ネットワークにリンク設定を忘れないようにしてください。
B
プライベート DNS ゾーンを参照するためには、Azure 既定の DNS サーバー (168.63.129.16) に DNS クエリを転送する必要があります。オンプレミスのリソースからプライベート DNS ゾーンを参照する場合は、Azure DNS Private Resolver をご利用いただき、オンプレミスの DNS サーバーから条件付きフォワーダーなどで参照できるように構成してください。構成事例はこちらにあります。
C
プライベート DNS ゾーンは、リソース グループ内で重複がなければ同一ゾーン名で複数構成が可能です。プライベート エンドポイントを構成時に DNS 統合した場合、自動で DNS レコードがプライベート DNS ゾーン上に構成されますが、この時対象のプライベート DNS ゾーンが異なるとクライアントが接続先の FQDN の名前解決ができなくなる場合があります。
ご期待に沿えず恐れ入りますが、現状該当 DNS ログを Azure ユーザーが確認する方法はございません、
Azure サポート担当にご依頼いただければ、該当ログの調査支援が可能ですが、ログの調査をするには対象の FQDN と調査対象の時刻を可能な限り具体的にご提示願います。
なお、Azure 既定の DNS のログは、30 日程度でローテーションされ、過去のログは参照できない点はご留意ください。
プライベート エンドポイントは、最終的に接続元クライアントが適切な名前解決ができれば接続可能なため、プライベート エンドポイントをご利用いただく上で hosts を利用いただくことがサポート外といった事はございません。そのため、トラブルシューティングの対応の一環でサポート担当から hosts への追加を依頼する場合があります。
しかしながら、hosts はクライアント端末毎に手動での個別管理となりますため、プライベート エンドポイントの作り直しによる IP アドレスの更新や新規エンドポイントの追加などが自動で適応されません。構成変更時などで hosts の更新漏れによる意図せぬ通信影響を回避するためにも、運用環境では hosts による構成は推奨していません。
プライベート エンドポイントをご利用いただく上でのポイント にも記載の通り、Azure PaaS にプライベート エンドポイント接続をする構成でも、接続時にご利用いただく FQDN は、Azure PaaS の既定のドメインが対象となります。
DNS レイヤーでルーティングができるように、privatelink サブドメインが追加されますが、この privatelink サブドメインが付与された FQDN で Azure PaaS に接続することは想定されていないため、接続エラーや証明書エラーが発生します。
プライベート エンドポイントは、Azure PaaS への接続点を提供しているものであり、ドメイン管理などの機能は持ち合わせていません。
そのため、カスタムドメインをご利用いただけるかは、ご利用される Azure PaaS の機能に依存し、カスタムドメインをご利用いただく場合は対象の FQDN の名前解決が、プライベート エンドポイントの IP アドレスに解決されるように DNS 構成を実施いただく必要があります。
以上、ご参考になれば幸いです。
]]>Microsoft Azure Peering Service (MAPS) は、インターネット サービス プロバイダー (ISP) や Internet Exchange (IX) 経由で Microsoft のグローバル ネットワーク (AS8075) へのルーティングを最適化し信頼性とパフォーマンスを強化するサービスです。サービス名に “Azure” の名前を冠してはいますが、その接続先は Azure だけではなく、パブリック インターネット経由でアクセス可能な Microsoft 365 や Dynamics 365 等を含んだ Microsoft のグローバル ネットワーク全体になります。
また、以下のドキュメントにも記載がありますが、Azure Peering Service は閉域接続 (プライベート接続) サービスではありません。あくまでも ISP や IX 経由で直接 Microsoft のネットワークに接続するサービスですので、他の AS を経由しない分だけホップ数や遅延が小さく抑えられ、通信経路上の影響を受けにくいというのみであり、位置づけとしてはパブリック ネットワーク (≒インターネット) 経由での接続となります。
Azure Peering Service と似たサービスとして、ExpressRoute 回線 (ExpressRoute Circuit) の Microsoft Peering が存在します。両者の違いについてお問い合わせいただく事も多いため、具体的な差異を以下の表でご説明します。
Azure Peering Service | ExpressRoute (Microsoft Peering) | |
---|---|---|
接続先 | Microsoft のグローバル ネットワーク | 主に Azure のみ |
Microsoft 側の ASN | 8075 | 12076 |
接続形態 | パブリック接続 (≒インターネット) | プライベート接続 (≒閉域網) |
Azure VNet への接続 | 不可 | Private Peering を構成すれば可能 |
Microsoft 365 との接続 (*) | 可能 | 一部の承認されたお客様のみ可能 |
Azure 上のリソース (**) | テレメトリ機能を利用する場合のみ作成 | ExpressRoute 回線リソースを作成 |
接続料金 (**) | 原則、接続プロバイダー様のみにお支払い | Azure と接続プロバイダー様の双方にお支払い |
SLA (**) | 接続プロバイダー様にご確認ください | MSEE 側の問題であれば Microsoft 側の SLA 有り |
サポート窓口 (**) | 原則、接続プロバイダー様 | Azure (MSEE) 側は Microsoft、PE 側は接続プロバイダー様 |
Azure ExpressRoute for Microsoft 365 に以下の記載がある通り、ExpressRoute での Microsoft 365 への接続は承認制となっています。法規制により閉域接続が必須となっているような一部のお客様に限ってのみ承認され、そうした特殊な要件がない場合にはご利用いただけません。Microsoft 365 との安定した接続を確保したい一般のお客様は、Azure Peering Service での接続をご検討ください。(ただし、前述の通り Azure Peering Service は閉域接続のためのサービスではございませんのでご留意ください。)
Microsoft 365 の ExpressRoute は、ほとんどの状況でサービスに最適な接続モデルを提供しないため 、お勧めしません。 そのため、この接続モデルを使用するには Microsoft の承認が必要です。 お客様のすべての要求を確認し、必要なまれなシナリオでのみ、Microsoft 365 の ExpressRoute を承認します。 詳細については 、ExpressRoute for Microsoft 365 ガイド を参照してください。また、生産性、ネットワーク、セキュリティ チームに関するドキュメントの包括的なレビューに従って、Microsoft アカウント チームと協力して、必要に応じて例外を送信してください。 Microsoft 365 のルート フィルターを作成しようとしている未承認のサブスクリプションには、 エラー メッセージが表示されます。
また、Microsoft 365 は Internet 経由で快適にご利用いただけるよう弊社外の 3rd party の CDN サービス等も利用しているため、ExpressRoute と Azure Peering Service のいずれを利用される場合であっても、弊社外のエンドポイントとの通信に Internet 接続が必要となりますので、十分ご留意ください。
ExpressRoute をご利用の場合には、Azure 上で ExpressRoute 回線のリソースを作成したり、各種設定をご実施いただきます。他方で Azure Peering Service に関しては、(テレメトリの機能を利用しない限りは) Azure 上のリソースは作成したり、設定を行っていただく必要はなく、ExpressRoute 回線のように Microsoft に対して接続料金をお支払いいただくことはありません。言い換えますと、仮に通信障害などが発生したとしても、Microsoft としては料金を頂戴していないため、SLA による返金はございません。(接続プロバイダー様による SLA の提供有無をご確認ください。)
また、Azure 側に個々のお客様のリソースが存在せず、各接続プロバイダー様とお客様間の契約情報なども弊社では把握できないことから、障害時に Microsoft 側へお問い合わせいただいたとしても環境固有の調査などを行うことができません。したがって、トラブル時のお問い合わせ先 (サポート窓口) は原則として Microsoft ではなく、接続プロバイダー様となります。(接続プロバイダー様によって Microsoft 側に問題があると判断された場合には、接続プロバイダー様と弊社の NOC 間で調査を行うこととなります。)
以上、ご参考になれば幸いです。
]]>Azure VM のいくつかの設定項目は、VM 作成後は変更いただくことが叶いませんが、OS / データディスクを保持したまま、VM を再作成いただくことで再作成時に変更することが可能でございます。
本記事では、通常変更不可である設定項目を、VM を再作成で変更する手順についてご案内します。
以下の項目を変更したい場合、VM の再作成が必要となっております。
それでは、実際に VM 再作成で各項目を変更するための手順について説明させていただきます。
まずは、VM 再作成時に再度同じ設定をするために Azure ポータルの対象 VM の画面を開き、赤枠の項目を控えます。
多くの項目がございますが、代表的なものについて説明させていただきますので、以下の通り設定値を控えておきましょう。
元の NIC を用いるかどうかによって、以下の 2 パターンに分けられます。VM 再作成時は Azure Portal にて既存 NIC を指定できませんが、VM 再作成後に後から NIC を付け替えることが可能です。該当する方を控えてください。
b-1. 元の NIC を用いて新しい仮想マシンを作成する場合
b-2. 新しい仮想マシンを作成する際に、元の NIC を使用しない場合
ネットワーク設定メニュー
負荷分散メニュー
ディスクメニュー
これで、再作成のための情報を控えることができました。
Note
この手順は以下のシナリオに該当する場合のみ実施をお願いいたします。
該当しない場合は、後述の「3. 元の仮想マシンを削除する」の手順に進んでください。
【該当シナリオ】
上記シナリオの場合は、そのゾーン設定に対応するディスクを作成する必要があります。
理由としては、以下の例のように特定のゾーン対応に存在しないディスクから、そのゾーン以外の VM を作成しようとすると、以下のような警告メッセージが表示され、VM 再作成ができないからとなります。
a. Azure ポータルより [Virtual Machines] - [<当該 VM 名>] を開きます。
b. 左メニュー “設定” より [ディスク] を選択し、開いた画面 “OS ディスク” より [<当該 OS ディスク名>] をクリックします。
c. 画面の [+ スナップショットの作成] をクリックします。
d. 必要項目を適宜入力し、[確認および作成] - [作成] をクリックします。
[ストレージの種類] は、スナップショットを高パフォーマンスのディスクに保存する必要がある場合を除き、 [Standard HDD(ローカル冗長ストレージ)] を選択します。
e. データディスクがある場合、データディスクについても同様にスナップショットを作成します。
a. Azure ポータル 上部の検索バーに “スナップショット” と入力し、サービス [スナップショット] を選択します。
上記手順で作成した OS ディスクおよび、データ ディスクのスナップショットが作成されていることを確認します。
b. 対象ディスクのスナップショットを選択し、[+ ディスクの作成] をクリックします
c. 必要項目を適宜入力し、[確認および作成] - [作成] をクリックします。
特定の可用性ゾーンに所属させたい場合は、以下のように可用性ゾーン番号をご指定ください。
それ以外の場合は [インフラストラクチャ冗長は必要ありません] を選択します。
これにより、特定のゾーンに所属するディスク(もしくは、ゾーン設定の無いディスク)を用意することが出来ました。
この作成したディスク名は VM 再作成時に使用しますので、控えておいてください。
元の仮想マシンを削除します。
なお、この際にディスク等のリソースは残しますので、データが消失するものでは無い点はご安心ください。
一時ディスクの内容は破棄されます点はご承知おきくださいませ。
a. 対象の仮想マシンの概要上部にある「削除」をクリック
b. 以下赤枠内にチェックを入れないように気を付けて削除してください
これでディスクを残したまま、仮想マシンのリソースを削除できました。
残されたディスクから VM を再作成します。
VM 再作成時にお好みの設定に変更が可能となっております。
a. Azure ポータルより削除した VM で使用していた OS ディスク (控えていた OS ディスク名を参照) の画面を開きます。
なお、ゾーンに関する設定変更を行う場合は 「2.スナップショットからゾーン設定を変更したディスク作成(可用性ゾーンの設定変更のシナリオの場合のみ実施)」 の手順で作成したディスクをかわりに選択します。
b. [VM の作成] をクリックします。
c. 手順 「1. 必要事項を控える」 にて控えていた内容をもとに VM の設定項目を入力していきます。
この際、変更を行いたい項目をご変更くださいませ。
リソース名を変更したい場合
データディスクを追加したい場合
元の仮想マシンのデータディスクを追加したい場合は、[既存のディスクの接続] より追加します。
新しい仮想マシンで可用性セットを使用したい場合
[可用性オプション] にて [可用性セット] を選択し、[可用性セット] の項目にてご希望の障害ドメイン、更新ドメイン数を入力ください。
新しい仮想マシンで可用性ゾーンを使用したい場合
[可用性オプション]の項目で[可用性ゾーン] を選択し、[可用性ゾーン] の項目では、スナップショットからディスクを作成する際に指定したゾーン番号を選択します。
Azure Spot 割引を変更したい場合
接続先 VNET を変更したい場合
Note
ネットワークについて、既存の NIC 接続は VM 作成後に行いますので、既存 NIC を使用する場合、この段階での “NIC ネットワーク セキュリティ グループ” の設定は不要です。
新規の NIC を使用する場合は、リージョンの変更が無い場合、元と同じ NSG を選択することも可能です。
d.全ての設定が完了後、 [確認および作成] から[作成] をクリックします。
Azure ポータルより VM 作成をする際には既存 NIC を指定できませんが、 VM 再作成後に後から NIC を付け替えることが可能です。
a. 仮想マシンを作成後、既存の NIC を接続するため、VM を停止 (割り当て解除) します。
b. VM 停止 (割り当て解除) 後、VM のページから [ネットワーク] - ネットワーク設定 - [ネットワーク インターフェイスのアタッチ] を選択し、削除した VM で使用していた NIC を接続します。
c. 既存の NIC の接続完了後も、VM 作成時に作成された NIC がまだプライマリとなっている状態なので、[ネットワーク インターフェイスのデタッチ] を選択し、その NIC をデタッチします。
NIC のデタッチを実施後、セカンダリとして接続した既存 NIC は自動的にプライマリとなります。
なお、デタッチした NIC については削除されても問題ありません。
d. VM を起動します。
手順は以上となります。本記事が皆様のお役に立ちましたら幸いです。
]]>幣 Azure テクニカル サポート チームにお問い合わせをいただく際に、パスワード等の機密情報を記載されてしまっているというケースが発生しております。
恐れ入りますが、機密情報はお客様自身で適切に管理いただき、お問い合わせにてお客様の機密情報を記載をしないようにお願い申し上げます。
これはお問い合わせ起票時以外にも、以下のようなお問い合わせ最中のやり取りも含めてのお願いとなります点、ご理解頂けますと幸いでございます。
加えて、テキストベースのファイル以外にもスクリーンショットなどの画像についても機密情報が含まれないようにご注意くださいませ。
以下の例のような機密情報は、お問い合わせに記載をしないようにお願い申し上げます。
もしこれらの情報が含まれる場合は、当該箇所をマスクしていただくようにお願い申し上げます。
以下はパスワードや Azure ストレージアカウントのアクセスキーおよび SAS キーについてマスクする一例となります。
1 | -- password P@ssw0rd! |
1 | $connectTestResult = Test-NetConnection -ComputerName test-storage-account.file.core.windows.net -Port 445 |
https://test-storage-account.blob.core.windows.net/container?sv=2022-11-02&ss=bfqt&srt=sco&sp=rwdlacupiytfx&se=2023-12-29T12:05:45Z&st=2023-12-29T04:05:45Z&spr=https&sig=<●●●ストレージアカウントの SAS キーなのでマスクします●●●>
ヒント
Azure ストレージアカウントのアクセスキーについてご懸念がございます場合は、以下の公開ドキュメントの通りローテーションを行うことが可能です。
もし、お客様側より上記のような機密情報を記載されてしまった際は、弊社よりお客様へご連絡の上、弊社およびお客様側で当該情報の削除の対応や、場合によっては新規のお問い合わせ発行をお願いさせていただくといったお手間をおかけする可能性があります。
そのため、サポート着手までお時間をいただく可能性がございます。
迅速なサポートのご提供およびお客様のセキュリティのためにも、機密情報の記載をしないようにご協力をお願い申し上げます。
Azure Firewall のイージー アップグレード/ダウングレード 機能の導入により、Standard と Premiume の SKU アップグレード/ダウングレードが容易に行えるようになりました。
しかしながら、Premium から Standard へのダウングレードに当たっては、Firewall Policy の ポリシー レベルを Premium から Standard へ変更することができません。
そのため、Azure Firewall の SKU を変更する前に Firewall Policy を Standard で再作成する必要があります。
Azure Firewall の SKU を Premium から Standard にダウングレードする手順は以下の通りとなります。
なお、Azure Firewall の SKU を Premium から Standard にダウングレードできるのは、Firewall Policy を使用している場合のみとなります。
ファイアウォール規則 (クラシック) を使用して Azure Firewall を管理することができないため、この点ご留意いただけますと幸いです。
また、ダウングレードした際のダウンタイムにつきましては、明確なダウンタイムはご案内することが困難ですが、15 ~ 20 分程度の時間がかかることを確認しております。
そのため、ダウングレードする際は、影響がない時間帯で実施いただければと存じます。
Azure Firewall の SKU 変更ついては以下にも記載がありますのでご一読ください。
Azure Firewall イージー アップグレード/ダウングレード
この度の通知以前から、お客様が ExpressRoute 回線リソースをご作成される際には 50 Mbps から 10 Gbps の間で回線帯域幅をご選択いただいております。この回線帯域幅は作成後にお客様にて増速することが可能です。この回線帯域幅はマイクロソフト側エッジルーターの割り当て済み帯域幅の計算に利用されております。
2024 年 1 月 17 日 の Tracking ID MV1F-T9G (タイトル : We have important information for your ExpressRoute service ) の通知は、すべてのお客様がご契約済みの回線帯域幅をより公平にご利用いただくために、ExpressRoute 回線のマイクロソフト側エッジルーターにおいて流量制御を今後実施する旨をご案内しております。
2024 年 2 月 15 日から 6 月 30 日の間にかけて、Azure における標準的な変更管理プロセス(※)に則って、順次マイクロソフト側エッジルーターにおけるレート制限は有効化されます。
(※) Advancing safe deployment practices | Microsoft Azure Blog
マイクロソフト側エッジルーターにおけるレート制限に際して、ほとんどのお客様において構成変更作業は発生いたしません。
この流量制御の影響を受けるのは、お客様にてご選択済みの ExpressRoute 回線帯域幅を超える帯域幅をご利用になっているお客様のみであるためです。
ご利用中の回線において実際に利用している帯域幅が、お客様にてご選択済みの ExpressRoute 回線帯域幅を下回っていることを確認するには、ExpressRoute 回線のメトリックをご利用ください。
(参考ドキュメント)
Azure ExpressRoute: 監視、メトリック、およびアラート | Microsoft Learn
ビットのインとアウト - ピアリングごとのメトリック
ご利用中の回線において実際に利用している帯域幅が、お客様にてご選択済みの ExpressRoute 回線帯域幅を上回っている場合、ご選択いただいた回線帯域幅の増速をご検討ください。
ExpressRoute 回線帯域幅の増速にあたっては、お客様と ExpressRoute プロバイダー様の間でご契約いただいている回線帯域幅についても過不足がないかをご確認ください。
(参考ドキュメント)
クイックスタート: ExpressRoute を使った回線の作成と変更 - Azure portal | Microsoft Learn
ExpressRoute 回線の変更
Azure では、ロール ベース アクセス制御 (RBAC) という機能を使用し、アクセスできるリソースを制限したり、リソースへの操作を制限したりすることが可能です。
Azure には既定で各リソース操作(アクション)の許可をまとめた組み込みロールのご用意がありますが、Azure 組み込みロールがお客様のご要件を満たさない場合は、独自の Azure カスタム ロールを作成することができます。
参考)Azure 組み込みロール
https://learn.microsoft.com/ja-jp/azure/role-based-access-control/built-in-roles
(抜粋)
Azure ロールベースのアクセス制御 (Azure RBAC) には、ユーザー、グループ、サービス プリンシパル、マネージド ID に割り当てることのできる Azure 組み込みロールがいくつかあります。 ロールの割り当ては、Azure リソースへのアクセスを制御する方法です。 組み込みロールが組織の特定のニーズを満たさない場合は、独自の Azure カスタム ロールを作成することができます。 ロールの割り当て方法については、「Azure ロールを割り当てる手順」を参照してください。
上記のドキュメントにて各組み込みロールで、実際にどのアクションが許可されているのかも確認が可能です。
ただし、リソースへの操作に対して最低限必要となるアクションの組み合わせについては、公開ドキュメントに明記されていないこともございますので、お客様のご要件に合わせてトライ アンド エラーしながら最終的に必要となるアクションを確認し、カスタム ロールを作成いただくこととなります。
また、Azure サポート窓口にて、カスタム ロールの作成の代行は叶いません点あらかじめご了承ください。
ここでは、Azure Portal から仮想マシンのディスクのスナップショットを取得するという操作を例に、当該操作を許可するためのアクションを確認し、カスタム ロールを作成していきます。
なお、他のどのような操作におきましても必要最小限のアクションのみが許可されたカスタム ロールを作成いただく場合、基本的には以下例のようにトライ アンド エラーを繰り返しながらカスタム ロールを作成いただくこととなります。
Microsoft.Compute のリソース プロバイダーに対する操作となるため、Microsoft.Compute の項目を確認します。
参考)Azure リソース プロバイダーの操作
https://learn.microsoft.com/ja-jp/azure/role-based-access-control/resource-provider-operations
スナップショットの作成には ‘Microsoft.Compute/snapshots/write’ のアクションが必要となることを確認します。
必要となるアクションについては、既に権限のあるユーザーで実際の操作を行った際に記録されるアクティビティ ログの action 項目をご確認いただくことも有用です。
手順 1 で確認した ‘Microsoft.Compute/snapshots/write’ アクションのみを許可したカスタム ロールを作成します。
[JSON] タブを選択すると ‘Microsoft.Compute/snapshots/write’ アクションのみが割り当たっていることを確認することができます。
特定のユーザー testuser01 に当該カスタム ロールを割り当てます。
カスタム ロールの作成手順の詳細については、以下のブログ記事や公開ドキュメントをご参照ください。
参考)カスタムロールを作成する手順
https://jpaztech.github.io/blog/vm/rbac-vm-start-stop-restart/#%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%A0%E3%83%AD%E3%83%BC%E3%83%AB%E3%82%92%E4%BD%9C%E6%88%90%E3%81%99%E3%82%8B%E6%89%8B%E9%A0%86
参考)Azure portal を使用して Azure カスタム ロールを作成または更新する
https://learn.microsoft.com/ja-jp/azure/role-based-access-control/custom-roles-portal
参考)カスタム ロールの作成手順
https://learn.microsoft.com/ja-jp/azure/role-based-access-control/custom-roles
ユーザー testuser01 で Azure Portal へサインインし、[Virtual Machines] の一覧ページへ遷移します。
仮想マシンが表示されていません。
これは、ユーザー testuser01 に対して [閲覧者] ロールが割り当てられていないためとなります。
リソースにアクセスできるよう ユーザー testuser01 に対して [閲覧者] ロールを割り当てます。
仮想マシンの閲覧が可能となりました。
OS ディスクのスナップショットを取得するため、対象となる OS ディスク名をクリックし、[+ スナップショットの作成] へ進みます。
スナップショット作成のための必要事項を編集し、作成を行うと以下のエラーが出力されました。
{“code”:”AuthorizationFailed”,”message”:”オブジェクト ID が ‘XXX’ のクライアント ‘testuser01@XXX’ には、スコープ ‘/subscriptions/XXXXXX/resourceGroups/rg_test/providers/Microsoft.Resources/deployments/Snapshot.snapshot01-20240103123034’ でアクション ‘Microsoft.Resources/deployments/validate/action’ を実行する認可がないか、スコープが無効です。アクセスが最近許可された場合は、資格情報を更新してください。”}
リソースのデプロイ検証に必要なアクションが不足していることが分かります。
参考)Microsoft.Resources
https://learn.microsoft.com/ja-jp/azure/role-based-access-control/resource-provider-operations#microsoftresources
アクション | 説明 |
---|---|
Microsoft.Resources/deployments/validate/action | デプロイを検証します。 |
手順 2 で作成したカスタム ロールに ‘Microsoft.Resources/deployments/validate/action’ アクションを追加します。
次は別のエラーが出力されました。
デプロイ要求を送信中にエラーが発生しました。
役立つ可能性がある基本 API から得られた追加の詳細情報: オブジェクト ID が ‘XXX’ のクライアント ‘testuser01@XXX’ には、スコープ ‘/subscriptions/XXXXX/resourceGroups/rg_test/providers/Microsoft.Resources/deployments/Snapshot.snapshot01-20240103124401’ でアクション ‘Microsoft.Resources/deployments/write’ を実行する認可がないか、スコープが無効です。アクセスが最近許可された場合は、資格情報を更新してください。
デプロイの作成に必要となるアクションが不足していることが分かります。
参考)Microsoft.Resources
https://learn.microsoft.com/ja-jp/azure/role-based-access-control/resource-provider-operations#microsoftresources
アクション | 説明 |
---|---|
Microsoft.Resources/deployments/write | デプロイを作成または更新します。 |
手順 2 で作成したカスタム ロールに ‘Microsoft.Resources/deployments/write’ アクションを追加します。
今度は、’Microsoft.Compute/disks/beginGetAccess/action’ アクションが不足しているというエラーが出力されました。
The client ‘testuser01@XXX’ with object id ‘XXX’ has permission to perform action ‘Microsoft.Compute/snapshots/write’ on scope ‘/subscriptions/XXXXX/resourcegroups/rg_test/providers/Microsoft.Compute/snapshots/snapshot01’; however, it does not have permission to perform action(s) ‘Microsoft.Compute/disks/beginGetAccess/action’ on the linked scope(s) ‘/subscriptions/XXXXX/resourceGroups/rg_test/providers/Microsoft.Compute/disks/win2022_OsDisk_1_XXX (respectively) or the linked scope(s) are invalid。詳細については、ここをクリックしてください
参考)Microsoft.Compute
https://learn.microsoft.com/ja-jp/azure/role-based-access-control/resource-provider-operations#microsoftcompute
アクション | 説明 |
---|---|
Microsoft.Compute/disks/beginGetAccess/action | BLOB へのアクセス用にディスクの SAS URI を取得します。 |
手順 2 で作成したカスタム ロールに “Microsoft.Compute/disks/beginGetAccess/action” を追加します。
ついに、スナップショットの作成に成功しました。
最終的にユーザー testuser01 に対して必要となったアクションは以下となります。
アクション | 説明 |
---|---|
*/read | 「閲覧者」ロール |
Microsoft.Compute/snapshots/write | 新しいスナップショットを作成するか、既存のスナップショットを更新します。 |
Microsoft.Resources/deployments/validate/action | デプロイを検証します。 |
Microsoft.Resources/deployments/write | デプロイを作成または更新します。 |
Microsoft.Compute/disks/beginGetAccess/action | BLOB へのアクセス用にディスクの SAS URI を取得します。 |
以上のような手順にて、トライ アンド エラーを繰り返しながら、お客様環境にて必要最小となるアクションのみを付与したロールを作成いただく形となります。
トライ アンド エラーにてカスタム ロールを作成いただく際の補足情報となりますが、ブラウザー トレース (HAR トレース、F12 トレース) をご活用いただくことで、特定の操作を行う際に必要となるリソース プロバイダー操作をある程度把握することも可能です。
既に権限を持っているユーザーにてスナップショットを作成する際に、ブラウザー トレースを取得します。
ブラウザー トレース (HAR トレース、F12 トレース) の取得手順の詳細は以下をご参照ください。
参考)ネットワーク トレースの収集方法
https://learn.microsoft.com/ja-jp/azure/azure-web-pubsub/howto-troubleshoot-network-trace
手順 1 にて生成された portal.azure.com.har という .har ファイルを開き、スナップショットを作成する際に必要となったリソース プロバイダー操作 (providers) を確認します。
以下 3 つに関するリソース プロバイダー操作が必要となることが分かります。
Microsoft.Resources/deployments
Microsoft.Compute/snapshots
Microsoft.Compute/disks
さらに細かなアクションまでを把握することは叶いませんが、カスタム ロールを作成いただく際にどのリソース プロバイダー操作が必要となるかをある程度把握することができます。
・Azure RBAC のスコープについて
Azure RBAC の付与は、管理グループ、サブスクリプション、リソース グループ、リソースいずれかのスコープに対して適用することが可能となります。
今回、サブスクリプションをスコープとしたカスタム ロールを割り当てたため、サブスクリプション内に存在する全ての仮想マシンに対して同様の操作が実施可能になります。
特定の複数の仮想マシンに対してロールを付与をしたい場合には、対象の仮想マシンが所属するリソース グループや仮想マシンひとつひとつに対して付与を行っていただくことが可能になります。
(親スコープに設定されたロールは、子スコープに継承されます)
参考)Azure RBAC のスコープについて
https://docs.microsoft.com/ja-jp/azure/role-based-access-control/scope-overview
・リソース操作を行うツールについて
Azure Portal や Azure PowerShell、Azure CLI 等のツールからリソースを操作することが可能ですが、操作を行うツールによって必要となるアクションが異なるケースがございます。このような場合は、リソース操作を行うツールにて検証を行い、必要となるアクションを取捨選択いただきますようお願い申し上げます。
]]>・RHEL のマイナーバージョンがアップデートされない
・yum/dnf update したら意図せずマイナーバージョンが上がってしまった
・脆弱性対応のためパッケージのバージョンをアップデートしたいのに、yum/dnf update しても対象のバージョンに更新されない
・パッケージをインストール / 更新しようとするとパッケージの競合などのエラーが発生する
という内容について、原因と解決方法をご紹介いたします。
結論から書いてしまうと、RHEL VM に接続されている Azure RHUI リポジトリが
非 EUS か EUS かによって発生している可能性が高いものと存じます。
RHEL VM のマイナーバージョンやパッケージのアップデートを実行する際には、
接続されているリポジトリの確認をする必要があります。
ヒント
マイナーバージョンがアップデートされない事例として、
ゲスト OS 内の /etc/dnf/dnf.conf 内に exclude=kernel* の設定がないかご確認をください。
この設定がある場合、カーネルのアップデートが除外対象となっているため、マイナーバージョンのアップデートもされません。
ここでは、非 EUS、EUS リポジトリについてご紹介します。
Azure 上の RHEL VM は、既定で Azure RHUI (Red Hat Update Infrastructure) のリポジトリサーバーに接続されています。
Azure RHUI には、非 EUS (Extend Update Support) リポジトリと EUS リポジトリ の 2 種類があります。
RHEL VM が 非 EUS リポジトリに接続されている場合に、yum/dnf update を実施した際には、その時点で提供されている
最新の RHEL マイナーバージョンにアップグレードされ、最新のパッケージを取得できることとなります。
一方で、RHEL VM が EUS リポジトリに接続されている場合、
yum/dnf update を実行した際に、更新プログラムは、
特定の RHEL マイナーバージョンを超えることはありません。
つまり、特定マイナーバージョンに固定されている状態 (マイナーバージョンロック) となります。
EUS は、ワークロードの都合上、特定のマイナーバージョンに固定して利用したいお客様向けにご利用頂けるものとなります。
EUS の詳細については、以下 Red Hat 社の公開情報にも纏められています。
□ 参考 : Red Hat Enterprise Linux (RHEL) Extended Update Support (EUS) の概要
https://access.redhat.com/ja/articles/3055941
弊社公開情報にもリポジトリについて情報をお纏めしておりますので
併せてご確認ください。
□ 参考 : Azure のオンデマンド Red Hat Enterprise Linux VM 用 Red Hat Update Infrastructure
https://learn.microsoft.com/ja-jp/azure/virtual-machines/workloads/redhat/redhat-rhui?tabs=rhel7#image-update-behavior
ご利用の RHEL VM が 非 EUS / EUS リポジトリのどちらに接続されているのか
確認する方法についてご紹介します。
yum repolist コマンドで接続されているリポジトリを確認することができます。
yum repolist all コマンドを実行すると、以下のようにリポジトリが設定されていることが確認できます。
また、以下コマンドで、releasever がどのマイナーバージョンに固定されているか確認することができます。
1 | # cat /etc/dnf/vars/releasever (RHEL 7 は、/etc/yum/vars/releasever) |
非 EUS リポジトリに接続されているときは以下のように releasever の固定もありません。
一方で、EUS リポジトリに接続されている環境では、リポジトリ名に “eus” の記載があり、
EUS リポジトリに接続されていることが確認できます。
例えば、EUS リポジトリに接続されている RHEL 8.4 の VM での
確認結果は以下のようになります。
それでは、接続しているリポジトリを変更する方法についてご紹介します。
リポジトリの変更については、以下 2 つの操作ができます。
・非 EUS から EUS リポジトリに切り替える方法 (バージョンロック)
・EUS から、非 EUS リポジトリに変更する方法 (バージョンロックの解除)
それぞれの方法について、RHEL 8 の環境を例にご紹介します。
なお、本操作はゲスト OS 内での作業となりますため、
予期せぬ問題に備えて、事前にバックアップを取得頂くことや十分な検証をすることを推奨します。
EUS リポジトリへ接続するためには以下の手順でコマンドを実行ください。
EUS 以外のリポジトリを無効にする
1 | # dnf --disablerepo='*' remove 'rhui-azure-rhel8' -y |
EUS リポジトリを追加する2 EUS リポジトリを追加する
1 | # dnf --config='https://rhelimage.blob.core.windows.net/repositories/rhui-microsoft-azure-rhel8-eus.config' install rhui-azure-rhel8-eus -y |
releaseverを固定する
EUS が提供されているバージョンを指定する必要があります。 (RHEL 8 の場合、8.1、8.2、8.4、8.6、8.8 のいずれかである必要があります)
1 | # sh -c 'echo 8.x > /etc/dnf/vars/releasever' |
EUS が提供されているバージョンは以下 Red Hat 社の公開情報からご確認ください。
□ 参考 : Red Hat Enterprise Linux (RHEL) Extended Update Support (EUS) の概要
https://access.redhat.com/ja/articles/3055941
以下の環境では、RHEL 8.4 の EUS リポジトリに接続されていることが確認できます。
この状態で dnf update をしても、マイナーバージョンは上がりません。(8.4 のまま)
また、アップデートできるパッケージは RHEL 8.4 向けのパッケージのバージョンまでしか取得できないことになります。
一例ではございますが、本記事の執筆時点で、httpd の最新バージョンは、
RHEL 8.4 に固定されている状態で、2.4.37-39 が取得できることが確認できます。
また、EUS リポジトリを特定のマイナーバージョンに固定することもできます。
以下のように releasever を固定したいバージョンに設定することが可能となります。
( x には、 EUS が提供されているバージョンを指定する必要があります)
1 | # echo 8.x > /etc/yum/vars/releasever |
以下例では、RHEL 8.4 の VM を RHEL 8.8 の EUS リポジトリに接続するよう変更しています。
この状態で、dnf update を実行し、再起動をすると RHEL 8.8 にマイナーバージョンがアップデートされます。
以下 dnf update を実施後の結果
また、パッケージは RHEL 8.8 向けのバージョンを取得することが可能となります。
httpd の場合、2.4.37-56 まで取得できることとなります。
非 EUS リポジトリへ接続するためには以下の手順でコマンドを実行ください。
releasever ファイルを削除
1 | # rm -f /etc/dnf/vars/releasever |
EUS リポジトリを無効にする
1 | # dnf --disablerepo='*' remove 'rhui-azure-rhel8-eus' -y |
非 EUS リポジトリを追加する
1 | # dnf --config='https://rhelimage.blob.core.windows.net/repositories/rhui-microsoft-azure-rhel8.config' install rhui-azure-rhel8 -y |
以下例では、RHEL 8.4 の VM を 非 EUS リポジトリに接続するよう変更しています。
この状態で dnf update をすると、その時点で提供されている最新のマイナーバージョンにアップデートされます。
dnf update を実施後の結果は以下のようになります。
各パッケージについては、RHEL 8 の最新のパッケージまで更新することが可能となります。
非 EUS リポジトリに接続することで、httpd は 2.4.37-62 のバージョンまでアップデートすることができます。
詳細な手順については、以下の公開ドキュメントにもお纏めしております。
□ 参考 : RHEL Server を EUS リポジトリに切り替えます。
https://learn.microsoft.com/ja-jp/azure/virtual-machines/workloads/redhat/redhat-rhui?tabs=rhel8#switch-a-rhel-server-to-eus-repositories
□ 参考 : RHEL Server を EUS 以外のリポジトリに切り替えます。
https://learn.microsoft.com/ja-jp/azure/virtual-machines/workloads/redhat/redhat-rhui?tabs=rhel8#switch-a-rhel-server-to-non-eus-repositories
マイナーバージョンが想定通りアップグレードできない場合や、
脆弱性対応などで、ご要望のパッケージバージョンが表示されない際には、
上記リポジトリの設定をご確認頂き、適切なリポジトリを設定頂くようご確認頂ければと思います。
ヒント
リポジトリの設定変更作業において、ゲスト OS の再起動は不要となります。
ただし、yum / dnf update によりカーネルの更新等を行った場合には、
更新を反映させるため再起動が必要となります。
再起動の必要性はパッチの適用状況によって異なるため、一概にご案内することは難しいですが、needs-restarting -r を実施することで、再起動が必要か判断することもできます。
以下の Red Hat 社の公開情報についてもご確認頂ければと思います。
□ 参考 : 更新後にシステムの再起動が必要なパッケージを特定する
https://access.redhat.com/ja/solutions/2725591
#閲覧には Red Hat 社のアカウントが必要になります。
マイナーバージョンの固定や、解除は環境に合わせて設定変更ができます。
しかしながら、以下のような場合、パッケージをインストールする際に、
関連するパッケージの依存関係の問題が発生し、
正常にインストールできないエラーが発生することがございます。
・マイナーバージョンを固定しない状態でパッケージのアップデートを行った後で、マイナーバージョンを固定した場合
・特定のマイナーバージョンに固定し、パッケージをアップデートした後に、それよりも低いマイナーバージョンに固定した場合
イメージとしては、以下の通りとなります。
EUS リポジトリでは、問題の修正のため、取得できるパッケージのバージョンが分岐されて提供されております。
インストール済みのパッケージのバージョンと、
インストール予定のパッケージのバージョンに差があることで パッケージの conflict が発生します。
一例ではございますが、本事象は以下のような手順を実施した場合に再現します。
以下の手順を実施します。
- RHEL 8.4 の VM で 非 EUS リポジトリに接続されている環境から、glibc をアップデート
- 非 EUS リポジトリから、RHEL 8.4 の EUS リポジトリに固定するよう変更
- dnf install gcc を実行する
この手順を実施した際にパッケージの conflict が発生して、正常にインストールができない事象が発生します。
エラー内容一部抜粋
1 | [root@rhel84 ~]# cat /etc/dnf/vars/releasever |
この場合、変更したマイナーバージョンへのアップデートまたは、
作業前のバックアップを取得している場合は、VM を復元頂くことを推奨いたします。
問題となっているパッケージのダウングレードや削除・再インストールで解消できる場合もありますが、
EUS の継続利用が困難になることや、
その他の予期しない問題が発生することもございますため、
再度マイナーバージョンの固定化を実施する際にはご留意ください。
Azure RHUI はRed Hat社のリポジトリとの即時の同期が実施されないため、タイミングによっては、最新バージョンのパッケージがまだ提供されてない場合もありますので、そのような場合は時間をおいて再度ご確認ください。
また、OSS のパッケージについてはその OSS が提供している最新のバージョンが RHUI では提供されていない場合もございます。
不具合に対する修正については、パッケージのバージョンが古い場合でも Red Hatでは適切にバックポートされている場合もございます。
本稿が皆様のお役に立てれば幸いです。
]]>本ブログでは、Azure Front Door 及び Microsoft Standard SKU の Azure CDN (以降は AFD と記載致します) において起こりうる接続の問題やお客様で対策可能な内容などについてご案内致します。
AFD のプラットフォーム上では、より早くより適切なルートでオリジンへトラフィックをルーティングするために、さまざまな仕組みが用いられています。その仕組みの 1 つとして、AFD のプラットフォーム上にて処理するトラフィックの流量を調整する機能が存在しております。
AFD のサービスは世界中のエッジ サーバーに分散配置されており、複数のお客様でエッジ サーバーを共有して利用するマネージド サービスです。お客様のリクエストが、どのエッジ サーバーへルーティングされるかは、AFD によって動的にコントロールされています。
また、トラフィックの流量を調整する機能が特定のエッジ サーバーで起動した場合は、そのエッジ サーバーにルーティングされた一部のクライアントに対して RST パケットを送信する動作になります。
つまり、お客様の構成した AFD にアクセスを行い、該当のエッジ サーバーにルーティングされてしまった一部のクライアントも RST パケットを受け取る可能性があります。
なお、この仕組みによって、断続的に数分から数十分程度の間、クライアントから AFD への接続に影響を及ぼす可能性があります。
TCP RST パケットを受信したクライアントが TCP レイヤー レベルで接続をリトライしない場合は、トラフィックの流量の調整が機能している間は、クライアントから AFD への接続に影響が発生してしまいます。
例えば、アプリケーション システムのフロントとして AFD を使用しており、一般ユーザーが PC 端末やスマートフォンの WEB ブラウザを用いて直接 AFD にアクセスする場合は、一時的に接続エラーになっても、WEB ブラウザにて画面を更新することによって正常に接続できる可能性があります。
一方で、API を処理するようなシステムのフロントとして AFD を使用しており、API を送信するクライアント側で TCP レイヤー レベルで再送処理を考慮していない場合は、RST パケットを受信したあとで AFD への TCP レイヤーでの再接続が実行されずに通信が失敗します。他には、Zabbix などの監視システムにおいて curl コマンドを AFD に送信している場合も同様のことが発生する可能性があります。
一時的な接続の問題をクライアントが処理できるようにするために、AFD に接続を行うクライアント サイドの動作にてリトライ ロジックやサーキット ブレークの実装をご検討ください。これにより、アプリケーション システム上の通信の安定性を向上させることに繋がります。
リトライ ロジックやサーキット ブレークの必要性や実装の概要について記載されている公開ドキュメントやブログ (英語) につきましては、下記の URL に記載がございますので、ご参考になれば幸いです。
Using the Retry pattern to make your cloud application more resilient
リトライ ロジックやサーキット ブレークを実装しているにもかかわらず、AFD への接続で遅延やタイムアウトなどの問題が、数分程度ではなく長時間にわたって事象が継続している場合は、詳細に調査を行う必要がございますので、サポート窓口までお問い合わせください。
なお、お問い合わせをいただく際には、AFD へ接続を実施している通信状況が分かるネットワーク パケットのキャプチャー ファイルとカスタム ドメインを nslookup コマンドなどで名前解決した結果をサポートまで提供いただくことにより、お客様とサポートとの間でのヒアリングをスムーズに進めることができます。
お手数をおかけいたしますが、下記の手順を参考にネットワーク パケット キャプチャー ファイルの採取及びカスタム ドメインの名前解決結果にご協力いただけますと幸いです。
【クライアントが Windows OS の場合】
1 | netsh trace start capture=yes |
1 | netsh trace stop |
【クライアントが Linux OS の場合】
1 | sudo tcpdump -s0 -i any -n -w outfile.pcap |
お手元の端末においてコマンド プロンプトなどを開き、以下のコマンドを実行します。
1 | nslookup <カスタム ドメイン名> |
もしくは
1 | dig <カスタム ドメイン名> |
また、お問い合わせをいただいた後に、担当のサポート エンジニアよりヒアリング シートへの記入をお願いする可能性もございます。その際はご協力の程よろしくお願い致します。
AFD はマネージド サービスになるため、場合によっては短期間で完全な対策を講じることができない可能性もあります。
AFD の接続の問題が長時間にわたって継続することによって、お客様のシステムに大きなサービス インパクトが懸念される場合は、お客様にて影響範囲や時間、発生パターンなどに応じてシステムを継続するための代替構成の導入をご検討をお願いする場合があります。
あくまで例としてですが、代替システムの構成例としては、以下のようなパターンがございます。
AFD に登録しているカスタム ドメインの名前解決先を AFD のエンドポイントではなく、オリジンのパブリック IP アドレスや FQDN になるように DNS レコードを更新して、AFD を経由せずに直接オリジンにアクセスします。
AFD と同じように L7 のリバース プロキシとして動作するサービスに Application Gateway がありますが、リージョン レベルでの冗長性を確保するために AFD をご利用いただいているお客様も多いかと存じます。
複数の Application Gateway を異なるリージョンにデプロイして、Traffic Manager のエンドポイントに Application Gateway パブリック IP アドレスや FQDN を登録し、AFD に登録しているカスタム ドメインの名前解決先を Traffic Manager の FQDN に変更することで、リージョン レベルでの冗長性を確保して継続稼働することが可能になります。
Traffic Manager と Application Gateway を組み合わせた構成については、下記の公開ドキュメントに記載がございますので、ご参考になれば幸いです。
Note
なお AFD とは異なり、Application Gateway ではバックエンドから取得したコンテンツをキャッシュしたり、コンテンツを圧縮してクライアントに配信することはできませんので、その点をご理解いただいたうえで、Application Gateway の使用をご検討ください。
Azure Front Door と Microsoft Standard SKU の Azure CDN は同じプラットフォーム上で動作しています。一方で、Edgio SKU の Azure CDN は Edgio 社が管理しているプラットフォーム上で動作しているため、AFD にて接続の問題が発生している間、Edgio SKU の Azure CDN にて同一の原因で接続の問題が発生することはありません。
また、AFD で使用しているカスタム ドメインを予め Edgio SKU の Azure CDN に登録いただけますので、予め Edgio SKU の Azure CDN を準備してカスタム ドメインを登録しておくことにより、AFD から Edgio SKU の Azure CDN に切り替えて継続稼働することが可能になります。
なお、Edgio SKU の Azure CDN に固定費用はなくデータ転送量による従量課金制になるため、アクセスが発生しない限りは課金されることはございません。
Azure VM はお客様に安心してご利用いただくためにセキュリティ向上の対応や機能改善等を目的として定期的に Azure 基盤側のメンテナンスを行っております。
お客様の VM に影響の発生する可能性のあるメンテナンスとして、大きく以下の 2 種類に分けられます。
■ご参考:Azure での仮想マシンのメンテナンス
https://learn.microsoft.com/ja-jp/azure/virtual-machines/maintenance-and-updates
再起動を必要とするメンテナンスについては、以下の通り Azure Portal の [サービスの正常性] で事前に確認が可能です。
■ご参考:計画メンテナンスの通知の処理
https://learn.microsoft.com/ja-jp/azure/virtual-machines/maintenance-notifications
再起動を必要としないメンテナンスについては、恐縮ながら Azure Portal での事前の確認をすることや、既定でメールの通知がされるものではございません。
そのため、「何とかして再起動を必要としないメンテナンスが発生することを事前に確認することができないか?」というお問い合わせをいただくこともございます。
後述の通り、IMDS を用いて Scheduled Events を監視することで再起動を必要としないメンテナンスを事前に確認する事が可能です。
まずは IMDS について簡単に解説させていただきます。
IMDS(Instance Metadata Service)は、現在実行中の VM に関する情報を取得できるものとなっております。
実行中の VM 内から IMDS に HTTP アクセスを行うことで、情報を取得することが可能です。
なお、同一の可用性セット内の VM もしくは同じ VMSS 内のインスタンスについても合わせて情報を取得できます。
■ご参考:Azure Instance Metadata Service
https://learn.microsoft.com/ja-jp/azure/virtual-machines/instance-metadata-service
この IMDS のエンドポイントの 1 つとして、Scheduled Events というものがございます。
これは VM の近い将来にスケジュールされている VM の再起動やメンテナンスのイベントを確認できるものとなっております。
■ご参考:Azure Metadata Service: Windows VM のScheduled Events
https://learn.microsoft.com/ja-jp/azure/virtual-machines/windows/scheduled-events
■ご参考:Azure Metadata Service: Linux VM の Scheduled Events
https://learn.microsoft.com/ja-jp/azure/virtual-machines/linux/scheduled-events
それでは、Scheduled Events の確認を実際にやってましょう。
以下のコマンドを Azure VM 上のゲスト OS 内にて実行します。
Windows の場合は PowerShell より以下のコマンドで、IMDS の Scheduled Events のエンドポイントに HTTP でアクセスします。
1 | Invoke-RestMethod -Headers @{"Metadata"="true"} -Method GET -Uri "http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01" | ConvertTo-Json -Depth 64 |
Linux の場合は以下の通り Bash で curl コマンドで、IMDS の Scheduled Events のエンドポイントに HTTP でアクセスします。
1 | curl -H Metadata:true http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01 |
実行結果として、以下の例のように直近のスケジュールされたイベントがレスポンスとして確認できます。
1 | { |
1 | { |
イベントによって何分前までには通知されるといった NotBefore の時間が違いますが、再起動を必要としないメンテナンスについては、実行される約 15 分前までにはスケジュールが設定されます。
つまり 20 分前といった場合はまだスケジュールが設定されていないために、確認が叶わない場合もございます点、ご留意ください。
すなわち、定期的に IMDS の Scheduled Events をアクセスすることで、再起動を必要としないメンテナンス実行の約 15 分前には事前にメンテナンスが発生する予定を確認することが可能です。
次のセクションではこの Scheduled Events を定期的に確認する方法についてご案内させていただきます。
Windows 環境においては、以下の通り公開ドキュメントとして、定期的に Scheduled Events を監視し、再起動を必要としないメンテナンスがスケジュールされた際にアラート通知を行うサンプルがございます。
■ご参考:Azure VM のスケジュールされたイベントを監視する
https://learn.microsoft.com/ja-jp/azure/virtual-machines/windows/scheduled-event-service
具体的な内容は実際のドキュメントをご確認いただきたく存じますが、簡単に内容を解説すると以下の通りとなります。
なお、恐縮ながら再起動を必要としないメンテナンスを疑似的に発生させて “EventType”:”Freeze” の Scheduled Events を発生させることは叶いません。
そのため、このサンプルの動作確認としては代替として再起動イベントを検知する形となっております。
上記のサンプルによって、同一の可用性セット内の VM で再起動を必要としないメンテナンスがスケジュールされた際に、自動的にメール通知を行うといったことが可能となります。
また、SchService.ps1 をご自身で拡張いただくことで、Scheduled Events を検知したら自動的に何かを実行するといったスクリプトにしていただくことも可能です。
Linux 環境においては、上記の Windows のようにアラート通知を行うといったサンプルのご用意がございませんが、定期的な Scheduled Events の監視をするサンプルが以下の通りご用意されております。
■ご参考:Azure Metadata Service: Scheduled Events Samples
https://github.com/Azure-Samples/virtual-machines-scheduled-events-discover-endpoint-for-non-vnet-vm
勿論、上記サンプル以外にも Scheduled Events へ定期的なアクセスを試みる方法を実行頂いても構いません。
以上の通り、Azure VM の再起動を必要としないメンテナンスを事前に検知する方法をご紹介させていただきました。
なお、再起動を必要としないメンテナンスを実行するタイミングをコントロールしたいといった場合は、Dedicated Host もしくは分離された仮想マシンをご利用の上、メンテナンス構成を設定いただくことで実現可能でございます。
この点については以下の公式ドキュメント等をご参照ください。
■ご参考:メンテナンス構成による VM の更新の管理
https://learn.microsoft.com/ja-jp/azure/virtual-machines/maintenance-configurations
定期的なメンテナンスは安心してお客様に Azure をご利用いただく上で必要不可欠でございます点、ご理解賜りますと幸いでございます。
]]>Azure サービスをご利用いただく中で、Azure ロールベースのアクセス制御 (RBAC) を利用し、必要な権限をユーザーに付与し、運用いただいているお客様も多いかと存じます。その中で、Azure Portal 上の NSG のサービスタグが一部しか表示されない事象があるというお問い合わせを多くいただいておりますので、その原因および回避策について本ブログでご説明いたします。
以下のように、一部のサービスタグのみしか表示されないというお問い合わせをいただいております。
結論から申し上げると、サービスタグを表示させるための、RBAC 権限が付与されていない、不足している場合、上記のような事象が発生いたします。上記のように一部のサービスタグのみしか表示されない場合、サービスタグを表示させるための、読み取りアクセス許可をユーザーに対して付与いただく必要がございます。具体的には、すべてのサービスタグを表示させるために、サブスクリプションのスコープに対して、以下の 2 つの読み取り権限を付与いただく必要がございます。
1 | "Microsoft.Network/locations/serviceTags/read" |
仮想ネットワーク サービス タグ - Virtual Network | Microsoft Learn
現在のサブスクリプションに対して、認証され、読み取りアクセス許可を持つロールを持っている必要があります。
一部のサービスタグのみしか表示されない場合、以下の手順をご確認下さい。
Azure Portal からサブスクリプションへ遷移いただき、[アクセス制御 (IAM)] > アクセスの確認 > 対象のユーザーを検索 > 割り当てられているロールを選択 > JSON から、上述の 2 つの権限、または 2 つの権限を含む権限 (e.g. “Microsoft.Network/*/read”, “*“) が付与されているかご確認下さい。
1 | "Microsoft.Network/locations/serviceTags/read" |
サブスクリプションのスコープに対して、閲覧者権限を付与したい場合、Azure Portal からサブスクリプションへ遷移いただき、[アクセス制御 (IAM)] > [+追加] > [ロールの割り当ての追加] > [閲覧者]を指定し、任意のユーザー、グループに権限を付与いただけます。
アクセス権の付与 - ロールベースのアクセス制御 | Microsoft Learn
カスタムロールをご利用いただいている場合、Azure Portal からサブスクリプションへ遷移いただき、[アクセス制御 (IAM)] > ユーザーに付与しているカスタムロールから [編集] を押下 > JSON から上記 2 つの権限を追加ください。
カスタム ロールの更新 - ロールベースのアクセス制御 | Microsoft Learn
上記設定適用後、ロールの更新には少々お時間を要しますので、一度 Azure Portal からログアウトいただき、再ログインいただいた後、サービスタグが表示されるようになるかご確認いただければと存じます。
Azure Portal の UI はサービスタグに関わらず、高頻度で改善/改修が行われているため、それに伴い、必要な権限が追加・変更になる場合がございます。そのため、カスタムロールで細かく権限を制御されている場合、Azure Portal の UI 変更にともなって、権限修正が必要になる可能性もございます。カスタムロールをご利用の場合には、お客様側でも十分に検証いただくと共に、修正が必要になる点も予めご認識いただきますようお願い申し上げます。
以上、ご参考になりましたら幸いでございます。
]]>こんにちは。Azure テクニカル サポートチームの桐井です。
Ignite 2023 で、ACR/AKS 関連の機能としてArtifact Streaming が発表されました。
本記事では、Artifact Streaming を使って ACR にあるコンテナー イメージを AKS クラスターにデプロイする様子を紹介します。
Artifact Streaming は 2023/12 現在、プレビュー機能として提供されております。
今後のアップデートにより、将来この記事で紹介した内容から変更される可能性があることを何卒ご了承ください!
ご参考) Public preview: Artifact streaming support in Azure Kubernetes Service (AKS)
https://azure.microsoft.com/ja-jp/updates/public-review-artifact-streaming-support-in-azure-kubernetes-service-aks/
コンテナー イメージは、データの実体を表す複数のレイヤー
と、イメージに含まれるレイヤーの情報をまとめたマニフェスト
によって構成されています。
通常、コンテナー化されたアプリケーションを起動するには、コンテナー イメージの Pull (ダウンロードと展開) が必要になります。
イメージの Pull では次のような処理が行われます:
このように、コンテナーの起動に至るまでには、イメージを構成するレイヤーのダウンロードと展開の処理が必要となります。
そのため、レイヤーのデータ サイズが大きい場合や、レイヤー数が多いコンテナー イメージの場合は、コンテナーが起動するまでに時間を要すことがあります。
特に、Pod のオートスケールをするシナリオでは、Pod の起動時間がオートスケールの速度に影響を与えます。
また、クラスター オートスケーラーによってノードが削減され、その後新規ノードが追加された場合には、ノード内のコンテナー イメージのキャッシュが利用できません (AKS ではノードプールの スケールダウン モードが Delete
の場合)。
新規ノードでは、コンテナー イメージのダウンロードと展開が再び必要となってしまうため、Pod の起動完了までに時間を要する要因となってしまいます。
これらの問題は、Artifact Streaming を利用することで、解決を図ることができます。
Artifact Streaming を利用すると、コンテナー イメージ全体のダウンロードと展開を待つことなく、コンテナーを開始できます。
実際に AKS クラスターへコンテナー イメージをデプロイして、Artifact Streaming によってイメージの Pull 時間が変化するかを試してみましょう。
今回の検証では、コンテナー イメージとして docker.io/jupyter/all-spark-notebook:latest
を使用します。
AKS にデプロイをする前に、まずは手元の PC でイメージの Pull を試してみます。
次のように、多数のレイヤーによって構成されているコンテナー イメージであることがわかります。
1 | docker pull docker.io/jupyter/all-spark-notebook:latest |
本記事の手順は、次のドキュメントに記載されている手順に沿っています。
ドキュメントをあわせてご参照ください。
Azure Kubernetes Service (AKS) の成果物ストリーミングを使用してイメージのプル時間を短縮する (プレビュー)
https://learn.microsoft.com/ja-jp/azure/aks/artifact-streaming
Artifact Streaming を利用するために、Azure Container Registry (ACR) のリポジトリを設定していきます。
はじめに、今回利用するコンテナーイメージを ACR にインポートします。
1 | az acr import -n {ACR_NAME} \ |
イメージのインポートが完了したら、Artifact Streaming を作成します。
作成にはしばらく時間がかかります。
1 | az acr artifact-streaming create -n {ACR_NAME} \ |
az acr artifact-streaming create
コマンドを実行すると、作成の進捗を確認するためのコマンド例が表示されます。az acr artifact-streaming operation show
コマンドで進捗が確認できます。
1 | az acr artifact-streaming operation show -n {ACR_NAME} \ |
Artifact Streaming の作成が完了したら、レジストリに存在する Artifact Streaming の一覧を確認してみましょう。az acr manifest list-referrers
コマンドに、レジストリ名とイメージ名を指定して実行します。"artifactType"
が "application/vnd.azure.artifact.streaming.v1"
となっていますね。
1 | az acr manifest list-referrers -r {ACR_NAME} \ |
続いて AKS 側の設定をします。
Artifact Streaming を利用するには、Artifact Streaming オプションを有効化した AKS ノードプールが必要になります。
az aks nodepool add
コマンドに --enable-artifact-streaming
オプションを付与して、新しいノードプールを追加します。
1 | az aks nodepool add \ |
ここでは acrtest
という名前でノードプールを追加しました。kubectl get nodes
コマンドでノードの一覧を表示すると、新しいノードが追加されていることが確認できます。
1 | kubectl get nodes |
これで ACR と AKS の準備は完了です!
準備したコンテナー イメージを AKS クラスターにデプロイして、Artifact Streaming によってイメージの Pull 時間が短縮されているか確かめてみましょう。
検証では、Artifact Streaming が無効のノードプールと、有効のノードプールのそれぞれに、同じコンテナー イメージを使用する Deployment をデプロイします。
nodeSelector
を使用して、Artifact Streaming が無効のノードプールに Pod をデプロイします。
1 | apiVersion: apps/v1 |
YAML マニフェストをクラスターにデプロイします。jupyter-79c4469c65-5cfpf
Pod が生成されました。
1 | kubectl get pods -o wide |
kubectl describe pod
コマンドの結果から、Events フィールドのメッセージを確認します。
Pulled
イベントでは、Successfully pulled image "{イメージ名}" in 1m25.27926119s
のようにメッセージが表示されています。
イメージの Pull に 1分25秒 ほど要したようです。
1 | kubectl describe pod jupyter-79c4469c65-5cfpf |
続いて Artifact Streaming を利用した場合の動作を確認してみましょう。
nodeSelector
を使用して、Artifact Streaming が有効のノードプールに Pod をデプロイします。
Pod 名やコンテナー名を変更していますが、使用するコンテナー イメージは先ほどと同じ {ACR_NAME}.azurecr.io/jupyter/all-spark-notebook:latest
です。
1 | apiVersion: apps/v1 |
YAML マニフェストをクラスターにデプロイします。jupyter-artifact-streaming-5b58c9c797-pxs4l
Pod が生成されました。デプロイ先を指定したので、acrtest
ノードプールのノードにデプロイされていますね。
1 | kubectl get pods -o wide |
kubectl describe pod
コマンドの結果から、Events フィールドのメッセージを確認します。
Pulling
イベントでは、Streaming enabled for "{イメージ名}"
のようにメッセージが表示されており、Artifact Streaming が利用されていることが確認できます。
また、Pulled
イベントでは、Successfully pulled image "{イメージ名}" in 3.442267417s
のようにメッセージが表示されています。
およそ 3.44 秒ほどでイメージ Pull が完了しました!
1 | kubectl describe pod jupyter-artifact-streaming-5b58c9c797-pxs4l |
Artifact Streaming を使わない場合では 1分25秒 ほど要したため、大幅に短縮されていますね!
az acr artifact-streaming delete
というコマンドは存在しないようです。
作成した Artifact Streaming を削除したい場合には、リポジトリに存在するイメージ自体を削除します。
イメージの削除にともない Artifact Streaming も一緒に削除されます。
1 | az acr repository delete -n {ACR_NAME} --repository jupyter/all-spark-notebook |
Artifact Streaming を使うと、なぜイメージ Pull の時間が短縮されるのでしょうか?
Artifact Streaming では、OverlayBD イメージ フォーマットというオープンソースのソリューションを利用しています。
ご参考) containerd/overlaybd
https://github.com/containerd/overlaybd
ご参考) containerd/accelerated-container-image
https://github.com/containerd/accelerated-container-image
OverlayBD は、アリババクラウドのコンテナーイメージ加速技術プロジェクト DADI で開発されました。
DADI: Alibaba Cloud’s Open-Source Accelerated Container Image Technology
https://www.alibabacloud.com/blog/dadi-alibaba-clouds-open-source-accelerated-container-image-technology_597956
OverlayBD は、コンテナー イメージのレイヤーを仮想ブロック デバイスとして提供し、オーバーレイ ファイルシステムとしてマウントします。
コンテナーは、オーバーレイ ファイルシステムを通してイメージのデータにアクセスをします。
コンテナーの起動前にイメージ全体をダウンロードや展開することなく、必要なデータのみをネットワーク経由でオンデマンドに読み込むことができます。
ネットワーク ドライブに保存されたファイルを、手元のマシンに一度ダウンロードしてから開くのではなく、SMB/CIFS でマウントして直接開く様子に似ていますね。
Pod がデプロイされたノードにログインし、df
コマンドを実行すると、出力結果の中に io.containerd.snapshotter.v1.overlaybd
の文字列が含まれていることが確認できます。
1 | root@aks-acrtest-29138108-vmss000000:/# df -h | grep overlaybd |
本記事では、Artifact Streaming の概要と、実際に AKS クラスターへコンテナーをデプロイした様子を紹介しました。
サイズの大きいコンテナー イメージを使用する Pod で起動時間を短縮したい場合に、利用を検討してみると良さそうです。
今回紹介しました Artifact Streaming が、今後の技術選定や AKS をよりご活用いただくうえでのご参考になりましたら幸いです。
Artifact Streaming は2023年12月現在、パブリック プレビューとして提供されております。ご利用いただきました際にお気づきの点やご要望などがございました際は、お気兼ねなくフィードバックいただけましたら幸いでございます。
また、AKS のご利用において、お困りの点やご不明点がありました際は、いつでも Azure サポートまでお気兼ねなくご相談ください。
最後まで読んでいただきありがとうございました!
Microsoft Azure Tech Advent Calendar 2023 は明日が最終日となります。是非ご覧くださいー!
本年は多くのお客様にお世話になりました。ありがとうございました。
来年もみなさまにとって素晴らしい年でありますように、心よりお祈り申し上げます。
こんにちは! Azure テクニカル サポート チームの川畑です。
az acr buildコマンドを用いてコンテナー イメージをビルドする際に、ACR の Firewall 機能によって失敗するお問い合わせを頂きます。
この記事では、ACR のFirewall 機能を有効にした状態で ACR の機能を用いてコンテナー イメージをビルドする方法についてご紹介します。
ACR では、お客様のコンテナー イメージなど OCI アーティファクトをより安全に管理いただくために、ACR にアクセス可能な端末を制限するためのパブリック ネットワーク アクセス機能を提供しております。
パブリック ネットワーク アクセスの設定には、次の3 種類があります。
「すべてのネットワーク」
名前の通りネットワーク レベルでの制限を実施いたしません。
そのため、インターネット経由でのアクセスを受け付けることが可能となります。
「選択されたネットワーク」
ACR の Firewall 機能を用いて、IP アドレス ベースでのアクセス制限を設けることが可能となります。
なお、ここで許可可能な IP アドレスの形式は CIDR 形式となっているため、IP アドレス レンジを許可することなども可能となります。
警告
許可可能な IP 規則は最大 100 個までとなります。
ご参考情報:パブリック IP ネットワーク ルールを構成する
警告
この設定を入れることによって、Azure Portal からリポジトリの情報を参照できなくなる 場合があります。
これは、Azure Portal を用いて ACR へアクセスしているクライアント端末の IP アドレスが許可されていないためとなります。
そのため、Azure Portal より ACR 内の情報を参照する必要がある場合には、クライアント端末のパブリック IP アドレスを許可してください。
「無効」
名前の通りパブリック IP アドレス経由でのアクセスを全て防ぐことが可能となります。
この設定だけでは、ACR にアクセス可能な端末が存在しなくなるため、あわせてプライベート エンドポイントを経由したアクセスを可能なように構成いただく必要があります。
下記ドキュメントに設定方法がまとまっておりますので、あわせてご参照ください。
ご参考情報:Azure Private Link を使用して Azure Container Registry にプライベートで接続する
https://learn.microsoft.com/ja-jp/azure/container-registry/container-registry-private-link
ACR ビルドとは、お客様のクライアント端末上ではなく、Azure が管理している各リージョンに存在する ACR 用のエージェントを用いてコンテナー イメージを作成する機能となります。
この機能を用いることで、お客様のクライアント端末にて Docker などのコンテナー ランタイムをインストールすることなく、Azure が用意しているエージェントを用いてコンテナー イメージを作成、ACR へプッシュすることが出来ます。
下記 は ACR ビルドの実行結果の一例となります。
今回の例では、 外部のコンテナー レジストリー (mcr.microsoft.com) より hello-world というコンテナー イメージを取得し、起動する Docker イメージを作成、ACR へプッシュします。
まずは、Docker イメージを作成するために Dockerfile を用意します。
1 | echo "FROM mcr.microsoft.com/hello-world" > Dockerfile |
それでは、この Dockerfile を基に ACR ビルドを使って Docker イメージの作成、ACR へプッシュを行います。
1 | az acr build --registry blogbuildtest --image buildtest/hello-world:v1 --file Dockerfile . |
しかしながら、上述の通り、ACR ビルドは Azure にて管理している各リージョンに存在する ACR 用のエージェントによってコンテナー イメージの作成、ACR へのプッシュをする機能であるため、ACR 用のエージェントからお客様の ACR へのアクセスが行われます。
このアクセスには、パブリック IP アドレスが使われているため、ACR の Firewall 機能を用いてパブリック アクセスを防がれている ACR へのアクセスが失敗することが予想されます。
試しに Azure VM を用意し、この Azure VM が利用しているパブリック IP アドレスを ACR の Firewall 機能によって許可します。
この設定の場合、Azure VM から ACR への通信は成功するため、ACR からコンテナー イメージの取得等は実行できますが、ACR ビルドは失敗します。
作成した Azure VM は以下の通りであり、割り当てられたパブリック IP アドレスは 4.xxx.xxx.xxx となります。
それでは、この IP アドレスを ACR の Firewall 機能で許可します。
では、Azure VM に SSH をして、Docker イメージを ACR から取得してみます。
1 | docker pull blogbuildtest.azurecr.io/buildtest/hello-world:v1 |
docker pull コマンドによってコンテナー イメージを ACR から取得出来ました。
次に ACR ビルドを使ってコンテナー イメージの作成をしてみます。
1 | az acr build --registry blogbuildtest --image buildtestfromvm/hello-world:v1 --file Dockerfile . |
予想通り Failed となることが確認できました。
なお、この IP アドレス 52.xxx.xxx.xxx が ACR のエージェントが利用しているパブリック IP アドレスとなり、このパブリック IP アドレスが許可されていないことから処理が失敗したことが確認できました。
前置きが長くなってしまいましたが、上述のように ACR ビルドを用いてコンテナー イメージを作成する場合、ACR の Firewall 機能によってアクセスが防がれてしまう場合があります。
この回避策としては、以下の方法が挙げられます。
パブリック ネットワーク アクセスの設定を「すべてのネットワーク」に変更する
ACR のエージェントが ACR へアクセスする際に使用しているパブリック IP アドレスが許可されていないことで本事象は発生するため、インターネットからのアクセスを全て受け付けるよう変更いただくことで事象が改善します。
ACR のエージェントが利用するパブリック IP アドレスを許可する
ACR のエージェントが利用するパブリック IP アドレスを「選択されたネットワーク」の IP 規則に追加する方法が挙げられます。
Azure では、下記サイトにて Azure の各サービスが利用する IP アドレスを公開しているため、こちらの AzureContainerRegistry.
ご参考情報:Download Azure IP Ranges and Service Tags – Public Cloud from Official Microsoft Download Center
https://www.microsoft.com/en-us/download/confirmation.aspx?id=56519
警告
ACR 含め Azure が利用するパブリック IP アドレスは動的なものであり、今後変更される可能性があります。
そのため、定期的もしくはアクセスが失敗するようになりましたら、最新の ACR のパブリック IP アドレスをご確認・更新いただく必要があります。
ACR タスクを利用する
ACR の Firewall 機能では、「信頼されたサービス」のアクセスについては別途 IP 規則を追加いただくことなく、アクセスを許可することが可能となります。
そして、この 「信頼されたサービス」に、下記ドキュメントに記載の通り ACR タスクが登録されています。
ご参考情報:信頼できるサービス
https://learn.microsoft.com/ja-jp/azure/container-registry/allow-access-trusted-services#trusted-services
ACR タスクは、ACR ビルドの制御等を行うことができ、ACR ビルド同様にコンテナー イメージの作成を行うことが可能となります。
そのため、ACR ビルドの代替方法として ACR タスクをご利用いただくことで ACR の Firewall 機能でパブリック アクセスを防いだまま ACR の機能によってコンテナー イメージを作成することが可能となります。
次のセクションにて ACR タスクを使ったコンテナー イメージの作成方法について紹介します。
上述の通り、ACR タスクでは、ACR ビルドと同様に ACR の機能を使ってコンテナー イメージを作成することが可能となります。
それでは、早速 ACR タスクを使って Firewall 機能を有効化した ACR に対してコンテナー イメージの作成、プッシュをしてみます。
なお、おおまかな手順につきましては、下記ドキュメントにて記載されています。
こちらを参考に実施してみます。
ご参考情報:例:ACR タスク
https://learn.microsoft.com/ja-jp/azure/container-registry/allow-access-trusted-services#example-acr-tasks
ACR タスクを作成する前に事前準備が必要となります。
ACR ビルドでは、コンテナー イメージの作成に使用していた Dockerfile を az acr build コマンドを実行したクライアント端末に存在していましたが、ACR タスクでは ACR のエージェントにてアクセスが可能な場所に配置する必要があります。
ここでは、Dockerfile を ACR 上に配置し、ACR 上に配置した Dockerfile を ACR タスクより使用してコンテナー イメージを作成してみます。
ACR に Dockerfile を配置するにあたり、オープン ソースにて開発がされている ORAS を使用します。
簡単な使用方法につきましては、下記ドキュメントでも紹介されておりますので、ご参考ください。
ご参考情報:Azure コンテナー レジストリを使って OCI 成果物をプッシュおよびプルする
https://learn.microsoft.com/ja-jp/azure/container-registry/container-registry-oci-artifacts
それでは、ORAS を使って Dockerfile を ACR にプッシュします。
1 | oras push blogbuildtest.azurecr.io/hello-world.dockerfile:1.0 Dockerfile |
今回は hello-world.dockerfile というリポジトリとしてプッシュしました。
では、この hello-world.dockerfile を用いるよう ACR タスクを作成してみます。
コマンドは下記のような形式となります。
1 | az acr task create -t <イメージ名> --registry <ACR 名> --name <タスク名> --context oci://<ACR 名>.azurecr.io/<Dockerfile の OCI アーティファクト名>:<Tag> --file <Dockerfile名> --assign-identity <[system] | マネージド ID のリソース ID> -g <リソース グループ名> |
今回の環境では、下記のコマンドとなります。
1 | az acr task create -t helloworld --registry blogbuildtest --name helloworldtask --context oci://blogbuildtest.azurecr.io/hello-world.dockerfile:1.0 --file hello-world.dockerfile --assign-identity [system] |
なお、「信頼されたサービス」を利用してアクセスを行う場合には、ACR タスクにマネージド ID を利用する必要があります。
先ほど実行したコマンドにて、今回作成した ACR タスクにはシステム割り当てマネージド ID を利用するよう設定しているため、このシステム割り当てマネージド ID に必要な権限 (ACRPUSH) を割り当てます。
1 | principalID=$(az acr task show --name helloworldtask --registry tasktest --query identity.principalId --output tsv -g blog) |
次に、ACR タスク “helloworldtask” に対して ACR “blogbuildtest” へのアクセスにマネージド ID を利用するよう設定を行います。
1 | az acr task credential add --name helloworldtask --registry blogbuildtest --login-server blogbuildtest.azurecr.io --use-identity [system] -g blog |
これで準備は完了です。それでは、ACR タスクを実行します。
1 | az acr task run --name helloworldtask --registry blogbuildtest -g blog Queued a run with ID: cad |
これで、Firewall を有効化している ACR に対して、ACR タスクを用いてコンテナー イメージを作成することが出来ました。
この記事では、ACR のFirewall 機能を有効にした状態で ACR の機能を用いてコンテナー イメージをビルドする方法をご紹介しました。
ご参考にいただけますと幸いです。
本稿が皆様のお役に立ちましたら幸いです。
最後まで読んでいただきありがとうございました!
]]>マネージドディスクやスナップショットを新規作成する際に、作成画面にて以下のように「ネットワーク」というタブで、ネットワーク設定をすることができます。
(作成後に、後から編集することも可能です。)
既定では、「すべてのネットワークからのパブリック アクセスを有効にする」となっておりますため、「ディスクに対し外部から不正アクセスされてしまうのでは?」というお問い合わせをいただくこともございます。
このネットワークの設定はマネージドディスクとスナップショットのエクスポート/インポートをする際に、アクセス許可をするネットワークを設定するものとなっております。
すなわち、明示的にエクスポート URL の生成を行わない場合は、パブリック上の不特定多数からディスクにアクセスされるといったことはございませんのでご安心ください。
また Azure VM から接続されているマネージドディスクへの通信に影響を及ぼす設定でもございません。
■ご参考:マネージド ディスクがインポートまたはエクスポートされる操作を制限する
https://learn.microsoft.com/ja-jp/azure/virtual-machines/disks-restrict-import-export-overview
マネージドディスクとスナップショットは以下の通り、ポータル等でエクスポート URL を発行し、VHD ファイルとしてダウンロードを行うといったことが可能です。
セキュリティ上の観点より、明示的にエクスポート URL を発行しない場合はエクスポートはできず、URL も有効期限を設ける必要がございます。
■ご参考:Azure から Windows VHD をダウンロードする
https://learn.microsoft.com/ja-jp/azure/virtual-machines/windows/download-vhd
■ご参考:Azure から Linux VHD をダウンロードする
https://learn.microsoft.com/ja-jp/azure/virtual-machines/linux/download-vhd
この際、マネージドディスクおよびスナップショットのネットワーク設定にて既定の「すべてのネットワークからのパブリック アクセスを有効にする」という設定にしている場合、エクスポート URL があればどのパブリックネットワークからも VHD のダウンロード等が可能となります。
しかしながら、万が一悪意のあるユーザーにエクスポート URL が入手されてしまった場合にも VHD ダウンロードを不可とさせるための設定として、
というオプションもご用意しているといったこととなります。
「パブリック アクセスを無効にし、プライベート アクセスを有効にする」の設定とした場合は、エクスポート URL があったとしてもパブリックネットワークからのアクセスはできず、Azure 仮想ネットワーク上のクライアントからプライベート リンクを介してでないとアクセスできないといった、よりセキュリティの高い設定となります。
この点詳細については以下の公開ドキュメントをご参照ください。
■ご参考:Azure Private Link を使用してマネージド ディスクに対するインポートおよびエクスポートのアクセスを制限する
https://learn.microsoft.com/ja-jp/azure/virtual-machines/disks-enable-private-links-for-import-export-portal
「パブリック アクセスとプライベート アクセスを無効にする」の設定にした場合は、エクスポート URL の発行自体が不可になります。
上記、エクスポートを例として記載しましたが以下のマネージドディスクに対する VHD インポートについても同じようにネットワークの制限の設定か可能です。
■ご参考:お使いの VHD をアップロードする
https://learn.microsoft.com/ja-jp/azure/virtual-machines/managed-disks-overview#upload-your-vhd
上述の通り、こちらのネットワーク設定はあくまでエクスポート/インポート時のネットワーク制限の設定を行うものである点、ご理解賜りますと幸いでございます。
]]>