Azure Arc で有効になっている AKS での証明書管理の概要

適用対象: AKS on Azure Stack HCI 22H2、AKS on Windows Server

Azure Arc によって有効になっている AKS では、証明書とトークンベースの認証の組み合わせを使用して、プラットフォーム内のさまざまな操作を担当するサービス (またはエージェント) 間の通信をセキュリティで保護します。 証明書ベースの認証では、リソースへのアクセスを許可する前に、デジタル証明書を使用してエンティティ (エージェント、マシン、ユーザー、またはデバイス) を識別します。

クラウド エージェント

Arc で有効になっている AKS をデプロイすると、クラスター内のさまざまな機能を実行するために使用されるエージェントが AKS によってインストールされます。 次のエージェントが含まれます。

• クラウド エージェント: 基になるプラットフォーム オーケストレーションを担当するサービス。
• ノード エージェント: 各ノード上に存在し、仮想マシンの作成や削除などの実際の作業を行うサービス。
• キー管理システム (KMS) ポッド: キー管理を担当するサービス。
• その他のサービス: クラウド オペレーター、証明書マネージャーなど。

AKS のクラウド エージェント サービスは、クラスター内のVirtual Machines (VM)、Virtual Network インターフェイス (VNIC)、仮想ネットワーク (VNET) などのインフラストラクチャ コンポーネントの作成、読み取り、更新、削除 (CRUD) 操作を調整する役割を担います。

クライアントがクラウド エージェントと通信するには、この通信をセキュリティで保護するために、証明書がプロビジョニングされている必要があります。 各クライアントには ID が関連付けられている必要があります。これにより、クライアントに関連付けられるロール ベースのアクセス制御 (RBAC) 規則が定義されます。 各 ID は 2 つのエンティティで構成されます。

• トークン。初期認証に使われ、証明書を返します。
• 証明書。上記のサインイン プロセスから取得され、任意の通信での認証に使われます。

各エンティティは特定の期間 (既定では 90 日間) 有効で、それが終わると期限切れになります。 クラウド エージェントにアクセスし続けるには、クライアントごとに証明書を更新し、トークンをローテーションする必要があります。

証明書の種類

Arc で有効になっている AKS では、次の 2 種類の証明書が使用されます。

• クラウド エージェント CA 証明書: クライアント証明書の署名/検証に使用される証明書。 この証明書は 365 日間 (1 年間) 有効です。
• クライアント証明書: クライアントがクラウド エージェントに対して認証するためにクラウド エージェント CA 証明書によって発行される証明書。 通常、これらの証明書は 90 日間有効です。

Microsoft では、新しいリリースから 60 日以内にクラスターを更新することをお勧めします。これは、内部証明書とトークンを最新の状態に保つためだけでなく、新機能やバグ修正プログラムに確実にアクセスし、最新の重要なセキュリティ修正プログラムを常に適用し続けるためでもあります。 これらの毎月の更新では、更新プロセスによって、クラスターの通常の操作中に自動ローテーションできないトークンがローテーションされます。 証明書とトークンの有効期間は、クラスターが更新された日付から既定の 90 日間にリセットされます。

Arc で有効になっている AKS の証明書との通信をセキュリティで保護する

証明書は、クラスター内のコンポーネント間でセキュリティで保護された通信をするために使用されます。 AKS では、組み込みの Kubernetes コンポーネントに対して、ゼロタッチのすぐに使用するプロビジョニングと証明書の管理が提供されます。 この記事では、Arc で有効になっている AKS で証明書をプロビジョニングおよび管理する方法について説明します。

証明書と CA

AKS は、次の証明機関 (CA) と証明書を生成して使用します。

クラスター CA

• API サーバーには、API サーバーから kubelet への一方向の通信に使用する証明書に署名するクラスター CA があります。
• また、それぞれが kubelet 、 から kubelet API サーバーへの通信のために、クラスター CA によって署名される証明書署名要求 (CSR) も作成します。
• etcd キー値ストアには、etcd から API サーバーへの通信用に、クラスター CA によって署名された証明書が含まれています。

etcd CA

etcd キー値ストアでは、クラスター内で etcd レプリカ間のデータ レプリケーションを認証および承認するために証明書に署名する etcd CA があります。

フロント プロキシ CA

フロント プロキシ CA は、API サーバーと拡張 API サーバー間の通信をセキュリティで保護します。

証明書のプロビジョニング

の kubelet 証明書のプロビジョニングは、 TLS ブートストラップを使用して行われます。 他のすべての証明書については、YAML ベースのキーと証明書の作成を使用します。

• 証明書は /etc/kubernetes/pki に格納されます。
• キーは RSA 4096、EcdsaCurve: P384 です。

証明書の更新と管理

ルート以外の証明書は自動的に更新されます。 次の証明書を除く Kubernetes のすべてのコントロール プレーン証明書が管理されます。

• Kubelet サーバー証明書
• Kubeconfig クライアント証明書

セキュリティのベスト プラクティスとして、ユーザー認証には Active Directory シングル サインイン を使用する必要があります。

証明書の失効

証明書の失効はまれであり、証明書の更新時に行う必要があります。

失効させる証明書のシリアル番号を取得したら、Kubernetes カスタム リソースを使用して、失効情報の定義と保持を行います。 各失効オブジェクトは、1 つまたは複数の失効エントリで構成されます。

失効を実行するには、次のいずれかを使用します。

• シリアル番号
• グループ
• DNS 名
• IP アドレス

特定の notBefore タイムスタンプより前に発行された証明書のみを取り消す時間を指定できます。 時刻を notBefore 指定しないと、失効に一致するすべての既存および将来の証明書が失効します。

失効を実行するときにシリアル番号を使用する場合は、以下で説明する PowerShell コマンドを Repair-AksHciClusterCerts 使用して、クラスターを動作状態にすることができます。 前述の他のフィールドのいずれかを使用する場合は、必ず時刻を notBefore 指定してください。

apiVersion: certificates.microsoft.com/v1 
kind: RenewRevocation 
metadata: 
  name: my-renew-revocation 
  namespace: kube-system 
spec: 
  description: My list of renew revocations 
  revocations: 
  - description: Revoked certificates by serial number 
    kind: serialnumber 
    notBefore: "2020-04-17T17:22:05Z" 
    serialNumber: 77fdf4b1033b387aaace6ce1c18710c2 
  - description: Revoked certificates by group 
    group: system:nodes 
    kind: Group 
  - description: Revoked certificates by DNS 
    dns: kubernetes.default.svc. 
    kind: DNS 
  - description: Revoked certificates by DNS Suffix 
    dns: .cluster.local 
    kind: DNS 
  - description: Revoked certificates by IP 
    ip: 170.63.128.124 
    kind: IP 

次の手順

• 証明書を更新する
• Kubernetes クラスターに Linux アプリケーションをデプロイする
• Kubernetes クラスターに Windows Server アプリケーションをデプロイする