コンテナー化されたアプリケーションをデプロイするときは、通常、暗号化されたセキュリティで保護された通信に HTTPS プロトコルを使用します。 セキュリティで保護された通信はトランスポート層セキュリティ (TLS) によって実装されます。これは、Secure Sockets Layer (SSL) を使用した以前の方法に代わる方法です。
[前提条件]
- Docker Desktop または Podman Desktop。
- Visual Studio、または Podman サポートの場合は、ASP.NET と Web 開発、Azure 開発ワークロード、.NET デスクトップ開発ワークロードがインストールされた Visual Studio 2026。
[前提条件]
- Docker Desktop。
- ASP.NET と Web 開発、Azure 開発ワークロード、.NET デスクトップ開発ワークロードがインストールされている Visual Studio。
Devtest 証明書
開発中、Visual Studio では自己署名証明書 ( devtest 証明書とも呼ばれます) が使用されます。 ローカル コンピューターでアプリケーションを初めて起動するときに、証明書を信頼するように求めるメッセージが表示されます。 これは開発とテストで許容されますが、Azure にデプロイしてカスタム ドメインでアプリケーションを公開する場合は、証明機関 (CA) によって発行された証明書 (Azure またはサード パーティの CA) に切り替える必要があります。
Azure でのデプロイ オプションのセキュリティ
多くの Azure サービスでは、証明書の管理を自動的に処理することで、構成と管理の負担が簡素化されます。 Azure のコンテナーの TLS を設定するための構成と手順は、デプロイするサービスによって異なります。
一般に、Azure サービスでは、証明書を取得して格納する複数の方法をサポートできます。 Azure 独自の証明機関 (CA) から信頼できる証明書を取得することも、サード パーティ CA によって発行されたプライベート信頼された証明書をアップロードすることもできます。 サービス独自の証明書ストアを使用することも、Azure Key Vault を使用して他のシークレットと共に証明書を格納することもできます。
次の表に、サービスを示し、これらのサービスにデプロイするときの HTTPS セキュリティのしくみと、証明書を管理するためのハウツー ガイドを示すリンクを示します。
| Azure サービス | 注記 |
|---|---|
| Azure App Service | Azure App Service は、1 つのコンテナーに適したデプロイ サービスであり、既定のエクスペリエンスを提供します。つまり、追加のオーバーヘッドなしで、Azure によって提供される信頼された証明書を使用してセキュリティで保護されたエンドポイントを取得できます。 より詳細な制御を行うには、証明書を取得して格納するための複数のオプションから選択できます。 Azure によって提供される既定の信頼された証明書ではなく、サードパーティ CA から取得した独自の信頼された証明書を使用できます。 必要に応じて、Azure Key Vault に証明書を格納できます。 App Service TLS の概要を参照してください。 |
| Azure Container Apps | Azure Container Apps は、1 つ以上のコンテナーを使用するコンテナー化されたアプリに適したホスティング サービスです。 Azure App Service と同様に、信頼された Azure が提供する証明書を自動的に使用する既定のエクスペリエンスが提供されますが、さまざまなシナリオをサポートするためのさまざまなネットワーク アーキテクチャ オプションも提供されます。 「Azure Container Apps でのネットワーク」を参照してください。 |
| Azure Container Instances | Azure Container Instances でホストされているコンテナーの HTTPS パブリック エンドポイントを構成するには、「 サイドカー コンテナーで TLS エンドポイントを有効にする」を参照してください。 このオプションは、コンテナー自体への影響を最小限に抑えます。 |
| Azure Kubernetes Service (AKS) | クラスターへのイングレス用に TLS を設定する方法については、AKS ドキュメントの ガイダンス を参照してください。 AKS には、最大限の柔軟性を備えた証明書のローテーションと更新を処理する、最も高度な管理機能が用意されています。 |
| Azure サービス | 注記 |
|---|---|
| Azure App Service | Azure App Service は、1 つのコンテナーに適したデプロイ サービスであり、既定のエクスペリエンスを提供します。つまり、追加のオーバーヘッドなしで、Azure によって提供される信頼された証明書を使用してセキュリティで保護されたエンドポイントを取得できます。 より詳細な制御を行うには、証明書を取得して格納するための複数のオプションから選択できます。 Azure によって提供される既定の信頼された証明書ではなく、サードパーティ CA から取得した独自の信頼された証明書を使用できます。 必要に応じて、Azure Key Vault に証明書を格納できます。 App Service TLS の概要を参照してください。 |
| Azure Container Apps | Azure Container Apps は、1 つ以上のコンテナーを使用するコンテナー化されたアプリに適したホスティング サービスです。 Azure App Service と同様に、信頼された Azure が提供する証明書を自動的に使用する既定のエクスペリエンスが提供されますが、さまざまなシナリオをサポートするためのさまざまなネットワーク アーキテクチャ オプションも提供されます。 「Azure Container Apps でのネットワーク」を参照してください。 |
| Azure Container Instances | Azure Container Instances でホストされているコンテナーの HTTPS パブリック エンドポイントを構成するには、「 サイドカー コンテナーで TLS エンドポイントを有効にする」を参照してください。 このオプションは、コンテナー自体への影響を最小限に抑えます。 |
| Service Fabric | Service Fabric のアプリケーションとサービスのセキュリティに関する説明を参照してください。 通常、受信要求のセキュリティを処理するようにリバース プロキシを設定します。 Azure Service Fabric のリバース プロキシを参照してください。 |
| Azure Kubernetes Service (AKS) | クラスターへのイングレス用に TLS を設定する方法については、AKS ドキュメントの ガイダンス を参照してください。 AKS には、最大限の柔軟性を備えた証明書のローテーションと更新を処理する、最も高度な管理機能が用意されています。 |
複数のコンテナーのネットワーク セキュリティ オプション
シナリオに複数のコンテナーが含まれている場合は、イングレス トラフィックのみをセキュリティで保護するか (つまり、外部に接続するロード バランサーまたはリバース プロキシ)、またはアプリケーション内のすべてのコンテナー間にセキュリティで保護された通信を適用することができます。 後者のオプションは、外部レイヤーに違反がある場合でも、システムのより深い層にセキュリティを提供します。 コンテナー間のすべての通信に HTTPS を使用することは、この記事の範囲外です。
Azure Container Apps の場合、外部の呼び出し元に HTTPS を使用するイングレスを構成し、複数のコンテナーのネットワーク内で HTTP または TCP を使用できます。 コンテナー間の安全な通信には、mTLS (相互 TLS) を使用できます。これには、要求、クライアント、サーバー、またはマイクロサービス間の両方の証明書が必要です。 「Azure Container Apps でのイングレス」と「Azure Container Apps でのクライアント証明書認証の構成」を参照してください。