如果還沒有看Day28的話,建議可以先回去看,不然接下來可能搞不清楚狀況。
延續昨天的內容,我們需要去驗證我們設定的OIDC/Dex server能夠正常運作。
我們先去下載kubelogin的binary,將kubelogin放在目錄底下,我們要先使用kubelogin驗證安裝的程序,使用下列指令執行
./kubelogin setup --insecure-skip-tls-verify \
--oidc-issuer-url=https://192.168.1.241 \
--oidc-client-id=kubernetes \
--oidc-client-secret=qwertasdfg
注意這邊的oidc-client-secret為我們昨天設定的dex config那邊的staticClients自訂的secret值
kubelogin會幫我們打開瀏覽器8000Port,與dex server溝通做跳轉,最終來到gitlab的登入頁面(因為我的IdP僅有Gitlab,否則應該可以選擇多種登入方式)
驗證完成後回到terminal,我們會看到下列引導,我們就跟著做第3步驟,為dex server綁定cluster admin權限,之後都要透過他管理,而第4步驟則是我們昨天已經先設定過了Kube-Apiserver的部分,所以可以跳過。
## 2. Verify authentication
You got a token with the following claims:
{
"iss": "https://192.168.1.241",
"sub": "CgcxOTQyNDUyEgZnaXRsYWI",
"aud": "kubernetes",
"exp": 1632225868,
"iat": 1632139468,
"nonce": "iLqq7kS2VqVlYDpwWnqneJ8-j_hqo5tILpfYL4W_SAc",
"at_hash": "UzM9v1rillKcH-JmOQ9W-w",
"c_hash": "gcrhI9p7zFQsHyuWKMHcoQ"
}
## 3. Bind a cluster role
Run the following command:
kubectl create clusterrolebinding oidc-cluster-admin --clusterrole=cluster-admin --user='https://192.168.1.241#CgcxOTQyNDUyEgZnaXRsYWI'
## 4. Set up the Kubernetes API server
Add the following options to the kube-apiserver:
--oidc-issuer-url=https://192.168.1.241
--oidc-client-id=kubernetes
## 5. Set up the kubeconfig
Run the following command:
kubectl config set-credentials oidc \
--exec-api-version=client.authentication.k8s.io/v1beta1 \
--exec-command=kubectl \
--exec-arg=oidc-login \
--exec-arg=get-token \
--exec-arg=--oidc-issuer-url=https://192.168.1.241 \
--exec-arg=--oidc-client-id=kubernetes \
--exec-arg=--oidc-client-secret=qwertasdfg \
--exec-arg=--insecure-skip-tls-verify
## 6. Verify cluster access
Make sure you can access the Kubernetes cluster.
kubectl --user=oidc get nodes
You can switch the default context to oidc.
kubectl config set-context --current --user=oidc
You can share the kubeconfig to your team members for on-boarding.
在執行第五步驟前,我們需要替我們的kubectl安裝kubelogin的plugin,執行
kubectl krew install oidc-login
而這邊顯示的第5步驟並不完全正確,因為我們在api-server中有明確指定oidc-username-claim
所以我們實際的指令執行是多了一個--oidc-extra-scope=email
kubectl config set-credentials oidc \
--exec-api-version=client.authentication.k8s.io/v1beta1 \
--exec-command=kubectl \
--exec-arg=oidc-login \
--exec-arg=get-token \
--exec-arg=--oidc-issuer-url=https://192.168.1.241 \
--exec-arg=--oidc-client-id=kubernetes \
--exec-arg=--oidc-client-secret=qwertasdfg \
--exec-arg=--oidc-extra-scope=email \
--exec-arg=--insecure-skip-tls-verify
執行第6步驟的驗證
kubectl --user=oidc get nodes
會發現沒有get nodes的權限,原因是並沒有針對oidc取得的user設定kubernetes的RBAC,那我們這邊快速apply一個test-rolebinding.yml
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: gurubear-rolebinding
subjects:
- kind: User
name: coolyupo@gmail.com ##oidc-username-claim=email
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
現在能夠正常使用啦,而這個kubeconfig就能夠直接給其他具備gitlab group權限的人啦,只是還是要去apply對應的權限喔
這邊補充一下kubelogin官方的flowchart,有興趣的話可以看一下怎麼運作的,其實就是OIDC那一套標準。
圖片來自官方github
那我們來看一下~/.kube/config
的內容,可以看到--insecure-skip-tls-verify
,是為了信任不安全的連線所用的。
但其實我們有CA可以讓它變成被認定的安全連線,這邊就將CA檔轉為base64輸出
調整config
一樣能夠正常取得驗證
最後來demo一下,在dex server那邊其實有針對gitlab connector設定白名單groups,那我就一樣用不屬於gurubear-ithome-13th group的帳號進行驗證,最後確實在dex這邊被拒絕啦~
透過這樣的方式應該就能更安全複雜的管理Kubernetes了吧~
這兩篇寫得實在是有點太長了,精疲力盡了,應該也是這次鐵人賽的最後一part了。明天估計就發些總結感言之類的湊湊篇幅XD