kubernetes系列之《k8s基于RBAC的授权》

一、RBAC介绍
基于角色的访问控制（Role-Based Access Control，即“RBAC”）使用“rbac.authorization.k8s.io” Apo Group实现授权决策，允许管理员通过Kubernetes Api动态配置策略。
要启用RBAC，请使用 --authorization-mode=RBAC启动API Server。

在RABC API中，通过如下的步骤进行授权：

1）定义角色：在定义角色时会指定此角色对于资源的访问控制的规则；
2）绑定角色：将主体与角色进行绑定，对用户进行访问授权。

1.1、角色和集群角色
在RBAC API中，角色包含代表权限集合的规则。在这里，权限只有被授予，而没有被拒绝的设置。
在Kubernetes中有两类角色，即普通角色和集群角色。可以通过Role定义在一个命名空间中的角色，或者可以使用ClusterRole定义集群范围的角色。一个角色只能被用来授予访问单一命名空间中的资源。
下面是在“default”命名空间中定义了一个名为“pod_reader”的角色，此角色能够对在“default”命名空间中访问Pod：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
namespace: default
name: pod-reader
rules:

• apiGroups: [""] # 空字符串""表明使用core API group
  resources: [“pods”]
  verbs: [“get”, “watch”, “list”]
  集群角色（ClusterRole）能够被授予如下资源的权限：

集群范围资源（例如Node）
非集群类型endpoint（例如“/healthz”）
集群中所有命名空间的资源（例如Pod）
下面是授予集群角色读取secret文件访问权限的例子：

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:

鉴于ClusterRole是集群范围对象，所以这里不需要定义"namespace"字段

name: secret-reader
rules:

• apiGroups: [""]
  resources: [“secrets”] # 明确资源类型
  verbs: [“get”, “watch”, “list”]
  1.2、角色绑定和集群角色绑定
  角色绑定用于将角色与一个或一组用户进行绑定，从而实现将对用户进行授权的目的。主题分为用户、组和服务账户。角色绑定也分为角色绑定和集群角色绑定，角色绑定只能应用同一个命名空间下的角色。

在下面例子中，在“default”命名空间中角色绑定将“jane”用户和“pod-reader”角色进行了绑定，这就授予了“jane”能够访问default命名空间下的Pod：

以下角色绑定定义将允许用户"jane"从"default"命名空间中读取pod。

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: read-pods
namespace: default
subjects: # 主体

• kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
  roleRef: # 引用的角色
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
  注解：给用户jane授权一个能读取Pod的角色权限

角色绑定也可以通过引用集群角色授予访问权限，当主体对资源的访问仅限于本命名空间，这就允许管理员定义这个呢个集群的公共角色集合，然后在多个命名空间中进行复用。
例如，下面的角色绑定引用了集群角色，但是“dave”用户也仅仅只能读取“development”命名空间中的secrets资源：

以下角色绑定允许用户"dave"读取"development"命名空间中的secret。

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: read-secrets
namespace: development # 这里表明仅授权读取"development"命名空间中的资源。
subjects:

• kind: User
  name: dave
  apiGroup: rbac.authorization.k8s.io
  roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io
  注解：给用户dave授权一个能读取secret的集群角色权限

集群角色可以被用在集群层面和整个命名空间进行授权。下面的示例允许在“manager”组中的用户能够访问所有命名空间中的secret资源。

以下ClusterRoleBinding对象允许在用户组"manager"中的任何用户都可以读取集群中任何命名空间中的secret。

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
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
  注解：给用户组manager授权一个能读取secret的集群角色权限

1.3、对资源的引用
在Kubernetes中，主要的资源包括：Pods、Nodes、Services、Deployment、Replicasets、Statefulsets、Namespace、Persistents、Secrets和ConfigMap等。另外，有些资源下面存在“子资源”，例如：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/v1beta1
metadata:
namespace: default
name: pod-and-pod-logs-reader
rules:

• apiGroups: [""]
  resources: [“pods”, “pods/log”]
  verbs: [“get”, “list”]
  也可以通过resourceNames指定特定的资源实例，以限制角色只能够对实例进行访问控制：

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.4、主体（subject）
  RBAC授权中的主体可以是组、用户、服务账户。用户通过字符串表示，比如“alice”、“[email protected]”等，具体形式取决于管理员在认证模块中配置的用户名。
  system：被保留作为用来Kubernetes系统使用，因此不能作为用户的前缀。组也有认证模块提供，格式与用户类似。

角色绑定主体的例子：
名称为“[email protected]”用户：

subjects:

• kind: User
  name: “[email protected]”
  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
  二、命令行工具
  Kubernetes可以通过命令进行角色绑定

2.1、kubectl create rolebinding
在指定的命名空间中进行角色绑定：
1、在“acme”命名空间中，将“admin”集群角色授予“bob”用户

$ kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme
2、在“acme”命名空间中，将“view”集群角色授予“acme:myapp”服务账户：

$ kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme
2.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
2.3、服务账户（Service Account）权限
默认情况下，RBAC策略授予控制板组件、Node和控制器作用域的权限，但是未授予“kube-system”命名空间外服务账户的访问权限。这就允许管理员按照需求将特定角色授予服务账户。

从最安全到最不安全的顺序，方法如下：
1、授予角色给一个指定应用的服务账户（最佳实践）
这要求在Pod规范（pod spec）中指定serviceAccountName字段，同时要创建此服务账户。
例如，在”my-namespace”命名空间中授予服务账户”my-sa”只读权限：

kubectl create rolebinding my-sa-view
–clusterrole=view
–serviceaccount=my-namespace:my-sa
–namespace=my-namespace
2、在某一命名空间中授予”default”服务账号一个角色
如果应用没有指定serviceAccountName，那么默认将使用“default”服务账户。
下面的例子将在”my-namespace”命名空间内授予”default”服务账号只读权限：

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”命名空间中的所有服务账户只读权限：

kubectl create rolebinding serviceaccounts-view
–clusterrole=view
–group=system:serviceaccounts:my-namespace
–namespace=my-namespace
4、对集群范围内的所有服务账户授予一个受限角色（不推荐）
如果不想管理每个命名空间的权限，则可以将集群范围角色授予所有服务帐户。
下面的例子将所有命名空间中的只读权限授予集群中的所有服务账户：

kubectl create clusterrolebinding serviceaccounts-view
–clusterrole=view
–group=system:serviceaccounts
5、授予超级用户访问权限给集群范围内的所有服务帐户（强烈不鼓励）
如果您根本不关心权限分块，您可以对所有服务账户授予超级用户访问权限。
警告：这种做法将允许任何具有读取权限的用户访问secret或者通过创建一个容器的方式来访问超级用户的凭据。

kubectl create clusterrolebinding serviceaccounts-cluster-admin
–clusterrole=cluster-admin
–group=system:serviceaccounts
2.4、宽松的RBAC权限
下面的策略允许所有的服务账户作为集群管理员。在容器运行的应用将自动收取到服务账户证书，并执行所有API行为。包括查看secret和修改权限，不推荐这种访问权限。

kubectl create clusterrolebinding permissive-binding
–clusterrole=cluster-admin
–user=admin
–user=kubelet
–group=system:serviceaccounts
三、RBAC 实战
K8s的用户和权限管理包括两个方面：认证和授权。认证解决用户是谁的问题，授权解决用户能做什么的问题。通过合理的权限管理，能够保证系统的安全可靠。

K8s的认证包含以下3种方式。这3种方式可以同时存在，认证时只按一种即可。

证书认证：设置apiserver的启动参数：–client_ca_file=SOMEFILE。
Token认证：设置apiserver的启动参数：–token_auth_file=SOMEFILE。
基本信息认证：设置apiserver的启动参数：–basic_auth_file=SOMEFILE。
实战目的：让名为“nicksors”的用户只能有权限访问指定namespace下的Pod

3.1、安装证书生成工具cfssl
使用此工具进行自签证书

$ wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64
$ wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
$ wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64
$ chmod +x cfssl_linux-amd64 cfssljson_linux-amd64 cfssl-certinfo_linux-amd64
$ mv cfssl_linux-amd64 /usr/local/bin/cfssl
$ mv cfssljson_linux-amd64 /usr/local/bin/cfssljson
$ mv cfssl-certinfo_linux-amd64 /usr/bin/cfssl-certinfo
3.2、签发用户证书
使用Kubernetes集群里原有CA证书对用户证书进行签发，如果不使用原有集群的CA证书签发的话集群不认；
集群根证书路径在：/opt/kubernetes/ssl/（我的是在这里，以你的证书路径为准哈）
确保有如下CA证书文件：

ca-config.json ca-key.pem ca.pem
生成用户nicksors的证书：

[[email protected] rbac]# cat nicksors_cert.sh
[[email protected] rbac]# cat nicksors_cert.sh
#!/bin/bash

export SSL_DIR=/opt/kubernetes/ssl/

创建用户“nicksors”证书

cat > nicksors-csr.json <<EOF
{
“CN”: “nicksors”,
“hosts”: [],
“key”: {
“algo”: “rsa”,
“size”: 2048
},
“names”: [
{
“C”: “CN”,
“L”: “BeiJing”,
“ST”: “BeiJing”,
“O”: “k8s”,
“OU”: “System”
}
]
}
EOF
cfssl gencert -ca= ${SSL_DIR}/ca.pem -ca-key=$SSLD​IR/ca.pem−ca−key={SSL_DIR}/ca-key.pem -config=${SSL_DIR}/ca-config.json -profile=kubernetes nicksors-csr.json | cfssljson -bare nicksors
[[email protected] rbac]# sh nicksors_cert.sh
2019/05/29 12:14:14 [INFO] generate received request
2019/05/29 12:14:14 [INFO] received CSR
2019/05/29 12:14:14 [INFO] generating key: rsa-2048
2019/05/29 12:14:14 [INFO] encoded CSR
2019/05/29 12:14:14 [INFO] signed certificate with serial number 241710936734166826753488524447632489452920840015
2019/05/29 12:14:14 [WARNING] This certificate lacks a “hosts” field. This makes it unsuitable for
websites. For more information see the Baseline Requirements for the Issuance and Management
of Publicly-Trusted Certificates, v.1.1.6, from the CA/Browser Forum (https://cabforum.org);
specifically, section 10.2.3 (“Information Requirements”).
执行命令后，生成如下文件：

nicksors_cert.sh nicksors.csr nicksors-csr.json nicksors-key.pem nicksors.pem
3.3、创建kubeconfig文件
export KUBE_APISERVER=“https://172.16.194.128:6443”
export SSL_DIR=/opt/kubernetes/ssl/

设置集群参数

kubectl config set-cluster kubernetes
–certificate-authority=KaTeX parse error: Undefined control sequence: \ at position 18: …SL_DIR}/ca.pem \̲ ̲--embed-certs=t…{KUBE_APISERVER}
–kubeconfig=nicksors.kubeconfig

设置客户端认证参数

kubectl config set-credentials nicksors
–client-certificate=KaTeX parse error: Undefined control sequence: \ at position 24: …}/nicksors.pem \̲ ̲--client-key={SSL_DIR}/nicksors-key.pem
–embed-certs=true
–kubeconfig=nicksors.kubeconfig

设置上下文参数

kubectl config set-context kubernetes
–cluster=kubernetes
–user=nicksors
–namespace=kube-system
–kubeconfig=nicksors.kubeconfig

设置默认上下文

kubectl config use-context kubernetes --kubeconfig=nicksors.kubeconfig
以上执行一个步骤就可以看一下 nicksors.kubeconfig 的变化。里面最主要的三个东西

cluster: 集群信息，包含集群地址与公钥
user: 用户信息，客户端证书与私钥，真正的信息是从证书里读取出来的，人能看到的只是给人看的。
context: 维护一个三元组，namespace cluster 与 user
3.4、创建角色
创建一个叫pod-reader的角色（见名思意：Pod只读）

cat >pod-reader.yaml <<EOF
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: kube-system

角色默认的命令空间为kube-system，如果user绑定到此角色，那么此角色只有在命令空间的权限

name: pod-reader
rules:

• apiGroups: [""] # “” indicates the core API group
  resources: [“pods”]
  verbs: [“get”, “watch”, “list”]
  EOF
  执行并查看执行结果：

[[email protected] rbac]# kubectl apply -f pod-reader.yaml
role.rbac.authorization.k8s.io/pod-reader created
[[email protected] rbac]# kubectl get role -n kube-system|grep pod-reader
pod-reader 43s
3.5、用户绑定角色
上面创建好了一个pod-reader角色，只有查看kube-system的权限，将这个角色绑定到nicksors用户上；

cat >nicksors-role-bind.yaml <<EOF
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: read-pods
namespace: kube-system
subjects:

• kind: User
  name: nicksors # 目标用户
  apiGroup: rbac.authorization.k8s.io
  roleRef:
  kind: Role
  name: pod-reader # 角色信息
  apiGroup: rbac.authorization.k8s.io
  EOF
  执行并查看执行结果：

[[email protected] rbac]# kubectl apply -f nicksors-role-bind.yaml
rolebinding.rbac.authorization.k8s.io/read-pods created
[[email protected] rbac]# kubectl get rolebinding -n kube-system|grep read-pods
read-pods 33s
3.6、使用新的config文件
cp -f ./nicksors.kubeconfig /root/.kube/config
测试使用：

[[email protected] rbac]# kubectl get pod # 默认获取kube-system命名空间的pod
NAME READY STATUS RESTARTS AGE
coredns-55f46dd959-85qgd 1/1 Running 0 5d19h
coredns-55f46dd959-czkgm 1/1 Running 0 5d19h
kubernetes-dashboard-7d5f7c58f5-dlmcv 1/1 Running 0 5d19h
[[email protected] rbac]# kubectl get pod -n kube-system
NAME READY STATUS RESTARTS AGE
coredns-55f46dd959-85qgd 1/1 Running 0 5d19h
coredns-55f46dd959-czkgm 1/1 Running 0 5d19h
kubernetes-dashboard-7d5f7c58f5-dlmcv 1/1 Running 0 5d19h
[[email protected] rbac]# kubectl get pod -n default # 可以看到指定其他命名空间获取Pod失败，没有权限了
Error from server (Forbidden): pods is forbidden: User “nicksors” cannot list resource “pods” in API group “” in the namespace “default”
[[email protected] rbac]#
[[email protected] rbac]# kubectl get deploy # 尝试查看其他资源也失败，因为nicksors用户只绑定了pod-reader权限
Error from server (Forbidden): deployments.extensions is forbidden: User “nicksors” cannot list resource “deployments” in API group “extensions” in the namespace “kube-system”
[[email protected] rbac]# kubectl get node Error from server (Forbidden): nodes is forbidden: User “nicksors” cannot list resource “nodes” in API group “” at the cluster scope