iT邦幫忙

2021 iThome 鐵人賽

DAY 29
1
自我挑戰組

HomeLab 30天,胡搞瞎搞亂弄一通。系列 第 29

Day29,使用Dex、OIDC為你的Kubernetes再上一道鎖 (2/2)

正文

如果還沒有看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


上一篇
Day28,使用Dex、OIDC為你的Kubernetes再上一道鎖 (1/2)
下一篇
Day30,旅途的終點
系列文
HomeLab 30天,胡搞瞎搞亂弄一通。30

尚未有邦友留言

立即登入留言