kubernetes RBAC Authentication 详解

开头语

写在前面:如有问题,以你为准,

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

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

Kubernetes 安全架构

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

① Authentication(认证):身份鉴别,只有正确的账号才能通过认证。

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

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

  1. 用户携带令牌或者证书给 Kubernetes 的 api-server 发送请求,要求修改集群资源。
  2. Kubernetes 开始认证。
  3. Kubernetes 认证通过之后,会查询用户的授权(有哪些权限)。
  4. 用户执行操作的过程中(操作 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

  1. 当创建naamespacel时,会自动创建一个名为default的SA,这个SA没有绑定任何权限
  2. 当default SA创建时,会自动创建一个default-token-xxx的secret,并自动关联到SA
  3. 当创建Pod时,如果没有指定SA,会自动为pod以volume方式挂载这个default SA,在容器目录:var/run/secrets/kubernetes.io/serviceaccount
  4. 验证默认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

<!--默认挂载目录:/run/secrets./kubernetes,io/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 设置)

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

  1.  AlwaysDeny:表示拒绝所有请求,一般用于测试。
  2.  AlwaysAllow:允许接收所有的请求,相当于集群不需要授权流程(Kubernetes 默认的策略)。
  3.  ABAC:基于属性的访问控制,表示使用用户配置的授权规则对用户请求进行匹配和控制。
  4.  Webhook:通过调用外部REST服务对用户进行授权。
  5.  Node:是一种专用模式,用于对 kubelet 发出的请求进行访问控制。
  6.  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 clusterroleNAME                                                                   CREATED ATadmin                                                                  2021-05-20T07:04:01Zedit                                                                   2021-05-20T07:04:01Zcluster-admin                                                          2021-05-20T07:04:01Zview                                                                   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/configapiVersion: v1clusters:- cluster:certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvakNDQWVhZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcm...

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

实操

命令行

# 查看kube-system namespace下的所有rolekubectl get role -n kube-system# 查看某个role定义的资源权限kubectl get role <role-name> -n kube-system -o yaml# 查看kube-system namespace下所有的rolebindingkubectl get rolebinding -n kube-system# 查看kube-system namespace下的某个rolebinding详细信息(绑定的Role和subject)kubectl get rolebinding <rolebind-name> -n kube-system -o yaml# 查看集群所有的clusterrolekubectl get clusterrole# 查看某个clusterrole定义的资源权限详细信息kubectl get clusterrole <clusterrole-name> -o yaml# 查看所有的clusterrolebindingkubectl get clusterrolebinding

# 在某一特定名字空间内授予Role或者ClusterRole。示例如下:a) 在名为”acme”的名字空间中将admin ClusterRole授予用户”bob”:kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acmeb) 在名为”acme”的名字空间中将view ClusterRole授予服务账户”myapp”:kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acmekubectl create clusterrolebinding# 在整个集群中授予ClusterRole,包括所有名字空间。示例如下:a) 在整个集群范围内将cluster-admin ClusterRole授予用户”root”:kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=rootb) 在整个集群范围内将system:node ClusterRole授予用户”kubelet”:kubectl create clusterrolebinding kubelet-node-binding --clusterrole=system:node --user=kubeletc) 在整个集群范围内将view ClusterRole授予名字空间”acme”内的服务账户”myapp”:kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp# 创建 sakubectl 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-clusterroleName:         deployment-clusterroleLabels:       <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-team1NAME         SECRETS   AGEcicd-token   0         5m2sdefault      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-tokenrolebinding.rbac.authorization.k8s.io/test created# 检查candidate@node01:~$ kubectl describe -n app-team1 rolebindings.rbac.authorization.k8s.ioName:         testLabels:       <none>Annotations:  <none>Role:Kind:  ClusterRoleName:  deployment-clusterroleSubjects: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/v1kind: Rolemetadata:name: pod-readernamespace: 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 allresourcesresourceNames: ["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/v1kind: ClusterRolemetadata:# "namespace" 被忽略,因为 ClusterRoles 不受名字空间限制name: secret-readerlabelssnj:"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/v1kind: ClusterRolemetadata:name: monitoringaggregationRule: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” 的 Rolekind: RoleBindingmetadata:name: read-podsnamespace: default #一般和role是一个命名空间,这里的这个参数也实现了role的作用域roleRef:# "roleRef" 指定与某 Role 或 ClusterRole 的绑定关系kind: Role        # 此字段必须是 Role 或 ClusterRolename: pod-reader  # 此字段必须与你要绑定的 Role 或 ClusterRole 的名称匹配 subjects:# 你可以指定不止一个“subject(主体)”- kind: ServiceAccountname: test # "name" 是区分大小写的
ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1# 此集群角色绑定允许 “manager” 组中的任何人访问任何名字空间中的 Secret 资源kind: ClusterRoleBindingmetadata:name: read-secrets-global# 作用域是整个Cluster,不是单个namespace所以不写namespace# 如果资源是某个 namespace 下的,也就resourceNames指定了,那么就需要设置 namespace# 因为不同命名空间中可能会有重名roleRef:kind: ClusterRolename: secret-readersubjects:- kind: Groupname: manager      # 'name' 是区分大小写的

ServiceAccout

apiVersion: v1kind: ServiceAccountmetadata:name: admin-usernamespace: kube-system

命名空间问题

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

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

yaml 实操

# 名称空间角色apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata:name: snj-rolenamespace: 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/v1kind: ClusterRolemetadata:name: snj-clusterrolerules:- apiGroups: [""] # "" 标明 core API 组,默认留空即可。resources: ["namespaces"]verbs: ["get", "watch", "list"]---# ServiceAccountapiVersion: v1kind: ServiceAccountmetadata:name: snj # ServiceAccount 的名称namespace: default---# 账号和角色绑定apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata:name: snj-rolebindingnamespace: studysubjects:- kind: ServiceAccountname: snj # "name" 是区分大小写的roleRef:kind: Rolename: snj-roleapiGroup: rbac.authorization.k8s.io---# 账号和集群角色绑定apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:name: snj-clusterrolebindingsubjects:- kind: ServiceAccountname: snj # "name" 是区分大小写的namespace: default # 如果资源是某个 namespace 下的,那么就需要设置 namespaceroleRef:kind: ClusterRolename: snj-clusterroleapiGroup: rbac.authorization.k8s.io
---# pod 使用 saapiVersion: v1kind: Podmetadata:name: web-seccompnamespace: studyspec:serviceAcccountName: snjcontainers:- image: busybox:1.30name: hellocommand:- sleep- 24h

[root@master k8s]# kubectl apply -f role-test.yamlrole.rbac.authorization.k8s.io/snj-role createdclusterrole.rbac.authorization.k8s.io/snj-clusterrole createdserviceaccount/snj createdrolebinding.rbac.authorization.k8s.io/snj-rolebinding createdclusterrolebinding.rbac.authorization.k8s.io/xudaxian-clusterrolebinding created[root@master k8s]# kubectl get role -n studyNAME       CREATED ATsnj-role   2023-02-21T08:24:41Z[root@master k8s]# kubectl get rolebindings.rbac.authorization.k8s.io -n studyNAME              ROLE            AGEsnj-rolebinding   Role/snj-role   14s[root@master k8s]# kubectl get saNAME      SECRETS   AGEdefault   0         18dsnj       0         70s[root@master k8s]#  kubectl get clusterrole | grep snjsnj-clusterrole                                                        2023-02-21T08:24:41Z[root@master k8s]# kubectl get clusterrolebindings.rbac.authorization.k8s.io  | grep snjsnj-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 tillerkubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tillerkubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'

提供查看日志权限

apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata:namespace: defaultname: pod-and-pod-logs-readerrules:- 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_amd64wget https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl_1.5.0_linux_amd64wget https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_linux_amd64chmod +x cfssl*for name in `ls cfssl*`; do mv $name ${name%_1.5.0_linux_amd64};  donemv 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 userdevuser.csrdevuser-key.pemdevuser.pem

所属命名空间和权限

示例1

[root@node-01 rbac]# vim  role-pods-reader.yamlapiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata:name: devuser-rolenamespace: devrules:- apiGroups:- ""resources:- podsverbs:- get- list- watch
[root@master cert]# kubectl apply -f pods-reader.yamlrole.rbac.authorization.k8s.io/pods-reader created[root@master cert]# kubectl describe role -n dev pods-readerName:         pods-readerLabels:       <none>Annotations:  <none>PolicyRule:Resources  Non-Resource URLs  Resource Names  Verbs---------  -----------------  --------------  -----pods       []                 []              [get list watch]
[root@master cert]# cat devuser-pods-reader.yamlapiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata:name: devuser-role-bindingnamespace: dev # 定义作用域roleRef:apiGroup: rbac.authorization.k8s.iokind: Rolename: devuser-rolesubjects:- apiGroup: rbac.authorization.k8s.iokind: Username: devusernamespace: dev # 可写可不写
[root@master cert]# kubectl apply -f devuser-pods-reader.yamlrolebinding.rbac.authorization.k8s.io/devuser-pods-reader created[root@master cert]# kubectl describe rolebindings.rbac.authorization.k8s.io -n devName:         devuser-role-bindingLabels:       <none>Annotations:  <none>Role:Kind:  RoleName:  devuser-roleSubjects:Kind  Name     Namespace----  ----     ---------User  devuser

示例2

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

kubectl create ns devkubectl 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]# lsdevuser.json  devuser.kubeconfig

[root@master cert]# cat devuser.kubeconfigapiVersion: v1clusters:- cluster: #设置的是这一部分certificate-authority-data: ...server: https://192.168.100.53:6443name: kubernetescontexts: nullcurrent-context: ""kind: Configpreferences: {}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.kubeconfigapiVersion: v1clusters:- cluster:certificate-authority-data: DATA+OMITTEDserver: https://192.168.100.53:6443name: kubernetescontexts:- context:cluster: kubernetesnamespace: devuser: devusername: kubernetescurrent-context: ""kind: Configpreferences: {}users: #设置的是这一部分- name: devuseruser:client-certificate-data: DATA+OMITTEDclient-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.kubeconfigapiVersion: v1clusters:- cluster:certificate-authority-data: DATA+OMITTEDserver: https://192.168.100.53:6443name: kubernetescontexts: #设置的是这一部分- context:cluster: kubernetesnamespace: devuser: devusername: devuser@kubernetescurrent-context: ""kind: Configpreferences: {}users:- name: devuseruser:client-certificate-data: DATA+OMITTEDclient-key-data: DATA+OMITTED
切换上下文
[root@master cert]#  kubectl config use-context devuser@kubernetes --kubeconfig=/root/k8s/cert/devuser.kubeconfigSwitched to context "devuser@kubernetes".

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

useradd devuser     #创建什么用户名都可以mkdir /home/devuser/.kubecp devuser.kubeconfig /home/devuser/.kube/configchown devuser.devuser -R /home/devuser/.kube/su - devuser

测试

 # 访问测试[devuser@master ~]$ kubectl get podNo resources found in dev namespace.[devuser@master ~]$ kubectl get pod -n defaultError 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 podNAME    READY   STATUS    RESTARTS   AGEnginx   1/1     Running   0          12m[devuser@master ~]$ kubectl delete pod nginxError 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.ioError 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.1Error from server (Forbidden): pods is forbidden: User "devuser" cannot create resource "pods" in API group "" in the namespace "dev"

准入控制

  1. 通过了前面的认证和授权之后,还需要经过准入控制通过之后,API Server 才会处理这个请求。
  2. 准入控制是一个可配置的控制器列表,可以通过在 API Server 上通过命令行设置选择执行哪些注入控制器。
  3. 通过添加不同的插件,实现额外的准入控制规则
--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 的安全策略进行控制

kubernetes 证书体系

在 Kubernetes 中,私钥就是证书的 key ,公钥就是证书,当然也会存在 CA 机构的

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/608253.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

二分查找

二分查找(binary search)是一种基于分治策略的高效搜索算法。它利用数据的有序性&#xff0c;每轮缩小一半搜索范围&#xff0c;直至找到目标元素或搜索区间为空为止。 例&#xff1a;给定一个n 的数组 nums &#xff0c;元素按从小到大的顺序排列且不重复。请查找并返回元素 …

一键转换,创新无限:将HTML轻松转化为PDF!

在数字时代&#xff0c;HTML与PDF已成为信息传递的两大主流格式。然而&#xff0c;在这两者之间转换常常让人感到困扰。现在&#xff0c;有了我们的创新工具&#xff0c;您只需轻点一下&#xff0c;即可一键将HTML转化为PDF&#xff01; 首先&#xff0c;我们要进入首助编辑高…

【产品人卫朋】硬件产品经理:从入门到精通

目录 本文目录 1. 前言说明 2. 内容说明 3. 资料包说明 作者简介 本文目录 1. 前言说明 2. 内容说明 3. 资料包说明 1. 前言说明 本篇内容节选自实体书《硬件产品经理&#xff1a;从入门到精通》。 2. 内容说明 鉴于硬件产品的特殊性&#xff0c;不同产品阶段的时间间…

react输入框检索树形(tree)结构

input搜索框搜索树形子级内容1. input框输入搜索内容2. 获取tree结构数据3. 与tree匹配输入的内容&#xff0c;tree是多维数组&#xff0c;一级一级的对比输入的内容是否匹配&#xff0c;用forEach循环遍历数据&#xff0c;匹配不到在往下找&#xff0c;直到找到为null &#x…

MIT_线性代数笔记:第 25 讲 对称矩阵和正定性

目录 对称矩阵 Symmetric matrices实特征值 Real eigenvalues正定矩阵 Positive definite matrices 对称矩阵是最重要的矩阵之一&#xff0c;其特征值为实数并且拥有一套正交特征向量。正定矩阵的性质则更好。 对称矩阵 Symmetric matrices 包含特殊性质的矩阵&#xff0c;例如…

Probabilistic Forecasting with Temporal Convolutional Neural Network

Abstract 我们提出了一种基于卷积神经网络&#xff08;CNN&#xff09;的概率预测框架&#xff0c;用于多个相关时间序列预测。该框架可用于估计参数和非参数设置下的概率密度。更具体地说&#xff0c;构建基于扩张因果卷积网络的堆叠残差块来捕获序列的时间依赖性。与表示学习…

Certum与Geotrust的SSL证书区别

Certum和GeoTrust都是知名的CA认证机构&#xff0c;这两个品牌下的SSL证书在多个方面存在一些差异。今天就随SSL盾小编了解Certum与Geotrust证书的区别。 一、Certum机构背景 Certum是波兰的一家CA认证机构&#xff0c;成立于2002年&#xff0c;至今已有近20多年的历史。旗下有…

LeetCode-棒球比赛(682)

题目描述&#xff1a; 你现在是一场采用特殊赛制棒球比赛的记录员。这场比赛由若干回合组成&#xff0c;过去几回合的得分可能会影响以后几回合的得分。 比赛开始时&#xff0c;记录是空白的。你会得到一个记录操作的字符串列表 ops&#xff0c;其中 ops[i] 是你需要记录的第…

基于ZU19EG的100G-UDP解决方案

概述 本文档介绍ZU19EG与Mellanox CX6 100G网卡通信解决方案。 环境配置 FPGA硬件&#xff1a;519-ZU19EG的4路100G光纤PCIe加上计算卡 电脑&#xff1a;国产国鑫主板&#xff08;双PCU&#xff09;&#xff1a;Gooxi G2DA-B CPU:Intel Xeon Silver 2.2GHz 内存&#xff1…

Asp .Net Web应用程序(.Net Framework4.8)网站发布到IIS

开启IIS 如果已开启跳过这步 打开控制面板-程序 打开IIS 发布Web程序&#xff08;.Net Framework 4.8 web网页&#xff09; 进入IIS管理器新建一个应用池 新建一个网站 网站创建完毕 为文件夹添加访问权限 如果不添加访问权限&#xff0c;运行时将会得到如下错误 设置权限 勾…

kubernetes ResourceQuotas Limits(资源配额)

开头语 写在前面&#xff1a;如有问题&#xff0c;以你为准&#xff0c; 目前24年应届生&#xff0c;各位大佬轻喷&#xff0c;部分资料与图片来自网络 内容较长&#xff0c;页面右上角目录方便跳转 简介 当多个用户或团队共享具有固定节点数目的集群时&#xff0c;人们会…

使用串口 DMA 模式接收不定长数据

一、简介 曾经遇到客户有一个需求&#xff0c;需要用串口 DMA 的方式接收不定长度的数据&#xff0c;DMA 有个缺点就是在每次传输前需要设定好传输的字节长度&#xff0c;这种方式显然对于接收不定长度的数据来说没有那么灵活。但 DMA 也有着显著的优点&#xff0c;如可直接访…

JS新手入门笔记整理:对象

对象可以分为两种&#xff1a;一种是“自定义对象”&#xff0c;另外一种是“内置对象”。自定义对象&#xff0c;指的是需要我们自己定义的对象。内置对象&#xff0c;指的是不需要我们自己定义的&#xff08;即系统已经定义好的&#xff09;、可以直接使用的对象。在JavaScri…

abp vnext 下载指定版本的项目

开发环境 Win11 vs2022 abp vnext 下载地址&#xff1a;Get Started | ABP.IO 下载abp框架之前&#xff0c;需要先安装CLI&#xff0c;打开命令提示符&#xff0c;执行以下命令即可&#xff0c;这个也可以指定版本下载&#xff0c;这里就不做介绍了&#xff0c;以及删除命令…

【MySQL】数据库之Redis的持久化

目录 一、Redis的高可用 1.1什么是高可用 1.2Redis的高可用技术 1.3持久化功能 1.4Redis持久化的方式 二、Redis的持久化之RDB 2.1RDB持久化的触发方式 触发条件 RDB持久化的触发分为手动触发和自动触发两种。 &#xff08;1&#xff09;手动触发 &#xff08;2&…

‘pip‘ 不是内部或外部命令、ImportError: cannot import name ‘SCHEME_KEYS‘

错误一&#xff1a;启动程序中出现致命错误:无法使用“f:\pythonv\scripts\python.exe” G:\pythonv\scripts\ pip.exe” 错误二&#xff1a;‘pip‘ 不是内部或外部命令&#xff0c;也不是可运行的程序或批处理文件。 错误三&#xff1a;ImportError: cannot import name SCH…

九、分布式锁 —— 超详细操作演示!!!

九、分布式锁 —— 超详细操作演示&#xff01; 九、分布式锁9.1 分布式锁的工作原理9.2 问题引入9.2.1 场景9.2.2 实现9.2.3 分析 9.3 setnx 实现方式9.3.1 原理9.3.2 实现9.3.3 问题 9.4 为锁添加过期时间9.4.1 原理9.4.2 实现9.4.3 问题 9.5 为锁添加标识9.5.1 原理9.5.2 实…

嵌入式-C语言-江科大-指针的详解与应用

文章目录 一&#xff1a;计算机存储机制二&#xff1a;定义指针三&#xff1a;指针的操作四&#xff1a;数组与指针五&#xff1a;指针的应用道友&#xff1a;最清晰的脚印&#xff0c;踩在最泥泞的道路上。 推荐视频配合我的笔记使用 [C语言] 指针的详解与应用-理论结合实践&a…

Excel5:自动化周报的制作

自动化周报的数据引用来源于8月成交数据-纯数值表格&#xff0c;因为8月成交数据表格中部分单元格中有vlookup函数&#xff0c;且存在跨表连接。 对于跨表连接的解释和说明&#xff1f; 首先打开我们之前做好的成交数据。打开后我们可以看到这上面出现了一个安全警告&#xff0…

python实现目录和文件管理

目录 一&#xff1a;模块介绍&#xff1a; 二&#xff1a;目录创建 三&#xff1a;目录删除 四&#xff1a;目录复制 五&#xff1a;目录移动 六&#xff1a;文件创建 七&#xff1a;文件删除 八&#xff1a;文件读取 一&#xff1a;模块介绍&#xff1a; Python的os和…