Kubelet Authentication & Authorization

हैकट्रिक्स का समर्थन करें और लाभ प्राप्त करें!

क्यूबलेट प्रमाणीकरण

डिफ़ॉल्ट रूप से, क्यूबलेट के HTTPS एंडपॉइंट के लिए अन्य प्रमाणीकरण विधियों द्वारा अस्वीकृत नहीं किए जाने वाले अनुरोधों को गैर-पहचाने अनुरोध के रूप में व्यवहारिक रूप से लिया जाता है, और उन्हें system:anonymous उपयोगकर्ता नाम और system:unauthenticated समूह दिया जाता है।

3 प्रमाणीकरण विधियाँ हैं:

  • अनामित (डिफ़ॉल्ट): पैरामीटर --anonymous-auth=true या कॉन्फ़िगरेशन सेट करके उपयोग करें:

"authentication": {
"anonymous": {
"enabled": true
},
  • वेबहुक: इससे कुबेक्टल को सक्षम किया जाएगा जो कि अधिकृती के रूप में kubectl API बियरर टोकन को सक्षम करेगा (कोई भी मान्य टोकन मान्य होगा)। इसे निम्नलिखित सेटिंग के साथ सक्षम करें:

  • सुनिश्चित करें कि authentication.k8s.io/v1beta1 API समूह API सर्वर में सक्षम है

  • kubelet को --authentication-token-webhook और --kubeconfig फ़्लैग के साथ शुरू करें या निम्नलिखित सेटिंग का उपयोग करें:

"authentication": {
"webhook": {
"cacheTTL": "2m0s",
"enabled": true
},

कुबलेट कॉन्फ़िगर किए गए एपीआई सर्वर पर TokenReview एपीआई को कॉल करता है ताकि बियरर टोकन से उपयोगकर्ता जानकारी निर्धारित की जा सके।

  • X509 क्लाइंट प्रमाणपत्र: X509 क्लाइंट प्रमाणपत्र के माध्यम से प्रमाणित करने की अनुमति देते हैं

  • --client-ca-file फ़्लैग के साथ kubelet को शुरू करें, जिसमें CA बंडल प्रदान करें ताकि क्लाइंट प्रमाणपत्रों की सत्यापन की जा सके। या कॉन्फ़िग के साथ:

"authentication": {
"x509": {
"clientCAFile": "/etc/kubernetes/pki/ca.crt"
}
}

Kubelet अधिकृतता

कोई भी अनुरोध जो सफलतापूर्वक प्रमाणीकृत होता है (सम्मानित अनुरोध सहित) उसकी अधिकृतता फिर से होती हैडिफ़ॉल्ट अधिकृतता मोड है AlwaysAllow, जो सभी अनुरोधों की अनुमति देता है

हालांकि, दूसरे संभावित मान है webhook (जिसे आप अधिकांशतः वहां पाएंगे। इस मोड में, अधिकृत उपयोगकर्ता की अनुमतियों की जांच की जाती है ताकि कोई कार्रवाई अनुमति देने या न देने की हो सके।

ध्यान दें कि यदि अनामित प्रमाणीकरण सक्षम है, तो अनामित पहुंच कोई भी कार्रवाई करने की कोई अनुमति नहीं हो सकती है।

वेबहुक के माध्यम से अधिकृतता को --authorization-mode=Webhook पैरामीटर का उपयोग करके या कॉन्फ़िग फ़ाइल के माध्यम से कॉन्फ़िगर किया जा सकता है:

"authorization": {
"mode": "Webhook",
"webhook": {
"cacheAuthorizedTTL": "5m0s",
"cacheUnauthorizedTTL": "30s"
}
},

kubelet कॉन्फ़िगर्ड API सर्वर पर SubjectAccessReview API को कॉल करता है ताकि प्रत्येक अनुरोध की अधिकृतता निर्धारित कर सके।

kubelet एपीआई अनुरोधों की अधिकृतता को apiserver के साथी अनुरोध गुण प्रणाली का उपयोग करके करता है:

  • क्रिया

HTTP verbअनुरोध verb

POST

create

GET, HEAD

get (व्यक्तिगत संसाधनों के लिए), list (संग्रहों के लिए, पूर्ण ऑब्जेक्ट सामग्री के साथ), watch (व्यक्तिगत संसाधन या संसाधन संग्रह के लिए)

PUT

update

PATCH

patch

DELETE

delete (व्यक्तिगत संसाधनों के लिए), deletecollection (संग्रहों के लिए)

  • Kubelet एपीआई के साथ बातचीत करने वाला संसाधन हमेशा नोड्स होता है और सबरेसोर्स आगंतुक अनुरोध के पथ से निर्धारित होता है:

Kubelet एपीआईसंसाधनसबरेसोर्स

/stats/*

nodes

stats

/metrics/*

nodes

metrics

/logs/*

nodes

log

/spec/*

nodes

spec

अन्य सभी

nodes

proxy

उदाहरण के लिए, निम्नलिखित अनुरोध ने अनुमति के बिना kubelet के पॉड्स जानकारी तक पहुँच करने का प्रयास किया:

curl -k --header "Authorization: Bearer ${TOKEN}" 'https://172.31.28.172:10250/pods'
Forbidden (user=system:node:ip-172-31-28-172.ec2.internal, verb=get, resource=nodes, subresource=proxy)
  • हमें एक निषिद्ध मिला, इसलिए अनुरोध ने प्रमाणीकरण जांच पास कर दी। यदि ऐसा न होता, तो हमें केवल एक अनधिकृत संदेश मिलता।

  • हम उपयोगकर्ता नाम देख सकते हैं (इस मामले में टोकन से)

  • जांचें कि संसाधन क्या था, यहां तक ​​कि नोड्स और सबरेसोर्स क्या था, जो पिछली जानकारी के साथ संगत है

संदर्भ

हैकट्रिक्स का समर्थन करें और लाभ प्राप्त करें!

Last updated