Kubernetes 基於 RBAC 的受權(十六)

目錄

• 1、RBAC介紹
  • 1.一、角色和集羣角色
  • 1.二、RoleBinding 和 ClusterRoleBinding
  • 1.三、資源
  • 1.四、主體
• 2、命令行工具
  • 2.一、kubectl create rolebinding
  • 2.二、kubectl create clusterrolebinding
• 3、服務賬戶權限

1、RBAC介紹

在Kubernetes中，受權有ABAC（基於屬性的訪問控制）、RBAC（基於角色的訪問控制）、Webhook、Node、AlwaysDeny（一直拒絕）和AlwaysAllow（一直容許）這6種模式。
從1.6版本起，Kubernetes 默認啓用RBAC訪問控制策略。從1.8開始，RBAC已做爲穩定的功能。經過設置--authorization-mode=RBAC，啓用RABC。在RABC API中，經過以下的步驟進行受權：
定義角色：在定義角色時會指定此角色對於資源的訪問控制的規則；
綁定角色：將主體與角色進行綁定，對用戶進行訪問受權。

1.一、角色和集羣角色

在 RBAC API 中，角色包含表明權限集合的規則。在這裏，權限只有被授予，而沒有被拒絕的設置。在 Kubernetes 中有兩類角色，即普通角色(Role)和集羣角色(ClusterRole)。能夠經過Role定義在一個命名空間中的角色，或者可使用ClusterRole定義集羣範圍的角色。一個Role只能被用來授予訪問單一命令空間中的資源。下面是在 default 命令空間中定義了一個名爲 pod-reader 的角色，此角色可以對在 default 命名空間中訪問 Pod：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

ClusterRole可用於授予與Role相同的權限。他們可以被授予以下資源的權限：

• 集羣範圍的資源（相似於Node）
• 非資源端點（相似於」/healthz」）
• 集羣中全部命名空間的資源（相似Pod）

下面的ClusterRole可用於授予對任何特定namespaces中的祕密的讀取訪問權限，或跨全部命名空間的訪問權限。

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  # "namespace" omitted since ClusterRoles are not namespaced
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

1.二、RoleBinding 和 ClusterRoleBinding

角色綁定用於將角色與一個或一組用戶進行綁定，從而實現將對用戶進行受權的目的。主體分爲用戶、組和服務賬戶。角色綁定也分爲角色普通角色綁定和集羣角色綁定。角色綁定只能引用同一個命名空間下的角色。
在下面的例子中，在 default 命名空間中角色綁定將 jane 用戶和 pod-reader 角色進行了綁定，這就授予了 jane 可以訪問 default 命名空間下的 Pod。

# This role binding allows "jane" to read pods in the "default" namespace.
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role #this must be Role or ClusterRole
  name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
  apiGroup: rbac.authorization.k8s.io

角色綁定也能夠經過引用集羣角色授予訪問權限，當主體對資源的訪問僅限與本命名空間，這就容許管理員定義整個集羣的公共角色集合，而後在多個命名空間中進行復用。
例如，下面的角色綁定引用了集羣角色，可是 dave 用戶也僅僅只能讀取 development 命名空間中的 secret s資源：

# This role binding allows "dave" to read secrets in the "development" namespace.
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-secrets
  namespace: development # This only grants permissions within the "development" namespace.
subjects:
- kind: User
  name: dave # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

集羣角色能夠被用來在集羣層面和整個命名空間進行受權。下面的示例容許在 manager 組的用戶可以訪問全部命名空間中的保密字典資源。

# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind:ClusterRoleBinding
apiVersion:rbac.authorization.k8s.io/v1
metadata:
  name:read-secrets-global
subjects:
- kind:Group
  name:manager
  apiGroup:rbac.authorization.k8s.io
roleRef:
  kind:ClusterRole
  name:secret-reader
  apiGroup:rbac.authorization.k8s.io

1.三、資源

在Kubernets中，主要的資源包括：Pods、Nodes、Services、Deployment、Replicasets、Statefulsets、Namespace、Persistents、Secrets和ConfigMaps等。另外，有些資源下面存在子資源，例如：Pod下就存在log子資源：

GET /api/v1/namespaces/{namespace}/pods/{name}/log

下面的例子顯示， pod-and-pod-logs-reader 角色可以對 pods 和 pods/log 進行訪問：

kind:Role
apiVersion:rbac.authorization.k8s.io/v1
metadata:
 namespace:default
 name:pod-and-pod-logs-reader
rules:
- apiGroups:[""]
  resources:["pods","pods/log"]
  verbs:["get","list"]

也能夠經過 resourceNamess 指定特定的資源實例，以限制角色只可以對實例進行訪問控制：

kind:Role
apiVersion:rbac.authorization.k8s.io/v1
metadata:
  namespace:default
  name:configmap-updater
rules:
- apiGroups:[""]
  resources:["configmaps"]
  resourceNames:["my-configmap"]
  verbs:["update","get"]

1.四、主體

RBAC受權中的主體能夠是組，用戶或者服務賬戶。用戶經過字符串表示，好比「alice」、 「bob@example.com」等，具體的形式取決於管理員在認證模塊中所配置的用戶名。system: 被保留做爲用來 Kubernetes 系統使用，所以不能做爲用戶的前綴。組也有認證模塊提供，格式與用戶相似。

在角色綁定主體的例子：

名稱爲 「alice@example.com」用戶：

subjects:
- kind:User
  name:"alice@example.com"
  apiGroup:rbac.authorization.k8s.io

名稱爲「frontend-admins」的組：

subjects:
- kind:Group
  name:"frontend-admins"
  apiGroup:rbac.authorization.k8s.io

在 kube-system 命名空間中，名稱爲「default」的服務賬戶：

subjects:
- kind:ServiceAccount
  name:default
  namespace:kube-system

在「qa」命名空間中，全部的服務賬戶：

subjects:
- kind:Group
  name:system:serviceaccounts:qa
  apiGroup:rbac.authorization.k8s.io

全部的服務賬戶：

subjects:
- kind:Group
  name:system:serviceaccounts
  apiGroup:rbac.authorization.k8s.io

全部被認證的用戶 (version 1.5+):

subjects:
- kind:Group
  name:system:authenticated
  apiGroup:rbac.authorization.k8s.io

全部未被認證的用戶 (version 1.5+):

subjects:
- kind:Group
  name:system:unauthenticated
  apiGroup:rbac.authorization.k8s.io

全部用戶(version 1.5+):

subjects:
- kind:Group
  name:system:authenticated
  apiGroup:rbac.authorization.k8s.io
- kind:Group
  name:system:unauthenticated
  apiGroup:rbac.authorization.k8s.io

2、命令行工具

Kubernetes能夠經過命令工具進行角色綁定。

2.一、kubectl create rolebinding

在指定的命名空間中進行角色綁定：

1）在acme命名空間中，將admin集羣角色授予bob用戶：

$ kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme

2）在acme命名空間中，將admin集羣角色授予acme:myapp服務賬戶：

$ kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme

2.二、kubectl create clusterrolebinding

在整個集羣中進行角色綁定：

1）在整個集羣中，授予cluster-admin集羣角色給root用戶：

$ kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root

2）在整個集羣中，授予system:node集羣角色給kubelet用戶：

$ kubectl create clusterrolebinding kubelet-node-binding --clusterrole=system:node --user=kubelet

3）在整個集羣中，授予view集羣角色給acme:myapp服務賬戶：

$ kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp

3、服務賬戶權限

默認狀況下，RBAC策略授予控制板組件、Node和控制器做用域的權限，可是未授予kube-system命名空間外服務賬戶的訪問權限。這就容許管理員按照須要將特定角色授予服務賬戶。

從最安全到最不安全的順序，方法以下：

• 1）授予角色給一個指定應用的服務賬戶(最佳實踐)

這要求在Pod規格中指定ServiveAccountName，同時此服務賬戶已被建立(經過API、kubectl create serviceaccount等)。例如，在my-namespace命名空間內，授予my-sa服務賬戶view集羣角色：

kubectl create rolebinding my-sa-view \ 
--clusterrole=view \ 
--serviceaccount=my-namespace:my-sa \ 
--namespace=my-namespace

• 2）在一個命名空間授予view集羣角色給default服務賬戶

若是應用沒有指定serviceAccountName，它將使用default服務賬戶。例如，例如，在my-namespace命名空間內，授予default服務賬戶view集羣角色：

kubectl create rolebinding default-view \ 
--clusterrole=view \ 
--serviceaccount=my-namespace:default \ 
--namespace=my-namespace

當前，在 kube-system 命名空間中，不少插件做爲 default 服務賬戶進行運行。爲了容許超級用戶訪問這些插件，在 kube-system 命名空間中授予 cluster-admin 角色給 default 賬戶。

$ kubectl create clusterrolebinding add-on-cluster-admin \ 
--clusterrole=cluster-admin \ 
--serviceaccount=kube-system:default

• 3）在一個命名空間中，授予角色給全部的服務賬戶：

若是但願在一個命名空間中的全部應用都擁有一個角色，而無論它們所使用的服務賬戶，能夠授予角色給服務賬戶組。例如，在 my-namespace 命名空間中，將 view 集羣角色授予 system:serviceaccounts:my-namespace 組：

$ kubectl create rolebinding serviceaccounts-view \ 
--clusterrole=view \ 
--group=system:serviceaccounts:my-namespace \ 
--namespace=my-namespace

• 4）在整個集羣中授予一個角色給全部的服務賬戶 (不推薦)

若是不想按照每一個命名空間管理權限，能夠在整個集羣的訪問進行受權。例如，在整個集羣層面，將 view 集羣角色授予 sytem:serviceaccounts ：

$ kubectl create clusterrolebinding serviceaccounts-view \ 
--clusterrole=view \ 
--group=system:serviceaccounts

• 5）在整個集羣中授予超級用戶訪問全部的服務賬戶 (強烈不推薦)

若是對訪問權限不過重視，能夠授予超級用戶訪問全部的服務賬戶。

$ kubectl create clusterrolebinding serviceaccounts-cluster-admin \ 
--clusterrole=cluster-admin \ 
--group=system:serviceaccounts

• 6）寬鬆的RBAC權限

下面的策略容許全部的服務賬戶做爲集羣管理員。在容器中運行的應用將自動的收取到服務賬戶證書，並執行全部的API行爲。包括查看保密字典恩將和修改權限，這是不被推薦的訪問策略。

$ kubectl create clusterrolebinding permissive-binding \ 
--clusterrole=cluster-admin \ 
--user=admin \ 
--user=kubelet \ 
--group=system:serviceaccounts

官方文檔：https://kubernetes.io/docs/reference/access-authn-authz/rbac/