10 k8s 考试基础知识（八）

API 对象解释

Kubernetes 对象是持久化的实体，是存入 etcd 中的数据，集群中通过这些实体来表示整个集群的状态。

Kubernetes API 是一个以 JSON 为主要序列化方式的 HTTP 服务，除此之外也支持 Protocol Buffers 序列化方式。

主要用于集群内部组件间的通信。为了可扩展性，Kubernetes 在不同的 API 路径（比如/api/v1 或者 /apis/batch）下面不同的 API 版本意味着不同级别的稳定性和支持：

• Alpha 级别，例如 v1alpha1 默认情况下是被禁用的，可以随时删除对功能的支持，所以要慎用
• Beta 级别，例如 v2beta1 默认情况下是启用的，表示代码已经经过了很好的测试，但是对象的语义可能会在随后的版本中以不兼容的方式更改
• 稳定级别，比如 v1 表示已经是稳定版本了，也会出现在后续的很多版本中。

Kubernetes 集群中，API 对象在 Etcd 里的完整资源路径，由： Group（API 组）; Version（API 版本）; Resource（API 资源类型）

kubectl get --raw /

RBAC详解

Role-Based Access Control

K8S中，有3种验证方式：

kubectl config set-credentials -h 
1 Client-certificate flags
2 Bearer token flags
3 Basic auth flags

• X509客户端证书
  客户端证书验证通过为API Server指定--client-ca-file=xxx选项启用，API Server通过此ca文件来验证API请求携带的客户端证书的有效性，一旦验证成功，API Server就会将客户端证书Subject里的CN属性作为此次请求的用户名
• 静态token文件
  通过指定--token-auth-file=SOMEFILE选项来启用bearer token验证方式，引用的文件是一个包含了 token,用户名,用户ID 的csv文件 请求时，带上Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269头信息即可通过bearer token验证
• 静态密码文件
  通过指定--basic-auth-file=SOMEFILE选项启用密码验证，类似的，引用的文件时一个包含 密码,用户名,用户ID 的csv文件 请求时需要将Authorization头设置为Basic BASE64ENCODED(USER:PASSWORD)

X509客户端证书 这个比较重要,下面按照Client-certificate 这个方式创建用户

在 RBAC API 中，一个角色包含一组相关权限的规则。权限是纯粹累加的（不存在拒绝某操作的规则），即只能给权限累加，不存在给了XX权限，然后去掉XX01权限的情况。

RBAC 账户管理有两种：

• userAccount: 给人设计使用，并且userAccount不在k8s集群内管理
• serviceAccount: 为集群内pod，外部service访问而设计的，更轻量级，更专注与实现某个任务

01 userAccount

为kubectl配置用户

在命令中带上 kubectl --context=tom@aliyun ... 参数即可指定kubectl使用之前添加的名为tom@aliyun的context操作集群
也可以通过命令 kubectl config use-context tom@aliyun 来设置当前激活的context

不在k8s集群内管理内的资源

为用户生成证书的步骤 为用户提供了基于X509证书的验证,也就是生成一个userAccount

{
    mkdir ~/userAccount_dir/ ; cd $_ ; }
# 1 为jemmy用户创建一个私钥
# 设置掩码077,这样只有当前用户有rw权限
(umask 077; openssl genrsa -out jemmy.key 2048)
# 2 用此私钥创建一个csr(证书签名请求)文件，需要在subject里带上用户信息(CN为用户名，O为用户组) 
# /O参数可以出现多次，即可以有多个用户组
openssl req -new -key jemmy.key -out jemmy.csr -subj "/CN=jemmy/O=Shanghai/O=worker"
# 3 找到K8S集群(API Server)的CA证书文件，其位置取决于安装集群的方式，通常会在`/etc/kubernetes/pki/`路径下，会有两个文件，一个是CA证书(ca.crt)，一个是CA私钥(ca.key)
# 4 通过集群的CA证书和之前创建的csr文件，来为用户颁发证书
# -CA和-CAkey参数需要指定集群CA证书所在位置path/to/ca.crt; path/to/ca.key，
# -days参数指定此证书的过期时间，这里为365天
openssl x509 -req -in jemmy.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out jemmy.crt -days 365
# openssl x509 -req -in mrvolleyball.csr -CA ca.pem  -CAkey ca-key.pem -CAcreateserial -out mrvolleyball.crt # 注：ca.pem与ca-key.pem分别是证书与私钥
# 5 最后将证书(jemmy.crt)和私钥(jemmy.key)保存起来，这两个文件将被用来验证API请求
# 看一下这个详细信息
openssl x509 -in jemmy.crt -text -noout
# openssl x509 -in mrvolleyball.crt -text
# Subject: CN=jemmy, O=Shanghai, O=worker

以上步骤就有了用户jemmy

接下来将账户注册到kubectl config当中进行管理：

# 注册这个用户
k config -h  # set-credentials   Set a user entry in kubeconfig
kubectl config set-credentials -h  #  --client-certificate=certfile --client-key=keyfile
# set User "jemmy" 
kubectl config set-credentials jemmy --client-certificate=jemmy.crt --client-key=jemmy.key
# kubectl config set-credentials jemmy --client-certificate=jemmy.crt --client-key=jemmy.key --embed-certs=true  # Embed client cert/key for the user entry in kubeconfig # 加上了就不显示真实目录显示 这个 DATA+OMITTED
# created Context "jemmyLoc" 
kubectl config set-context jemmyLoc --cluster=kubernetes --user=jemmy
#  --namespace=a-1 这个ns可加可不叫，不加就没有默认的命名空间
# 创建好之后使用新账户来登录：
kubectl config use-context jemmyLoc
# 一开始由于没有权限，我们只能允许被进入k8s集群，但是没有访问任何资源的权限
kubectl get pod
kubectl config use-context kubernetes-admin@kubernetes 

接下来为用户添加基于角色的访问控制(RBAC)

目前RBAC已作为稳定的功能，管理员可以通过 Kubernetes API 动态配置策略来启用RBAC，需要在 kube-apiserver 中添加参数--authorization-mode=RBAC

# 查看哪些插件是默认启用的：
cat  /etc/kubernetes/manifests/kube-apiserver.yaml  | grep enable-admission-plugins
#   - --authorization-mode=Node,RBAC

02 clusterrole 和 rolebinding

RoleBinding 在 哪个名命名空间，用户就有哪个命名空间的权限

角色

• 普通角色(Role) 作用域 某个命名空间
• 集群角色(ClusterRole) 作用域 整个集群 可以多次复用
  • 比如node资源的管理；
  • 非资源类型的接口请求(如"/healthz")；
  • 请求全命名空间的资源(通过指定 --all-namespaces)

apiGroups
要使用的API Group name。若此欄空白，則預設為core API

cat <<- eof | kubectl apply -f - 
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  # ClusterRole 是集群范围对象，没有 "namespace" 区分
  name: jemmy-clusterrole
rules:
  # 对哪个api组进行授权，""核心资源组，apps组是deployment控制器所在的api组
- apiGroups: ["", "apps"]
  # 授权资源的类型
  resources: ["pods","deployments"]
  verbs: ["get", "watch", "list", "create", "delete"]
eof

kubectl get clusterrole | grep jemmy-clusterrole
k get clusterrole.rbac.authorization.k8s.io/jemmy-clusterrole
k describe $_

RoleBinding的目的即是連接User或者service account 和Role

如yaml中所示，RoleBinding资源创建了一个 Role-User 之间的关系，roleRef节点指定此RoleBinding所引用的角色，subjects节点指定了此RoleBinding的受体，可以是User，也可以是前面说过的ServiceAccount，在这里只包含了名为 tom 的用户

RoleBinding资源将用户和角色绑定

通过RoleBinding角色绑定将用户与集群角色进行绑定

cat <<- eof | kubectl apply -f - 
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: jemmy-clusterrole-csdn-binding
  namespace: csdn-test
#关联用户信息
subjects:
  #类型为用户
- kind: User	
  #用户名称
  name: jemmy
  #角色所能控制的命名空间
  namespace: csdn-test			
  apiGroup: rbac.authorization.k8s.io
#关联角色信息
roleRef:
  #类型为ClusterRole
  kind: ClusterRole		
  #角色名称
  name: jemmy-clusterrole						  
  apiGroup: rbac.authorization.k8s.io
eof

验证

k auth can-i -h 
kubectl auth can-i <verb> <resoureces>
k auth can-i get po -n default --as=jemmy
k auth can-i get deploy -n default --as=jemmy
k auth can-i get po -n csdn-test --as=jemmy
k auth can-i get deploy -n csdn-test --as=jemmy
kubectl config use-context jemmyLoc

下面以命令行的方式创建

kubectl config