使用默认Secret提供的验证信息
Last updated
Was this helpful?
Last updated
Was this helpful?
集群内部Pod与API服务器需要关注以下三点：
确定API服务器的位置；
确保与API服务器进行交互，而不是一个冒名者；
获得API服务器的授权，获取操作资源的权限；
在Kubernetes集群中，API服务是由名为kube-apiserver的Pod提供的，而在集群中有一个名为kubernetes的Service对象，其Endpoint列表中就是kube-apiserver，因此集群中的Pod可以通过访问该Service对象，与API服务器交互。
其中kube-apiserverPod使用的是hostNetwork类型的网络，即与主机共享网络命名空间，因此其IP地址是宿主机的IP地址，即对于集群而言，是集群外部地址，因此kubernetes是一个spec.selector=None的Service，其Endpoint列表为空，是另外单独指定的，具体原理可参考，原理图如下：
综上，我们有两种方法确定API服务器的位置：
在Pod中，通过KUBERNETES_SERVICE_HOST和KUBERNETES_SERVICE_PORT两个环境变量，确定kubernetesService的IP地址和端口；
可以直接通过访问https://kubernetes的FQDN的方式访问该Service（域名写全了是kubernetes.default.svc.cluster.local）；
在确定了API服务器的位置（IP地址和端口）后，我们需要验证是否是真的API服务器。
此时需要使用CA证书验证API服务器的证书是否由CA签发，从而验证其是否是真正的API服务器。
在使用curl访问API服务器时，需要使用--cacert参数指定CA证书：
由于还没有获得API服务器的授权，因此到这一步，还是没有权限对资源对象进行操作的。
想获得API服务器的授权，需要使用凭证来申请。
在使用curl访问API服务器时，需要使用-H在请求数据中，加入头信息：
可能在执行完一下操作后还是提示没有权限访问，可能是因为Kubernetes的基于角色的访问控制机制（RBAC），我们可以通过下面的命令先绕过该机制：
下面总结一下使用默认Secret与API服务器的交互过程：
使用环境变量或FQDN确定API服务器的位置；
应用使用/var/run/secrets/kubernetes.io/serviceaccount/ca.crtCA证书验证API服务器的真实性；
应用使用/var/run/secrets/kubernetes.io/serviceaccount/token作为获取API服务器授权的凭证；
并且之前在介绍内部Pod访问Service中提到，我们可以轻易的，进而由Service将我们的请求转发至API服务器（Pod）。
在中，说过每一个Pod都会挂载一个默认的Secret卷，该卷会被挂载至容器中的/var/run/secrets/kubernetes.io/serviceaccount目录下，其中有一个名为ca.crt的文件，其中就是用于验证API服务器的CA证书。
凭证在挂载目录/var/run/secrets/kubernetes.io/serviceaccount下的一个名为token的文件中。
