189 8069 5689

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

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

青州网站建设公司成都创新互联公司,青州网站设计制作，有大型网站制作公司丰富经验。已为青州近1000家提供企业网站建设服务。企业网站搭建\外贸网站制作要多少钱，请找那个售后服务好的青州做网站的公司定做！

 

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的基本概念，希望能对你有所帮助。


网站栏目：Kubernetes身份认证和授权操作全攻略：访问控制之ServiceAccount
当前URL：http://cdxtjz.cn/article/ghhcsh.html

其他资讯