⒈机制说明
⒉Authentication（认证）
1.分类
1.HTTP Token认证:通过一个Token（字符串） 来识别合法用户
kubectl get secret --all-namespaces
kubectl describe secret default-token-5gm9r --namespace=kube-system
{ "CN": "admin", "hosts": [], "key":{ "algo": "rsa", "size": 2048 }, "names":[ { "C": "CN", "ST":"TianJin", "L": "TJ", "O": "system:masters", "OU": "System" } ] }
API Server会把客户端证书的CN 字段作为User，把 names.0 字段作为Group
kubelet 使用TLS Bootstaping 认证时，API Server 可以使用Bootstrap Tokens 或者 Token authenticationfile验证 =token，无论哪一种，Kubenetes 都会为token 绑定一个默认的 User 和 Group
Pod使用ServiceAccount 认证时，service-account-token 中的JWT会保存User信息
有了用户信息，再创建一对角色/角色绑定(集群角色/集群角色绑定)资源对象，就可以完成权限绑定了
3.Role and ClusterRole
在 RBAC API中，Role表示一组规则权限，权限只会增加(累加权限)，不存在一个资源一开始就有很多权限而通过RBAC对其进行减少的操作:Role可以定义在一个namespace 中，如果想要跨namespace则可以创建ClusterRole
kind: Role apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: namespace: default name: pod-reader rules: - apiGroups: [""] # "" indicates the core API group resources: ["pods"] verbs: ["get", "watch", "list"]
ClusterRole具有与Role相同的权限角色控制能力，不同的是 ClusterRole是集群级别的，CusterRole可以用于:
1.集群级别的资源控制(例如 node访问权限)
2.非资源型endpoints( 例如 /healthz 访问)
3.所有命名空间资源控制(例如 pods )
kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: #"namespace" omitted since ClusterRoles are not namespaced name: secret-reader rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get","watch","list"]
4.RoleBinding and ClusterRoleBinding
RoloBinding 可以将角色中定义的权限授予用户或用户组，RoleBinding包含一组权限列表(subjects)，权限列表中包含有不同形式的待授予权限资源类型(users,groups,or service accounts); Ro|oBinding同样包含对被Bind 的 Role 引用；RoleBinding适用于某个命名空间内授权，而 ClusterRoleBinding适用于集群范围内的授权
将default命名空间的 pod-reader Role授予jane用户，此后jane用户在 default 命名空间中将具有pod-reader 的权限
kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: read-pods namespace: default subjects: - kind: User name: jane apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io
RoleBinding同样可以引用ClusterRole来对当前namespace 内用户、用户组或ServiceAccount 进行授权，这种操作允许集群管理员在整个集群内定义一些通用的ClusterRole，然后在不同的namespace中使用RoleBinding来引用
例如，以下 RoleBinding引用了一个ClusterRole，这个 ClusterRole具有整个集群内对secrets的访问权限；但是其授权用户 dave只2能访问development空间中的secrets(因为RoleBinding定义在 development命名空间)
# This role binding allows"dave"to read secrets in the "development"namespace. kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: read-secrets namespace: development # This only grants permissions within the "devel]opment" namespace. subjects: - kind: User name: dave apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: secret-reader apiGroup: rbac.authorization.k8s.io
使用ClusterRoleBinding可以对整个集群中的所有命名空间资源权限进行授权；:以下 ClusterRoleBinding样例 展示了授权manager 组内所有用户在全部命名空间中对 secrets 进行访问
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace. kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: read-secrets-global subjects: - kind: Group name: manager apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: secret-reader apiGroup: rbac.authorization.k8s.io
5.Resources
Kubernetes 集群内一些资源一般以其名称字符串来表示，这些字符串一般会在AP的URL地址中出现；同时某些资源也会包含子资源，例如logs资源就属于 pods的子资源，AP中URL样例如下
GET /api/v1/namespaces/{namespace}/pods/{name}/log
如果要在 RBAC授权模型中控制这些子资源的访问权限，可以通过分隔符来实现，以下是一个定义 pods资资源logs 访问权限的 Role定义样例
kind: Role apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: namespace: default name: pod-and-pod-logs-reader rules: - apiGroups: [""] resources: ["pods/log"] verbs: ["get", "list"]
6.to Subjects
RoleBinding 和 ClusterRoleBinding可以将Role绑定到 Subjects; Subjects 可以是 groups、users 或者service accounts
Subjects 中 Users使用字符串表示，它可以是一个普通的名字字符串，如“alice”；也可以是emai格式的邮箱地址，如“wangyanglinux@163.com”；甚至是一组字符串形式的数字ID。但是 Users的前缀system:是系统保留的，集群管理员应该确保普通用户不会使用这个前缀格式
Groups书写格式与 Users相同，都为一个字符串，并且没有特定的格式要求；同样system:前缀为系统保留
7. 实践:创建一个用户只能管理dev空间
{ "CN": "devuser", "hosts": [], "key":{ "algo":"rsa", "size":2048 }, "": [ { "C":"CN", "ST":"Tianjin", "L":"Tianjin", "O":"k8s", "OU":"System", } ] }
# 下载证书生成工具 wget https://pkg.cfssl.org/R1.2/cfss1_linux-amd64 mv cfssl_linux-amd64 /usr/local/bin/cfssl wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 mv cfssljson_linux-amd64 /usr/local/bin/cfssljson wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 mv cfssl-certinfo_linux-amd64 usr/local/bin/cfssl-certinfo cfssl gencert -ca=ca.crt -ca-key=ca.key -profile=kubernetes /root/devuser-csr.json | cfssljson -bare devuser #设置集群参数 export KUBE_APISERVER="https://172.20.0.113:6443" kubectl config set-cluster kubernetes --certificate-authority=/etc/kubernetes/ssl/ca.crt --embed-certs=true --server=${KUBE_APISERVER} --kubeconfig=devuser.kubeconfig #设置客户端认证参数 kubectl config set-credentials devuser --client-certificate=/etc/kubernetes/ssl/devuser.pem --client-key=/etc/kubernetes/ssl/devuser-key.pem --embed-certs=true --kubeconfig=devuser.kubeconfig
#创建命名空间
kubectl create namespace dev
#设置上下文参数 kubectl config set-context kubernetes --cluster=kubernetes --user=devuser --namespace=dev --kubeconfig=devuser.kubeconfig #设置默认上下文 kubectl config use-context kubernetes --kubeconfig=devuser.kubeconfig cp -f ./devuser.kubeconfig /root/.kube/config kubectl create rolebinding devuser-admin-binding --clusterrole=admin --user=devuser --namespace=dev
8.准入控制
准入控制是AP| Server的插件集合，通过添加不同的插件，实现额外的准入控制规则。甚至于APl|Server的一些主要的功能都需要通过Admission Controllers 实现，比如 ServiceAccount官方文档上有一份针对不同版本的准入控制器推荐列表，其中最新的1.14的推荐列表是:
NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds ,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota
列举几个插件的功能:
1.NamespaceLifecycle:防止在不存在的namespace上创建对象，防止删除系统预置namespace，删除namespace时，连带删除它的所有资源对象。
2.LimitRanger:确保请求的资源不会超过资源所在Namespace 的 LimitRange的限制。
3.ServiceAccount:实现了自动化添加 ServiceAccount.
4.ResourceQuota:确保请求的资源不会超过资源的ResourceQuota限制。