• Kubernetes中的RBAC 支持
    • 前言
    • RBAC vs ABAC
    • 基础概念
    • Kubernetes中的RBAC
    • 参考

    Kubernetes中的RBAC 支持

    在Kubernetes1.6版本中新增角色访问控制机制（Role-Based Access，RBAC）让集群管理员可以针对特定使用者或服务账号的角色，进行更精确的资源访问控制。在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。

    前言

    本文翻译自RBAC Support in Kubernetes，转载自kubernetes中文社区，译者催总，Jimmy Song做了稍许修改。该文章是5天内了解Kubernetes1.6新特性的系列文章之一。

    One of the highlights of the Kubernetes 1.6中的一个亮点时RBAC访问控制机制升级到了beta版本。RBAC，基于角色的访问控制机制，是用来管理kubernetes集群中资源访问权限的机制。使用RBAC可以很方便的更新访问授权策略而不用重启集群。

    本文主要关注新特性和最佳实践。

    RBAC vs ABAC

    目前kubernetes中已经有一系列l 鉴权机制。鉴权的作用是，决定一个用户是否有权使用 Kubernetes API 做某些事情。它除了会影响 kubectl 等组件之外，还会对一些运行在集群内部并对集群进行操作的软件产生作用，例如使用了 Kubernetes 插件的 Jenkins，或者是利用 Kubernetes API 进行软件部署的 Helm。ABAC 和 RBAC 都能够对访问策略进行配置。

    ABAC（Attribute Based Access Control）本来是不错的概念，但是在 Kubernetes 中的实现比较难于管理和理解，而且需要对 Master 所在节点的 SSH 和文件系统权限，而且要使得对授权的变更成功生效，还需要重新启动 API Server。

    而 RBAC 的授权策略可以利用 kubectl 或者 Kubernetes API 直接进行配置。RBAC 可以授权给用户，让用户有权进行授权管理，这样就可以无需接触节点，直接进行授权管理。RBAC 在 Kubernetes 中被映射为 API 资源和操作。

    因为 Kubernetes 社区的投入和偏好，相对于 ABAC 而言，RBAC 是更好的选择。

    基础概念

    需要理解 RBAC 一些基础的概念和思路，RBAC 是让用户能够访问 Kubernetes API 资源的授权方式。

    RBAC架构图1

    在 RBAC 中定义了两个对象，用于描述在用户和资源之间的连接权限。

    role

    角色是一系列权限的集合，例如一个角色可以包含读取 Pod 的权限和列出 Pod 的权限， ClusterRole 跟 Role 类似，但是可以在集群中到处使用（ Role 是 namespace 一级的）。

    role binding

    RoleBinding 把角色映射到用户，从而让这些用户继承角色在 namespace 中的权限。ClusterRoleBinding 让用户继承 ClusterRole 在整个集群中的权限。

    RBAC架构图2

    另外还要考虑cluster roles和cluster role binding。cluster role和cluster role binding方法跟role和role binding一样，出了它们有更广的scope。详细差别请访问 role binding与clsuter role binding.

    Kubernetes中的RBAC

    RBAC 现在被 Kubernetes 深度集成，并使用他给系统组件进行授权。System Roles 一般具有前缀system:，很容易识别：

    1. $ kubectl get clusterroles --namespace=kube-system
    2. NAME                                           AGE
    3. admin                                          10d
    4. cluster-admin                                  10d
    5. edit                                           10d
    6. system:auth-delegator                          10d
    7. system:basic-user                              10d
    8. system:controller:attachdetach-controller      10d
    9. system:controller:certificate-controller       10d
    10. system:controller:cronjob-controller           10d
    11. system:controller:daemon-set-controller        10d
    12. system:controller:deployment-controller        10d
    13. system:controller:disruption-controller        10d
    14. system:controller:endpoint-controller          10d
    15. system:controller:generic-garbage-collector    10d
    16. system:controller:horizontal-pod-autoscaler    10d
    17. system:controller:job-controller               10d
    18. system:controller:namespace-controller         10d
    19. system:controller:node-controller              10d
    20. system:controller:persistent-volume-binder     10d
    21. system:controller:pod-garbage-collector        10d
    22. system:controller:replicaset-controller        10d
    23. system:controller:replication-controller       10d
    24. system:controller:resourcequota-controller     10d
    25. system:controller:route-controller             10d
    26. system:controller:service-account-controller   10d
    27. system:controller:service-controller           10d
    28. system:controller:statefulset-controller       10d
    29. system:controller:ttl-controller               10d
    30. system:discovery                               10d
    31. system:heapster                                10d
    32. system:kube-aggregator                         10d
    33. system:kube-controller-manager                 10d
    34. system:kube-dns                                10d
    35. system:kube-scheduler                          10d
    36. system:node                                    10d
    37. system:node-bootstrapper                       10d
    38. system:node-problem-detector                   10d
    39. system:node-proxier                            10d
    40. system:persistent-volume-provisioner           10d
    41. view                                           10d

    RBAC 系统角色已经完成足够的覆盖，让集群可以完全在 RBAC 的管理下运行。

    在 ABAC 到 RBAC 进行迁移的过程中，有些在 ABAC 集群中缺省开放的权限，在 RBAC 中会被视为不必要的授权，会对其进行降级。这种情况会影响到使用 Service Account 的负载。ABAC 配置中，从 Pod 中发出的请求会使用 Pod Token，API Server 会为其授予较高权限。例如下面的命令在 ABAC 集群中会返回 JSON 结果，而在 RBAC 的情况下则会返回错误。

    1. $ kubectl run nginx --image=nginx:latest
    2. $ kubectl exec -it $(kubectl get pods -o jsonpath='{.items[0].metadata.name}') bash
    3. $ apt-get update && apt-get install -y curl
    4. $ curl -ik \
    5.   -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \
    6.   https://kubernetes/api/v1/namespaces/default/pods

    所有在 Kubernetes 集群中运行的应用，一旦和 API Server 进行通信，都会有可能受到迁移的影响。

    要平滑的从 ABAC 升级到 RBAC，在创建 1.6 集群的时候，可以同时启用ABAC 和 RBAC。当他们同时启用的时候，对一个资源的权限请求，在任何一方获得放行都会获得批准。然而在这种配置下的权限太过粗放，很可能无法在单纯的 RBAC 环境下工作。

    目前RBAC已经足够了，ABAC可能会被弃用。在可见的未来ABAC依然会保留在kubernetes中，不过开发的重心已经转移到了RBAC。

    参考

    RBAC documentation

    Google Cloud Next talks 1

    Google Cloud Next talks 2

    在Kubernetes Pod中使用Service Account访问API Server