【手把手教學】使用 GKE 進行第三方認證授權

現今社會中,人們在日常生活或工作中都離不開網路的應用,常見的像是社群媒體、網路銀行、第三方的應用軟體...等,每一種平台服務通常都會需要用戶註冊全新的帳號登入,這導致人們會需要管理各種服務平台的帳號和密碼。除了增加管理上的困難,同時用戶為了方便記憶各種的網路服務帳戶,常常使用相同的帳號和密碼或是使用強度較弱的密碼複雜度,這間接也造成了許多安全性的問題。

因此,目前大多數的社群網站或是手機軟體都開始提供可以讓使用者藉由像是 Google 或 Facebook 等可靠的第三方的驗證方式進行平台的註冊及登入,這樣一來使用者既可不用管理多組帳號密碼,同時也可以擁有更多安全性防護的保障。

這樣便利的第三方驗證及授權流程其實是藉由 OAuth2.0 機制訂定出一套標準流程框架,但 OAuth 本身只具備了授權功能,並沒有驗證機制,所以進而衍生出 OIDC (OpenID Connect) 機制使其可以用來進行認證的功能。而 GKE (Google Kubernetes Engine) 服務實際上也可以藉由 OIDC 的機制來進行第三方授權。

什麼是 OIDC

OIDC (OpenID Connect) 是常見提供身份驗證和授權的機制,我們常聽到的 Okta, Azure Active Directory 及 Microsoft Active Directory Federation service (ADFS) 等都可以是 OIDC 的身份驗證提供者 (IdP, Identity Provider),這些 IdP 在進行使用者身份認證及授權後會回傳像是 Access Token的授權訊息,ID Token 的認證訊息和 Refresh Token等內容。

GKE 為何要使用 OIDC 

雖然在 Google Cloud Platform 中也可以使用 Cloud Identity 的服務搭配 GCDS (Google Cloud Directory Sync) 的方式進行 GKE 的認證和授權,但這樣的做法會讓我們必須將使用者的資訊及權限都同步到 Cloud Identity 上,對於部分的系統管理者不想將這些使用者的權限資訊上傳到雲端平台中就不是一個理想的解決方案。

相對 OIDC 進行授權認證的過程中,並不需要同步或上傳使用者目錄資料,所有的驗證行為皆在 IdP 端完成,並且等待認證完後 IdP 則會以回傳 Access Token 及 Id Token 等內容讓 GKE 可以確認合法的使用者並給予相對應管控權限登入 GKE 服務,因此 OIDC 對使用 GCDS 服務來的更有彈性的應用。

GKE 如何利用 OIDC 進行認證及授權 

GKE 在使用 OIDC 進行認證及授權前須先啟用 identity-service

請先執行以下指令,進行 identity-service 啟用

1gcloud container clusters create <CLUSTER-NAME> \ 2 --enable-identity-service

再來,我們需要準備 client config 及 login config 兩個 yaml 的設定檔,針對 cluster 進行 OIDC 的預先設置。

首先我們可先藉由以下指令取的 client config 設定檔的 template

1kubectl get clientconfig default -n kube-public -o yaml > client-config.yaml

取得 client-config.yaml 之後,我們需要針對 OIDC 的相關參數進行設定,基本參數介紹如下

clientID

在 idp 新增 Application 時自動產生的 clientID

clientSecret

在 IdP 新增 Application 時自動產生的 clientSecret

certificateAuthorityData (optional)

若 idp 使用的是自謙憑證,這裡請帶入 IdP 的 CA 憑證 (一定要是用 base64 編碼過後的 PEM 格式)

extraParams

針對不同 IdP 的要求給予不同的值

  • 若 IdP 為 Microsoft Azure 或是 Okta,請帶入 prompt=consent
  • 若 IdP 為 Cloud Identity,請帶入 prompt=consent,access_type=offline

issuerURI

IdP 的 issuer URI

kubectlRedirectURI

OIDC 認證完之後要重新導向的地方,通常為 localhost,port 建議大於 1024

scopes

向 IdP 請求的使用者資料範圍

userClaim

拿來當作 GKE user name 的 claim

將以上參數正確的填寫上 config 的設定值後,請執行以下指令,將 client config apply 到 cluster 上

1kubectl apply -f client-config.yaml

接下來,為了讓在做完 OIDC 設定後可以讓 user 擁有操控 cluster 內部資的權限,這時候我們就需要用到 RBAC 來幫助我們管理 cluster 內部資源的存取權限,而 RBAC 的設定一樣需要使用到 yaml 檔進行。

RBAC 的設定需要先建立一個 cluster role,並賦予這個 role 存取特定資源權利,然後再將這個 cluster role 綁定到某個 user 上,讓特定的使用者可擁有相對的權限

所以我們先來設定 create-role.yaml, role-binding.yaml 兩個設定檔來設定 RBAC (Role-Based Access Control)

create-role.yaml(創建 cluster role)

1apiVersion: rbac.authorization.k8s.io/v1 2kind: ClusterRole 3metadata: 4 name: <ROLE-NAME> 5rules: 6- apiGroups: [""] 7 # The resource type for which access is granted 8 resources: ["pods", "namespaces"] 9 # The permissions granted by the ClusterRole 10 verbs: ["get", "watch", "list"]

role-binding.yaml(將 cluster role 綁定到特定的 user 上)

1apiVersion: rbac.authorization.k8s.io/v1 2kind: ClusterRoleBinding 3metadata: 4 name: <ROLE-BINDING-NAME> 5subjects: 6- kind: User 7 name: <ISSUER_URI#USER> 8 apiGroup: rbac.authorization.k8s.io 9roleRef: 10 kind: ClusterRole 11 name: <ROLE-NAME> 12 apiGroup: rbac.authorization.k8s.io 13

 *若 client config 設定的 userClaim 為 email 可以不加 ISSUER_URI

創建好兩個RBAC 設定檔後,請執行以下指令,將 create-role.yaml, role-binding.yaml apply 到 cluster 上

1kubectl apply -f create-role.yaml 2kubectl apply -f role-binding.yaml

街下來我們就可以讓 GKE 嘗試使用 OIDC 來進行第三方的授權認證,但在這之前需要先安裝 Google Cloud SDK 額外提供的 kubectl-oidc 的 component 才能夠讓 GKE 使用 OIDC 做登入。

請先藉由下面指令安裝 kubectl-oidc

1gcloud components install kubectl-oidc

安裝後,我們就能使用 kubectl-oidc 進行登入

以下為 kubect oidc 的登入指令,請記得這邊要帶上前面創建好的 login-config.yaml

1kubectl oidc login --cluster=<CLUSTER-NAME> \ --login-config=login-config.yaml

執行以上指令後,會自動在 browser 開啟 authorization server 提供的登入畫面,再進行號密碼登入後,即完成第三方驗證

最後,user 即可擁有 RBAC 中授予的 resource 權限,可執行以下指令進行確認

1kubectl get pods

此處應該能夠列出已有的 pod。

撰文者:Joanne Chen/目前專注於 infra 及 security 的領域,協助客戶雲端架構的執行

 

訂閱 CloudMile 電子報

所有 CloudMile 最新消息、產品動態、活動資訊和特別優惠,立即掌握。