Kubernetes RBAC访问控制

714浏览 Kubernetes 发表评论

RBAC 负责完成授权：基于角色的访问控制（Role-Based Access Control）

  • Role 角色，其实是一组规则，定义了一组对 Kubernetes API 对象的操作权限
    • 对象资源
      • Pod
      • Deployment
      • Service
      • ConfigMap
      • Secret
      • Node
      • Namespace
    • 操作
      • create
      • get
      • patch
      • delete
      • list
      • watch
  • Subject 被作用者
    • 开发者
    • 集群管理员
    • 系统组件进程
    • Pod 进程
  • RoleBinding 定义了“被作用者”和“角色”的绑定关系

 

Role 对象

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: mynamespace
  name: example-role
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "watch", "list"]

能产生作用的 Namespace 是 mynamespace；rules 字段定义权限规则。

 

RoleBinding 对象

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: example-rolebinding
  namespace: mynamespace
subjects:
  - kind: User
    name: example-user
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: example-role
  apiGroup: rbac.authorization.k8s.io

 

User 是一个授权系统里的逻辑概念，需要通过外部认证服务来提供；或者给 APIServer 指定一个用户名、密码文件。

roleRef 字段引用前面定义的 Role 对象，定义了“被作用者”和“角色”之间的绑定关系。

Role 和 RoleBinding 都是有命名空间的对象，它们对权限的限制规则仅在自己的命名空间中有效。

 

ClusterRole

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: example-clusterrole
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "watch", "list"]

 

没有 Namespace 字段

Kubernetes 中内置了很多个为系统保留的 ClusterRole，名字以 system: 开头。

四个预先定义好的 ClusterRole：

  1. cluster-admin（最高权限）
  2. admin
  3. edit
  4. view

 

ClusterRoleBinding

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: example-clusterrolebinding
subjects:
  - kind: User
    name: example-user
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: example-clusterrole
  apiGroup: rbac.authorization.k8s.io

 

没有 Namespace 字段

上面 ClusterRole 和 ClusterRoleBinding 的组合表示名叫 example-user 的用户，拥有对所有 Namespace 里的 Pod 进行 GET、WATCH 和 LIST 操作的权限。

所有权限：

verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

 

默认 ClusterRoleBinding

  • system:basic-user 未认证用户组（system:unauthenticated）的默认角色，不具备任何操作权限
  • cluster-admin system:masters 组默认的集群角色绑定，通过绑定之，具备集群的超级管理员权限
  • 集群系统组件都有默认 ClusterRoleBinding
    • kube-controller-manager
    • scheduler
    • kube-proxy

 

ServiceAccount “内置用户”

定义 ServiceAccount

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

 

通过编写 RoleBinding，为 ServiceAccount 分配权限

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: example-rolebinding
  namespace: mynamespace
subjects:
  - kind: ServiceAccount
    name: example-sa
    namespace: mynamespace
roleRef:
  kind: Role
  name: example-role
  apiGroup: rbac.authorization.k8s.io

 

$ kubectl get sa -n mynamespace -o yaml
- apiVersion: v1
  kind: ServiceAccount
  metadata:
    creationTimestamp: 2018-09-08T12:59:17Z
    name: example-sa
    namespace: mynamespace
    resourceVersion: "409327"
    ...
  secrets:
  - name: example-sa-token-vmfg6

Kubernetes 会为 ServiceAccount 自动创建并分配一个 Secret 对象，即这个 ServiceAccount 对应的、用来跟 API server 交互的授权文件。

 

Pod 声明使用 ServiceAccount

apiVersion: v1
kind: Pod
metadata:
  namespace: mynamespace
  name: sa-token-test
spec:
  containers:
    - name: nginx
      image: nginx:1.7.9
  serviceAccountName: example-sa

 

在 Pod 运行起来之后，ServiceAccount 的 token 会被挂载到容器的 /var/run/secrets/kubernetes.io/serviceaccount 目录下：

$ kubectl describe pod sa-token-test -n mynamespace
Name:               sa-token-test
Namespace:          mynamespace
...
Containers:
  nginx:
    ...
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from example-sa-token-vmfg6 (ro)
$ kubectl exec -it sa-token-test -n mynamespace -- /bin/bash
root@sa-token-test:/# ls /var/run/secrets/kubernetes.io/serviceaccount
ca.crt namespace  token

 

容器里的应用可以使用 ca.crt 来访问 API server。

发表评论