K8s-安全_鉴权与准入控制

K8s-安全_鉴权与准入控制

Authorization--鉴权

​ 之前认证过程，只是确认通信的双方都确认了对方是可信的， 可以相互通信。而鉴权是确定请求方有哪些资源的权限。API Server 目前支持以下几种授权策略（通过 API Server 的启动参数 “--authorization-mode” 设置）

  • 鉴权方式

    • AlwaysDeny：表示拒绝所有的请求，一般用于测试
    • AlwaysAllow：允许接收所有请求，如果集群不需要授权流程，则可以采用该策略
    • ABAC（Attribute-Based Access Control）：基于属性的访问控制，表示使用用户配置的授权规则对用户请求进行匹配和控制，有些时候需要重启集群才生效
    • Webhook：通过调用外部 REST 服务对用户进行授权
    • RBAC（Role-Based Access Control）：基于角色的访问控制，现行默认规则

  • RBAC授权模式--双向认证

​ RBAC（Role-Based Access Control）基于角色的访问控制， 在 Kubernetes 1.5 中引入，现行版本成为默认标准。相对其它访问控制方式，拥有以下优势：

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

​ 整个 RBAC 完全由几个 API 对象完成，同其它 API 对象一 样，可以用 kubectl 或 API 进行操作(语言开发操作--go，java， python)

​ 可以在运行时进行调整，无需重启 API Server

  • RBAC的API资源对象说明

​ RBAC 引入了 4 个新的顶级资源对象：Role、ClusterRole、 RoleBinding、ClusterRoleBinding，4 种对象类型均可以通过 kubectl 与 API 操作

​ 说明：角色绑定绑定集群角色--降维(降权)，如下图

​ 总结：Role CLusterRole RoleBinding CLusterRoleBinding 对应关系三种

​ User、Pod---RoleBiding Role

​ User、Pod---RoleBiding ClusterRole ---降维(降 权)

​ User、Pod---ClusterRoleBinding ClusterRole

​ 注意

​ 需要注意的是 Kubenetes 并不会提供用户管理，那么 User、 Group、ServiceAccount 指定的用户又是从哪里来的呢？ Kubenetes 组件（kubectl、kube-proxy）或是其他自定义的用户在向 CA 申请证书时，需要提供一个证书请求文件，如下，即用户是证书里读出来的，CA签发即可用

{
  "CN": "chen",    			# 用户
  "hosts": [],				# 主机范围，[]表示所有主机都可使用
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "name":[
    {
      "C": "CN"
      "ST": "ShenZhen",
      "L": "HK"
      "O": "system:master",	#组
      "OU":"System"
    }
  ]
}
#说明：API Server会把客户端证书的CN字段作为User，把names.O字段作为Group

​ kubelet 使用 TLS Bootstaping 认证时，API Server 可以使用 Bootstrap Tokens 或者 Token authentication file 验证 =token，无论哪一种，Kubernetes 都会为 token 绑定一个默认的 User 和 Group

​ Pod使用 ServiceAccount 认证时，service-account-token 中的 JWT 会保存 User 信息

​ 有了用户信息，再创建一对角色/角色绑定(集群角色/集群角色 绑定)资源对象，就可以完成权限绑定了

  • Role and ClusterRole

​ 在 RBAC API 中，Role 表示一组规则权限，权限只会增加(累 加权限)，不存在一个资源一开始就有很多权限而通过 RBAC 对其 进行减少的操作；Role 可以定义在一个 namespace 中，如果想 要跨 namespace 则可以创建 ClusterRole

​ 如何创建，基于以下模板测试

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]	# "" 表示API核心组
  resources: ["pods"]
  verbs: ["get","watch","list"]
# 注释
# API group：可使用kubectl explain Role.apiVersion查看
# resources: 操作的对象类型
# verbs：执行的动作
# [""]：默认值，核心组v1版，需和pod对应，若是deployment，则不是V1版

​ ClusterRole 具有与 Role 相同的权限角色控制能力，不同的是 ClusterRole 是集群级别的，ClusterRole 可以用于：

​ 集群级别的资源控制( 例如 node 访问权限 )

​ 非资源型 endpoints( 例如 /health 访问 )

​ 所有命名空间资源控制(例如 pods )

无需定义名字空间，如下

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata: 
  name: secret-reader	#"namespace" omitted since ClusterRoles are not namespaced
rules: 
- apiGroup: [""]
  resources: ["secrets"]
  verbs: ["get","watch","list"]

三种角色绑定如下

  • RoleBinding and ClusterRoleBinding

​ RoloBinding 可以将角色中定义的权限授予用户或用户组， RoleBinding 包含一组权限列表(subjects)，权限列表中包含有不 同形式的待授予权限资源类型(users, groups, or service accounts)；RoloBinding 同样包含对被 Bind 的 Role 引用； RoleBinding 适用于某个命名空间内授权，而 ClusterRoleBinding 适用于集群范围内的授权。将 default 命名空间的 pod-reader Role 授予 jane 用户，此 后 jane 用户在 default 命名空间中将具有 pod-reader 的权限， 如下模板所示

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
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 来对当前 namespace 内用户、用户组或 ServiceAccount 进行授权，这种 操作允许集群管理员在整个集群内定义一些通用的 ClusterRole，然后在不同的 namespace 中使用 RoleBinding 来引用

​ 注意：若想解除绑定，只需要删除建立的pod即可

​ 例如，以下 RoleBinding 引用了一个 ClusterRole，这个 ClusterRole 具有整个集群内对 secrets 的访问权限；但是其授权 用户 dave 只能访问 development 空间中的 secrets(因为 RoleBinding 定义在 development 命名空间)

# this cluster role binding allows anyone in the "manager" group to readd secrets in any namespace.
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: read-secret-global
subjects:
- kind: Group
  name: manager
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

  • 关键字说明

    • Resources：Kubernetes 集群内一些资源一般以其名称字符串来表示，这 些字符串一般会在 API 的 URL 地址中出现；同时某些资源也会包 含子资源，例如 logs 资源就属于 pods 的子资源，API 中 URL 样例如下：GET /api/v1/namespaces/{namespace}/pods/{name}/log

      如果要在 RBAC 授权模型中控制这些子资源的访问权限，可以 通过 / 分隔符来实现，以下是一个定义 pods 资源 logs 访问权限 的 Role 定义样例

      apiVersion: rbac.authorization.k8s.io/v1beta1
metadata: 
  namespece: default
  name: pod-and-pod-logs-reader
rules: 
- apiGroups: [""]
  resources: ["pods/logs"]
  verbs: ["get","list"]

    • to Subjects：RoleBinding 和 ClusterRoleBinding 可以将 Role 绑定到 Subjects；Subjects 可以是 groups、users 或者 service accounts，Subjects 中 Users 使用字符串表示，它可以是一个普通的名字字符串，如 “alice”；也可以是 email 格式的邮箱地址，如 chenxiyanglinux@163.com”；甚至是一组字符串形式的数字 ID 。但是 Users 的前缀 system: 是系统保留的，集群管理员应该确保普通用户不会使用这个前缀格式，Groups 书写格式与 Users 相同，都为一个字符串，并且没有特定的格式要求；同样 system: 前缀为系统保留

​

  • 测试：创建一个用户只能管理dev空间--实现资源分割-但目前不 做资源限制

    • 进入证书存放目录-/etc/kuberbetes/pki/目录下创建申请证 书文件

      cd /etc/kubernetes/pki/ vim devuser.csr

    • 下载证书生成工具

      wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 mv cfssl_linux-amd64 /usr/local/bin/cfssl #cfssl:基于json模板签发证书，

      wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 mv cfssljson_linux-amd64 /usr/local/bin/cfssljson

      wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 mv cfssl-certinfo_linux-amd64 /usr/local/bin/cfssl-certinfo #文件已下载，放在/usr/local/bin/目录下即可，加可执行权限即可

    • 返回/etc/kuberbetes/pki/目录下执行后续操作 执行基于ca.crt,ca.key签发证书命令

      cfssl gencert -ca=ca.crt -ca-key=ca.key - profile=kubernetes /etc/kubernetes/pki/devuser.csr | cfssljson -bare devuser

      说明：无论是kubeadm还是kubectl，要去对接apiserver，都是基于kubeconfig #kubectl之所以能够获取集群信息，是因为它拿着/root/.kube/config文件进行认证现在创建devuser用户的config文件，有固有格式

    • 设置集群参数，声明服务器地址

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

    • 生成config文件

      kubectl config set-cluster kubernetes \ --certificate-authority=ca.crt \ --embed-certs=true \ --server=${KUBE_APISERVER}

    • 设置客户端认证参数

      kubectl config set-credentials devuser \ --client-certificate=devuser.pem \ --client-key=devuser-key.pem \ --embed-certs=true \ --kubeconfig=devuser.kubeconfig

    • 设置上下文参数

      kubectl config set-context kubernetes \ --cluster=kubernetes \ --user=devuser \ --namespace=dev \ --kubeconfig=devuser.kubeconfig

    • 设置默认上下文，用户切换下上下文，能够读到

      kubectl config use-context kubernetes -- kubeconfig=devuser.kubeconfig

    • 创建名字空间--dev

      kubectl create ns dev && kubectl get namespaces

    • 权限绑定，管理员在操作系统装完就有的

    • 复制文件，先将系统之前的config移出来备份再做以下操作

      很明显，此时已经不能获取default名字空间内容--权限不够

    • 为了方便测试，我们可以创建linux系统用户dev进行测试(先将文件还原回去)

      还原文件回去便能正常查看default资源

    • 创建系统用户来做以上操作

    • xshell远程登录，使用devuser用户登录192.168.10.10服务器，执行下列操作

      cd /home/devuser && cp -a /etc/kubernetes/pki/devuser.kubeconfig .kube/config #服务器端执行

      chown devuser.devuser -R .kube #服务器端执行

      kubectl get pod #客户端执行

      kubectl gte pod -n default #对比查看显示效果

    • 创建pod测试

      kubectl create deployment myapp -- image=chenxiyanglinux/myapp:v1

      kubectl get pod

      kubectl create svc clusterip myapp --tcp=80:80 kubectl get svc

      能够正常创建pod，svc

    • 服务器端操作，查看dev的名字空间是否和dev用户创建的一致

      kubectl get pod --all-namespaces

      结论：两端pod数据一致，证明用户可用dev下资源，后续我们在 对devuser用户对dev名字空间的资源限制做一定操作

准入控制

​ 准入控制是API Server的插件集合，通过添加不同的插件，实现额外的准入控制规则。甚至于API Server的一些主要的功能都需要通过 Admission Controllers 实现，比如 ServiceAccount

​ 官方文档上有一份针对不同版本的准入控制器推荐列表，其中最新的 1.14 的推荐列表是

​ NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass, DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota

列举几个插件的功能

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

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

​ ServiceAccount：实现了自动化添加 ServiceAccount

​ ResourceQuota：确保请求的资源不会超过资源的 ResourceQuota 限制

posted @ 2022-07-27 16:54  Sunset_cloud  阅读(109)  评论(0)  编辑  收藏  举报