目录
- Kubernetes之（十五）身份认证，授权，准入控制
- ServiceAccount
- 创建serviceaccount
- 自定义serviceaccount
- 自建证书和账号进行访问apiserver
- RBAC简介
- Kubernetes RBAC演示
- RBAC的三种授权访问
- ServiceAccount
Kubernetes之（十五）身份认证，授权，准入控制
API Server作为Kubernetes网关，是访问和管理资源对象的唯一入口，其各种集群组件访问资源都需要经过网关才能进行正常访问和管理。每一次的访问请求都需要进行合法性的检验，其中包括身份验证、操作权限验证以及操作规范验证等，需要通过一系列验证通过之后才能访问或者存储数据到etcd当中。如下图：
ServiceAccount
Service account是为了方便Pod里面的进程调用Kubernetes API或其他外部服务而设计的。它与User account不同:
- User account是为人设计的，而service account则是为Pod中的进程调用Kubernetes API而设计
- User account是跨namespace的，而service account则是仅局限它所在的namespace
- 每个namespace都会自动创建一个default service account
- Token controller检测service account的创建，并为它们创建secret
- 开启ServiceAccount Admission Controller后
- 每个Pod在创建后都会自动设置spec.serviceAccount为default（除非指定了其他ServiceAccout）
- 验证Pod引用的service account已经存在，否则拒绝创建
- 如果Pod没有指定ImagePullSecrets，则把service account的ImagePullSecrets加到Pod中
- 每个container启动后都会挂载该service account的token和ca.crt到/var/run/secrets/kubernetes.io/serviceaccount/
当创建 pod 的时候，如果没有指定一个 service account，系统会自动在与该pod 相同的 namespace 下为其指派一个default service account。而pod和apiserver之间进行通信的账号，称为serviceAccountName。如下:
[[email protected] manifests]# kubectl get pods
NAME READY STATUS RESTARTS AGE
myapp-0 1/1 Running 0 16h
myapp-1 1/1 Running 0 16h
myapp-2 1/1 Running 0 16h
myapp-3 1/1 Running 0 16h
[[email protected] manifests]# kubectl get pods myapp-0 -o yaml|grep serviceAccountName
serviceAccountName: default
[[email protected] manifests]# kubectl describe pods myapp-0
......
default-token-dqd2f:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-dqd2f
......每个Pod无论定义与否都会有个存储卷，这个存储卷为default-token-*** token令牌，这就是pod和serviceaccount认证信息。通过secret进行定义，由于认证信息属于敏感信息，所以需要保存在secret资源当中，并以存储卷的方式挂载到Pod当中。从而让Pod内运行的应用通过对应的secret中的信息来连接apiserver，并完成认证。每个 namespace 中都有一个默认的叫做 default 的 service account 资源。进行查看名称空间内的secret，也可以看到对应的default-token。让当前名称空间中所有的pod在连接apiserver时可以使用的预制认证信息，从而保证pod之间的通信。
[[email protected] manifests]# kubectl get sa
NAME SECRETS AGE
default 1 7d21h
[[email protected] manifests]# kubectl get sa -n ingress-nginx #所有的名称空间都存在name是default的serviceAccount
NAME SECRETS AGE
default 1 2d20h
nginx-ingress-serviceaccount 1 2d5h
[[email protected] manifests]# kubectl get secret
NAME TYPE DATA AGE
default-token-dqd2f kubernetes.io/service-account-token 3 7d21h
mysql-root-password Opaque 1 23h
tomcat-ingress-secret kubernetes.io/tls 2 2d3h
[[email protected] manifests]# kubectl get secret -n ingress-nginx
NAME TYPE DATA AGE
default-token-fkw6s kubernetes.io/service-account-token 3 2d20h
nginx-ingress-serviceaccount-token-jvlq9 kubernetes.io/service-account-token 3 2d5h默认的service account 仅仅只能获取当前Pod自身的相关属性，无法观察到其他名称空间Pod的相关属性信息。如果想要扩展Pod，假设有一个Pod需要用于管理其他Pod或者是其他资源对象，是无法通过自身的名称空间的serviceaccount进行获取其他Pod的相关属性信息的，此时就需要进行手动创建一个serviceaccount，并在创建Pod时进行定义。那么serviceaccount该如何进行定义呢？？？实际上，service accout也属于一个kubernetes资源，如下查看service account的定义方式：
[[email protected] ~]# kubectl explain sa.
KIND: ServiceAccount
VERSION: v1
FIELDS:
apiVersion <string>
imagePullSecrets <[]Object>
kind <string>
metadata <Object>
secrets <[]Object>创建serviceaccount
[[email protected] manifests]# kubectl create serviceaccount mysa -o yaml --dry-run #干跑模式，类似ansible的-C检查语法
apiVersion: v1
kind: ServiceAccount
metadata:
creationTimestamp: null
name: mysa
[[email protected] manifests]# kubectl create serviceaccount mysa -o yaml --dry-run > serviceaccount.yaml #保存为yaml文件，
[[email protected] manifests]# cat serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
creationTimestamp: null
name: mysa
[[email protected] manifests]# kubectl get sa mysa -o yaml
apiVersion: v1
kind: ServiceAccount
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"v1","kind":"ServiceAccount","metadata":{"annotations":{},"creationTimestamp":null,"name":"mysa","namespace":"default"}}
creationTimestamp: "2019-04-04T06:23:58Z"
name: mysa
namespace: default
resourceVersion: "273220"
selfLink: /api/v1/namespaces/default/serviceaccounts/mysa
uid: 3ab9e525-56a2-11e9-80a7-000c295ec349
secrets:
- name: mysa-token-cxlvc看到有一个 token 已经被自动创建，并被 service account 引用。设置非默认的 service account，只需要在 pod 的spec.serviceAccountName 字段中将name设置为您想要用的 service account 名字即可。在 pod 创建之初 service account 就必须已经存在，否则创建将被拒绝。需要注意的是不能更新已创建的 pod 的 service account。
自定义serviceaccount
在default名称空间创建了一个sa为admin
[[email protected] manifests]# kubectl create sa admin
serviceaccount/admin created
[[email protected] manifests]# kubectl get sa
NAME SECRETS AGE
admin 1 40s
default 1 7d22h
[[email protected] manifests]# kubectl describe sa admin
Name: admin
Namespace: default
Labels: <none>
Annotations: <none>
Image pull secrets: <none>
Mountable secrets: admin-token-sswgb
Tokens: admin-token-sswgb
Events: <none>
[[email protected] manifests]# kubectl get secret
NAME TYPE DATA AGE
admin-token-sswgb kubernetes.io/service-account-token 3 99s
default-token-dqd2f kubernetes.io/service-account-token 3 7d22h
mysql-root-password Opaque 1 23h
tomcat-ingress-secret kubernetes.io/tls 2 2d4h可以看到已经自动生成了一个 Tokens: admin-token-sswgb
[[email protected] manifests]# vim pod-sa-demo.yaml #新建pod引用 Tokens: admin-token-sswgb
apiVersion: v1
kind: Pod
metadata:
name: pod-sa-demo
namespace: default
labels:
app: myapp
tier: frontend
annotations:
white.com/created-by: "cluster admin"
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
ports:
- name: http
containerPort: 80
serviceAccountName: admin #引用刚才创建的sa账户创建并查看
[[email protected] manifests]# kubectl apply -f pod-sa-demo.yaml
pod/pod-sa-demo created
[[email protected] manifests]# kubectl get pods
NAME READY STATUS RESTARTS AGE
myapp-0 1/1 Running 0 21h
myapp-1 1/1 Running 0 21h
myapp-2 1/1 Running 0 21h
myapp-3 1/1 Running 0 21h
pod-sa-demo 1/1 Running 0 2s
[[email protected] manifests]# kubectl describe pods pod-sa-demo
......
Volumes:
admin-token-sswgb: #已经使用藏才创建的admin账户的token
Type: Secret (a volume populated by a Secret)
SecretName: admin-token-sswgb
Optional: false
QoS Class: BestEffort
......在K8S集群当中，每一个用户对资源的访问都是需要通过apiserver进行通信认证才能进行访问的，那么在此机制当中，对资源的访问可以是token，也可以是通过配置文件的方式进行保存和使用认证信息，可以通过kubectl config进行查看配置，如下：
[[email protected] manifests]# kubectl config view
apiVersion: v1
clusters: #集群状态
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://10.0.0.10:6443
name: kubernetes
contexts: #上下文列表
- context: #集群和访问用户的映射
cluster: kubernetes
user: kubernetes-admin
name: [email protected]
current-context: [email protected] #当前上下文
kind: Config
preferences: {}
users: #用户列表
- name: kubernetes-admin
user:
client-certificate-data: REDACTED
client-key-data: REDACTED在上面的配置文件当中，定义了集群、上下文以及用户。其中Config也是K8S的标准资源之一，在该配置文件当中定义了一个集群列表，指定的集群可以有多个；用户列表也可以有多个，指明集群中的用户；而在上下文列表当中，是进行定义可以使用哪个用户对哪个集群进行访问，以及当前使用的上下文是什么。如图：定义了用户kubernetes-admin可以对kubernetes该集群的访问，用户kubernetes-user1对Clluster1集群的访问。
（图片来源：https://www.cnblogs.com/linuxk/）
自建证书和账号进行访问apiserver
生成证书
[[email protected] manifests]# cd /etc/kubernetes/pki/
[[email protected] pki]# (umask 077;openssl genrsa -out white.key 2048)
Generating RSA private key, 2048 bit long modulus
..........................................................+++
................................+++
e is 65537 (0x10001)
[[email protected] pki]# ls -l white.key
-rw------- 1 root root 1679 4月 4 14:49 white.key使用ca.crt 签署证书
[[email protected] pki]# openssl req -new -key white.key -out white.csr -subj "/CN=white" # 证书签署请求
[[email protected] pki]# openssl x509 -req -in white.csr -CA ./ca.crt -CAkey ./ca.key -CAcreateserial -out white.crt -days 365 #证书签署
Signature ok
subject=/CN=white
Getting CA Private Key
[[email protected] pki]# openssl x509 -in white.crt -text -noout
[[email protected] pki]# kubectl config set-credentials white --client-certificate=./white.crt --client-key=./white.key --embed-certs=true
User "white" set.添加到用户认证
[[email protected] pki]# kubectl config set-context [email protected] --cluster=kubernetes --user=white
Context "[email protected]" created.
[[email protected] pki]# kubectl config view
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://10.0.0.10:6443
name: kubernetes
contexts:
- context:
cluster: kubernetes
user: kubernetes-admin
name: [email protected]
- context:
cluster: kubernetes
user: white
name: [email protected]
current-context: [email protected]
kind: Config
preferences: {}
users:
- name: kubernetes-admin
user:
client-certificate-data: REDACTED
client-key-data: REDACTED切换账号
[[email protected] pki]# kubectl config use-context [email protected]
Switched to context "[email protected]".
[[email protected] pki]# kubectl get pods
Error from server (Forbidden): pods is forbidden: User "system:anonymous" cannot list resource "pods" in API group "" in the namespace "default"当切换成magedu用户进行访问集群时，由于magedu该账户没有管理集群的权限，所以在获取pods资源信息时，会提示Forrbidden。那么下面就再来了解一下怎么对账户进行授权.
RBAC简介
Kubernetes的授权是基于插件形式的，其常用的授权插件有以下几种：
- Node（节点认证）
- ABAC(基于属性的访问控制)
- RBAC（基于角色的访问控制）
- Webhook（基于http回调机制的访问控制）
让一个用户（Users）扮演一个角色（Role），角色拥有权限，从而让用户拥有这样的权限，随后在授权机制当中，只需要将权限授予某个角色，此时用户将获取对应角色的权限，从而实现角色的访问控制。如图：
基于角色的访问控制（Role-Based Access Control, 即RBAC）使用”rbac.authorization.k8s.io” API Group实现授权决策，允许管理员通过Kubernetes API动态配置策略。
在k8s的授权机制当中，采用RBAC的方式进行授权，其工作逻辑是 把对对象的操作权限定义到一个角色当中，再将用户绑定到该角色，从而使用户得到对应角色的权限。此种方式仅作用于名称空间当中，这是什么意思呢？当User1绑定到Role角色当中，User1就获取了对该NamespaceA的操作权限，但是对NamespaceB是没有权限进行操作的，如get，list等操作。
另外，k8s为此还有一种集群级别的授权机制，就是定义一个集群角色（ClusterRole），对集群内的所有资源都有可操作的权限，从而将User2，User3通过ClusterRoleBinding到ClusterRole，从而使User2、User3拥有集群的操作权限。Role、RoleBinding、ClusterRole和ClusterRoleBinding的关系如下图:
这里有2种绑定ClusterRoleBinding、RoleBinding。也可以使用RoleBinding去绑定ClusterRole。
当使用这种方式进行绑定时，用户仅能获取当前名称空间的所有权限。为什么这么绕呢？？举例有10个名称空间，每个名称空间都需要一个管理员，而该管理员的权限都是一致的。那么此时需要去定义这样的管理员，使用RoleBinding就需要创建10个Role，这样显得更加繁重。为此当使用RoleBinding去绑定一个ClusterRole时，该User仅仅拥有对当前名称空间的集群操作权限，换句话说，此时只需要创建一个ClusterRole就解决了以上的需求。
注意：RoleBinding仅仅对当前名称空间有对应的权限。
在RBAC API中，一个角色包含了一套表示一组权限的规则。 权限以纯粹的累加形式累积（没有”否定”的规则）。 角色可以由命名空间（namespace）内的Role对象定义，而整个Kubernetes集群范围内有效的角色则通过ClusterRole对象实现。
Kubernetes RBAC演示
1、User --> Rolebinding --> Role
创建角色 一个Role对象只能用于授予对某一单一命名空间中资源的访问权限
语法：
Usage:
kubectl create role NAME --verb=verb --resource=resource.group/subresource
[--resource-name=resourcename] [--dry-run] [options]--verb指定权限，--resource指定资源或者资源组，--dry-run单跑模式并不会创建
[[email protected] manifests]# kubectl create role pods-reader --verb=get,list,watch --resource=pods --dry-run -o yaml #干跑查看定义格式
apiVersion: rbac.authorization.k8s.io/v1
kind: Role #资源类型
metadata:
creationTimestamp: null
name: pods-reader
rules:
- apiGroups: #目标api群组
- ""
resources: #目标资源
- pods
verbs: #操作权限
- get
- list
- watch
[[email protected] manifests]# kubectl create role pods-reader --verb=get,list,watch --resource=pods --dry-run -o yaml > role-demo.yaml
[[email protected] manifests]# vim role-demo.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: pods-reader
namespace: default
rules:
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- list
- watch
#创建用户并查看
[[email protected] manifests]# kubectl apply -f role-demo.yaml
role.rbac.authorization.k8s.io/pods-reader created
[[email protected] manifests]# kubectl get role
NAME AGE
pods-reader 5s
[[email protected] manifests]# kubectl describe role pods-reader
Name: pods-reader
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"rbac.authorization.k8s.io/v1","kind":"Role","metadata":{"annotations":{},"name":"pods-reader","namespace":"default"},"rules...
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
pods [] [] [get list watch] #此处已经定义了pods-reader这个角色对pods资源拥有get、list、watch的权限
角色绑定 RoleBinding可以引用在同一命名空间内定义的Role对象。
语法
Usage:
kubectl create rolebinding NAME --clusterrole=NAME|--role=NAME [--user=username]
[--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run] [options]--role|--clusterrole指定绑定哪个角色，--user指定哪个用户
[[email protected] manifests]# kubectl create rolebinding white-read-pod --role=pods-reader --user=white --dry-run -o yaml>rolebinding-demo.yaml
[[email protected] manifests]# vim rolebinding-demo.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: white-read-pod
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: pods-reader
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: white
[[email protected] manifests]# kubectl apply -f rolebinding-demo.yaml #创建角色绑定
rolebinding.rbac.authorization.k8s.io/white-read-pod created
[[email protected] manifests]# kubectl describe rolebinding white-read-pod
Name: white-read-pod
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"rbac.authorization.k8s.io/v1","kind":"RoleBinding","metadata":{"annotations":{},"creationTimestamp":null,"name":"white-read...
Role:
Kind: Role
Name: pods-reader
Subjects:
Kind Name Namespace
---- ---- ---------
User white #查看角色绑定的信息，这里可以看到user：white绑定到了pods-reader这个角色上
[[email protected] manifests]# kubectl config use-context [email protected] #切换white这个用户，并使用get获取pods资源信息
Switched to context "[email protected]".
[[email protected] manifests]# kubectl get pods
NAME READY STATUS RESTARTS AGE
myapp-0 1/1 Running 0 4d18h
myapp-1 1/1 Running 0 4d18h
myapp-2 1/1 Running 0 4d18h
myapp-3 1/1 Running 0 4d18h
pod-sa-demo 1/1 Running 0 3d21h从上面的操作，可以总结出，role的定义和绑定，仅作用于当前名称空间，在获取ingress-nginx名称空间时，一样会出现Forbidden！！！
[[email protected] manifests]# kubectl get pods -n ingress-nginx
Error from server (Forbidden): pods is forbidden: User "white" cannot list resource "pods" in API group "" in the namespace "ingress-nginx"
[[email protected] manifests]# kubectl get pods -n kube-system
Error from server (Forbidden): pods is forbidden: User "white" cannot list resource "pods" in API group "" in the namespace "kube-system"2、User --> Clusterrolebinding --> Clusterrole
clusterrole定义
ClusterRole对象可以授予与Role对象相同的权限，但由于它们属于集群范围对象， 也可以使用它们授予对以下几种资源的访问权限：
- 集群范围资源（例如节点，即node）
- 非资源类型endpoint（例如”/healthz”）
- 跨所有命名空间的命名空间范围资源（例如pod，需要运行命令kubectl get pods --all-namespaces来查询集群中所有的pod）
[[email protected] manifests]# kubectl config use-context [email protected]
Switched to context "[email protected]".
[[email protected] manifests]# kubectl create clusterrole cluster-reader --verb=get,list,watch --resource=pods -o yaml --dry-run >clusterrole-demo.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-reader
rules:
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- list
- watch
[[email protected] manifests]# kubectl apply -f clusterrole-demo.yaml
clusterrole.rbac.authorization.k8s.io/cluster-reader created这里我们需要切换回kubernetes-admin账户，是由于white账户不具备创建的权限，这也说明普通用户是无法进行创建K8S资源的，除非进行授权。如下，我们另开一个终端，将配置到一个普通用户ik8s上，使其使用white账户进行通信
[[email protected] manifests]# useradd ik8s
[[email protected] manifests]# cp -rp ~/.kube/ /home/ik8s/
[[email protected] manifests]# chown -R ik8s.ik8s /home/ik8s/
[[email protected] manifests]# su - ik8s
[[email protected] ~]$ kubectl config view
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://10.0.0.10:6443
name: kubernetes
contexts:
- context:
cluster: kubernetes
user: kubernetes-admin
name: [email protected]
- context:
cluster: kubernetes
user: white
name: [email protected]
- context:
cluster: ""
user: ""
name: xiaomi
current-context: [email protected]
kind: Config
preferences: {}
users:
- name: kubernetes-admin
user:
client-certificate-data: REDACTED
client-key-data: REDACTED
- name: white
user:
client-certificate-data: REDACTED
client-key-data: REDACTEDclusterrolebinding定义
#清理原有的rolebinding
[[email protected] manifests]# kubectl get rolebinding
NAME AGE
white-read-pods 22m
[[email protected] manifests]# kubectl delete rolebinding white-read-pods
rolebinding.rbac.authorization.k8s.io "white-read-pods" deleted
#删除后，在ik8s普通用户上进行获取pods资源信息，就立马出现forbidden了
[[email protected] ~]$ kubectl get pods
Error from server (Forbidden): pods is forbidden: User "white" cannot list resource "pods" in API group "" in the namespace "default"
#创建clusterrolebinding
[[email protected] manifests]# kubectl create clusterrolebinding white-read-all-pods --clusterrole=cluster-reader --user=white --dry-run -o yaml >clusterrolebinding-demo.yaml
[[email protected] manifests]# vim clusterrolebinding-demo.yaml
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: white-read-all-pods
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-reader
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: white
[[email protected] manifests]# kubectl apply -f clusterrolebinding-demo.yaml
clusterrolebinding.rbac.authorization.k8s.io/white-read-all-pods created
[[email protected] manifests]# kubectl get clusterrolebinding|grep white
white-read-all-pods
[[email protected] manifests]# kubectl describe clusterrolebinding white-read-all-pods
Name: white-read-all-pods
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"rbac.authorization.k8s.io/v1beta1","kind":"ClusterRoleBinding","metadata":{"annotations":{},"name":"white-read-all-pods"},"...
Role:
Kind: ClusterRole
Name: cluster-reader
Subjects:
Kind Name Namespace
---- ---- ---------
User white 角色绑定后在ik8s终端上进行获取pods信息，已经不会出现forbidden了
[[email protected] ~]$ kubectl get pods
NAME READY STATUS RESTARTS AGE
myapp-0 1/1 Running 0 4d18h
myapp-1 1/1 Running 0 4d18h
myapp-2 1/1 Running 0 4d18h
myapp-3 1/1 Running 0 4d18h
pod-sa-demo 1/1 Running 0 3d21h
[[email protected] ~]$ kubectl get pods -n kube-system
NAME READY STATUS RESTARTS AGE
coredns-78d4cf999f-6cb69 1/1 Running 0 11d
coredns-78d4cf999f-tflpn 1/1 Running 0 11d
etcd-master 1/1 Running 0 11d
kube-apiserver-master 1/1 Running 0 11d
kube-controller-manager-master 1/1 Running 0 11d
kube-flannel-ds-amd64-gtv85 1/1 Running 0 11d
kube-flannel-ds-amd64-gwbql 1/1 Running 1 11d
kube-flannel-ds-amd64-ml7nf 1/1 Running 0 11d
kube-proxy-ch4vp 1/1 Running 0 11d
kube-proxy-cz2rf 1/1 Running 1 11d
kube-proxy-kdp7d 1/1 Running 0 11d
kube-scheduler-master 1/1 Running 0 11d但是进行删除pod就无法进行，因为在授权时是没有delete权限的
[[email protected] ~]$ kubectl delete pods myapp-0
Error from server (Forbidden): pods "myapp-0" is forbidden: User "white" cannot delete resource "pods" in API group "" in the namespace "default"从上面的实验，我们可以知道对用户white进行集群角色绑定，用户white将会获取对集群内所有资源的对应权限。
3、User --> Rolebinding --> Clusterrole
将white通过rolebinding到集群角色white-read-pods当中，此时，white仅作用于当前名称空间的所有pods资源的权限
[[email protected] manifests]# kubectl delete clusterrolebinding white-read-all-pods
clusterrolebinding.rbac.authorization.k8s.io "white-read-all-pods" deleted
[[email protected] manifests]# kubectl create rolebinding white-read-pods --clusterrole=cluster-reader --user=white --dry-run -oyaml >rolebinding-clusterrole-demo.yaml
[[email protected] manifests]# vim rolebinding-clusterrole-demo.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: white-read-pods
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-reader
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: white
[[email protected] manifests]# kubectl apply -f rolebinding-clusterrole-demo.yaml
rolebinding.rbac.authorization.k8s.io/white-read-pods created
[[email protected] ~]$ kubectl get pods
NAME READY STATUS RESTARTS AGE
myapp-0 1/1 Running 0 4d18h
myapp-1 1/1 Running 0 4d18h
myapp-2 1/1 Running 0 4d18h
myapp-3 1/1 Running 0 4d18h
pod-sa-demo 1/1 Running 0 3d21h
[[email protected] ~]$ kubectl get pods -n ingress-nginx
Error from server (Forbidden): pods is forbidden: User "white" cannot list resource "pods" in API group "" in the namespace "ingress-nginx"
[[email protected] ~]$ kubectl get pods -n kube-system
Error from server (Forbidden): pods is forbidden: User "white" cannot list resource "pods" in API group "" in the namespace "kube-system"
[[email protected] ~]$ RBAC的三种授权访问
BAC不仅仅可以对user进行访问权限的控制，还可以通过group和serviceaccount进行访问权限控制。当我们想对一组用户进行权限分配时，即可将这一组用户归并到一个组内，从而通过对group进行访问权限的分配，达到访问权限控制的效果。
从前面serviceaccount我们可以了解到，Pod可以通过 spec.serviceAccountName来定义其是以某个serviceaccount的身份进行运行，当我们通过RBAC对serviceaccount进行访问授权时，即可以实现Pod对其他资源的访问权限进行控制。也就是说，当我们对serviceaccount进行rolebinding或clusterrolebinding，会使创建Pod拥有对应角色的权限和apiserver进行通信。如图：
参考资料
https://www.cnblogs.com/linuxk
马永亮. Kubernetes进阶实战 (云计算与虚拟化技术丛书)
Kubernetes-handbook-jimmysong-20181218
原文地址：https://www.cnblogs.com/wlbl/p/10694364.html