Kubeadm: 서명 된 kubelet 제공 인증서 사용

@ raravena80 /var/lib/kubelet/pki/ .. 아래 kubeadm에서 만든 인증서를 알지 못합니다. 친절하게 더 많은 정보를 제공 할 수 있습니까? 예 : kubeadm 구성 파일, 클러스터 생성 단계

@fabriziopandini 인증서가 kubeadm에 의해 생성되었는지 확실하지 않지만 일반적인 절차는 여기 에 설명되어

디렉토리의 내용은 다음과 같습니다.

root@ip-172-31-1-118:/var/lib/kubelet/pki# pwd
/var/lib/kubelet/pki
root@ip-172-31-1-118:/var/lib/kubelet/pki# ls -al
total 24
drwxr-xr-x 2 root root 4096 Jul 23 21:10 .
drwxr-xr-x 7 root root 4096 Nov 12 04:52 ..
-rw------- 1 root root 2810 Jul 23 21:09 kubelet-client-2018-07-23-21-09-53.pem
-rw------- 1 root root 1159 Jul 23 21:10 kubelet-client-2018-07-23-21-10-43.pem
lrwxrwxrwx 1 root root   59 Jul 23 21:10 kubelet-client-current.pem -> /var/lib/kubelet/pki/kubelet-client-2018-07-23-21-10-43.pem
-rw-r--r-- 1 root root 1501 Nov  8 23:53 kubelet.crt
-rw------- 1 root root 1679 Nov  8 23:53 kubelet.key
root@ip-172-31-1-118:/var/lib/kubelet/pki#

kubelet이 처음로드 할 때 kubelet.crt 및 kubelet.key 파일이 생성됩니까?

@ raravena80 설명 주셔서 감사합니다
아마도 여기에 완전한 맥락이 없기 때문에 다른 사람들에게 대답 할 여지를 남겨 둡니다.

단 하나의 참고 사항 (도움이 될 수 있음)
Kubeadm은 이미 apiserver-kubelet-client 라는 인증서를 생성하여 API 서버가 kubelet과 안전하게 통신 할 수 있도록합니다. ca에 의해 서명되고 필요한 RBAC 규칙에 바인딩됩니다.

/ 할당 @liztio

나는 이것이 kubelet의 서버 인증서를 미리 생성하는 것이라고 생각합니다. TLS 서버 부트 스트랩에 Kubelet 플래그를 사용하고 서버 인증서를 회전하려고 시도했지만, 불행히도 Kubelet이 부트 스트랩 토큰을 사용하여 서버 인증서를 요청할 수 없었습니다. Kubelet은 자체 서명 된 인증서를 생성하는 서버 인증서의 기본 동작으로 되돌아갑니다.

내가 아는 한, 현재 유일한 방법은 Kubelet의 서버 인증서를 대역 외에서 생성하여 결정적 경로에 배치하는 것입니다. kubelet (kubeadm에서 구성)이이를 선택하고 이에 따라 일부 kubelet 플래그를 설정합니다. ; 참조 : https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#client -and-serving-certificates

apiserver-kubelet-client 는 API 서버가 kubelet에 제공 할 클라이언트 인증서이지만 kubelet은 k8s CA에서 서명 한 클라이언트를 신뢰하도록 구성됩니다.

# cat /var/lib/kubelet/config.yaml 
address: 0.0.0.0
apiVersion: kubelet.config.k8s.io/v1beta1
authentication:
  anonymous:
    enabled: false
  webhook:
    cacheTTL: 2m0s
    enabled: true
  x509:
    clientCAFile: /etc/kubernetes/pki/ca.crt

k8s CA가 서명해야하는 서버로서의 kubelet의 신원은 원래 질문으로 돌아옵니다.

이 글의 끝에는 관련 토론도 있습니다 : https://github.com/kubernetes/kubeadm/issues/118

클라이언트 인증서 요청과 마찬가지로 kubeadm이 유효한 부트 스트랩 토큰으로 서버 인증서 요청에 대한 CSR 승인자를 추가해야 할 수 있다고 생각합니다.

kubelet이 자체 서명 된 CA를 configmap 어딘가에 업로드하도록하는 것은 어떻습니까? nodeadmission 플러그인은 자신의 configmap으로 만 제한 할 수 있습니다. metrics-server는이를 사용하여 노드에 연결할 수 있습니다.

그것에 대한 아이디어가 있습니까?

가능하다면 인증서 요청 / 순환을 위해 kubelet에 내장 된 TLS 부트 스트래핑 기능을 사용해야한다고 생각합니다.

@alexbrand 동의합니다

kubelet TLS 부트 스트랩 핑은 어떤 이유로 든 클라이언트 인증서 만 생성합니다.
--bootstrap-kubeconfig string
Path to a kubeconfig file that will be used to get client certificate for kubelet. If the file specified by --kubeconfig does not exist, the bootstrap kubeconfig is used to request a client certificate from the API server. On success, a kubeconfig file referencing the generated client certificate and key is written to the path specified by --kubeconfig. The client certificate and key file will be stored in the directory pointed by --cert-dir.

그리고 kubeadm은 이미 이것을합니다. 아마도 이것이 kubelet 기능 요청일까요?

문제를 요약 해 보겠습니다.

@anitgandhi 에 의해 설명 된
https://github.com/kubernetes/kubeadm/issues/1223#issuecomment -454572577

여기서 kubeadm의 문제는 kubelet에 몇 가지 플래그를 전달하지 않는다는 것입니다.

--tls-cert-file=<some-path>/kubelet.crt
--tls-private-key-file=<some-path>/kubelet.key

이러한 플래그가 없으면 kubelet은 기본적으로 자체 서명으로 설정되어 처음 실행될 때 인증서를 제공하며 다음으로 확인할 수 있습니다.

sudo openssl verify -verbose -CAfile /var/lib/kubelet/pki/kubelet.crt /var/lib/kubelet/pki/kubelet.crt

클러스터 CA ( /etc/kubernetes/ca.crt )에서 서명 한 인증서 대신 자체 서명 된 인증서를 사용하는 경우 자체 서명 된 인증서 SAN에는 DNS:hostname 만 포함되므로 메트릭 서버와 같은 배포는 kubelet을 스크 레이 핑 할 수 없습니다.

가능한 해결책:
A) 새로운 kubelet.crt/key 쌍, 이상적으로는 /var/lib/kubelet/pki 미만의 노래를 구현하고 추가 kubelet 플래그 --tls-cert-file , --tls-private-key-file 합니다.

B) 문서는 @ raravena80 이 여기에서 한 것과 유사하게 온 디맨드로 활성화하는 것을 의미합니다 : https://stackoverflow.com/questions/53212149/x509-certificate-signed-by-unknown-authority-kubeadm/53218524#53218524
Kubernetes CSR / kubeadm 명령을 사용하는 경우는 예외입니다.

C) @alexbrand의 코멘트

가능하다면 인증서 요청 / 순환을 위해 kubelet에 내장 된 TLS 부트 스트래핑 기능을 사용해야한다고 생각합니다.

D)?

@ kubernetes / sig-cluster-lifecycle
나에게 이것은 버그 / 기능 사이의 공간에서 보인다.

참조 :
https://github.com/kubernetes/community/pull/602/files

많은 부트 스트랩 토큰 클라이언트 cert / CSR 논리 kubelet + kubeadm이 이에 대한 공통 논리를 가질 것이기 때문에 옵션 B + C 사이에 뭔가를해야한다고 생각합니다.

문제를 요약 해 보겠습니다.

@anitgandhi 에 의해 설명 된
# 1223 (코멘트)

여기서 kubeadm의 문제는 kubelet에 몇 가지 플래그를 전달하지 않는다는 것입니다.

--tls-cert-file=<some-path>/kubelet.crt
--tls-private-key-file=<some-path>/kubelet.key

이러한 플래그가 없으면 kubelet은 기본적으로 자체 서명으로 설정되어 처음 실행될 때 인증서를 제공하며 다음으로 확인할 수 있습니다.

sudo openssl verify -verbose -CAfile /var/lib/kubelet/pki/kubelet.crt /var/lib/kubelet/pki/kubelet.crt

클러스터 CA ( /etc/kubernetes/ca.crt )에서 서명 한 인증서 대신 자체 서명 된 인증서를 사용하는 경우 자체 서명 된 인증서 SAN에는 DNS:hostname 만 포함되므로 메트릭 서버와 같은 배포는 kubelet을 스크 레이 핑 할 수 없습니다.

가능한 해결책:
A) 새로운 kubelet.crt/key 쌍, 이상적으로는 /var/lib/kubelet/pki 미만의 노래를 구현하고 추가 kubelet 플래그 --tls-cert-file , --tls-private-key-file 합니다.

B) 문서는 @ raravena80 이 여기에서 한 것과 유사하게 온 디맨드로 활성화하는 것을 의미합니다 : https://stackoverflow.com/questions/53212149/x509-certificate-signed-by-unknown-authority-kubeadm/53218524#53218524
Kubernetes CSR / kubeadm 명령을 사용하는 경우는 예외입니다.

C) @alexbrand의 코멘트

가능하다면 인증서 요청 / 순환을 위해 kubelet에 내장 된 TLS 부트 스트래핑 기능을 사용해야한다고 생각합니다.

D)?

@ kubernetes / sig-cluster-lifecycle
나에게 이것은 버그 / 기능 사이의 공간에서 보인다.

참조 :
https://github.com/kubernetes/community/pull/602/files

훌륭한 요약 @ neolit123 . 이것이 다음 사이클로 넘어갈 것인지 아니면 우리가 말하는 것처럼 진행중인 작업인지 알고 있습니까? 주로 모든 배포가 원하는 메트릭 서버 때문에 묻습니다.)

@randomvariable 은 이에 대한 또 다른 해결 방법이 있다고 언급했습니다.
지금까지 논의한 내용에서 클러스터 CA로 kubelet-serving 인증서에 서명하는 것을 주저하고 있습니다. 이 주제는 추가 논의가 필요합니다.

/ remove-help

구현할 솔루션이 아직 선택되지 않았기 때문입니다.

이것에 대한 움직임? kubeadm 배포 클러스터 내에서 자동 확장 기능을 지원하기 위해 실행 중입니다.

현재 해결 방법은 kubelet 인증서의 CA 검사를 끄는 것입니다.

helm install --set 'args={--kubelet-insecure-tls}' --namespace kube-system metrics stable/metrics-serve

실제로는 디자인 제안에서 차단됩니다.
여러 가지 해결 방법이 있지만 중단 된 문제를 문서화하는 작업은 다음과 같습니다.
https://github.com/kubernetes/kubeadm/issues/1602

--kubelet-insecure-tls

이것은 모든 사용자에게 이상적이지 않을 수 있습니다.

90 일 동안 활동이 없으면 문제가 부실해집니다.
/remove-lifecycle stale 하여 최신 문제로 표시합니다.
비활성 문제는 추가로 30 일 동안 사용하지 않으면 썩고 결국 종료됩니다.

이 문제를 지금 종료해도 안전하다면 /close 하여 종료하세요.

sig-testing, kubernetes / test-infra 및 / 또는 fejta에 피드백을
/ lifecycle stale

/ lifecycle frozen

kubeadm을 사용하여 v1.18.2 클러스터를 만드는 정확한 문제가 발생합니다.

metrics-server를 설정할 때 kubelet-insecure-tls 플래그를 설정하거나 kublet "out of band"에 대한 인증서를 발급하고 kubernetes CA로 서명하지 않으면 작동하지 않습니다.

kubelet 클라이언트 인증서를 재사용하는 것에 대해 생각했지만 당연히 CN = system:node:nodename 발급되고 SAN이 없습니다. 그리고 나는 그것을 나타 내기 위해 오류를 변경했지만 테스트했습니다. 주체 대체 이름으로 노드 이름이있는 경우 동일한 인증서를 서버 / 클라이언트로 사용할 수 있습니까? 하지만 서버 / 클라이언트에 대해 별도의 인증서를 사용하는 것이 더 적절하다고 생각합니까?

/ remove-lifecycle frozen

/ lifecycle frozen

봇이 문제를 해결하지 못하도록 고정되어 있습니다.

주체 대체 이름으로 노드 이름이있는 경우 동일한 인증서를 서버 / 클라이언트로 사용할 수 있습니까?

이론적으로 그리고 kubelet이 검증하지 않는 한-예를 들어 "클라이언트 인증서에는 SAN이 없어야합니다".

하지만 서버 / 클라이언트에 대해 별도의 인증서를 사용하는 것이 더 적절하다고 생각합니까?

피할 수있는 경우에도 별도로 사용하는 것이 일반적입니다. kubelet / auth {z | n} 관리자가이 세부 사항을 변경할 가능성은 거의 없습니다.

야. 조금 더 파헤 쳤습니다. Kubelet 구성 옵션 serverTLSBootstrap: true 은 실제로 제공 인증서에 대한 CSR을 생성 할 수 있습니다. 그러나 그것은 승인되지 않은 채로 남습니다. 어느 쪽이 괜찮을까요?

rotateCertificates: true 및 serverTLSBootsrap: true 를 모두 설정 한 다음 제공 인증서에 대한 CSR을 승인하는 것이 여기로 이동하는 가장 쉬운 방법 인 것 같습니다. 요청 / 발급 된 제공 인증서는 O = system:nodes, CN = system:node:<nodename> 대한 것이며 주체 대체 이름은 DNS: <nodename>, IP Address: <node IP address>

적어도 serverTLSBootstrap 구성 옵션을 활성화 할 때 kubeadm이 서버 인증서를 승인하는 것이 쉬운 일입니까? 아니면 kubeadm도 승인을 할 수 있습니까?

야. 조금 더 파헤 쳤습니다. Kubelet 구성 옵션 serverTLSBootstrap: true 은 실제로 제공 인증서에 대한 CSR을 생성 할 수 있습니다. 그러나 그것은 승인되지 않은 채로 남습니다. 어느 쪽이 괜찮을까요?

rotateCertificates: true 및 serverTLSBootsrap: true 를 모두 설정 한 다음 제공 인증서에 대한 CSR을 승인하는 것이 여기로 이동하는 가장 쉬운 방법 인 것 같습니다. 요청 / 발급 된 제공 인증서는 O = system:nodes, CN = system:node:<nodename> 대한 것이며 주체 대체 이름은 DNS: <nodename>, IP Address: <node IP address>

적어도 serverTLSBootstrap 구성 옵션을 활성화 할 때 kubeadm이 서버 인증서를 승인하는 것이 쉬운 일입니까? 아니면 kubeadm도 승인을 할 수 있습니까?

보안 구현은 확실하지 않지만 serverTLSBootstrap 와이 연산자를 결합하여 CSR https://github.com/kontena/kubelet-rubber-stamp 를 자동 승인 할 수

적어도 serverTLSBootstrap 구성 옵션을 활성화 할 때 kubeadm이 서버 인증서를 승인하는 것이 쉬운 일입니까? 아니면 kubeadm도 승인을 할 수 있습니까?

kubeadm이 데몬이 아니기 때문에 kubeadm이 승인을 수행 할 수 없습니다. 사용자를 위해이를 관리하는 컨트롤러 / 운영자를 배포해야합니다. 아마 미래에는.

인증서 API가 곧 GA 될 것이며, 우리는 이것을 k8s에서 더 나은 방법으로 관리 할 수있을 것입니다. 시청하십시오 :
https://github.com/kubernetes/enhancements/issues/267
(아직 우리가 무엇으로 끝날 것인지 불분명합니다 ...)

대안 아이디어도 있습니다. 그러나이 모든 것이 metric-server 문제를 해결하려는 경우 kubelet에 대한 MS 요청에 대해 SAR을 수행 할 수있는 https://github.com/brancz/kube-rbac-proxy 를 사용하는 것이 좋습니다. 슬프게도 이것은 아직 우리 측에 문서화되지 않았습니다.
https://github.com/kubernetes/kubeadm/issues/1602

@ neolit123 적어도 --kubelet-insecure-tls 플래그를 지정하는 것이었지만 안전한 방법으로 문제를 해결하는 방법을보고 싶었고 문제에 관심을 갖게되었습니다. 🙂

지금은 kubelet 구성에 serverTLSbootstrap 플래그를 추가하고 인증서를 수동으로 승인하는 것이 쉽습니다. 하지만 단점은 인증서를 승인 할 때까지 노드의 포드와 완전히 상호 작용할 수 없다는 것입니다. (예를 들어, kubectl exec는 승인 전에 노드에서 실행중인 포드에서 명령을 실행하지 못함)

향상 문제도 따라갈 것입니다. 감사.

충분히 성숙해 보이는 kubeadm을 사용하면 kubeletet cert의 기본 결과가 자체 서명되고 많은 사람들이 제대로 일을하는 대신 메트릭 서버에 대해 kubelet-insecure-tls 을 선택한다는 것은 정말 슬픈 일입니다.

복잡한 문제입니다.

시도하십시오 :
https://github.com/kontena/kubelet-rubber-stamp
또는
https://github.com/brancz/kube-rbac-proxy
해결 방법으로

복잡한 문제입니다.

시도하십시오 :
https://github.com/kontena/kubelet-rubber-stamp
또는
https://github.com/brancz/kube-rbac-proxy
해결 방법으로

실제로 https://github.com/kontena/kubelet-rubber-stamp 는 꽤 잘 작동하며 imo는 프록시 대신 더 정확한 솔루션 인 것 같습니다.

1 단계:
더하다
kubelets 재구성을 위해 serverTLSBootstrap: true 매 /var/lib/kubelet/config.yaml 끝까지 & 구성 적용 (또는 재부팅)을 잊지 마세요.

2 단계:
kubelet-rubber-stamp 배포

service_account.yaml
role.yaml
role_binding.yaml
operator.yaml

3 단계 :
메트릭-서버 배포 편집 및 --kubelet-insecure-tls 제거

결과:

kubectl get csr
NAME        AGE   SIGNERNAME                      REQUESTOR          CONDITION
csr-7dvsx   31m   kubernetes.io/kubelet-serving   system:node:u-02   Approved,Issued
csr-d6rvm   31m   kubernetes.io/kubelet-serving   system:node:u-03   Approved,Issued
csr-szblz   31m   kubernetes.io/kubelet-serving   system:node:u-01   Approved,Issued
csr-zjfgj   31m   kubernetes.io/kubelet-serving   system:node:u-04   Approved,Issued

헤이, @vainkop에 추가하기 위해
클러스터를 생성하기 위해 초기 kubeadm init 동안 KubeletConfiguration API 개체 파일을 전달하여 serverTLSBootstrap 를 설정할 수도 있습니다.

```kubeadm-config.yaml
apiVersion : kubeadm.k8s.io/v1beta2
종류 : ClusterConfiguration

...

apiVersion : kubelet.config.k8s.io/v1beta1
종류 : KubeletConfiguration
serverTLSBootstrap : true

`kubeadm init --config=kubeadm-config.yaml`

Then all kubelet's will automatically be set up using the `serverTLSBootstrap` flag.

To get the CSRs

kubectl get csr
이름 연령 서명자 이름 요청자 조건
csr-2qkdw 2m1s kubernetes.io/kube-apiserver-client-kubelet 시스템 : 부트 스트랩 : fcufbo 승인 됨, 발급 됨
csr-9wvgt 114s kubernetes.io/kubelet-serving system : node : worker-1 Pending
csr-lz97v 4m58s kubernetes.io/kubelet-serving 시스템 : node : master-1 보류 중
csr-rsdsp 4m59s kubernetes.io/kube-apiserver-client-kubelet 시스템 : node : master-1 승인 됨, 발급 됨
csr-wgxqs 4m49s kubernetes.io/kubelet-serving 시스템 : node : master-1 보류 중

Then either approve them manually or deploy https://github.com/kontena/kubelet-rubber-stamp which approves them automatically. I just tried it with kubelet-rubber-stamp and it works great.

Also I did not seem to need to restart the kubelet's this way, they picked up their certificates as soon as I approvde the CSR, but a caveat is that the kublet's have NO cert until the CSR is approved, it does not get a self signed certificate first.

kubectl certificate accept csr-ab123 # 또는 rubber-stamp 배포!

kubectl get csr
이름 연령 서명자 이름 요청자 조건
csr-9wvgt 3m kubernetes.io/kubelet-serving 시스템 : node : worker-1 승인 됨, 발행 됨
...
```

여기서 또 다른 이상한 일이 발생하는 것 같습니다. 즉, 마스터 노드가 CSR을 두 번 생성하는 것 같습니다. (적어도 두 번 시도했습니다)

그러나 @nijave 가 위의 의견에서

@allir , @vainkop 까지는 kubelet-rubber-stamp가 CSR의 일반 이름이 요청자 이름과 일치하는지 확인하지만 kubelet에서 요청한 추가 호스트 이름과 IP 주소가 유효한지 여부는 확인하지 않습니다. 이는 kubelet 클라이언트 인증서에 액세스 할 수있는 공격자가 기본적으로 모든 도메인 이름 또는 IP 주소에 대한 인증서를 생성 할 수 있음을 의미합니다. 그러면 루트 CA를 신뢰하도록 구성된 모든 클라이언트가이 인증서를 수락합니다.
물론 주어진 kubelet에 대해 유효한 호스트 이름과 IP 주소를 확인하는 것은 현재 kubelet이 요청할 수있는 것을 확인할 수있는 권한이 없기 때문에 어렵습니다. 예를 들어 API 서버에서 노드 객체를 사용하는 것은 kubelet이 제한없이 객체를 업데이트 할 수 있기 때문에 충분하지 않습니다.

헤이, @vainkop에 추가하기 위해
클러스터를 생성하기 위해 초기 kubeadm init 동안 KubeletConfiguration API 개체 파일을 전달하여 serverTLSBootstrap 를 설정할 수도 있습니다.
kubeadm init --config=kubeadm-config.yaml
그러면 모든 kubelet이 serverTLSBootstrap 플래그를 사용하여 자동으로 설정됩니다.

또는 Ansible을 사용하는 기존 K8 설정의 경우 다음과 같을 수 있습니다.

  tasks:
    - name: Insert a line at the end of /var/lib/kubelet/config.yaml
      lineinfile:
        path: /var/lib/kubelet/config.yaml
        line: 'serverTLSBootstrap: true'

+ kubelets 다시 시작

와우,이 문제를 발견하게되어 기쁩니다.이 올바른 방법을 만들고 싶은 사람은 혼자가 아닙니다. :)

이제이 문제에 대한 내 생각을 공유하겠습니다 (내가 잘못된 경우 수정 해주세요) .

먼저 원래 문제에 대한 나의 비전 :
현재 kubeadm은 기본적으로 모든 kubelet에 대해 웹 후크 인증을 활성화하므로 kubelet은 --kubelet-insecure-tls 옵션이 지정된 경우에도 문제없이 수신 연결에 대한 클라이언트 인증서를 검증합니다.
다른 쪽에서 metrics-server는 노드에서 자체 서명되기 때문에 특정 kubelet 인증서를 확인할 기회가 없습니다.

메트릭 서버에 --kubelet-insecure-tls 사용시 가능한 위험 :
kubelet 데이터는 다소 안전하며 성공적인 웹 후크 인증 없이는 메트릭 서버에 제공되지 않습니다.
이론적으로 누군가 서버 IP 또는 호스트 이름을 손상시키고 잘못된 통계를 제공 할 수 있습니다. 그러나 연결 설정을 위해 metricserver는 kube-apiserver를 통해 노드에 지정된 IP 주소와 호스트 이름을 사용하므로 공격자는 먼저 API-server, DNS 또는 노드 IP 주소를 해킹해야합니다.

약간의 관찰 :
metrics-server는 kubelet에 직접 액세스하는 단일 서비스가 아닙니다. 또한 Kube-apiserver는 컨테이너 로그를 읽거나 해당 로그에서 셸을 실행하기 위해이 작업을 수행합니다. 좋은 질문은 kube-apiserver가 인증서를 발행 한 CA에 대한 정보가없는 동안 특정 kubelet과의 연결을 설정하는지 확인하는 방법입니다.
이 경우 --kubelet-insecure-tls 옵션을 사용하는 메트릭 서버와 동일하게 작동하지 않습니까?

가능한 해결책:
오늘날 웹훅과 API 집계는 Kubernetes에서 매우 인기가 있습니다. 그들 모두는 자체 CA와 crt / key 쌍을 생성함으로써 유사한 방식으로 작동합니다. CA 해시는 또한 특정 리소스에 저장되어 kube-apiserver에 신뢰할 수있는 인증서에 대한 정보를 제공합니다.

예를 들면 :

• APIServices는 apiservices.apiregistration.k8s.io 리소스에 관련 CA 해시를 저장합니다.

  spec:
  caBundle: <ca-hash>
  

• 웹 후크는 validatingwebhookconfigurations.admissionregistration.k8s.io 및 mutatingwebhookconfigurations.admissionregistration.k8s.io 리소스에 관련 CA 해시를 저장합니다.

  webhooks:
  - clientConfig:
    caBundle: <ca-hash>
  

나에게 각 노드의 자원이 있어야한다 꽤 분명하다 유사한 caBundle 에서 자신의 spec kubelets가 클라이언트 인증서를 사용하여 역할에 대한 자신의 CA를 등록 할 수있는 곳 :

spec:
  caBundle: <ca-hash>

metris-server와 kube-apiserver는 모두이 인증서를 사용하여 kubelet에 대한 연결을 확인하고 신뢰해야합니다.

이전에 유사한 아이디어를 표현한 @ kfox1111 덕분에 https://github.com/kubernetes/kubeadm/issues/1223#issuecomment -460854312

좋은 질문은 kube-apiserver가 인증서를 발행 한 CA에 대한 정보가없는 동안 특정 kubelet과의 연결을 설정하는지 확인하는 방법입니다.
이 경우 --kubelet-insecure-tls 옵션을 사용하는 메트릭 서버와 동일하게 작동하지 않습니까?

이 질문에 답하기 위해 여기에서 @luxas 를 인용 할 수 있습니다.

맞습니다. 각 kubelet에는 자체 서명 된 인증서가 있으므로 api 서버에서 확인 된 kubelet 서버로 연결할 수 없습니다. 앞으로 인증서를 제공하는 kubelet의 수동 승인 흐름을 고려할 수 있지만 현재 기본적으로 보호되지는 않습니다.

https://github.com/kubernetes/kubeadm/issues/118#issuecomment -407498529에서

언젠가 해결 될 수 있기를 바랍니다

[root<strong i="6">@jenkins</strong> metrics-server]# kubectl -n kube-system logs -f metrics-server-6955d88db9-lftlz
I1120 08:23:09.094132       1 requestheader_controller.go:169] Starting RequestHeaderAuthRequestController
I1120 08:23:09.094234       1 shared_informer.go:240] Waiting for caches to sync for RequestHeaderAuthRequestController
I1120 08:23:09.094270       1 configmap_cafile_content.go:202] Starting client-ca::kube-system::extension-apiserver-authentication::client-ca-file
I1120 08:23:09.094279       1 shared_informer.go:240] Waiting for caches to sync for client-ca::kube-system::extension-apiserver-authentication::client-ca-file
I1120 08:23:09.094307       1 configmap_cafile_content.go:202] Starting client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file
I1120 08:23:09.094315       1 shared_informer.go:240] Waiting for caches to sync for client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file
I1120 08:23:09.095064       1 dynamic_serving_content.go:130] Starting serving-cert::/tmp/apiserver.crt::/tmp/apiserver.key
I1120 08:23:09.095207       1 secure_serving.go:197] Serving securely on [::]:4443
I1120 08:23:09.095259       1 tlsconfig.go:240] Starting DynamicServingCertificateController
I1120 08:23:09.194453       1 shared_informer.go:247] Caches are synced for client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file 
I1120 08:23:09.194660       1 shared_informer.go:247] Caches are synced for client-ca::kube-system::extension-apiserver-authentication::client-ca-file 
I1120 08:23:09.194455       1 shared_informer.go:247] Caches are synced for RequestHeaderAuthRequestController 
E1120 08:23:10.420643       1 server.go:132] unable to fully scrape metrics: [unable to fully scrape metrics from node k8s-master3: unable to fetch metrics from node k8s-master3: Get "https://10.39.140.250:10250/stats/summary?only_cpu_and_memory=true": x509: cannot validate certificate for 10.39.140.250 because it doesn't contain any IP SANs, unable to fully scrape metrics from node k8s-master1: unable to fetch metrics from node k8s-master1: Get "https://10.39.140.248:10250/stats/summary?only_cpu_and_memory=true": x509: cannot validate certificate for 10.39.140.248 because it doesn't contain any IP SANs, unable to fully scrape metrics from node k8s-master2: unable to fetch metrics from node k8s-master2: Get "https://10.39.140.249:10250/stats/summary?only_cpu_and_memory=true": x509: cannot validate certificate for 10.39.140.249 because it doesn't contain any IP SANs, unable to fully scrape metrics from node k8s-node1: unable to fetch metrics from node k8s-node1: Get "https://10.39.140.251:10250/stats/summary?only_cpu_and_memory=true": x509: cannot validate certificate for 10.39.140.251 because it doesn't contain any IP SANs]
I1120 08:23:33.874949       1 requestheader_controller.go:183] Shutting down RequestHeaderAuthRequestController
I1120 08:23:33.874978       1 configmap_cafile_content.go:223] Shutting down client-ca::kube-system::extension-apiserver-authentication::client-ca-file
I1120 08:23:33.874993       1 configmap_cafile_content.go:223] Shutting down client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file
I1120 08:23:33.875019       1 tlsconfig.go:255] Shutting down DynamicServingCertificateController
I1120 08:23:33.875026       1 dynamic_serving_content.go:145] Shutting down serving-cert::/tmp/apiserver.crt::/tmp/apiserver.key
I1120 08:23:33.875041       1 secure_serving.go:241] Stopped listening on [::]:4443

이 호에 대한 소식이 없습니까? 이것에 대한 해결책도 갖고 싶습니다.

여기에 해결 방법을 문서화하고 있습니다.
https://github.com/kubernetes/website/pull/27071
https://github.com/kubernetes/kubeadm/issues/1602

이 문제를 계속 열어 둘 수는 있지만 기본적으로 kubeadm을 사용하여 서명자를 배포해야하는 복잡성으로 인해 조만간이 변경을 수행 할 가능성이 낮습니다.