如何測試KubernetesRBAC？

店家小二發表於2018-12-18
建設Kubernetes叢集的安全是一回事，而維護它也會越來越困難。幸運的是，Kubernetes引入的新特性使這兩件事都變得容易起來。

Kubernetes（從1.6版本）引入了基於角色的訪問控制（RBAC），允許系統管理員定義策略來限制叢集使用者的行為。這意外著建立有限訪問許可權的使用者是可能的。它允許你限制如Secrets等資源的訪問，或限制使用者對某個名稱空間的訪問。

本文不會介紹如何實現RBAC，因為它已經有很多不錯的詳實的資料：



本文將聚集於怎樣使你業務的合規性和需求得到切實滿足。為此，我們需要測試被應用的RBAC物件，以確保它們像我們期望地那樣工作。

我們的場景

某個組織有多組團隊的人員，剛開始上手使用Kubernetes叢集。這時要求一個團隊不能去修改另一個團隊的deployment，否則會導致不可預見的跨團隊問題或停機。

負責Kubernetes deployment維護的平臺團隊最近在叢集裡部署了RBAC，它會將團隊成員的訪問限制在其對應的名稱空間。首先，團隊不能看到其它團隊名稱空間的Pod。

執行一週後，平臺團隊發現在一個被限制的名稱空間的使用者一直在讀取其它名稱空間的Secrets，但這是怎麼做到的呢？他們沒實現RBAC嗎？

事實上，他們做了。但就像對程式碼一樣，我們需要測試我們的系統來看它是否符合期望。慶幸的是，Kubernetes的命令列工具kubectl提供了測試RBAC配置的工具。kubectl auth can-i

Can I？

can-i只是使用API檢查是否某個操作可以被執行。它有以下選項 kubectl auth can-i VERB [TYPE | TYPE/NAME | NONRESOURCEURL] 現在可以檢查當前使用者是否可以執行某個操作。我們試一下：

kubectl auth can-i create pods


這會返回”yes”或”no”及相應的退出碼。

但只要我們嘗試測試另一使用者的授權，就會碰到障礙。因為用以上指令，我們只能使用當前載入的./kube/config來測試。而每個使用者一個檔案是很不足取的。好在Kubernetes又提供了使用–as=和–as-group-來模擬使用者的能力。

我們修改下指令，來模擬一個不同的使用者：

kubectl auth can-i create pods --as=me


我們應該會看到它返回”no”和退出碼1。

這很棒，我們現在有了一堆指令來測試一組使用者或單個使用者是否可以訪問任何Kubernetes資源，不論是檢視Pod列表還是刪除Secrets。

自動化

但我們不要停下來，我們已經為實現一個可以描述需求列表的並且可整合到持續交付流水線的測試集鋪平了道路，我們開始吧！

要實現自動化，我們有很多技術和程式語言的選擇，從JavaScript裡的Ava和Mocha到Rspec，這裡，我將使用一個純bash實現的測試框架，它叫Bats。

下面是一個例子，它測試一個團隊名稱空間的使用者可以對其deployment做擴縮容。如果該檔案設定了可執行許可權，它可以像任何shell指令碼一樣執行，或通過bats filename來執行。

#!/usr/bin/env bats
@test "Team namespaces can scale deployments within their own namespace" {
run kubectl auth can-i update deployments.apps --subresource="scale" --as-group="$group" --as="$user" -n $ns
[ "$status" -eq 0 ]
[ "$output" == "yes" ]
done
}


注意一下：--as和--as-group指令要求使用以下的RBAC規則：

rules:
- apiGroups:
- authorization.k8s.io
resources:
- selfsubjectaccessreviews
- selfsubjectrulesreviews
verbs:
- create


如上，你有了一個簡單的測試Kubernetes RBAC規則的實現方法。將其整合到你的Kubernetes持續交付流水線中，我們就有了一個被驗證過的更可靠的RBAC策略配置。這使得破壞策略的變化可以被及早發現。

本文轉自DockOne-如何測試Kubernetes RBAC？


相關文章