Azure Arc によって有効になっている AKS の Kubernetes API サーバーへのセキュリティで保護された接続に Active Directory シングル サインオンを使用する

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

Active Directory (AD) シングル サインオン (SSO) 資格情報を使用して、Arc によって有効になっている AKS の Kubernetes API サーバーへのセキュリティで保護された接続を作成できます。

Arc で有効になっている AKS の AD の概要

Active Directory 認証を使用しない場合は、kubectl コマンドを使用して API サーバーに接続するときに、証明書ベースの kubeconfig ファイルに依存する必要があります。 kubeconfig ファイルには、秘密キーや証明書など、慎重に配布する必要があるシークレットが含まれており、これは重大なセキュリティ リスクになる可能性があります。

証明書ベースの kubeconfig を使用する代わりに、API サーバーに接続するための安全な方法として AD SSO 資格情報を使用できます。 AKS Arc との AD 統合により、Windows ドメインに参加しているコンピューター上のユーザーは、SSO 資格情報を使用して kubectl 経由で API サーバーに接続できます。 これにより、秘密キーを含む証明書ベースの kubeconfig ファイルを管理および配布する必要がなくなります。

AD 統合によって使用される AD kubeconfig は、証明書ベースの kubeconfig ファイルとは異なり、シークレットが一切含まれません。 ただし、Active Directory 資格情報を使用した接続に問題がある場合は、トラブルシューティングなどのバックアップの目的で、証明書ベースの kubeconfig ファイルを使用できます。

また、ユーザーとグループがセキュリティ識別子 (SID) として格納されることも、AD 統合のセキュリティ上のメリットの 1 つです。 グループ名とは異なり、SID は不変かつ一意であるため、名前が競合することはありません。

Note

AD SSO 接続は、ワークロード クラスターでのみサポートされます。

Note

入れ子になった AD グループ (別の AD グループ内に AD グループを作成する) の使用はサポートされていません。

この記事では、Id プロバイダーとして Active Directory を設定し、 kubectl経由で SSO を有効にする手順について説明します。

• API サーバーに対して AD アカウントを作成し、そのアカウントに関連付けられた keytab ファイルを作成します。 「keytab ファイルを使用して AD 認証を作成する」を参照して、AD アカウントを作成し、keytab ファイルを生成します。
• keytab ファイルを使用して、Kubernetes クラスター上で AD 認証をインストールします。 この手順の一部として、既定のロールベースのアクセス制御 (RBAC) 構成が自動的に作成されます。
• RBAC 構成を作成または編集するときは、グループ名を SID に変換するか、SID をグループ名に変更します。手順については、「AD グループの役割のバインドを作成および更新する」をご覧ください。

開始する前に

Active Directory SSO 資格情報を構成するプロセスを開始する前に、次の項目を確認する必要があります。

• 最新の Aks-Hci PowerShell モジュールがインストールされている必要があります。 インストールする必要がある場合は、「AksHci PowerShell モジュールをダウンロードしてインストールする」をご覧ください。

• AKS ホストがインストールされ、構成されている。 ホストをインストールする必要がある場合は、デプロイを構成する手順に従います。

• keytab ファイルが使用できる。 使用できない場合は、API サーバーの AD アカウントと keytab ファイルを作成する手順に従います。

  Note

  特定のサービス プリンシパル名 (SPN) に対して keytab ファイルを生成し、この SPN は、ワークロード クラスター用の API サーバー AD アカウントに対応している必要があります。 また、AD 認証プロセス全体で同じ SPN が使用されていることを確認する必要もあります。 keytab ファイルの名前は current.keytab にします。

• AKS ワークロード クラスターごとに 1 つの API サーバー AD アカウントを使用できます。

• クライアント マシンは、Windows ドメイン参加済みマシンである必要があります。

keytab ファイルを使用して AD 認証を作成する

手順 1: ワークロード クラスターを作成し、AD 認証を有効にする

AD 認証をインストールする前に、まず AKS ワークロード クラスターを作成し、クラスターで AD 認証アドオンを有効にする必要があります。 新しいクラスターの作成時に AD 認証を有効にしない場合は、後で有効にすることはできません。

管理者として PowerShell を開き、New-AksHciCluster コマンドの -enableADAuth パラメーターを使用して次を実行します。

New-AksHciCluster -name mynewcluster1 -enableADAuth

ワークロード クラスターごとに、1 つの API サーバー AD アカウントが使用可能であることを確認します。

ワークロード クラスターの作成の詳細については、「Windows PowerShell を使用して Kubernetes クラスターを作成するを参照してください。

手順 2: AD 認証をインストールする

AD 認証をインストールする前に、ワークロード クラスターがインストールされており、クラスター上で AD 認証が有効になっている必要があります。 AD 認証をインストールするには、次のいずれかのオプションを使用します。

オプション 1

ドメインに参加している Azure Local または Windows Server クラスターの場合は、管理者として PowerShell を開き、次のコマンドを実行します。

Install-AksHciAdAuth -name mynewcluster1 -keytab .\current.keytab -SPN k8s/apiserver@CONTOSO.COM -adminUser contoso\bob

Note

SPN k8s/apiserver@CONTOSO.comの場合は、SPN k8s/apiserver@<realm name>形式を使用します。 最初の試行では、 <realm name> を大文字で指定します。 ただし、大文字に問題がある場合は、小文字で SPN を作成します。 Kerberos では大文字と小文字が区別されます。

オプション 2

クラスター ホストがドメインに参加していない場合は、次の例に示すように、管理者ユーザー名またはグループ名を SID 形式で使用します。

管理者ユーザー:

Install-AksHciAdAuth -name mynewcluster1 -keytab .\current.keytab -SPN k8s/apiserver@CONTOSO.COM -adminUserSID <User SID>

管理者グループ:

Install-AksHciAdAuth -name mynewcluster1 -keytab .\current.keytab -SPN k8s/apiserver@CONTOSO.COM -adminGroupSID <Group SID>

ユーザー アカウントの SID を検索するには、「ユーザーまたはグループのセキュリティ識別子を決定する」をご覧ください。

次の手順に進む前に、次の項目をメモしておきます。

• keytab ファイルの名前が current.keytab であることを確認します。
• ご自身の環境に対応する SPN を置き換えます。
• -adminGroup パラメーターは、クラスター管理者特権を持つ指定した AD グループに対応するロール バインドを作成します。 contoso\bob (上記のオプション 1 に示すように) を、環境に対応する AD グループまたはユーザーに置き換えます。

手順 3: AD Webhook と keytab ファイルをテストする

AD Webhook が API サーバーで実行されており、keytab ファイルが Kubernetes シークレットとして格納されていることを確認します。 ワークロード クラスター用の証明書ベースの kubeconfig ファイルを取得するには、次の手順に従います。

1. 次のコマンドを使用して、証明書ベースの kubeconfig ファイルを取得します。 kubeconfig ファイルを使用して、ローカル ホストとしてクラスターに接続します。

   Get-AksHciCredential -name mynewcluster1
   

2. 接続したサーバーで (前に作成した証明書ベースの kubeconfig ファイルを使用して) kubectl 実行し、AD webhook のデプロイを確認して、 ad-auth-webhook-xxxx形式になっていることを確認します。

   kubectl get pods -n=kube-system
   

3. kubectl を実行して、keytab ファイルがシークレットとしてデプロイされ、Kubernetes シークレットとして表示されていることを確認します。

   kubectl get secrets -n=kube-system
   

手順 4: AD kubeconfig ファイルを作成する

AD Webhook と keytab が正常にデプロイされたら、AD kubeconfig ファイルを作成します。 ファイルが作成された後、AD kubeconfig ファイルをクライアント マシンにコピーし、それを使用して、API サーバーに対して認証します。 証明書ベースの kubeconfig ファイルとは異なり、AD kubeconfig はシークレットではなく、プレーン テキストとしてコピーしても問題ありません。

管理者として PowerShell を開き、次のコマンドを実行します。

Get-AksHciCredential -name mynewcluster1 -configPath .\AdKubeconfig -adAuth

手順 5: kubeconfig およびその他のファイルをクライアント マシンにコピーする

AKS ワークロード クラスターからクライアント コンピューターに次の 3 つのファイルをコピーする必要があります。

• 前の手順で作成した AD kubeconfig ファイルを $env:USERPROFILE.kube\config にコピーします。

• フォルダー パス c:\adsso を作成し、AKS ワークロード クラスターからクライアント コンピューターに次のファイルをコピーします。

  • $env:ProgramFiles\AksHci で c:\adsso にKubectl.exeします。
  • Kubectl-adsso.exe $env:ProgramFiles\AksHci から c:\adsso にアクセスします。

  Note

  adsso.exe ファイルは、 Get-AksHciCredential コマンドレットの実行時にサーバー上に生成されます。

手順 6: クライアント マシンから API サーバーに接続する

前の手順を完了したら、SSO 資格情報を使用して、Windows ドメインに参加しているクライアント コンピューターにサインインします。 PowerShell を開き、kubectl を使用して、API サーバーへのアクセスを試みます。 操作が正常に完了した場合は、AD SSO を正しく設定します。

AD グループのロール バインドを作成および更新する

手順 2 で説明したように、クラスター管理特権を持つ既定のロール バインドが、インストール中に提供されたユーザーやグループに対して作成されます。 Kubernetes 内のロール バインドにより、AD グループのアクセス ポリシーが定義されます。 この手順では、RBAC を使用して、Kubernetes 内で新しい AD グループのロール バインドを作成し、既存のロール バインドを編集する方法について説明します。 たとえば、クラスター管理者は、AD グループを使用してユーザーに追加の特権を付与したい場合があります (これにより、プロセスがより効率的になります)。 RBAC の詳細については、「 RBAC 承認の使用」を参照してください。

他の AD グループ RBAC エントリを作成または編集する場合、サブジェクト名には microsoft:activedirectory:CONTOSO\group name プレフィックスが必要です。 名前には、二重引用符で囲まれたドメイン名とプレフィックスが含まれている必要があることに注意してください。

次に 2 つの例を挙げます。

例 1

apiVersion: rbac.authorization.k8s.io/v1 
kind: ClusterRoleBinding 
metadata: 
  name: ad-user-cluster-admin 
roleRef: 
  apiGroup: rbac.authorization.k8s.io 
  kind: ClusterRole 
  name: cluster-admin 
subjects: 
- apiGroup: rbac.authorization.k8s.io 
  kind: User 
  name: "microsoft:activedirectory:CONTOSO\Bob" 

例 2

次の例では、AD グループを使用して、 namespace のカスタム ロールとロール バインドを作成する方法を示します。 この例では、 SREGroup は Contoso Active Directory の既存のグループです。 ユーザーが AD グループに追加されると、すぐに特権が付与されます。

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: sre-user-full-access
  namespace: sre
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["*"]
  verbs: ["*"]
- apiGroups: ["batch"]
  resources:
  - jobs
  - cronjobs
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ad-user-cluster-admin
  namespace: sre
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: sre-user-full-access
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: Group
    name: "microsoft:activedirectory:CONTOSO\SREGroup" 

YAML ファイルを適用する前に、次のコマンドを使用して、グループ名とユーザー名を常に SID に変換する必要があります。

kubectl-adsso nametosid <rbac.yml>

同様に、既存の RBAC を更新するために、変更を行う前に、SID をユーザー フレンドリなグループ名に変換することができます。 SID を変換するには、次のコマンドを使用します。

kubectl-adsso sidtoname <rbac.yml>

API サーバー アカウントに関連付けられている AD アカウントのパスワードを変更する

API サーバー アカウント用のパスワードが変更された場合は、AD 認証アドオンをアンインストールし、更新された現在の keytab と前の keytab を使用して再インストールする必要があります。

パスワードを変更するたびに、現在の keytab の名前 (current.keytab) を previous.keytab に変更する必要があります。 次に、新しいパスワードに current.keytab という名前を付けてください。

重要

これらのファイルには、それぞれ current.keytab と previous.keytab という名前を付ける必要があります。 既存のロール バインドは、この変更の影響を受けません。

AD 認証をアンインストールして再インストールする

API サーバーのアカウントが変更されたとき、パスワードが更新されたとき、またはエラーのトラブルシューティングを行うときに、AD SSO を再インストールすることができます。

AD 認証をアンインストールするには、管理者として PowerShell を開き、次のコマンドを実行します。

Uninstall-AksHciAdAuth -name mynewcluster1

AD 認証を再インストールするには、管理者として PowerShell を開き、次のコマンドを実行します。

Install-AksHciAdAuth -name mynewcluster1 -keytab <.\current.keytab> -previousKeytab <.\previous.keytab> -SPN <service/principal@CONTOSO.COM> -adminUser CONTOSO\Bob

Note

クライアントがチケットをキャッシュした場合のダウンタイムを回避するには、パスワードを変更する場合にのみ、 -previousKeytab パラメーターが必要です。

API サーバー AD アカウントと keytab ファイルを作成する

AD アカウントと keytab ファイルの作成には、2 つの手順が関係します。 まず、サービス プリンシパル名 (SPN) を使用して API サーバーの新しい AD アカウント/ユーザーを作成し、次に AD アカウントのキータブ ファイルを作成します。

手順 1: API サーバーに対して新しい AD アカウントまたはユーザーを作成する

New-ADUser PowerShell コマンドを使用して、SPN を含む新しい AD アカウント/ユーザーを作成します。 次に例を示します。

New-ADUser -Name apiserver -ServicePrincipalNames k8s/apiserver -AccountPassword (ConvertTo-SecureString "password" -AsPlainText -Force) -KerberosEncryptionType AES128 -Enabled 1

手順 2: AD アカウントに対して keytab ファイルを作成する

keytab ファイルを作成するには、 ktpass Windows コマンドを使用します。

ktpass を使用する例を次に示します。

ktpass /out current.keytab /princ k8s/apiserver@CONTOSO.COM /mapuser contoso\apiserver_acct /crypto all /pass p@$$w0rd /ptype KRB5_NT_PRINCIPAL

Note

名前エントリ 0x2返されたエラー DsCrackNames が表示された場合、 /mapuser のパラメーターがフォーム mapuser DOMAIN\userにあることを確認します。DOMAIN はエコー %userdomain%の出力です。

ユーザーまたはグループのセキュリティ識別子を決定する

次の 2 つのオプションのいずれかを使用して、アカウントまたは他のアカウントの SID を見つけます。

• アカウントに関連付けられている SID を検索するには、ホーム ディレクトリのコマンド プロンプトから次のコマンドを入力します。

  whoami /user
  

• 別のアカウントに関連付けられている SID を見つけるには、管理者として PowerShell を開き、次のコマンドを実行します。

  (New-Object System.Security.Principal.NTAccount(<CONTOSO\Bob>)).Translate([System.Security.Principal.SecurityIdentifier]).value
  

証明書のトラブルシューティング

Webhook と API サーバーは、証明書を使用して、TLS 接続を相互に検証します。 この証明書は 500 日後に有効期限が切れます。 証明書の有効期限が切れていることを確認するには、ad-auth-webhook コンテナーからログを表示します。

kubectl logs ad-auth-webhook-xxx

証明書の検証エラーが表示された場合は、webhook をアンインストールして再インストール し、新しい証明書を取得する手順を完了します。

ベスト プラクティスとクリーンアップ

• クラスターごとに一意のアカウントを使用します。
• クラスター間で API サーバー アカウントのパスワードを再利用することは避けてください。
• クラスターを作成したらすぐにキータブ ファイルのローカル コピーを削除し、SSO 資格情報が機能することを確認します。
• API サーバー用に作成された Active Directory ユーザーを削除します。 詳細については、「Remove-ADUser」をご覧ください。

次のステップ

この攻略ガイドでは、SSO 資格情報を使用して、API サーバーに安全に接続するように AD 認証を構成する方法について学習しました。 次に、以下を実行できます。

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