K8s | K8s权限控制模型 RBAC

• 很多实际的容器化工作，都会要求你设计一个自己的编排对象，实现自己的控制器模式。

• K8s 里新增和操作 API 对象，必须先了解RBAC

负责完成授权（Authorization）工作的机制，就是 RBAC
​

• 3大概念（Role + RoleBinding + ServiceAccount）

  • • 产生作用的 Namepace 是：mynamespace
      Namespace 并不会提供任何实际的隔离或者多租户能力

    • rules 字段，就是它所定义的权限规则
      在上面的例子里：允许“被作用者”，对 mynamespace 下面的 Pod 对象，进行 GET、WATCH 和 LIST 操作
      ​

  • RoleBinding

    可以指定上面Role的“被作用者”

    • “User”字段，只是一个授权系统里的逻辑概念

      大多数私有的使用环境中，我们只要使用 Kubernetes 提供的内置“用户”，就足够

      • 可以通过外部认证服务，比如 Keystone来提供keystone?

      • 也可以直接给 APIServer 指定一个用户名、密码文件

    • roleRef字段

      • 绑定我们前面定义的 Role 对象（example-role）

      • Role对权限的限制规则仅在自己的 Namespace 内有效，roleRef 也只能引用当前 Namespace 里的 Role 对象

  • Subject(User)——一般用ServiceAccount，是由 k8s负责管理的“内置用户”

    • ServiceAccount
      apiVersion: v1
      kind: ServiceAccount
      metadata:
      namespace: mynamespace
      name: example-sa

    • RoleBinding 下面的example-role在上面已经创建

    • 实践：用Pod绑定按上述步骤创建的ServiceAccount

      • Pod引用这个serviceAccount的name，创建成功后的Secret 对象（但cncamp课程演示 sa一旦被创建secrete就也一起被创建）（ServiceAccount 对应的用来跟 APIServer 进行交互的授权文件：Token）被mount到pod里面的/var/run/secret/k8s.io/sa( ，pod应用带着它访问apiserver，apiserver就知道你是谁
        Token 文件的内容一般是证书或者密码，以 Secret对象的方式保存在 Etcd

      • kubectl describe pod sa-token-test -n mynamespace 可以查看该 ServiceAccount 的 token
        eg ：被 k8s自动挂载到了容器的/var/run/secrets/kubernetes.io/serviceaccount，容器里的应用就可以使用里面的 ca.crt 来访问 APIServer 了

      • tips:

        • Pod 没有声明 serviceAccountName，Kubernetes 会自动在它的 Namespace 下创建一个名叫 default 的默认 ServiceAccount，然后分配给这个 Pod，有访问 APIServer 的绝大多数权限

        • 你可以通过describe sa default查看对应的secret对象，也可以通过kubectl describe secret default-token-s8rbq查看对应的sa对象

    • 用户组：一个 ServiceAccount，在 Kubernetes 里对应的“用户”的名字
      system:serviceaccount:<ServiceAccount 名字 >

    • 而它对应的内置“用户组”的名字
      system:serviceaccounts:<Namespace 名字 >
      name: system:serviceaccounts就意味着这个 Role 的权限规则，作用于整个系统里的所有 ServiceAccount

  • 更大的授权

    ：对于非 Namespaced（Non-namespaced）对象（比如：Node），或者某一个 Role 想要作用于所有的 Namespace 的时候，我们又该如何去做授权呢？

    • ClusterRole和ClusterRoleBinding

      用法跟 Role 和 RoleBinding 完全一样，只是没有了ns字段

      • k8s内置了很多为系统保留的 ClusterRole

        • eg ：system:kube-scheduler
          绑定给 kube-system Namesapce下名叫 kube-scheduler 的 ServiceAccount（k8s调度器的 Pod 声明使用的 ServiceAccount）

        • 1.cluster-admin；2. admin；3. edit；4. view
          务必要谨慎而小心地使用 cluster-admin（cluster-admin是最高权限（verbs=*））

    • Role 或者 ClusterRole 里，如果要赋予用户 (是User，不是ServiceAccount )example-user 所有权限，那就可以给它指定一个 verbs 字段的全集
      verbs: [“get”, “list”, “watch”, “create”, “update”, “patch”, “delete”]

  • 更细化的授权

    • 这条规则的“被作用者”，只对名叫“my-config”的 ConfigMap 对象，有进行 GET 操作的权限