当我们执行kubectl exec -it pod [podName] sh命令时，apiserver会向kubelet发起API请求。也就是说，kubelet会提供HTTP服务，而为了安全，kubelet必须提供HTTPS服务，且还要提供一定的认证与授权机制，防止任何知道kubelet端口的人都能访问它的API。
kubelet 认证
默认情况下，没有携带身份凭证的匿名请求会被认证为用户system:anonymous以及组system:unauthenticated。如果要拒绝将匿名请求认证为以上的用户与组，配置kubelet的如下启动参数，那么匿名请求就会认证失败
--anonymous-auth=false
kubelet的认证方法与apiserver相似，有client证书认证及token认证。
要开启client证书认证：
- 配置kubelet的启动参数
--client-ca-file，用来校验client证书
kubelet 授权
kubelet的默认授权模式为AlwaysAllow，所有通过认证的请求（包括通过认证的匿名请求）有权限访问kubelet所有的API。这显然是不合理的，所以我们需要像apiserver那样对不同的请求赋予不同的权限。
kubelet可以通过如下的方法把授权委托给apiserver：
- 在apiserver中开启
authorization.k8s.io/v1beta1这个API组 - 配置kubelet的启动参数
--authorization-mode=Webhook以及--kubeconfig - 然后kubelet就会通过apiserver的
SubjectAccessReviewAPI来决定是否给每一个请求授权
kubelet与apiserver的资源映射
kubelet与apiserver的API不一样，当访问kubelet的API时，kubelet需要把这个API映射到apiserver的API，apiserver才知道该授予怎样的权限。kubelet与apiserver的资源映射如下。比如A用户访问kubelet的Get /healthz，那么会映射为apiserver的Get /api/v1//nodes/<kubelet-name>/proxy，然后kubelet会通过apiserver的SubjectAccessReview判断A用户是否有权限访问apiserver对应的API
Apiserver访问kubelet
在kubeadm安装方法中，apiserver要访问kubelet的API，会携带一个client证书，这个证书由apiserver的启动参数--kubelet-client-certificate和--kubelet-client-key指定。kubeadm为apiserver生成的client证书中的域名为与组织分别为CN=kube-apiserver-kubelet-client、O=system:masters。
当apiserver携带这个证书去访问kubelet时，就会被认证为上面的用户与组，然后apiserver访问kubelet，检测这个用户与组的权限。kubeadm会在集群中为这个用户与组建立如下的ClusterRole与ClusterRoleBinding。可以看出，system:masters这个组拥有所有的权限
cat kube-apiserver.yaml - --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt- --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key- --kubelet-preferred-address-types=InternalIP,ExternalIP,HostnameapiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:name: cluster-admin
roleRef:apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.iokind: Groupname: system:mastersapiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:name: cluster-admin
rules:
- apiGroups:- '*'resources:- '*'verbs:- '*'
- nonResourceURLs:- '*'verbs:- '*'kubelet TLS私钥与证书
kubelet要提供HTTPS服务，那么它需要一个私钥和一个签名证书。我们可以通过kubelet的启动参数--tls-cert-file与--tls-cert-private-key来指定。如果这两个参数没有指定，那么kubelet会生成一个自签名证书，放在--cert-dir目录（默认/var/lib/kubelet/pki），自签名证书的名字为kubelet.key、kubelet.crt：
$ ls -lh /var/lib/kubelet/pki
-rw-------. 1 root root 2.8K Mar 10 11:26 kubelet-client-2023-03-10-11-26-25.pem
lrwxrwxrwx. 1 root root 59 Mar 10 11:26 kubelet-client-current.pem -> /var/lib/kubelet/pki/kubelet-client-2023-03-10-11-26-25.pem
-rw-r--r--. 1 root root 2.2K Mar 10 11:26 kubelet.crt
-rw-------. 1 root root 1.7K Mar 10 11:26 kubelet.key我们查看kubelet.crt的Issure与Subject，可以发现是一样的（即自签名），就为主机名加一个数字后缀，DNS中有一个记录就为主机名：
$ openssl x509 -text -in /var/lib/kubelet/pki/kubelet.crt
Certificate:Data:Version: 3 (0x2)Serial Number: 2 (0x2)Signature Algorithm: sha256WithRSAEncryptionIssuer: CN=kata02-ca@1678418785ValidityNot Before: Mar 10 02:26:24 2023 GMTNot After : Mar 9 02:26:24 2024 GMTSubject: CN=kata02@1678418785Subject Public Key Info:Public Key Algorithm: rsaEncryptionPublic-Key: (2048 bit)Modulus:...Exponent: 65537 (0x10001)X509v3 extensions:X509v3 Key Usage: criticalDigital Signature, Key EnciphermentX509v3 Extended Key Usage: TLS Web Server AuthenticationX509v3 Basic Constraints: criticalCA:FALSEX509v3 Authority Key Identifier: keyid:C4:7A:AD:CC:65:73:17:07:3B:69:3A:C9:B7:53:EE:0C:CC:04:07:7CX509v3 Subject Alternative Name: DNS:kata02
...我们可以查看kubelet的源码，也可以确定，就是自签名的一个证书：
由于kubelet默认情况下用的就是自签名证书，所以kube-apiserver在连接kubelet时（比如kubectl logs）,并不会校验kubelet.crt证书。
