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复制代码

2NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGEkubernetes   ClusterIP   10.96.0.1            443/TCP   123m复制代码

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

kubectl get secret复制代码

NAME                  TYPE                                  DATA   AGEdefault-token-4rpmv   kubernetes.io/service-account-token   3      123m复制代码

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

kubectl run -i --tty --rm curl-tns --image=radial/busyboxplus:curl
复制代码

123kubectl 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复制代码

2[ root@curl-tns-56c6d54585-6v2xp:/tmp/secrets/kubernetes.io/serviceaccount ]$ lsca.crt     namespace  token复制代码

让咱们来设置一些环境变量以简化curl命令。

CA_CERT=/var/run/secrets/kubernetes.io/serviceaccount/ca.crtTOKEN=$(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/"复制代码

1234567891011121314{  "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建立一个角色绑定。

1234kubectl 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复制代码

123kubectl 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.crtTOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)NAMESPACE=$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace)复制代码

1curl --cacert $CA_CERT -H "Authorization: Bearer $TOKEN" "https://kubernetes/api/v1/namespaces/$NAME复制代码

{  "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的基本概念，但愿能对你有所帮助。