第二十章 kubernetes核心技术-集群安全机制

2021-11-26 14:33:24 阅读：200 来源： 互联网

标签：kubernetes 角色核心技术第二十章 rbac io k8s authorization name

一、概述

Kubernetes过一系列机制来实现集群的安全机制，包括API Server的认证授权、准入控制机制及保护敏感信息的Secret机制等。集群的安全性必须考虑以下的几个目标：

#1.保证容器与其所在宿主机的隔离；
#2.限制容器给基础设施及其他容器带来消极影响的能力；
#3.最小权限原则，合理限制所有组件权限，确保组件只执行它被授权的行为，通过限制单个组件的能力来限制他所能达到的权限范围；
#4.明确组件间边界的划分；
#5.划分普通用户和管理员角色；
#6.在必要的时候允许将管理员权限赋给普通用户；
#7.允许拥有Secret数据（Keys、Certs、Passwords）的应用在集群中运行；

二、API Server认证

通常访问k8s集群的时候，需要经过三个步骤完成具体操作
#1.认证
#2.鉴权（授权）
#3.准入控制

Kubernetes集群中所有资源的访问和变更都是通过Kubernetes API Server的REST API来实现的，所以集群安全的关键点在于识别认证客户端身份（Authentication）以及访问权限的授权（Authorization）。如果访问Pod，需要serverAccount。

1.认证和传输安全

Kubernetes提供管理三种级别的客户端身份认证方式：
#1.最严格的HTTPS证书认证：基于CA根证书签名的双向数字证书认证方式；
#2.HTTP Token认证：通过一个Token来识别合法用户；
#3.HTTP Base认证：通过用户名+密码的方式认证；

Kubernetes传输安全：
对外不暴露8080端口，只能内部访问，对外端口使用6443

2.鉴权（授权）

#1.基于RBAC进行鉴权操作
#2.基于角色访问控制

3.准入控制

就是准入控制器的列表，如果列表有请求内容通过，没有则拒绝。

三、RBAC基本概念

RBAC(Role-Based Access Control，基于角色的访问控制)在 k8s v1.5 中引入，在 v1.6 版本时升级为 Beta 版本，并成为 kubeadm 安装方式下的默认选项，相对于其他访问控制方式， 新的 RBAC 具有如下优势：

（1）	对集群中的资源和非资源权限均有完整的覆盖
（2）	整个 RBAC 完全由几个 API 对象完成，同其他 API 对象一样，可以用 kubectl 或 API 进行操作
（3）	可以在运行时进行调整，无需重启 API Server

要使用 RBAC 授权模式，需要在 API Server 的启动参数中加上--authorization-mode=RBAC

四、RBAC 的 API 资源对象说明

RBAC 引入了 4 个新的顶级资源对象：Role、ClusterRole、RoleBinding、
ClusterRoleBinding。同其他 API 资源对象一样，用户可以使用 kubectl 或者 API 调用等方式操作这些资源对象。

1. 角色(Role)

一个角色就是一组权限的集合，这里的权限都是许可形式的，不存在拒绝的规则。在一个   命名空间中，可以用角色来定义一个角色，如果是集群级别的，就需要使用 ClusterRole 了。角色只能对命名空间内的资源进行授权，下面的例子中定义的角色具备读取 Pod 的权限：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1 
metadata:
  namespace: default 
  name: pod-reader
rules:
- apiGroups: [""]	# 空字符串表示核心 API 群
  resource: ["pods"]
  verbs: ["get", "watch", "list"]

rules 中的参数说明：
#1.- apiGroup：支持的 API 组列表，例如：APIVersion: batch/v1、APIVersion:extensions:v1、apiVersion:apps/v1 等
#2.resources：支持的资源对象列表，例如：pods、deployments、jobs 等
#3.verbs：对资源对象的操作方法列表，例如：get、watch、list、delete、replace 等

2.集群角色(ClusterRole)

集群角色除了具有和角色一致的命名空间内资源的管理能力，因其集群级别的范围，还可以用于以下特殊元素的授权。

集群范围的资源，例如 Node 
非资源型的路径，例如/healthz
包含全部命名空间的资源，例如 pods

下面的集群角色可以让用户有权访问任意一个或所有命名空间的 secrets：

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1 
metadata:
  # name: secret-reader
  # ClusterRole 不受限于命名空间，所以省略了 namespace name 的定义
rules:
- apiGroups: [""] 
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

3.角色绑定(RoleBinding)和集群角色绑定(ClusterRoleBinding)

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

RoleBinding 可以引用 Role 进行授权，下例中的 RoleBinding 将在 default 命名空间中把pod-reader 角色授予用户 jane，可以让 jane 用户读取 default 命名空间的 Pod：

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1 
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，对属于同一命名空间内 ClusterRole 定义的资源主体进行授权。一种常见的做法是集群管理员为集群范围预先定义好一组角色(ClusterRole)，然后在多个命名空间中重复使用这些 ClusterRole。

使用 RoleBinding 绑定集群角色 secret-reader，使 dave 只能读取 development 命名空间中的 secret：

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-secrets 
  namespace: development
subjects:
- kind: User
  name: dave
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole 
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

集群角色绑定中的角色只能是集群角色，用于进行集群级别或者对所有命名空间都生效授权。允许 manager 组的用户读取任意 namespace 中的 secret

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
  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

五、RBAC对资源的引用方式

多数资源可以用其名称的字符串来表达，也就是 Endpoint 中的 URL 相对路径，例如 pods。然后，某些 Kubernetes API 包含下级资源，例如 Pod 的日志(logs)。Pod 日志的 Endpoint 是 GET /api/v1/namespaces/{namespaces}/pods/{name}/log。

Pod 是一个命名空间内的资源，log 就是一个下级资源。要在一个 RBAC 角色中体现，则需要用斜线/来分割资源和下级资源。若想授权让某个主体同时能够读取 Pod 和 Pod log，则可以配置 resources 为一个数组：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list"]

资源还可以通过名字(ResourceName)进行引用。在指定 ResourceName 后，使用 get、delete、update、patch 动词的请求，就会被限制在这个资源实例范围内。例如下面的声明让一个主体只能对一个叫 my-configmap 的 configmap 进行 get 和 update 操作：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: configmap-updater
rules:
- apiGroups: [""] resources: ["configmap"]
resourceNames: ["my-configmap"]
verbs: ["update", "get"]

六、角色(Role)示例

1.创建新的名称空间

#1.查看名称空间
[root@kubernetes-master-001 ~]# kubectl  get ns
NAME              STATUS   AGE
default           Active   8d
kube-node-lease   Active   8d
kube-public       Active   8d
kube-system       Active   8d

#2.创建名称空间
[root@kubernetes-master-001 ~]# kubectl  create  ns roledemo
namespace/roledemo created

#3.再次查看名称空间
[root@kubernetes-master-001 ~]# kubectl  get  ns
NAME              STATUS   AGE
default           Active   8d
kube-node-lease   Active   8d
kube-public       Active   8d
kube-system       Active   8d
roledemo          Active   7s

2.在新的名称空间中创建Pod

[root@kubernetes-master-001 ~]# kubectl  run  nginx --image=nginx -n roledemo 
pod/nginx created

[root@kubernetes-master-001 ~]# kubectl  get  pods -n roledemo 
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          21s

3.编写角色文件

[root@kubernetes-master-001 ~]# vim rbac-role.yaml
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: roledemo
  name: pod-reader
rules:
- apiGroups: [""] #"" indicates the core API group
  resources: ["pods"]
  verbs: ["get","watch","list"]

4.创建角色

#1.创建角色
[root@kubernetes-master-001 ~]# kubectl  apply  -f rbac-role.yaml 
role.rbac.authorization.k8s.io/pod-reader created

#2.查看角色
[root@kubernetes-master-001 ~]# kubectl get role -n roledemo 
NAME         CREATED AT
pod-reader   2021-11-16T09:48:17Z

5.创建角色绑定文件

[root@kubernetes-master-001 ~]# vim rbac-rolebinding.yaml
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: roledemo
subjects:
- kind: User
  name: mary
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

6.绑定角色

#1.绑定角色
[root@kubernetes-master-001 ~]# kubectl  apply  -f rbac-rolebinding.yaml 
rolebinding.rbac.authorization.k8s.io/read-pods created

#2.查看角色
[root@kubernetes-master-001 ~]# kubectl  get role,rolebinding -n roledemo 
NAME                                        CREATED AT
role.rbac.authorization.k8s.io/pod-reader   2021-11-16T09:48:17Z

NAME                                              ROLE              AGE
rolebinding.rbac.authorization.k8s.io/read-pods   Role/pod-reader   63s

7.安装证书生成工具

#1.下载cfssl证书生成工具
[root@kubernetes-master-001 ~]# mkdir -p /data/software
[root@kubernetes-master-001 ~]# cd /data/software
[root@kubernetes-master-001 /data/software]# wget https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl_1.5.0_linux_amd64
[root@kubernetes-master-001 /data/software]# wget https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_linux_amd64

#2.查看安装包
[root@kubernetes-master-001 /data/software]# ll
total 24196
-rw-r--r-- 1 root root 15108368 Aug 17 14:12 cfssl_1.5.0_linux_amd64
-rw-r--r-- 1 root root  9663504 Aug 17 14:12 cfssljson_1.5.0_linux_amd64

#3.设置执行权限
[root@kubernetes-master-001 /data/software]# chmod +x ./*

#4.移动到/usr/local/bin
[root@kubernetes-master-001 /data/software]# mv cfssljson_1.5.0_linux_amd64 cfssljson
[root@kubernetes-master-001 /data/software]# mv cfssl_1.5.0_linux_amd64 cfssl
[root@kubernetes-master-001 /data/software]# mv cfssljson cfssl /usr/local/bin

#5.查看cfssl证书生成工具版本
[root@kubernetes-master-001 /data/software]# cfssl version
Version: 1.5.0
Runtime: go1.12.12

8.使用证书识别身份

#1.创建用户目录
[root@kubernetes-master-001 ~]# mkdir mary

#2.进入用户目录
[root@kubernetes-master-001 ~]# cd mary/

#3.编辑生成证书文件
cat > /root/mary/ca-config.json <<EOF
{
  "signing": {
    "default": {
      "expiry": "8760h"
    },
    "profiles": {
      "kubernetes": {
        "usages": [
          "signing",
          "key encipherment",
          "server auth",
          "client auth"
        ],
           "expiry": "8760h"
      }
    }
  }
}
EOF

#4.便写创建用户脚本
[root@kubernetes-master-001 ~/mary]# vim rabc-user.sh 
cat > mary-csr.json <<EOF
{
  "CN": "mary",
  "hosts": [],
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "CN",
      "L": "BeiJing",
      "ST": "BeiJing"
    }
  ]
}
EOF

cfssl gencert -ca=ca.crt -ca-key=ca.key -config=ca-config.json -profile=kubernetes mary-csr.json | cfssljson -bare mary

kubectl config set-cluster kubernetes \
  --certificate-authority=ca.pem \
  --embed-certs=true \
  --server=https://192.168.13.100:6443 \
  --kubeconfig=mary-kubeconfig
  
kubectl config set-credentials mary \
  --client-key=mary-key.pem \
  --client-certificate=mary.pem \
  --embed-certs=true \
  --kubeconfig=mary-kubeconfig

kubectl config set-context default \
  --cluster=kubernetes \
  --user=mary \
  --kubeconfig=mary-kubeconfig

kubectl config use-context default --kubeconfig=mary-kubeconfig

#5.拷贝证书文件
[root@kubernetes-master-001 ~/mary]# cp /etc/kubernetes/pki/ca* ./
[root@kubernetes-master-001 ~/mary]# ll
total 16
-rw-r--r-- 1 root root  285 Nov 22 10:38 ca-config.json
-rw-r--r-- 1 root root 1066 Nov 22 10:14 ca.crt
-rw------- 1 root root 1675 Nov 22 10:14 ca.key
-rw-r--r-- 1 root root  834 Nov 22 10:20 rabc-user.sh

#6.生成用户mary证书
[root@kubernetes-master-001 ~/mary]# sh rabc-user.sh 
2021/11/22 10:39:00 [INFO] generate received request
2021/11/22 10:39:00 [INFO] received CSR
2021/11/22 10:39:00 [INFO] generating key: rsa-2048
2021/11/22 10:39:00 [INFO] encoded CSR
2021/11/22 10:39:00 [INFO] signed certificate with serial number 135651817161029423468382016328226371914633346991
2021/11/22 10:39:00 [WARNING] This certificate lacks a "hosts" field. This makes it unsuitable for
websites. For more information see the Baseline Requirements for the Issuance and Management
of Publicly-Trusted Certificates, v.1.1.6, from the CA/Browser Forum (https://cabforum.org);
specifically, section 10.2.3 ("Information Requirements").
Cluster "kubernetes" set.
User "mary" set.
Context "default" created.
Switched to context "default".

9.验证证书

#1.该用户只对查看Pod有权限
[root@kubernetes-master-001 ~/mary]# kubectl  get pods -n roledemo 
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          5d17h
[root@kubernetes-master-001 ~/mary]# kubectl  get svc -n roledemo 
No resources found in roledemo namespace.

七、常用角色（role）示例

1.允许读取核心 API 组中 Pod 的资源

rules:
- apiGroups: [""] 
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

2.允许读写"extensions"和"apps"两个 API 组中的 deployment 资源

rules:
- apiGroups: ["extensions", "apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

3.允许读写 pods 及读写 jobs

rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

- apiGroups: ["batch", "extensions"]
  resources: ["jobs"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

4.允许读取一个名为 my-config 的 ConfigMap(必须绑定到一个 RoleBinding 来限制到一个 namespace 下的 ConfigMap)

rules:
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["my-config"]
  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"]

八、常用的角色绑定

1. 用户名 Alice@example.com

subjects:
- kind: User
  name:  "Alice@example.com"
  apiGroup: rbac.authorization.k8s.io

2.组名frontend-admins

subjects:
- kind: Group
  name: "frontend-admins"
  apiGroup: rbac.authorization.k8s.io

3.kube-system 命名空间中的默认 Service Account

subjects:
- kind: ServiceAccount
  name: default
  namespace: kube-system

4.qa 命名空间中的所有 Service Account

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

5.所有 Service Account

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

6.所有认证用户

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

7.所有未认证用户

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

8.全部用户

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

九、默认的角色和用户绑定

API Server 会创建一套默认的 ClusterRole 和 ClusterRoleBinding 对象，其中很多是以 system:为前缀的，以表明这些资源属于基础架构，对这些对象的改动可能造成集群故障。所有默认的 ClusterRole 和RoleBinding 都会用标签 kubernetes.io/bootstrapping=rbac-defaults 进行标记。常见的系统角色如下：

有些默认角色不是以 system:为前缀的，这部分角色是针对用户的，其中包含超级用户角色 cluster-admin，有的用于集群一级的角色 cluster-status，还有针对 namespace 的角色 admin、edit、view.常见的用户角色如下：

核心 Master 组件角色如下：

十、授权注意事项：预防提权和授权初始化

RBAC API 拒绝用户利用编辑角色或者角色绑定的方式进行提权。这一限制是在 API 层面做出的，因此即使 RBAC 没有启用也仍然有效。用户只能在拥有一个角色的所有权限，且与该角色的生效范围一致的前提下，才能对角色进行创建和更新。例如用户 user-1 没有列出集群中所有 secret 的权限，就不能创建具有这一权限的集群角色。要让一个用户能够创建或更新角色，需要以下权限：#1.为其授予一个允许创建/更新 Role 或 ClusterRole 资源对象的角色；为用户授予角色，要覆盖该用户所能控制的所有权限范围。用户如果尝试创建超出  其自身权限的角色或者集群角色，则该 API 调用会被禁止。如果一个用户的权限包含了一个角色的所有权限，那么就可以为其创建和更新角色绑  定；或者如果被授予了针对某个角色的绑定授权，则也有权完成此操作。例如：user1 没有列出集群内所有 secret 的权限，就无法为一个具有这样权限的角色创建集群角色绑定。要使用户能够创建、更新这一角色绑定，则需要有如下做法：#1.为其授予一个允许创建和更新角色绑定或者集群角色绑定的角色 为其授予绑定某一角色的权限，有隐式或显式两种方法1）隐式：让其具有所有该角色的权限2）显式：让用户授予针对该角色或集群角色绑定操作的权限让 user-1 有对 user-1-namespace 命名空间中的其他用户授予 admin、edit 及 view 角色

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: role-grantor rules:
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["rolebindings"]
  verbs: ["create"]
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["clusterroles"]
  verbs: ["bind"]
  resourceNames: ["admin", "edit", "view"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: role-grantor-binding
  namespace: user-1-namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: role-grantor
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: user-1

在进行第一个角色和角色绑定时，必须让初始用户具备其尚未被授予的权限，要进行初始的角色和角色绑定设置，有以下两种方法：

#1.使用属于 system:masters 组的身份，这一群组默认具有 cluster-admin 这一超级角色的绑定。
#2.如果 API Server 以--insecure-port 参数运行，则客户端通过这个非安全端口进行接口调用，这一端口没有认证鉴权的限制。

标签：kubernetes,角色,核心技术,第二十章,rbac,io,k8s,authorization,name
来源： https://www.cnblogs.com/jhno1/p/15607638.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9