Kubeadm: हस्ताक्षरित क्यूबलेट सेवारत प्रमाणपत्र का उपयोग करें

@ raravena80 मैं /var/lib/kubelet/pki/ तहत kubeadm द्वारा बनाए गए किसी भी प्रमाण पत्र से अवगत नहीं हूं। क्या आप कृपया अधिक जानकारी प्राप्त कर सकते हैं? जैसे kubeadm config फाइल, क्लस्टर बनाने के चरण

@fabriziopandini मुझे पूरी तरह से यकीन नहीं है कि अगर सीट्स कुबेदम द्वारा बनाई गई हैं, लेकिन सामान्य प्रक्रिया यहां वर्णित

निर्देशिका की सामग्री इस प्रकार दिखती है:

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.crt और kubelet.key फ़ाइलें क्यूबलेट द्वारा पहली बार लोड की गई हैं?

@ raravena80 स्पष्टीकरण के लिए धन्यवाद
संभवतः मेरे पास यहां पूरा संदर्भ नहीं है इसलिए मैं दूसरों को जवाब देने के लिए कमरे में छोड़ देता हूं।

केवल एक पक्ष नोट (यह मदद कर सकता है)
कुबेदम पहले से ही एक सर्टिफिकेट बनाता है जिसका नाम apiserver-kubelet-client ताकि एप सर्वर को क्यूबलेट्स के साथ सुरक्षित रूप से बात कर सकें; यह सीए द्वारा हस्ताक्षरित है और आवश्यक आरबीएसी नियमों के लिए बाध्य है।

/ असाइन करें @liztio

मुझे लगता है कि यह क्यूबलेट के सर्वर सेटर को प्री-जेनरेट करना है। मैं टीएलएस सर्वर बूटस्ट्रैप के लिए क्यूबलेट झंडे का उपयोग करने की कोशिश कर रहा हूं और सर्वर सेर्ट्स को घुमाता हूं, दुर्भाग्य से मैं बूटस्ट्रैप टोकन का उपयोग करके सर्वर सर्टिफिकेट का अनुरोध करने के लिए क्यूबलेट नहीं मिला। क्यूबलेट सर्वर सर्वर के लिए अपने डिफ़ॉल्ट व्यवहार पर वापस गिरता है, जो कि एक स्व-हस्ताक्षरित उत्पन्न करना है।

मेरे ज्ञान का सबसे अच्छा करने के लिए, इस समय केवल एक ही रास्ता है कि क्यूबलेट के सर्वर सेर-बैंड को उत्पन्न किया जाए और उन्हें एक नियत पथ पर रखा जाए और क्यूबलेट (कुबेदम द्वारा कॉन्फ़िगर किया गया) इसे उठाएगा, और तदनुसार कुछ क्यूबलेट झंडे सेट करेगा। ; संदर्भ: https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#client -and- सर्विंग-सर्टिफिकेट

apiserver-kubelet-client क्लाइंट सर्टिफिकेट है कि एपीआई सर्वर एक क्यूबलेट को प्रस्तुत करेगा, लेकिन क्यूलेट को उन ग्राहकों पर भरोसा करने के लिए कॉन्फ़िगर किया गया है जो 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 द्वारा हस्ताक्षरित किया जाना चाहिए, जो मूल प्रश्न के आसपास आता है।

इस सूत्र के अंत में कुछ प्रासंगिक चर्चा भी है: https://github.com/kubernetes/kubeadm/issues/118

मुझे लगता है कि kubeadm को एक वैध बूटस्ट्रैप टोकन के साथ सर्वर सर्टिफिकेट अनुरोधों के लिए CSR अप्रूवल जोड़ना पड़ सकता है, जैसे कि क्लाइंट सर्टिफिकेट रिक्वेस्ट के लिए होता है?

क्यूबलेट के बारे में क्या कहीं से एक कॉन्फ़िगरमैप पर अपना स्वयं का हस्ताक्षरित सीए अपलोड करना है? nodeadmission प्लगइन इसे केवल अपने स्वयं के कॉन्फ़िगरेशन में प्रतिबंधित कर सकता है। मैट्रिक्स-सर्वर नोड से संपर्क करने के लिए इसका उपयोग कर सकता है।

उस बारे में कोई विचार?

यदि संभव हो तो, मुझे लगता है कि हमें सर्विंग सर्टिफिकेट के लिए अनुरोध / घुमाने के लिए क्यूब्लेट में निर्मित टीएलएस बूटस्ट्रैपिंग सुविधाओं का उपयोग करना चाहिए।

@alexbrand मैं उस पर सहमत हूं

क्यूबलेट टीएलएस बूटस्ट्रैपिंग केवल ग्राहक प्रमाण पत्र उत्पन्न करता है जो भी कारण हो:
--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 पहले से ही ऐसा करता है। शायद यह एक क्यूबलेट सुविधा अनुरोध है?

इस मुद्दे को सारांशित करने देता है:

जैसा कि @anitgandhi द्वारा उल्लिखित है:
https://github.com/kubernetes/kubeadm/issues/1223#issuecomment -4545725777

यहाँ kubeadm के साथ समस्या यह है कि हम क्यूबलेट में झंडे के एक जोड़े को पारित नहीं कर रहे हैं:

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

इन झंडों के बिना यह क्यूबलेट स्व-हस्ताक्षर करने के लिए चूक जाता है, जब यह पहली बार चलता है, तो यह सेवा प्रमाणपत्र है, जिसे इसके साथ सत्यापित किया जा सकता है:

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.crt/key जोड़ी के गायन को लागू करता है, आदर्श रूप से /var/lib/kubelet/pki तहत और अतिरिक्त क्यूबलेट झंडे --tls-cert-file , --tls-private-key-file ।

बी) दस्तावेज़ का मतलब है कि इसे इसी तरह से डिमांड पर सक्षम किया जाए @ raravena80 ने इसे यहां कैसे किया: https://stackoverflow.com/questions/53212149/x509-certificate-signed-by-unknown-authority-kubeadm/53218524#53218524
सिवाय Kubernetes CSRs / kubeadm कमांड के उपयोग से।

ग) @alexbrand द्वारा टिप्पणी के रूप में

यदि संभव हो तो, मुझे लगता है कि हमें सर्विंग सर्टिफिकेट के लिए अनुरोध / घुमाने के लिए क्यूब्लेट में निर्मित टीएलएस बूटस्ट्रैपिंग सुविधाओं का उपयोग करना चाहिए।

डी)?

@ कुबेरनेट्स / सिग-क्लस्टर-जीवनचक्र
मुझे यह करने के लिए बग / सुविधा के बीच अंतरिक्ष में लगता है।

यह भी देखें:
https://github.com/kubernetes/community/pull/602/files

मुझे लगता है कि विकल्प B + C के बीच कुछ किया जाना चाहिए क्योंकि बहुत सारे बूटस्ट्रैप टोकन क्लाइंट सर्टिफिकेट / CSR लॉजिक क्यूबलेट + kubeadm के लिए सामान्य तर्क होगा।

इस मुद्दे को सारांशित करने देता है:

जैसा कि @anitgandhi द्वारा उल्लिखित है:
# 1223 (टिप्पणी)

यहाँ kubeadm के साथ समस्या यह है कि हम क्यूबलेट में झंडे के एक जोड़े को पारित नहीं कर रहे हैं:

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

इन झंडों के बिना यह क्यूबलेट स्व-हस्ताक्षर करने के लिए चूक जाता है, जब यह पहली बार चलता है, तो यह सेवा प्रमाणपत्र है, जिसे इसके साथ सत्यापित किया जा सकता है:

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.crt/key जोड़ी के गायन को लागू करता है, आदर्श रूप से /var/lib/kubelet/pki तहत और अतिरिक्त क्यूबलेट झंडे --tls-cert-file , --tls-private-key-file ।

बी) दस्तावेज़ का मतलब है कि इसे इसी तरह से डिमांड पर सक्षम किया जाए @ raravena80 ने इसे यहां कैसे किया: https://stackoverflow.com/questions/53212149/x509-certificate-signed-by-unknown-authority-kubeadm/53218524#53218524
सिवाय Kubernetes CSRs / kubeadm कमांड के उपयोग से।

ग) @alexbrand द्वारा टिप्पणी के रूप में

यदि संभव हो तो, मुझे लगता है कि हमें सर्विंग सर्टिफिकेट के लिए अनुरोध / घुमाने के लिए क्यूब्लेट में निर्मित टीएलएस बूटस्ट्रैपिंग सुविधाओं का उपयोग करना चाहिए।

डी)?

@ कुबेरनेट्स / सिग-क्लस्टर-जीवनचक्र
मुझे यह करने के लिए बग / सुविधा के बीच अंतरिक्ष में लगता है।

यह भी देखें:
https://github.com/kubernetes/community/pull/602/files

महान सारांश @ neolit123 । क्या आप जानते हैं कि क्या यह अगले चक्र पर फिसल जाएगा या प्रगति में काम करेगा जैसा कि हम बोलते हैं? मेट्रिक्स-सर्वर के कारण मुख्य रूप से पूछना जो हर तैनाती को लागू करना चाहता है;)

@randomvariable ने उल्लेख किया कि इसके लिए एक और समाधान है।
इस प्रकार की चर्चाओं से, हम क्लस्टर CA के साथ क्यूबलेट-सर्विंग सर्टिफिकेट पर हस्ताक्षर करने में संकोच कर रहे हैं। इस विषय पर और चर्चा की जरूरत है।

/ हटाने-मदद

क्योंकि कार्यान्वयन का समाधान अभी तक चुना नहीं गया है।

इस पर कोई आंदोलन? मैं एक kubeadm तैनात क्लस्टर के भीतर ऑटोस्कोलिंग सुविधाओं का समर्थन करने के लिए इसके खिलाफ चल रहा हूं।

क्यूबलेट प्रमाणपत्र के सीए चेकिंग को चालू करने के लिए वर्तमान समाधान है।

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

वास्तव में, यह डिजाइन प्रस्तावों पर अवरुद्ध है।
कई प्रकार के वर्कअराउंड हैं, लेकिन उन कामों को रोकने का काम है:
https://github.com/kubernetes/kubeadm/issues/1602

- क्यूबलेट-असुरक्षित- tls

यह सभी उपयोगकर्ताओं के लिए आदर्श नहीं हो सकता है।

90 डी निष्क्रियता के बाद मुद्दे बासी हो जाते हैं।
/remove-lifecycle stale साथ ताज़ा अंक को चिह्नित करें।
अतिरिक्त 30 डी निष्क्रियता के बाद बासी मुद्दे सड़ जाते हैं और अंततः बंद हो जाते हैं।

यदि यह समस्या अब बंद करने के लिए सुरक्षित है, तो कृपया /close साथ ऐसा करें।

सिग-टेस्टिंग, कुबेरनेट्स / टेस्ट-इन्फ्रा और / या फेज्टा को फीडबैक भेजें ।
/ जीवनचक्र बासी

/ जीवन चक्र जमे हुए

Kubeadm के साथ v1.18.2 क्लस्टर बनाने वाले इस सटीक मुद्दे में चल रहा है।

मेट्रिक्स-सर्वर सेट करते समय यह बिना kubelet-insecure-tls फ्लैग सेट करने के बिना काम नहीं करता है या "बैंड से बाहर", इसे kubernetes CA के साथ हस्ताक्षर करने के लिए प्रमाणपत्र जारी करता है।

मैंने क्यूबलेट क्लाइंट सर्टिफिकेट का फिर से उपयोग करने के बारे में सोचा था लेकिन यह CN = system:node:nodename और नो SANs को जारी किया गया है। और मैंने इसका परीक्षण किया था, हालांकि विचकोरे ने यह संकेत देने के लिए त्रुटि को बदल दिया। एक ही प्रमाण पत्र को सर्वर / क्लाइंट दोनों के रूप में इस्तेमाल किया जा सकता है अगर उसका नाम वैकल्पिक विषय के रूप में होता है? लेकिन मैं यह अनुमान लगा रहा हूं कि सर्वर / क्लाइंट के लिए अलग सेर का उपयोग करना अधिक उचित होगा?

/ हटाने-जीवन चक्र जमे हुए

/ जीवन चक्र जमे हुए

यह जमे हुए है ताकि बॉट्स समस्या को बंद न करें।

एक ही प्रमाण पत्र को सर्वर / क्लाइंट दोनों के रूप में इस्तेमाल किया जा सकता है अगर उसका नाम वैकल्पिक विषय के रूप में होता है?

सिद्धांत रूप में और जब तक कि क्यूबलेट उन्हें मान्य नहीं करता है - उदाहरण के लिए "क्लाइंट सर्टिफिकेट में SANs नहीं होना चाहिए"।

लेकिन मैं यह अनुमान लगा रहा हूं कि सर्वर / क्लाइंट के लिए अलग सेर का उपयोग करना अधिक उचित होगा?

यह उन मामलों में भी अलग से उपयोग करने के लिए सामान्य अभ्यास है जहां यह परिहार्य लगता है। यह संभव नहीं है कि क्यूबलेट / ऑर्टरी {z | n} बनाए रखने वाले इस विवरण को बदल देंगे।

अरे। थोड़ा और पचाया। क्यूबलेट विन्यास विकल्प serverTLSBootstrap: true वास्तव में सेवारत प्रमाण पत्र के लिए एक सीएसआर बना सकता है। लेकिन यह इसे अप्राप्त छोड़ देता है। जो ठीक हो सकता है?

दोनों rotateCertificates: true और serverTLSBootsrap: true और फिर सर्विंग सर्टिफिकेट के लिए CSR को मंजूरी देना यहां जाने का सबसे आसान तरीका लगता है। सेवारत / जारी किया गया प्रमाण पत्र O = system:nodes, CN = system:node:<nodename> के लिए विषय वैकल्पिक नामों के साथ DNS: <nodename>, IP Address: <node IP address>

Kubeadm को कम से कम सर्वरटूट्सबुटस्ट्रैप कॉन्फ़िगरेशन विकल्प को सक्षम करने के लिए करना चाहिए ताकि सर्वर प्रमाणपत्र का अनुमोदन करना एक आसान बात हो? या कुबेदम भी अनुमोदन कर सकता है?

अरे। थोड़ा और पचाया। क्यूबलेट विन्यास विकल्प serverTLSBootstrap: true वास्तव में सेवारत प्रमाण पत्र के लिए एक सीएसआर बना सकता है। लेकिन यह इसे अप्राप्त छोड़ देता है। जो ठीक हो सकता है?

दोनों rotateCertificates: true और serverTLSBootsrap: true और फिर सर्विंग सर्टिफिकेट के लिए CSR को मंजूरी देना यहां जाने का सबसे आसान तरीका लगता है। सेवारत / जारी किया गया प्रमाण पत्र O = system:nodes, CN = system:node:<nodename> के लिए विषय वैकल्पिक नामों के साथ DNS: <nodename>, IP Address: <node IP address>

Kubeadm को कम से कम सर्वरटूट्सबुटस्ट्रैप कॉन्फ़िगरेशन विकल्प को सक्षम करने के लिए करना चाहिए ताकि सर्वर प्रमाणपत्र का अनुमोदन करना एक आसान बात हो? या कुबेदम भी अनुमोदन कर सकता है?

सुरक्षा कार्यान्वयन सुनिश्चित नहीं है, लेकिन आप CSRs को https://github.com/kontena/kubelet-rubber-stamp को ऑटो-एप्रूव करने के लिए इस ऑपरेटर के साथ serverTLSBootstrap जोड़ सकते हैं।

Kubeadm को कम से कम सर्वरटूट्सबुटस्ट्रैप कॉन्फ़िगरेशन विकल्प को सक्षम करने के लिए करना चाहिए ताकि सर्वर प्रमाणपत्र का अनुमोदन करना एक आसान बात हो? या कुबेदम भी अनुमोदन कर सकता है?

kubeadm अनुमोदन नहीं कर सकता क्योंकि kubeadm डेमॉन नहीं है। इसे एक नियंत्रक / ऑपरेटर को तैनात करना होगा जो उपयोगकर्ता के लिए इसका प्रबंधन करता है। भविष्य में हो सकता है।

प्रमाणपत्र एपीआई जल्द ही जीए जाना चाहिए और उम्मीद है कि हम इसे k8 में प्रबंधित करने का एक बेहतर तरीका होने जा रहे हैं। कृपया देखें:
https://github.com/kubernetes/enhancements/issues/267
(अभी तक मुझे स्पष्ट नहीं है कि हम क्या करने जा रहे हैं ...)

हमारे पास वैकल्पिक विचार भी हैं। लेकिन अगर यह सब मीट्रिक-सर्वर के मुद्दे को हल करने की कोशिश कर रहा है, तो आप बस https://github.com/brancz/kube-rbac-proxy का उपयोग कर सकते हैं जो kubelet के लिए MS अनुरोधों पर SAR कर सकते हैं। दुख की बात है कि यह अभी तक हमारी ओर से प्रलेखित नहीं है:
https://github.com/kubernetes/kubeadm/issues/1602

@ neolit123 मैंने कम से कम इसे --kubelet-insecure-tls साथ MS को फ़्लैग करने का कोर्स, लेकिन मैं वास्तव में यह देखना चाहता था कि इसे सुरक्षित तरीके से कैसे ठीक किया जाए और फिर बस इस मुद्दे पर दिलचस्पी हुई। 🙂

अभी के लिए मेरे लिए serverTLSbootstrap ध्वज को क्यूबलेट कॉन्फ़िगरेशन में जोड़ना आसान है और प्रमाणपत्रों को मैन्युअल रूप से अनुमोदित करता है। मैंने हालांकि इसका एक पहलू देखा है, जो यह है कि आप नोड पर पॉड्स के साथ तब तक बातचीत नहीं कर सकते जब तक कि आप सर्टिफिकेट को मंजूरी नहीं देते। (उदाहरण के लिए अनुमोदन से पहले नोड पर चलने वाले पॉड्स पर kubectl निष्पादित करने में विफल रहता है)

मैं संवर्द्धन मुद्दे के साथ भी पालन करूँगा। धन्यवाद।

यह वास्तव में दुखद है कि कुबेदाम के साथ जो काफी हद तक परिपक्व प्रतीत होता है क्यूबलेट प्रमाण पत्र के लिए परिणाम स्वयं हस्ताक्षरित हैं और बहुत से लोग चीजों को ठीक से करने और आदि के बजाय मैट्रिक्स सर्वर के लिए kubelet-insecure-tls चुनते हैं :(

यह एक जटिल समस्या है।

प्रयास करें:
https://github.com/kontena/kubelet-rubber-stamp
या
https://github.com/brancz/kube-rbac-proxy
workarounds के रूप में

यह एक जटिल समस्या है।

प्रयास करें:
https://github.com/kontena/kubelet-rubber-stamp
या
https://github.com/brancz/kube-rbac-proxy
workarounds के रूप में

वास्तव में https://github.com/kontena/kubelet-rubber-stamp बहुत अच्छा काम करता है और इमोजी प्रॉक्सी के बजाय अधिक सही समाधान लगता है।

चरण 1:
जोड़ना
serverTLSBootstrap: true प्रत्येक के अंत में /var/lib/kubelet/config.yaml क्यूबलेट्स पुनर्निधारण के लिए /var/lib/kubelet/config.yaml

चरण दो:
क्यूबलेट-रबर-स्टैम्प की तैनाती करें

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 के दौरान क्लस्टर बनाने के लिए आपको serverTLSBootstrap सेट करने के लिए KubeletConfiguration API ऑब्जेक्ट फ़ाइल में पास करने में सक्षम होना चाहिए।

`` `kubeadm-config.yaml
apiVersion: kubeadm.k8s.io/v1beta2
तरह: क्लस्टरस्टरफिगरेशन

...

apiVersion: kubelet.config.k8s.io/v1beta1
तरह: KubeletConfiguration
serverTLSBootstrap: सच है

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

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

To get the CSRs

kubectl को csr मिलता है
NAME AGE SIGNERNAME REQUESTOR CONDITION
csr-2qkdw 2m1s kubernetes.io/kube-apiserver-client-kubelet सिस्टम: बूटस्ट्रैप : fcufbo स्वीकृत, जारी किए गए
सीएसआर -9wvgt 114s kubernetes.io/kubelet-serves सिस्टम: नोड : वर्कर -1
सीएसआर-lz97v 4m58s kubernetes.io/kubelet-serving सिस्टम: नोड : गुरु-1 विचाराधीन
सीएसआर- rsdsp 4m59s kubernetes.io/kube-apiserver-client-kubelet सिस्टम: नोड : मास्टर -1 स्वीकृत, जारी
सीएसआर-wgxqs 4m49s kubernetes.io/kubelet-serving सिस्टम: नोड : गुरु-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 प्रमाणपत्र csr-ab123 # या रबर-स्टैम्प की तैनाती को मंजूरी देता है!

kubectl को csr मिलता है
NAME AGE SIGNERNAME REQUESTOR CONDITION
सीएसआर-9wvgt 3m kubernetes.io/kubelet-serving सिस्टम: नोड : कार्यकर्ता -1 स्वीकृत, जारी किए गए
...
`` `

एक और विचित्र बात यहाँ प्रतीत होती है btw, जो यह है कि मास्टर नोड बनाने के लिए लगता है कि यह दो बार सीएसआर है। (कम से कम दो बार मैंने यह कोशिश की)

लेकिन जैसा कि @nijave ऊपर की टिप्पणी में कहता है, मुझे यकीन नहीं है कि रबर-स्टैपर का उपयोग करने के सुरक्षा निहितार्थ क्या हैं।

@allir , @vainkop जहाँ तक है, मैं देख सकता हूँ कि क्यूबलेट-रबर-स्टैम्प केवल सत्यापित करता है कि CSR का सामान्य नाम आवश्यक नाम से मेल खाता है, लेकिन यह सत्यापित नहीं करता है कि क्यूबलेट द्वारा अनुरोधित अतिरिक्त होस्टनाम और IP पते मान्य हैं या नहीं। इसका मतलब है कि एक हमलावर जिसके पास क्यूबलेट क्लाइंट प्रमाणपत्र तक पहुंच है, वह मूल रूप से किसी भी डोमेन नाम या आईपी पते के लिए प्रमाण पत्र बना सकता है। सभी क्लाइंट जो रूट CA पर भरोसा करने के लिए कॉन्फ़िगर किए गए हैं, फिर इस प्रमाणपत्र को स्वीकार करेंगे।
बेशक होस्टनाम और आईपी पते जो किसी दिए गए क्यूबलेट के लिए मान्य हैं, कठिन है क्योंकि वर्तमान में कोई प्राधिकरण नहीं है जो पुष्टि कर सकता है कि क्यूबलेट को अनुरोध करने की अनुमति है या नहीं। उदाहरण के लिए एपीआई सर्वर पर नोड ऑब्जेक्ट का उपयोग करना पर्याप्त नहीं है क्योंकि क्यूबलेट ऑब्जेक्ट को बिना सीमा के अपडेट कर सकते हैं।

अरे, बस उस @vainkop को जोड़ना है
अपने प्रारंभिक kubeadm init के दौरान क्लस्टर बनाने के लिए आपको serverTLSBootstrap सेट करने के लिए KubeletConfiguration API ऑब्जेक्ट फ़ाइल में पास करने में सक्षम होना चाहिए।
kubeadm init --config=kubeadm-config.yaml
तब सभी क्यूबलेट स्वतः serverTLSBootstrap ध्वज का उपयोग करके सेट हो जाएंगे।

या एक मौजूदा K8s के लिए सेटअप का उपयोग कर सकते हैं, यह हो सकता है:

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

+ क्यूबलेट्स को पुनः आरंभ करें

वाह मैं बहुत खुश हूं कि मुझे यह मुद्दा मिला, और मैं अकेला नहीं हूं जो इस उचित तरीके से बनाना चाहता हूं। :)

अब मुझे इस मुद्दे पर अपने विचार साझा करने दें (कृपया मुझे सही करें अगर मैं कहीं गलत हूं) :

मूल समस्या की पहली दृष्टि:
वर्तमान में kubeadm डिफ़ॉल्ट रूप से सभी क्यूबलेट्स के लिए वेबहूक प्रमाणीकरण सक्षम करता है, इसलिए क्यूबलेट आने वाले कनेक्शन के लिए क्लाइंट प्रमाणपत्रों को मान्य कर रहा है, भले ही --kubelet-insecure-tls विकल्प निर्दिष्ट किया गया हो।
दूसरी तरफ से मेट्रिक्स-सर्वर के पास विशिष्ट क्यूबलेट प्रमाण पत्र को सत्यापित करने के लिए कोई अपारदर्शिता नहीं है क्योंकि यह नोड पर स्व-हस्ताक्षरित है।

मैट्रिक्स-सर्वर के लिए --kubelet-insecure-tls का उपयोग करने के संभावित जोखिम:
जबकि क्यूबलेट डेटा कुछ हद तक सुरक्षित है और कभी भी सफल webhook प्रमाणीकरण के बिना मैट्रिक्स-सर्वर को प्रदान नहीं किया जाएगा।
सिद्धांत रूप में कोई व्यक्ति सर्वर आईपी या होस्टनाम से समझौता कर सकता है और गलत आँकड़े प्रदान कर सकता है। लेकिन कनेक्शन स्थापित करने के लिए मीट्रिक आईपी-एड्रेस का उपयोग कर रहा है और क्यूब-अपीज़र के माध्यम से नोड के लिए निर्दिष्ट होस्टनाम का उपयोग कर रहा है, इसलिए हमलावर को एपीआई-सर्वर, डीएनएस या नोड आईपी-एड्रेस को पहले हैक करना होगा।

थोड़ा अवलोकन:
मेट्रिक्स-सर्वर एकल सेवा नहीं है जो सीधे क्यूबलेट्स तक पहुंच रही है। कंटेनर लॉग को पढ़ने या उन पर शेल को निष्पादित करने के लिए कूब-अपीज़र भी ऐसा कर रहा है। अच्छा सवाल यह है कि क्यूब-अपीज़र यह सुनिश्चित करता है कि यह विशिष्ट क्यूबलेट के साथ संबंध स्थापित कर रहा है जबकि सीए के बारे में कोई जानकारी नहीं है कि यह प्रमाण पत्र जारी किया है?
क्या इस मामले में --kubelet-insecure-tls विकल्प के साथ मैट्रिक्स सर्वर के समान व्यवहार नहीं होता है?

संभावित स्थिति:
आजकल वेबबुक और एपीआई एकत्रीकरण कुबेरनेट्स में काफी लोकप्रिय हैं। यह सभी एक ही तरह से व्यवहार करते हैं, यह स्वयं के सीए और सीआरटी / कुंजी जोड़ी उत्पन्न करके है। सीए हैश को एक विशिष्ट संसाधन में भी संग्रहित किया जाता है, जो क्यूब-अपीज़र प्रदान करता है कि वह किस प्रमाणपत्र पर भरोसा कर सकता है।

उदाहरण के लिए:

• APIServices अपने apiservices.apiregistration.k8s.io संसाधन में संबंधित CA हैश का भंडारण कर रहे हैं:

  spec:
  caBundle: <ca-hash>
  

• Webhooks अपने validatingwebhookconfigurations.admissionregistration.k8s.io और mutatingwebhookconfigurations.admissionregistration.k8s.io संसाधनों में संबंधित CA हैश का भंडारण कर रहे हैं:

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

मेरे लिए यह बहुत स्पष्ट है कि प्रत्येक नोड संसाधन के समान caBundle उनके spec , जहां क्यूबलेट अपने क्लाइंट प्रमाणपत्र का उपयोग करके सेवा करने के लिए अपने स्वयं के सीए को पंजीकृत कर सकते हैं:

spec:
  caBundle: <ca-hash>

मेट्रिस-सर्वर और क्यूब-अपीज़र दोनों को क्यूबलेट्स के कनेक्शन को सत्यापित करने और भरोसा करने के लिए इन प्रमाणपत्रों का उपयोग करना चाहिए।

@ kfox1111 के लिए धन्यवाद जिन्होंने पहले एक समान विचार व्यक्त किया था https://github.com/kubernetes/kubeadm/issues/1223#issuecomment -460854312

अच्छा सवाल यह है कि क्यूब-अपीज़र यह सुनिश्चित करता है कि यह विशिष्ट क्यूबलेट के साथ संबंध स्थापित कर रहा है जबकि सीए के बारे में कोई जानकारी नहीं है कि यह प्रमाण पत्र जारी किया है?
क्या इस मामले में --kubelet-insecure-tls विकल्प के साथ मैट्रिक्स सर्वर के समान व्यवहार नहीं करता है?

इस प्रश्न का उत्तर देने के लिए मैं यहां @luxas उद्धरण

दाईं ओर, हम एपी सर्वर से क्यूबलेट सर्वरों से सत्यापित किए गए कनेक्शन नहीं बना सकते हैं, क्योंकि प्रत्येक क्यूबलेट का अपना स्व-हस्ताक्षरित प्रमाण पत्र है। हम भविष्य में सेवारत वर्गों को सेवारत करने के लिए एक मैनुअल अनुमोदन पर विचार कर सकते हैं, लेकिन यह डिफ़ॉल्ट रूप से सुरक्षित नहीं है।

https://github.com/kubernetes/kubeadm/issues/118#issuecomment -4049492929 से

आशा है कि इसे किसी दिन हल किया जा सकता है

[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

हम इस मुद्दे को खुला रख सकते हैं, लेकिन डिफ़ॉल्ट रूप से कुबेदम के साथ हस्ताक्षरकर्ता को तैनात करने की आवश्यकता की जटिलताओं के कारण, यह संभावना नहीं है कि हम जल्द ही यह बदलाव करने जा रहे हैं।