Azure Kubernetes Service (AKS) でのポッドのセキュリティに関するベスト プラクティス

Azure Kubernetes Service (AKS) でアプリケーションを開発および実行する際には、ポッドのセキュリティが重要な考慮事項になります。 ご使用のアプリケーションは、必要な最小数の特権のプリンシパルを考慮して設計する必要があります。 顧客にとって最大の関心事は、プライベート データを安全に保つことです。 外部に、データベース接続文字列、キー、シークレット、証明書などの資格情報を公開しないでください。外部では、攻撃者がそれらのシークレットを悪意のある目的で利用する恐れがあります。 これらの資格情報をコードに追加したり、コンテナー イメージに埋め込んだりしないでください。 このアプローチでは、コンテナー イメージを再ビルドする必要があるので、これらの資格情報をローテーションする機能が公開および制限されるというリスクが生じます。

このベスト プラクティスの記事では、AKS でポッドをセキュリティで保護する方法について説明します。 学習内容は次のとおりです。

• ポッドのセキュリティ コンテキストを使用して、プロセスおよびサービスへのアクセス、または特権エスカレーションを制限する
• Microsoft Entra Workload ID を使って他の Azure リソースで認証する
• Azure Key Vault などのデジタル資格情報コンテナーに対して資格情報を要求して取得する

クラスター セキュリティおよびコンテナー イメージ管理に関するベスト プラクティスも参照できます。

リソースへのポッドのアクセスをセキュリティで保護する

ベスト プラクティス ガイダンス - 別のユーザーまたはグループとして実行し、基盤となるノードのプロセスおよびサービスへのアクセスを制限するには、ポッドのセキュリティ コンテキスト設定を定義します。 必要な最小数の特権を割り当てます。

アプリケーションを正常に実行するには、ルートではなく、定義済みのユーザーまたはグループとしてポッドを実行する必要があります。 ポッドまたはコンテナーに対して securityContext を使用すると、runAsUser や fsGroup などの設定を定義して適切なアクセス許可を想定することができます。 必要なユーザーまたはグループのアクセス許可のみを割り当てます。追加のアクセス許可を想定する手段としてセキュリティ コンテキストを使用しないでください。 runAsUser、権限昇格、およびその他の Linux 機能の設定は、Linux のノードとポッドでのみ使用可能です。

ルート以外のユーザーとして実行する際に、コンテナーを 1024 下の特権ポートにバインドすることはできません。 このシナリオでは、アプリが特定のポートで実行されているという事実を偽装するために Kubernetes Services を使用できます。

ポッドのセキュリティ コンテキストでは、プロセスおよびサービスにアクセスするための追加の機能またはアクセス許可も定義できます。 次の一般的なセキュリティ コンテキスト定義を設定できます。

• allowPrivilegeEscalation は、ポッドがルート特権を想定できるかどうかを定義します。 この設定が常に false に設定されるようにアプリケーションを設計します。
• Linux 機能を使用すると、ポッドに対して、基になるノード プロセスへのアクセスを許可できます。 これらの機能を割り当てる際には注意が必要です。 必要な最小数の特権を割り当ててください。 詳細については、Linux 機能に関する記事を参照してください。
• SELinux ラベルは、サービス、プロセス、およびファイル システム アクセスに対するアクセス ポリシーを定義するための Linux カーネル セキュリティ モジュールです。 ここでも、必要な最小数の特権を割り当ててください。 詳細については、Kubernetes での SELinux オプションに関する記事を参照してください。

次のポッド YAML マニフェストの例では、定義するセキュリティ コンテキスト設定を実行します。

• ユーザー ID 1000、およびグループ ID 2000 の一部として実行されるポッド
• root を使用するように特権をエスカレートできない
• Linux 機能に対して、ネットワーク インターフェイスおよびホストのリアルタイム (ハードウェア) クロックへのアクセスを許可する

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    fsGroup: 2000
  containers:
    - name: security-context-demo
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
      securityContext:
        runAsUser: 1000
        allowPrivilegeEscalation: false
        capabilities:
          add: ["NET_ADMIN", "SYS_TIME"]

クラスター オペレーターと連携して、どのようなセキュリティ コンテキスト設定が必要かを判断します。 ポッドが必要とする追加のアクセス許可およびアクセスを最小限に抑えるように、アプリケーションを設計してみてください。 クラスター オペレーターが実装できる、AppArmor および seccomp (セキュリティで保護されたコンピューティング) を使用してアクセスを制限する追加のセキュリティ機能があります。 詳細については、「リソースへのコンテナー アクセスをセキュリティで保護する」を参照してください。

資格情報の公開を制限する

ベスト プラクティス ガイダンス - アプリケーション コードで資格情報を定義しないでください。 その他のリソースへのアクセスをポッドが要求できるようにするには、Azure リソースのマネージド ID を使用します。 デジタル キーと資格情報を格納および取得するために、Azure Key Vault などのデジタル資格情報コンテナーも使用する必要があります。 ポッドで管理されている ID は、Linux のポッドおよびコンテナー イメージのみでの使用を目的としています。

アプリケーション コードで資格情報が公開されるリスクを制限するには、固定または共有の資格情報を使用しないようにします。 資格情報またはキーをコードに直接含めないでください。 これらの資格情報が公開されている場合は、アプリケーションを更新して再デプロイする必要があります。 より適切なアプローチとしては、ポッドに対して独自の ID と自己認証の方法を指定するか、またはデジタル資格情報コンテナーから資格情報を自動的に取得します。

Microsoft Entra ワークロード ID を使う

ワークロード ID は、ポッドで実行されているアプリケーションによって使用される ID であり、それをサポートする他の Azure サービス (ストレージや SQL など) に対して自身を認証できます。 Kubernetes にネイティブな機能と統合され、外部 ID プロバイダーとフェデレーションされます。 このセキュリティ モデルでは、AKS クラスターがトークン発行者として機能し、Microsoft Entra ID は OpenID Connect を使って公開署名キーを検出し、Microsoft Entra トークンと交換する前にサービス アカウント トークンの信頼性を確認します。 ワークロードでは、Azure SDK または Microsoft Authentication Library (MSAL) を使う Azure ID クライアント ライブラリを使って、ボリュームに投影されたサービス アカウント トークンを Microsoft Entra トークンと交換できます。

ワークロード ID の詳細については、お使いのアプリケーションで Microsoft Entra ワークロード ID を使うように AKS クラスターを構成する方法に関する記事を参照してください

シークレット ストア CSI ドライバーで Azure Key Vault を使用する

Microsoft Entra ワークロード ID を使うと、サポートする Azure サービスに対する認証が可能になります。 Azure リソースのマネージド ID を使用しない独自のサービスまたはアプリケーションでは、引き続き資格情報またはキーを使用して使用して認証を行うことができます。 これらの機密コンテンツを格納するには、デジタル資格情報コンテナーを使用できます。

アプリケーションで資格情報が必要な場合は、デジタル資格情報コンテナーと通信し、最新の機密コンテンツを取得してから、必要なサービスに接続します。 Azure Key Vault は、このデジタル資格情報コンテナーとして使用できます。 次の図に、ポッドのマネージド ID を使用して Azure Key Vault から資格情報を取得する際の簡略化されたワークフローを示します。

Key Vault では、資格情報、ストレージ アカウント キー、証明書などのシークレットを格納し、定期的にローテーションします。 シークレット ストア CSI ドライバーの Azure Key Vault プロバイダーを使用して、Azure Key Vault を AKS クラスターと統合できます。 シークレット ストア CSI ドライバーを使用すると、AKS クラスターで Key Vault から機密コンテンツをネイティブに取得し、要求されているポッドだけに安全に提供できます。 クラスター オペレーターと連携して、シークレット ストア CSI ドライバーを AKS worker ノードにデプロイします。 Microsoft Entra ワークロード ID を使うと、Key Vault へのアクセスを要求することや、シークレット ストア CSI ドライバーを使う場合に必要なシークレットの内容を取得することができます。

次のステップ

この記事では、ポッドをセキュリティで保護する方法について説明しました。 これらの領域のいくつかを実装する場合は、次の記事を参照してください。

• AKS で Azure リソースに Microsoft Entra ワークロード ID を使用する
• Azure Key Vault を AKS と統合する