在 Azure Arc 所啟用的 AKS 中使用 Active Directory 單一登錄來保護 Kubernetes API 伺服器的連線

發行項
08/07/2024

適用於：Azure Stack HCI 22H2 上的 AKS、Windows Server 上的 AKS

您可以使用 Active Directory （AD）單一登入（SSO）認證，在 Arc 啟用的 AKS 中建立與 Kubernetes API 伺服器的安全連線。

Arc 所啟用 AKS 中的 AD 概觀

如果沒有 Active Directory 驗證，當您透過 kubectl 命令連線到 API 伺服器時，必須依賴以憑證為基礎的 kubeconfig 檔案。 kubeconfig 檔案包含秘密，例如需要仔細散發的私鑰和憑證，這可能會造成重大安全性風險。

作為使用憑證型 kubeconfig 的替代方案，您可以使用 AD SSO 認證作為連線到 API 伺服器的安全方式。 AD 與 AKS Arc 整合可讓使用者使用其 SSO 認證，在加入網域的電腦上連線到 API 伺服器 kubectl 。這樣就不需要管理和散發包含私鑰的憑證型 kubeconfig 檔案。

AD 整合會使用 AD kubeconfig，這與憑證型 kubeconfig 檔案不同，且不包含任何秘密。不過，如果使用 Active Directory 認證進行連線時發生問題，憑證型 kubeconfig 檔案可用於備份用途，例如進行疑難解答。

AD 整合的另一個安全性優點是使用者和群組會儲存為安全性標識碼（SID）。不同於組名，SID 不可變且是唯一的，因此不會發生命名衝突。

注意

只有工作負載叢集支援AD SSO 連線。

注意

不支援使用巢狀 AD 群組（在另一個 AD 群組內建立 AD 群組）。

本文會引導您完成將 Active Directory 設定為識別提供者的步驟，並透過 kubectl啟用 SSO：

建立 API 伺服器的 AD 帳戶，然後建立與帳戶相關聯的 keytab 檔案。請參閱使用keytab檔案建立AD驗證，以建立AD帳戶併產生keytab檔案。
使用 keytab 檔案在 Kubernetes 叢集上安裝 AD 驗證。在此步驟中，會自動建立預設角色型訪問控制（RBAC）組態。
在建立或編輯 RBAC 組態時，將組名轉換成 SID，反之亦然，請參閱建立和更新 AD 群組角色系結以取得指示。

開始之前

開始設定 Active Directory SSO 認證的程式之前，您應該確定您有下列專案可供使用：

已安裝最新的 Aks-Hci PowerShell 模組。如果您需要安裝它，請參閱下載並安裝 AksHci PowerShell 模組。
AKS 主機已安裝並設定。如果您需要安裝主機，請遵循步驟來設定您的部署。
keytab 檔案可供使用。如果無法使用，請遵循步驟來建立 API 伺服器 AD 帳戶和 keytab 檔案。

注意

您應該為特定服務主體名稱（SPN）產生 keytab 檔案，而且此 SPN 必須對應至工作負載叢集的 API 伺服器 AD 帳戶。您也必須確保整個 AD 驗證程式都使用相同的 SPN。 keytab 檔案應該命名為 current.keytab。
每個 AKS 工作負載叢集都有一個 API 伺服器 AD 帳戶可供使用。
用戶端電腦必須是已加入網域的 Windows 電腦。

使用 keytab 檔案建立 AD 驗證

步驟 1：建立工作負載叢集並啟用 AD 驗證

安裝 AD 驗證之前，您必須先建立 AKS 工作負載叢集，並在叢集上啟用 AD 驗證附加元件。如果您在建立新的叢集時未啟用AD驗證，則稍後就無法加以啟用。

以系統管理員身分開啟 PowerShell，並使用 -enableADAuth 命令的 New-AksHciCluster 參數執行下列命令：

New-AksHciCluster -name mynewcluster1 -enableADAuth

針對每個工作負載叢集，請確定有一個 API 伺服器 AD 帳戶可供使用。

如需建立工作負載叢集的相關信息，請參閱使用 Windows PowerShell 建立 Kubernetes 叢集。

步驟 2：安裝 AD 驗證

安裝AD驗證之前，必須先安裝工作負載叢集，並在叢集上啟用AD驗證。若要安裝 AD 驗證，請使用下列其中一個選項。

選項 1

針對已加入網域的 Azure 本機或 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 所示）取代 contoso\bob 為對應至您環境的 AD 群組或使用者。

步驟 3：測試 AD Webhook 和 keytab 檔案

請確定 AD Webhook 正在 API 伺服器上執行，而 keytab 檔案會儲存為 Kubernetes 秘密。若要取得工作負載叢集的憑證型 kubeconfig 檔案，請遵循下列步驟：

使用下列命令取得憑證型 kubeconfig 檔案。使用 kubeconfig 檔案以本機主機身分連線到叢集：
```
Get-AksHciCredential -name mynewcluster1
```
在您連接的伺服器上執行 kubectl （使用您先前建立的憑證型 kubeconfig 檔案），然後檢查 AD Webhook 部署，以確定其格式 ad-auth-webhook-xxxx為：
```
kubectl get pods -n=kube-system
```
執行 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 工作負載叢集複製到用戶端電腦：

複製在上一個步驟中建立的 AD kubeconfig 檔案，以 $env：USERPROFILE.kube\config。
建立資料夾路徑 c：\adsso ，並將下列檔案從 AKS 工作負載叢集複製到用戶端電腦：
- 在 $env：ProgramFiles\AksHci 底下Kubectl.exe c：\adsso。
- 在 $env：ProgramFiles\AksHci 底下Kubectl-adsso.exe c：\adsso。
注意

當您執行 Get-AksHciCredential Cmdlet 時，會在伺服器上產生adsso.exe檔案。

步驟 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 前置詞。請注意，名稱必須包含功能變數名稱和以雙引弧括住的前置詞。

以下提供兩個範例：

範例 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 （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

注意

若要避免用戶端快取票證的停機時間， -previousKeytab 只有在您變更密碼時，才需要參數。

建立 API 伺服器 AD 帳戶和 keytab 檔案

建立 AD 帳戶和 keytab 檔案涉及兩個步驟。首先，為具有服務主體名稱（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

注意

如果您在名稱專案中看到傳回的 DsCrackNames 錯誤0x2，請確定 /mapuser 的參數格式mapuser DOMAIN\user為，其中 DOMAIN 是 echo %userdomain%的輸出。

判斷使用者或群組安全性標識碼

使用下列兩個選項之一來尋找您帳戶或其他帳戶的 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 認證正常運作時，請刪除 keytab 檔案的本機複本。
刪除為 API 伺服器建立的 Active Directory 使用者。如需詳細資訊，請參閱 Remove-ADUser。

下一步

在本操作指南中，您已瞭解如何設定 AD 驗證，以使用 SSO 認證安全地連線到 API 伺服器。接著，您可以：

共用方式為