k8s访问控制

 访问k8s的API Server的客户端主要分为两类：

kubectl ：用户家目录中的 .kube/config 里面保存了客户端访问API Server的密钥相关信息，这样当用kubectl访问k8s时，它就会自动读取该配置文件，向API Server发起认证，然后完成操作请求。

pod：Pod中的进程需要访问API Server，如果是人去访问或编写的脚本去访问，这类访问使用的账号为：UserAccount；而Pod自身去连接API Server时，使用的账号是：ServiceAccount，生产中后者使用居多

kubectl向apiserver发起的命令,采用的是http方式,其实就是对URL发起增删改查的操作。
$ kubectl  proxy --port=8888 &
$ curl http://localhost:8888/api/v1/namespaces/default
$ curl http://localhost:8888/apis/apps/v1/namespaces/default/deployments

UserAccount与serviceaccount： 用户账户是针对人而言的。 服务账户是针对运行在 pod 中的进程而言的。 用户账户是全局性的。 其名称在集群各 namespace 中都是全局唯一的，未来的用户资源不会做 namespace 隔离， 服务账户是 namespace 隔离的。

通常情况下，集群的用户账户可能会从企业数据库进行同步，其创建需要特殊权限，并且涉及到复杂的业务流程。 服务账户创建的目的是为了更轻量，允许集群用户为了具体的任务创建服务账户 ( 即权限最小化原则 )。

kubectl get sa -n nfs-client-provisioner
kubectl get sa #查看sa
kubectl create sa admin #创建sa为admin
kubectl describe sa admin #//此时k8s为用户自动生成认证信息，但没有授权生成token

 

mkdir sa
cd sa/
ls
vim pod.yaml #把serviceaccount和pod绑定起来
kubectl apply -f pod.yaml
kubectl get pod
kubectl describe pod myapp #挂载于 /var/run/secrets/kubernetes.io/serviceaccount 的 volumeSource 添加到 pod 下的容器
kubectl exec myapp -- cat  /var/run/secrets/kubernetes.io/serviceaccount/token #查看token
kubectl describe secrets admin-token-trzh2

将认证信息添加到serviceAccount中，要比直接在Pod指定imagePullSecrets要安全很多。 

创建UserAccount 

kubectl delete pod myapp
kubectl delete sa admin

cd /etc/kubernetes/pki/
ls
openssl genrsa -out test.key 2048
openssl req -new -key test.key -out test.csr -subj "/CN=test"
openssl  x509 -req -in test.csr -CA ca.crt -CAkey ca.key  -CAcreateserial -out test.crt -days 365
ll test.crt #生成证书
openssl x509 -in test.crt -text -noout #查看证书内容
kubectl config set-credentials test --client-certificate=/etc/kubernetes/pki/test.crt --client-key=/etc/kubernetes/pki/test.key --embed-certs=true #添加相应配置
 kubectl  config view #查看当前配置有两个用户
kubectl config set-context test@kubernetes --cluster=kubernetes --user=test #给用户test 添加上下文
kubectl  config view #生成针对用户的信息
kubectl config use-context test@kubernetes #切换当前用户为test
kubectl  config view
kubectl get pod #此用户没有权限获取pod资源
kubectl config use-context kubernetes-admin@kubernetes #切换用户为管理员admin
kubectl get pod #可以访问

RBAC（Role Based Access Control）：基于角色访问控制授权。

允许管理员通过Kubernetes API动态配置授权策略。

RBAC就是用户通过角色与权限进行关联。 RBAC只有授权，没有拒绝授权，所以只需要定义允许该用户做什么即可。

RBAC包括四种类型：Role、ClusterRole、RoleBinding、ClusterRoleBinding。  

RBAC的三个基本概念：

Subject：被作用者，它表示k8s中的三类主体， user， group， serviceAccount

Role：角色，它其实是一组规则，定义了一组对 Kubernetes API 对象的操作权限。 RoleBinding：定义了“被作用者”和“角色”的绑定关系 

Role 和 ClusterRole Role是一系列的权限的集合，Role只能授予单个namespace 中资源的访问权限。 ClusterRole 跟 Role 类似，但是可以在集群中全局使用 

Role示例：

vim role.yaml #一定要指定namespace
kubectl apply -f role.yaml

RoleBinding和ClusterRoleBinding
RoleBinding是将Role中定义的权限授予给用户或用户组。它包含一个subjects列表(users，groups ，service accounts)，并引用该Role。
RoleBinding是对某个namespace 内授权，ClusterRoleBinding适用在集群范围内使用。

vim role.yaml #RoleBinding示例，test用户绑定上面定义的myrole
kubectl apply -f role.yaml
kubectl get role#查看角色
kubectl get rolebindings.rbac.authorization.k8s.io #查看角色banding
kubectl config use-context test@kubernetes #切换成test普通用户
kubectl get pod #可以访问pod

 vim pod.yaml #创建pod
 kubectl apply -f pod.yaml
kubectl get pod #可以查看pod

kubectl delete -f pod.yaml #也可以删除
kubectl get pod
kubectl get pod -n kube-system #一旦指定别的namespace就会报错，因为这种权限只是授权操作当前的default的namespace,其他不行

 

 kubectl config use-context kubernetes-admin@kubernetes #切换成管理员
kubectl get pod -n kube-system #可以访问
kubectl config use-context test@kubernetes
kubectl get sa #切换成test,查看不了sa
kubectl get pod #只能查看pod
kubectl get deployments.apps #别的什么权限都没

 

kubectl config use-context kubernetes-admin@kubernetes
vim role.yaml #ClusterRole表示全局
kubectl apply -f role.yaml

使用rolebinding绑定clusterRole 

vim role.yaml #必须指定namespace，绑定到test 用户
kubectl apply -f role.yaml
kubectl config use-context test@kubernetes
kubectl get deployments.apps #可以操作deploy控制器
kubectl get deployments.apps -n kube-system #不能访问其他namespace

 

cd
cd pod/
ls
vim deploy.yml #创建deploy控制器
kubectl apply -f deploy.yml
kubectl get pod
kubectl get all #只有deploy控制器有权限，其他都不行
kubectl get rs #不能查看rs
kubectl delete -f deploy.yml
kubectl config use-context kubernetes-admin@kubernetes

创建clusterrolebinding 

cd
cd sa/
ls
vim role.yaml #创建clusterrolebinding，不用指定namespace，针对整个集群的资源授权，全局的
kubectl apply -f role.yaml
kubectl config use-context test@kubernetes#切换test普通用户
kubectl get pod
kubectl get pod -n kube-system #可以访问
kubectl get pod --all-namespaces
kubectl get all --all-namespaces #只是pod和deploy，其他的还是没有权限

kubectl config use-context kubernetes-admin@kubernetes
kubectl get clusterrole #查看全局角色
kubectl describe clusterrole cluster-admin #查看集群角色权限

 

服务账户的自动化
服务账户准入控制器（Service account admission controller）
如果该 pod 没有 ServiceAccount 设置，将其 ServiceAccount 设为 default。
保证 pod 所关联的 ServiceAccount 存在，否则拒绝该 pod。
如果 pod 不包含 ImagePullSecrets 设置，那么 将 ServiceAccount 中的 ImagePullSecrets 信息添加到 pod 中。
将一个包含用于 API 访问的 token 的 volume 添加到 pod 中。
将挂载于 /var/run/secrets/kubernetes.io/serviceaccount 的 volumeSource 添加到 pod 下的每个容器中。

 Token 控制器（Token controller）

检测服务账户的创建，并且创建相应的 Secret 以支持 API 访问。

检测服务账户的删除，并且删除所有相应的服务账户 Token Secret。

检测 Secret 的增加，保证相应的服务账户存在，如有需要，为 Secret 增加 token。

检测 Secret 的删除，如有需要，从相应的服务账户中移除引用

服务账户控制器（Service account controller） 服务账户管理器管理各命名空间下的服务账户，并且保证每个活跃的命名空间下存在一个名为 “default” 的服务账户 

Kubernetes 还拥有“用户组”（Group）的概念：

ServiceAccount对应内置“用户”的名字是：
system:serviceaccount:<ServiceAccount名字 >

而用户组所对应的内置名字是：
system:serviceaccounts:<Namespace名字 >

示例1：表示mynamespace中的所有ServiceAccount
subjects:
- kind: Group
  name: system:serviceaccounts:mynamespace
  apiGroup: rbac.authorization.k8s.io

示例2：表示整个系统中的所有ServiceAccount
subjects:
- kind: Group
  name: system:serviceaccounts
  apiGroup: rbac.authorization.k8s.io