建设Kubernetes集群的安全是一回事，而维护它也会越来越困难。幸运的是，Kubernetes引入的新特性使这两件事都变得容易起来。
Kubernetes（从1.6版本）引入了基于角色的访问控制（RBAC），允许系统管理员定义策略来限制集群使用者的行为。这意外着创建有限访问权限的用户是可能的。它允许你限制如Secrets等资源的访问，或限制用户对某个命名空间的访问。
本文将聚集于怎样使你业务的合规性和需求得到切实满足。为此，我们需要测试被应用的RBAC对象，以确保它们像我们期望地那样工作。
负责Kubernetes deployment维护的平台团队最近在集群里部署了RBAC，它会将团队成员的访问限制在其对应的命名空间。首先，团队不能看到其它团队命名空间的Pod。
运行一周后，平台团队发现在一个被限制的命名空间的用户一直在读取其它命名空间的Secrets，但这是怎么做到的呢？他们没实现RBAC吗？
事实上，他们做了。但就像对代码一样，我们需要测试我们的系统来看它是否符合期望。庆幸的是，Kubernetes的命令行工具kubectl提供了测试RBAC配置的工具。
这会返回"yes"或"no"及相应的退出码。
但只要我们尝试测试另一用户的授权，就会碰到障碍。因为用以上指令，我们只能使用当前加载的./kube/config来测试。而每个用户一个文件是很不足取的。好在Kubernetes又提供了使用--as=和--as-group-来模拟用户的能力。
我们修改下指令，来模拟一个不同的用户：
我们应该会看到它返回"no"和退出码1。
这很棒，我们现在有了一堆指令来测试一组用户或单个用户是否可以访问任何Kubernetes资源，不论是查看Pod列表还是删除Secrets。
要实现自动化，我们有很多技术和编程语言的选择，从JavaScript里的Ava和Mocha到Rspec，这里，我将使用一个纯bash实现的测试框架，它叫 Bats 。
下面是一个例子，它测试一个团队命名空间的用户可以对其deployment做扩缩容。如果该文件设置了可执行权限，它可以像任何shell脚本一样执行，或通过
注意一下：
Kubernetes（从1.6版本）引入了基于角色的访问控制（RBAC），允许系统管理员定义策略来限制集群使用者的行为。这意外着创建有限访问权限的用户是可能的。它允许你限制如Secrets等资源的访问，或限制用户对某个命名空间的访问。
本文不会介绍如何实现RBAC，因为它已经有很多不错的详实的资料：
- https://medium.com/containerum ... 17d5d
- https://www.cncf.io/blog/2018/ ... etes/
- https://docs.bitnami.com/kuber ... ster/
- https://kubernetes.io/docs/ref ... 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？
