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

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

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

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 接続はワークロード クラスターでのみサポートされています。

この記事では、ID プロバイダーとして Active Directory を設定し、 を使用して kubectlSSO を有効にする手順について説明します。

• 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 を開き、 コマンドの パラメーターを使用して -enableADAuth 次を New-AksHciCluster 実行します。

New-AksHciCluster -name mynewcluster1 -enableADAuth

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

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

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

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

方法 1

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

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

注意

の場合は 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 グループに対応するロール バインドを作成します。 (上記のオプション 1 に示すように) を、お使いの環境に対応する AD グループまたはユーザーに置き換えます contoso\bob 。

手順 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 します。
  • $env :ProgramFiles\AksHci から c:\adsso に Kubectl-adsso.exe します。

  注意

  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 名 プレフィックスが必要です。 名前には、二重引用符で囲まれたドメイン名とプレフィックスが含まれている必要があることに注意してください。

次に 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 グループを持つ 名前空間 のカスタム ロールとロール バインドを作成する方法を示しています。 この例では、 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 アカウントの keytab ファイルを作成します。

手順 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

名前エントリに dsCrackNames が0x2返されるエラーが表示される場合は、 のパラメーター/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 アプリケーションをデプロイします。