rbac权限

1.1 认证

认证基本介绍

kubernetes主要通过APIserver对外提供服务，那么就需要对访问apiserver的用户做认证，如果任何人都能访问apiserver，那么就可以随意在k8s集群部署资源，这是非常危险的，也容易被黑客攻击渗透，所以需要我们对访问k8s系统的apiserver的用户进行认证，确保是合法的符合要求的用户。

授权基本介绍：

认证通过后仅代表它是一个被apiserver信任的用户，能访问apiserver，但是用户是否拥有删除资源的权限， 需要进行授权操作，常见的授权方式有rbac授权。

准入控制基本介绍：当用户经过认证和授权之后，最后一步就是准入控制了，k8s提供了多种准入控制机制，它有点类似"插件"，为apiserver提供了很好的"可扩展性"。请求apiserver时，通过认证、鉴权后、持久化("api对象"保存到etcd)前，会经过"准入控制器"，让它可以做"变更和验证"。

创建pod时定义了资源上下限，但不满足LimitRange规则中定义的资源上下限，此时LimitRanger就会拒绝我们创建此pod

 

在K8S集群当中，当我们使用kubectl操作k8s资源时候，需要确定用哪个用户访问哪个k8s集群，kubectl操作k8s集群资源会去/root/.kube目录下找config文件，可以通过kubectl config查看config文件配置

 查看管理员配置文件

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
[root@k8s-master resourcequota]# kubectl config view
apiVersion: v1
clusters:  # 定义集群
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://192.168.10.50:6443 # 集群访问地址
  name: kubernetes  # 集群名字
contexts: # 集群用户绑定关系
- context: # 第一个集群绑定关系
    cluster: kubernetes # 集群名字
    user: kubernetes-admin  # 用户名字
  name: kubernetes-admin@kubernetes # 绑定关系的名字
current-context: kubernetes-admin@kubernetes # 设置当前使用那个绑定关系访问那个集群
kind: Config
preferences: {}
users:# 用户设定
- name: kubernetes-admin #名字
  user:
    client-certificate-data: REDACTED #key
    client-key-data: REDACTED

　　

在上面的配置文件当中，定义了集群、上下文以及用户。其中Config也是K8S的标准资源之一，在该配置文件当中定义了一个集群列表，指定的集群可以有多个；用户列表也可以有多个，指明集群中的用户；而在上下文列表当中，是进行定义可以使用哪个用户对哪个集群进行访问，以及当前使用的上下文是什么。

 kubectl get pods --kubeconfig=/root/.kube/config

.2 授权

用户通过认证之后，什么权限都没有，需要一些后续的授权操作，如对资源的增删该查等，kubernetes1.6之后开始有RBAC（基于角色的访问控制机制）授权检查机制。

 Kubernetes的授权是基于插件形成的，其常用的授权插件有以下几种：

1）Node（节点认证）

2）ABAC(基于属性的访问控制)

3）RBAC（基于角色的访问控制）***

4）Webhook（基于http回调机制的访问控制）

rbac 介绍：让一个用户（Users）扮演一个角色（Role），角色拥有权限，从而让用户拥有这样的权限，随后在授权机制当中，只需要将权限授予某个角色，此时用户将获取对应角色的权限，从而实现角色的访问控制。

Role：角色，它其实是一组规则，定义了一组对 Kubernetes API 对象的操作权限。

Subject：被作用者，既可以是“人”，也可以是“机器”，也可以是你在 Kubernetes 里定义的“用户”。

RoleBinding：定义了“被作用者”和“角色”的绑定关系。而这三个概念，其实就是整个 RBAC 体系的核心所在。

Role、RoleBinding、ClusterRole和ClusterRoleBinding的关系如下

1、用户基于rolebinding绑定到role:限定在rolebinding所在的名称空间

2、用户基于rolebinding绑定到clusterrole

 

（1）用户通过rolebinding绑定role

 

（2）用户通过rolebinding绑定clusterrole

 

rolebinding绑定clusterrole的好处：

 

假如有6个名称空间，每个名称空间的用户都需要对自己的名称空间有管理员权限，那么需要定义6个role和rolebinding，然后依次绑定，如果名称空间更多，我们需要定义更多的role，这个是很麻烦的，所以我们引入clusterrole，定义一个clusterrole，对clusterrole授予所有权限，然后用户通过rolebinding绑定到clusterrole，就会拥有自己名称空间的管理员权限了

 

 注：RoleBinding仅仅对当前名称空间有对应的权限。

用户基于clusterrolebinding绑定到clusterrole

 

用户基于rbac授权有几种方案：

 

基于rolebinding绑定到role上

 

基于rolebinding绑定到clusterrole上

 

基于clusterrolebinding绑定到clusterrole上

 

准入控制

 

 

在k8s上准入控制器的模块有很多，其中比较常用的有LimitRanger、ResourceQuota、ServiceAccount、PodSecurityPolicy(k8s1.25废弃了)等等，对于前面三种准入控制器系统默认是启用的，我们只需要定义对应的规则即可；对于PodSecurityPolicy(k8s1.25废弃了)这种准入控制器，系统默认没有启用，如果我们要使用，就必需启用以后，对应规则才会正常生效；这里需要注意一点，对应psp准入控制器，一定要先写好对应的规则，把规则和权限绑定好以后，在启用对应的准入控制器，否则先启用准入控制器，没有对应的规则，默认情况它是拒绝操作，这可能导致现有的k8s系统跑的系统级pod无法正常工作；所以对于psp准入控制器要慎用，如果规则和权限做的足够精细，它会给我们的k8s系统安全带来大幅度的提升，反之，可能导致整个k8s系统不可用。

 

https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/admission-controllers/

 

Useraccount和ServiceAccount介绍

kubernetes中账户分为：UserAccounts（用户账户） 和 ServiceAccounts（服务账户） 两种：

UserAccount是给kubernetes集群外部用户使用的，如kubectl访问k8s集群要用useraccount用户， kubeadm安装的k8s，默认的useraccount用户是kubernetes-admin；

k8s客户端(一般用:kubectl) ------>API Server：APIServer需要对客户端做认证，使用kubeadm安装的K8s，会在用户家目录下创建一个认证配置文件 .kube/config 这里面保存了客户端访问API Server的密钥相关信息，这样当用kubectl访问k8s时，它就会自动读取该配置文件，向API Server发起认证，然后完成操作请求。

 

 

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
[root@k8s-master resourcequota]# kubectl create sa sa-test
serviceaccount/sa-test created
[root@k8s-master resourcequota]# kubectl create -f sa-pod.yaml
pod/sa-test created
[root@k8s-master resourcequota]#
[root@k8s-master resourcequota]# cat sa-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: sa-test
spec:
  serviceAccountName: sa-test # 指定pod 运行时服务账户
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
    ports:
    - name: web
      containerPort: 80
[root@k8s-master resourcequota]# kubectl exec -it sa-test -- /bin/bash
root@sa-test:/#  cd /var/run/secrets/kubernetes.io/serviceaccount/
root@sa-test:/var/run/secrets/kubernetes.io/serviceaccount# curl --cacert ./ca.crt  -H "Authorization: Bearer $(cat ./token)"  https://kubernetes/api/v1/namespaces/kube-system
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {},
  "status": "Failure",
  "message": "namespaces \"kube-system\" is forbidden: User \"system:serviceaccount:default:sa-test\" cannot get resource \"namespaces\" in API group \"\" in the namespace \"kube-system\"",
  "reason": "Forbidden",
  "details": {
    "name": "kube-system",
    "kind": "namespaces"
  },
  "code": 403
}
[root@k8s-master ~]# kubectl create clusterrolebinding sa-test-admin --clusterrole=cluster-admin  --serviceaccount=default:sa-test
clusterrolebinding.rbac.authorization.k8s.io/sa-test-admin created
root@sa-test:/var/run/secrets/kubernetes.io/serviceaccount# curl --cacert ./ca.crt  -H "Authorization: Bearer $(cat ./token)"  https://kubernetes/api/v1/namespaces/kube-system #授权后再次访问
{
  "kind": "Namespace",
  "apiVersion": "v1",
  "metadata": {
    "name": "kube-system",
    "uid": "94d68d58-8c7d-4364-bc8e-a837cba93099",
    "resourceVersion": "9",
    "creationTimestamp": "2023-10-04T02:05:39Z",
    "labels": {
      "kubernetes.io/metadata.name": "kube-system"
    },
    "managedFields": [
      {
        "manager": "kube-apiserver",
        "operation": "Update",
        "apiVersion": "v1",
        "time": "2023-10-04T02:05:39Z",
        "fieldsType": "FieldsV1",
        "fieldsV1": {
          "f:metadata": {
            "f:labels": {
              ".": {},
              "f:kubernetes.io/metadata.name": {}
            }
          }
        }
      }
    ]
  },
  "spec": {
    "finalizers": [
      "kubernetes"
    ]
  },
  "status": {
    "phase": "Active"
  }
}

　　rbac 认证授权策略

在Kubernetes中，所有资源对象都是通过API进行操作，他们保存在etcd里。而对etcd的操作我们需要通过访问 kube-apiserver 来实现，上面的Service Account其实就是APIServer的认证过程，而授权的机制是通过RBAC：基于角色的访问控制实现。RBAC有四个资源对象，分别是Role、ClusterRole、RoleBinding、ClusterRoleBinding

Role:一组权限的集合，在一个命名空间中，可以用其来定义一个角色，只能对命名空间内的资源进行授权。如果是集群级别的资源，则需要使用ClusterRole。例如：定义一个角色用来读取Pod的权限

 

?
1
2
3
4
5
6
7
8
9
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: rbac
  name: example-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

rules中的参数说明：

1、apiGroups：支持的API组列表，例如："apiVersion: apps/v1"等

2、resources：支持的资源对象列表，例如pods、deployments、jobs等

3、resourceNames: 指定resource的名称

4、verbs：对资源对象的操作方法列表。

ClusterRole：集群角色

?
1
2
3
4
5
6
7
8
9
10
11
[root@k8s-master resourcequota]# cat rbac2.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secrets-clusterroleu
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get","watch","list"]
[root@k8s-master resourcequota]# kubectl apply -f rbac2.yaml
clusterrole.rbac.authorization.k8s.io/secrets-clusterroleu created

　　

具有和角色一致的命名空间资源的管理能力，还可用于以下特殊元素的授权

1、集群范围的资源，例如Node

2、非资源型的路径，例如：/healthz

3、包含全部命名空间的资源，例如Pods

 RoleBinding：角色绑定、ClusterRolebinding：集群角色绑定

 

角色绑定和集群角色绑定用于把一个角色绑定在一个目标上，可以是User，Group，Service Account，使用RoleBinding为某个命名空间授权，使用ClusterRoleBinding为集群范围内授权。

将在rbac命名空间中把pod-read角色授予用户es

 

?
1
2
3
4
5
6
7
8
9
10
11
12
13
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-read-bind
  namespace: rbac
subjects:
- kind: User
  name: es
  apiGroup: rbac.authorization.k8s.io
roleRef:
- kind: Role
  name: pod-read
  apiGroup: rbac.authorizatioin.k8s.io

　　

RoleBinding也可以引用ClusterRole，对属于同一命名空间内的ClusterRole定义的资源主体进行授权， 

?
1
2
3
4
5
6
7
8
9
10
11
12
13
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: es-allresource
  namespace: rbac
subjects:
- kind: User
  name: es
  apiGroup: rbac.authorization.k8s.io
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin

常见角色(role)授权的案例

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
（1）允许读取核心API组的Pod资源
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get","list","watch"]
 
（2）允许读写apps API组中的deployment资源
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get","list","watch","create","update","patch","delete"]
 
 
（3）允许读取Pod以及读写job信息
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get","list","watch"]
- apiGroups: [""]
  resources: ["jobs"]
  verbs: ["get","list","watch","create","update","patch","delete"]
 
 
（4）允许读取一个名为my-config的ConfigMap（必须绑定到一个RoleBinding来限制到一个Namespace下的ConfigMap）：
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["my-configmap"]
  verbs: ["get"]
 
（5）读取核心组的Node资源（Node属于集群级的资源，所以必须存在于ClusterRole中，并使用ClusterRoleBinding进行绑定）：
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get","list","watch"]
 
（6）允许对非资源端点“/healthz”及其所有子路径进行GET和POST操作（必须使用ClusterRole和ClusterRoleBinding）：
rules:
- nonResourceURLs: ["/healthz","/healthz/*"]
  verbs: ["get","post"]

　　

资源的引用方式

多数资源可以用其名称的字符串表示，也就是Endpoint中的URL相对路径，例如pod中的日志是GET /api/v1/namaspaces/{namespace}/pods/{podname}/log

如果需要在一个RBAC对象中体现上下级资源，就需要使用“/”分割资源和下级资源。

例如：若想授权让某个主体同时能够读取Pod和Pod log，则可以配置 resources为一个数组

?
1
2
3
4
5
6
7
8
9
10
11
12
[root@k8s-master resourcequota]# cat rbac3.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: logs-reader
  namespace: test
rules:
- apiGroups: [""]
  resources: ["pods","pods/log"]
  verbs: ["get","list","watch"]
[root@k8s-master resourcequota]# kubectl apply -f rbac3.yaml
role.rbac.authorization.k8s.io/logs-reader unchanged

　　做绑定

?
1
2
3
4
[root@k8s-master resourcequota]#  kubectl create sa sa-test -n test
serviceaccount/sa-test created
[root@k8s-master resourcequota]# kubectl create rolebinding sa-test-1 -n test  --role=logs-reader --serviceaccount=test:sa-test
rolebinding.rbac.authorization.k8s.io/sa-test-1 created

　　

对Service Account的授权管理

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Service Account也是一种账号，是给运行在Pod里的进程提供了必要的身份证明。需要在Pod定义中指明引用的Service Account，这样就可以对Pod的进行赋权操作。例如：pod内可获取rbac命名空间的所有Pod资源，pod-reader-sc的Service Account是绑定了名为pod-read的Role
1）my-namespace中的my-sa Service Account授予只读权限
kubectl create rolebinding my-sa-view --clusterrole=view --serviceaccount=my-namespace:my-sa --namespace=my-namespace
 
（2）为一个命名空间中名为default的Service Account授权
如果一个应用没有指定 serviceAccountName，则会使用名为default的Service Account。注意，赋予Service Account “default”的权限会让所有没有指定serviceAccountName的Pod都具有这些权限
 
例如，在my-namespace命名空间中为Service Account“default”授予只读权限：
kubectl create rolebinding default-view --clusterrole=view --serviceaccount=my-namespace:default --namespace=my-namespace
 
 
（3）为命名空间中所有Service Account都授予一个角色
如果希望在一个命名空间中，任何Service Account应用都具有一个角色，则可以为这一命名空间的Service Account群组进行授权
 
kubectl create rolebinding serviceaccounts-view --clusterrole=view --group=system:serviceaccounts:my-namespace --namespace=my-namespace
 
（4）为集群范围内所有Service Account都授予一个低权限角色
如果不想为每个命名空间管理授权，则可以把一个集群级别的角色赋给所有Service Account。
 
kubectl create clusterrolebinding serviceaccounts-view --clusterrole=view --group=system:serviceaccounts
 
（5）为所有Service Account授予超级用户权限
kubectl create clusterrolebinding serviceaccounts-view --clusterrole=cluster-admin --group=system:serviceaccounts

　　

使用kubectl命令行工具创建资源对象

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
9、使用kubectl命令行工具创建资源对象
（1）在命名空间rbac中为用户es授权admin ClusterRole：
 
kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=es --namespace=rbac
 
 
（2）在命名空间rbac中为名为myapp的Service Account授予view ClusterRole：
     
kubctl create rolebinding myapp-role-binding --clusterrole=view --serviceaccount=rbac:myapp --namespace=rbac
 
 
（3）在全集群范围内为用户root授予cluster-admin ClusterRole：
     
kubectl create clusterrolebinding cluster-binding --clusterrole=cluster-admin --user=root
 
 
（4）在全集群范围内为名为myapp的Service Account授予view ClusterRole：
     
kubectl create clusterrolebinding service-account-binding --clusterrole=view --serviceaccount=myapp
 
 
yaml文件进行rbac授权：https://kubernetes.io/zh/docs/reference/access-authn-authz/rbac/

　　限制不同用户授权

ssl认证
生成一个私钥

?
1
2
3
4
5
6
7
[root@k8s-master rs]# cd /etc/kubernetes/pki/
您在 /var/spool/mail/root 中有新邮件
[root@k8s-master pki]# (umask 077; openssl genrsa -out lucky1.key 2048)
Generating RSA private key, 2048 bit long modulus
...............................................................................+++
...............................+++
e is 65537 (0x10001)

　　生成一个证书请求

?
1
[root@k8s-master pki]# openssl req -new -key lucky1.key -out lucky1.csr -subj "/CN=lucky66"

　　（3）生成一个证书

?
1
2
3
4
[root@k8s-master pki]# openssl x509 -req -in lucky1.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out lucky1.crt -days 3650
Signature ok
subject=/CN=lucky66
Getting CA Private Key

　　

在kubeconfig下新增加一个lucky这个用户
（1）把lucky这个用户添加到kubernetes集群中，可以用来认证apiserver的连接

?
1
2
[root@k8s-master pki]# kubectl config set-credentials lucky66 --client-certificate=./lucky1.crt --client-key=./lucky1.key --embed-certs=true 
User "lucky66" set.

　（2）在kubeconfig下新增加一个lucky这个账号

?
1
2
[root@k8s-master pki]# kubectl config set-context lucky66@kubernetes --cluster=kubernetes --user=lucky66
Context "lucky66@kubernetes" created.

　　查看配置文件

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
[root@k8s-master pki]# kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://192.168.10.50:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
- context:
    cluster: kubernetes
    user: lucky66
  name: lucky66@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
- name: lucky66
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED

　　切换集群访问用户

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
[root@k8s-master pki]# kubectl config use-context lucky66@kubernetes
Switched to context "lucky66@kubernetes".
[root@k8s-master pki]# kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://192.168.10.50:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
- context:
    cluster: kubernetes
    user: lucky66
  name: lucky66@kubernetes
current-context: lucky66@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
- name: lucky66
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED

　　使用这个无任何权限用户访问集群pod 资源

?
1
2
[root@k8s-master pki]# kubectl get pod
Error from server (Forbidden): pods is forbidden: User "lucky66" cannot list resource "pods" in API group "" in the namespace "default"

　　用户切换回来

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
[root@k8s-master pki]# kubectl config use-context kubernetes-admin@kubernetes
Switched to context "kubernetes-admin@kubernetes".
[root@k8s-master pki]# kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://192.168.10.50:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
- context:
    cluster: kubernetes
    user: lucky66
  name: lucky66@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
- name: lucky66
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
[root@k8s-master pki]# kubectl get pod
NAME                                    READY   STATUS    RESTARTS       AGE
nfs-client-provisioner-cbdf98fc-wfc5z   1/1     Running   4 (2d3h ago)   2d12h
sa-test                                 1/1     Running   0              35h

　　创建名称空间授权新用户管理员权限

?
1
2
3
4
[root@k8s-master pki]# kubectl create ns luck-chenxi
namespace/luck-chenxi created
[root@k8s-master pki]# kubectl create rolebinding lucky -n luck-chenxi --clusterrole=cluster-admin --user=lucky66
rolebinding.rbac.authorization.k8s.io/lucky created

　　切换访问集群用户测试新用户

?
1
2
3
4
[root@k8s-master pki]# kubectl get pod
Error from server (Forbidden): pods is forbidden: User "lucky66" cannot list resource "pods" in API group "" in the namespace "default"  无权限
[root@k8s-master pki]# kubectl get pod -n luck-chenxi  有权限
No resources found in luck-chenxi namespace.

　　添加用户

?
1
2
3
4
5
6
7
8
9
10
11
12
13
添加一个test66的普通用户
useradd test66
rm -rf /tmp/.kube
cp -ar /root/.kube /tmp/
修改/tmp/.kube/config文件，把kubernetes-admin和lucky相关的删除，只留lucky66用户
cp -ar /tmp/.kube/ /home/test66/
chown -R test66.test66 /home/test66/
[root@master1]# vim /home/test66/.kube/config
把current-context变成如下：
current-context: lucky66@kubernetes
su  - test66
kubectl get pods
kubectl get pods  -n kube-system

　　授权用户查看所有名称空间pod

生成证书

?
1
2
3
4
5
6
7
8
9
ssl认证
生成一个证书
（1）生成一个私钥
cd /etc/kubernetes/pki/
(umask 077; openssl genrsa -out lucky1.key 2048)
（2）生成一个证书请求
openssl req -new -key lucky1.key -out lucky1.csr -subj "/CN=lucky66"
（3）生成一个证书
openssl x509 -req -in lucky1.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out lucky1.crt -days 3650

　　

在kubeconfig下新增加一个lucky这个用户

 

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
ssl认证
生成一个证书
（1）生成一个私钥
cd /etc/kubernetes/pki/
(umask 077; openssl genrsa -out lucky1.key 2048)
（2）生成一个证书请求
openssl req -new -key lucky1.key -out lucky1.csr -subj "/CN=lucky66"
（3）生成一个证书
openssl x509 -req -in lucky1.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out lucky1.crt -days 3650
在kubeconfig下新增加一个lucky这个用户
（1）把lucky这个用户添加到kubernetes集群中，可以用来认证apiserver的连接
[root@master1 pki]# kubectl config set-credentials lucky66 --client-certificate=./lucky1.crt --client-key=./lucky1.key --embed-certs=true 
（2）在kubeconfig下新增加一个lucky这个账号
kubectl config set-context lucky66@kubernetes --cluster=kubernetes --user=lucky66
(3)创建一个clusterrole
[root@master1 sa]# vim lucky66-clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: lucky66-get-pod
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
 
[root@master1]# kubectl apply -f lucky66-clusterrole.yaml
（4）创建一个clusterrolebinding
[root@master1]# kubectl create clusterrolebinding lucky66-get-pods --clusterrole=lucky66-get-pod  --user=lucky66

 

　　

 

posted @   烟雨楼台，行云流水  阅读(90)  评论(0)  编辑  收藏  举报
相关博文：
· k8s的rbac 授权
· k8s1.25安装
· k8s安全管理
· k8s安全---安全机制之RBAC授权(14)
· 15.RBAC授权
阅读排行：
· 无需6万激活码！GitHub神秘组织3小时极速复刻Manus，手把手教你使用OpenManus搭建本
· C#/.NET/.NET Core优秀项目和框架2025年2月简报
· 葡萄城 AI 搜索升级：DeepSeek 加持，客户体验更智能
· 什么是nginx的强缓存和协商缓存
· 一文读懂知识蒸馏
点击右上角即可分享
微信分享提示