上周忙于考試沒時間更新部落格，這周繼續來談談關于AKS的一些内容，AKS是個很大也很重要的服務，其實能講的細節有很多，慢慢道來吧
接下來要分享的是關于AKS和AzureAD內建的一些内容，Kubernetes其實支援很多種身份驗證的方式，除了傳統的證書，token等，還可以支援和一些第三方的認證提供商進行內建，通過openid connect進行聯合認證，通過這種方法就可以把第三方的賬号體系和K8S本身的RBAC結合在一起進行授權，是以AKS本身其實是可以和AzureAD進行內建，對登入Azure的賬号進行K8S内部資源的授權的
預設情況下，其實這不是個by default就啟用的功能，而是需要手動開啟的，而如果不開啟AzureAD內建的話，我們想要進行細粒度的叢集管理，也可以使用傳統的K8S RBAC的方式，通過建立K8S的user，綁定role來完成授權，但是就沒辦法授權給AzureAD的賬号了
而想要和Azure AD內建的話，其實在Azure有兩種方式
一種是手動開啟內建，需要很繁瑣的步驟
一種是managed ad內建，隻需要設定開啟和關閉就行了
手動內建這種方式，弊端有很多，例如，隻能在建立叢集時開啟AAD內建，無法對現有叢集進行設定，一旦建立後再想用到AD內建的功能就沒辦法了，另外繁瑣的建立步驟也是不大不小的劣勢，相比之下托管的AAD內建要友善很多，估計也是微軟聽取了一些建議，把這點做得更人性化了，托管的AAD內建允許在叢集建立後再進行開啟，并且開啟時隻需要一條指令即可，所有步驟都由背景自動完成，在Global Azure的AKS中，在portal上通過簡單勾選其實就可以完成這個步驟，非常友善
叢集建立完成後，也可以單獨再進行開啟
對于21v Azure來說，托管的AAD內建目前在portal上還看不到選項，但是測試下來發現用CLI的方式應該還是可以啟用的
az aks create -g myResourceGroup -n myManagedCluster --enable-aad --aad-admin-group-object-ids <id> [--aad-tenant-id <id>]
如果是21v Azure，建立完AKS叢集後，想再開啟AAD內建，可以考慮用az aks update直接啟用托管的AAD內建
當然如果想繼續使用舊版的AAD內建，也可以使用CLI腳本進行叢集的建立，以下這個CLI腳本就可以用來建立舊版AAD內建的AKS叢集
https://github.com/Azure-Samples/azure-cli-samples/blob/master/aks/azure-ad-integration/azure-ad-integration.sh
不過經過實際測試發現，對于21v的Azure，這其實是有一些bug的，因為21v Azure不支援以下這個操作
az ad app permission admin-consent --id $serverApplicationId
經過case溝通，最終背景團隊給的解決辦法就是直接在portal進行這一步的授權操作
https://docs.azure.cn/zh-cn/aks/azure-ad-integration-cli?WT.mc_id=AZ-MVP-5001235
可以看到現在的中國區文檔這部分内容也已經更新過了。具體的執行步驟就不一一細講了，照着腳本跑就完事了