12.2 通过基于角色的权限控制加强集群安全

除了 RBAC, 还有 ABAC, WebHook.

12.2.1 介绍 RBAC 授权插件

授权插件运行在 API 服务.

了解动作

API 服务使用 REST, 所以用 GET, POST, PUT, DELETE 等操作资源.
资源包括 Pod, Service, Secret 等. 所以动作就是 CRUD 这些资源.

了解 RBAC 插件

12.2.2 介绍 RBAC 资源

• Role
• ClusterRole
• RoleBinding
• ClusterRoleBinding

可以绑定不再命名空间下的集群角色:

开始练习

确保使用 Kubenetes 1.6 以上.

创建命名空间和运行 pod

列出 pod 中的服务

$ curl localhost:8001/api/v1/namespaces/foo/services
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {
  },
  "status": "Failure",
  "message": "services is forbidden: User \"system:serviceaccount:foo:default\" cannot list resource \"services\" in API group \"\" in the namespace \"foo\"",
  "reason": "Forbidden",
  "details": {
    "kind": "services"
  },
  "code": 403
}

12.2.3 使用 Role 和 RoleBinding

创建角色

$ kubectl create -f service-reader.yaml -n foo

也可以在命令行中创建:

$ kubectl create role service-reader --verb=get --verb=list --resource=services -n bar

绑定角色到 ServiceAccount

操作主体可以是用户, ServiceAccount, 或一个组.

$ kubectl create rolebinding test --role=service-reader --serviceaccount=foo:default -n foo

RoleBinding 的 yaml 格式:

测试:

# 进入容器内部
$ kubectl exec -it test -n foo sh

$ curl localhost:8001/api/v1/namespaces/foo/services
{
  "kind": "ServiceList",
  "apiVersion": "v1",
  "metadata": {
    "resourceVersion": "8176683"
  },
  "items": []
}

在角色绑定中使用其他命名空间的 ServiceAccount

$ kubectl edit rolebinding test -n foo

添加新项, 允许 bar 中的 pod 访问 foo 中的资源:

12.2.4 使用 ClusterRole 和 ClusterRoleBinding

有 Cluster* 的原因:

• 跨多个 namespace 的资源管理
• 对一些不表示资源的 URL 进行管理: /healthz
• 管理不在 namespace 的资源
  • Node
  • PersistentVolume
  • Namespace

ClusterRole 是一种集群级资源.

允许访问集群级别的资源

创建角色:

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

查看该角色的 yaml 格式:

在 foo 命名空间的 pod 中运行:

创建 RoleBinding:

$ kubectl create rolebinding pv-test --clusterrole=pv-reader --serviceaccount=foo:default -n foo

查看 RoleBinding 的 yaml 格式:

用 RoleBinding 绑定 ClusterRole 是无法访问集群级资源的:

清理之前的 RoleBinding:

$ kubectl delete rolebinding pv-test

创建 ClusterRoleBinding:

$ kubectl create clusterrolebinding pv-test --clusterrole=pv-reader --serviceaccount=foo:default

允许访问非资源型的 URL

查看 system:discovery ClusterRole:

查看 system:discovery ClusterRoleBinding:

使用 ClusterRole 来授权访问指定命名空间中的资源

查看自有的 view ClusterRole:

绑定 view:

$ kubectl create clusterrolebinding view-test --clusterrole=view --serviceaccount=foo:default

可以访问指定命名空间中的 pod:

使用命名空间中的 RoleBinding:

$ kubectl create rolebinding view-test --clusterrole=view --serviceaccount=foo:default -n foo

总结 Role, ClusterRole, RoleBinding 和 ClusterRoleBinding 的组合

理解上表的关键点在于 “重用”:

• 注意表中括号中的文字

12.2.5 了解默认的 ClusterRole 和 ClusterRoleBinding

查看 kubernetes 自动创建的 ClusterRole 和 ClusterRoleBinding:

$ kubectl get clusterrolebindings
$ kubectl get clusterroles

• 用 view ClusterRole 允许对资源的只读访问
• 用 edit ClusterRole 允许对资源的修改
• 用 admin ClusterRole 赋予一个命名空间全部的控制权
• 用 cluster-admin ClusterRole 得到完全的控制权

12.2.6 理性地授予授权权限

• 为每个 pod 创建特定的 ServiceAccount
• 假设你的应用会被入侵