扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
本文的kubernetes环境:https://blog.51cto.com/billy98/2350660
公司主营业务:成都网站建设、成都网站设计、移动网站开发等业务。帮助企业客户真正实现互联网宣传,提高企业的竞争能力。创新互联建站是一支青春激扬、勤奋敬业、活力青春激扬、勤奋敬业、活力澎湃、和谐高效的团队。公司秉承以“开放、自由、严谨、自律”为核心的企业文化,感谢他们对我们的高要求,感谢他们从不同领域给我们带来的挑战,让我们激情的团队有机会用头脑与智慧不断的给客户带来惊喜。创新互联建站推出长沙县免费做网站回馈大家。
RBAC官方文档:https://kubernetes.io/docs/reference/access-authn-authz/rbac/
rbac.authorization.k8s.io
API Group 来实现授权决策,允许管理员通过 Kubernetes API 动态配置策略,要启用RBAC,需要在 apiserver 中添加参数--authorization-mode=RBAC,如果使用的kubeadm安装的集群,都默认开启了RBAC,可以通过查看 Master 节点上 apiserver 的静态Pod定义文件:
[root@node-01 ~]# cat /etc/kubernetes/manifests/kube-apiserver.yaml
···
- --authorization-mode=Node,RBAC
···
Kubernetes有一个很基本的特性就是它的所有资源对象都是模型化的 API 对象,允许执行增、删、改、查等操作,比如下面的这下资源:
上面这些资源对象的可能存在的操作有:
Kubernetes 并不会存储由认证插件从客户端请求中提取出的用户及所属组的信息,它们仅仅用于检验用户是否有权限执行其所请求的操作。
客户端访问API服务的途径通常有三种:kubectl、客户端库或者直接使用 REST接口进行请求。
而可以执行此类请求的主体也被 Kubernetes 分为两类:现实中的“人”和 Pod 对象, 它们的用户身份分别对应于常规用户 (User Account )和服务账号 ( Service Account) 。
Kubernetes 有着以下几个内建的用于特殊目的的组 。
RoleBinding用于将Role上的许可权限绑定到一个或一组用户之上,它隶属于且仅能作用于一个命名空间。绑定时,可以引用同一名称中的Role,也可以引用集群级别的 ClusterRole。
Role、RoleBinding、ClusterRole和ClusterRoleBinding 的关系如图 所示 。
下面我们来创建一个User Account,测试访问某些我们授权的资源:
创建user私钥
[root@node-01 ~]# cd /etc/kubernetes/pki/
[root@node-01 pki]# (umask 077;openssl genrsa -out billy.key 2048)
Generating RSA private key, 2048 bit long modulus
.................................................................................+++
..................+++
e is 65537 (0x10001)
创建证书签署请求
O=组织信息,CN=用户名
[root@node-01 pki]# openssl req -new -key billy.key -out billy.csr -subj "/O=jbt/CN=billy"
[root@node-01 pki]# openssl x509 -req -in billy.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out billy.crt -days 365
Signature ok
subject=/O=jbt/CN=billy
Getting CA Private Key
创建配置文件主要有以下几个步骤:
kubectl config set-cluster --kubeconfig=/PATH/TO/SOMEFILE #集群配置
kubectl config set-credentials NAME --kubeconfig=/PATH/TO/SOMEFILE #用户配置
kubectl config set-context #context配置
kubectl config use-context #切换context
- --embed-certs=true的作用是不在配置文件中显示证书信息。
- --kubeconfig=/root/billy.conf用于创建新的配置文件,如果不加此选项,则内容会添加到家目录下.kube/config文件中,可以使用use-context来切换不同的用户管理k8s集群。
- context简单的理解就是用什么用户来管理哪个集群,即用户和集群的结合。
创建集群配置
[root@node-01 pki]# kubectl config set-cluster k8s --server=https://10.31.90.200:8443 --certificate-authority=ca.crt --embed-certs=true --kubeconfig=/root/billy.conf
Cluster "k8s" set.
[root@node-01 pki]# kubectl config view --kubeconfig=/root/billy.conf
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://10.31.90.200:8443
name: k8s
contexts: []
current-context: ""
kind: Config
preferences: {}
users: []
创建用户配置
[root@node-01 pki]# kubectl config set-credentials billy --client-certificate=billy.crt --client-key=billy.key --embed-certs=true --kubeconfig=/root/billy.conf
User "billy" set.
#查看配置文件
[root@node-01 pki]# kubectl config view --kubeconfig=/root/billy.conf
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://10.31.90.200:8443
name: k8s
contexts: []
current-context: ""
kind: Config
preferences: {}
users:
- name: billy
user:
client-certificate-data: REDACTED
client-key-data: REDACTED
创建context配置
[root@node-01 pki]# kubectl config set-context billy@k8s --cluster=k8s --user=billy --kubeconfig=/root/billy.conf
Context "billy@k8s" created.
#查看配置文件
[root@node-01 pki]# kubectl config view --kubeconfig=/root/billy.conf
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://10.31.90.200:8443
name: k8s
contexts:
- context:
cluster: k8s
user: billy
name: billy@k8s
current-context: ""
kind: Config
preferences: {}
users:
- name: billy
user:
client-certificate-data: REDACTED
client-key-data: REDACTED
切换context
[root@node-01 pki]# kubectl config use-context billy@k8s --kubeconfig=/root/billy.conf
Switched to context "billy@k8s".
#查看配置文件
[root@node-01 pki]# kubectl config view --kubeconfig=/root/billy.conf
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://10.31.90.200:8443
name: k8s
contexts:
- context:
cluster: k8s
user: billy
name: billy@k8s
current-context: billy@k8s
kind: Config
preferences: {}
users:
- name: billy
user:
client-certificate-data: REDACTED
client-key-data: REDACTED
创建系统用户及k8s验证文件
[root@node-01 ~]# useradd billy #创建什么用户名都可以
[root@node-01 ~]# mkdir /home/billy/.kube
[root@node-01 ~]# cp billy.conf /home/billy/.kube/config
[root@node-01 ~]# chown billy.billy -R /home/billy/.kube/
[root@node-01 ~]# su - billy
[billy@node-01 ~]$ kubectl get pod
Error from server (Forbidden): pods is forbidden: User "billy" cannot list resource "pods" in API group "" in the namespace "default"
#默认新用户是没有任何权限的。
此role只有pod的get、list、watch权限
[root@node-01 rbac]# cat pods-reader.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: pods-reader
rules:
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- list
- watch
[root@node-01 rbac]# kubectl apply -f pods-reader.yaml
role.rbac.authorization.k8s.io/pods-reader created
用户billy和role pods-reader的绑定
[root@node-01 rbac]# cat billy-pods-reader.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: billy-pods-reader
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: pods-reader
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: billy
[root@node-01 rbac]# kubectl apply -f billy-pods-reader.yaml
rolebinding.rbac.authorization.k8s.io/billy-pods-reader created
如果没有指定命名空间的话,默认就是default命名空间。
[billy@node-01 ~]$ kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-demo-95bd675d5-66xrm 1/1 Running 0 18d
tomcat-5c5dcbc885-7vr68 1/1 Running 0 18d
[billy@node-01 ~]$ kubectl -n kube-system get pod
Error from server (Forbidden): pods is forbidden: User "billy" cannot list resource "pods" in API group "" in the namespace "kube-system"
所以我们是可以查看查看default命名空间的pod,但是其他空间的pod是无法查看的。
[root@node-01 rbac]# cat cluster-reader.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-reader
rules:
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- list
- watch
[root@node-01 rbac]# kubectl apply -f cluster-reader.yaml
clusterrole.rbac.authorization.k8s.io/cluster-reader created
[root@node-01 rbac]# cat billy-read-all-pods.yaml
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: billy-read-all-pods
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-reader
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: billy
[root@node-01 rbac]# kubectl apply -f billy-read-all-pods.yaml
clusterrolebinding.rbac.authorization.k8s.io/billy-read-all-pods created
创建了ClusterRole和ClusterRoleBinding后就可以看到所有命名空间的pod了。
[billy@node-01 ~]$ kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-demo-95bd675d5-66xrm 1/1 Running 0 18d
tomcat-5c5dcbc885-7vr68 1/1 Running 0 18d
[billy@node-01 ~]$ kubectl -n kube-system get pod
NAME READY STATUS RESTARTS AGE
canal-gd4qn 2/2 Running 0 21d
cert-manager-6464494858-wqpnb 1/1 Running 0 18d
coreDNS-7f65654f74-89x69 1/1 Running 0 18d
coredns-7f65654f74-bznrl 1/1 Running 2 54d
...
至于ServiceAccount怎么授权,其实相对user account来说更简单,只需先创建ServiceAccount,然后创建role或者ClusterRole,最后在RoleBinding或ClusterRoleBinding绑定即可。以下简单做一个示例,就不在显示结果了,大家可以自己去验证。
kubectl create sa billy-sa
[root@node-01 rbac]# cat billy-sa-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: billy-sa-role
rules:
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- list
- watch
将billy-sa和billy-sa-role的绑定
[root@node-01 rbac]# cat billy-sa-rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: billy-sa-rolebinding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: billy-sa-role
subjects:
- kind: ServiceAccount
name: billy-sa
创建完SA之后系统会自动创建一个secret,我们可以获取这个secret里面的token去登录dashboard,就可以看到相应有权限的资源。
kubectl get secret billy-sa-token-9rc55 -o jsonpath={.data.token} |base64 -d
还可以在创建pod时在pod的spec里指定serviceAccountName,那么这个pod就拥有了对应的权限,具体的就不在演示了。
本次的分享就到此,如有问题欢迎在下面留言交流,希望大家多多关注和点赞,谢谢!
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流