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:<namespace>
		特定名称空间内所有的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:              <none>
Annotations:         <none>
Image pull secrets:  <none>
Mountable secrets:   <none>
Tokens:              <none>
Events:              <none>
可以看到：
	对于1.24版本的k8s，sa账号内部没有关联任何其他的信息

SA实践

资源属性

apiVersion: v1  						# ServiceAccount所属的API群组及版本
kind: ServiceAccount  					# 资源类型标识
metadata:
  name <string>  						# 资源名称
  namespace <string>  					# ServiceAccount是名称空间级别的资源
automountServiceAccountToken <boolean>  # 是否让Pod自动挂载API令牌
secrets <[]Object>   					# 以该SA运行的Pod所要使用的Secret对象组成的列表
  apiVersion <string>  					# 引用的Secret对象所属的API群组及版本，可省略
  kind <string>   						# 引用的资源的类型，这里是指Secret，可省略
  name <string>   						# 引用的Secret对象的名称，通常仅给出该字段即可
  namespace <string>  					# 引用的Secret对象所属的名称空间
  uid  <string>   						# 引用的Secret对象的标识符；
imagePullSecrets <[]Object> 			# 引用的用于下载Pod中容器镜像的Secret对象列表
  name <string>   						# 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:         <none>
结果显示：
	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:              <none>
Annotations:         <none>
Image pull secrets:  <none>
Mountable secrets:   <none>
Tokens:              superopsmsb-secret
Events:              <none>

挂载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:       <nil>
    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 <string>
    kind <string>
    metadata     <Object>
    rules        <[]Object>
      apiGroups    			<[]string>
      nonResourceURLs      	<[]string>
      resourceNames        	<[]string>
      resources    			<[]string>
      verbs        			<[]string> -required-
    结果显示：
        对于role来说，其核心的内容主要是rules的权限规则
        在这么多rules属性中，最重要的是verbs权限条目，而且所有的属性都是可以以列表的形式累加存在

	kubectl 提供 auth can-i 子命令，用于快速查询当前用户是否可以执行给定操作。格式如下：
	kubectl auth can-i [权限] [资源对象] <--namespace 命名空间>
	注意：
		如果返回值是True，表示当前用户具有该权限

命令行创建role，查看具有pod资源的get、list权限的属性信息
[root@kubernetes-master1 ~]# kubectl create role pods-reader --verb=get,list --resource=pods --dry-run -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  creationTimestamp: null		时间信息
  name: pods-reader				role的名称
rules:							授权规则
- apiGroups:					操作的对象
  - ""								所有权限
  resources:					资源对象
  - pods							pod的对象
  verbs:							对pod允许的权限
  - get								获取
  - list								查看
结果显示：
    对于一个role必备的rules来说，他主要有三部分组成：apiGroup、resources、verbs
    apiGroups	设定包含资源的api组，如果是多个，表示只要属于api组范围中的任意资源都可以操作
    resources	位于apiGroup范围中的某些具体的资源对象
    verbs		针对具体资源对象的一些具体操作
注意：
	关于api组的信息获取，可以参照https://kubernetes.io/docs/reference/#api-reference

简单实践

按照上面的role格式，我们写一个role资源文件,允许用户操作 Deployment、Pod、RS 的所有权限
[root@kubernetes-master1 /data/kubernetes/secure]# 05_kubernetes_platform_secure_rbac_role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: myrole
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["pods", "deployments", "replicasets"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
属性解析：
    Pod属于 core 的 API Group，在YAML中用空字符就可以，Deployment 属于 apps 的 API Group，ReplicaSets属于extensions这个 API Group，所以 rules 下面的 apiGroups 的内容：["", "extensions", "apps"]
    verbs是可以对这些资源对象执行的操作，如果是所有动作，也可以使用["*"]来代替。

查看资源对象

初始化实例对象
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl  apply -f 05_kubernetes_platform_secure_rbac_role.yaml
role.rbac.authorization.k8s.io/myrole created

查看效果
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl describe role myrole 

Role用户授权实践

限定用户只能访问命名空间资源
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl create rolebinding super-rolebind --role=myrole --user=superopsmsb
rolebinding.rbac.authorization.k8s.io/super-rolebind created

查看资源效果
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl  get pod --kubeconfig=/tmp/superopsmsb.conf
NAME        READY   STATUS    RESTARTS   AGE
nginx-web   1/1     Running   0          56m
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl  get svc --kubeconfig=/tmp/superopsmsb.conf
Error from server (Forbidden): services is forbidden: User "superopsmsb" cannot list resource "services" in API group "" in the namespace "default"
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl  get svc --kubeconfig=/tmp/superopsmsb.conf -n kube-system
Error from server (Forbidden): services is forbidden: User "superopsmsb" cannot list resource "services" in API group "" in the namespace "kube-system"

清理授权
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl delete rolebindings super-rolebind
rolebinding.rbac.authorization.k8s.io "super-rolebind" deleted

ClusterRole实践

属性解析

[root@kubernetes-master1 /data/kubernetes/secure]# kubectl explain clusterrole
aggregationRule      <Object>
apiVersion <string>
kind <string>
metadata     <Object>
rules        <[]Object>
    apiGroups    			<[]string>
    nonResourceURLs      	<[]string>
    resourceNames        	<[]string>
    resources    			<[]string>
    verbs        			<[]string> -required-
结果显示：
	clusterrole相对于role的属性多了一个集中控制器的属性aggregationRule，而这是一个可选的属性

命令行创建clusterrole，查看具有pod资源的get、list权限的属性信息
[root@kubernetes-master1 ~]# kubectl create clusterrole myclusterrole --verb=get,list --resource=pods --dry-run -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: null		时间信息
  name: myclusterrole			role的名称
rules:							授权规则
- apiGroups:					操作的对象
  - ""								所有权限
  resources:					资源对象
  - pods							pod的对象
  verbs:							对pod允许的权限
  - get								获取
  - list								查看
结果显示：
    ClusterRole与role的配置一样，也由三部分组成：apiGroup、resources、verbs

简单实践

按照上面的clusterrole格式，我们写一个clusterrole资源文件,允许用户操作 Deployment、Pod、RS 的所有权限
[root@kubernetes-master1 /data/kubernetes/secure]# 06_kubernetes_platform_secure_rbac_clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: myclusterrole
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
  
创建资源对象
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl  apply -f 06_kubernetes_platform_secure_rbac_clusterrole.yaml
clusterrole.rbac.authorization.k8s.io/myclusterrole created

查看效果
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl describe clusterrole myclusterrole
Name:         myclusterrole
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  pods       []                 []              [get list watch]

ClusterRole用户授权实践

限定用户只能访问命名空间资源
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl create clusterrolebinding super-clusterrolebind --clusterrole=myclusterrole --user=superopsmsb

查看资源效果
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl  get pod --kubeconfig=/tmp/superopsmsb.conf
NAME        READY   STATUS    RESTARTS   AGE
nginx-web   1/1     Running   0          68m
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl  get svc --kubeconfig=/tmp/superopsmsb.conf
Error from server (Forbidden): services is forbidden: User "superopsmsb" cannot list resource "services" in API group "" in the namespace "default"
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl  get pod --kubeconfig=/tmp/superopsmsb.conf -n kube-system
NAME                                         READY   STATUS    RESTARTS         AGE
coredns-5d555c984-hzq8q                      1/1     Running   0                9h

清理授权
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl delete clusterrolebinding super-clusterrolebind
rolebinding.rbac.authorization.k8s.io "super-clusterrolebind" deleted

小结

1.3.4 用户组实践

学习目标

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

基础知识

简介

	在实际的工作中，往往会有一大批用户具有相同的角色权限，那么我们就没有必要为每一个用户赋予一些权限，这样的话太过繁琐。有一种简单的方法就是将用户加入到一个用户组，然后为用户组赋予操作权限，这样的话，该用户组的所有用户都会具有对应的操作权限。

创建用户的时候，用户组的设定
]# openssl req -new -key  superopsmsb.key -out superopsmsb.csr -subj "/CN=superopsmsb/O=superopsmsb"

查看证书的用户组信息
]# openssl x509 -in superopsmsb.crt -text -noout
Certificate:
   ...
    Signature Algorithm: sha256WithRSAEncryption
        ...
        Subject: CN=superopsmsb, O=superopsmsb

创建普通用户

[root@kubernetes-master1 /data/scripts]# /bin/bash 05_kubernetes_create_UA.sh
批量设定远程主机免密码认证管理界面
=====================================================
 1: 创建证书  2: 创建config  3: 退出操作
=====================================================
请输入有效的操作id: 1
请输入有效的证书信息(用户名 组名 有效时间): zhangsan superopsmsb 365
开始创建证书操作...
Generating RSA private key, 2048 bit long modulus
..+++
...............................+++
e is 65537 (0x10001)
Signature ok
subject=/CN=zhangsan/O=superopsmsb
Getting CA Private Key
批量设定远程主机免密码认证管理界面
=====================================================
 1: 创建证书  2: 创建config  3: 退出操作
=====================================================
请输入有效的操作id: 2
请输入config文件名称(示例: zhangsan.conf): zhangsan.conf
开始创建config操作...
User "zhangsan" set.
Cluster "zhangsan" set.
Context "zhangsan@zhangsan" created.
Switched to context "zhangsan@zhangsan".
批量设定远程主机免密码认证管理界面
=====================================================
 1: 创建证书  2: 创建config  3: 退出操作
=====================================================
请输入有效的操作id: 3
开始退出管理界面...

简单实践

role用户赋权

创建role资源对象
kubectl  apply -f 05_kubernetes_platform_secure_rbac_role.yaml

创建基于组的 rolebinding
kubectl create rolebinding super-rolebind --role=myrole --group=superopsmsb

正常演示效果效果
kubectl get pod --kubeconfig=/tmp/superopsmsb.conf
kubectl get pod --kubeconfig=/tmp/zhangsan.conf

异常演示效果
kubectl  get svc --kubeconfig=/tmp/superopsmsb.conf
kubectl  get svc --kubeconfig=/tmp/zhangsan.conf

还原环境
kubectl delete rolebindings super-rolebind

clusterrole用户赋权

创建clusterrole资源对象
kubectl  apply -f 06_kubernetes_platform_secure_rbac_clusterrole.yaml

创建基于组的 rolebinding
kubectl create clusterrolebinding super-clusterrolebind --clusterrole=myclusterrole --group=superopsmsb

正常演示效果效果
kubectl get pod --kubeconfig=/tmp/superopsmsb.conf
kubectl get pod --kubeconfig=/tmp/zhangsan.conf

异常演示效果
kubectl  get svc --kubeconfig=/tmp/superopsmsb.conf -n kube-system
kubectl  get svc --kubeconfig=/tmp/zhangsan.conf -n kube-system

还原环境
kubectl delete clusterrolebinding super-clusterrolebind

小结

1.3.5 SA授权

学习目标

这一节，我们从 场景需求、简单实践、小结 三个方面来学习。

场景需求

简介

	作为k8s平台的应用资源，肯定会出现平台上的A应用需要访问B应用的资源对象的一些情况，对于这种场景的需求，我们一般是直接借助于kubernetes的SA的token机制来实现的。

基本操作流程：
	1 创建SA账号
	2 创建Role角色
	3 SA和Role角色进行绑定
	4 使用pod内部的token进行通信认证测试

准备工作 - 升级django镜像(旧有django镜像的Python版本太低了，需要升级)

准备python镜像
docker pull python
docker tag python kubernetes-register.superopsmsb.com/superopsmsb/python

准备基准代码文件
cd /data/images/web/django/
cp -a django python

修改首页信息
# vim blog/app1/views.py
...
    version=os.environ.get("PYTHON_VERSION")
    ....

定制Dockerfile文件
[root@kubernetes-master1 ~]# cat /data/images/web/python/Dockerfile
# 构建一个基于python的定制镜像
# 基础镜像
FROM kubernetes-register.superopsmsb.com/superopsmsb/python
# 镜像作者
MAINTAINER shuji@superopsmsb.com

# 拷贝文件
RUN pip install django==3.1.2
ADD blog /data/code/blog
ADD scripts/startup.sh /data/scripts/startup.sh

# 暴露django端口
EXPOSE 8000

# 定制容器的启动命令
CMD ["/bin/bash", "/data/scripts/startup.sh"]

定制构造镜像
docker build -t kubernetes-register.superopsmsb.com/superopsmsb/django_web:v0.2 /data/images/web/python/

测试构造镜像
docker run -d --name django-test -p 666:8000 kubernetes-register.superopsmsb.com/superopsmsb/django_web:v0.2

测试效果
curl 10.0.0.12:666
docker rm -f django-test

提交镜像到远程仓库
docker push kubernetes-register.superopsmsb.com/superopsmsb/django_web:v0.2

测试脚本

准备测试脚本
]# cat /data/scripts/06_kubernetes_test_pod.py
"""
检测Kubernetes的SA令牌文件权限
"""

# 1 导入模块
from kubernetes import client, config

# 2 打开令牌
with open('/var/run/secrets/kubernetes.io/serviceaccount/token') as f:
    token = f.read()

# 3 定制连接kubernetes对象
configuration = client.Configuration()
configuration.host = "https://kubernetes"
configuration.ssl_ca_cert = "/var/run/secrets/kubernetes.io/serviceaccount/ca.crt"
configuration.verify_ssl = True
configuration.api_key = {"authorization": "Bearer " + token}
client.Configuration.set_default(configuration)
apps_api = client.AppsV1Api()
core_api = client.CoreV1Api()

# 4 检测权限信息
try:
    print("----显示default空间的Service资源对象----")
    for svc in apps_api.list_namespaced_service("default").items:
        print(svc.metadata.name)
        print("Service名称: %s, 命名空间: %s" % (svc.metadata.name, svc.metadata.namespace))
except:
    print("没有访问default空间的Service资源对象的权限")
# 5 检测权限信息
try:
    print("----显示default空间的Pod资源对象----")
    for pod in core_api.list_namespaced_pod("default").items:
        print("Pod名称: %s, Pod地址: %s, 命名空间: %s" % (pod.metadata.name, pod.status.pod_ip, pod.metadata.namespace))
except:
    print("没有访问default空间的Pod资源对象的权限")

try:
    print("----显示kube-system空间的Pod资源对象----")
    for pod in core_api.list_namespaced_pod("kube-system").items:
        print("Pod名称: %s, Pod地址: %s, 命名空间: %s" % (pod.metadata.name, pod.status.pod_ip, pod.metadata.namespace))
except:
    print("没有访问kube-system空间的Pod资源对象的权限")

简单实践

创建资源

资源清单文件内容 08_kubernetes_platform_secure_sa_username.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: superopsmsb
---
apiVersion: v1
kind: Pod
metadata:
  name: django-web
spec:
  containers:
  - image: kubernetes-register.superopsmsb.com/superopsmsb/django_web:v0.2
    name: django
    volumeMounts:
    - mountPath: /var/run/secrets/tokens
      name: superopsmsb-token
  serviceAccountName: superopsmsb

应用资源对象
kubectl apply -f 08_kubernetes_platform_secure_sa_username.yaml

拷贝脚本文件到容器内部
kubectl cp /data/scripts/06_kubernetes_test_pod.py django-web:/

进入django-web环境中
kubectl exec -it django-web -- /bin/bash

安装模块插件
pip install kubernetes

测试效果

role赋权操作
kubectl  apply -f 05_kubernetes_platform_secure_rbac_role.yaml
kubectl  create rolebinding super-rolebind --role=myrole --serviceaccount=default:superopsmsb

django-web环境中测试效果
root@django-web:/# python 06_kubernetes_test_pod.py
----显示default空间的Service资源对象----
没有访问default空间的Service资源对象的权限
----显示default空间的Pod资源对象----
Pod名称: django-web, Pod地址: 10.244.4.9, 命名空间: default
Pod名称: my-deploy-6c44c54668-rzhmg, Pod地址: 10.244.5.9, 命名空间: default
Pod名称: nginx, Pod地址: 10.244.4.6, 命名空间: default
Pod名称: nginx-nosa, Pod地址: 10.244.5.2, 命名空间: default
----显示kube-system空间的Pod资源对象----
没有访问kube-system空间的Pod资源对象的权限

clusterrole赋权操作
kubectl  apply -f 06_kubernetes_platform_secure_rbac_clusterrole.yaml
kubectl create clusterrolebinding super-clusterrolebind --clusterrole=myclusterrole --serviceaccount=default:superopsmsb

django-web环境中测试效果
root@django-web:/# python 06_kubernetes_test_pod.py
----显示default空间的Service资源对象----
没有访问default空间的Service资源对象的权限
----显示default空间的Pod资源对象----
Pod名称: django-web, Pod地址: 10.244.4.9, 命名空间: default
...
----显示kube-system空间的Pod资源对象----
Pod名称: coredns-7dc9dcf7fd-4b8vp, Pod地址: 10.244.2.4, 命名空间: kube-system
...

小结

1.3.6 SA秘钥

学习目标

这一节，我们从 场景需求、简单实践、小结 三个方面来学习。

场景需求

简介

	我们以kubernetes的dashboard页面访问为例，基于SA的token信息做一个config的文件认证。

功能需求：
	基于zhangsan的SA账号定制config文件，只允许访问superopsmsb的命名空间资源对象。
	基于lisi的SA账号定制config文件，允许访问所有命名空间资源对象。
	
注意：
	集群级别的权限，可以借助于默认的 Clusterrole -- cluster-admin

准备工作

创建命名空间
kubectl create ns superopsmsb

创建资源对象
kubectl create deployment nginx --image kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1 --replicas 3  -n superopsmsb
kubectl expose deployment nginx --port 80  -n superopsmsb

简单实践

命名空间SA实践

定制SA资源清单文件
cat 03_kubernetes_platform_secure_sa_secret.yaml > 09_kubernetes_platform_secure_zhangsan_config.yaml

修改资源清单文件 09_kubernetes_platform_secure_zhangsan_config.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: zhangsan
  namespace: superopsmsb
---
apiVersion: v1
kind: Secret
metadata:
  name: zhangsan-secret
  namespace: superopsmsb
  annotations:
    kubernetes.io/service-account.name: zhangsan
type: kubernetes.io/service-account-token

定制集群权限角色策略
kubectl -n superopsmsb create role zhangsan --verb="*" --resource="*" --dry-run=client
echo '---' >> 09_kubernetes_platform_secure_zhangsan_config.yaml
kubectl -n superopsmsb create role zhangsan --verb="*" --resource="*" --dry-run=client -o yaml >> 09_kubernetes_platform_secure_zhangsan_config.yaml

定制集群权限绑定策略
kubectl -n superopsmsb create rolebinding zhangsan-rolebind --role=zhangsan --serviceaccount=superopsmsb:zhangsan --dry-run=client

echo '---' >> 09_kubernetes_platform_secure_zhangsan_config.yaml
kubectl -n superopsmsb create rolebinding zhangsan-rolebind --role=zhangsan --serviceaccount=superopsmsb:zhangsan --dry-run=client -o yaml >> 09_kubernetes_platform_secure_zhangsan_config.yaml

创建资源对象
kubectl apply -f 09_kubernetes_platform_secure_zhangsan_config.yaml

定制config文件的集群内容
kubectl config set-cluster kubernetes --certificate-authority=/etc/kubernetes/pki/ca.crt  --server="https://10.0.0.200:6443" --embed-certs=true --kubeconfig=/root/dashboard-zhangsan.conf

定制config文件的用户内容
NAMESPACE_TOKEN=$(kubectl -n superopsmsb get secrets $(kubectl get secret -n superopsmsb  | awk '/zhangsan/{print $1}') -o jsonpath={.data.token} | base64 -d)
kubectl config set-credentials dashboard-zhangsan --token=$NAMESPACE_TOKEN --kubeconfig=/root/dashboard-zhangsan.conf

定制config文件的上下文内容
kubectl config set-context dashboard-zhangsan@kubernetes --cluster=kubernetes --user=dashboard-zhangsan --kubeconfig=/root/dashboard-zhangsan.conf
kubectl config use-context dashboard-zhangsan@kubernetes --kubeconfig=/root/dashboard-zhangsan.conf

确认效果
kubectl get pod -n superopsmsb --kubeconfig /root/dashboard-zhangsan.conf
kubectl get pod -n kube-system --kubeconfig /root/dashboard-zhangsan.conf

下载 dashboard-superopsmsb.conf 文件到宿主机，然后用宿主机进行应用访问

集群级别SA实践

定制SA资源清单文件
cat 03_kubernetes_platform_secure_sa_secret.yaml > 10_kubernetes_platform_secure_lisi_config.yaml

修改资源清单文件 10_kubernetes_platform_secure_lisi_config.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: lisi
  namespace: superopsmsb
---
apiVersion: v1
kind: Secret
metadata:
  name: lisi-secret
  namespace: superopsmsb
  annotations:
    kubernetes.io/service-account.name: lisi
type: kubernetes.io/service-account-token

定制集群权限绑定策略
kubectl create clusterrolebinding lisi-clusterrolebind --clusterrole=cluster-admin --serviceaccount=superopsmsb:lisi --dry-run=client

echo '---' >> 10_kubernetes_platform_secure_lisi_config.yaml
kubectl create clusterrolebinding lisi-clusterrolebind --clusterrole=cluster-admin --serviceaccount=superopsmsb:lisi --dry-run=client -o yaml >> 10_kubernetes_platform_secure_lisi_config.yaml

创建资源对象
kubectl apply -f 10_kubernetes_platform_secure_lisi_config.yaml

定制config文件的集群内容
kubectl config set-cluster kubernetes --certificate-authority=/etc/kubernetes/pki/ca.crt  --server="https://10.0.0.200:6443" --embed-certs=true --kubeconfig=/root/dashboard-lisi.conf

定制config文件的用户内容
NAMESPACE_TOKEN=$(kubectl -n superopsmsb get secrets $(kubectl get secret -n superopsmsb  | awk '/lisi/{print $1}') -o jsonpath={.data.token} | base64 -d)
kubectl config set-credentials dashboard-lisi --token=$NAMESPACE_TOKEN --kubeconfig=/root/dashboard-lisi.conf

定制config文件的上下文内容
kubectl config set-context dashboard-lisi@kubernetes --cluster=kubernetes --user=dashboard-lisi --kubeconfig=/root/dashboard-lisi.conf
kubectl config use-context dashboard-lisi@kubernetes --kubeconfig=/root/dashboard-lisi.conf

测试效果
kubectl get pod -n kube-system --kubeconfig /root/dashboard-lisi.conf

下载 dashboard-cluster.conf 文件到宿主机，然后用宿主机进行应用访问

小结

1.4 准入实践

1.4.1 准入基础

学习目标

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

基础知识

简介

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

	Kubernetes 的许多高级功能都要求启用一个准入控制器，以便正确地支持该特性。 因此，没有正确配置准入控制器的 Kubernetes API 服务器是不完整的，它无法支持你所期望的所有特性。而且越来越多的控制性功能组件以准入控制器的样式出现。

准入机制

	准入控制过程分为两个阶段，运行变更准入控制器 和 运行验证准入控制器。 实际上，某些控制器既是变更准入控制器又是验证准入控制器。如果任何一个阶段的任何控制器拒绝了该请求，则整个请求将立即被拒绝，并向终端用户返回一个错误。

最后，除了对对象进行变更外，准入控制器还可以有其它作用：将相关资源作为请求处理的一部分进行变更。 增加使用配额就是一个典型的示例，说明了这样做的必要性。 此类用法都需要相应的回收或回调过程，因为任一准入控制器都无法确定某个请求能否通过所有其它准入控制器。

准入控制器类型

	kubernetes的准入控制器主要有两种类型：
		内置的静态准入控制器组件
			- 基于kube-apiserver启动时候设置的控制器属性
		扩展的动态准入控制器组件
			- 用于接收准入请求并对其进行处理的 HTTP 回调机制

流程解读

控制器配置

	准入控制器需要在kube-apiserver中进行配置，我们的kubeadm的kube-apiserver的配置文件中就通过属性开启了准入控制器：

# grep -ni 'admission' /etc/kubernetes/manifests/kube-apiserver.yaml
20:    - --enable-admission-plugins=NodeRestriction

准入控制器使用

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

更多控制器的作用：https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/admission-controllers/#what-does-each-admission-controller-do

查看默认开启的准入控制器

[root@kubernetes-master1 ~]# kubectl -n kube-system exec -it kube-apiserver-kubernetes-master1 -- kube-apiserver -h | grep 'enable-admission-plugins strings'
      --enable-admission-plugins strings       admission plugins that should be enabled in addition to default enabled ones (NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, PodSecurity, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota). Comma-delimited list of admission plugins: AlwaysAdmit,....
结果显示：
	默认启用了 18个 准入控制器。

常见与pod相关的准入控制器

limitranger
	为Pod添加默认的计算资源需求和计算资源限制；以及存储资源需求和存储资源限制； 支持分别在容器和Pod级别进行限制；
resourcequota
	限制资源数量，限制计算资源总量，存储资源总量；资源类型名称
ResourceQuotapodsecuritpolicy
	在集群级别限制用户能够在Pod上可配置使用的所有securityContext。由于RBAC的加强，该功能在 Kubernetes v1.21 版本中被弃用，将在 v1.25 中删除

小结

1.4.2 优先调度

学习目标

这一节，我们从 场景解析、简单实践、小结 三个方面来学习。

场景解析

资源调度

	资源调度为即将执行的任务，选择合理的节点Pod调度为即将执行的任务，分配合理的逻辑关联搭配污点调度在任务调度的时候，设定一些避免措施拓扑调度在任务已确定调度的前提下，合理的分配任务，实现资源的高效利用。按照调度的基本属性可以划分为：
		节点调度、pod调度、污点调度、拓扑调度

调度优先级

	在实际的工作场景中，往往会因为应用资源的需求特点，我们在调度的时候，可能先出现的应用可以正常的运行，在后出现的资源对象往往会因为资源不足而无法调度。
	如果后续创建的pod的重要性比较高，如果以默认的资源调度方式实现pod创建的话，导致无法创建，所以我们会引入pod优先级的概念，如果当前pod优先级比较高的话，我们可以抢占优先级值较低的pod资源。
	在一个并非所有用户都是可信的集群中，恶意用户可能以最高优先级创建 Pod， 导致"调度队列"中的其他 Pod 被驱逐或者无法被调度。管理员可以使用 ResourceQuota 来阻止用户创建高优先级的 Pod。
	注意：
		它不会对已经调度的资源对象进行驱逐,它主要针对的是调度队列里面的pod

优先级和抢占

要使用优先级和抢占：
	1 新增一个或多个 PriorityClass。
	2 创建 Pod，并将其 priorityClassName 设置为新增的 PriorityClass。
		- PriorityClass 可以内嵌到deployment的模板属性中
		
注意：
	PriorityClass 是一个无命名空间对象，它定义了从优先级类名称到优先级整数值的映射

默认的优先级抢占

	Kubernetes 已经提供了 2 个 PriorityClass： system-cluster-critical 和 system-node-critical
    [root@kubernetes-master1 /data/kubernetes/secure]# kubectl get priorityclasses
    NAME                      VALUE        GLOBAL-DEFAULT   AGE
    system-cluster-critical   2000000000   false            3d18h
    system-node-critical      2000001000   false            3d18h
    
注意：
 	这两个值是20亿，远远超过可以定义的优先级值，它用于确保始终优先调度关键组件

属性解析

apiVersion: scheduling.k8s.io/v1			
kind: PriorityClass							# 资源类型
metadata:
  name: high-priority						# 调度优先级名称，不能以 system- 为前缀
value: 1000000								# 值越大，优先级越高，不允许超过10亿
preemptionPolicy: Never						# 是否为非抢占式优先级，1.24版本正式
globalDefault: false						# 是否是全局默认的优先级
description: "xxx"							# 基本描述信息

简单实践

定制优先级

资源对象文件 11_kubernetes_platform_secure_priorityclass.yaml
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: "定制高优先级"
--- 
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: low-priority
value: 100000
globalDefault: false
description: "定制低优先级"
应用资源对象
kubectl apply -f 11_kubernetes_platform_secure_priorityclass.yaml

确认效果
kubectl get priorityclass
kubectl describe priorityclass

应用优先级

在node1上创建资源对象
apiVersion: v1
kind: Pod
metadata:
  name: low-priority
spec:
  nodeName: "kubernetes-node1"
  containers:
  - name: low-priority
    image: kubernetes-register.superopsmsb.com/superopsmsb/busybox
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo hello; sleep 10;done"]
    resources:
      requests:
        memory: "2Gi"
        cpu: "1"
  priorityClassName: low-priority

应用资源清单文件
kubectl apply -f 12_kubernetes_platform_secure_priorityclass_pod.yaml

确认效果
]# kubectl get pod
]# kubectl describe  nodes  kubernetes-node1  | egrep 'cpu |memory  '
  cpu                1250m (62%)  0 (0%)
  memory             2Gi (55%)    0 (0%)

清理环境

kubectl delete -f 12_kubernetes_platform_secure_priorityclass_pod.yaml
kubectl apply -f 11_kubernetes_platform_secure_priorityclass.yaml

小结

1.4.3 资源配额

学习目标

这一节，我们从 属性解读、简单实践、小结 三个方面来学习。

属性解读

简介

	Kubernetes技术已经对Pod做了相应的资源配额设置，这些资源主要体现在：CPU和内存、存储，因为存储在k8s中有专门的资源对象来进行管控，所以我们在说到pod资源限制的时候，一半指的是 CPU和内存。Kubernetes中，对于每种资源的配额限定都需要两个参数：Resquests和Limits
    申请配额(Requests)：
        业务运行时最小的资源申请使用量，该参数的值必须满足，若不满足，业务运行不起来。
    最大配额(Limits)：
        业务运行时最大的资源允许使用量，该参数的值不能被突破，若突破，该资源对象会被重启或删除

资源配额

	当k8s集群被多个用户或团队使用时，为了避免因为团队的资源对象使用导致资源抢占的问题，我们需要借助于资源配额(ResourceQuota)，来帮助集群管理员为不同的团队或资源对象分配资源的使用量。
	ResourceQuota是命名空间级别的资源对象，它主要基于资源对象的数量 和 资源消耗的总量来进行限制。
	-- ResourceQuota 处理的是 资源的不均匀使用
参考资料：https://kubernetes.io/zh/docs/concepts/policy/resource-quotas/

工作方式

资源配额的工作方式如下：
	ResourceQuota为命名空间做资源配额，不同的团队在不同的命名空间下工作。
	ResourceQuota为命名空间做多个资源配额，团队针对场景使用不同的配额，实现精细化配置
	结合LimitRange 准入控制器对资源的使用量进行更加精细化的设置
	超出配额限制，返回403 FORBIDDEN

使用示例

	k8s集群的资源量：32 GiB 内存 和 16 核CPU资源，该集群被两个团队使用：
		- 允许A团队使用 15 GiB 内存 和 8 核的CPU资源
		- 允许B团队使用 10 GiB 内存 和 4 核的CPU资源
		- 预留 7 GiB 内存 和 4 核的CPU资源供将来分配。
		- 限制 “dev” 命名空间使用 1 GiB 内存 和  核的CPU资源
		- 允许 “superopsmsb”命名空间使用任意数量。

常见资源配额限制

计算资源配额
limits.cpu|memory	所有非终止状态的 Pod，其 CPU|MEM 限额总量不能超过该值。
requests.cpu|memory	所有非终止状态的 Pod，其 CPU|MEM 需求总量不能超过该值。
cpu|memory			与 requests.cpu|memory 相同。

存储资源配置
requests.storage		所有 PVC，存储资源的需求总量不能超过该值。
persistentvolumeclaims	在该命名空间中所允许的 PVC 总量。
<storage-class-name>.storageclass.storage.k8s.io/requests.storage	
		在与 <storage-class-name> 相关的持久卷申领中，存储请求的总和不能超过该值。
<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims	
		在与 <storage-class-name> 相关的所有持久卷申领中，命名空间中可以存在的持久卷申领总数。

资源对象配额
	样式：
		count/<resource>.<group>：用于非核心（core）组的资源的数量上限
		count/<resource>：用于核心组的资源的数量上限
	资源对象
		configmaps、persistentvolumeclaims、pods、replicationcontrollers
		ReplicationController、resourcequotas、services、services.loadbalancers
		services.nodeports、secrets

属性解读

ResourceQuota的配置属性
apiVersion: v1
kind: ResourceQuota
metadata:
  name: 						# 资源对象的名称
spec:
  hard:							# 资源配额的优先级，主要有low、medium、high三类
    cpu: "1000"						# CPU资源的配额
    memory: 200Gi						# mem资源的配额
    pods: "10"						# pod数量的配额
  scopeSelector:					# 选择合适的pod资源对象
    matchExpressions:					# 标签选择器
      - operator : In					# 操作符号，支持In、NotIn、Exists、DoesNotExist
        scopeName: PriorityClass		# 基于谁来比较，PriorityClass代表配额优先级
        values: ["high"]
        
注意：
	如果 operator 为 Exists 或 DoesNotExist，则不可以设置 values 字段。

定制优先调度

资源对象文件 13_kubernetes_platform_secure_priorityclass_list.yaml
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high
value: 10000
globalDefault: false
description: "high priority"
---
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: low
value: 100
globalDefault: false
description: "low priority"
---
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: medium
value: 1000
globalDefault: false
description: "medium priority"

应用资源对象文件
kubectl apply -f 13_kubernetes_platform_secure_priorityclass_list.yaml

查看效果
kubectl get priorityclass

设定资源配额

资源清单文件 14_kubernetes_platform_secure_resourcequota_list.yaml
apiVersion: v1
kind: List
items:
- apiVersion: v1
  kind: ResourceQuota
  metadata:
    name: pods-high
  spec:
    hard:
      cpu: "2"
      memory: 2Gi
      pods: "5"
    scopeSelector:
      matchExpressions:
      - operator : In
        scopeName: PriorityClass
        values: ["high"]
- apiVersion: v1
  kind: ResourceQuota
  metadata:
    name: pods-medium
  spec:
    hard:
      cpu: "2"
      memory: 1Gi
      pods: "4"
    scopeSelector:
      matchExpressions:
      - operator : In
        scopeName: PriorityClass
        values: ["medium"]
- apiVersion: v1
  kind: ResourceQuota
  metadata:
    name: pods-low
  spec:
    hard:
      cpu: "1"
      memory: 1Gi
      pods: "3"
    scopeSelector:
      matchExpressions:
      - operator : In
        scopeName: PriorityClass
        values: ["low"]

创建资源对象
kubectl apply -f 14_kubernetes_platform_secure_resourcequota_list.yaml

检查效果
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl describe quota
Name:       pods-high
Namespace:  default
Resource    Used  Hard
--------    ----  ----
cpu         0     2
memory      0     2Gi
pods        0     5
...
Name:       pods-medium
Namespace:  default
Resource    Used  Hard
--------    ----  ----
cpu         0     2
memory      0     1Gi
pods        0     4

使用资源配额

资源对象文件 15_kubernetes_platform_secure_resourcequota_pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: high-priority
spec:
  containers:
  - name: high-priority
    image: kubernetes-register.superopsmsb.com/superopsmsb/busybox
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo hello; sleep 10;done"]
    resources:
      requests:
        memory: "1Gi"
        cpu: "500m"
      limits:
        memory: "1Gi"
        cpu: "500m"
  priorityClassName: high

创建资源对象
kubectl apply -f 15_kubernetes_platform_secure_resourcequota_pod.yaml

检查效果
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl get quota
NAME          AGE   REQUEST                                       LIMIT
pods-high     89m   cpu: 0/1k, memory: 0/200Gi, pods: 0/10
pods-low      89m   cpu: 300m/5, memory: 500Mi/10Gi, pods: 1/10
pods-medium   89m   cpu: 0/10, memory: 0/20Gi, pods: 0/10

小结

1.4.4 配额实践

学习目标

这一节，我们从 pod资源、对象数量、小结 三个方面来学习。

pod资源

简介

	ResourceQuota是命名空间级别的资源对象，它主要基于资源对象的数量 和 资源消耗的总量来进行限制。这一节，我们针对pod的资源使用量来进行调整。
	关于资源的使用量，我们主要是针对 cpu、mem、storage 对象来进行设置

简单实践

资源对象文件 16_kubernetes_platform_secure_resourcequota_compute.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
  namespace: superopsmsb
spec:
  hard:
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: storage-resources
  namespace: superopsmsb
spec:
  hard:
    requests.storage: "5Gi"

应用资源对象
kubectl apply -f 16_kubernetes_platform_secure_resourcequota_compute.yaml

查看效果
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl describe quota compute-resources storage-resources --namespace=superopsmsb
Name:            compute-resources
Namespace:       superopsmsb
Resource         Used  Hard
--------         ----  ----
limits.cpu       0     2
limits.memory    0     2Gi
requests.cpu     0     1
requests.memory  0     1Gi

Name:             storage-resources
Namespace:        superopsmsb
Resource          Used  Hard
--------          ----  ----
requests.storage  0     5Gi

创建资源对象 17_kubernetes_platform_secure_resourcequota_compute_test.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx1
  namespace: superopsmsb
spec:
  containers:
  - name: nginx
    image: kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1
    resources:
      requests:
        memory: "1Gi"
        cpu: "1"
      limits:
        memory: "1Gi"
        cpu: "1"
---
apiVersion: v1
kind: Pod
metadata:
  name: nginx2
  namespace: superopsmsb
spec:
  containers:
  - name: nginx
    image: kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1
    resources:
      requests:
        memory: "1Gi"
        cpu: "1"
      limits:
        memory: "1Gi"
        cpu: "1"

应用资源对象
kubectl apply -f 17_kubernetes_platform_secure_resourcequota_compute_test.yaml

删除对象
kubectl delete -f 17_kubernetes_platform_secure_resourcequota_compute_test.yaml
kubectl delete -f 16_kubernetes_platform_secure_resourcequota_compute.yaml

对象数量

简介

	ResourceQuota是命名空间级别的资源对象，它主要基于资源对象的数量 和 资源消耗的总量来进行限制。这一节，我们针对资源对象的使用数量来进行限制。

简单实践

资源对象文件 18_kubernetes_platform_secure_resourcequota_count.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: object-counts
  namespace: superopsmsb
spec:
  hard:
    configmaps: "2"
    persistentvolumeclaims: "2"
    pods: "7"
    replicationcontrollers: "6"
    secrets: "2"
    services: "6"
    services.loadbalancers: "2"

应用资源对象
kubectl apply -f 18_kubernetes_platform_secure_resourcequota_count.yaml

查看效果
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl describe quota -n superopsmsb
Name:                   object-counts
Namespace:              superopsmsb
Resource                Used  Hard
--------                ----  ----
configmaps              1     2
persistentvolumeclaims  0     2
pods                    3     7
replicationcontrollers  0     6
secrets                 0     2
services                1     6
services.loadbalancers  0     2

测试效果

[root@kubernetes-master1 /data/kubernetes/secure]# kubectl -n superopsmsb create configmap cm1 --from-literal=a=a
configmap/cm1 created
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl -n superopsmsb create configmap cm2 --from-literal=a=a
error: failed to create configmap: configmaps "cm2" is forbidden: exceeded quota: object-counts, requested: configmaps=1, used: configmaps=2, limited: configmaps=2

清理环境
kubectl delete -f 18_kubernetes_platform_secure_resourcequota_count.yaml

小结

1.4.5 资源限制

学习目标

这一节，我们从 属性解读、简单实践、小结 三个方面来学习。

属性解读

简介

	默认情况下， Kubernetes 集群上的容器运行使用的计算资源没有限制。 使用资源配额，集群管理员可以以名字空间为单位，限制其资源的使用与创建。 在命名空间中，一个 Pod 或 Container 最多能够使用命名空间的资源配额所定义的 CPU 和内存用量。 这可能导致 Pod 或 Container 会垄断所有可用的资源。 LimitRange 是在命名空间内限制资源分配（给多个 Pod 或 Container）的策略对象。
	
	limitranger可以对集群内Request和Limits的配置做一个全局的统一的限制，相当于批量设置了某一个范围内(某个命名空间)的Pod的资源使用限制。

Limitrange的功能特点：
	在一个命名空间中实施对每个 Pod 或 Container 最小和最大的资源使用量的限制。
    在一个命名空间中实施对每个 PersistentVolumeClaim 能申请的最小和最大的存储空间大小的限制。
    在一个命名空间中实施对一种资源的申请值和限制值的比值的控制。
    设置一个命名空间中对计算资源的默认申请/限制值，并且自动的在运行时注入到多个 Container 中。

属性解析

apiVersion: v1
kind: LimitRange
metadata:
  name: 						# 资源对象的名称
spec:
  limits:						# 资源对象的运行限制
  - max:						# 最大资源限制,支持cpu 和 memory
      cpu: "800m"				
    min:						# 最小资源限制,支持cpu 和 memory
      cpu: "200m"				
    default:					# 默认资源限制,支持cpu 和 memory
      cpu: 800m
    defaultRequest:				# 默认资源请求限制,支持cpu 和 memory
      cpu: "110m"
    maxLimitRequestRatio:       # 控制资源限制量和请求量的最大比例,支持cpu 和 memory
      memory: 2
    type: Container				# 资源限制作用类型,，常见的类型有：
    							# Container、Pod、PersistentVolumeClaim等 

简单实践

容器资源限制

资源对象内容 19_kubernetes_platform_secure_limitrange_container.yaml
apiVersion: v1
kind: LimitRange
metadata:
  name: limit-container
spec:
  limits:
  - max:
      cpu: "800m"
      memory: "1Gi"
    min:
      cpu: "100m"
      memory: "99Mi"
    default:
      cpu: "700m"
      memory: "900Mi"
    defaultRequest:
      cpu: "110m"
      memory: "111Mi"
    type: Container

应用资源对象
kubectl apply -f 19_kubernetes_platform_secure_limitrange_contaner.yaml

查看效果
# kubectl get limitranges
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl describe limitranges limit-container
Name:       limit-container
Namespace:  default
Type        Resource  Min   Max   Default Request  Default Limit  Max Limit/Request Ratio
----        --------  ---   ---   ---------------  -------------  -------------------
Container   cpu       100m  800m  110m             700m           -
Container   memory    99Mi  1Gi   111Mi            900Mi          -

创建测试资源对象 20_kubernetes_platform_secure_limitrange_container_test.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx-1
    image: kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1
  - name: nginx-2
    image: kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1
    resources:
      requests:
        memory: "100Mi"
        cpu: "100m"
  - name: nginx-3
    image: kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1
    resources:
      limits:
        memory: "200Mi"
        cpu: "500m"
    
应用资源对象
kubectl apply -f 20_kubernetes_platform_secure_limitrange_container_test.yaml

确认效果
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl describe  pod nginx
Name:         nginx
...
Containers:
  nginx-1:
    ...
    Limits:
      cpu:     700m
      memory:  900Mi
    Requests:
      cpu:        110m
      memory:     111Mi
    
  nginx-2:
    ...
    Limits:
      cpu:     700m
      memory:  900Mi
    Requests:
      cpu:        100m
      memory:     100Mi
    
  nginx-3:
    ...
    Limits:
      cpu:     500m
      memory:  200Mi
    Requests:
      cpu:        500m
      memory:     200Mi

清理环境
kubectl delete -f 19_kubernetes_platform_secure_limitrange_container.yaml -f 20_kubernetes_platform_secure_limitrange_container_test.yaml

pvc资源限制

资源对象内容 21_kubernetes_platform_secure_limitrange_pvc.yaml
apiVersion: v1
kind: LimitRange
metadata:
  name: limit-pvc
spec:
  limits:
  - type: PersistentVolumeClaim
    max:
      storage: 2Gi
    min:
      storage: 1Gi

应用资源对象
kubectl apply -f kubectl apply -f 21_kubernetes_platform_secure_limitrange_pvc.yaml

查看效果
# kubectl get limitranges
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl describe limitranges limit-pvc
Name:                  limit-pvc
Namespace:             default
Type                   Resource  Min  Max  Default Request  Default Limit  Max Limit/Request Ratio
----                   --------  ---  ---  ---------------  -------------  -----------------------
PersistentVolumeClaim  storage   1Gi  2Gi  -                -              -

创建测试资源对象 22_kubernetes_platform_secure_limitrange_pvc_test.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-volume
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/tmp"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pv-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi
    
应用资源对象
kubectl apply -f 22_kubernetes_platform_secure_limitrange_pvc_test.yaml

清理资源对象
kubectl delete -f 21_kubernetes_platform_secure_limitrange_pvc.yaml -f 22_kubernetes_platform_secure_limitrange_pvc_test.yaml

小结

1.4.6 Pod策略

学习目标

这一节，我们从 功能解读、环境部署、小结 三个方面来学习。

功能解读

简介

	在 Kubernetes 中，我们定义了代表软件应用程序构建块的资源，例如 Deployment、StatefulSet 和 Services。Kubernetes 集群内的各种控制器对这些资源做出反应，创建更多的 Kubernetes 资源或配置一些软件或硬件来实现我们的目标。
	虽然我们可以借助于与RBAC实现资源对象的权限管控，但是安全的管理粒度还是比较大，PodSecurityPolicy是一个内置的准入控制器，允许集群管理员控制 Pod 规范的安全敏感方面，而且它还可以与PodSecurityContext 实现pod级别的更深层次的安全管控。

	只不过，由于kubernetes管理人员的能力水平不足，导致在使用PSP的时候，意外授予比预期更广泛的权限，而且难以检查在给定情况下应用哪些 PSP可以被我们进行正常使用，所以为了照顾大部分的普通kubernetes管理人员的玻璃心，PSP被废弃了，预计在1.25版本清除掉。但是PSP并没有完全移除，而是以 PodSecurity 准入控制器的方式来进行存在了。

基本信息

查看默认的准入控制器列表
kubectl -n kube-system exec -it kube-apiserver-kubernetes-master1 -- kube-apiserver -h | grep 'enable-admission-plugins strings'
结果显示：	
	PodSecurityPolicy 默认情况下，没有启用

注意：
	由于默认psp是拒绝所有pod的，所以我们在启用psp的时候，需要额外做一些措施 -- 即提前做好psp相关的策略，然后再开启PSP功能。

PodSecurityPolicy默认情况下可以进行多个维度的安全限制：
	pod级别的特权：
		privileged				创建具有特权命令执行权限的容器
		volumes					允许使用的数据卷
	宿主机资源：
		hostNetwork|hostPorts	使用宿主机网络资源
		hostPID|hostIPC			使用宿主机命名空间
	容器级别属性：
		runAsUser|runAsGroup|supplementalGroups		指定容器的用户属性信息
	其他属性：
		allowedCapabilities、defaultAddCapabilities、等
参考资料：
	https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/psp-to-pod-security-standards/#podsecuritypolicy-spec

实践步骤

	Policy本身并不会产生实际作用，需要将其与用户或者serviceaccount绑定才可以完成授权。所以生产中PSP的基本的操作步骤是：
		1 定义psp资源的策略
		2 定制PSP相关的账号授权
		3 集群启用PSP功能
	如果要在生产环境中使用，必须要提前测试一下，否则不推荐使用，因为它的门槛较多

我们这里直接从集群直接启用PSP的步骤开始，来给大家演示一个完整的安全过程

环境部署

启用psp功能

编辑 /etc/kubernetes/manifests/kube-apiserver.yaml 文件，添加如下配置
	--enable-admission-plugins=NodeRestriction,PodSecurityPolicy
	
由于kubeadm集群中，api-server是以静态pod的方式来进行管控的，所以我们不用重启，稍等一会，环境自然就开启了PSP功能

因为PSP默认已经禁用所有的pod创建权限，所以默认情况下，我们也看不到api-server的pod的
kubectl get pod -n kube-system | grep api
注意：
	如果出现api-server的pod，是因为其他master启用PSP太慢导致的。

我们只能通过端口方式来进行检测
[root@kubernetes-master1 ~]# netstat -atnulp | grep 6443
tcp        0      0 10.0.0.12:52818         10.0.0.12:6443          ESTABLISHED 108627/kube-control
tcp        0      0 10.0.0.12:36852         10.0.0.200:6443         ESTABLISHED 127389/kubelet
tcp        0      0 10.0.0.12:52350         10.0.0.12:6443          ESTABLISHED 123701/kube-schedul
tcp        0      0 10.0.0.12:36314         10.0.0.200:6443         ESTABLISHED 3109/kube-proxy
...
结果显示：
	只要我们能够看到 6443，说明kube-apiserver服务已经启动成功了

检查效果

定制资源清单文件 23_kubernetes_platform_secure_psp_deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1

创建资源清单文件
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl apply -f 23_kubernetes_platform_secure_psp_deployment.yaml
deployment.apps/nginx-deployment created

检查效果
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl get deployments.apps
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   0/1     0            0           79s
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl get rs
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-647c85d77f   1         0         0       84s
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl get pod
No resources found in default namespace.
结果显示：
	除了pod没有创建成功，其他的都创建成功了

手工测试创建pod
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl run pod-client --image kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1
Error from server (Forbidden): pods "pod-client" is forbidden: PodSecurityPolicy: no providers available to validate pod request
结果显示：
	没有权限操作PSP资源

临时允许PSP开启所有权限

资源对象文件 24_kubernetes_platform_secure_psp_all.yaml
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: privileged
spec:
  privileged: true
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  seLinux:
    rule: RunAsAny
  volumes:
  - '*'

创建资源对象
kubectl apply -f 24_kubernetes_platform_secure_psp_all.yaml

创建pod
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl run pod-client --image kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1
pod/pod-client created
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl get pod
NAME         READY   STATUS    RESTARTS   AGE
pod-client   1/1     Running   0          3s
结果显示：
	经过psp的授权，所以我们能够创建pod了

清理环境
kubectl delete -f 23_kubernetes_platform_secure_psp_deployment.yaml -f 24_kubernetes_platform_secure_psp_all.yaml

小结

1.4.7 策略实践

学习目标

这一节，我们从 属性解读、简单实践、小结 三个方面来学习。

属性解读

简介

	根据我们刚才的实践，应该能够感受的到，PSP的核心就是针对Pod资源对象的所有权限的精细化管控，如果要实现Pod的更加精细的安全性，我们需要定制特定的PSP规则。
	为了让管理员可以自由的管理pod资源对象，所以我们还需要针对PSP的策略规则定制RBAC的授权，才可以放心的交给相关的人员去使用，否则会导致更大的问题。

策略属性

PSP策略基本属性
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: privileged   				# 设定PSP策略名称
spec:								# 设定PSP的特定规则，实现多个维度的安全限制
  privileged: true					# 是否开启容器的特权模式
  hostNetwork: false				# 是否允许pod使用宿主机网络
  hostPorts:						# 允许容器使用宿主机的端口范围
    - min: 10000
      max: 13000
  runAsUser:						# 设定容器的属主、属组等相关信息
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  seLinux:							# 使用宿主机的Selinux策略
    rule: RunAsAny
  volumes:							# 允许pod使用所有类型的数据卷模式
  - '*'

简单实践

定制PSP策略

资源清单文件 25_kubernetes_platform_secure_psp_mul.yaml
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: psp-restrictive
spec:
  privileged: false
  hostNetwork: false
  allowPrivilegeEscalation: false
  defaultAllowPrivilegeEscalation: false
  hostPID: false
  hostIPC: false
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  volumes:
  - '*'
---
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: psp-permissive
spec:
  privileged: true
  hostNetwork: true
  hostIPC: true
  hostPID: true
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  volumes:
  - '*'

应用资源清单文件
kubectl apply -f 25_kubernetes_platform_secure_psp_mul.yaml

查看效果
[root@kubernetes-master1 /data/kubernetes/secure]# kubectl get psp
Warning: policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
NAME              PRIV    CAPS   SELINUX    RUNASUSER   FSGROUP    SUPGROUP   READONLYROOTFS   VOLUMES
psp-permissive    true           RunAsAny   RunAsAny    RunAsAny   RunAsAny   false            *
psp-restrictive   false          RunAsAny   RunAsAny    RunAsAny   RunAsAny   false            *

定制SA使用PSP的RBAC

定制角色权限
kubectl create clusterrole psp-restrictive --verb=use --resource=podsecuritypolicies --resource-name=psp-restrictive --dry-run=client

kubectl create clusterrole psp-restrictive --verb=use --resource=podsecuritypolicies --resource-name=psp-restrictive --dry-run=client -o yaml >> 26_kubernetes_platform_secure_psp_restrictive_rbac.yaml
echo '---' >> 26_kubernetes_platform_secure_psp_restrictive_rbac.yaml

定制角色授权
kubectl create clusterrolebinding psp-restrictive --clusterrole=psp-restrictive --group="system:serviceaccounts" --dry-run=client -o yaml

kubectl create clusterrolebinding psp-restrictive --clusterrole=psp-restrictive --group="system:serviceaccounts" --dry-run=client -o yaml >> 26_kubernetes_platform_secure_psp_restrictive_rbac.yaml

应用资源清单文件
kubectl apply -f 26_kubernetes_platform_secure_psp_restrictive_rbac.yaml

测试效果
kubectl apply -f 23_kubernetes_platform_secure_psp_deployment.yaml
kubectl get all

kubectl apply -f 23_kubernetes_platform_secure_psp_deployment.yaml -n superopsmsb
kubectl get all -n superopsmsb
结果显示：
	正常的资源可以正常的创建

清理环境
kubectl delete -f 23_kubernetes_platform_secure_psp_deployment.yaml
kubectl delete -f 23_kubernetes_platform_secure_psp_deployment.yaml -n superopsmsb

小结

1.4.8 策略进阶

学习目标

这一节，我们从 网络策略、SA策略、小结 三个方面来学习。

网络策略

简介

	虽然我们刚才实现了通用用户组创建资源对象的效果，但是对于一些特殊场景来说，比如 kube-apiserver之类的服务需要底层网络的支持才能够建立起来：。
]# grep hostNe /etc/kubernetes/manifests/kube-apiserver.yaml
  hostNetwork: true
  	如果当前的psp没有hostNetwork的支持的话，很多特殊的依赖于底层网络的应用pod都无法建立。

改造实践

改造deployment
cp 23_kubernetes_platform_secure_psp_deployment.yaml  27_kubernetes_platform_secure_psp_deployment_hostnetwork.yaml

改造文件
[root@kubernetes-master1 /data/kubernetes/secure]# cat 27_kubernetes_platform_secure_psp_deployment_hostnetwork.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      hostNetwork: true   # 增加此处配置
      containers:
      - name: nginx
        image: kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1

创建资源对象
kubectl apply -f 27_kubernetes_platform_secure_psp_deployment_hostnetwork.yaml
查看效果
kubectl get deployments.apps
结果显示：
	pod无法创建

分析：
	我们刚才定制的RBAC使用的PSP策略是没有包含 hostNetwork 等宿主机属性的使用权限的。所以我们要使用另外一个PSP的策略来进行管理

定制网络使用PSP的RBAC

定制角色权限
kubectl create clusterrole psp-permissive --verb=use --resource=podsecuritypolicies --resource-name=psp-permissive --dry-run=client

kubectl create clusterrole psp-permissive --verb=use --resource=podsecuritypolicies --resource-name=psp-permissive --dry-run=client -o yaml >> 28_kubernetes_platform_secure_psp_permissive_rbac.yaml
echo '---' >> 28_kubernetes_platform_secure_psp_permissive_rbac.yaml

定制角色授权
kubectl create clusterrolebinding psp-permissive --clusterrole=psp-permissive --group="system:serviceaccounts" --dry-run=client -o yaml

kubectl create clusterrolebinding psp-permissive --clusterrole=psp-permissive --group="system:serviceaccounts" --dry-run=client -o yaml >> 28_kubernetes_platform_secure_psp_permissive_rbac.yaml

应用资源清单文件
kubectl apply -f 28_kubernetes_platform_secure_psp_permissive_rbac.yaml

测试效果
kubectl delete -f 27_kubernetes_platform_secure_psp_deployment_hostnetwork.yaml
kubectl apply -f 27_kubernetes_platform_secure_psp_deployment_hostnetwork.yaml
kubectl get deployments.apps
结果显示：
	正常的资源可以正常的创建

清理环境
kubectl delete -f 27_kubernetes_platform_secure_psp_deployment_hostnetwork.yaml
kubectl delete -f 28_kubernetes_platform_secure_psp_permissive_rbac.yaml

SA策略

简介

	如果我们有一个需求: 在某个命名空间下面要使用受限制的psp_restrictive策略，但是个别应用需要使用 psp_permissive策略。
	对于这种场景，我们可以为应用的 ServiceAccount 提供使用 psp_permissive 策略，其思路与Clusterrole和rolebinding的逻辑类似。

准备资源清单

准备资源清单文件
kubectl create sa superopsmsb -n superopsmsb --dry-run=client -o yaml > 29_kubernetes_platform_secure_psp_deployment_sa.yaml
echo '---' >> 29_kubernetes_platform_secure_psp_deployment_sa.yaml
cat 27_kubernetes_platform_secure_psp_deployment_hostnetwork.yaml >> 29_kubernetes_platform_secure_psp_deployment_sa.yaml
 
定制资源清单文件 29_kubernetes_platform_secure_psp_deployment_sa.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: null
  name: superopsmsb
  namespace: superopsmsb
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: superopsmsb
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      serviceAccount: superopsmsb
      hostNetwork: true
      containers:
      - name: nginx
        image: kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1

尝试创建资源清单文件
kubectl apply -f 29_kubernetes_platform_secure_psp_deployment_sa.yaml

检查效果
kubectl get deployments.apps -n superopsmsb
结果显示：
	没有创建成功
	
kubectl delete -f 29_kubernetes_platform_secure_psp_deployment_sa.yaml

定制特定SA使用PSP的RBAC

定制角色权限
kubectl create clusterrole psp-permissive --verb=use --resource=podsecuritypolicies --resource-name=psp-permissive --dry-run=client

kubectl create clusterrole psp-permissive --verb=use --resource=podsecuritypolicies --resource-name=psp-permissive --dry-run=client -o yaml >> 30_kubernetes_platform_secure_psp_permissive_rbac_sa.yaml
echo '---' >> 30_kubernetes_platform_secure_psp_permissive_rbac_sa.yaml

定制角色授权
kubectl create clusterrolebinding psp-permissive --clusterrole=psp-permissive --serviceaccount=superopsmsb:superopsmsb --dry-run=client -o yaml

kubectl create clusterrolebinding psp-permissive --clusterrole=psp-permissive --serviceaccount=superopsmsb:superopsmsb --dry-run=client -o yaml >>30_kubernetes_platform_secure_psp_permissive_rbac_sa.yaml

应用资源清单文件
kubectl apply -f 30_kubernetes_platform_secure_psp_permissive_rbac_sa.yaml

测试效果
kubectl apply -f 30_kubernetes_platform_secure_psp_permissive_rbac_sa.yaml
kubectl get deployments.apps
结果显示：
	正常的资源可以正常的创建

清理环境
kubectl delete -f 29_kubernetes_platform_secure_psp_deployment_sa.yaml
kubectl delete -f 30_kubernetes_platform_secure_psp_permissive_rbac_sa.yaml

收尾动作

为了不影响后续知识点的学习，我们这里将所有kube-apiserver的服务的PSP功能移除，查看最终效果
[root@kubernetes-master1 ~]# kubectl get pod -n kube-system | grep api
kube-apiserver-kubernetes-master1  1/1     Running   0               6s
kube-apiserver-kubernetes-master2  1/1     Running   0               8s
kube-apiserver-kubernetes-master3  1/1     Pending   0               1s

小结