美文网首页云原生
十二 K8S细粒度权限控制

十二 K8S细粒度权限控制

作者: 負笈在线 | 来源:发表于2022-05-18 15:05 被阅读0次

    (一) RBAC

    一个K8S集群并不只有管理员在使用,如果是一个开发或者一个测试,就不能有太高的权限,预防出错。 此时就要通过K8S一个机制RBAC对权限经行细粒度划分,例如张三,可设置只能在namespaceA进行操作,不能在其他命名空间操作。
    官网:https://kubernetes.io/zh/docs/reference/access-authn-authz/rbac/


    1.4种资源

    ClusterRole:可以配置一些权限,允许对整个集群做你想做的
    ClusterRoleBinding:可以把ClusterRole配置的权限,授权给指定的“人”,让他可以对整个集群做他想做的
    Role:只能允许对该Namespace做你想做的
    RoleBinding:只能让指定的“人”对该Namespace做他想做的
    Role和ClusterRole

    kind: Role
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      namespace: default
      name: pod-reader
    rules:
    - apiGroups: [""] # "" indicates the core API group
      resources: ["pods"]
      verbs: ["get", "watch", "list"]
    
    备注
    kind:定义资源类型为Role
    API Version:定义该资源的API版本,建议使用v1版本,因为其它版本如beta版本在Kubernetes1.22+将被彻底启用
    metadata:元数据定义
    namespace:因为Role是作用单个Namespace下的,具有命名空间隔离,所以需要制定Namespace,不指定则为default
    name:Role的名称
    rules:定义具体的权限,切片类型,可以配置多个
    API Groups:包含该资源的apiGroup名称,比如extension
    resources:定义对哪些资源进行授权,切片类型,可以定义多个,比如pods、service等
    verbs:定义可以执行的操作,切片类型,可以定义多个,比如create、delete、list、get、watch、deletecollection等
    

    RoleBinding和ClusterRoleBinding

    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: read-pods
      namespace: default
    subjects:
    - kind: User
      name: jane # Name is case sensitive
      apiGroup: rbac.authorization.k8s.io
    roleRef:
      kind: Role
      name: pod-reader
      apiGroup: rbac.authorization.k8s.io
    
    roleRef:绑定的类别
    kind:指定权限来源,可以是Role或ClusterRole
    name:Role或ClusterRole的名字
    apiGroup:API 组名
    subjects:配置被绑定对象,可以配置多个
    kind:绑定对象的类别,当前为User,还可以是Group、ServiceAccount
    name:绑定对象名称
    

    2.Role和RoleBinding的使用

    Role示例:允许读取在API 组下的 “Pods”:

    rules:
    - apiGroups: [""]
      # 在 HTTP 层面,用来访问 Pod 的资源的名称为 "pods"
      resources: ["pods"]
      verbs: ["get", "list", "watch"]
    

    允许读/写在 “extensions” 和 “apps” API 组中的 Deployment(在 HTTP 层面,对应 URL 中资源部分为 “deployments”):

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

    允许读取核心 API 组中的 “pods” 和读/写 “batch” 或 “extensions” API 组中的 “jobs”:

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

    对于名称为 alice@example.com 的用户:

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

    对于名称为 frontend-admins 的用户组:

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

    RoleBinding示例:对于名称为 alice@example.com 的用户:

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

    对于任何名称空间中的 “qa” 组中所有的服务账户:

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

    对于所有已经过认证的用户:

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

    对于所有用户:

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

    3.ClusterRole和ClusterRoleBinding的使用

    默认 ClusterRole和默认 ClusterRoleBinding 一些默认的 ClusterRole 不是以前缀 system: 开头的。这些是面向用户的角色。 它们包括超级用户(Super-User)角色(cluster-admin)、 使用 ClusterRoleBinding 在集群范围内完成授权的角色(cluster-status)、 以及使用 RoleBinding 在特定名字空间中授予的角色(admin、edit、view)。 面向用户的 ClusterRole 使用 ClusterRole 聚合以允许管理员在 这些 ClusterRole 上添加用于定制资源的规则。如果想要添加规则到 admin、edit 或者 view, 可以创建带有以下一个或多个标签的 ClusterRole:


    4.聚合ClusterRole

    假设有2个ClusterRole,ClusterRoleA和ClusterRoleB,ClusterRoleA设置了rule并打上了标签,ClusterRoleB就可以引用A的标签,ClusterRoleB就会自动补上ClusterRoleA的rule.

    kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
    name: monitoring
    aggregationRule:
    clusterRoleSelectors:
    - matchLabels:
    rbac.example.com/aggregate-to-monitoring: "true"
    rules: []
    
    kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
    name: monitoring-endpoints
    labels:
    rbac.example.com/aggregate-to-monitoring: "true"  #打上标签
    # These rules will be added to the "monitoring" role.
    rules:
    - apiGroups: [""]
    resources: ["services", "endpoints", "pods"]
    verbs: ["get", "list", "watch"]
    

    示例:

    [root@k8s-master01 ~]# vim a-ClusterRole.yaml
    kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: test-aggregation
    aggregationRule:
      clusterRoleSelectors:
      - matchLabels:
          rbac.example.com/aggregate-to-test-aggregation: "true"
    rules: []
    
    [root@k8s-master01 ~]# kubectl create -f a-ClusterRole.yaml
    [root@k8s-master01 ~]# kubectl get -f a-ClusterRole.yaml -oyaml | grep rule -A 3 #创建查看a-ClusterRole,发现rule是空
          f:rules: {}
        manager: kubectl-create
        operation: Update
        time: "2021-12-04T09:29:51Z"
    --
    rules: null
    

    验证:创建sa,并查看sa创建的secret,获得token

    [root@k8s-master01 ~]# kubectl create sa test-aggregation
    serviceaccount/test-aggregation created
    
    [root@k8s-master01 ~]# kubectl get secret
    NAME                           TYPE                                  DATA   AGE
    default-token-c5kj5            kubernetes.io/service-account-token   3      12d
    test-aggregation-token-l6v25   kubernetes.io/service-account-token   3      3s
    
    [root@k8s-master01 ~]# kubectl describe secret test-aggregation-token-l6v25   #查看toekn
    ...
    Data
    ====
    ca.crt:     1066 bytes
    namespace:  7 bytes
    token:      eyJhbGciOiJSUzI1NiIsImtpZCI6IlVrWjJjSlVHM09qU1laUnJpM1ZJZEVONDF3M1hRRzVkNFRKdTFjTEZXODQifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6InRlc3QtYWdncmVnYXRpb24tdG9rZW4tbDZ2MjUiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoidGVzdC1hZ2dyZWdhdGlvbiIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6ImJiMTUwYjcwLWI2NGUtNDcxYy1hMzhiLWNiYzExYWY5NjZkYyIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OnRlc3QtYWdncmVnYXRpb24ifQ.Yl92rD0KHkwSLg-Oq8meSAnVeXdHkcOjBprURSj1UFDRzj1KpBqaoPNO0zTao0FIFni2hAKxg-pG6lzPXdO2bCBRxB8rha41JYqmIEvU7UvgQXxXGr6my80f5lZHo4_AD9y0O5pJAqio4fwOqOgIk8jP7zG7me9VZNbn4ygt2mi2fSYkcNxmb2-Zj7_jzBndYP_VfgtFesaX0GHWmMeN_agsGtYlyf7cBNBebGhmmFBSx-VR-tWUhi_L6ArCC6dFKm1vcYFmDaVZQ3CZ2-Df21J0UYLwjG0tzJEk8oLD638PRTtvHCSExacbeatfO5ivoNf1_XRSEik7Tu5I9rOoaADf21J0UYLwjG0tzJEk8oLD638PRTtvHCSExacbeatfO5ivoNf1_XRSEik7Tu5I9rOoaA
    

    创建一个名称叫test-aggregation的clusterrolebinding,把clusterrole:test-aggregation授权给SA:default命名空间下 的test-aggregation

    [root@k8s-master01 ~]# kubectl create clusterrolebinding test-aggregation --clusterrole=test-aggregation  --serviceaccount=default:test-aggregation
    clusterrolebinding.rbac.authorization.k8s.io/test-aggregation created
    

    登录测试,发现并没有权限,只能登录



    创建b-ClusterRole,使其聚合a-ClusterRole

    [root@k8s-master01 ~]# vim b-ClusterRole.yaml
    kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: b-aggregation
      labels:
        rbac.example.com/aggregate-to-test-aggregation: "true"   #标签,使其和a-ClusterRole一直才能聚合
    # These rules will be added to the "monitoring" role.
    rules:
    - apiGroups: [""]
      resources: ["services", "endpoints", "pods","namespaces"]  #分配权限,加上命名空间svc等权限
      verbs: ["get", "list", "watch"]
    
    [root@k8s-master01 ~]# kubectl create -f b-ClusterRole.yaml   #
    clusterrole.rbac.authorization.k8s.io/b-aggregation created
    

    再次验证,发现可以查看命名空间和svc等监控


    (二) RBAC实践**

    问题:
    1.创建一个名为deployment-clusterrole的clusterrole
    a)该clusterrole只允许创建Deployment、Daemonset、Statefulset的create操作
    2.在名字为app-team1的namespace下创建一个名为cicd-token的serviceAccount,并且将上一步创建clusterrole的权限绑定到该serviceAccount
    实操:
    创建namespace和serviceAccount

    [root@k8s-master01 ~]# kubectl create ns app-team1
    namespace/app-team1 created
    [root@k8s-master01 ~]# kubectl create sa cicd-token -n app-team1
    serviceaccount/cicd-token created
    

    创建名为deployment-clusterrole的clusterrole

    [root@k8s-master01 ~]# vim dp-clusterrole.yaml
    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
     # "namespace" omitted since ClusterRoles are not namespaced
     name: deployment-clusterrole
    rules:
    - apiGroups: ["extensions", "apps"]
     # 1.17以前要用extensions
     # at the HTTP level, the name of the resource for accessing Secret
     # objects is "secrets"
     resources: ["deployments","statefulsets","daemonsets"]
     verbs: ["create"]
     # 赋予"deployments","statefulsets","daemonsets"的创建权限
    [root@k8s-master01 ~]# kubectl create -f dp-clusterrole.yaml
    [root@k8s-master01 ~]# kubectl get clusterrole deployment-clusterrole -oyaml | grep rule -A 7 #查看
    ...
    rules:
    - apiGroups:
     - extensions
     - apps
     resources:
     - deployments
     - statefulsets
     - daemonsets
    

    绑定权限并查看

    [root@k8s-master01 ~]# kubectl create rolebinding deployment-rolebinding --clusterrole=deployment-clusterrole --serviceaccount=app-team1:cicd-token -n app-team1
    [root@k8s-master01 ~]# kubectl get rolebindings.rbac.authorization.k8s.io -n app-team1 -oyaml #查看
    

    编辑一份deployment模板

    [root@k8s-master01 ~]# cat deployment-cicd-token.yaml 
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx
      namespace: app-team1
    spec:
      progressDeadlineSeconds: 600
      replicas: 1
      revisionHistoryLimit: 10
      selector:
        matchLabels:
          app: nginx
      strategy:
        rollingUpdate:
          maxSurge: 25%
          maxUnavailable: 25%
        type: RollingUpdate
      template:
        metadata:
          creationTimestamp: null
          labels:
            app: nginx
        spec:
          containers:
          - image: nginx
            imagePullPolicy: Always
            name: nginx
            resources: {}
            terminationMessagePath: /dev/termination-log
            terminationMessagePolicy: File
          - image: redis
            imagePullPolicy: Always
            name: redis
          restartPolicy: Always
    

    验证:通过sa创建的secret的token登录dashboard,选择右上+,选择app-team1参试创建yaml,发下最终有权限创建。

    [root@k8s-master01 ~]# kubectl get secrets -n app-team1  #查看secrets名称
    NAME                     TYPE                                  DATA   AGE
    cicd-token-token-kmtcd   kubernetes.io/service-account-token   3      34m
    default-token-sqnjn      kubernetes.io/service-account-token   3      35m
    
    [root@k8s-master01 ~]# kubectl describe secrets cicd-token-token-kmtcd -n app-team1  #查看token
    ...
    Data
    ====
    ca.crt:     1066 bytes
    namespace:  9 bytes
    token:      eyJhbGciOiJSUzI1NiIsImtpZCI6IlVrWjJjSlVHM09qU1laUnJpM1ZJZEVONDF3M1hRRzVkNFRKdTFjTEZXODQifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJhcHAtdGVhbTEiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlY3JldC5uYW1lIjoiY2ljZC10b2tlbi10b2tlbi1rbXRjZCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJjaWNkLXRva2VuIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQudWlkIjoiOWEzMDg0MjQtZWQ2OS00MjkwLWI4MjEtY2I5YzJlODQxN2Q4Iiwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50OmFwcC10ZWFtMTpjaWNkLXRva2VuIn0.hVYAuxRu_LZkbiDCp0Fw_J8_2DpEGD2Veh9dqG9hjhHBmItEcjU2WhKfy-9iQsyD-xunBmwf4cxZEkBp3k3_r4pgoancg5Yu-rTkgnsoTqZhKB36CDwq_W1P9ZHlQ9Qj2sh3Uf2VJx9B_5CWCqKfFyONKab8AYqhdeyj7GqgZmsVU1GBULpYmGkx9GbSd5wssuCy2UG7xwV3mRdAa6QKgx5tywx7cqtKGeWn-E2IoG4VdtgMzt-MmEtUMmurgCsK4lGuaDlK3Je2nGTAAl8uHK6SUspvhQG0m4fgLrpvtIuYFXlfnWFdINZqMcY3X3mu9Y794iaUMUz4a6iKljfcdw
    

    通过token登录dashboard



    最后查看deployment,已创建

    [root@k8s-master01 ~]# kubectl get deployments.apps -n app-team1 -owide  
    NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
    nginx 0/1 0 0 2m35s nginx,redis nginx,redis app=nginx
    

    (****三) RBAC企业实战

    企业中的权限划分:




    如上三图,我们可以用RBAC进行权限控制,但是在企业中有很多需求场景。 正常授权,配置会非常多,这边可以把通用的权限单独给一个ClusterRole,然后再对每个用户授权(上图二) 我们可以建立单独的命名空间,把SA用户专门放入里面,通用权限可以通过ClusterRoleBinding给此命名空间授权,然后此命名空间所有用户就有了通用的权限,部分单独的权限给单独的用户授权。
    示例需求: 1.用户dotbalo可以查看default、kube-system下Pod的日志 2.用户dukuan可以在default下的Pod中执行命令,并且可以删除Pod
    解答: 1.创建管理用户的命名空间kube-users
    [root@k8s-master01 ~]# kubectl create ns kube-users
    namespace/kube-users created
    

    2.根据需求先创建2个用户dotbalo,dukuan(sa,通过Sa创建的secret的token管理节点)

    [root@k8s-master01 ~]# kubectl create sa dotablo -n kube-users
    serviceaccount/dotablo created
    [root@k8s-master01 ~]# kubectl create sa dukuan -n kube-users
    serviceaccount/dukuan created
    

    3.根据需求总共有4中权限分别是只读命名空间,删除日志,执行pod命名,查看日志,然后创建4种权限的ClusterRole

    [root@k8s-master01 ~]# vim namespace-readonly.yaml   #只读查看命名空间权限
    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: namespace-readonly
    rules:
    - apiGroups:
      - ""
      resources:
      - namespaces
      verbs:
      - get
      - list
      - watch
    - apiGroups:
      - metrics.k8s.io
      resources:
      - pods
      verbs:
      - get
      - list
      - watch
    
    [root@k8s-master01 ~]# vim delete-pod.yaml   #删除pod的权限
    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: pod-delete
    rules:
    - apiGroups:
      - ""
      resources:
      - pods
      verbs:
      - get
      - list
      - delete
    
    [root@k8s-master01 ~]# vim exec-pod.yaml  #执行Pod的权限
    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: pod-exec
    rules:
    - apiGroups:
      - ""
      resources:
      - pods
      verbs:
      - get
      - list
    - apiGroups:
      - ""
      resources:
      - pods/exec
      verbs:
      - create
    
    [root@k8s-master01 ~]# vim log-pod.yaml   #查看log日志的权限
    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: pod-log
    rules:
    - apiGroups:
      - ""
      resources:
      - pods
      - pods/log
      verbs:
      - get
      - list
      - watch
    
    [root@k8s-master01 ~]# kubectl create -f namespace-readonly.yaml   #创建4种ClusterRole
    clusterrole.rbac.authorization.k8s.io/namespace-readonly created
    [root@k8s-master01 ~]# kubectl create -f delete-pod.yaml 
    clusterrole.rbac.authorization.k8s.io/pod-delete created
    [root@k8s-master01 ~]# kubectl create -f log-pod.yaml 
    clusterrole.rbac.authorization.k8s.io/pod-log created
    [root@k8s-master01 ~]# kubectl create -f exec-pod.yaml 
    clusterrole.rbac.authorization.k8s.io/pod-exec created
    

    4.绑定全局命名空间查看权限(clusterrolebinding)

    # kubectl create clusterrolebinding namespace-readonly --clusterrole=namespace-readonly --serviceaccount=system:serviceaccounts:kube-users
    

    5.绑定用户dotbalo两个命名空间default、kube-system的查看pod日志的权限(rolebinding)

    # kubectl create rolebinding dotbalo-pod-log \
    --clusterrole=pod-log --serviceaccount=kube-users:dotbalo --namespace=kube-system
    # kubectl create rolebinding dotbalo-pod-log \
    --clusterrole=pod-log --serviceaccount=kube-users:dotbalo --namespace=default
    

    6.绑定用户dukuan在deefault中执行pod命令权限和删除Pod权限

    # kubectl create rolebinding dukuan-pod-exec \
    --clusterrole=pod-exec --serviceaccount=kube-users:dukuan --namespace=default
    # kubectl create rolebinding dukuan-pod-delete \
    --clusterrole=pod-delete --serviceaccount=kube-users:dukuan --namespace=default
    

    (四) Kubernetes多集群图形化管理工具Ratel

    1.Kubernetes多集群图形化管理工具Ratel介绍&使用

    2.图形化管理Kubernetes多租户权限

    相关文章

      网友评论

        本文标题:十二 K8S细粒度权限控制

        本文链接:https://www.haomeiwen.com/subject/fhtuurtx.html