在啟用了AzureAD內建之後，理所當然的我們要進行一波測試，來驗證啟用之後具體會有什麼效果
如果我們想對叢集内部的資源進行細粒度的權限劃分的話，其實還是依托于AKS本身的RBAC，隻不過授權對象換成了AAD裡的object，也就是AAD的使用者或者組等，是以我們還是要在AKS裡建立一些role和rolebinding這種資源的，而想要建立這些對象，在AKS裡這部分操作暫時沒辦法在portal進行，而是需要使用kubectl完成操作，想要使用kubectl的話，就需要提前先拿到kubeconfig
在AKS中藥擷取kubeconfig的話，如果是管理者，可以直接運作az aks get-credentials --resource-group rg--name aksname來擷取
如果不是類似owner或者contributor這種角色的話，則可以通過首先授予使用者Azure Kubernetes Service Cluster User Role這個角色，來讓使用者先能下載下傳到kubeconfig
接下來，就開始實際看下開啟AAD內建之後，如何對叢集進行授權
首先建立個dev的ns，我們最終要模拟的就是給一個AAD使用者隻授予這個dev namespace的一部分權限
kubectl create ns dev
接下來，編輯一個Role的定義，将來準備給AAD使用者bind到這個role上
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: dev-user-full-access
namespace: dev
rules:
- apiGroups: ["", "extensions", "apps"]
resources: ["*"]
verbs: ["*"]
- apiGroups: ["batch"]
resources:
- jobs
- cronjobs
建立role
kubectl apply -f role-dev-namespace.yaml
建立個dev的AAD組，準備後邊的role binding，可以看到這個組裡有個使用者叫labuser
接下來就可以開始準備rolebinding-dev-namespace.yaml檔案
kind: RoleBinding
name: dev-user-access
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
subjects:
- kind: Group
name: 8b385787-9431-463e-9269-49a8c679c0ca
kubectl apply -f rolebinding-dev-namespace.yaml
之後az login使用labuser這個賬戶登入，下載下傳kubeconfig
開啟AAD內建的AKS叢集，很明顯的一個特點就是運作kubectl指令的時候，不管是什麼指令都會要求再做一次Azure賬号的登入，以拿到token
可以看到有dev ns的權限，但是沒有default這個namespace的權限