Kubernetes apiserver access kubelet получил "Http 401: не авторизован" с https и сертификатом существующего сервера в качестве сертификата клиента
Я хочу использовать безопасное соединение TLS от apiserver до kubelet, мой кластер создается копиями на экземплярах AWS EC2, и в папке есть пара ожидающих сертификатов / ключей /srv/kubernetes/ после того, как кластер подготовлен.
Но на стороне клиента apiserver, если использовать существующий сертификат / ключ в качестве сертификата клиента, получит следующий результат:
@ip-172-30-96-198:/srv/kubernetes# curl -k --cert /srv/kubernetes/server.cert --key /srv/kubernetes/server.key https://ip-172-30-96-99.-2.compute.internal:10250/metrics -v
* Trying 172.30.96.99...
* Connected to ip-172-30-96-99.ap-southeast-2.compute.internal (172.30.96.99) port 10250 (#0)
* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 592 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
* server certificate verification SKIPPED
* server certificate status verification SKIPPED
* common name: ip-172-30-96-99.ap-southeast-2.compute.internal@1534895331 (matched)
* server certificate expiration date OK
* server certificate activation date OK
* certificate public key: RSA
* certificate version: #3
* subject: CN=ip-172-30-96-99.ap-southeast-2.compute.internal@1534895331
* start date: Tue, 21 Aug 2018 23:48:51 GMT
* expire date: Wed, 21 Aug 2019 23:48:51 GMT
* issuer: CN=ip-172-30-96-99.ap-southeast-2.compute.internal@1534895331
* compression: NULL
* ALPN, server accepted to use http/1.1
> GET /metrics HTTP/1.1
> Host: ip-172-30-96-99.ap-southeast-2.compute.internal:10250
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 401 Unauthorized
< Date: Thu, 23 Aug 2018 06:58:19 GMT
< Content-Length: 12
< Content-Type: text/plain; charset=utf-8
<
* Connection #0 to host ip-172-30-96-99.ap-southeast-2.compute.internal left intact
--anonymous-auth включен на стороне кублета.
Это работает при использовании нового сгенерированного сертификата, даже используя тот же CA, ключ, Common Name и SubjectAlternativeName с существующим сертификатом для этого нового сертификата.
Я не знаю почему, это означает, что я должен сгенерировать новую пару сертификат / ключ для клиента kubelet? Почему сертификат этого сервера не работает и есть ли проблемы с авторизацией в kubelet?