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

Azure Kubernetes Service (AKS) でアプリケーションを開発および実行する際には、ポッドのセキュリティが重要な考慮事項になります。As you develop and run applications in Azure Kubernetes Service (AKS), the security of your pods is a key consideration. ご使用のアプリケーションは、必要な最小数の特権のプリンシパルを考慮して設計する必要があります。Your applications should be designed for the principle of least number of privileges required. 顧客にとって最大の関心事は、プライベート データを安全に保つことです。Keeping private data secure is top of mind for customers. 外部に、データベース接続文字列、キー、シークレット、証明書などの資格情報を公開しないでください。外部では、攻撃者がそれらのシークレットを悪意のある目的で利用する恐れがあります。You don't want credentials like database connection strings, keys, or secrets and certificates exposed to the outside world where an attacker could take advantage of those secrets for malicious purposes. これらの資格情報をコードに追加したり、コンテナー イメージに埋め込んだりしないでください。Don't add them to your code or embed them in your container images. このアプローチでは、コンテナー イメージを再ビルドする必要があるので、これらの資格情報をローテーションする機能が公開および制限されるというリスクが生じます。This approach would create a risk for exposure and limit the ability to rotate those credentials as the container images will need to be rebuilt.

このベスト プラクティスの記事では、AKS でポッドをセキュリティで保護する方法について説明します。This best practices article focuses on how secure pods in AKS. 学習内容は次のとおりです。You learn how to:

  • ポッドのセキュリティ コンテキストを使用して、プロセスおよびサービスへのアクセス、または特権エスカレーションを制限するUse pod security context to limit access to processes and services or privilege escalation
  • ポッドのマネージド ID を使用して他の Azure リソースとの認証を行うAuthenticate with other Azure resources using pod managed identities
  • Azure Key Vault などのデジタル資格情報コンテナーに対して資格情報を要求して取得するRequest and retrieve credentials from a digital vault such as Azure Key Vault

クラスター セキュリティおよびコンテナー イメージ管理に関するベスト プラクティスも参照できます。You can also read the best practices for cluster security and for container image management.

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

ベスト プラクティス ガイダンス - 別のユーザーまたはグループとして実行し、基盤となるノードのプロセスおよびサービスへのアクセスを制限するには、ポッドのセキュリティ コンテキスト設定を定義します。Best practice guidance - To run as a different user or group and limit access to the underlying node processes and services, define pod security context settings. 必要な最小数の特権を割り当てます。Assign the least number of privileges required.

アプリケーションを正常に実行するには、ルートではなく、定義済みのユーザーまたはグループとしてポッドを実行する必要があります。For your applications to run correctly, pods should run as a defined user or group and not as root. ポッドまたはコンテナーに対して securityContext を使用すると、runAsUserfsGroup などの設定を定義して適切なアクセス許可を想定することができます。The securityContext for a pod or container lets you define settings such as runAsUser or fsGroup to assume the appropriate permissions. 必要なユーザーまたはグループのアクセス許可のみを割り当てます。追加のアクセス許可を想定する手段としてセキュリティ コンテキストを使用しないでください。Only assign the required user or group permissions, and don't use the security context as a means to assume additional permissions. runAsUser、権限昇格、およびその他の Linux 機能の設定は、Linux のノードとポッドでのみ使用可能です。The runAsUser, privilege escalation, and other Linux capabilities settings are only available on Linux nodes and pods.

ルート以外のユーザーとして実行する際に、コンテナーを 1024 下の特権ポートにバインドすることはできません。When you run as a non-root user, containers cannot bind to the privileged ports under 1024. このシナリオでは、アプリが特定のポートで実行されているという事実を偽装するために Kubernetes Services を使用できます。In this scenario, Kubernetes Services can be used to disguise the fact that an app is running on a particular port.

ポッドのセキュリティ コンテキストでは、プロセスおよびサービスにアクセスするための追加の機能またはアクセス許可も定義できます。A pod security context can also define additional capabilities or permissions for accessing processes and services. 次の一般的なセキュリティ コンテキスト定義を設定できます。The following common security context definitions can be set:

  • allowPrivilegeEscalation は、ポッドがルート特権を想定できるかどうかを定義します。allowPrivilegeEscalation defines if the pod can assume root privileges. この設定が常に false に設定されるようにアプリケーションを設計します。Design your applications so this setting is always set to false.
  • Linux 機能を使用すると、ポッドに対して、基になるノード プロセスへのアクセスを許可できます。Linux capabilities let the pod access underlying node processes. これらの機能を割り当てる際には注意が必要です。Take care with assigning these capabilities. 必要な最小数の特権を割り当ててください。Assign the least number of privileges needed. 詳細については、Linux 機能に関する記事を参照してください。For more information, see Linux capabilities.
  • SELinux ラベルは、サービス、プロセス、およびファイル システム アクセスに対するアクセス ポリシーを定義するための Linux カーネル セキュリティ モジュールです。SELinux labels is a Linux kernel security module that lets you define access policies for services, processes, and filesystem access. ここでも、必要な最小数の特権を割り当ててください。Again, assign the least number of privileges needed. 詳細については、Kubernetes での SELinux オプションに関する記事を参照してください。For more information, see SELinux options in Kubernetes

次のポッド YAML マニフェストの例では、定義するセキュリティ コンテキスト設定を実行します。The following example pod YAML manifest sets security context settings to define:

  • ユーザー ID 1000、およびグループ ID 2000 の一部として実行されるポッドPod runs as user ID 1000 and part of group ID 2000
  • root を使用するように特権をエスカレートできないCan't escalate privileges to use root
  • Linux 機能に対して、ネットワーク インターフェイスおよびホストのリアルタイム (ハードウェア) クロックへのアクセスを許可するAllows Linux capabilities to access network interfaces and the host's real-time (hardware) clock
apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  containers:
    - name: security-context-demo
      image: nginx:1.15.5
    securityContext:
      runAsUser: 1000
      fsGroup: 2000
      allowPrivilegeEscalation: false
      capabilities:
        add: ["NET_ADMIN", "SYS_TIME"]

クラスター オペレーターと連携して、どのようなセキュリティ コンテキスト設定が必要かを判断します。Work with your cluster operator to determine what security context settings you need. ポッドが必要とする追加のアクセス許可およびアクセスを最小限に抑えるように、アプリケーションを設計してみてください。Try to design your applications to minimize additional permissions and access the pod requires. クラスター オペレーターが実装できる、AppArmor および seccomp (セキュリティで保護されたコンピューティング) を使用してアクセスを制限する追加のセキュリティ機能があります。There are additional security features to limit access using AppArmor and seccomp (secure computing) that can be implemented by cluster operators. 詳細については、リソースへのコンテナーのアクセスをセキュリティで保護する方法に関する記事を参照してください。For more information, see Secure container access to resources.

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

ベスト プラクティス ガイダンス - アプリケーション コードで資格情報を定義しないでください。Best practice guidance - Don't define credentials in your application code. その他のリソースへのアクセスをポッドが要求できるようにするには、Azure リソースのマネージド ID を使用します。Use managed identities for Azure resources to let your pod request access to other resources. デジタル キーと資格情報を格納および取得するために、Azure Key Vault などのデジタル資格情報コンテナーも使用する必要があります。A digital vault, such as Azure Key Vault, should also be used to store and retrieve digital keys and credentials. ポッドで管理されている ID は、Linux のポッドおよびコンテナー イメージのみでの使用を目的としています。Pod managed identities is intended for use with Linux pods and container images only.

アプリケーション コードで資格情報が公開されるリスクを制限するには、固定または共有の資格情報を使用しないようにします。To limit the risk of credentials being exposed in your application code, avoid the use of fixed or shared credentials. 資格情報またはキーをコードに直接含めないでください。Credentials or keys shouldn't be included directly in your code. これらの資格情報が公開されている場合は、アプリケーションを更新して再デプロイする必要があります。If these credentials are exposed, the application needs to be updated and redeployed. より適切なアプローチとしては、ポッドに対して独自の ID と自己認証の方法を指定するか、またはデジタル資格情報コンテナーから資格情報を自動的に取得します。A better approach is to give pods their own identity and way to authenticate themselves, or automatically retrieve credentials from a digital vault.

次の関連付けられた AKS オープン ソース プロジェクトを使用すると、ポッドを自動的に認証するか、デジタル資格情報コンテナーから資格情報とキーを要求することができます。The following associated AKS open source projects let you automatically authenticate pods or request credentials and keys from a digital vault:

  • Azure リソースのマネージド IDManaged identities for Azure resources, and
  • Azure Key Vault FlexVol ドライバーAzure Key Vault FlexVol driver

関連付けられた AKS オープン ソース プロジェクトは Azure テクニカル サポートではサポートされません。Associated AKS open source projects are not supported by Azure technical support. これらは、コミュニティからフィードバックやバグを収集するために提供されています。They are provided to gather feedback and bugs from our community. これらのプロジェクトを運用環境で使用することはお勧めできません。These projects are not recommended for production use.

ポッドのマネージド ID を使用するUse pod managed identities

Azure リソースのマネージド ID を使用すると、ポッドは、Storage や SQL など、この機能をサポートする Azure 内の任意のサービスに対して自己認証を行うことができます。A managed identity for Azure resources lets a pod authenticate itself against any service in Azure that supports it such as Storage, SQL. ポッドには、Azure Active Directory に対して自己認証を行い、デジタル トークンを受信するために、Azure ID が割り当てられます。The pod is assigned an Azure Identity that lets them authenticate to Azure Active Directory and receive a digital token. このデジタル トークンを他の Azure サービスに提示すると、これらのサービスは、ポッドにそのサービスへのアクセス権が付与されているかどうかを確認し、必要なアクションを実行します。This digital token can be presented to other Azure services that check if the pod is authorized to access the service and perform the required actions. つまり、このアプローチでは、(たとえばデータベース接続文字列用に) シークレットは何も必要ありません。This approach means that no secrets are required for database connection strings, for example. 次の図に、ポッドのマネージド ID の簡略化されたワークフローを示します。The simplified workflow for pod managed identity is shown in the following diagram:

Azure でのポッドのマネージド ID の簡略化されたワークフロー

マネージド ID を使用すると、Azure Storage などのサービスにアクセスするためにアプリケーション コードに資格情報を含める必要はありません。With a managed identity, your application code doesn't need to include credentials to access a service, such as Azure Storage. 各ポッドが自己の ID で認証を行うので、アクセスを監査および確認できます。As each pod authenticates with its own identity, so you can audit and review access. アプリケーションが他の Azure サービスに接続する場合は、マネージド ID を使用して、資格情報の再利用と公開のリスクを制限します。If your application connects with other Azure services, use managed identities to limit credential reuse and risk of exposure.

ポッドの ID の詳細については、お使いのアプリケーションでポッドのマネージド ID を使用するよう AKS クラスターを構成する方法に関するページを参照してくださいFor more information about pod identities, see Configure an AKS cluster to use pod managed identities and with your applications

FlexVol と共に Azure Key Vault を使用するUse Azure Key Vault with FlexVol

ポッドのマネージド ID は、サポートされる Azure サービスに対する認証において的確に動作します。Managed pod identities work great to authenticate against supporting Azure services. Azure リソースのマネージド ID を使用しない独自のサービスまたはアプリケーションでは、引き続き資格情報またはキーを使用して使用して認証を行います。For your own services or applications without managed identities for Azure resources, you still authenticate using credentials or keys. これらの資格情報を格納するには、デジタル資格情報コンテナーを使用できます。A digital vault can be used to store these credentials.

アプリケーションが資格情報を必要とする場合は、デジタル資格情報コンテナーと通信し、最新の資格情報を取得してから、必要なサービスに接続します。When applications need a credential, they communicate with the digital vault, retrieve the latest credentials, and then connect to the required service. Azure Key Vault は、このデジタル資格情報コンテナーとして使用できます。Azure Key Vault can be this digital vault. 次の図に、ポッドのマネージド ID を使用して Azure Key Vault から資格情報を取得する際の簡略化されたワークフローを示します。The simplified workflow for retrieving a credential from Azure Key Vault using pod managed identities is shown in the following diagram:

ポッドのマネージド ID を使用して Key Vault から資格情報を取得する際の簡略化されたワークフロー

Key Vault では、資格情報、ストレージ アカウント キー、証明書などのシークレットを格納し、定期的にローテーションします。With Key Vault, you store and regularly rotate secrets such as credentials, storage account keys, or certificates. FlexVolume を使用して、Azure Key Vault を AKS クラスターと統合できます。You can integrate Azure Key Vault with an AKS cluster using a FlexVolume. FlexVolume ドライバーを使用すると、AKS クラスターは、Key Vault からネイティブに資格情報を取得し、要求元のポッドにのみ安全に提供することができます。The FlexVolume driver lets the AKS cluster natively retrieve credentials from Key Vault and securely provide them only to the requesting pod. クラスター オペレーターと連携して、AKS ノードに Key Vault FlexVol ドライバーをデプロイしてください。Work with your cluster operator to deploy the Key Vault FlexVol driver onto the AKS nodes. ポッドのマネージド ID を使用して、Key Vault へのアクセスを要求し、FlexVolume ドライバーを介して必要な資格情報を取得することができます。You can use a pod managed identity to request access to Key Vault and retrieve the credentials you need through the FlexVolume driver.

Flex Vol を備えた Azure Key Vault は、Linux のポッドおよびノードで実行されているアプリケーションとサービスでの使用を目的としています。Azure Key Vault with FlexVol is intended for use with applications and services running on Linux pods and nodes.

次の手順Next steps

この記事では、ポッドをセキュリティで保護する方法について説明しました。This article focused on how to secure your pods. これらの領域のいくつかを実装する場合は、次の記事を参照してください。To implement some of these areas, see the following articles: