权限控制：探索Kubernetes的Service Accounts

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

• Kubernetes 权限控制概览
• 权限控制-经过实例理解Kubernetes的认证
• 权限控制-经过实例理解Kubernetes的受权
• 权限控制-探索Kubernetes的Service Accounts

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，行文时略有删减