Kubernetes-认证、鉴权、准入控制
目录
一、认证
1.HTTPS证书认证
2.需要认证的节点
3.kubeconfig
4.ServiceAccount
5.Secret 与 SA 的关系
创建SA实验：
6.总结
二、鉴权
1.Authorization
2.RBAC授权模式
3.Role and ClusterRole
4.RoleBinding and ClusterRoleBinding
5.Resources
6.Subjects
7.实践：创建一个用户只能管理 dev 空间
三、准入控制
Kubernetes 作为一个分布式集群的管理工具，保证集群的安全性是其一个重要的任务。API Server 是集群内部各个组件通信的中介，也是外部控制的入口。所以 Kubernetes 的安全机制基本就是围绕保护 API Server 来设计的。Kubernetes 使用了认证（Authentication）、鉴权（Authorization）、准入控制（Admission Control）三步来保证API Server的安全，称为3A服务。
一、认证
Authentication
（1）HTTP Token 认证：通过一个 Token 来识别合法用户
HTTP Token 的认证是用一个很长的特殊编码方式的并且难以被模仿的字符串 - Token 来表达客户的一种方式。Token 是一个很长的很复杂的字符串，每一个 Token 对应一个用户名存储在 API Server 能访问的文件中。当客户端发起 API 调用请求时，需要在 HTTP Header 里放入 Token**
（2）HTTP Base 认证：通过 用户名+密码 的方式认证
用户名+：+密码 用 BASE64 算法进行编码后的字符串放在 HTTP Request 中的 Heather Authorization 域里发送给服务端，服务端收到后进行编码，获取用户名及密码**
（3）最严格的 HTTPS 证书认证：基于 CA 根证书签名的客户端身份认证方式**
1.HTTPS证书认证
HTTPS 加密
单向认证：客户端认证服务器端
双向认证：客户端与服务器端互相认证
2.需要认证的节点
两种类型
（1）Kubenetes 组件对 API Server 的访问：kubectl、Controller Manager、Scheduler、kubelet、kube-proxy**
（2）Kubernetes 管理的 Pod 对容器的访问：Pod（dashborad 也是以 Pod 形式运行）**
安全性说明
（1）Controller Manager、Scheduler 与 API Server 在同一台机器，所以直接使用 API Server 的非安全端口访问，`--insecure-bind-address=127.0.0.1`
（2）kubectl、kubelet、kube-proxy 访问 API Server 就都需要证书进行 HTTPS 双向认证。
证书颁发
（1）手动签发：通过 k8s 集群的跟 ca 进行签发 HTTPS 证书**
（2）自动签发：kubelet 首次访问 API Server 时，使用 token 做认证，通过后，Controller Manager 会为 kubelet 生成一个证书，以后的访问都是用证书做认证了**
3.kubeconfig
kubeconfig 文件包含集群参数（CA证书、API Server地址），客户端参数（上面生成的证书和私钥），集群 context 信息（集群名称、用户名）。Kubenetes 组件通过启动时指定不同的 kubeconfig 文件可以切换到不同的集群
4.ServiceAccount
Pod中的容器访问API Server。因为Pod的创建、销毁是动态的，所以要为它手动生成证书就不可行了。Kubenetes使用了Service Account解决Pod 访问API Server的认证问题。
5.Secret 与 SA 的关系
Kubernetes 设计了一种资源对象叫做 Secret，分为两类，一种是用于 ServiceAccount 的 service-account-token， 另一种是用于保存用户自定义保密信息的Opaque。ServiceAccount 中用到包含三个部分：Token、ca.crt、namespace
（1）token是使用 API Server 私钥签名的 JWT。用于访问API Server时，Server端认证
（2）ca.crt，根证书。用于Client端验证API Server发送的证书
（3）namespace, 标识这个service-account-token的作用域名空间
创建SA实验：
kubectl create sa zhangsan --dry-run -o yaml
#创建张三的sa证书
kubectl get pod -n kube-system
#查看kube-system名称空间下的pod
kubectl get pod calico-node-2pm9r -n kube-system -o yaml
#查看caloco-node绑定的SA
kubectl exec -it calico-node-2pm9r -n kube-system -- /bin/sh
#进入pod内的容器
cd /run/secrets/kubernetes.io/serviceaccount/
#切换到证书存放的目录
ls 
kubectl get secret --all-namespaces
kubectl describe secret -n kube-system default-token-5gm9r
#查看已存在的secret默认情况下，每个 namespace 都会有一个 ServiceAccount，如果 Pod 在创建时没有指定 ServiceAccount，就会使用 Pod 所属的 namespace 的 ServiceAccount
6.总结
二、鉴权
1.Authorization
上面认证过程，只是确认通信的双方都确认了对方是可信的，可以相互通信。而鉴权是确定请求方有哪些资源的权限。API Server 目前支持以下几种授权策略 （通过 API Server 的启动参数 “--authorization-mode” 设置）
（1）AlwaysDeny：表示拒绝所有的请求，一般用于测试
（2）AlwaysAllow：允许接收所有请求，如果集群不需要授权流程，则可以采用该策略
（3）ABAC（Attribute-Based Access Control）：基于属性的访问控制，表示使用用户配置的授权规则对用户请求进行匹配和控制
（4）Webhook：通过调用外部 REST 服务对用户进行授权
（5）RBAC（Role-Based Access Control）：基于角色的访问控制，现行默认规则
2.RBAC授权模式
RBAC（Role-Based Access Control）基于角色的访问控制，在 Kubernetes 1.5 中引入，现行版本成为默认标准。相对其它访问控制方式，拥有以下优势：
（1）对集群中的资源和非资源均拥有完整的覆盖
（2）整个 RBAC 完全由几个 API 对象完成，同其它 API 对象一样，可以用 kubectl 或 API 进行操作
（3）可以在运行时进行调整，无需重启 API Server
在集群里面又三个附着点：user（用户），group（组），SA（serviceaccount）（pod访问serviec的一个认证），一个角色可以背绑定给多个用户，一个用户可以绑定多个角色，权限和角色也是多对多的关系。
用户绑定角色的过程，这条线（关联）就是一个对象，这个对象叫RoleBinding（角色绑定），RoleBinding被创建时，这条线就被连上了，RoleBinding被删除时，这条线就断了。
集群角色绑定就是ClusterBinding，也就是说，角色进行角色绑定，集群角色进行集群角色绑定。需要注意的是：集群角色被角色绑定而绑定。（下方图解释）
ROLE ROLEBINDING #角色被角色绑定
CLUSTERROLE CLUSTERROLEBINDING #集群角色被集群角色绑定
CLUSTERROLE ROLEBINDING #集群角色被角色绑定
RBAC的API资源对象说明
RBAC 引入了 4 个新的顶级资源对象：Role、ClusterRole、RoleBinding、ClusterRoleBinding，4 种对象类型均可以通过 kubectl 与 API 操作
需要注意的是 Kubenetes 并不会提供用户管理，那么 User、Group、ServiceAccount 指定的用户又是从哪里来的呢？ Kubenetes 组件（kubectl、kube-proxy）或是其他自定义的用户在向 CA 申请证书时，需要提供一个证书请求文件。
CFSSL #申请证书的工具
#coreos公司开发的基于Golang语言编写的证书签发工具，这个工具允许我们通过json文件作为我们证书生成的模板，生成证书签发证书，是一个简化的证书生成工具。
证书签发描述文件：
```json
{
"CN": "admin", #将CN当作用户字段。冒号后面写什么，就代表是什么用户。
"hosts": [], #允许使用这个证书的地址，如果不写代表所用用户都可以使用这个证书
"key": {
"algo": "rsa", #加密算法使用rsa加密算法
"size": 2048 #2048位字符
},
"names": [
{
"C": "CN",
"ST": "HangZhou",
"L": "XS",
"O": "system:masters", #O字段，组字段，冒号后面跟什么就是什么组。
"OU": "System"
}
]
}#API Server会把客户端证书的`CN`字段作为User，把`names.O`字段作为Group
#kubelet 使用 TLS Bootstaping 认证时，API Server 可以使用 Bootstrap Tokens 或者 Token authentication file 验证 =token，无论哪一种，Kubenetes 都会为 token 绑定一个默认的 User 和 Group
#Pod使用 ServiceAccount 认证时，service-account-token 中的 JWT 会保存 User 信息
#有了用户信息，再创建一对角色/角色绑定(集群角色/集群角色绑定)资源对象，就可以完成权限绑定了
3.Role and ClusterRole
在 RBAC API 中，Role 表示一组规则权限，权限只会增加(累加权限)，不存在一个资源一开始就有很多权限而通过 RBAC 对其进行减少的操作；Role 可以定义在一个 namespace 中，如果想要跨 namespace 则可以创建 ClusterRole
vim rule.yaml
#用户角色的yaml文件
kind: Role #资源类别，用户组类型
apiVersion: rbac.authorization.k8s.io/v1beta1 #组类别版本
metadata:
namespace: default #角色是名称空间里面的，所以一定要写名称空间，如果不写，默认就在defaults名称空间下。
name: pod-reader #当前角色名字为pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
#规则指定当前操作对象的兼容的组版本，什么都没写，默认为核心组v1版。
resources: ["pods"] #操作对象为pod，兼容的组版本为核心组v1版
verbs: ["get", "watch", "list"]
#允许的动作类型，这里是：获取，监视，列出，这几个是当前k8s集群中抽象出来的动作类型。ClusterRole 具有与 Role 相同的权限角色控制能力，不同的是 ClusterRole 是集群级别的，ClusterRole 可以用于:
（1）集群级别的资源控制( 例如 node 访问权限 )
（2）非资源型 endpoints( 例如 `/health` 访问 )
（3）所有命名空间资源控制(例如 pods )
vim clusterrole.yaml
#集群角色的yaml文件
kind: ClusterRole #集群角色类型
apiVersion: rbac.authorization.k8s.io/v1beta1 #操作集群角色的组和版本
metadata: #元数据
# "namespace" omitted since ClusterRoles are not namespaced
name: secret-reader #当前集群角色的名
rules: #规则
- apiGroups: [""] #操作当前集群角色的兼容组版本
resources: ["secrets"]
#操作当前集群角色的对象为secrets，他的组和版本为核心组v1版，所以上方可以不写。
verbs: ["get", "watch", "list"] #允许的操作类型
4.RoleBinding and ClusterRoleBinding
RoloBinding 可以将角色中定义的权限授予用户或用户组，RoleBinding 包含一组权限列表(subjects)，权限列表中包含有不同形式的待授予权限资源类型(users, groups, or service accounts)；RoloBinding 同样包含对被 Bind 的 Role 引用；RoleBinding 适用于某个命名空间内授权，而 ClusterRoleBinding 适用于集群范围内的授权
#将 default 命名空间的 `pod-reader` Role 授予 jane 用户，此后 jane 用户在 default 命名空间中将具有 `pod-reader` 的权限.
vim rolebinding.yaml
kind: RoleBinding #角色绑定类型
apiVersion: rbac.authorization.k8s.io/v1beta1 #监控主版本
metadata:
name: read-pods #角色绑定的名称为read-pods
namespace: default #放在default名称空间下
subjects: #绑定给哪个类型呢
- kind: User #绑定给用户类型（类型可以写三种：用户，组，SA）
name: jane #哪个用户呢，名为jane的用户
apiGroup: rbac.authorization.k8s.io
roleRef: #角色来源于谁呢
kind: Role #来源于角色类型
name: pod-reader #哪个角色呢，名为pod-reader的角色，pod-reader角色在上面已经创建了
apiGroup: rbac.authorization.k8s.io
#达到的效果jane用户在default名称空间下，能够对pod有获取，列出，监听的权限。
#jane用户怎么来的呢？证书里的CN字段得到的
RoleBinding 同样可以引用 ClusterRole 来对当前 namespace 内用户、用户组或 ServiceAccount 进行授权，这种操作允许集群管理员在整个集群内定义一些通用的 ClusterRole，然后在不同的 namespace 中使用 RoleBinding 来引用。
RoleBinding 引用了一个 ClusterRole，这个 ClusterRole 具有整个集群内对 secrets 的访问权限；但是其授权用户 `dave` 只能访问 development 空间中的 secrets(因为 RoleBinding 定义在 development 命名空间)
vim rolebinding-clusterrole.yaml
# This role binding allows "dave" to read secrets in the "development" namespace.
kind: RoleBinding #角色绑定类型
apiVersion: rbac.authorization.k8s.io/v1beta1 #监控主版本
metadata:
name: read-secrets #名字为read-secrets
namespace: dev # This only grants permissions within the "development" namespace.
#放在dev名称空间下
subjects:
- kind: User #给的是用户类型
name: dave #dave用户
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole #来源于一个集群角色
name: secret-reader #集群角色为secret-reader
apiGroup: rbac.authorization.k8s.io
#理论上有这个集群角色，可以在所有名称空间下去读取secret对象，但现在做的是角色绑定，dave用户，只能在dev名称空间下，行使这个权限（读取secret），
使用 ClusterRoleBinding 可以对整个集群中的所有命名空间资源权限进行授权；以下 ClusterRoleBinding 样例展示了授权 manager 组内所有用户在全部命名空间中对 secrets 进行访问。
vim clusterrolebinding-yaml
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding #集群角色绑定
apiVersion: rbac.authorization.k8s.io/v1beta1 #兼容主版本
metadata:
name: read-secrets-global #集群角色绑定名字
subjects:
- kind: Group #来源的组类型
name: manager #组名为manager
apiGroup: rbac.authorization.k8s.io
roleRef: #角色
kind: ClusterRole #集群角色
name: secret-reader #集群角色的名字为secret-reader
apiGroup: rbac.authorization.k8s.io
#当前manager组内所有用户可以在所有的名称空间里对当前的secret拥有读的权限
5.Resources
Kubernetes 集群内一些资源一般以其名称字符串来表示，这些字符串一般会在 API 的 URL 地址中出现；同时某些资源也会包含子资源，例如 logs 资源就属于 pods 的子资源，API 中 URL 样例如下:
```yaml
GET /api/v1/namespaces/{namespace}/pods/{name}/log
#如果想要获取一个pod日志的话，应该发起一个GET的url类型。向谁发呢，向APIserver发，发送的URL应该是上面的格式。
#在API下，有个v1（核心组v1版），在这个版本下，我去访问一个namespaces（名称空间级别的），哪个名称空间呢，{}里面填写具体的名称空间。在这个名称空间下，读取pod，哪个pod呢？{}里面写具体的pod名，pod名下面还有一个log
如果要在 RBAC 授权模型中控制这些子资源的访问权限，可以通过 / 分隔符来实现，以下是一个定义 pods 资资源 logs 访问权限的 Role 定义样例
vim role-resourse.yaml
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
namespace: default
name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"] #赋予的权限
verbs: ["get", "list"]
6.Subjects
#绑定权限的标识点
RoleBinding 和 ClusterRoleBinding 可以将 Role 绑定到 Subjects；Subjects 可以是 groups、users 或者 service accounts
Subjects 中 Users 使用字符串表示，它可以是一个普通的名字字符串，如 “alice”；也可以是 email 格式的邮箱地址，如 “[email protected]”；甚至是一组字符串形式的数字 ID 。但是 Users 的前缀 system: 是系统保留的，集群管理员应该确保普通用户不会使用这个前缀格式
Groups 书写格式与 Users 相同，都为一个字符串，并且没有特定的格式要求；同样 system: 前缀为系统保留
7.实践：创建一个用户只能管理 dev 空间
```shell
{
"CN": "devuser",
"hosts": [],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"ST": "BeiJing",
"L": "BeiJing",
"O": "k8s",
"OU": "System"
}
]
}
# 下载证书生成工具
wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64
mv cfssl_linux-amd64 /usr/local/bin/cfssl
coreOS json
wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
mv cfssljson_linux-amd64 /usr/local/bin/cfssljson
wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64
mv cfssl-certinfo_linux-amd64 /usr/local/bin/cfssl-certinfo
cfssl gencert -ca=ca.crt -ca-key=ca.key -profile=kubernetes /root/devuser-csr.json | cfssljson -bare devuser
# 设置集群参数
export KUBE_APISERVER="https://172.20.0.113:6443"
kubectl config set-cluster kubernetes \
--certificate-authority=/etc/kubernetes/ssl/ca.pem \
--embed-certs=true \
--server=${KUBE_APISERVER} \
--kubeconfig=devuser.kubeconfig
# 设置客户端认证参数
kubectl config set-credentials devuser \
--client-certificate=/etc/kubernetes/ssl/devuser.pem \
--client-key=/etc/kubernetes/ssl/devuser-key.pem \
--embed-certs=true \
--kubeconfig=devuser.kubeconfig
# 设置上下文参数
kubectl config set-context kubernetes \
--cluster=kubernetes \
--user=devuser \
--namespace=dev \
--kubeconfig=devuser.kubeconfig
# 设置默认上下文
kubectl config use-context kubernetes --kubeconfig=devuser.kubeconfig
cp -f ./devuser.kubeconfig /root/.kube/config
kubectl create rolebinding devuser-admin-binding --clusterrole=admin --user=devuser --namespace=dev
```
实验：
wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64
wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
#下载证书生成工具
mv cfssl* /usr/local/bin/
chmod a+x /usr/local/bin/xfssl*
ll /usr/local/bin/xfssl*
cd /etc/kubernetes/pki/ ls
vim devuser.json
{
"CN": "devuser",
"hosts": [],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"ST": "BeiJing",
"L": "BeiJing",
"O": "k8s",
"OU": "System"
}
]
}
cfssl gencert -ca=ca.crt -ca-key=ca.key -profile=kubernetes devuser.json | cfssljson -bare devuser
#通过cfssl工具来签发证书，指定ca证书，指定ca的私钥，创建的证书是给kubermetes集群提供的，证书的描述文件在当前目录下decuser.json文件，通过管道符交给cfssljson，他将理解这个json文件，在转化成devuser所描述的证书信息。
ls
#查看生成的文件
export KUBE_APISERVER="https://集群节点的地址:6443" #定义环境变量，
#cat /root/.kube/config与里面的地址一致。
kubectl config set-cluster kubernetes \
--certificate-authority=/etc/kubernetes/pki/ca.crt \
--embed-certs=true \
--server=${KUBE_APISERVER} \
--kubeconfig=devuser.kubeconfig
cat devuser.kubeconfig #查看生成的文件
kubectl config set-credentials devuser \ #设置客户端认证参数
--client-certificate=/etc/kubernetes/pki/devuser.pem \ #客户端的证书
--client-key=/etc/kubernetes/pki/devuser-key.pem \ #客户端的私钥
--embed-certs=true \
--kubeconfig=devuser.kubeconfig
kubectl create ns dev #创建dev名称空间
kubectl config set-context kubernetes \ #设置上下文参数
--cluster=kubernetes \
--user=devuser \
--namespace=dev \
--kubeconfig=devuser.kubeconfig
cat devuser.kubeconfig #再次查看，看看还有哪些信息没填写
kubectl config use-context kubernetes --kubeconfig=devuser.kubeconfig #切换上下文
kubectl create rolebinding devuser-admin-binding --clusterrole=admin --user=devuser --namespace=dev --dry-run -o yaml #先测试查看不执行
#创建一个rolebinding，因为我们希望devuser用户能够在dev名称空间下当管理员，rolebinding绑定的是一个admin集群角色，绑定给devuser用户，绑定在dev名称空间。
kubectl create rolebinding devuser-admin-binding --clusterrole=admin --user=devuser --namespace=dev
#进行赋予权限
mv /root/.kube/config /root/
#先将admin的config移动到root下，使其不生效
cp -a /etc/kubernetes/pki/devuser.kubeconfig /root/.kube/config
#将新创建的devuser的鉴权移动到/root/.kube/config，使其生效。
kubectl get pod -n dev
#有权限查看dev名称空间下的资源
kubectl get pod -n default
#查看default名称空间的pod时会报错。
#当前的root用户使用了devuser的权限，只能查看dev名称空间
cp -a config .kube/config
#将管理员的文件给覆盖回去
kubectl get pod
#现在又使用管理员的权限，所以可以查看了
useradd devuser
passwd devuser
mkdir /home/devuser/.kube/
cp -a /etc/kubenetes/pki/devuser.kubeconfig /home/devuser/.kube/config
#将devuser授权的文件放到devuser的家目录下。
chown -R devuser.devuser /home/devuser/.kube/
#给devuser用户授权。
登录devuser用户
kubectl get pod -n dev #可以查看
kubectl get pod -n default #无法查看
kubectl create deployment dev-deployment --image=nginx:latest
kubectl get pod
kubectl create svc clusterip dev-deployment --tcp=80:80
kubectl get svc三、准入控制
准入控制是API Server的插件集合，通过添加不同的插件，实现额外的准入控制规则。甚至于API Server的一些主要的功能都需要通过 Admission Controllers 实现，比如 ServiceAccount
插件列表：
NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,
DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,
ResourceQuota
列举几个插件的功能：
（1）NamespaceLifecycle： 防止在不存在的 namespace 上创建对象，防止删除系统预置 namespace，删除 namespace 时，连带删除它的所有资源对象。
（2）LimitRanger：确保请求的资源不会超过资源所在 Namespace 的 LimitRange 的限制。
（3）ServiceAccount： 实现了自动化添加 ServiceAccount。
（4）ResourceQuota：确保请求的资源不会超过资源的 ResourceQuota 限制。
以devuser用户登录终端
kubectl get sa -n dev
#这个default本质上就是我们的ServiceAccount，我们并没有创建，他是自己自动创建出来的
#这就是ServiceAccount插件的含义，每创建一个名称空间，他就会自动在当前的名称空间下创建一个default ServiceAccount
