企业项目实战k8s篇（十二）kubernetes控制

最新推荐文章于 2024-05-08 03:30:23 发布

张一不二

最新推荐文章于 2024-05-08 03:30:23 发布

阅读量263

点赞数 2

分类专栏： linux学习 docker容器 k8s 文章标签： kubernetes linux docker

本文链接：https://blog.csdn.net/qq_42003848/article/details/119348014

版权

linux学习同时被 3 个专栏收录

87 篇文章 4 订阅

订阅专栏

docker容器

31 篇文章 4 订阅

订阅专栏

k8s

21 篇文章 8 订阅

订阅专栏

kubernetes控制

一.访问控制原理
二.serviceaccount
三.UserAccount
四.RBAC（Role Based Access Control）
五.服务账户的自动化

一.访问控制原理

kubernetes API 访问控制
在这里插入图片描述

Authentication（认证）

认证方式现共有8种，可以启用一种或多种认证方式，只要有一种认证方式通过，就不再进行其它方式的认证。通常启用X509 Client Certs和Service Accout Tokens两种认证方式。

Kubernetes集群有两类用户

由Kubernetes管理的Service Accounts （服务账户）和（Users Accounts）普通账户。k8s中账号的概念不是我们理解的账号，它并不真的存在，它只是形式上存在。

Authorization（授权）

必须经过认证阶段，才到授权请求，根据所有授权策略匹配请求资源属性，决定允许或拒绝请求。授权方式现共有6种，AlwaysDeny、AlwaysAllow、ABAC、RBAC、Webhook、Node。默认集群强制开启RBAC。

Admission Control（准入控制）

用于拦截请求的一种方式，运行在认证、授权之后，是权限认证链上的最后一环，对请求API资源对象进行修改和校验

访问k8s的API Server的客户端主要分为两类：

kubectl ：用户家目录中的 .kube/config 里面保存了客户端访问API Server的密钥相关信息，这样当用kubectl访问k8s时，它就会自动读取该配置文件，向API Server发起认证，然后完成操作请求。
pod：Pod中的进程需要访问API Server，如果是人去访问或编写的脚本去访问，这类访问使用的账号为：UserAccount；而Pod自身去连接API Server时，使用的账号是：ServiceAccount，生产中后者使用居多。

kubectl向apiserver发起的命令,采用的是http方式,其实就是对URL发起增删改查的操作。

$ kubectl proxy --port=8888 &
$ curl http://localhost:8888/api/v1/namespaces/default
$ curl http://localhost:8888/apis/apps/v1/namespaces/default/deployments

以上两种api的区别是：

api它是一个特殊链接,只有在核心v1群组中的对象才能使用。
apis 它是一般API访问的入口固定格式名。

UserAccount与serviceaccount：

用户账户是针对人而言的。服务账户是针对运行在 pod 中的进程而言的。
用户账户是全局性的。其名称在集群各 namespace 中都是全局唯一的，未来的用户资源不会做 namespace 隔离，服务账户是 namespace 隔离的。
通常情况下，集群的用户账户可能会从企业数据库进行同步，其创建需要特殊权限，并且涉及到复杂的业务流程。服务账户创建的目的是为了更轻量，允许集群用户为了具体的任务创建服务账户 ( 即权限最小化原则 )。

二.serviceaccount

创建serviceaccount

kubectl create serviceaccount admin
serviceaccount/admin created

创建镜像拉取认证secret/myregistrykey

[root@server1 test]# kubectl create secret docker-registry myregistrykey --docker-server=reg.westos.org --docker-username=admin --docker-password=westos --docker-email=root@westos.org
secret/myregistrykey created

添加secrets到serviceaccount中：

 kubectl patch serviceaccount admin -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}'

[root@server1 test]# kubectl  get secrets 
NAME                  TYPE                                  DATA   AGE
admin-token-4cf4w     kubernetes.io/service-account-token   3      27m
default-token-t5dst   kubernetes.io/service-account-token   3      9d
myregistrykey         kubernetes.io/dockerconfigjson        1      7s

[root@server1 account]# kubectl describe sa admin 
Name:                admin
Namespace:           default
Labels:              <none>
Annotations:         <none>
Image pull secrets:  myregistrykey
Mountable secrets:   admin-token-4cf4w
Tokens:              admin-token-4cf4w
Events:              <none>

把serviceaccount和pod绑定起来,拉取私密仓库创建nginx pod：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
   labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: reg.westos.org/westos/nginx
    ports:
    - name: http
      containerPort: 80
  serviceAccountName: admin

[root@server1 test]# kubectl  get pod
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   1          42h

将认证信息添加到serviceAccount中，要比直接在Pod指定imagePullSecrets要安全很多。

三.UserAccount

创建UserAccount


[root@server1 account]# cd /etc/kubernetes/pki/
[root@server1 pki]# ls
apiserver.crt                 apiserver-kubelet-client.key  front-proxy-ca.key
apiserver-etcd-client.crt     ca.crt                        front-proxy-client.crt
apiserver-etcd-client.key     ca.key                        front-proxy-client.key
apiserver.key                 etcd                          sa.key
apiserver-kubelet-client.crt  front-proxy-ca.crt            sa.pub
[root@server1 pki]# openssl genrsa -out test.key 2048
Generating RSA private key, 2048 bit long modulus
.............+++
.............................+++
e is 65537 (0x10001)
[root@server1 pki]#  openssl req -new -key test.key -out test.csr -subj "/CN=test"
[root@server1 pki]# openssl  x509 -req -in test.csr -CA ca.crt -CAkey ca.key  -CAcreateserial -out test.crt -days 365
Signature ok
subject=/CN=test
Getting CA Private Key
[root@server1 pki]# openssl x509 -in test.crt -text -noout
Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number:
            ec:4d:01:87:aa:a7:c0:34
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=kubernetes
        Validity
            Not Before: Aug  3 03:15:15 2021 GMT
            Not After : Aug  3 03:15:15 2022 GMT
        Subject: CN=test
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:eb:1a:4e:81:33:00:97:68:87:79:83:20:6c:e1:
                    3c:d8:f7:67:ad:08:ae:87:13:9c:5f:5b:84:ed:82:
                    be:c1:0b:d4:ed:59:fb:1a:d4:08:63:5a:ff:db:1f:
                    3f:2a:0d:98:dc:1b:7c:67:59:ef:11:98:8a:2f:67:
                    b2:8b:02:fa:ca:3c:d8:b3:b0:a7:dc:6e:ff:58:3a:
                    c6:b1:a2:88:05:0d:e4:6c:5c:41:d4:5d:47:3d:f3:
                    49:55:51:27:b7:4c:2c:55:77:21:e6:ed:8e:90:2d:
                    6e:89:53:b2:c7:9a:fc:b6:60:93:f2:04:5e:dc:f7:
                    1a:76:80:ea:94:d1:80:60:db:fa:c9:ad:37:7b:8c:
                    86:bd:0a:7e:79:9f:74:25:36:4a:58:2a:16:62:f2:
                    36:8e:fd:b2:73:72:41:22:92:63:78:cd:39:7f:af:
                    e1:c6:fa:0c:25:69:01:81:e2:41:49:13:9c:04:d2:
                    f5:9c:aa:78:1a:40:a8:4d:98:69:b2:55:c8:aa:05:
                    93:df:fe:05:05:56:e7:8c:f6:04:f5:35:03:c2:89:
                    ec:20:9b:f0:33:22:3e:6a:10:eb:15:21:80:e2:a6:
                    d5:8a:92:9e:24:7a:61:4f:32:f0:50:d2:c5:c8:2b:
                    aa:9a:0f:5c:83:94:38:54:df:35:1e:bb:f9:46:8b:
                    e7:a7
                Exponent: 65537 (0x10001)
    Signature Algorithm: sha256WithRSAEncryption
         59:81:b5:8a:d4:cd:45:31:7b:24:b8:c5:1e:5c:9a:29:c8:ee:
         26:ac:e6:ee:aa:63:08:04:ce:d1:9a:e8:a6:30:f3:38:9b:58:
         77:69:4c:3f:a6:ad:56:a7:b0:64:6d:40:7c:ed:6e:9c:f1:e3:
         bd:43:fa:e4:d4:b2:15:f4:05:9f:7e:0e:6f:f9:8e:7b:98:eb:
         fe:56:ef:26:90:95:67:9b:02:b8:f8:fb:a2:f9:ee:00:4a:91:
         08:a1:a9:8e:22:f3:32:5f:63:ce:46:8f:94:de:60:95:2c:83:
         fe:78:f6:0e:05:7b:8e:42:11:e5:43:d4:c0:36:e2:fa:5f:8f:
         28:a8:f2:af:6d:79:1d:66:64:a8:52:2d:6e:62:18:21:ee:79:
         14:41:99:f8:11:a3:01:14:67:e5:28:69:5b:e8:8c:00:71:c8:
         44:50:bc:41:26:5c:ac:65:47:33:3d:03:4b:f0:6b:61:c8:ac:
         f8:f2:ad:29:15:82:c7:bb:43:eb:58:a3:66:a8:a9:bb:5d:ba:
         7a:e2:aa:35:94:fa:25:d6:aa:3d:06:c2:8c:73:e2:d4:c6:3c:
         0f:a0:7c:9a:0c:44:06:fb:eb:3c:02:9e:34:64:72:9a:e4:97:
         09:a2:b6:b0:d4:fb:14:47:ce:b9:c6:8e:1e:a8:a7:6b:a6:fa:
         94:47:f8:0d
[root@server1 pki]# 
[root@server1 pki]# $ kubectl config set-credentials test --client-certificate=/etc/kubernetes/pki/test.crt --client-key=/etc/kubernetes/pki/test.key --embed-certs=true
-bash: $: command not found
[root@server1 pki]#  kubectl config set-credentials test --client-certificate=/etc/kubernetes/pki/test.crt --client-key=/etc/kubernetes/pki/test.key --embed-certs=true
User "test" set.
[root@server1 pki]# kubectl  config view
apiVersion: v1
clusters:

- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://172.25.3.1: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
    client-key-data: REDACTED
- name: test
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
  [root@server1 pki]#  kubectl config set-context test@kubernetes --cluster=kubernetes --user=test
  Context "test@kubernetes" created.
  [root@server1 pki]# kubectl config use-context test@kubernetes
  Switched to context "test@kubernetes".
  [root@server1 pki]# kubectl  get pod
  Error from server (Forbidden): pods is forbidden: User "test" cannot list resource "pods" in API group "" in the namespace "default"

此时用户通过认证，但还没有权限操作集群资源，需要继续添加授权。

四.RBAC（Role Based Access Control）

RBAC（Role Based Access Control）：基于角色访问控制授权。

允许管理员通过Kubernetes API动态配置授权策略。RBAC就是用户通过角色与权限进行关联。
RBAC只有授权，没有拒绝授权，所以只需要定义允许该用户做什么即可。
RBAC包括四种类型：Role、ClusterRole、RoleBinding、ClusterRoleBinding。

在这里插入图片描述
RBAC的三个基本概念：

Subject：被作用者，它表示k8s中的三类主体， user， group， serviceAccount
Role：角色，它其实是一组规则，定义了一组对 Kubernetes API 对象的操作权限。
RoleBinding：定义了“被作用者”和“角色”的绑定关系。

Role 和 ClusterRole

Role是一系列的权限的集合，Role只能授予单个namespace 中资源的访问权限。
ClusterRole 跟 Role 类似，但是可以在集群中全局使用。

role

[root@server1 account]# cat role.yml 
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: myrole
rules:
- apiGroups: [""] 
  resources: ["pods"]
  verbs: ["get", "watch", "list", "create", "update", "patch", "delete"]

RoleBinding和ClusterRoleBinding
RoleBinding是将Role中定义的权限授予给用户或用户组。它包含一个subjects列表(users，groups ，service accounts)，并引用该Role。
RoleBinding是对某个namespace 内授权，ClusterRoleBinding适用在集群范围内使用。

RoleBinding

[root@server1 account]# cat rolebinging.yml 
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: test-read-pods
  namespace: default
subjects:
- kind: User
  name: test
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: myrole
  apiGroup: rbac.authorization.k8s.io

ClusterRole

[root@server1 account]# cat cluster
clusterbind.yml  clusterrole.yml  
[root@server1 account]# cat clusterrole.yml 
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: myclusterrole
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list", "delete", "create", "update"]
- apiGroups: ["extensions", "apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: [""]
  resources: ["services","endpoints"]
  verbs: ["get", "watch", "list", "delete", "create", "update"]

使用rolebinding绑定clusterRole

[root@server1 account]# cat rolebind-clusterrRole.yml 
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: rolebind-myclusterrole
  namespace:  default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: myclusterrole
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: test

创建clusterrolebinding

[root@server1 account]# cat clusterbind.yml 
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: clusterrolebinding-myclusterrole
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: myclusterrole
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: test

五.服务账户的自动化

服务账户的自动化

服务账户准入控制器（Service account admission controller）
如果该 pod 没有 ServiceAccount 设置，将其 ServiceAccount 设为 default。
保证 pod 所关联的 ServiceAccount 存在，否则拒绝该 pod。
如果 pod 不包含 ImagePullSecrets 设置，那么将 ServiceAccount 中的 ImagePullSecrets 信息添加到 pod 中。
将一个包含用于 API 访问的 token 的 volume 添加到 pod 中。
将挂载于 /var/run/secrets/kubernetes.io/serviceaccount 的 volumeSource 添加到 pod 下的每个容器中。

Token 控制器（Token controller）

检测服务账户的创建，并且创建相应的 Secret 以支持 API 访问。
检测服务账户的删除，并且删除所有相应的服务账户 Token Secret。
检测 Secret 的增加，保证相应的服务账户存在，如有需要，为 Secret 增加 token。
检测 Secret 的删除，如有需要，从相应的服务账户中移除引用。

服务账户控制器（Service account controller）

服务账户管理器管理各命名空间下的服务账户，并且保证每个活跃的命名空间下存在一个名为 “default” 的服务账户

Kubernetes 还拥有“用户组”（Group）的概念：

ServiceAccount对应内置“用户”的名字是：

system:serviceaccount:<ServiceAccount名字 >

而用户组所对应的内置名字是：

system:serviceaccounts:<Namespace名字 >

示例1：表示mynamespace中的所有ServiceAccount
subjects:

- kind: Group
  name: system:serviceaccounts:mynamespace
  apiGroup: rbac.authorization.k8s.io

示例2：表示整个系统中的所有ServiceAccount

subjects:
- kind: Group
  name: system:serviceaccounts
  apiGroup: rbac.authorization.k8s.io

Kubernetes 还提供了四个预先定义好的 ClusterRole 来供用户直接使用：

cluster-amdin
admin
edit
view

示例：(最佳实践)

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: readonly-default
subjects:
- kind: ServiceAccount
  name: default
  namespace: default
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io

张一不二

关注

2
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
企业项目实战k8s篇（十二）kubernetes控制

kubernetes控制一.访问控制原理二.serviceaccount三.UserAccount四.RBAC（Role Based Access Control）五.服务账户的自动化一.访问控制原理kubernetes API 访问控制Authentication（认证）认证方式现共有8种，可以启用一种或多种认证方式，只要有一种认证方式通过，就不再进行其它方式的认证。通常启用X509 Client Certs和Service Accout Tokens两种认证方式。Kubernetes集
复制链接

扫一扫