关于Kubernetes的RBAC

1 年 ago

清, 宇

2 minutes

RBAC 是 Role-Based Access Control 的缩写。

RBAC（基于角色的访问控制）是一种基于角色的访问控制功能。

RBAC资源有四种资源，分别是角色资源、集群角色资源、角色绑定资源和集群角色绑定资源。

RoleとClusterRoleは、どのリソースにどんな操作を許可するかを定義するためのリソース

RoleBindingとClusterRoleBindingはどのRole/ClusterRoleをどのUserやServiceAcctountに紐付けるかを定義するためのリソース。

ユーザは以下のようにkubectl config set-credentialsを使って作成できる

kubectl config set-credentials alice –username=alice –password=password
参考： kubernetesがサポートする認証方法の全パターンを動かす

资源和操作是什么？

Kubernetesのリソースを指す。例えばPod, Deployment, Service, Secret etc..

操作とは

get, create, update, delete, list, watch, deletecollection などがある。

操作列表

種別内容*全ての処理create作成delete削除get取得list一覧取得update更新patch一部変更watch変更の追従

Role 和 ClusterRole 的区别，以及 RoleBinding 和 ClusterRoleBinding 的区别。

Role和ClusterRole的区别，以及RoleBinding和ClusterRoleBinding的区别在于，Role/RoleBinding属于特定的命名空间，而ClusterRole/ClusterRoleBinding不属于命名空间（属于集群级资源）。

namespaceに属するnamespaceに属さないRole◯
Cluster Role
◯RoleBinding◯
ClusterRoleBinding
◯

默认提供的集群角色

ClusterRoleにはいくつかデフォルトClusterRoleが用意されている。そのためざっくりとした権限でいい場合は新規でRoleやClusterRoleを作成せずにデフォルトClusterRoleを使うことができる。(参考)

デフォルトClusterRole名内容cluster-admin全てのリソースに対しどんなアクションでも可能。
ClusterRoleBindingを使うと、clusterの全てのリソースにたいしてどんなアクションでも可能になる。
RoleBindingを使うとそのnamespaceの全てのリソースにたいしてどんなアクションでも可能になる(namespaceリソース含む)。adminRoleBindingを使ってbindingがされることを期待されているClusterRole。
namespace内のほとのどのリソースに対してread/writeができる。
またそのnamespace内のRole/RoleBindingリソースのwrite権限も有する。
しかしResourceQuotaとnamespace自身にはwriteできない。editほとんどのリソースのread writeができるが、Role/RoleBindingのreadやwriteはできないviewほとんどのリソースのread ができるが、Role/RoleBinding、そしてSecretのreadはできない

集群角色聚合

自Kubernetes 1.9版本开始，您可以使用聚合功能将多个ClusterRole定义加载到ClusterRole中。聚合根据设置在ClusterRole上的标签进行操作，但不会反映在聚合发送的ClusterRole上的规则。更多详细信息，请参阅这里。

在中国本土将以下内容改写为中文：

Role和RoleBinding的创建示例

创建角色

以下はServiceリソースをget, listできる権限を表したRole

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: hoge-ns
  name: service-reader-role
rules:
- apiGroups:
  - apps
  - extensions
  resources:
  - deployments
  - services
  verbs:
  - "get"
  - "list"

使用kubectl命令创建my-reader-role.yaml文件中的Role角色。

创建一个角色绑定

Role: my-reader-roleをServiceAccount: my-app-saに紐付けるためのRoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: service-reader-rolebinding
  namespace: hoge-ns
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: my-reader-role
subjects:
- kind: ServiceAccount
  name: my-app-sa
  namespace: hoge-ns

使用`kubectl create -f my-reader-rolebinding.yaml`命令创建RoleBinding。

ServiceAccountについて

namespaceを1つ作るとdefaultという名前のServiceAccountが自動的に作成される。
Kubernetesクラスタを作るとdefaultというnamespaceが自動で作成されるが、そのnamespaceに属するdefaultという名前のServiceAccountも自動で作成される。podを作成すると紐付けるServiceAccountに指定がなければdefaultのServiceAccountが紐付けられる。

defaultのServiceAccount以外にも新しくServiceAccountを手動で作成することができ、podに紐付けることができる

たとえばWebアプリケーション用のServiceAccountを作成し、そのWebアプリケーション用Podに作成したServiceAccountを紐付け、そのServiceAccountにKubernetesリソースの参照のみを許可することができる。

其他建议

どんな時にRole/RoleBindingとClusterRole/ClusterRoleBindingを使えばいいかは以下を参考にすればよい

アクセス制限対象Role種類Binding種類Cluster-level resources (Nodes, PersistentVolumes, …)ClusterRoleClusterRoleBindingNon-resource URLs (/api, /healthz, …)ClusterRoleClusterRoleBindingいくつかのnamespace、もしくは全てのnamespaceに存在するNamespaced resourcesClusterRoleClusterRoleBinding特定のnamespaceに存在するNamespaced resources。(共通のRoleを使いたい場合)ClusterRoleRoleBinding特定のnamespaceに存在するNamespaced resources。(namespaceごとにRoleを定義する場合)RoleRoleBinding

もしminikube上でRBACを有効にしたい場合は、minikube起動時に、–extra-config=apiserver.Authorization.Mode=RBACを指定する必要がある。

请查看：

Kubernetes in Action (最高に分かりやすく書かれているのでぜひ買いましょう)
Using RBAC Authorization
Kubernetes Engine: 役割ベースのアクセス制御
Kubernetes in Action
Kubernetes Cookbook
Configure RBAC In Your Kubernetes Cluster