在Kubernetes中，授权有ABAC（基于属性的访问控制）、RBAC（基于角色的访问控制）、Webhook、Node、AlwaysDeny（一直拒绝）和AlwaysAllow（一直允许）这6种模式。
从1.6版本起，Kubernetes 默认启用RBAC访问控制策略。从1.8开始，RBAC已作为稳定的功能。通过设置--authorization-mode=RBAC，启用RABC。在RABC API中，通过如下的步骤进行授权：
定义角色：在定义角色时会指定此角色对于资源的访问控制的规则；
绑定角色：将主体与角色进行绑定，对用户进行访问授权。
1.1角色和集群角色
在 RBAC API 中，角色包含代表权限集合的规则。在这里，权限只有被授予，而没有被拒绝的设置。
在 Kubernetes 中有两类角色，即普通角色(Role)和集群角色(ClusterRole)。
可以通过Role定义在一个命名空间中的角色，或者可以使用ClusterRole定义集群范围的角色。一个Role只能被用来授予访问单一命令空间中的资源。
下面是在 yunwei-test命名空间中定义了一个名为 pod-reader 的角色，此角色能够对在 yunwei-test命名空间中访问 Pod：
k8s-rabc-01
ClusterRole可用于授予与Role相同的权限。他们能够被授予如下资源的权限：
1.集群范围的资源（类似于Node）
2.非资源端点（类似于”/healthz”）
3.集群中所有命名空间的资源（类似Pod）
下面的ClusterRole可用于授予对任何命名空间中的秘密的读取访问权限，或跨所有命名空间的访问权限。
k8s-rabc-02
1.2、RoleBinding 和 ClusterRoleBinding
角色绑定用于将角色与一个或一组用户进行绑定，从而实现将对用户进行授权的目的。主体分为用户、组和服务帐户。
角色绑定也分为角色普通角色绑定和集群角色绑定。角色绑定只能引用同一个命名空间下的角色。
在下面的例子中，在 default 命名空间中角色绑定将 dai用户和 pod-reader 角色进行了绑定，这就授予了 dai能够访问 default 命名空间下的 Pod。
k8s-rabc-03
角色绑定也可以通过引用集群角色授予访问权限，当主体对资源的访问仅限与本命名空间，
这就允许管理员定义整个集群的公共角色集合，然后在多个命名空间中进行复用。
例如，下面的角色绑定引用了集群角色，但是 dai 用户也仅仅只能读取default命名空间中的secret资源：
k8s-rabc-04
集群角色可以被用来在集群层面和整个命名空间进行授权。下面的示例允许在yunwei组的用户能够访问所有命名空间中的保密字典资源。
k8s-rabc-05
1.3、资源
在Kubernets中，主要的资源包括：Pods、Nodes、Services、Deployment、Statefulsets、Namespace、Secrets和ConfigMaps等。
下面的例子显示， pod-reader 角色能够对 pods 和 pods/log 进行访问：
k8s-rabc-06
也可以通过 resourceNamess 指定特定的资源实例，以限制角色只能够对实例进行访问控制：
k8s-rabc-07
1.4、主体
RBAC授权中的主体可以是组，用户或者服务帐户。用户通过字符串表示，比如“dai”、 “dai@example.com”等，具体的形式取决于管理员在认证模块中所配置的用户名。
system: 被保留作为用来 Kubernetes 系统使用，因此不能作为用户的前缀。组也有认证模块提供，格式与用户类似。
在角色绑定主体的例子：
名称为 “dai@example.com”用户：
subjects:
- kind: User
name: "dai@example.com"
apiGroup: rbac.authorization.k8s.io
名称为“frontend-admins”的组：
subjects:
- kind:Group
name:"yunwei"
apiGroup:rbac.authorization.k8s.io
在 yunwei-test命名空间中，名称为“yunwei”的服务帐户：
subjects:
- kind: ServiceAccount
name: yunwei-test
namespace: yunwei
在“default”命名空间中，所有的服务帐户：
subjects:
- kind:Group
name:system:serviceaccounts:default
apiGroup:rbac.authorization.k8s.io
所有的服务帐户：
subjects:
- kind:Group
name:system:serviceaccounts
apiGroup:rbac.authorization.k8s.io
在生产环境中为避免在发布过程中频繁调用同命名空间的不同serviceaccount(华为云cce集群的不同namespace下貌似只能有一个serviceaccount)，而需要经常修改发布脚本关于k8s的认证，如secrets的token，所以JSNing一般将system:serviceaccounts:{namespace}与相应角色进行绑定
如下图所示，hello命名空间下的默认服务账号default，其对应secrets为default-token-cjg4v:
k8s-rabc-08
在hello命名空间中，诸如涉及发布的gitlab-ci、jenkins等服务的认证以及各种插件都需要以default 服务帐户进行运行。为了允许超级用户访问这些插件，方便起见会在 hello命名空间中授予 cluster-admin 角色给 default 帐户:
kubectl create clusterrolebinding hello-cluster-admin --clusterrole=cluster-admin --serviceaccount=hello:default
k8s-rabc-09
如果对访问权限不太重视，可以授予超级用户访问所有的服务帐户:
kubectl create clusterrolebinding all-cluster-admin \
--clusterrole=cluster-admin \
--group=system:serviceaccounts
网友评论