使用 KeyCloak 对 Kubernetes 进行统一用户管理

2019/8/2 posted in  Kubernetes

众所周知,K8s 的权限管理体系 (不熟悉的盆友可以跳转至《Kubernetes 安全机制解读》) 中,可以将 RoleBinding 绑定到 ServiceAccount、User、Group 上来实现权限分配。

其中 ServiceAccount 我们经常用到,用来限制某个 pod 的权限;对于 User 和 Group,除了一些特殊的系统 group,并没有具体的资源与之对应,这对于传统项目中的用户管理十分不友好。

上一篇文章中讲到了 OIDC 协议在 K8s 集群中如何工作,这篇文章来具体讲讲如何在 K8s 集群中进行统一用户管理。

准备工作

首先我们需要有一个 Identity Provider 来统一管理 K8s 中的用户,并且提供 OIDC 协议服务,本文采用了 KeyCloak 作为 Identity Provider。

KeyCloak 中的配置

要想实现用户管理,我们需要利用 K8s 中 group 的概念,来对一组用户分配权限,这需要利用 OIDC 协议中的 Claim 概念,来实现 K8s 中用户的分组。

Claim 是 ID Token 中携带的信息,指的是客户端请求的信息范围,如用户名、邮箱等,而这些可以进行扩展用来携带一些用户所属 group 的信息等等。

那么第一步,我们需要扩展 KeyCloak 中的 Claim,如下图:

我们在 Client 中添加了一项 “User Attribute”,并将其加入到 ID Token 中;Multivalued 必须设置为 ON,保证 "groups" Claim 的值为一个 String 数组,其中每个值代表 User 所属的一个分组,一个 User 可以同时属于多个分组,每个值之间使用逗号分隔。

第二步就是为用户设置 "groups" 属性:

一切都设置好之后,可以在 “admin” 这个用户的 ID Token 中看到其 “groups” 属性:

{
    "jti":"9259af9c-8a3d-45ff-94f6-6780f2a79580",
    "exp":1564739637,
    "nbf":0,
    "iat":1564739337,
    "iss":"https://172.16.105.1:8082/auth/realms/hdls",
    "aud":"kubernetes",
    "sub":"f846ddb1-4435-429f-9ce5-faba7a791d43",
    "typ":"ID",
    "azp":"kubernetes",
    "auth_time":0,
    "session_state":"37b1a2ca-1b3b-4c61-ae2c-f8c14818ca6e",
    "acr":"1",
    "email_verified":false,
    "groups":[
        "manager"
    ],
    "preferred_username":"admin"
}

ApiServer 的配置

ApiServer 中留了几个可配置的环境变量,用以支持 OIDC 插件,官方链接

oidc-issuer-url:OIDC Server 的 URL,只接受 https 协议。
oidc-client-id:OIDC Server 中配置的 client_id,具有唯一性。
oidc-username-claim:指明 ID Token 中用以标识用户名称的 claim。
oidc-username-prefix:用户名前缀,“-” 表示没有前缀。
oidc-groups-claim:ID Token 中可以表明用户所在 group 的 claim,要求该 claim 必须是数组形式,所以用户可以属于多个 group。
oidc-groups-prefix:group 前缀。
oidc-ca-file:Identity Provider 的 CA 证书所在路径。

本文的配置参数如下:

    - --oidc-issuer-url=https://172.16.105.1:8082/auth/realms/hdls
    - --oidc-client-id=kubernetes
    - --oidc-username-claim=preferred_username
    - --oidc-username-prefix=-
    - --oidc-groups-claim=groups
    - --oidc-ca-file=/etc/kubernetes/pki/ca.crt

KubeConfig 的配置

作为用户,我们需要通过 Client Application 来访问 API Server,kubectl 显然是首选 Client,让 kubectl 以我们创建的用户 "admin" 的身份来访问 Kubernetes,并通过身份认证,而这需要对 KubeConfig 进行配置,来完成以下几个流程:

  1. 创建一个 kubeconfig user:"admin"。
  2. 为 "admin" 配置上 client-id,client credential,id-token,refresh-token,certficaite 等等属性。
  3. 为 "admin" 创建的一个 user context。
  4. 将它设置为当前 context。

下面的命令可以一键生成配置:

kubectl config set-credentials USER_NAME \
   --auth-provider=oidc \
   --auth-provider-arg=idp-issuer-url=( issuer url ) \
   --auth-provider-arg=client-id=( your client id ) \
   --auth-provider-arg=client-secret=( your client secret ) \
   --auth-provider-arg=refresh-token=( your refresh token ) \
   --auth-provider-arg=idp-certificate-authority=( path to your ca certificate ) \
   --auth-provider-arg=id-token=( your id_token )

Token 的获取方式

ID Token 和 Refresh Token 的生成方式有很多种,其中最简单的方式是使用 curl 进行 Password Grant 方式的身份认证,从而获取想要的 ID Token 和 Refresh Token:

$ curl -k 'https://172.16.105.1:8082/auth/realms/hdls/protocol/openid-connect/token' -d "client_id=kubernetes" -d "client_secret=40dc1fef...c3eeec6" -d "response_type=code token" -d "grant_type=password" -d "username=test" -d "password=dangerous" -d "scope=openid"
{
    "access_token":"eyJhbGciOiJSU...0CMPw",
    "expires_in":300,
    "refresh_expires_in":1800,
    "refresh_token":"eyJhbGciOiJ...W1VUA",
    "token_type":"bearer",
    "id_token":"eyJhbGc...z3TaGJGQ",
    "not-before-policy":0,
    "session_state":"2845e...92ff2",
    "scope":"openid profile email"
}

然而这每次都需要手动生成 Token 并填写进 KubeConfig 中,非常麻烦。好消息是,社区已经有很多可以帮你自动将 Token 写入 KubeConfig 中的工具,非常好用,比如:

  1. kubelogin
  2. k8s-auth-client
  3. k8s-keycloak-oidc-helper
  4. kuberos
  5. k8s-oidc-helper

用户管理

在将一切都配置成功后,我们再来看给用户分配权限。这需要考虑到 K8s 的 RBAC 系统。

RBAC

对 group 为 manager 的用户,我们对其赋予系统自带的 "cluster-admin" 角色,即为 cluster 的管理员权限:

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: keycloak-admin-group
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: Group
  name: manager
  apiGroup: rbac.authorization.k8s.io

我们在 keyCloak 中将 admin 用户 “加入” 到 “manager” 组中:

然后用该用户访问 APIServer :

[root@172-16-105-1 ~]# kubelogin --username=admin --password=dangerous
You got a valid token until 2019-08-03 15:32:42 +0800 CST
[root@172-16-105-1 ~]#
[root@172-16-105-1 ~]# kubectl get cs
NAME                 STATUS    MESSAGE             ERROR
controller-manager   Healthy   ok
scheduler            Healthy   ok
etcd-0               Healthy   {"health":"true"}
[root@172-16-105-1 ~]# kubectl get no
NAME           STATUS   ROLES    AGE   VERSION
172-16-105-1   Ready    master   54d   v1.14.1
172-16-105-2   Ready    <none>   54d   v1.14.1
[root@172-16-105-1 ~]# kubectl get po
No resources found.
[root@172-16-105-1 ~]# kubectl get all
NAME                     TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
service/kubernetes       ClusterIP   10.96.0.1        <none>        443/TCP        54d

可以看到 “admin” 用户有所有资源的权限。

然后,我们再对 group 为 developer 的用户,新建一个角色叫做 "hdls-role",只给他们对 pod 的查看权限:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: hdls-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: hdls-rolebinding
roleRef:
  kind: ClusterRole
  name: hdls-role
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  name: developer
  apiGroup: rbac.authorization.k8s.io

在 keyCloak 中将 test 用户 “加入” 到 “developer” 组中:

然后用该用户访问 APIServer :

[root@172-16-105-1 ~]# kubelogin --username=test --password=dangerous
You got a valid token until 2019-08-03 15:40:21 +0800 CST
[root@172-16-105-1 ~]#
[root@172-16-105-1 ~]# kubectl get po
No resources found.
[root@172-16-105-1 ~]# kubectl get no
Error from server (Forbidden): nodes is forbidden: User "test" cannot list resource "nodes" in API group "" at the cluster scope
[root@172-16-105-1 ~]#
[root@172-16-105-1 ~]# kubectl get cs
Error from server (Forbidden): componentstatuses is forbidden: User "test" cannot list resource "componentstatuses" in API group "" at the cluster scope
[root@172-16-105-1 ~]#
[root@172-16-105-1 ~]# kubectl get all
Error from server (Forbidden): replicationcontrollers is forbidden: User "test" cannot list resource "replicationcontrollers" in API group "" in the namespace "default"
Error from server (Forbidden): services is forbidden: User "test" cannot list resource "services" in API group "" in the namespace "default"
Error from server (Forbidden): daemonsets.apps is forbidden: User "test" cannot list resource "daemonsets" in API group "apps" in the namespace "default"
Error from server (Forbidden): deployments.apps is forbidden: User "test" cannot list resource "deployments" in API group "apps" in the namespace "default"
Error from server (Forbidden): replicasets.apps is forbidden: User "test" cannot list resource "replicasets" in API group "apps" in the namespace "default"
Error from server (Forbidden): statefulsets.apps is forbidden: User "test" cannot list resource "statefulsets" in API group "apps" in the namespace "default"
Error from server (Forbidden): horizontalpodautoscalers.autoscaling is forbidden: User "test" cannot list resource "horizontalpodautoscalers" in API group "autoscaling" in the namespace "default"
Error from server (Forbidden): jobs.batch is forbidden: User "test" cannot list resource "jobs" in API group "batch" in the namespace "default"
Error from server (Forbidden): cronjobs.batch is forbidden: User "test" cannot list resource "cronjobs" in API group "batch" in the namespace "default"

test 用户除了能够获取 pod 信息,对于其他资源处处受限。

总结

本文仅仅通过 KeyCloak 和 kubectl 向大家介绍了 K8s 中如何进行用户管理,相应地,如果自己的用户中心实现 OIDC 协议,并且客户端通过 ID Token 以 "bearer token" 的方式来访问 APIServer,就能真正的将 K8s 的权限系统与上层建筑打通。