文章目录

  • 前言
  • 一、RBAC API 对象
  • 二、创建一个只能访问某个namespace的用户
  • 第一步：创建用户凭证
  • 第二步：创建角色
  • 第三步：用户和角色绑定


前言

RBAC 使用rbac.authorization.k8s.io API Group 来实现授权决策，允许管理员通过 Kubernetes API 动态配置策略，要启动RBAC，需要在 apiserver 中添加参数 --authorization - mode - RBAC，如果使用 kubeadm 安装的集群，1.6版本以上都默认开启了 RBAC， 可以通过查看Master 节点上apiserver 的静态 Pod 定义文件：

$ cat /etc/kubernetes/manifests/kube-apiserver.yaml 
...
    - --authorization-mode=Node,RBAC
...

如果是二进制的方式单间的集群，添加这个参数后，记得要重启apiserver。

一、RBAC API 对象

Kubernetes有一个很基本的特征就是它的所有资源对象都是模型化的API 对象，允许执行CRUD 操作比如下面的资源：

  • Pods
  • ConfigMaps
  • Deployments
  • Nodes
  • Secrets
  • Namespaces

上面的资源可能存在的操作有：

  • create
  • get
  • delete
  • list
  • update
  • edit
  • watch
  • exec

在更上层，这些资源和 API Group 进行关联，比如 Pods 属于 Core API Group ，而 Deployments 属于 apps API Group ，要在 Kubernetes 中进行 RBAC 管理，除了上面的这些资源和操作以外，我们还需要另外的一些对象：

  • Rule：规则，规则是一组属于不同 API Group，而 Deployments 属于 apps API Group ，要在 Kubernetes 中进行 RBAC 管理，除了上面的这些资源和操作以外，我们还需要一些其他的对象：
  • Role和ClusterRole ：角色和集群角色，这两个对象都包含上面的Rules 元素，二者的区别在于，Role属于单个命名空间的，和namespace 关联的，而ClusterRole 是集群内的，因此定义的规则不受命名空间的约束。Role和ClusterRole在 Kubernetes 中都被定义为集群内部的 API 资源。所以都可以用kubectl 相关命令来操作
  • Subject ：主题，对应在集群中常识操作的对象，集群中定义了3中类型的主题资源：
  1. User Account ：用户，这是有外部独立服务进行管理的，管理员进行撕咬的分配，用户可以使用 KeyStone 或者 Goole 账号，甚至一个用户名和密码的文件列表也可以，对于用户的管理集群内部没有一个关联的资源对象，所以用户不能通过集群内部的API 进行管理
  2. Group ：组，这是用来关联多个账户的，集群中有一些默认创建的组，比如 cluster-admin
  3. Service Account ： 服务账号，通过 Kubernetes API 来管理的一些用户账号，和namespace 进行关联的，适用于集群内部运行的应用程序，需要通过 API 来完成权限认证，所在集群内部进行权限操作，我们都需要适用到Service Account 。
  • Rolebinding 和ClusterRolebinding：角色绑定和集群角色绑定，简单来说就是吧生命的 Subject 和我们的 Role 进行绑定的过程（给某个用户绑定上操作的权限）。二者的区别是作用范围：Rolebinding只会影响该命名空间下的资源操作权限，而ClusterRolebinding会影响到所有的namespace。

二、创建一个只能访问某个namespace的用户

我们创建一个 UserAccount ，只能访问default 命名空间：

  • username：admin
  • group : example

第一步：创建用户凭证

Kubernetes 没有 User Account 的API 对象，不过要创建一个用户账号的话也是挺简单的，利用管理员分配给你一个私钥就可以创建了，这个我们可以参考官方文档中的方法，这里我们来使用 OpenSSL 证书来创建一个User ，当然我们也可以使用更简单的 cfssl工具来创建：

  • 给用户admin 创建一个私钥，命名成为： admin.key：
$ openssl genrsa -out admin.key 2048
  • 使用我们刚刚创建的一个证书签名请求文件：admin.csr，需要注意确保在 -subj 参数中指定用户名和组（CN表示用户名，O表示组）：
$ openssl req -new -key haimaxy.key -out haimaxy.csr -subj "/CN=admin/O=example"
  • 然后找到我们Kubernetes 集群的 CA ，我们使用的是kubeadm 安装的集群， CA 相关证书位于 /etc/kubernetes/pki/ 目录下面，如果你是二进制搭建的，你应该在最开始搭建集群的时候就已经指定好了 CA 的目录，我们会利用该目录下面的 ca.crt 和 ca.key 两个文件来批准上面的证书请求。
  • 生成最终的证书文件，我们这里设置证书的有效期为 500 天：
$ openssl x509 -req -in haimaxy.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out admin.crt -days 500

现在查看我们当前的文件夹下面是否生成了一个证书文件：

$ ls
haimaxy.csr admin.key admin.crt
  • 现在我们可以使用刚刚创建的证书文件和私钥文件在集群中创建新的凭证和上下文（Context）：
$ kubectl config set-credentials admin --client-certificate=admin.crt  --client-key=admin.key

我们可以看到一个用户admin 创建了，然后为这个用户设置新的 Context

$ kubectl config set-context admin-context --cluster=kubernetes --namespace=default --user=admin

我们的admin 用户就创建好了，现在我们使用当前这个配置文件来操作 kubectl 命令的时候，应该会出现错误，因为我们还没有给该用户设置任何权限

$ kubectl get pods --context=admin-context
Error from server (Forbidden): pods is forbidden: User "admin" cannot list pods in the namespace "default"

第二步：创建角色

用户创建之后，我们就需要给用户添加操作权限了，我们来定义一个 YAML 文件，创建一个允许用户操作 Deployment 、Pod 、ReplicaSet 的角色，

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: admin-role
  namespace: kube-system
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["deployments", "replicasets", "pods"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] # 也可以使用['*']

其中 Pod 属于 core 这个 API Group ，在 YAML 中用空字符就可以，而 Deployment 属于 apps 这个 API Group ，RS属于 extensions 这个API Group ，所以 rules 下面的 api Group 就综合了这几个资源的 api Group 。其中verbs就是操作权限，如果需要所有操作权限，*即可表示。
然后创建这个role

$ kubectl create -f admin-role.yaml

第三步：用户和角色绑定

Role 创建完成之后，但是俩者还没有任何关系，所以我们需要进行将他们绑定，这时候就需要创建一个Rolebinding 对象，在default 这个命名空间下，将admin-role 和用户进行绑定，

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: admin-rolebinding
  namespace: default
subjects:
- kind: User
  name: admin
  apiGroup: ""
roleRef:
  kind: Role
  name: admin-role
  apiGroup: ""

上面的YAML文件中我们看到了subjects关键字，这里就是我们上面提到的用来尝试操作集群的对象，这里对应上面的 User 帐号 admin，使用kubectl创建上面的资源对象：

$ kubectl create -f admin-rolebinding.yaml