Kubernetes身份认证和授权操作全攻略：访问控制之Service Account

这是本系列的最后一篇文章，前面我们了解了访问控制中的基本概念以及身份认证和授权的具体操作，本文我们将进一步了解访问控制中的service account。

Kubernetes中有用户和service account的概念，可用于访问资源。用户与密钥和证书相关联用于验证API请求，使用其中一个配置方案对在集群外部发起的任何请求进行身份验证。最常见的方案是通过X.509证书进行身份认证请求。有关创建证书和将证书与用户关联的信息，请参阅Kubernetes身份验证教程。

请记住，Kubernetes不维护数据库或用户和密码的配置文件。相反，它希望在集群之外进行管理。通过身份验证模块的概念，Kubernetes可以将身份验证委派给第三方，如OpenID或Active Directory。

尽管X.509证书可用于身份验证的外部请求，但service account可以用于验证集群中运行的进程。此外，service account与进行API server内部调用的pod相关联。

每个Kubernetes安装都有一个默认的service account，它与每个正在运行的pod相关联。类似地，为了使pod能够调用内部API Server端点，有一个名为Kubernetes的ClusterIP服务，它与默认的service account一起使内部进程可以调用API端点。

kubectl get serviceAccounts 

NAME SECRETS AGE default 1 122m 

 kubectl get svc 

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 443/TCP 123m 

请注意，这个service account指向嵌在每个pod内部的secret。这一secret包含API Server所需的令牌。

kubectl get secret 

NAME TYPE DATA AGE default-token-4rpmv kubernetes.io/service-account-token 3 123m 

当我们开始调度pod并且访问它时，一切都变得明朗起来。我们将使用curl命令启动一个基于BusyBox的pod。

kubectl run -i --tty --rm curl-tns --image=radial/busyboxplus:curl 

kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead. If you don't see a command prompt, try pressing enter. [ root@curl-tns-56c6d54585-6v2xp:/ ]$ 

当我们在BusyBox shell中时，让我们尝试访问API Server端点。

[ root@curl-tns-56c6d54585-6v2xp:/ ]$ curl https://kubernetes:8443/api 

由于请求缺少身份验证令牌，因此不会产生任何结果。让我们看看如何检索可以嵌入HTTP头部的令牌。

如之前所讨论的，令牌作为一个secret安装在pod里。查看/var/run/secrets/kubernetes.io/serviceaccount 来查找令牌。

[ root@curl-tns-56c6d54585-6v2xp:/ ]$ cd /var/run/secrets/kubernetes.io/serviceaccount 

[ root@curl-tns-56c6d54585-6v2xp:/tmp/secrets/kubernetes.io/serviceaccount ]$ ls ca.crt namespace token 

让我们来设置一些环境变量以简化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) 

以下curl命令请求在默认命名空间中的服务。让我们看看我们能否从API Server中获得回应。

[ root@curl-tns-56c6d54585-6v2xp:~ ]$ curl --cacert $CA_CERT -H "Authorization: Bearer $TOKEN" "https://kubernetes/api/v1/namespaces/$NAMESPACE/services/" 

{ "kind": "Status", "apiVersion": "v1", "metadata": { }, "status": "Failure", "message": "services is forbidden: User \"system:serviceaccount:default:default\" cannot list resource \"services\" in API group \"\" in the namespace \"default\"", "reason": "Forbidden", "details": { "kind": "services" }, "code": 403 } 

然而，默认的service account并没有足够的权限来检索在同一命名空间内的服务。

请记住，Kubernetes遵循封闭开放的惯例，这意味着在默认情况下用户和service account没有任何权限。

为了满足这一请求，我们需要创建一个角色绑定，将默认service account和适当的角色相关联。这一步与我们将角色绑定到Bob的方式类似，后者授予他列出pod的权限。

退出pod并且运行以下命令，为默认service account创建一个角色绑定。

kubectl create rolebinding default-view \ --clusterrole=view \ --serviceaccount=default:default \ --namespace=default 

 rolebinding.rbac.authorization.k8s.io/default-view created 

以上命令将默认service account与集群角色视图相关联，该角色视图使pod能够列出资源。

如果你十分好奇，想看所有可用的集群角色，运行命令：kubectl get clusterroles。

让我们再次启动BusyBox pod并且访问API Server。

kubectl run -i --tty --rm curl-tns --image=radial/busyboxplus:curl 

kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead. If you don't see a command prompt, try pressing enter. [ root@curl-tns-56c6d54585-2cx44:/ ]$ 

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) 

curl --cacert $CA_CERT -H "Authorization: Bearer $TOKEN" "https://kubernetes/api/v1/namespaces/$NAMESPACE/services/" 

{ "kind": "ServiceList", "apiVersion": "v1", "metadata": { "selfLink": "/api/v1/namespaces/default/services/", "resourceVersion": "11076" }, "items": [ { "metadata": { "name": "kubernetes", "namespace": "default", "selfLink": "/api/v1/namespaces/default/services/kubernetes", "uid": "b715a117-6be1-4de0-8830-45bddcda701c", "resourceVersion": "151", "creationTimestamp": "2019-08-13T09:45:27Z", "labels": { "component": "apiserver", "provider": "kubernetes" } }, "spec": { "ports": [ { "name": "https", "protocol": "TCP", "port": 443, "targetPort": 8443 } ], "clusterIP": "10.96.0.1", "type": "ClusterIP", "sessionAffinity": "None" }, "status": { "loadBalancer": { } } } ] } 

您可以随意为默认service account创建其他绑定，以检查RBAC如何扩展到pod。

关于Kubernetes身份认证与授权系列文章到此结束，我们讨论了身份验证，授权和Service account的基本概念，希望能对你有所帮助。