Kubelet 认证

当我们执行kubectl exec -it pod [podName] sh命令时，apiserver会向kubelet发起API请求。也就是说，kubelet会提供HTTP服务，而为了安全，kubelet必须提供HTTPS服务，且还要提供一定的认证与授权机制，防止任何知道kubelet端口的人都能访问它的API。

默认情况下，没有携带身份凭证的匿名请求会被认证为用户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,Hostname

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:masters

apiVersion: 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: sha256WithRSAEncryption
        Issuer: CN=kata02-ca@1678418785
        Validity
            Not Before: Mar 10 02:26:24 2023 GMT
            Not After : Mar  9 02:26:24 2024 GMT
        Subject: CN=kata02@1678418785
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    ...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Authority Key Identifier: 
                keyid:C4:7A:AD:CC:65:73:17:07:3B:69:3A:C9:B7:53:EE:0C:CC:04:07:7C

            X509v3 Subject Alternative Name: 
                DNS:kata02
...

我们可以查看kubelet的源码，也可以确定，就是自签名的一个证书：

由于kubelet默认情况下用的就是自签名证书，所以kube-apiserver在连接kubelet时（比如kubectl logs）,并不会校验kubelet.crt证书。