Kubernetes使用Users和Service Account进行权限控制的相关工作,User 通过密钥和证书对Kuberntes API的访问进行认证,任何来自集群外的访问都需要被Kubernetes认证。通常使用X.509生成的证书对请求进行认证。
首先我们要再次重申Kubernetes没有通过数据库或者其他介质存储用户名和密码。相反,Kubenetes更希望对用户的管理可以由集群的外的程序来管理。借助Kubernetes的认证模块,可以将Kubernetes的认证我委托给第三方代理(如OpenID和Active Directory)。
X.509证书用于对Kubernetes外部请求的认证,Service accounts用于对集群内部请求的认证。Service Accounts与Pods相关,主要用于对集群内部API Server访问请求的认证。
在Kubernetes集群中,每一个运行的Pods都有一个叫default的默认用户。同时,为了使Pods可以访问内部的API Server端点,集群中有一个叫做Kubernetes的ClusterIP Server。
$ kubectl get serviceaccounts
$ kubectl get svc
为了更好的阐释相关内容,接下来我将通过Busybox镜像启动一个Pod,在Pod中使用curl命令做相关操作。
1. 使用Busybox镜像启动Pod
$ kubectl run -i --tty --rm curl-tns --image=radial/busyboxplus:curl
在Busybox的shell命令行中,我们尝试使用curl命令连接API Server端点。
$ curl https://kubernetes:8443/api
由于在请求中缺少相关的token,因此上面的请求并没有任何返回,接下来我将尝试获取token,并将token嵌入到请求的header中。
2. 获取token
我们已经已经讲过,token是通过secret的形式嵌入到Pod中。进入文件夹 /var/run/secrets/kubernetes.io/serviceaccount 后即可发现token。
$ cd /var/run/secrets/kubernetes.io/serviceaccount
为了更方便的curl命令,接下来我将设置一些环境变量:
$ CA_CERT=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
$ TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
$ NAMESPACE=$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace)
获取Kubectl API Service的url:
$ kubectl config view -o jsonpath='{"Cluster name\tServer\n"}{range .clusters[*]}{.name}{"\t"}{.cluster.server}{"\n"}{end}'
下面的命令将会获取default namespace下所有的serices,我们一起看看api service的返回结果。
$ curl --cacert $CA_CERT -H "Authorization: Bearer $TOKEN" "https://35.203.146.149:6443/api/v1/namespaces/$NAMESPACE/services/"
惊奇的发现default service account竞然没有获取相同namespace下services的权限。
在这里我们还要重申下Kubernetes遵循由关到开的准则,这就意味着默认的user或者service account并不具备任何权限。
3. 对service account进行授权
为了完成请求,我们需要通过role binding将相关的role绑定到default service account。这个过程与通过role binding将具有list pod权限的role绑定到Bob上的例子很像。
退出pod,执行下面的命令创建role后并将role绑定到default service account上。
$ kubectl create rolebinding default-view \
--clusterrole=view \
--serviceaccount=default:default \
--namespace=default
如果你对集群中的cluster role好奇,执行下面的命令:
$ kubectl get clusterroles
4. 再次验证
再次启动运行BusyBox镜像的Pod后请求API Server
$ kubectl run -i --tty --rm curl-tns --image=radial/busyboxplus:curl
为了更方便的curl命令,接下来我将设置一些环境变量:
$ CA_CERT=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
$ TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
$ NAMESPACE=$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace)
获取Kubectl API Service的url:
$ kubectl config view -o jsonpath='{"Cluster name\tServer\n"}{range .clusters[*]}{.name}{"\t"}{.cluster.server}{"\n"}{"end"}'
下面的命令将会获取default namespace下所有的serices,我们一起看看api service的返回结果。
$ curl --cacert $CA_CERT -H "Authorization: Bearer $TOKEN" "https://35.203.146.149:6443/api/v1/namespaces/$NAMESPACE/services/"
你也可以自定义一些role通过RBAC授权default service account更多的操作。