K8s---访问控制

K8s---访问控制

目录

基本概念

API Server认证

ServiceAccount（SA）

 UserAccount（UA）

 RBAC授权

---

基本概念

kubernetes API 访问控制过程：认证、授权、准入控制

 

Authentication（认证）

认证方式现共有8种，可以启用一种或多种认证方式，只要有一种认证方式通过，就不再进行其它方式的认证。通常启用X509 Client Certs和Service Accout Tokens两种认证方式。Kubernetes集群有两类用户：由Kubernetes管理的ServiceAccounts（服务账户）和（UsersAccounts） 普通账户。k8s中账号的概念不是我们理解的账号，它并不真的存在，它只是形式上存在。
 

Authorization（授权）

必须经过认证阶段，才到授权请求，根据所有授权策略匹配请求资源属性，决定允许或拒绝请求。授权方式现共有6种，AlwaysDeny、AlwaysAllow、ABAC、RBAC、Webhook、Node。默认集群强制开启RBAC。

AdmissionControl（准入控制）

用于拦截请求的一种方式，运行在认证、授权之后，是权限认证链上的最后一环，对请求API资源对象进行修改和校验。

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

kubectl ：用户家目录中的 .kube/config里面保存了客户端访问APIServer的密钥相关信息，这样当用kubectl访问k8s时，它就会自动读取该配置文件，向API Server发起认证，然后完成 *** 作请求。pod：Pod中的进程需要访问API Server，如果是人去访问或编写的脚本去访问，这类访问使用的账号为：UserAccount；而Pod自身去连接API Server时，使用的账号是：ServiceAccount，生产中后者使用居多。

以上两种api的区别是：

api它是一个特殊链接,只有在核心v1群组中的对象才能使用。apis 它是一般API访问的入口固定格式名。

API Server认证

UserAccount与serviceaccount：

用户账户是针对人而言的。 服务账户是针对运行在 pod 中的进程而言的。用户账户是全局性的。 其名称在集群各namespace 中都是全局唯一的，未来的用户资源不会做namespace 隔离，服务账户是namespace 隔离的。通常情况下，集群的用户账户可能会从企业数据库进行同步，其创建需要特殊权限，并且涉及到复杂的业务流程。服务账户创建的目的是为了更轻量，允许集群用户为了具体的任务创建服务账户 ( 即权限最小化原则 )。 ServiceAccount（SA）

kubectl get sa
kubectl create serviceaccount admin
创建一个名为admin的sa

kubectl patch serviceaccount admin -p '{"imagePullSecrets": [{"name":"myregistrykey"}]}'
添加secrets到serviceaccount中

kubectl describe sa admin 
cd 
cd configmap/
vim registry.yml 
kubectl apply -f registry.yml 
kubectl get pod
kubectl describe pod mypod 
kubectl describe sa admin 

 UserAccount（UA）

创建UserAccount：
cd /etc/kubernetes/pki/
openssl genrsa -out test.key 2048
ll test.key 
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
#有key有crt证书

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
kubectl config use-context test@kubernetes

kubectl get pod
【此时用户通过认证，但还没有权限 *** 作集群资源，需要继续添加授权】
kubectl config use-context kubernetes-admin@kubernetes
kubectl get pod

 RBAC授权

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

允许管理员通过Kubernetes API动态配置授权策略。RBAC就是用户通过角色与权限进行关联。RBAC只有授权，没有拒绝授权，所以只需要定义允许该用户做什么即可。RBAC包括四种类型：Role、ClusterRole、RoleBinding、ClusterRoleBinding。

RBAC的三个基本概念：

Subject：被作用者，它表示k8s中的三类主体， user， group， serviceAccountRole：角色，它其实是一组规则，定义了一组对Kubernetes API 对象的 *** 作权限。RoleBinding：定义了“被作用者”和“角色”的绑定关系。

Role 和 ClusterRole

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

RoleBinding和ClusterRoleBinding

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

cd
ls
mkdir role
cd role/
vim role.yaml
kubectl apply -f role.yaml 
kubectl get role

 
绑定：
[把角色和test用户做捆绑]
 

vim role.yaml 
kubectl apply -f role.yaml 
kubectl describe rolebindings.rbac.authorization.k8s.io test-read-pods 
kubectl config use-context test@kubernetes
kubectl get pod
这个时候pod已经没有问题了

kubectl get pod -n kube-system
指定一个ns会报错，因为这个角色针对当前default的，要定别的ns没有权限

kubectl config use-context kubernetes-admin@kubernetes
切换到管理员

vim role.yaml 【添加一个集群角色】

vim role.yaml  【使用rolebinding绑定clusterRole:】

kubectl apply -f role.yaml 
切换到test角色

cd 
cd pod/

vim deploy.yml 

kubectl apply -f deploy.yml 

kubectl get pod
【此时不仅可以创建pod还可以创建deployment控制器】

 

创建clusterrolebinding：
 

cd
cd role/
vim role.yaml 

kubectl config use-context kubernetes-admin@kubernetes
[切换到admin用户，一定要切换，不然创建会报错]
kubectl apply -f role.yaml 
kubectl config use-context test@kubernetes

kubectl get pod -n kube-system
(此时没有报错)
kubectl get deployments.apps 
kubectl get deployments.apps --all-namespaces 

kubectl get storageclasses.storage.k8s.io 
[查看存储类会报错，没有权限]

 

kubectl config use-context kubernetes-admin@kubernetes
kubectl get sa
kubectl describe sa admin 
kubectl delete sa admin 
kubectl get secrets 

把权限授予所有的sa

kubectl get clusterrole
kubectl describe clusterrole view 
(只能看，不能编辑)
kubectl describe clusterrole edit
（可以编辑）
kubectl describe clusterrole cluster-admin 
(针对整个集群的管理)
kubectl describe clusterrole admin