阅读 2405

权限控制:探索Kubernetes的Service Accounts

这一系列文档都是关于Kubernetes集群内部pods等资源对外部请求的认证与授权的管以及如何使用roles和role binding控制Kubernetes内部资源的访问权限。

Kubernetes使用Users和Service Account进行权限控制的相关工作,User 通过密钥和证书对Kuberntes API的访问进行认证,任何来自集群外的访问都需要被Kubernetes认证。通常使用X.509生成的证书对请求进行认证,你可以参照前面的文章通过实例理解Kubernetes的认证理解如何创建用户以及对用户进行相关认证。

首先我们要再次重申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更多的操作。

到此我们这一关于Kubernetes权限控制的系列文章已经结束了,我们先后讨论如何认证,授权以及service accounts对控制用户操作Kubernetes操作API Server的权限。

文章翻译自Kubernetes Access Control: Exploring Service Accounts,行文时略有删减

文章分类
阅读
文章标签