RBAC 详解(基于角色的访问控制)一个实验搞定RBAC在Kubernetes中授权有ABAC基于属性的访问控制、RBAC基于角色的访问控制、Webhook、Node、AlwaysDeny一直拒绝和AlwaysAllow一直允许这6种模式。 RBAC基于角色的访问控制--全拼Role-Based Access Control----做权限控制的顾名思义就是通过给角色赋予相应的权限从而使得该角色具有访问相关资源的权限。 k8s里面有两种用户,一种是User,一种就是service account(服务使用的账号)。 User account是为人设计的属于用户账户个人使用的账号此外User Account是跨Namespace的而ServiceAccount则是仅局限它所在的Namespace。在K8s中这些资源分属于两个级别名称空间role/rolebinding和集群级别clusterrole/clusterrolebinding这两个都是标准的K8s资源可以直接定义。 Role与ClusterRole Role普通角色:一个Role对象只能用于授予对某一单一命名空间中资源的访问权限普通角色只是在当前的名称空间生效。 ClusterRole集群角色:整个Kubernetes集群范围内有效的角色则通过ClusterRole对象实现可以访问整个集群资源。 简介 role/ClusterRole: 1、允许的操作如get,list,update,create,delete等权限 2、允许操作的对象如pod,svc等资源创建k8s账号与RBAC授权使用创建账号1、创建私钥[rootkub-k8s-master ~]# (umask 077; openssl genrsa -out soso.key 2048)Generating RSA private key,2048bit long modulus......................................................... e is65537(0x10001)用此私钥创建一个csr(证书签名请求)文件[rootkub-k8s-master ~]# openssl req -new -key soso.key -out soso.csr -subj /CNsoso拿着私钥和请求文件生成证书[rootkub-k8s-master ~]# openssl x509 -req -in soso.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out soso.crt -days 365Signature oksubject/CNsoso Getting CA Private Key 生成账号[rootkub-k8s-master ~]# kubectl config set-credentials soso --client-certificatesoso.crt --client-keysoso.key --embed-certstrueUsersososet.3、设置上下文环境--指的是创建这个账号的环境在当前名称空间中设置pod的特权和访问控制的[rootkub-k8s-master ~]# kubectl config set-context sosokubernetes --clusterkubernetes --usersosoContextsosokubernetescreated. 查看当前的工作上下文[rootkub-k8s-master ~]# kubectl config viewapiVersion: v1 clusters: - cluster: certificate-authority-data: DATAOMITTED server: https://192.168.246.166:6443....4、切换用户切换上下文[rootkub-k8s-master ~]# kubectl config use-context sosokubernetesSwitched to contextsosokubernetes.验证是否已经切换到了新的上下文[rootkub-k8s-master ~]# kubectl config current-contextsosokubernetes5.测试还未赋予权限[rootkub-k8s-master ~]# kubectl get podError from server(Forbidden): pods is forbidden: Usersosocannot list resourcepodsinAPI groupinthe namespacedefault6、删除上下文先不用删除试验完成后再删除 kubectl config delete-context sosokubernetes创建一个角色role---设置权限1.切回管理帐号先[rootkub-k8s-master ~]# kubectl config use-context kubernetes-adminkubernetesSwitched to contextkubernetes-adminkubernetes.创建角色命令[rootkub-k8s-master ~]# kubectl create role role-reader --verbget,list,watch --resourcepod,svcrole.rbac.authorization.k8s.io/role-reader created --verb 相当于是权限 --resource给什么资源使用 yaml文件方式:[rootkub-k8s-master ~]# vim role.yamlapiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: role-reader rules:#定义规则- apiGroups:[]#表示当前pod使用核心的APIserver组默认用表示就可以resources:[pods,svc]verbs:[get,list,watch,create,update,delete]#[*]表示所有权限[rootkub-k8s-master ~]# kubectl apply -f role.yamlrole.rbac.authorization.k8s.io/role-reader created[rootkub-k8s-master ~]# kubectl get rolesNAME AGE role-reader 30s[rootkub-k8s-master ~]# kubectl describe role role-readerName: role-reader Labels:noneAnnotations: kubectl.kubernetes.io/last-applied-configuration:{apiVersion:rbac.authorization.k8s.io/v1beta1,kind:Role,metadata:{annotations:{},name:role-reader,namespace:default},... PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- pods [] [] [get list watch create update delete] svc [] [] [get list watch create update delete] 2.绑定用户soso上面创建的用户绑定用户到role-reader [rootkub-k8s-master ~]# kubectl create rolebinding myrole-binding --rolerole-reader --usersoso rolebinding.rbac.authorization.k8s.io/myrole-binding created yaml文件方式 [rootk8s-master ~]# vim role-binding.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: myrolebind subjects: #定义对那个主体进行操作有三种Subjects:Service Account、User Account、Groups - kind: User name: soso apiGroup: rbac.authorization.k8s.io roleRef: #定义使用哪个角色 kind: Role name: role-reader apiGroup: rbac.authorization.k8s.io [rootk8s-master ~]# kubectl apply -f role-binding.yaml rolebinding.rbac.authorization.k8s.io/myrolebind created [rootk8s-master ~]# kubectl get rolebinding NAME AGE myrolebind 25s 3.切换用户 [rootkub-k8s-master ~]# kubectl config use-context sosokubernetes Switched to context sosokubernetes. 4.查看权限只授权了default名称空间pod和svc的getlistwatch权限 [rootkub-k8s-master ~]# kubectl get pod NAME READY STATUS RESTARTS AGE lifecycle-demo 1/1 Running 1 22h mypod 1/1 Running 0 8h nginx-configmap 1/1 Running 0 4h29m nginx-pod 1/1 Running 0 39m [rootkub-k8s-master ~]# kubectl get pod -n kube-system #无权访问kube-system Error from server (Forbidden): pods is forbidden: User soso cannot list resource pods in API group inthe namespacekube-system[rootkub-k8s-master ~]# kubectl delete pod nginx-pod #无权限删除Error from server(Forbidden): podsnginx-podis forbidden: Usersosocannot delete resourcepodsinAPI groupinthe namespacedefault5.切换用户[rootkub-k8s-master ~]# kubectl config use-context kubernetes-adminkubernetesSwitched to contextkubernetes-adminkubernetes.实验二绑定用户到集群角色6.删除soso账号之前绑定的rolebinding[rootkub-k8s-master ~]# kubectl delete rolebinding myrole-bindingrolebinding.rbac.authorization.k8s.iomyrole-bindingdeleted7.创建clusterrole#可以访问全部的namespace[rootkub-k8s-master ~]# kubectl create clusterrole myclusterrole --verbget,list,watch --resourcepod,svcclusterrole.rbac.authorization.k8s.io/myclusterrole created yaml文件方式[rootkub-k8s-master ~]# vim clusterrole.yamlapiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: myclusterrole rules: - apiGroups: -resources: - pods verbs: - get - list -watch[rootkub-k8s-master ~]# kubectl apply -f clusterrole.yaml[rootkub-k8s-master ~]# kubectl get clusterrole8.绑定集群角色到用户soso[rootkub-k8s-master ~]# kubectl create clusterrolebinding my-cluster-rolebinding --clusterrolemyclusterrole --usersosoclusterrolebinding.rbac.authorization.k8s.io/my-cluster-rolebinding created yaml文件方式[rootkub-k8s-master ~]# vim clusterrolebinding.yamlapiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: my-cluster-rolebinding roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: myclusterrole subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: soso[rootkub-k8s-master ~]# kubectl apply -f clusterrolebinding.yaml[rootkub-k8s-master ~]# kubectl get clusterrolebinding9.切换账号[rootkub-k8s-master ~]# kubectl config use-context sosokubernetesSwitched to contextsosokubernetes.10.查看权限 查看kube-system空间的pod[rootkub-k8s-master ~]# kubectl get pod -n kube-systemNAME READY STATUS RESTARTS AGE coredns-5644d7b6d9-sm8hs1/1 Running05d coredns-5644d7b6d9-vddll1/1 Running05d etcd-kub-k8s-master1/1 Running05d... 注意11.切换为管理员用户[rootkub-k8s-master ~]# kubectl config use-context kubernetes-adminkubernetes设置上下文和账户切换设置工作上下文前提得有用户[rootkub-k8s-master ~]# kubectl config set-context sosokubernetes --clusterkubernetes --usersosoContextsosokubernetescreated.查看当前的工作上下文[rootkub-k8s-master ~]# kubectl config viewapiVersion: v1 clusters: - cluster:....切换上下文切换用户[rootkub-k8s-master ~]# kubectl config use-context sosokubernetesSwitched to contextsosokubernetes.切换为管理员用户[rootkub-k8s-master prome]# kubectl config use-context kubernetes-adminkubernetesSwitched to contextkubernetes-adminkubernetes.容器监控检查及恢复机制​ 在 k8s 中可以为 Pod 里的容器定义一个健康检查探针Probe。kubelet 就会根据这个 Probe 的返回值决定这个容器的状态而不是直接以容器是否运行来自 Docker 返回的信息作为依据。这种机制是生产环境中保证应用健康存活的重要手段。命令模式探针Kubernetes 文档中的例子:[rootkub-k8s-master ~]# cd prome/[rootkub-k8s-master prome]# vim test-liveness-exec.yaml--- apiVersion: v1 kind: Pod metadata: labels: test: liveness name: test-liveness-exec spec: containers: - name: liveness image: daocloud.io/library/nginx args: - /bin/sh#sh -c 非交互式执行命令--c-touch/tmp/healthy;sleep30;rm-rf/tmp/healthy;sleep50livenessProbe:#探针健康检查exec:#类型command:#命令-cat- /tmp/healthy initialDelaySeconds:5#健康检查在容器启动5s后开始执行periodSeconds:5#每5s执行一次它在启动之后做的第一件事是在/tmp目录下创建了一个healthy文件以此作为自己已经正常运行的标志。而30s过后它会把这个文件删除掉。与此同时定义了一个这样的 livenessProbe健康检查。它的类型是 exec它会在容器启动后在容器里面执行一句我们指定的命令比如cat /tmp/healthy。这时如果这个文件存在这条命令的返回值就是0Pod就会认为这个容器不仅已经启动而且是健康的。这个健康检查在容器启动5s后开始执行initialDelaySeconds:5每5s执行一次periodSeconds:5。创建Pod[rootkub-k8s-master prome]# kubectl apply -f test-liveness-exec.yamlpod/test-liveness-exec created查看 Pod 的状态[rootkub-k8s-master prome]# kubectl get podNAME READY STATUS RESTARTS AGE nginx-configmap1/1 Running016h nginx-pod1/1 Running012h test-liveness-exec1/1 Running075s由于已经通过了健康检查这个 Pod 就进入了 Running 状态。然后30 s 之后再查看一下 Pod 的 Events[rootkub-k8s-master prome]# kubectl describe pod test-liveness-exec发现这个 Pod 在 Events 报告了一个异常Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning Unhealthy 54s(x9 over 3m34s)kubelet, kub-k8s-node1 Liveness probe failed: cat: /tmp/healthy: No suchfileor directory这个健康检查探查到 /tmp/healthy 已经不存在了所以它报告容器是不健康的。那么接下来会发生什么呢再次查看一下这个 Pod 的状态[rootkub-k8s-master prome]# kubectl get pod test-liveness-execNAME READY STATUS RESTARTS AGE test-liveness-exec1/1 Running45m19s这时发现Pod 并没有进入 Failed 状态而是保持了 Running 状态。这是为什么呢RESTARTS 字段从0到1的变化就明白原因了这个异常的容器已经被 Kubernetes 重启了。在这个过程中Pod 保持 Running 状态不变。#注k8s 中并没有 Docker 的 Stop 语义。所以如果容器被探针检测到有问题查看状态虽然看到的是 Restart但实际却是重新创建了容器。这个功能就是 Kubernetes 里的Pod 恢复机制也叫 restartPolicy。它是 Pod 的 Spec 部分的一个标准字段pod.spec.restartPolicy默认值是 Always即任何时候这个容器发生了异常它一定会被重新创建。小提示Pod 的恢复过程永远都是发生在当前节点上而不会跑到别的节点上去。事实上一旦一个 Pod 与一个节点Node绑定除非这个绑定发生了变化pod.spec.node 字段被修改否则它永远都不会离开这个节点。这也就意味着如果这个宿主机宕机了这个 Pod 也不会主动迁移到其他节点上去。http get方式探针[rootkub-k8s-master prome]# vim liveness-httpget.yaml--- apiVersion: v1 kind: Pod metadata: name: liveness-httpget-pod namespace: default spec: containers: - name: liveness-exec-container image: daocloud.io/library/nginx imagePullPolicy: IfNotPresent ports: - name: http containerPort:80livenessProbe:#探针健康检查httpGet: port: http path: /index.html initialDelaySeconds:1periodSeconds:3创建该pod[rootkub-k8s-master prome]# kubectl create -f liveness-httpget.yamlpod/liveness-httpget-pod created查看当前pod的状态[rootkub-k8s-master prome]# kubectl describe pod liveness-httpget-pod... Liveness: http-get http://:http/index.htmldelay1stimeout1speriod3s#success1 #failure3...登陆容器测试将容器内的index.html删除掉[rootkub-k8s-master prome]# kubectl exec -it liveness-httpget-pod /bin/bashrootliveness-httpget-pod:/# mv /usr/share/nginx/html/index.html index.htmlrootliveness-httpget-pod:/# command terminated with exit code 137可以看到当把index.html移走后这个容器立马就退出了。此时查看pod的信息[rootkub-k8s-master prome]# kubectl describe pod liveness-httpget-pod... Normal Killing 49s kubelet, kub-k8s-node2 Container liveness-exec-container failed liveness probe, will be restarted Normal Pulled 49s kubelet, kub-k8s-node2 Container imagedaocloud.io/library/nginxalready present on machine...看输出容器由于健康检查未通过pod会被杀掉并重新创建[rootkub-k8s-master prome]# kubectl get podsNAME READY STATUS RESTARTS AGE lifecycle-demo1/1 Running134h liveness-httpget-pod1/1 Running15m42s#restarts 为 1重新登陆容器发现index.html又出现了证明容器是被重拉了。[rootkub-k8s-master prome]# kubectl exec -it liveness-httpget-pod /bin/bashrootliveness-httpget-pod:/# cat /usr/share/nginx/html/index.htmlPOD 的恢复策略Pod 的恢复策略 可以通过设置 restartPolicy改变 Pod 的恢复策略。一共有3种1. Always 在任何情况下只要容器不在运行状态就自动重启容器重新创建2. OnFailure: 只在容器 异常时才自动重启容器3. Never: 从来不重启容器。 实际使用时需要根据应用运行的特性合理设置这三种恢复策略。