ServiceAccount和RBAC
- ServiceAccount
- 使用场景：
- Service account与User account区别:
- Service Account应用示例
- 创建角色
- RBAC
- RBAC简述
- 创建k8s账号与RBAC授权使用
- 设置上下文和账户切换
- 设置工作上下文（前提得有用户）
- 查看当前的工作上下文
- 切换上下文（切换用户）
- 切换为管理员用户
- 查看某个资源类型是由哪个apiserver版本提供
ServiceAccount
官方文档地址：https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/
k8s中提供了良好的多租户认证管理机制，如RBAC、ServiceAccount还有各种Policy等。
Pod里的进程也可以与apiserver联系。 当它们在联系apiserver的时候，它们就会被认证为一个特定的 Service Account。
使用场景：
Service Account它并不是给kubernetes集群的用户使用的，而是给pod里面的进程使用的，它为pod提供必要的身份认证。----专门为pod里面的进程和apiserver通信提供认证的。
Service account与User account区别:
1. User account是为人设计的，而service account则是为Pod中的进程调用Kubernetes API或其他外部服务而设计的2. User account是跨namespace的，而service account则是仅局限它所在的namespace；3. 每个namespace都会自动创建一个default service account 4. Token controller检测service account的创建，并为它们创建secret
Service Account应用示例
Service Account（服务账号）示例
因为平时系统会使用默认service account，我们不需要自己创建，感觉不到service account的存在，本实验是使用自己手动创建的service account
创建serviceaccountkubectl create serviceaccount mysa查看： kubectl get sa|serviceaccountserviceaccount/mysa created
yaml文件创建
---
apiVersion: v1
kind: ServiceAccount
metadata:name: mysa查看mysa
kubectl describe sa mysa查看mysa自动创建的secretkubectl get secret使用mysa的sa资源配置pod
cd prome/vim mysa-pod.yaml---
apiVersion: v1
kind: Pod
metadata:name: mysa-podlabels:app: pod
spec:containers:- name: mysa-podimage: qingning800/kubectlcommand:- "tail"- "-f"- "/dev/null"serviceAccountName: mysa #指定serviceaccount的名称导入：kubectl apply -f mysa-pod.yaml查看：kubectl describe pod mysa-pod查看使用的token和secret（使用的是mysa的token）kubectl get pod mysa-pod -o jsonpath={".spec.volumes"}
创建角色
vim role.yaml
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:name: mysa-role
rules: #定义规则- apiGroups: [""] #表示当前pod使用核心的APIserver组，默认用""表示就可以resources: ["pods"]verbs: ["get", "list", "watch"] #["*"]表示所有权 #尝试不用空格看看能不能行
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:name: mysa-binding
subjects: #定义对那个主体进行操作，有三种Subjects:Service Account、User Account、Groups
- kind: ServiceAccountname: mysa
roleRef: #定义使用哪个角色kind: Rolename: mysa-roleapiGroup: rbac.authorization.k8s.io
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。在RABC API中，通过如下的步骤进行授权：
1）定义角色：在定义角色时会指定此角色对于资源的访问控制的规则；
2）绑定角色：将主体与角色进行绑定，对用户进行访问授权。
在K8s中这些资源分属于两个级别，名称空间（role/rolebinding）和集群级别（clusterrole/clusterrolebinding）这两个都是标准的K8s资源，可以直接定义。Role与ClusterRoleRole普通角色:一个Role对象只能用于授予对某一单一命名空间中资源的访问权限，普通角色只是在当前的名称空间生效。ClusterRole集群角色:整个Kubernetes集群范围内有效的角色则通过ClusterRole对象实现，可以访问整个集群资源。简介
role/ClusterRole:1、允许的操作，如get,list,update,create,delete等权限2、允许操作的对象，如pod,svc等资源
rolebinding:将哪个用户绑定到哪个role上
clusterrolebinding:绑定到集群角色上如果使用clusterrolebinding绑定到clusterrole上，表示绑定的用户拥有所有namespace的权限#这里面有哪些重要的东西：role，clusterrole，binding，账号。
RBAC简述
基于角色的访问控制角色
role：特定命名空间的访问权限
ClusterRole：所有命名空间访问权限角色绑定
roleBinding：角色绑定到主体
ClusterRoleBinding：集群角色绑定到主体主体
user：用户
group：用户组
serviceAccount：服务账号
1创建命名空间：kubectl create ns roledemo查询命令空间：kubectl get ns2在新创建的命名空间下创建pod
kubectl run nginx --image=nginx -n roledemo3创建角色
vim rbac-role.yamlkind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:namespace: roledemoname: pod-reader
rules :
- apiGroups: [""]resources: ["pods"]verbs:["get","watch","list"]kubectl apply -f rbac-role.yaml
kubectl get role -n roledemo //查看角色4角色绑定
vim rbac-rolebinding.yamlkind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:name: read-podsnamespace: roledemo #名称空间的名字
subiects:
- kind: username: lucyapiGroup: rbac.authorization.k8s.io
roleRef:kind: Rolename: pod-readerapiGroup: rbac.authorization.k8s.iokubectl apply -f rbac-rolebinding.yaml
kubectl get role,rolebinding -n roledemo5使用证书识别身份
vim rabc-user.shcat > mary-csr.json << EOF
{"CN": "mary","hosts": "[]","key": {"algo": "rsa","size": 2048},"names": [{"C": "CN","L": "Beijing","ST": "Beijing"}]
}
EOFcfssl gencert -ca=ca.pam -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes mary-csr.json | cfssljson -bare marykubectl config set-cluster kubernetes \--certificate-authority=ca.pem \--embed-certs=true \--server=https://192.168.188.175:6443 \--kubeconfig=mary-kubeconfigkubectl config set-credentials mary \--client-key=mary-key.pem \--client-certificate=mary.pem \--embed-certs=true \--kubeconfig=mary-kubeconfigkubectl config set-context default \--cluster=kubernetes \--user=mary \--kubeconfig=mary-kubeconfigkubectl config use-context default --kubeconfig=mary-kubeconfig将证书拷贝的目录下，执行脚本
kubectl get pods -n roledemo
创建k8s账号与RBAC授权使用
创建账号
创建私钥
(umask 077; openssl genrsa -out soso.key 2048)用此私钥创建一个csr(证书签名请求)文件
openssl req -new -key soso.key -out soso.csr -subj "/CN=soso" # 这个地方是用户名拿着私钥和请求文件生成证书
openssl x509 -req -in soso.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out soso.crt -days 365生成账号
kubectl config set-credentials soso --client-certificate=soso.crt --client-key=soso.key --embed-certs=true设置上下文环境--指的是创建这个账号的环境在当前名称空间中
kubectl config set-context soso@kubernetes --cluster=kubernetes --user=soso查看当前的工作上下文
kubectl config view切换用户（切换上下文）
kubectl config use-context soso@kubernetes验证是否已经切换到了新的上下文
kubectl config current-context测试（还未赋予权限）
kubectl get pod
创建一个角色（role）---设置权限
切回管理帐号先
kubectl config use-context kubernetes-admin@kubernetes创建角色（命令）：
kubectl create role role-reader --verb=get,list,watch --resource=pod,svcyaml文件方式:
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"] #["*"]表示所有权限kubectl apply -f role.yaml kubectl get roleskubectl describe role role-reader绑定用户soso（上面创建的用户），绑定用户到role-reader
kubectl create rolebinding myrole-binding --role=role-reader --user=sosoyaml文件方式：
vim role-binding.yamlapiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:name: myrolebind
subjects: #定义对那个主体进行操作，有三种Subjects:Service Account、User Account、Groups
- kind: Username: sosoapiGroup: rbac.authorization.k8s.io
roleRef: #定义使用哪个角色kind: Rolename: role-readerapiGroup: rbac.authorization.k8s.iokubectl apply -f role-binding.yaml kubectl get rolebinding 切换用户
kubectl config use-context soso@kubernetes查看权限（只授权了default名称空间pod和svc的get，list，watch权限）
kubectl get podkubectl get pod -n kube-system #无权访问kube-systemkubectl delete pod nginx-pod #无权限删除切换用户
kubectl config use-context kubernetes-admin@kubernetes实验二，绑定用户到集群角色6.删除soso账号之前绑定的rolebinding
kubectl delete rolebinding myrolebind7.创建clusterrole #可以访问全部的namespace
kubectl create clusterrole myclusterrole --verb=get,list,watch --resource=pod,svcyaml文件方式：
vim clusterrole.yamlapiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:name: myclusterrole
rules:
- apiGroups:- ""resources:- podsverbs:- get- list- watchkubectl apply -f clusterrole.yamlkubectl get clusterrole8.绑定集群角色到用户soso
kubectl create clusterrolebinding my-cluster-rolebinding --clusterrole=myclusterrole --user=sosoyaml文件方式：
vim clusterrolebinding.yamlapiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:name: my-cluster-rolebinding
roleRef:apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: myclusterrole
subjects:
- apiGroup: rbac.authorization.k8s.iokind: Username: sosokubectl apply -f clusterrolebinding.yamlkubectl get clusterrolebinding切换账号
kubectl config use-context soso@kubernetes查看权限 查看kube-system空间的pod
kubectl get pod -n kube-system注意：切换为管理员用户
kubectl config use-context kubernetes-admin@kubernetes
设置上下文和账户切换
设置工作上下文（前提得有用户）
kubectl config set-context soso@kubernetes --cluster=kubernetes --user=soso
查看当前的工作上下文
kubectl config view
切换上下文（切换用户）
kubectl config use-context soso@kubernetes
切换为管理员用户
kubectl config use-context kubernetes-admin@kubernetes
查看某个资源类型是由哪个apiserver版本提供
kubectl explain ClusterRole
)
)