Azure Kubernetes Service (AKS) でのアプリケーションとクラスターに対するセキュリティの概念Security concepts for applications and clusters in Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) でアプリケーション ワークロードを実行する場合に顧客データを保護するためには、クラスターのセキュリティが重要な考慮事項です。To protect your customer data as you run application workloads in Azure Kubernetes Service (AKS), the security of your cluster is a key consideration. Kubernetes には、ネットワーク ポリシーシークレットなどのセキュリティ コンポーネントが含まれています。Kubernetes includes security components such as network policies and Secrets. ネットワーク セキュリティ グループや調整されたクラスターのアップグレードなどのコンポーネントは、Azure で後で追加されます。Azure then adds in components such as network security groups and orchestrated cluster upgrades. これらのセキュリティ コンポーネントを組み合わせることで、AKS クラスターでは常に最新の OS セキュリティ更新プログラムと Kubernetes リリースが実行され、ポッドのトラフィックと機密の資格情報へのアクセスがセキュリティで保護されます。These security components are combined to keep your AKS cluster running the latest OS security updates and Kubernetes releases, and with secure pod traffic and access to sensitive credentials.

この記事では、AKS 内でアプリケーションをセキュリティで保護する主要な概念について説明します。This article introduces the core concepts that secure your applications in AKS:

マスターのセキュリティMaster security

AKS では、Kubernetes マスター コンポーネントは、Microsoft で提供されているマネージド サービスの一部です。In AKS, the Kubernetes master components are part of the managed service provided by Microsoft. 各 AKS クラスターには、API サーバーやスケジューラなどを提供する独自シングル テナントの専用 Kubernetes マスターがあります。このマスターの管理と保守は、Microsoft によって行われます。Each AKS cluster has its own single-tenanted, dedicated Kubernetes master to provide the API Server, Scheduler, etc. This master is managed and maintained by Microsoft.

既定では、Kubernetes API サーバーは、パブリック IP アドレスと完全修飾ドメイン名 (FQDN) を使用します。By default, the Kubernetes API server uses a public IP address and a fully qualified domain name (FQDN). 許可された IP 範囲を使用して、API サーバー エンドポイントへのアクセスを制限できます。You can limit access to the API server endpoint using authorized IP ranges. また、フル プライベート クラスターを作成して、API サーバーから仮想ネットワークへのアクセスを制限することもできます。You can also create a fully private cluster to limit API server access to your virtual network.

API サーバーへのアクセスは、Kubernetes のロールベースのアクセス制御 (RBAC) と Azure Active Directory を使って制御できます。You can control access to the API server using Kubernetes role-based access control (RBAC) and Azure Active Directory. 詳細については、Azure AD と AKS の統合に関するページを参照してください。For more information, see Azure AD integration with AKS.

ノードのセキュリティNode security

AKS ノードは、ユーザーが管理および保守する Azure 仮想マシンです。AKS nodes are Azure virtual machines that you manage and maintain. Linux ノードは、Moby コンテナー ランタイムを使用して、最適化された Ubuntu ディストリビューションを実行します。Linux nodes run an optimized Ubuntu distribution using the Moby container runtime. Windows Server ノードは、最適化された Windows Server 2019 リリースを実行し、同様に Moby コンテナー ランタイムを使用します。Windows Server nodes run an optimized Windows Server 2019 release and also use the Moby container runtime. AKS クラスターを作成またはスケールアップすると、ノードは自動的に、最新の OS セキュリティ更新プログラムと構成でデプロイされます。When an AKS cluster is created or scaled up, the nodes are automatically deployed with the latest OS security updates and configurations.

Azure プラットフォームでは、OS セキュリティ修正プログラムが夜間スケジュールで Linux ノードに自動的に適用されます。The Azure platform automatically applies OS security patches to Linux nodes on a nightly basis. Linux OS セキュリティ更新プログラムがホストの再起動を必要とする場合、再起動は自動的には実行されません。If a Linux OS security update requires a host reboot, that reboot is not automatically performed. Linux ノードは手動で再起動できますが、一般的な方法は Kured (Kubernetes 用のオープン ソースの再起動デーモン) を使用する方法です。You can manually reboot the Linux nodes, or a common approach is to use Kured, an open-source reboot daemon for Kubernetes. Kured は DaemonSet として実行され、再起動が必要であることを示すファイルの存在を各ノードで監視します。Kured runs as a DaemonSet and monitors each node for the presence of a file indicating that a reboot is required. 再起動は、クラスター アップグレードと同じ切断およびドレイン プロセスを使用するクラスターで管理されます。Reboots are managed across the cluster using the same cordon and drain process as a cluster upgrade.

Windows Server ノードでは、Windows Update が自動的に実行されたり、最新の更新プログラムが適用されたりすることはありません。For Windows Server nodes, Windows Update does not automatically run and apply the latest updates. Windows Update のリリース サイクルと独自の検証プロセス周辺の定期的スケジュールで、AKS クラスター内の Windows Server ノード プールでアップグレードを実行する必要があります。On a regular schedule around the Windows Update release cycle and your own validation process, you should perform an upgrade on the Windows Server node pool(s) in your AKS cluster. このアップグレード プロセスでは、最新の Windows Server イメージと修正プログラムを実行するノードが作成されて、古いノードが削除されます。This upgrade process creates nodes that run the latest Windows Server image and patches, then removes the older nodes. このプロセスの詳細については、AKS でのノード プールのアップグレードに関するページを参照してください。For more information on this process, see Upgrade a node pool in AKS.

ノードは、パブリック IP アドレスが割り当てられていないプライベート仮想ネットワーク サブネットにデプロイされます。Nodes are deployed into a private virtual network subnet, with no public IP addresses assigned. トラブルシューティングと管理のために、既定では SSH が有効になっています。For troubleshooting and management purposes, SSH is enabled by default. この SSH アクセスは、内部 IP アドレスでのみ使用できるようにします。This SSH access is only available using the internal IP address.

ストレージを提供するために、ノードは Azure Managed Disks を使用します。To provide storage, the nodes use Azure Managed Disks. ほとんどの VM ノードのサイズでは、これらは高パフォーマンスの SSD によってサポートされる Premium ディスクです。For most VM node sizes, these are Premium disks backed by high-performance SSDs. マネージド ディスクに格納されたデータは、Azure プラットフォームへの保存時に自動的に暗号化されます。The data stored on managed disks is automatically encrypted at rest within the Azure platform. 冗長性を高めるためには、これらのディスクも Azure データ センター内で安全にレプリケートされます。To improve redundancy, these disks are also securely replicated within the Azure datacenter.

現在、AKS またはその他の場所にある Kubernetes 環境は、悪意のあるマルチテナント使用に対して完全に安全ではありません。Kubernetes environments, in AKS or elsewhere, currently aren't completely safe for hostile multi-tenant usage. ノードに対して Pod Security Policy やより高度なロールベースのアクセス制御 (RBAC) などの追加のセキュリティ機能を使用すると、セキュリティ上の弱点を悪用されにくくなります。Additional security features like Pod Security Policies, or more fine-grained role-based access control (RBAC) for nodes, make exploits more difficult. ただし、悪意のあるマルチテナント ワークロードの実行に対して真のセキュリティを実現するために信頼できる唯一のセキュリティ レベルはハイパーバイザーです。However, for true security when running hostile multi-tenant workloads, a hypervisor is the only level of security that you should trust. Kubernetes 用のセキュリティ ドメインは、個々のノードではなく、クラスター全体になります。The security domain for Kubernetes becomes the entire cluster, not an individual node. この種の悪意のあるマルチテナント ワークロードでは、物理的に分離されたクラスターを使用する必要があります。For these types of hostile multi-tenant workloads, you should use physically isolated clusters. ワークロードを分離する方法については、「AKS でのクラスターの分離に関するベスト プラクティス」を参照してください。For more information on ways to isolate workloads, see Best practices for cluster isolation in AKS.

コンピューティングの分離Compute isolation

特定のワークロードでは、コンプライアンスや規制上の要件により、他の顧客のワークロードからの高いレベルの分離が必要になる場合があります。Certain workloads may require a high degree of isolation from other customer workloads due to compliance or regulatory requirements. これらのワークロードの場合、Azure は、AKS クラスター内のエージェント ノードとして使用できる分離された仮想マシンを提供します。For these workloads, Azure provides isolated virtual machines, which can be used as the agent nodes in an AKS cluster. これらの分離された仮想マシンは、特定のハードウェアの種類に分離され、単一顧客専用です。These isolated virtual machines are isolated to a specific hardware type and dedicated to a single customer.

これらの分離された仮想マシンを AKS クラスターで使用するには、AKS クラスターを作成するとき、またはノード プールを追加するときに、 [ノード サイズ] としてこちらに示されている分離された仮想マシンのサイズのいずれかを選択します。To use these isolated virtual machines with an AKS cluster, select one of the isolated virtual machines sizes listed here as the Node size when creating an AKS cluster or adding a node pool.

クラスターのアップグレードCluster upgrades

セキュリティとコンプライアンスのため、または最新の機能を使用するために、Azure には、AKS クラスターとコンポーネントのアップグレードを調整するためのツールが用意されています。For security and compliance, or to use the latest features, Azure provides tools to orchestrate the upgrade of an AKS cluster and components. このアップグレードの調整には、Kubernetes のマスターとエージェントの両方のコンポーネントが含まれます。This upgrade orchestration includes both the Kubernetes master and agent components. AKS クラスターで使用可能な Kubernetes バージョンの一覧を表示できます。You can view a list of available Kubernetes versions for your AKS cluster. アップグレード プロセスを開始するには、これらの使用可能なバージョンのいずれかを指定します。To start the upgrade process, you specify one of these available versions. その後、Azure が各 AKS ノードを安全に切断およびドレインし、アップグレードを実行します。Azure then safely cordons and drains each AKS node and performs the upgrade.

切断およびドレインCordon and drain

アップグレード プロセス中、AKS ノードはクラスターから個別に切断されるため、それらには新しいポッドはスケジュールされません。During the upgrade process, AKS nodes are individually cordoned from the cluster so new pods aren't scheduled on them. ノードはその後でドレインされ、次のようにアップグレードされます。The nodes are then drained and upgraded as follows:

  • 新しいノードは、ノード プールにデプロイされます。A new node is deployed into the node pool. このノードは、最新の OS イメージと修正プログラムを実行します。This node runs the latest OS image and patches.
  • 既存のノードのいずれかで、アップグレードが識別されます。One of the existing nodes is identified for upgrade. このノード上のポッドは適切に終了されて、ノード プール内の他のノードにケジュールされます。Pods on this node are gracefully terminated and scheduled on the other nodes in the node pool.
  • この既存のノードは、AKS クラスターから削除されます。This existing node is deleted from the AKS cluster.
  • アップグレード プロセスの一部としてすべてのノードが正常に置き換えられるまで、同じプロセスを使用してクラスター内の次のノードが切断されてドレインされます。The next node in the cluster is cordoned and drained using the same process until all nodes are successfully replaced as part of the upgrade process.

詳細については、「AKS クラスターのアップグレード」を参照してください。For more information, see Upgrade an AKS cluster.

ネットワークのセキュリティNetwork security

オンプレミス ネットワークの接続とセキュリティのために、既存の Azure 仮想ネットワーク サブネットに AKS クラスターをデプロイすることができます。For connectivity and security with on-premises networks, you can deploy your AKS cluster into existing Azure virtual network subnets. これらの仮想ネットワークには、オンプレミス ネットワークへの Azure サイト間 VPN または Express Route 接続がある場合があります。These virtual networks may have an Azure Site-to-Site VPN or Express Route connection back to your on-premises network. Kubernetes イングレス コントローラーはプライベートの内部 IP アドレスで定義できるため、サービスはこの内部のネットワーク接続経由でのみアクセスすることができます。Kubernetes ingress controllers can be defined with private, internal IP addresses so services are only accessible over this internal network connection.

Azure ネットワーク セキュリティ グループAzure network security groups

仮想ネットワークでのトラフィックのフローをフィルター処理するため、Azure はネットワーク セキュリティ グループ規則を使用します。To filter the flow of traffic in virtual networks, Azure uses network security group rules. これらの規則は、リソースへのアクセスを許可または拒否する発信元と宛先の IP 範囲、ポート、およびプロトコルを定義します。These rules define the source and destination IP ranges, ports, and protocols that are allowed or denied access to resources. Kubernetes API サーバーへの TLS トラフィックを許可する、既定の規則が作成されます。Default rules are created to allow TLS traffic to the Kubernetes API server. ロード バランサー、ポート マッピング、またはイングレス ルートでサービスを作成すると、AKS が自動的に、トラフィックが適切にフローするようにネットワーク セキュリティ グループを変更します。As you create services with load balancers, port mappings, or ingress routes, AKS automatically modifies the network security group for traffic to flow appropriately.

AKS クラスターに独自のサブネットを指定し、トラフィックのフローを変更する場合は、AKS によって管理されるサブネットレベルのネットワーク セキュリティ グループを変更しないでください。In cases where you provide your own subnet for your AKS cluster and you wish to modify the flow of traffic, do not modify the subnet-level network security group managed by AKS. ロード バランサーへのアクセス、コントロール プレーンとの通信、エグレスなど、クラスターの管理に必要なトラフィックが妨げられない限り、サブネットレベルのネットワーク セキュリティ グループをさらに作成してトラフィックのフローを変更することができます。You may create additional subnet-level network security groups to modify the flow of traffic as long as they do not interfere with traffic needed for managing the cluster, such as load balancer access, communication with the control plane, and egress.

Kubernetes ネットワーク ポリシーKubernetes network policy

クラスター内のポッド間のネットワーク トラフィックを制限するために、AKS では、Kubernetes ネットワーク ポリシーのサポートを提供しています。To limit network traffic between pods in your cluster, AKS offers support for Kubernetes network policies. ネットワーク ポリシーを使用すると、名前空間とラベル セレクターに基づいて、クラスター内の特定のネットワーク パスを許可するか拒否するかを選択できます。With network policies, you can choose to allow or deny specific network paths within the cluster based on namespaces and label selectors.

Kubernetes シークレットKubernetes Secrets

Kubernetes シークレットは、アクセス資格情報やキーなどの機密データをポッドに挿入するために使用します。A Kubernetes Secret is used to inject sensitive data into pods, such as access credentials or keys. まず Kubernetes API を使用してシークレットを作成します。You first create a Secret using the Kubernetes API. ポッドまたはデプロイを定義するとき、特定のシークレットを要求できます。When you define your pod or deployment, a specific Secret can be requested. シークレットは、シークレットを必要とするポッドがスケジュールされているノードのみに提供されます。シークレットは tmpfs に格納され、ディスクには書き込まれません。Secrets are only provided to nodes that have a scheduled pod that requires it, and the Secret is stored in tmpfs, not written to disk. シークレットを必要とする最後のポッドがノードから削除されると、シークレットはノードの tmpfs から削除されます。When the last pod on a node that requires a Secret is deleted, the Secret is deleted from the node's tmpfs. シークレットは、指定した名前空間内に格納され、同じ名前空間内のポッドによってのみアクセスできます。Secrets are stored within a given namespace and can only be accessed by pods within the same namespace.

シークレットを使用すると、ポッドやサービスの YAML マニフェストに定義されている機密情報が減少します。The use of Secrets reduces the sensitive information that is defined in the pod or service YAML manifest. 代わりに、YAML マニフェストの一部として Kubernetes API サーバーに格納されたシークレットを要求します。Instead, you request the Secret stored in Kubernetes API Server as part of your YAML manifest. この方法により、シークレットへのアクセス権が特定のポッドにのみ提供されます。This approach only provides the specific pod access to the Secret. 注意: 生のシークレット マニフェスト ファイルには、base64 形式の機密データが含まれています (詳細については、公式ドキュメントを参照してください)。Please note: the raw secret manifest files contains the secret data in base64 format (see the official documentation for more details). そのため、このファイルは機密情報として扱ってください。また、絶対にソース管理にはコミットしないでください。Therefore, this file should be treated as sensitive information, and never committed to source control.

Kubernetes シークレットは、分散型キー値ストアである etcd に格納されます。Kubernetes secrets are stored in etcd, a distributed key-value store. etcd ストアは AKS によって完全に管理されており、データは Azure プラットフォーム内での保存時に暗号化されますEtcd store is fully managed by AKS and data is encrypted at rest within the Azure platform.

次のステップNext steps

AKS クラスターのセキュリティでの保護を開始するには「AKS クラスターのアップグレード」を参照してください。To get started with securing your AKS clusters, see Upgrade an AKS cluster.

関連付けられているベスト プラクティスについては、AKS でのクラスターのセキュリティとアップグレードに関するベスト プラクティスのページと、AKS でのポッドのセキュリティに関するベスト プラクティスのページを参照してください。For associated best practices, see Best practices for cluster security and upgrades in AKS and Best practices for pod security in AKS.

Kubernetes と AKS の中心概念の追加情報については、次の記事を参照してください。For additional information on core Kubernetes and AKS concepts, see the following articles: