基础原理 - 探索Kubernetes的Service Accounts - 《云原生》

https://juejin.cn/post/6844903952870293511

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

作者：spursyy
链接：https://juejin.cn/post/6844903952870293511
来源：掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

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 复制代码
探索Kubernetes的Service Accounts - 图1
kubectl get svc 复制代码

为了更好的阐释相关内容，接下来我将通过Busybox镜像启动一个Pod，在Pod中使用curl命令做相关操作。
1. 使用Busybox镜像启动Pod
kubectl run -i —tty —rm curl-tns —image=radial/busyboxplus:curl 复制代码
探索Kubernetes的Service Accounts - 图3
在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 复制代码
探索Kubernetes的Service Accounts - 图4
为了更方便的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”}’ 复制代码
探索Kubernetes的Service Accounts - 图9
下面的命令将会获取default namespace下所有的serices，我们一起看看api service的返回结果。
curl —cacert $CA_CERT -H “Authorization: Bearer $TOKEN” “https://35.203.146.149:6443/api/v1/namespaces/$NAMESPACE/services/“ 复制代码
探索Kubernetes的Service Accounts - 图10
你也可以自定义一些role通过RBAC授权default service account更多的操作。
到此我们这一关于Kubernetes权限控制的系列文章已经结束了，我们先后讨论如何认证，授权以及service accounts对控制用户操作Kubernetes操作API Server的权限。

作者：spursyy
链接：https://juejin.cn/post/6844903952870293511
来源：掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。