kubernets集群的安全防护(下)

一   集群角色以及集群角色绑定

　　

　　1.1  前面我们提到过角色以及角色绑定，那么现在为什么会出现集群级别的角色以及角色绑定，作用有如下所示

• • 我们如果需要在所有的命名的空间创建某个角色或者角色绑定的时候，按照目前已经学习的方法只能将现有的命名空间里一个一个的去创建，并且这种办法只能创建已经存在的命名空间，对于那些即将创建的命名空间也还需要等待创建完成之后在去创建角色以及角色绑定
  • API服务器存储的有2类URL，第一类是资源类型的URL，另一种是非资源性的URL
  • 利用角色，以及角色绑定需要明确指出需要访问的集群资源的名称service等是无法访问到非资源形URL
  • 再有一点，如果命名空间想要访问集群级别的资源，也只能通过绑定集群角色来访问

　　　　

　　1.2  让某个命名空间的pod访问集群级别的资源

k create clusterrole pv-reader --verb=get,list --resource=persistentvolumes

　　

　　1.3  它的yaml形式如下所示

[root@node01 Chapter12]# k get clusterrole pv-reader -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pv-reader
rules:
- apiGroups:
  - ""
  resources:
  - persistentvolumes
  verbs:
  - list
  - get

　

　　1.4 此时来通过wdm的pod来访问集群级别的资源persistentvolumes，结果如下所示

/ # curl localhost:8001/api/v1/persistentvolumes
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {

  },
  "status": "Failure",
  "message": "persistentvolumes is forbidden: User \"system:serviceaccount:wdm:default\" cannot list resource \"persistentvolumes\" in API group \"\" at the cluster scope",
  "reason": "Forbidden",
  "details": {
    "kind": "persistentvolumes"
  },
  "code": 403

　　

　　1.5 现在我们将这个集群资源绑定到wdm这个命名空间的SA上面去,执行的命令如下所示

k create rolebinding pv-test --cluster-role=pv-reader --serviceaccount=wdm:default 

　　1.6 之后继续进入wdm命名空间所在的pod来访问集群资源persistentvolumes

/ # curl localhost:8001/api/v1/persistentvolumes
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {

  },
  "status": "Failure",
  "message": "persistentvolumes is forbidden: User \"system:serviceaccount:wdm:default\" cannot list resource \"persistentvolumes\" in API group \"\" at the cluster scope",
  "reason": "Forbidden",
  "details": {
    "kind": "persistentvolumes"
  },
  "code": 403

• 很是奇怪，明明创建了rolebinding并将其具有访问集群资源persistentvolumes的clusterrole，但是还是访问失败
• 说明虽然rolebinding能够将clusterrole绑定到命名空间role上面，但是却无法对集群资源进行访问

　　

　　1.7 创建一个clusterrolebinding来与clusterrole进行相关绑定

k create clusterrolebinding pv-test --clusterrole=pv-reader --serviceaccount=wdm:default

　　1.8 之后在wdm的命名空间里面pod访问集群资源

/ # curl localhost:8001/api/v1/persistentvolumes
{
  "kind": "PersistentVolumeList",
  "apiVersion": "v1",
  "metadata": {
    "selfLink": "/api/v1/persistentvolumes",
    "resourceVersion": "3570872"
  },
  "items": [
    {
      "metadata": {
        "name": "pv-a",
        "selfLink": "/api/v1/persistentvolumes/pv-a",
        "uid": "17346ca6-53e0-11eb-ae9a-5254002a5691",
        "resourceVersion": "3033946",
        "creationTimestamp": "2021-01-11T07:39:09Z",
        "labels": {
          "type": "local"
        },
　　　　......

• 可以看到已经成功的查询到了集群级别的信息PV
• 综上所叙，即使给role绑定了集群级别的资源，也无法去访问集群级别的资源
• 集群级别的资源只能通过clusterrolebinding来关联到某个命名空间的pod才能进行访问

　　1.9  对于非资源类型的URL，集群给其system:discovery的clusterrole,并且将其绑定到了未被认证和已经被认证的组了，即集群内部的任何pod都可以对其进行访问

　　1.10  集群中也有些clusterrolebinding不仅仅可以与clusterrole进行绑定，同时也可以与role进行绑定,其中有一个名字为view的clusterrole，里面包含了集群内部所有的命名空间的资源相关信息，所有它会具有以下2个特点

• 当它与集群角色绑定进行绑定的时候，那么集群绑定下面的账户就拥有访问这个集群的权限
• 当它与某个命名空间里面的角色绑定的时候进行绑定，那么角色绑定下面的用户或组或serviceaccount则可以访问这个命名空间的资源

总结角色，角色绑定，集群角色，集群角色绑定的一些规律如下图所示：

　　1.11 介绍集群默认的clusterrolebinding

• • admin的clusterrole允许访问某个命名空间的所有资源(除了role，以及rolebinding)
  • cluster-admin允许访问整个集群的所有资源