K8S平台安全框架

1 平台安全框架

1.1 安全框架

1.1.1 认证框架

学习目标

这一节，我们从 基础知识、认证流程、小结 三个方面来学习。

基础知识

安全机制

	Kubernetes通过一系列的安全机制来实现Kubernetes的集群安全控制，这里面包括API Server的认证、授权、准入、Secret等机制。一般情况下，Kubernetes集群的安全性主要考虑如下几个目标：
	容器和宿主机的资源隔离、容器和宿主机的权限隔离、容器操作的最小权限
	组件通信的功能边界、普通用户和管理员用户、资源操作权限、等

资源操作

用户访问k8s业务应用的流程：
    方法一：无需api_server认证
        用户 -- ingress|service -- pod
    方法二：基于api_server认证
        管理k8s平台上各种应用对象

表现样式

	对于Kubernetes平台来说，几乎所有的操作基本上都是通过kube-apiserver这个组件进行的，该组件提供HTTP RESTful形式的API供集群内外客户端调用，对于kubernetes集群的部署样式主要有两种：http形式和https形式。
	我们采用kubeadm部署的形式默认对外是基于https的方式，而内部组件的通信时基于http方式，而k8s的认证授权机制仅仅存在于https形式的api访问中，也就是说，如果客户端使用HTTP连接到kube-apiserver，那么是不会进行认证授权的，这样既增加了安全性，也不至于太复杂。

认证流程

简介

对APIServer的访问一般都要经过的三个步骤，认证(Authn)+授权(Authz)、准入控制(Admission)，它也能在一定程度上提高安全性，不过更多是资源管理方面的作用。
注意：认证和授权功能都是以插件化的方式来实现的，这样可以最大化的用户自定义效果。

认证(Authn)
	对用户身份进行基本的认证，只允许被当前系统许可的人进入集群内部
授权(Authz)
	不同的用户可以获取不同的资源操作权限，比如普通用户、超级用户、等
准入控制(Admission)
	类似于审计，主要侧重于 操作动作的校验、语法规范的矫正等写操作场景。

解析

左侧：
	对于k8s来说，它主要面对两种用户：
		普通人类用户(交互模式) - User Account
		集群内部的pod用户(服务进程) - Service Account
中间：
	每个部分都是以插件的方式来整合到 k8s 集群环境中：
	- 认证和授权是按照 插件的顺序进行依次性的检测，并且遵循 "短路模型" 的认证方式
		所谓的"短路"即，失败的时候，到此结束,后续的规则不会进行。
	- 准入控制 由于仅用户写操作场景，所以它不遵循 "短路模型"，而是会全部检测
		原因在于，它要记录为什么不执行，原因是什么，方便后续审计等动作。

小结

1.1.2 框架解读

学习目标

这一节，我们从 流程解读、对象梳理、小结 三个方面来学习。

流程解读

认证

认证用户
	在我们的认证范围中，有一个术语叫Subject，它表示我们在集群中基于某些规则和动作尝试操作的对象，在k8s集群中定义了两种类型的subject资源：
	User Account：
		有外部独立服务进行管理的，对于用户的管理集群内部没有一个关联的资源对象
		如果需要操作k8s资源，需要集群内部证书的认证签名。
		因为是基于证书方式实现集群的https方式，所以这种认证，我们也称为 HTTPS证书认证
	Service Account
		通过Kubernetes API 来管理的一些用户帐号，和 namespace 进行关联的
		一般是内部资源对象操作资源的一种方式
		由于K8s内部的资源对象操作是借助于token方式认证校验的，我们也称为HTTP token认证

注意：
	曾经Kubernetes还有一种 HTTP Base的认证方式，通过在kube-apiserver内部实现用户名和密码方式认证，不过由于操作复杂、安全隐患过多，所以在 1.19版本之后就被废弃了

常见令牌

引导令牌：
	kubeadm创建集群环境的时候，自动创建好的令牌，用于其他节点加入到集群环境中
静态令牌：	
	存储于API Server进程可直接加载到的文件中保存的令牌，该文件内容会由API Server缓存于内存中
	比如我们在使用kubelet的时候，需要依赖的token文件
SA令牌:
	SA 就是 ServiceAccount，集群内部账号之间操作相关资源的一些认证方式。
Webhook令牌：
	常应用于触发第三个动作时候的一些认证机制，主要侧重于http协议场景。
等等

参考资料：
	https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/authentication/

用户组
	单个控制用户的权限台繁琐，可以借助于用户组的机制实现批量用户的自动化管理，主要有以下几种
	system:unauthenticated
		未能通过任何一个授权插件检验的账号的所有未通过认证测试的用户统一隶属的用户组；	
	system:authenticated
		认证成功后的用户自动加入的一个专用组，用于快捷引用所有正常通过认证的用户账号；
	system:serviceaccounts
		所有名称空间中的所有ServiceAccount对象
	system:serviceaccounts:
		特定名称空间内所有的ServiceAccount对象

认证方式
	kubernetes的认证方式主要有两种：
		证书认证 - 本质上就是TLS双向认证
		令牌认证 - 大量手动配置TLS认证比较麻烦，可以将证书生成token进行间接使用。

授权

	授权主要是在认证的基础上，用于对集群资源的访问控制权限设置，通过检查请求包含的相关属性值，与相对应的访问策略相比较，API请求必须满足某些策略才能被处理。
	我们可以在apiserver的启用文件kube-apiserver.yaml中使用
		--authorization-mode=xxx
	常见授权机制有：

Node
	一个专用鉴权模式，根据调度到 kubelet 上运行的 Pod 为 kubelet 授予权限。 
ABAC (Attribute Based Access Control)
	基于属性的访问控制（ABAC）定义了一种访问控制范型，通过使用将属性组合在一起的策略， 将访问权限授予用户。策略可以使用任何类型的属性（用户属性、资源属性、对象，环境属性等）。 
RBAC (Role Based Access Control)
	基于角色的访问控制（RBAC） 是一种基于企业内个人用户的角色来管理对计算机或网络资源的访问的方法。 在此上下文中，权限是单个用户执行特定任务的能力， 例如查看、创建或修改文件。
		被启用之后，RBAC基于 rbac.authorization.k8s.io允许管理员动态配置权限策略。
		要启用 RBAC，请使用 --authorization-mode=RBAC 启动 API 服务器。
Webhook
	WebHook 是一个 HTTP Callback：发生某些事情时调用的 HTTP POST，利用外部授权接口对于已有访问控制组件实现权限控制的无缝衔接。 
AlwaysDeny
	此标志阻止所有请求. 仅使用此标志进行测试
AlwaysAllow
	此标志允许所有请求. 只有在您不需要API请求授权的情况下才能使用此标志

我们重点使用的授权机制和默认使用的授权机制就是RBAC，而RBAC可以针对API的请求属性进行多层次的权限配置操作，这些授权的维度有：
	用户级别：用户名、用户组、用户扩展身份信息、服务账号等
	URL级别：API、API组、请求路径、请求权限、http属性等
	资源级别：资源名、子资源、命名空间等

准入控制

	准入控制(Admission Control)是一段代码，它会在请求通过认证和授权之后、对象被持久化之前拦截到达 API 服务器的请求。实际上是一个准入控制器插件列表并编译进 kube-apiserver 可执行文件，并且只能由集群管理员配置。准入控制器可以执行 “验证（Validating）” 和/或 “变更（Mutating）” 操作。
	发送到APIServer的请求都需要经过这个列表中的每个准入控制器插件的检查，如果某一个控制器插件准入失败，就准入失败。它主要涉及到pod和容器对特定用户和特定权限之间的关联关系。
	比如操作的对象是否存在依赖关系、被操作的对象是否能够增删改查等限制。

启用准入控制器
	kube-apiserver --enable-admission-plugins=xxx,xxx,...
关闭准入控制器
	kube-apiserver --disable-admission-plugins=xxx,xxx,...
查看准入控制器
	kube-apiserver -h | grep enable-admission-plugins

官方对于准入控制器的理解：
	Kubernetes 的许多高级功能都要求启用一个准入控制器，以便正确地支持该特性。 因此，没有正确配置准入控制器的 Kubernetes API 服务器是不完整的，它无法支持你所期望的所有特性。

准入控制器解读：https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/admission-controllers/#what-does-each-admission-controller-do

对象梳理

资源对象

对象简介

认证对象：SA、token
授权对象：Role、ClusterRole、RoleBinding、ClusterRoleBinding
准入对象：LimitRanger、ResourceQuota、PodSecurityPolicy等

小结

1.2 认证实践

1.2.1 令牌用户

学习目标

这一节，我们从 SA简介、SA实践、小结 三个方面来学习。

SA简介

简介

	当我们在创建 Pod 时，如果没有指定服务账户，Pod 会被指定给命名空间中的 default 服务账户。 如果你查看 Pod 的原始 JSON 或 YAML，你可以看到 spec.serviceAccountName 字段已经被自动设置了。相关的认证token信息会自动挂载到容器内部的 /var/run/secrets/kubernetes.io/serviceaccount 目录下。当然了，我们可以借助于 pod.spec.automountServiceAccountToken 属性禁止pod创建时候自动挂载Sa相关的信息。

查看默认的SA
[root@kubernetes-master1 ~]# kubectl get sa
NAME              SECRETS   AGE
default           0         27h

确认默认的pod自动关联默认SA
[root@kubernetes-master1 ~]# kubectl  run nginx --image kubernetes-register.superopsmsb.com/superopsmsb/nginx
pod/nginx created
[root@kubernetes-master1 ~]# kubectl  get pod nginx -o yaml | grep serviceAccountName
  serviceAccountName: default

SA & Secret

kubernetes的 SA 和 token的关系：
    1.20版本之前  
        -- 创建SA的时候，自动创建secret和配套的token
        -- 在pod内部直接挂载使用 
    1.21-1.23版本间
        -- 创建SA的时候，自动创建secret和配套的token
        -- 在pod内部挂载后，不直接使用
    1.24版本之后
        -- 创建SA的时候，不创建secret和配套的token
        -- 在pod使用的时候，由kubelet来自动申请

[root@kubernetes-master1 ~]# kubectl  describe sa default
Name:                default
Namespace:           default
Labels:              
Annotations:         
Image pull secrets:  
Mountable secrets:   
Tokens:              
Events:              
可以看到：
	对于1.24版本的k8s，sa账号内部没有关联任何其他的信息

SA实践

资源属性

apiVersion: v1  						# ServiceAccount所属的API群组及版本
kind: ServiceAccount  					# 资源类型标识
metadata:
  name   						# 资源名称
  namespace   					# ServiceAccount是名称空间级别的资源
automountServiceAccountToken   # 是否让Pod自动挂载API令牌
secrets <[]Object>   					# 以该SA运行的Pod所要使用的Secret对象组成的列表
  apiVersion   					# 引用的Secret对象所属的API群组及版本，可省略
  kind    						# 引用的资源的类型，这里是指Secret，可省略
  name    						# 引用的Secret对象的名称，通常仅给出该字段即可
  namespace   					# 引用的Secret对象所属的名称空间
  uid     						# 引用的Secret对象的标识符；
imagePullSecrets <[]Object> 			# 引用的用于下载Pod中容器镜像的Secret对象列表
  name    						# docker-registry类型的Secret资源的名称

命令解析

命令格式：kubectl create serviceaccount NAME [--dry-run] [options]
作用：创建一个"服务账号"
参数详解
    --dry-run=false						模拟创建模式
    --generator='serviceaccount/v1'		设定api版本信息
    -o, --output=''						设定输出信息格式，常见的有：
    										json|yaml|name|template|...
    --save-config=false					保存配置信息
    --template=''						设定配置模板文件

简单实践

创建专属目录
[root@kubernetes-master1 ~]# mkdir /data/kubernetes/secure -p; cd /data/kubernetes/secure

手工创建SA账号
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl create serviceaccount mysa
serviceaccount/mysa created

检查效果
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl  get sa mysa
NAME   SECRETS   AGE
mysa   1         9s

资源清单创建SA 01_kubernetes_platform_secure_sa.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: superopsmsb
---
apiVersion: v1
kind: Pod
metadata:
  name: nginx-web
spec:
  containers:
  - name: nginx-web
    image: kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1
  serviceAccountName: superopsmsb

应用资源清单
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl  apply -f 01_kubernetes_platform_secure_sa.yaml
serviceaccount/superopsmsb created
pod/nginx-web created

查看资源属性
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl describe pod nginx-web
Name:               nginx-web
... 
Containers:
  nginx-web:
    ...
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-wqb6w (ro)
...
结果显示：
	用户信息挂载到容器的 /var/run/secrets/kubernetes.io/serviceaccount 目录下了

容器内部的账号身份信息
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl exec -it nginx-web -- /bin/sh
# ls /var/run/secrets/kubernetes.io/serviceaccount/
ca.crt  namespace  token

清理环境
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl  delete -f 01_kubernetes_platform_secure_sa.yaml

禁止挂载SA信息

定制资源清单文件 02_kubernetes_platform_secure_nosa.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-web
spec:
  automountServiceAccountToken: false
  containers:
  - name: nginx-web
    image: kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1

应用资源清单文件
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl  apply -f 02_kubernetes_platform_secure_nosa.yaml
pod/nginx-web created

确认效果
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl  describe  pod nginx-web | grep 'Mounts:'
    Mounts:         
结果显示：
	SA账号没有进行相关证书的挂载操作

创建SA时候关联Secret

定制资源清单文件 03_kubernetes_platform_secure_sa_secret.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: superopsmsb
---
apiVersion: v1
kind: Secret
metadata:
  name: superopsmsb-secret
  annotations:
    kubernetes.io/service-account.name: superopsmsb
type: kubernetes.io/service-account-token

应用资源清单文件
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl apply -f 03_kubernetes_platform_secure_sa_secret.yaml
serviceaccount/superopsmsb created
secret/superopsmsb-secret created

确认效果
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl  get secret
NAME                 TYPE                                  DATA   AGE
superopsmsb-secret   kubernetes.io/service-account-token   3      5s
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl  describe  sa superopsmsb
Name:                superopsmsb
Namespace:           default
Labels:              
Annotations:         
Image pull secrets:  
Mountable secrets:   
Tokens:              superopsmsb-secret
Events:              

挂载SA的token信息给pod使用

定制资源清单文件 04_kubernetes_platform_secure_sa_secret_mount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: superopsmsb
---
apiVersion: v1
kind: Secret
metadata:
  name: superopsmsb-secret
  annotations:
    kubernetes.io/service-account.name: superopsmsb
type: kubernetes.io/service-account-token
---
apiVersion: v1
kind: Pod
metadata:
  name: nginx-web
spec:
  containers:
  - image: kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1
    name: nginx
    volumeMounts:
    - mountPath: /var/run/secrets/tokens
      name: superopsmsb-token
  serviceAccountName: superopsmsb
  volumes:
  - name: superopsmsb-token
    projected:
      sources:
      - serviceAccountToken:
          path: superopsmsb-token
          expirationSeconds: 7200
          audience: superopsmsb

应用资源清单文件
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl  apply -f 04_kubernetes_platform_secure_sa_secret_mount.yaml
serviceaccount/superopsmsb created
secret/superopsmsb-secret created
pod/nginx-web created

确认效果
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl  describe pod nginx-web
Name:         nginx-web
...
Containers:
  nginx:
    ...
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-9t6n8 (ro)
      /var/run/secrets/tokens from superopsmsb-token (rw)
...
Volumes:
  superopsmsb-token:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  7200
  kube-api-access-9t6n8:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       
    DownwardAPI:             true

1.2.2 证书用户

学习目标

这一节，我们从 UA简介、UA实践、小结 三个方面来学习。

UA简介

简介

	所有 Kubernetes 集群都有两类用户：由 Kubernetes 管理的服务账号和普通用户。当Kubernetes 集群有由一个与集群无关的服务通过以下方式之一进行管理的：
	负责分发私钥的管理员
	类似 Keystone 或者 App Accounts 这类用户数据库
	包含用户名和密码列表的文件
	
	Kubernetes 可以通过提供由集群的证书机构签名的合法证书的用户来进行登录，然后操作对应的资源对象。

	关于用户，我们可以通过证书中的 'subject' 的
		通用名称(Common Name)字段 （例如，"/CN=zhangsan"） 来确定用户名
		用户组(Organization)字段 （例如，"/O=dev"）来确定用户组
	示例：
	openssl req -new -key xxx.pem -out csr.pem -subj "/CN=zhangsan/O=dev/O=test"

创建证书相关资料：
	https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/certificates/

UA实践

简介

	所谓的UA其实就是我们平常做CA时候的基本步骤，主要包括如下几步
	1 创建私钥文件
    2 基于私钥文件创建证书签名请求
    3 基于私钥和签名请求生成证书文件

1 创建私钥文件

给用户 superopsmsb 创建一个私钥，命名成：superopsmsb.key(无加密)
[root@kubernetes-master1 ~]# cd /etc/kubernetes/pki/
[root@kubernetes-master1 /etc/kubernetes/pki]# (umask 077; openssl genrsa -out superopsmsb.key 2048)
G
命令解析：
    genrsa			该子命令用于生成RSA私钥，不会生成公钥，因为公钥提取自私钥
    -out filename	生成的私钥保存至filename文件，若未指定输出文件，则为标准输出
    -numbits		指定私钥的长度，默认1024，该项必须为命令行的最后一项参数

2 签名请求

用刚创建的私钥创建一个证书签名请求文件：superopsmsb.csr
[root@kubernetes-master1 /etc/kubernetes/pki]# openssl req -new -key  superopsmsb.key -out superopsmsb.csr -subj "/CN=superopsmsb/O=superopsmsb"
参数说明：
    -new  	生成证书请求文件
    -key   	指定已有的秘钥文件生成签名请求，必须与-new配合使用
    -out 	输出证书文件名称
    -subj 	输入证书拥有者信息，这里指定 CN 以及 O 的值，/表示内容分隔
        CN以及O的值对于kubernetes很重要，因为kubernetes会从证书这两个值对应获取相关信息：
        	"CN"：Common Name，用于从证书中提取该字段作为请求的用户名 (User Name)；
        		浏览器使用该字段验证网站是否合法；
        	"O"：Organization，用于分组认证

检查效果：
[root@kubernetes-master1 /etc/kubernetes/pki]# ls superopsmsb.*
superopsmsb.csr  superopsmsb.key
结果显示：
	*.key 是我们的私钥，*.csr是我们的签名请求文件

3 生成证书

利用Kubernetes集群的CA相关证书对UA文件进行认证
[root@kubernetes-master1 /etc/kubernetes/pki]# openssl x509 -req -in superopsmsb.csr -CA ./ca.crt  -CAkey ./ca.key  -CAcreateserial -out superopsmsb.crt -days 365
Signature ok
subject=/CN=superopsmsb/O=superopsmsb
Getting CA Private Key
参数说明：
    -req   				产生证书签发申请命令
    -in					指定需要签名的请求文件
    -CA 				指定CA证书文件
    -CAkey 			指定CA证书的秘钥文件
    -CAcreateserial	生成唯一的证书序列号
    -x509 				表示输出一个X509格式的证书
    -days 				指定证书过期时间为365天
    -out 				输出证书文件
检查文件效果
[root@kubernetes-master1 /etc/kubernetes/pki]# ls superopsmsb.*
superopsmsb.crt  superopsmsb.csr  superopsmsb.key
结果显示：
	*.crt就是我们最终生成的签证证书

提取信息效果
]# openssl x509 -in superopsmsb.crt -text -noout
Certificate:
   ...
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=kubernetes
        ...
        Subject: CN=superopsmsb, O=superopsmsb
结果显示：
	Issuer: 表示是哪个CA机构帮我们认证的
	我们关注的重点在于Subject内容中的请求用户所属的组信息

用户认证脚本

脚本文件内容 05_kubernetes_create_UA.sh
#!/bin/bash
# 功能: 创建kubernetes专属的UA信息
# 版本: v0.1
# 作者: 书记
# 联系: superopsmsb.com
# 定制普通环境变量
ssl_dir='/etc/kubernetes/pki'
config_dir='/tmp'
kubernernetes_entry='https://10.0.0.200:6443'
target_type=(证书 配置 退出)
# 菜单
menu(){
  echo -e "\e[31m批量设定远程主机免密码认证管理界面\e[0m"
  echo "====================================================="
  echo -e "\e[32m 1: 创建证书  2: 创建config  3: 退出操作 \e[0m"
  echo "====================================================="
}

# 创建证书文件
create_cert(){
  # 接收外部参数
  user_name="$1"
  group_name="$2"
  expire_time="$3"
  # 创建逻辑
  cd ${ssl_dir}
  (umask 077; openssl genrsa -out ${user_name}.key 2048)
  openssl req -new -key  ${user_name}.key -out ${user_name}.csr -subj "/CN=${user_name}/O=${group_name}"
  openssl x509 -req -in ${user_name}.csr -CA ./ca.crt  -CAkey ./ca.key  -CAcreateserial -out ${user_name}.crt -days ${expire_time}
}

# 创建认证配置文件
create_config(){
  # 接收外部参数
  conf_name="$1"
  user_name="$2"
  # 创建逻辑
  cd ${ssl_dir}
  kubectl config set-credentials ${user_name} --client-certificate=./${user_name}.crt --client-key=./${user_name}.key  --embed-certs=true --kubeconfig=${config_dir}/${conf_name}
  kubectl config set-cluster ${user_name} --server="${kubernernetes_entry}" --certificate-authority=/etc/kubernetes/pki/ca.crt --embed-certs=true --kubeconfig=${config_dir}/${conf_name}
  kubectl config set-context ${user_name}@${user_name} --cluster=${user_name} --user=${user_name} --kubeconfig=${config_dir}/${conf_name}
  kubectl config use-context ${user_name}@${user_name} --kubeconfig=${config_dir}/${conf_name}
}

# 帮助信息逻辑
Usage(){
  echo "请输入有效的操作id"
}
# 逻辑入口
while true
do
  menu
  read -p "请输入有效的操作id: " target_id
  if [ ${#target_type[@]} -ge ${target_id} ]
  then
    if [ ${target_type[${target_id}-1]} == "证书" ]
    then
       read -p "请输入有效的证书信息(用户名 组名 有效时间): " user_name group_name expire_time
       echo "开始创建证书操作..."
       create_cert ${user_name} ${group_name} ${expire_time}
    elif [ ${target_type[${target_id}-1]} == "配置" ]
    then
       read -p "请输入config文件名称(示例: zhangsan.conf): " conf_name
       echo "开始创建config操作..."
       create_config ${conf_name} ${user_name}
    elif [ ${target_type[${target_id}-1]} == "退出" ]
    then
       echo "开始退出管理界面..."
       exit
    fi
  else
    Usage
  fi
done

小结

1.3 授权实践

1.3.1 集群用户

学习目标

这一节，我们从 config基础、简单实践、小结 三个方面来学习。

config基础

简介

	根据我们之前对kubernetes集群的了解，我们主要是通过config文件来进入到kubernetes集群内部的，然后具有操作相关资源的权限。

在config文件内部主要做了四件事情：
	1 创建登录k8s集群的用户
		基于证书和秘钥信息创建用户
	2 创建登录k8s集群的地址
	3 将登录用户和目标k8s集群关联在一起，形成k8s集群入口
	4 设定默认的k8s集群入口
	
注意：
	这里的k8s集群入口其实就类似于我们 通过ssh登录远程主机的一个入口，示例如下：
		ssh root@10.0.0.12

命令解读

集群操作
	get-clusters    显示 kubeconfig 文件中定义的集群
	delete-cluster  删除 kubeconfig 文件中指定的集群
	set-cluster     Set a cluster entry in kubeconfig
	
用户操作 
	delete-user     Delete the specified user from the kubeconfig
	get-users       Display users defined in the kubeconfig
	set-credentials Set a user entry in kubeconfig
	
上下文操作 
	current-context Display the current-context
	delete-context  删除 kubeconfig 文件中指定的 context
	get-contexts    描述一个或多个 contexts
	rename-context  Rename a context from the kubeconfig file
	set-context     Set a context entry in kubeconfig
	use-context     Set the current-context in a kubeconfig file
	
其他操作 
    set             Set an individual value in a kubeconfig file
    unset           Unset an individual value in a kubeconfig file	  
    view            显示合并的 kubeconfig 配置或一个指定的 kubeconfig 文件

简单实践

创建用户

创建用户
[root@kubernetes-master1 /etc/kubernetes/pki]# kubectl config set-credentials superopsmsb --client-certificate=./superopsmsb.crt --client-key=./superopsmsb.key  --embed-certs=true --kubeconfig=/tmp/superopsmsb.conf
参数详解：
    set-credentials 	子命令的作用就是给kubeconfig认证文件创建一个用户条目
    --client-certificate=path/to/certfile	指定用户的签证证书文件
    --client-key=path/to/keyfile				指定用户的私钥文件
    --embed-certs=true，在kubeconfig中为用户条目嵌入客户端证书/密钥，默认值是false，
    --kubeconfig=/path/to/other_config.file 表示将属性信息单独输出到一个文件，不指定的话，表示存到默认的 ~/.kube/config文件中

创建集群

创建集群
[root@kubernetes-master1 /etc/kubernetes/pki]# kubectl config set-cluster mycluster  --server="https://10.0.0.200:6443" --certificate-authority=/etc/kubernetes/pki/ca.crt --embed-certs=true --kubeconfig=/tmp/superopsmsb.conf
参数详解：
	--server=cluster_api_server
	--certificate-authority=path/to/certificate/authority

关联用户和集群

配置上下文信息
[root@kubernetes-master1 /etc/kubernetes/pki]# kubectl  config set-context superopsmsb@mycluster --cluster=mycluster --user=superopsmsb  --kubeconfig=/tmp/superopsmsb.conf
属性详解
    --cluster=cluster_nickname		关联的集群名称
    --user=user_nickname			关联的用户名称
    --namespace=namespace			可以设置该生效的命名空间

设定默认的入口

更改默认登录kubernetes的用户
[root@kubernetes-master1 /etc/kubernetes/pki]# kubectl config use-context superopsmsb@mycluster --kubeconfig=/tmp/superopsmsb.conf

测试效果

查看配置文件内容
[root@kubernetes-master1 /etc/kubernetes/pki]# kubectl config view --kubeconfig=/tmp/superopsmsb.conf
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://10.0.0.200:6443
  name: mycluster
contexts:
- context:
    cluster: mycluster
    user: superopsmsb
  name: superopsmsb@mycluster
current-context: superopsmsb@mycluster
kind: Config
preferences: {}
users:
- name: superopsmsb
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED

查看资源测试
[root@kubernetes-master1 /etc/kubernetes/pki]# kubectl get pod --kubeconfig=/tmp/superopsmsb.conf
Error from server (Forbidden): pods is forbidden: User "superopsmsb" cannot list resource "pods" in API group "" in the namespace "default"
结果显示：
	虽然提示报错，但是这也证明了用户已经被kubernetes承认了

小结

1.3.2 角色基础

学习目标

这一节，我们从 RBAC、角色绑定、小结三个方面来学习。

RBAC

场景简介

授权机制

	RBAC使用rbac.authorization.k8s.io API Group 来实现授权决策，允许管理员通过 Kubernetes API 动态配置策略，要启用RBAC，需要在 apiserver 中添加参数--authorization-mode=RBAC，kubeadm安装的集群默认开启了RBAC，我们可以通过查看 Master 节点上 apiserver 的静态Pod定义文件：
[root@kubernetes-master1 ~]# grep authorization-mode /etc/kubernetes/manifests/kube-apiserver.yaml
    - --authorization-mode=Node,RBAC

	Kubernetes的基本特性就是它的所有资源对象都是模型化的 API 对象，我们可以基于api-server对各种资源进行增、删、改、查等操作，但是这些操作涉及到的不仅仅是资源本身和动作，而且还涉及到资源和动作之间的内容，比如api的分组版本和资源和api的关联即权限授权等。

授权

	所谓的授权，其实指的是，将某些subject对象赋予执行某些资源动作的权限。我们有时候会将其称为Group(权限组)，而这个组其实是有两部分组成：组名和组关联(也称绑定)。
简单来说：所谓的授权，其实是为用户授予xx角色

    所谓的RBAC，说白了就是为 xx用户 赋予 xx资源 的 xx权限。
        授权主体： 用户、用户组、服务账号
        授权对象： 集群角色、命名空间角色
        授权动作： 集群绑定、命名空间绑定

授权属性

关于kubernetes的授权属性，主要包括如下三个层次：namespace级别、cluster级别、混合级别

namespace级别
	rules 
		- 规则，是一组属于不同 API Group 资源上的权限操作的集合
	role 
		- 表示在一个namespace中基于rules使用资源的权限，主要涉及到操作和对象
	RoleBingding 
		- 将Subject和Role绑定在一起，表示Subject具有指定资源的role操作权限

cluster级别
	ClusterRole 
		- 表示在一个Cluster中基于rules使用资源的权限
	ClusterRoleBingding 
		- 将Subject和ClusterRole绑定在一起，表示Subject指定资源的ClusterRole操作权限

混合级别
	RoleBingding 
		- 将Subject基于RoleBingding与ClusterRole绑定在一起
		- 表示Subject可以使用所有ClusterRole中指定资源的role角色
		- 但是限制在了只能操作某个命名空间的资源。
		- 也就是所谓的"权限降级"

场景1：
	多个namespace中的role角色都一致，如果都使用内部的RoleBingding的话，每个namespace都必须单独创建role，而使用ClusterRole的话，只需要一个就可以了，大大的减轻批量使用namespace中的RoleBingding 操作。
场景2：
	我们对A用户要提升权限，但是，由于A处于考察期，那么我们暂时给他分配一个区域，测试一下它的运行效果。生活中的场景，提升张三为公司副总裁，但是由于是新手，所以加了一个限制 -- 主管销售范围的副总裁。

角色绑定

内部角色

	kubernetes 预制了很多不同功能场景的内部角色功，这些角色主要有：资源发现、用户操作、核心组件、其他组件、控制器等。这些常见的角色除了用户操作相关的角色之外，其他的角色都是以system:为前缀

资源发现角色：
	system:basic-user	system:authenticated 组	
		允许用户以只读的方式去访问他们自己的基本信息。
	system:discovery	system:authenticated 组	
		允许以只读方式访问 API 发现端点，这些端点用来发现和协商 API 级别。 
	system:public-info-viewer	system:authenticated 和 system:unauthenticated 组	
		允许对集群的非敏感信息进行只读访问。
注意：
	这些ClusterRole 是以前缀 system: 开头的

用户操作角色：
	cluster-admin	system:masters 组	
		允许超级用户在平台上的任何资源上执行所有操作。 
		当在 ClusterRoleBinding 中使用时，可以授权对集群所有资源进行完全控制。 
		当在 RoleBinding 中使用时，可以授权特定名字空间中的所有资源操作。
	admin	无组	
		允许管理员访问权限，旨在使用 RoleBinding 在名字空间内执行授权。
	edit	无组	
		允许对名字空间的大多数对象进行读/写操作，不允许查看或者修改角色或者角色绑定。
        可以访问 Secret，以名字空间中任何 ServiceAccount 的身份运行 Pod
	view	无组	
		允许对名字空间的大多数对象有只读权限，不允许查看角色或角色绑定。
		不允许查看 Secrets，因为读取 Secret 的内容依赖 ServiceAccount 的凭据信息。

[root@kubernetes-master1 /data/kubernetes/secure]# kubectl get clusterrole  | grep -v 'system:'
NAME                       CREATED AT
admin                      2062-09-04T10:57:12Z
cluster-admin              2062-09-04T10:57:12Z
edit                       2062-09-04T10:57:12Z
flannel                    2062-09-05T01:25:49Z
kubeadm:get-nodes          2062-09-04T10:57:27Z
view                       2062-09-04T10:57:12Z

小结

1.3.3 授权基础

学习目标

这一节，我们从 Role实践、clusterRole实践、小结 三个方面来学习。

Role实践

属性解析

我们可以使用 kubectl explain role 的方式来查看一下Role的属性信息：

    apiVersion 
    kind 
    metadata