认证的流程分为三个模块

• 用户通过Api接口来访问k8s平台的资源时—账号认证（Authenticatioon账号）
  
• 是否具有删除资源的权限—授权检查(Authorization)
  
• 是否具有操作此资源及此资源级联到其它资源或环境的权限—准入控制（admincontrol）

认证的方式

• token 令牌认证，每一个用户对应一个token并存放到一个文件中，用户发起api请求时，需要在http header里放入token
  
• ssl服务器和客户端双方认证（client ,server证书），通过密钥相互认证

授权的方式

• node， rbac， abac ，webhook等

apiserver的客户端分类

• Use Account（用户账号）：一般是指由独立于Kubernetes之外的其他服务管理的用 户账号，例如由管理员分发的密钥、Keystone一类的用户存储（账号库）、甚至是包 含有用户名和密码列表的文件等。Kubernetes中不存在表示此类用户账号的对象， 因此不能被直接添加进 Kubernetes 系统中 。
• Service Account（服务账号）：是指由Kubernetes API 管理的账号，用于为Pod 之中的服务进程在访问Kubernetes API时提供身份标识（ identity ） 。Service Account通常要绑定于特定的命名空间，它们由 API Server 创建，或者通过 API 调用于动创建 ，附带着一组存储为Secret的用于访问API Server的凭据。

创建一个ServiceAccount

kubectl create serviceaccount -h 查看帮助信息
#使用命令行的方式创建
kubectl create serviceaccount sa_test --dry-run
#使用资源清单的方式创建
cat > ServiceAccount.yml <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa_test
EOF

查看当前账号的权限,，用户名为kubernetes-admin

/root/.kube/config
#使用命令查看
kubelet  config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED    #服务端认证信息
    server: https://10.0.0.70:6443              #访问apiserver入口信息
  name: kubernetes#集群名称
contexts:                                       #指定那个账号可以访问那个集群
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes    #当前使用那个账号
kind: Config
preferences: {}
users:
- name: kubernetes-admin                        #用户信息
  user:
    client-certificate-data: REDACTED           #客户端的认证信息
    client-key-data: REDACTED                   #客户端的私钥

RBAC认证（Role-base access control）

• RBAC (Role-Based Access Control，基于角色的访问控制）是一种新型、灵活且使用广泛的访问控制机制，它将权限授予“角色”（role）之上，这一点有别于传统访问控制机制中 将权限直接赋予使用者的方式，简单点来说就是将权限绑定到role中，然后用户和role绑定，这样用户就拥有了和role一样的权限。

角色的类型有两种，又称为认证的主体

• user
• service account
• group授权这个组中的所有用户都有某种权限

RBAC API资源对象

Kubernetes有一个很基本的特性就是它的所有资源对象都是模型化的 API 对象，允许执行增、删、改、查等操作，比如下面的这下资源：

• Pods
• ConfigMaps
• Deployments
• Nodes
• Secrets
• Namespaces

上面这些资源对象的可能存在的操作有：

• create
• get
• delete
• list
• update
• edit
• watch
• exec

创建User Account

#进入api证书目录
cd /etc/kubernetes/pki
#创建一个私钥
openssl genrsa -out esion.key 2014
#生成一个证书请求
openssl req -new -key esion.key -out esion.csr -subj "/CN=esion"  #CN代表动作的执行主体
#用kubernetes的CA去签发一个证书
openssl x509 -req -in esion.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out esion.crt -days 3650
#查看一个证书的信息
openssl x509 -in esion.crt -text -noout
#生成一个用户
kubectl config set-credentials esion --client-certificate=/etc/kubernetes/pki/esion.crt --client-key=/etc/kubernetes/pki/esion.key --embed-certs=true
esion                #用户名称   
--client-certificate #指定认证的证书
--client-key         #指定私钥
--embed-certs=true   #将证书信息隐藏
#生成一个上下文
kubectl config set-context esion@kubernetes --cluster=kubernetes --user=esion 
#使用当前账号
 kubectl config use-context esion@kubernetes0
#检查是否成功
kubectl config view
#删除上下文
kubectl config delete-context esion@kubernetes
#删除用户
kubectl config unset users.esion

创建系统普通用户

useradd esion
cp -rp /root/.kube/ /home/esion
chown -R esion:esion /home/esion
su - esion
#设置当前使用那个用户
kubectl config use-context esion@kubernetes

RBAC授权的方法有那三种

Role和RoleBinding

• Role是只作用于命名空间级别的，用于定义命名空间内资源权限集合。
• ClusterRole则用于集群级别的资源权限集合，它们都是标准的 API 资源类型 。
• 一般来说， ClusterRole 的许可授权作用于整个集群，因此常用于控制 Role 无法生效的资源类型，这包括集群级别的资源（如Nodes）、非资源类型的端点（如／healthz）和作用于所有命名空间的资源（例如跨命名空间获取任何资源的权限）。
• RoleBinding用于将Role上的许可权限绑定到一个或一组用户之上，它隶属于且仅能作用于一个命名空间。绑定时，可以引用同一名称中的Role，也可以引用集群级别的 ClusterRole。

创建角色（role）

#命令行的方式创建
kubectl create role esion_role --verb=get,list,watch --resource=pods,Deployments
esion_role   #角色的名称
--verb       #允许的操作
--resource   #对象资源
#查看角色
kubectl get role
#查看角色详细信息
kubectl describe role esion_role
------------------------
#资源清单
cat > esion_role.yml <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  creationTimestamp: null
  name: esion_role
  namespace: default
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list
  - watch
EOF

rolebinding(角色与用户绑定)

#命令行创建
kubectl  create rolebinding esion_rolebinding --role=esion_role --user=esion
esion_rolebinding       #rolebinding资源名称
--role                  #指定角色
--user                  #指定用户
#查看rolebinding资源
kubectl get rolebinding
#查看rolebinding资源详细信息
kubectl describe rolebinding esion_rolebinding
#切换系统普通用户测试
su - esion
kubectl get pods
-------------------------
#资源清单
cat > esion_rolebinding.yml << EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  creationTimestamp: null
  name: esion_rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: esion_role
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: esion
EOF

clusterrole和ClusterRoleBinding

• ClusterRoleBinding则把ClusterRole中定义的许可权限绑定在一个或一组用户之上，它仅可以引用集群级别的ClusterRole。
• 一个命名空间中可以包含多个Role和RoleBinding对象，类似地，集群级别也可以同时存在多个ClusterRole和ClusterRoleBinding对 象。而一个账户也可经由RoleBinding ClusterRoleBinding关联至多个角色，从而具有多重许可授权。

创建clusterrole角色

#命令行创建
kubectl create clusterrole esion_clusterrole --verb=get,list,watch --resource=pods
esion_clusterrole   #clusterrole角色名称
--verb              #允许的操作
--resource          #对象资源
#查看clusterrole角色
kubectl get clusterrole
#查看clusterrole角色详细信息
kubectl describe clusterrole esion_clusterrole
#资源清单的方式创建
cat > esion_clusterrole.yml <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: null
  name: esion_clusterrole
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list
  - watch
EOF

创建clusterrolebinding资源

#命令行创建
kubectl  create clusterrolebinding esion_clusterrolebinding --clusterrole=esion_clusterrole --user=esion
esion_clusterrolebinding     #clusterrolebinding资源名称
--clusterrole                #指定角色
--user                       #指定用户
#切换系统普通用户测试
su - esion
kubectl get pods
-----------------------------------
#资源清单
cat > esion_clusterrolebinding.yml <<EOF
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  creationTimestamp: null
  name: esion_clusterrolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: esion_clusterrole
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: esion
EOF

clusterrole和rolebinding

• 授于访问指定名称空间所有资源的权限

创建rolebinding资源,绑定一个集群管理员的角色admin,只限定于指定的名称空间内

#命令行创建
kubectl  create rolebinding esion_clusterrole_rolebinding --clusterrole=admin --user=esion
esion_clusterrole_rolebinding  #rolebinding资源名称
--clusterrole                  #指定角色
--user                         #指定用户
#切换系统普通用户测试
su - esion
kubectl get pods
#资源清单
cat > esion_clusterrole_rolebinding.yml <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  creationTimestamp: null
  name: esion_clusterrole_rolebinding
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: esion
EOF

工作中使用RBAC授权普通用户

使用token登录:

#创建一个serviceaccount
kubectl create sa leihb -n default
#创建RBAC资源(根据需求创建对应的role,或绑定对应clusterrole)
kubectl create clusterrolebinding leihb --clusterrole=cluster-admin --serviceaccount=default:leihb
#生成一个集群.conf文件
kubectl config set-cluster leihbcluster --certificate-authority=/etc/kubernetes/pki/ca.crt  --server="https://10.0.0.70:6443" --embed-certs=true  --kubeconfig=/root/leihb.conf
#解密token,并赋值变量
token=`kubectl get secret leihb-token-zp77t -o jsonpath={.data.token}|base64 -d`
#用token在leihb.conf文件创建一个user
kubectl config set-credentials leihb --token=$token --kubeconfig=/root/leihb.conf
#在leihb.conf文件中生成context
kubectl config set-context leihb@leihbcluster --cluster=leihbcluster --user=leihb  --kubeconfig=/root/leihb.conf
#在leihb.conf文件中生成current-context
kubectl config use-context leihb@leihbcluster --kubeconfig=/root/leihb.conf
#创建系统普通用户
useradd leihb
mkdir /home/leihb/.kube
cp  /root/leihb.conf /home/leihb/.kube
chown -R leihb:leihb /home/leihb
su - leihb
#设置当前使用那个用户
kubectl config use-context leihb@kubernetes