kubernetes RBAC Authentication 详解

开头语

写在前面：如有问题，以你为准，

目前24年应届生，各位大佬轻喷，部分资料与图片来自网络

内容较长，页面右上角目录方便跳转

Kubernetes 安全架构

K8S安全控制框架主要由下面3个阶段进行控制，每一个阶段都支持插件方式，通过API Server配置来启用插件。

① Authentication（认证）：身份鉴别，只有正确的账号才能通过认证。

② Authorization（授权）：判断用户是否有权限对访问的资源执行特定的动作。

③ Admission Control（准入控制）：用于补充授权机制以实现更加精细的访问控制功能

用户携带令牌或者证书给 Kubernetes 的 api-server 发送请求，要求修改集群资源。
Kubernetes 开始认证。
Kubernetes 认证通过之后，会查询用户的授权（有哪些权限）。
用户执行操作的过程中（操作 CPU、内存、硬盘、网络……），利用准入控制来判断是否可以执行这样的操作。

两种类型

Kubenetes组件对API Server的i访i问：kubectl、.Controller Manager、Scheduler、kubelet,kube-proxy

使用kubeconfig

Kubernetes管理的Pod对容器的访问：Pod(dashborad也是以Pod形式运行)

使用ServiceAccount

安全性说明

Controller Manager、Scheduler与API Server在同一台机器，所以直接使用API Server的非安全端口

访问，--insecure-.bind-address-127.0.0.1

kubectl、kubelet、kube-proxy访间API Server就都需要证书进行HTTPS双向认证

证书颁发

手动签发：通过k8s集群的限cā进行签发HTTPS证书

自动签发：kubelet首次访问API Server时，使用token做认证，通过后，Controller Manager会为kubelet生成一个证书，以后的访问都是用证书做认证了

kubeconfig

kubeconfig文件包含集群参数(CAi证书、API Serveri地址)，客户端参数（上面生成的证书和私钥），集群context信息（集群名称、用户名）。

Kubenetes组件通过启动时指定不同的kubeconfig文件可以切换到不同的集群

[root@master cks]# ls /root/.kube/

cache  config

ServiceAccount

Pod中的容器访问API Server。因为Pod的创建、销毁是动态的，所以要为它手动生成i证书就不可行了。Kubenetes使用了Service Account解决Pod访问API Server的认证问题

default SA

当创建naamespacel时，会自动创建一个名为default的SA,这个SA没有绑定任何权限
当default SA创建时，会自动创建一个default-token-xxx的secret,并自动关联到SA
当创建Pod时，如果没有指定SA,会自动为pod以volume方式挂载这个default SA,在容器目录：var/run/secrets/kubernetes.io/serviceaccount
验证默认SA权限：kubectl --as=system:serviceaccount:default:default get pods

Secret 与 SA 的关系

Kubernetes 设计了一种资源对象叫做Secret,分为两类，

一种是用于ServiceAccount的service-account-token

一种是用于保存用户自定义保密信息的Opaque,.ServiceAccount中用到包含三个部分：Token、ca.crt、namespace

token 是使用API Server私钥签名的JWT。用于访问API Server时，Server端认证

ca.crt 根证书。用于Client端验证API Server发送的证书

namespace 标识这个service-account-token的作用l域名空间

默认情况下，每个namespace都会有一个default SA,如果Pod在创建时没有指定ServiceAccount,

就会使用Pod所属的namespace的ServiceAccount

容器下都有着这三个东西

Authentication 认证（鉴权）

上面认证过程，只是确认通信的双方都确认了对方是可信的，可以相互通信。而鉴权是确定请求方有那些资源的权限。

API Server目前支持以下几种授权第路（通过API Server的启动参数”--authorization-mode"设置）

认证有如下几种方式：

1、HTTP Token认证：通过一个Token来识别合法用户。

HTTP Token的认证是用一个很长的特殊编码方式的并且难以被模仿的字符串来表达客户的一种方式。每一个Token对应一个用户名，存储在API Server能访问的文件中。当客户端发起API调用请求时，需要在HTTP Header里放入Token。

2、HTTP Base认证：通过用户名+密码的方式认证

用户名:密码用base64算法进行编码后的字符串放在HTTP Request中的Heather Authorization 域里发送给服务端，服务端收到后进行解码，获取用户名和密码。

3、最严格的HTTPS证书认证：基于CA根证书签名的客户端身份认证方式，但是同时也是操作起来最麻烦的一种方式（企业使用）

认证只是确认通信的双方都是可信的，可以相互通信。而授权是确定请求方有哪些资源的权限

API Server目前支持的几种授权策略

API Server目前支持如下几种授权策略（通过API Server的启动参数 --authorization-mode 设置）

AlwaysDeny：表示拒绝所有请求。仅用于测试
AlwaysAllow：表示允许所有请求。如果有集群不需要授权流程，则可以采用该策略
Node：节点授权是一种特殊用途的授权模式，专门授权由 kubelet 发出的 API 请求
Webhook：是一种 HTTP 回调模式，允许使用远程 REST 端点管理授权
ABAC：基于属性的访问控制，表示使用用户配置的授权规则对用户请求进行匹配和控制
RBAC：基于角色的访问控制，默认使用该规则

AlwaysDeny：表示拒绝所有请求，一般用于测试。
AlwaysAllow：允许接收所有的请求，相当于集群不需要授权流程（Kubernetes 默认的策略）。
ABAC：基于属性的访问控制，表示使用用户配置的授权规则对用户请求进行匹配和控制。
Webhook：通过调用外部REST服务对用户进行授权。
Node：是一种专用模式，用于对 kubelet 发出的请求进行访问控制。
RBAC：基于角色的访问控制（ kubeadm 安装方式下的默认选项）。

cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep -i rbac

RBAC

k8s 通过Role-based access control (RBAC) 管理权限，基于角色（Role）的访问控制（类似于AWS role）

（RBAC）是一种基于组织中用户的角色来调节控制对计算机或网络资源的访问的方法

在早期的K8s版本，RBAC还未出现的时候，整个K8s的安全是较为薄弱的，有了RBAC后，我们可以对K8s集群的访问人员作非常明细化的控制，控制他们能访问什么资源，以只读还是可以读写的形式来访问，目前RBAC是K8s默认的安全授权标准

RBAC 权限机制使用 rbac.authorization.k8s.io API 组来驱动鉴权决定，允许你通过 Kubernetes API 动态配置策略，可以接入第三方

优势

1、对集群中的资源和非资源均拥有完整的覆盖

2、整个RBAC完全由几个API对象完成，同其他API对象一样，可以用kubectl或API进行操作

3、可以在运行时进行操作，无需重启API Server

资源架构

角色

• Role：授权特定命名空间的访问权限

• ClusterRole：授权所有命名空间的访问权限

角色绑定（这个才是决定作用域即命名空间）

• RoleBinding：将角色绑定到主体（即subject）

• ClusterRoleBinding：将集群角色绑定到主体

主体（subject）

• User：用户

• Group：用户组

• ServiceAccount：服务账号

Role、ClusterRole、RoleBinding 和 ClusterRoleBinding

                  |--- Role --- RoleBinding               

ServiceAccount ---|            # 只在指定namespace中生效

                  |--- ClusterRole --- ClusterRoleBinding 

                  |           # 不受namespace限制，在整个K8s集群中生效

# 真正限制的是作用域（命名空间）的是bingding连接

ClusterRole:和Role的区别，Role是只作用于命名空间内，作用于整个集群

RoleBinding：作用于命令空间内

将ClusterRole或者Role绑定到User、Group、ServiceAccount。

ClusterRoleBinding：作用于整个集群。

ServiceAccount RoleBinding Role 资源都可以指定命名空间，但是作用域是看RoleBinding的metadata中的命名空间

ClusterRoleBinding / ClusterRole 是不指定命名空间的

此时有一个场景，有很多的用户，每个都访问不同的命名空间，但是他们要求的权限是一样的

使用ClusterRole（权限集合，模板）可以绑定在不同命名空间上，通过RoleBinding来指定每个用户的作用域

这种操作允许集群管理员在整个集群内定义一些通用的ClusterRole,然后在不同的namespace中使用RoleBinding来引用*

也可以将主体设置为Group 来实现，但是只能是同一个命名空间

k8s内置的集群角色

cluster-admin 超级管理员，对集群所有权限（在部署dashboard的时候，先创建sa，然后将sa绑定到角色cluster-admin，最后获取到token，这就使用了内置的cluster-admin ）

admin 主要用于授权命名空间所有读写权限

edit 允许对命名空间大多数对象读写操作，不允许查看或者修改角色、角色绑定。

view 允许对命名空间大多数对象只读权限，不允许查看角色、角色绑定和Secret

[root@master default]# kubectl get clusterrole

NAME                                                                   CREATED AT

admin                                                                  2021-05-20T07:04:01Z

edit                                                                   2021-05-20T07:04:01Z

cluster-admin                                                          2021-05-20T07:04:01Z

view                                                                   2021-05-20T07:04:01Z

带system: 开头的，不要去动，因为这是集群运行所需的clusterrole

role 和 clusterrole 和binding之间的关系

如果是正常来说

role 和 clusterrole 通过创建对应的 rolebinding 和 clusterrolebinding

在 role 和 clusterrole 创建中，role指定命令空间（导致role也被限制了命名空间），clusterrole不需要命名空间

rolebinding 和 clusterrolebinding 真正决定了role和clusterrole 的作用域

clusterrole 结合 rolebinding ，哪就只能在该命名空间内使用

role 和 clusterrole 与 rolebinding 和 clusterrolebinding可以混搭

效果是

如果有多个命名空间，但是使用同一个权限，如果使用role要创建多个相同的role，指定不同的命名空间，这就要使用 clusterrole 来实现，因为不用指定命名空间，作用域是整个集群，可以给不同的命名空间，通过rolebinding进行作用域的限制

管理员权限

管理员权限配置所在位置如下图

[root@master k8s]# ll ~/.kube/config

-rw-------. 1 root root 5638 Feb  2 07:13 /root/.kube/config

[root@master k8s]# cat !$

cat ~/.kube/config

apiVersion: v1

clusters:

- cluster:

    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvakNDQWVhZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcm...

这个配置文件一定要保存好，如果弄丢了，重新生产会非常麻烦

实操

命令行

# 查看kube-system namespace下的所有role

kubectl get role -n kube-system

# 查看某个role定义的资源权限

kubectl get role <role-name> -n kube-system -o yaml



# 查看kube-system namespace下所有的rolebinding

kubectl get rolebinding -n kube-system

# 查看kube-system namespace下的某个rolebinding详细信息（绑定的Role和subject）

kubectl get rolebinding <rolebind-name> -n kube-system -o yaml



# 查看集群所有的clusterrole

kubectl get clusterrole

# 查看某个clusterrole定义的资源权限详细信息

kubectl get clusterrole <clusterrole-name> -o yaml



# 查看所有的clusterrolebinding

kubectl get clusterrolebinding

# 在某一特定名字空间内授予Role或者ClusterRole。示例如下：

    a) 在名为”acme”的名字空间中将admin ClusterRole授予用户”bob”：

kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme

    b) 在名为”acme”的名字空间中将view ClusterRole授予服务账户”myapp”：

kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme

kubectl create clusterrolebinding





# 在整个集群中授予ClusterRole，包括所有名字空间。示例如下：

    a) 在整个集群范围内将cluster-admin ClusterRole授予用户”root”：

kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root



    b) 在整个集群范围内将system:node ClusterRole授予用户”kubelet”：

kubectl create clusterrolebinding kubelet-node-binding --clusterrole=system:node --user=kubelet



    c) 在整个集群范围内将view ClusterRole授予名字空间”acme”内的服务账户”myapp”：

kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp



# 创建 sa

kubectl create serviceaccount --namespace kube-system tiller

示例

# 创建 clusterrole

# 查看帮助

kubectl create clusterrole -h

# 创建

kubectl create clusterrole deployment-clusterrole --verb=create --resource=deployments,statefulsets,daemonsets

# 检查

candidate@node01:~$ kubectl describe clusterrole deployment-clusterrole

Name:         deployment-clusterrole

Labels:       <none>

Annotations:  <none>

PolicyRule:

  Resources          Non-Resource URLs  Resource Names  Verbs

  ---------          -----------------  --------------  -----

  daemonsets.apps    []                 []              [create]

  deployments.apps   []                 []              [create]

  statefulsets.apps  []                 []              [create]

# 创建sa

  # 查看帮助

candidate@node01:~$ kubectl create sa -h

# 创建

kubectl create sa -n app-team1  cicd-token

# 检查

candidate@node01:~$ kubectl get sa  -n app-team1

NAME         SECRETS   AGE

cicd-token   0         5m2s

default      0         116d

# 创建 rolebinding

# 查看帮助

candidate@node01:~$ kubectl create rolebinding -h

# 创建

candidate@node01:~$ kubectl create rolebinding -n app-team1  test --clusterrole=deployment-clusterrole --serviceaccount=app-team1:cicd-token

rolebinding.rbac.authorization.k8s.io/test created

# 检查

candidate@node01:~$ kubectl describe -n app-team1 rolebindings.rbac.authorization.k8s.io

Name:         test

Labels:       <none>

Annotations:  <none>

Role:

  Kind:  ClusterRole

  Name:  deployment-clusterrole

Subjects:

  Kind            Name        Namespace

  ----            ----        ---------

  ServiceAccount  cicd-token  app-team1

# 检查不了rolebindings 所在区域

测试

kubectl --as=system:serviceaccount:app-team1:cicd-token get  deployments -n app-team1

yaml 解析

资源和动作查询

# 查询资源

kubectl api-resources

# 查询资源和动作

kubectl api-resources -o wide

Role / ClusterRole

Role

定义到名称为 “study” 的命名空间，可以用来授予对该命名空间中的 Pods 的读取权限

apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

  name: pod-reader

  namespace: study #指定所属命名空间

rules:

- apiGroups: [""] # "" 指定核心 API 组

    # "*" represents all API groups 空字符串""表明使用core API group

    # （如pods属于core api group，deployments属于apps api group）

    # 通过 kubectl api-resources | grep deployment 查看api 组

    # 例如 aaps/v1 写为["","apps"]

  resources: ["pods"] # 资源,'*' represents all

 resources

  resourceNames: ["nginx"] # 指定某资源下的具体某个资源，不写即为全部

  verbs: ["get", "watch", "list"] # 对资源的操作动作,'*' represents all verbs

  # 包括操作（get、create、list、delete、update、edit、watch、exec）资源

# 指定多组权限

# - apiGroups: [""]

#   resources: [""]

#   verbs: [""]

Core Groups (核心组)，也可以称为Legacy Groups，该组的REST路径位于/api/v1, 作为 Kubernetes 最核心的 API，

它是没有“组”的概念，例如 ”v1“，在资源对象的定义中表示为”apiVersion: v1“

具有分组信息的API，以/apis/$GROUP_NAME/$VERSIONURL路径进行标识，在资源对象的定义中表示为

apiVersion: $GROUP_NAME/$VERSION（例如，apiVersion: batch/v1）。已支持的 API 组详细列表请参阅

Kubernetes API reference。

ClusterRole

大体上跟role差不多，主要是没有命名空间，其作用域是整个集群

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRole

metadata:

  # "namespace" 被忽略，因为 ClusterRoles 不受名字空间限制

  name: secret-reader

  labels

    snj:"test" #用于其他role聚合

rules:

- apiGroups: [""] # "" 标明 core API 组，默认留空即可

  # 在 HTTP 层面，用来访问 Secret 资源的名称为 "secrets"

  resources: ["secrets"]

  verbs: ["get", "watch", "list"]

聚合ClusterRole

就是将rbac.example.com/aggregate-to-monitoring标签的ClusterRole所有权限添加到该ClusterRole中

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRole

metadata:

  name: monitoring

aggregationRule:

  clusterRoleSelectors:

  - matchLabels:

      snj:"test" # 此时 monitoring就有了上面secret-reader的所有的权限

rules: [] # 控制面自动填充这里的规则

RoleBinding / ClusterRoleBinding

角色绑定用来把一个角色绑定到一个目标对象上，绑定目标可以是 User、Group 或者 ServiceAccount

RoleBinding

apiVersion: rbac.authorization.k8s.io/v1

# 此角色绑定允许 "jane" 读取 "default" 名字空间中的 Pod

# 你需要在该命名空间中有一个名为 “pod-reader” 的 Role

kind: RoleBinding

metadata:

  name: read-pods

  namespace: default #一般和role是一个命名空间，这里的这个参数也实现了role的作用域

roleRef:

  # "roleRef" 指定与某 Role 或 ClusterRole 的绑定关系

  kind: Role        # 此字段必须是 Role 或 ClusterRole

  name: pod-reader  # 此字段必须与你要绑定的 Role 或 ClusterRole 的名称匹配 

subjects:

# 你可以指定不止一个“subject（主体）”

- kind: ServiceAccount

  name: test # "name" 是区分大小写的

ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1

# 此集群角色绑定允许 “manager” 组中的任何人访问任何名字空间中的 Secret 资源

kind: ClusterRoleBinding

metadata:

  name: read-secrets-global

  # 作用域是整个Cluster，不是单个namespace所以不写namespace

  # 如果资源是某个 namespace 下的，也就resourceNames指定了，那么就需要设置 namespace

        # 因为不同命名空间中可能会有重名

roleRef:

  kind: ClusterRole

  name: secret-reader

subjects:

- kind: Group

  name: manager      # 'name' 是区分大小写的

ServiceAccout

apiVersion: v1

kind: ServiceAccount

metadata:

  name: admin-user

  namespace: kube-system

命名空间问题

role和rolebinding一般是一个命名空间

sa 和 rolebinding / role 不在同一个命名空间

yaml 实操

# 名称空间角色

apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

  name: snj-role

  namespace: study # 所属的名称空间

rules: # 当前角色的规则

- apiGroups: [""] # "" 标明 core API 组，默认留空即可。

  resources: ["pods"] # 指定能操作的资源 ，通过 kubectl api-resources 查看即可。

  # resourceNames: [""] #  指定只能操作某个名字的资源

  verbs: ["get", "watch", "list"] # 操作动作，通过 kubectl api-resources -o wide 查看即可。

---

# 集群角色

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRole

metadata:

  name: snj-clusterrole

rules:

- apiGroups: [""] # "" 标明 core API 组，默认留空即可。

  resources: ["namespaces"]

  verbs: ["get", "watch", "list"]

---

# ServiceAccount

apiVersion: v1

kind: ServiceAccount

metadata:

  name: snj # ServiceAccount 的名称

  namespace: default

---

# 账号和角色绑定

apiVersion: rbac.authorization.k8s.io/v1

kind: RoleBinding

metadata:

  name: snj-rolebinding

  namespace: study

subjects:

- kind: ServiceAccount

  name: snj # "name" 是区分大小写的

roleRef:

  kind: Role

  name: snj-role

  apiGroup: rbac.authorization.k8s.io

---

# 账号和集群角色绑定

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRoleBinding

metadata:

  name: snj-clusterrolebinding

subjects:

- kind: ServiceAccount

  name: snj # "name" 是区分大小写的

  namespace: default # 如果资源是某个 namespace 下的，那么就需要设置 namespace

roleRef:

  kind: ClusterRole

  name: snj-clusterrole

  apiGroup: rbac.authorization.k8s.io
---

# pod 使用 sa

apiVersion: v1

kind: Pod

metadata:

  name: web-seccomp

  namespace: study

spec:

  serviceAcccountName: snj

  containers:

  - image: busybox:1.30

    name: hello

    command:

    - sleep

    - 24h

[root@master k8s]# kubectl apply -f role-test.yaml

role.rbac.authorization.k8s.io/snj-role created

clusterrole.rbac.authorization.k8s.io/snj-clusterrole created

serviceaccount/snj created

rolebinding.rbac.authorization.k8s.io/snj-rolebinding created

clusterrolebinding.rbac.authorization.k8s.io/xudaxian-clusterrolebinding created

[root@master k8s]# kubectl get role -n study

NAME       CREATED AT

snj-role   2023-02-21T08:24:41Z

[root@master k8s]# kubectl get rolebindings.rbac.authorization.k8s.io -n study

NAME              ROLE            AGE

snj-rolebinding   Role/snj-role   14s

[root@master k8s]# kubectl get sa

NAME      SECRETS   AGE

default   0         18d

snj       0         70s

[root@master k8s]#  kubectl get clusterrole | grep snj

snj-clusterrole                                                        2023-02-21T08:24:41Z

[root@master k8s]# kubectl get clusterrolebindings.rbac.authorization.k8s.io  | grep snj

snj-clusterrolebinding                                 ClusterRole/snj-clusterrole                                                        72s

用途

（1）第一类是保证在K8s上运行的pod服务具有相应的集群权限，如gitlab的CI/CD，它需要能访问除自身以外其他pod，比如gitlab-runner的pod的权限，再比如gitlab-runner的pod需要拥有创建新的临时pod的权限，用以来构建CI/CD自动化流水线

（2）第二类是创建能访问K8s相应资源、拥有对应权限的kube-config配置给到使用K8s的人员，来作为连接K8s的授权凭证

第一类示例：

helm是一个快捷安装K8s各类资源的管理工具（类似于linux yaml），通过之前给大家讲解的，一个较为完整的服务可能会存在deployment，service，configmap，secret，ingress等资源来组合使用，大家在用的过程中可能会觉得配置使用较为麻烦，这时候helm就出现了，它把这些资源都打包封装成它自己能识别的内容，我们在安装一个服务的时候，就只需要作下简单的配置，一条命令即可完成上述众多资源的配置安装，titller相当于helm的服务端，它是需要有权限在K8s中创建各类资源的，在初始安装使用时，如果没有配置RBAC权限，我们会看到如下报错：

root@node1:~# helm install stable/mysql

Error: no available release name found

更改使用权限

这时，我们可以来快速解决这个问题，创建sa关联K8s自带的最高权限的ClusterRole（生产中建议不要这样做，权限太高有安全隐患，这个就和linux的root管理帐号一样，一般都是建议通过sudo来控制帐号权限）

kubectl create serviceaccount --namespace kube-system tiller

kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller

kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'

提供查看日志权限

apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

  namespace: default

  name: pod-and-pod-logs-reader

rules:

- apiGroups: [""]

  resources: ["pods", "pods/log"] # log 是 pods 的子资源 用斜线（/）来分隔资源和子资源

  verbs: ["get", "list"]

配置一个能访问集群的特定用户( master主机内 )

创建证书（master）

配置 cfssl

# 注意：只需要在一台机器下载即可

wget https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl-certinfo_1.5.0_linux_amd64

wget https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl_1.5.0_linux_amd64

wget https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_linux_amd64

chmod +x cfssl*

for name in `ls cfssl*`; do mv $name ${name%_1.5.0_linux_amd64};  done

mv cfssl* /usr/bin

创建申请证书的json

O=组织信息，CN=用户名

 sudo tee /root/k8s/cert/devuser.json <<-'EOF'

{

  "CN": "devuser",

  "hosts": [],

  "key": {

    "algo": "rsa",

    "size": 2048

  },

  "names": [

    {

      "C": "CN",

      "ST": "Shenzhen",

      "L": "Shenzhen",

      "O": "k8s",

      "OU": "system"

    }

  ]

}

EOF

创建证书和公私钥

CN: 用户名

O: 用户组

cfssl gencert -ca=/etc/kubernetes/pki/ca.crt -ca-key=/etc/kubernetes/pki/ca.key -profile=kubernetes /root/k8s/cert/devuser.json | cfssljson -bare devuser


[root@master pki]# ls | grep user

devuser.csr

devuser-key.pem

devuser.pem

所属命名空间和权限

示例1

[root@node-01 rbac]# vim  role-pods-reader.yaml

apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

  name: devuser-role

  namespace: dev

rules:

- apiGroups:

  - ""

  resources:

  - pods

  verbs:

  - get

  - list

  - watch

[root@master cert]# kubectl apply -f pods-reader.yaml

role.rbac.authorization.k8s.io/pods-reader created

[root@master cert]# kubectl describe role -n dev pods-reader

Name:         pods-reader

Labels:       <none>

Annotations:  <none>

PolicyRule:

  Resources  Non-Resource URLs  Resource Names  Verbs

  ---------  -----------------  --------------  -----

  pods       []                 []              [get list watch]

[root@master cert]# cat devuser-pods-reader.yaml

apiVersion: rbac.authorization.k8s.io/v1

kind: RoleBinding

metadata:

  name: devuser-role-binding

  namespace: dev # 定义作用域

roleRef:

  apiGroup: rbac.authorization.k8s.io

  kind: Role

  name: devuser-role

subjects:

- apiGroup: rbac.authorization.k8s.io

  kind: User

  name: devuser

  namespace: dev # 可写可不写

[root@master cert]# kubectl apply -f devuser-pods-reader.yaml

rolebinding.rbac.authorization.k8s.io/devuser-pods-reader created

[root@master cert]# kubectl describe rolebindings.rbac.authorization.k8s.io -n dev

Name:         devuser-role-binding

Labels:       <none>

Annotations:  <none>

Role:

  Kind:  Role

  Name:  devuser-role

Subjects:

  Kind  Name     Namespace

  ----  ----     ---------

  User  devuser

示例2

给devuser最大权限，作用空间在dev下kubectl create ns dev

kubectl create ns dev

kubectl create rolebinding devuser-admin-binding --clusterrole=admin --user=devuser --namespace=dev

创建配置文件

创建配置文件主要有以下几个步骤：


kubectl config set-cluster --kubeconfig=/PATH/TO/SOMEFILE      #集群配置

kubectl config set-credentials NAME --kubeconfig=/PATH/TO/SOMEFILE #用户配置

kubectl config set-context    #context配置

kubectl config use-context    #切换context

–embed-certs =true的作用是不在配置文件中显示证书信息。

–kubeconfig =/root/jenkins.conf 用于创建新的配置文件，如果不加此选项,则内容会添加到家目录下.kube/config文件中，可以使用use-context来切换不同的用户管理k8s集群。可以不加

context简单的理解就是用什么用户来管理哪个集群，即用户和集群的结合。

创建集群配置

--certificate-authority # 指定ca证书，pki下自带

--embed-certs # 是否进行加密

--server # 服务器信息

--kubeconfig 根据信息创建 kubeconfig 配置文件，给访问机子使用

export KUBE_APISERVER="https://192.168.100.53:6443"

kubectl config set-cluster kubernetes \

--certificate-authority=/etc/kubernetes/pki/ca.crt \

--embed-certs=true \

--server="https://192.168.100.53:6443" \

--kubeconfig=/root/k8s/cert/devuser.kubeconfig

# /etc/kubernetes/pki/ca.crt  集群ca证书，自带

#/root/k8s/cert/devuser.kubeconfig 生成的kubeconfig文件名和路径

[root@master cert]# ls

devuser.json  devuser.kubeconfig

[root@master cert]# cat devuser.kubeconfig

apiVersion: v1

clusters:

- cluster: #设置的是这一部分

    certificate-authority-data: ...

    server: https://192.168.100.53:6443

  name: kubernetes

contexts: null

current-context: ""

kind: Config

preferences: {}

users: null

创建用户配置

kubectl config set-credentials devuser \

 --client-certificate=/root/k8s/cert/devuser.pem \

 --client-key=/root/k8s/cert/devuser-key.pem \

 --embed-certs=true \

 --kubeconfig=/root/k8s/cert/devuser.kubeconfig

 # User "devuser" set.

 # --client 使用上面创建证书时候pem文件

 # /root/k8s/cert/devuser.kubeconfig 要设置的kubeconfig文件

[root@master cert]#  kubectl config view --kubeconfig=/root/k8s/cert/devuser.kubeconfig

apiVersion: v1

clusters:

- cluster:

    certificate-authority-data: DATA+OMITTED

    server: https://192.168.100.53:6443

  name: kubernetes

contexts:

- context:

    cluster: kubernetes

    namespace: dev

    user: devuser

  name: kubernetes

current-context: ""

kind: Config

preferences: {}

users: #设置的是这一部分

- name: devuser

  user:

    client-certificate-data: DATA+OMITTED

    client-key-data: DATA+OMITTED

创建上下文配置

#设置上下文参数

kubectl config set-context devuser@kubernetes \

--cluster=kubernetes \

--user=devuser \

--namespace=dev \

--kubeconfig=/root/k8s/cert/devuser.kubeconfig

# Context "kubernetes" created.

[root@master cert]#  kubectl config view --kubeconfig=/root/k8s/cert/devuser.kubeconfig

apiVersion: v1

clusters:

- cluster:

    certificate-authority-data: DATA+OMITTED

    server: https://192.168.100.53:6443

  name: kubernetes

contexts: #设置的是这一部分

- context:

    cluster: kubernetes

    namespace: dev

    user: devuser

  name: devuser@kubernetes

current-context: ""

kind: Config

preferences: {}

users:

- name: devuser

  user:

    client-certificate-data: DATA+OMITTED

    client-key-data: DATA+OMITTED

切换上下文

[root@master cert]#  kubectl config use-context devuser@kubernetes --kubeconfig=/root/k8s/cert/devuser.kubeconfig

Switched to context "devuser@kubernetes".

创建系统用户及k8s验证文件

useradd devuser     #创建什么用户名都可以

mkdir /home/devuser/.kube

cp devuser.kubeconfig /home/devuser/.kube/config

chown devuser.devuser -R /home/devuser/.kube/

su - devuser

测试

 # 访问测试

[devuser@master ~]$ kubectl get pod

No resources found in dev namespace.

[devuser@master ~]$ kubectl get pod -n default

Error from server (Forbidden): pods is forbidden: User "devuser" cannot list resource "pods" in API group "" in the namespace "default"

# 该用户默认就直接是dev namespace

# 对于其他命名空间没有权限


在role只给了get list watch

[devuser@master ~]$ kubectl get pod

NAME    READY   STATUS    RESTARTS   AGE

nginx   1/1     Running   0          12m

[devuser@master ~]$ kubectl delete pod nginx

Error from server (Forbidden): pods "nginx" is forbidden: User "devuser" cannot delete resource "pods" in API group "" in the namespace "dev"

[devuser@master ~]$ kubectl get rolebindings.rbac.authorization.k8s.io

Error from server (Forbidden): rolebindings.rbac.authorization.k8s.io is forbidden: User "devuser" cannot list resource "rolebindings" in API group "rbac.authorization.k8s.io" in the namespace "dev"

[devuser@master ~]$ kubectl run pod nginx --image=nginx:1.17.1

Error from server (Forbidden): pods is forbidden: User "devuser" cannot create resource "pods" in API group "" in the namespace "dev"

准入控制

通过了前面的认证和授权之后，还需要经过准入控制通过之后，API Server 才会处理这个请求。
准入控制是一个可配置的控制器列表，可以通过在 API Server 上通过命令行设置选择执行哪些注入控制器。
通过添加不同的插件，实现额外的准入控制规则

--enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,ResourceQuota,DefaultTolerationSeconds

只有当所有的注入控制器都检查通过之后，API Server 才会执行该请求，否则返回拒绝

kube-apiserver 容器内部可以使用kube-apiserver进行查看启动关闭

# 查看启动插件

kubectl exec kube-apiserver-k8s-master-n kube-system --kube-apiserver -h | grep enable-admission-plugins

      --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, ClusterTrustBundleAttest, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionPolicy, ValidatingAdmissionWebhook, ResourceQuota)

上面这些是默认启用的，用括号括起来

      . Comma-delimited list of admission plugins: AlwaysAdmit, AlwaysDeny, AlwaysPullImages, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, ClusterTrustBundleAttest, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, DenyServiceExternalIPs, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PersistentVolumeLabel, PodNodeSelector, PodSecurity, PodTolerationRestriction, Priority, ResourceQuota, RuntimeClass, SecurityContextDeny, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionPolicy, ValidatingAdmissionWebhook. The order of plugins in this flag does not matter.

启用一个准入控制器：

kube-apiserver --enable-admission-plugins=NamespaceLifecycle,LimitRanger...

关闭一个准入控制器：

kube-apiserver --disable-admission-plugins=PodNodeSelector,AlwaysDeny ..

当前可配置的 Admission Control

列举几个插件的功能：

NamespaceLifecycle: 防止在不存在的namespace上创建对像，防止删除系统预置namespace,别除namespace时，连带删除它的所有资源对象。

LimitRanger: 确保情求的资源不会超过资源所在Namespace的LimitRange的限制：

ServiceAccount: 实现了自动化添加ServiceAccount。

ResourceQuota: 确保请求的资源不会超过资源的ResourceQuota限制。


 AlwaysAdmit：允许所有请求。

 AlwaysDeny：禁止所有请求，一般用于测试。

 AlwaysPullImages：在启动容器之前总去下载镜像。

 DenyExecOnPrivileged：它会拦截所有想在 Privileged Container 上执行命令的请求。

 ImagePolicyWebhook：这个插件将允许后端的一个 Webhook 程序来完成 admission control 的功能。

 Service Account：实现 ServiceAccount 实现了自动化。

 SecurityContextDeny：这个插件将使用 SecurityContext 的 Pod 中的定义全部失效。

 ResourceQuota：用于资源配额管理目的，观察所有请求，确保在 namespace 上的配额不会超标。

 LimitRanger：用于资源限制管理，作用于 namespace 上，确保对 Pod 进行资源限制。

 InitialResources：为未设置资源请求与限制的 Pod，根据其镜像的历史资源的使用情况进行设置。

 NamespaceLifecycle：如果尝试在一个不存在的 namespace 中创建资源对象，则该创建请求将被拒绝。当删除一个 namespace 时，系统将会删除该 namespace 中所有对象。

 DefaultStorageClass：为了实现共享存储的动态供应，为未指定 StorageClass 或 PV 的 PVC 尝试匹配默认 StorageClass，尽可能减少用户在申请 PVC 时所需了解的后端存储细节。

 DefaultTolerationSeconds：这个插件为那些没有设置 forgiveness tolerations 并具有 notready:NoExecute 和 unreachable:NoExecute 两种taints的Pod设置默认的容忍时间，为 5min 。

 PodSecurityPolicy：这个插件用于在创建或修改 Pod 时决定是否根据 Pod 的 security context 和可用的 PodSecurityPolicy 对 Pod 的安全策略进行控制