Kubernetes Basics
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
The original author of this page is Jorge (read his original post here)
कंटेनर/को कंटेनर इंजन में चलाने की अनुमति देता है।
शेड्यूल कंटेनरों को मिशन कुशल बनाता है।
कंटेनरों को जीवित रखता है।
कंटेनर संचार की अनुमति देता है।
तैनाती तकनीकों की अनुमति देता है।
जानकारी की मात्रा को संभालता है।
Node: ऑपरेटिंग सिस्टम जिसमें पॉड या पॉड्स होते हैं।
Pod: एक कंटेनर या कई कंटेनरों के चारों ओर लपेटने वाला। एक पॉड में केवल एक एप्लिकेशन होना चाहिए (इसलिए आमतौर पर, एक पॉड केवल 1 कंटेनर चलाता है)। पॉड वह तरीका है जिससे कुबेरनेट्स चल रही कंटेनर तकनीक को अमूर्त करता है।
Service: प्रत्येक पॉड का 1 आंतरिक IP पता होता है जो नोड के आंतरिक रेंज से होता है। हालाँकि, इसे एक सेवा के माध्यम से भी उजागर किया जा सकता है। सेवा का भी एक IP पता होता है और इसका लक्ष्य पॉड्स के बीच संचार बनाए रखना है ताकि यदि एक मर जाता है तो नया प्रतिस्थापन (एक अलग आंतरिक IP के साथ) उसी सेवा के IP पर उपलब्ध होगा। इसे आंतरिक या बाहरी के रूप में कॉन्फ़िगर किया जा सकता है। सेवा तब भी कार्य करती है जब 2 पॉड्स एक ही सेवा से जुड़े होते हैं।
जब एक सेवा बनाई जाती है, तो आप प्रत्येक सेवा के अंत बिंदुओं को kubectl get endpoints चलाकर पा सकते हैं।
Kubelet: प्राथमिक नोड एजेंट। वह घटक जो नोड और कुबectl के बीच संचार स्थापित करता है, और केवल पॉड्स चला सकता है (API सर्वर के माध्यम से)। कुबलेट उन कंटेनरों का प्रबंधन नहीं करता है जो कुबेरनेट्स द्वारा नहीं बनाए गए थे।
Kube-proxy: वह सेवा है जो apiserver और नोड के बीच संचार (सेवाओं) के लिए जिम्मेदार है। आधार नोड्स के लिए IPtables है। सबसे अनुभवी उपयोगकर्ता अन्य विक्रेताओं से अन्य kube-proxies स्थापित कर सकते हैं।
Sidecar container: साइडकार कंटेनर वे कंटेनर हैं जो पॉड में मुख्य कंटेनर के साथ चलने चाहिए। यह साइडकार पैटर्न वर्तमान कंटेनरों की कार्यक्षमता को बिना बदले बढ़ाता और बढ़ाता है। आजकल, हम जानते हैं कि हम एप्लिकेशन को कहीं भी चलाने के लिए सभी निर्भरताओं को लपेटने के लिए कंटेनर तकनीक का उपयोग करते हैं। एक कंटेनर केवल एक काम करता है और वह काम बहुत अच्छा करता है।
Master process:
Api Server: यह वह तरीका है जिससे उपयोगकर्ता और पॉड मास्टर प्रक्रिया के साथ संवाद करते हैं। केवल प्रमाणित अनुरोधों की अनुमति दी जानी चाहिए।
Scheduler: शेड्यूलिंग का तात्पर्य यह सुनिश्चित करने से है कि पॉड्स को नोड्स से मिलाया जाए ताकि कुबलेट उन्हें चला सके। इसमें यह तय करने के लिए पर्याप्त बुद्धिमत्ता है कि कौन सा नोड अधिक उपलब्ध संसाधनों के साथ है और नए पॉड को सौंपता है। ध्यान दें कि शेड्यूलर नए पॉड्स शुरू नहीं करता है, यह केवल नोड के अंदर चल रहे कुबलेट प्रक्रिया के साथ संवाद करता है, जो नए पॉड को लॉन्च करेगा।
Kube Controller manager: यह संसाधनों जैसे कि रिप्लिका सेट या तैनातियों की जांच करता है यह देखने के लिए कि, उदाहरण के लिए, सही संख्या में पॉड्स या नोड्स चल रहे हैं। यदि कोई पॉड गायब है, तो यह एक नया शुरू करने के लिए शेड्यूलर के साथ संवाद करेगा। यह API के लिए प्रतिकृति, टोकन और खाता सेवाओं को नियंत्रित करता है।
etcd: डेटा भंडारण, स्थायी, सुसंगत, और वितरित। यह कुबेरनेट्स का डेटाबेस है और कुंडल के पूर्ण राज्य को रखने के लिए कुंजी-मूल्य भंडारण है (यहाँ प्रत्येक परिवर्तन लॉग किया जाता है)। शेड्यूलर या कंट्रोलर प्रबंधक जैसे घटक इस डेटा पर निर्भर करते हैं यह जानने के लिए कि कौन से परिवर्तन हुए हैं (नोड्स के उपलब्ध संसाधन, चल रहे पॉड्स की संख्या...)।
Cloud controller manager: यह प्रवाह नियंत्रण और अनुप्रयोगों के लिए विशिष्ट नियंत्रक है, यानी: यदि आपके पास AWS या OpenStack में क्लस्टर हैं।
ध्यान दें कि चूंकि कई नोड्स (कई पॉड्स चला रहे हैं) हो सकते हैं, इसलिए कई मास्टर प्रक्रियाएँ भी हो सकती हैं जिनका एपीआई सर्वर तक पहुंच लोड संतुलित होती है और उनका etcd समन्वयित होता है।
Volumes:
जब एक पॉड डेटा बनाता है जो पॉड के गायब होने पर नहीं खोना चाहिए, तो इसे एक भौतिक वॉल्यूम में संग्रहीत किया जाना चाहिए। कुबेरनेट्स एक पॉड में डेटा को स्थायी बनाने के लिए एक वॉल्यूम संलग्न करने की अनुमति देता है। वॉल्यूम स्थानीय मशीन में या दूरस्थ भंडारण में हो सकता है। यदि आप विभिन्न भौतिक नोड्स में पॉड्स चला रहे हैं, तो आपको एक दूरस्थ भंडारण का उपयोग करना चाहिए ताकि सभी पॉड्स इसे एक्सेस कर सकें।
Other configurations:
ConfigMap: आप सेवाओं तक पहुँचने के लिए URLs कॉन्फ़िगर कर सकते हैं। पॉड यहाँ से डेटा प्राप्त करेगा यह जानने के लिए कि बाकी सेवाओं (पॉड्स) के साथ कैसे संवाद करना है। ध्यान दें कि यह क्रेडेंशियल्स को सहेजने के लिए अनुशंसित स्थान नहीं है!
Secret: यह गुप्त डेटा जैसे पासवर्ड, API कुंजी... को B64 में एन्कोड करने के लिए स्टोर करने का स्थान है। पॉड इस डेटा को आवश्यक क्रेडेंशियल्स का उपयोग करने के लिए एक्सेस कर सकेगा।
Deployments: यह वह स्थान है जहाँ कुबेरनेट्स द्वारा चलाए जाने वाले घटकों को इंगित किया जाता है। एक उपयोगकर्ता आमतौर पर पॉड्स के साथ सीधे काम नहीं करेगा, पॉड्स को ReplicaSets (एक समान पॉड्स की संख्या जो दोहराई जाती है) में अमूर्त किया जाता है, जिन्हें तैनातियों के माध्यम से चलाया जाता है। ध्यान दें कि तैनातियाँ stateless अनुप्रयोगों के लिए होती हैं। तैनाती के लिए न्यूनतम कॉन्फ़िगरेशन नाम और चलाने के लिए छवि है।
StatefulSet: यह घटक विशेष रूप से डेटाबेस जैसे अनुप्रयोगों के लिए है जिन्हें एक ही भंडारण तक पहुँचने की आवश्यकता होती है।
Ingress: यह वह कॉन्फ़िगरेशन है जिसका उपयोग URL के साथ अनुप्रयोग को सार्वजनिक रूप से उजागर करने के लिए किया जाता है। ध्यान दें कि यह बाहरी सेवाओं का उपयोग करके भी किया जा सकता है, लेकिन यह अनुप्रयोग को उजागर करने का सही तरीका है।
यदि आप एक इनग्रेस लागू करते हैं, तो आपको Ingress Controllers बनाने की आवश्यकता होगी। इनग्रेस कंट्रोलर एक पॉड है जो वह अंत बिंदु होगा जो अनुरोध प्राप्त करेगा और उन्हें जांचेगा और सेवाओं के लिए लोड संतुलित करेगा। इनग्रेस कंट्रोलर कॉन्फ़िगर किए गए इनग्रेस नियमों के आधार पर अनुरोध भेजेगा। ध्यान दें कि इनग्रेस नियम विभिन्न पथों या यहां तक कि विभिन्न आंतरिक कुबेरनेट्स सेवाओं के लिए उपडोमेन की ओर इशारा कर सकते हैं।
एक बेहतर सुरक्षा प्रथा यह होगी कि किसी भी कुबेरनेट्स क्लस्टर के भाग को उजागर न करने के लिए एक क्लाउड लोड बैलेंसर या प्रॉक्सी सर्वर का उपयोग किया जाए।
जब कोई अनुरोध प्राप्त होता है जो किसी भी इनग्रेस नियम से मेल नहीं खाता है, तो इनग्रेस कंट्रोलर इसे "डिफ़ॉल्ट बैकएंड" की ओर निर्देशित करेगा। आप इस पैरामीटर के पते को प्राप्त करने के लिए इनग्रेस कंट्रोलर का describe कर सकते हैं।
minikube addons enable ingress
CA क्लस्टर के भीतर सभी प्रमाणपत्रों के लिए विश्वसनीय रूट है।
घटकों को एक-दूसरे को मान्य करने की अनुमति देता है।
सभी क्लस्टर प्रमाणपत्र CA द्वारा हस्ताक्षरित होते हैं।
ETCd का अपना प्रमाणपत्र है।
प्रकार:
apiserver cert.
kubelet cert.
scheduler cert.
Minikube का उपयोग कुछ त्वरित परीक्षण करने के लिए किया जा सकता है कुबेरनेट्स पर बिना पूरे कुबेरनेट्स वातावरण को तैनात किए। यह एक मशीन में मास्टर और नोड प्रक्रियाओं को चलाएगा। Minikube नोड चलाने के लिए वर्चुअल बॉक्स का उपयोग करेगा। देखें यहाँ इसे स्थापित करने का तरीका।
Kubectl क्यूबेरनेट्स क्लस्टर के लिए कमांड लाइन टूल है। यह क्यूबेरनेट्स में क्रियाएँ करने या डेटा मांगने के लिए मास्टर प्रक्रिया के एपीआई सर्वर के साथ संवाद करता है।
डैशबोर्ड आपको यह देखने की अनुमति देता है कि मिनीक्यूब क्या चला रहा है, आप इसे एक्सेस करने के लिए URL यहाँ पा सकते हैं:
प्रत्येक कॉन्फ़िगरेशन फ़ाइल में 3 भाग होते हैं: metadata, specification (क्या लॉन्च करना है), status (इच्छित स्थिति)। डिप्लॉयमेंट कॉन्फ़िगरेशन फ़ाइल की स्पेसिफिकेशन के अंदर आप एक टेम्पलेट पा सकते हैं जो चलाने के लिए इमेज को परिभाषित करने के लिए एक नई कॉन्फ़िगरेशन संरचना के साथ परिभाषित है:
Example of Deployment + Service declared in the same configuration file (from here)
चूंकि एक सेवा आमतौर पर एक डिप्लॉयमेंट से संबंधित होती है, इसलिए दोनों को एक ही कॉन्फ़िगरेशन फ़ाइल में घोषित करना संभव है (इस कॉन्फ़िगरेशन में घोषित सेवा केवल आंतरिक रूप से सुलभ है):
बाहरी सेवा कॉन्फ़िगरेशन का उदाहरण
यह सेवा बाहरी रूप से सुलभ होगी (चेक करें nodePort और type: LoadBlancer विशेषताएँ):
यह परीक्षण के लिए उपयोगी है लेकिन उत्पादन के लिए आपको केवल आंतरिक सेवाएँ और एप्लिकेशन को उजागर करने के लिए एक Ingress होना चाहिए।
Ingress कॉन्फ़िग फ़ाइल का उदाहरण
यह एप्लिकेशन को http://dashboard.com पर उजागर करेगा।
Example of secrets config file
ध्यान दें कि पासवर्ड B64 में एन्कोडेड हैं (जो सुरक्षित नहीं है!)
ConfigMap का उदाहरण
एक ConfigMap वह कॉन्फ़िगरेशन है जो पॉड्स को दिया जाता है ताकि वे जान सकें कि अन्य सेवाओं को कैसे ढूंढना और उन तक पहुंचना है। इस मामले में, प्रत्येक पॉड को पता होगा कि नाम mongodb-service एक पॉड का पता है जिससे वे संवाद कर सकते हैं (यह पॉड एक mongodb निष्पादित करेगा):
फिर, एक deployment config के अंदर, इस पते को इस प्रकार निर्दिष्ट किया जा सकता है ताकि यह pod के env के अंदर लोड हो सके:
उदाहरण वॉल्यूम कॉन्फ़िगरेशन
आप विभिन्न स्टोरेज कॉन्फ़िगरेशन yaml फ़ाइलों के उदाहरण https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes पर पा सकते हैं। ध्यान दें कि वॉल्यूम नामस्पेस के अंदर नहीं हैं
Kubernetes एक ही भौतिक क्लस्टर द्वारा समर्थित कई आभासी क्लस्टर का समर्थन करता है। इन आभासी क्लस्टरों को नामस्पेस कहा जाता है। ये उन वातावरणों में उपयोग के लिए हैं जहां कई उपयोगकर्ता कई टीमों या परियोजनाओं में फैले हुए हैं। कुछ से लेकर दर्जनों उपयोगकर्ताओं वाले क्लस्टरों के लिए, आपको नामस्पेस बनाने या उनके बारे में सोचने की आवश्यकता नहीं होनी चाहिए। आपको केवल नामस्पेस का उपयोग करना शुरू करना चाहिए ताकि आप kubernetes में तैनात प्रत्येक भाग के बेहतर नियंत्रण और संगठन को प्राप्त कर सकें।
नामस्पेस नामों के लिए एक दायरा प्रदान करते हैं। संसाधनों के नाम को एक नामस्पेस के भीतर अद्वितीय होना चाहिए, लेकिन नामस्पेस के बीच नहीं। नामस्पेस एक-दूसरे के अंदर नहीं हो सकते और प्रत्येक Kubernetes संसाधन केवल एक नामस्पेस में ही हो सकता है।
यदि आप minikube का उपयोग कर रहे हैं तो डिफ़ॉल्ट रूप से 4 नामस्पेस हैं:
kube-system: यह उपयोगकर्ताओं के लिए नहीं है और आपको इसे छूना नहीं चाहिए। यह मास्टर और kubectl प्रक्रियाओं के लिए है।
kube-public: सार्वजनिक रूप से सुलभ डेटा। इसमें एक configmap है जो क्लस्टर की जानकारी रखता है।
kube-node-lease: एक नोड की उपलब्धता निर्धारित करता है।
default: वह नामस्थान जिसे उपयोगकर्ता संसाधन बनाने के लिए उपयोग करेगा।
ध्यान दें कि अधिकांश Kubernetes संसाधन (जैसे pods, services, replication controllers, और अन्य) कुछ namespaces में होते हैं। हालाँकि, अन्य संसाधन जैसे namespace संसाधन और निम्न-स्तरीय संसाधन, जैसे nodes और persistentVolumes एक namespace में नहीं होते हैं। यह देखने के लिए कि कौन से Kubernetes संसाधन namespace में हैं और कौन से नहीं:
आप उस संदर्भ में सभी बाद के kubectl कमांड के लिए नामस्थान को सहेज सकते हैं।
Helm Kubernetes के लिए पैकेज प्रबंधक है। यह YAML फ़ाइलों को पैकेज करने और उन्हें सार्वजनिक और निजी रिपॉजिटरी में वितरित करने की अनुमति देता है। इन पैकेजों को Helm Charts कहा जाता है।
Helm एक टेम्पलेट इंजन भी है जो वेरिएबल के साथ कॉन्फ़िग फ़ाइलें उत्पन्न करने की अनुमति देता है:
एक Secret एक ऑब्जेक्ट है जो संवेदनशील डेटा जैसे पासवर्ड, टोकन या कुंजी को शामिल करता है। ऐसी जानकारी अन्यथा एक Pod स्पेसिफिकेशन या एक इमेज में रखी जा सकती है। उपयोगकर्ता Secrets बना सकते हैं और सिस्टम भी Secrets बनाता है। एक Secret ऑब्जेक्ट का नाम एक मान्य DNS उपडोमेन नाम होना चाहिए। यहाँ पढ़ें आधिकारिक दस्तावेज़।
Secrets कुछ इस प्रकार हो सकते हैं:
API, SSH Keys.
OAuth tokens.
Credentials, Passwords (plain text या b64 + encryption)।
जानकारी या टिप्पणियाँ।
डेटाबेस कनेक्शन कोड, स्ट्रिंग्स…।
Kubernetes में विभिन्न प्रकार के secrets होते हैं
Opaque
मनमाने उपयोगकर्ता-परिभाषित डेटा (डिफ़ॉल्ट)
kubernetes.io/service-account-token
सेवा खाता टोकन
kubernetes.io/dockercfg
अनुक्रमित ~/.dockercfg फ़ाइल
kubernetes.io/dockerconfigjson
अनुक्रमित ~/.docker/config.json फ़ाइल
kubernetes.io/basic-auth
मूल प्रमाणीकरण के लिए क्रेडेंशियल
kubernetes.io/ssh-auth
SSH प्रमाणीकरण के लिए क्रेडेंशियल
kubernetes.io/tls
TLS क्लाइंट या सर्वर के लिए डेटा
bootstrap.kubernetes.io/token
बूटस्ट्रैप टोकन डेटा
Opaque प्रकार डिफ़ॉल्ट है, उपयोगकर्ताओं द्वारा परिभाषित सामान्य कुंजी-मूल्य जोड़ी।
Secrets कैसे काम करते हैं:
निम्नलिखित कॉन्फ़िगरेशन फ़ाइल एक secret को परिभाषित करती है जिसे mysecret कहा जाता है जिसमें 2 कुंजी-मूल्य जोड़े username: YWRtaW4= और password: MWYyZDFlMmU2N2Rm होते हैं। यह एक pod को भी परिभाषित करता है जिसे secretpod कहा जाता है जो mysecret में परिभाषित username और password को environment variables SECRET_USERNAME __ और __ SECRET_PASSWOR में उजागर करेगा। यह 0640 अनुमतियों के साथ /etc/foo/my-group/my-username पथ में mysecret के अंदर username secret को भी mount करेगा।
etcd एक सुसंगत और उच्च-उपलब्धता वाला की-मान भंडार है, जिसका उपयोग Kubernetes द्वारा सभी क्लस्टर डेटा के लिए बैकिंग स्टोर के रूप में किया जाता है। चलिए etcd में संग्रहीत रहस्यों तक पहुँचते हैं:
आप देखेंगे कि सर्ट्स, कीज़ और यूआरएल फ़ाइल सिस्टम में कहां स्थित हैं। एक बार जब आप इसे प्राप्त कर लेते हैं, तो आप etcd से कनेक्ट करने में सक्षम होंगे।
एक बार जब आप संचार स्थापित कर लेते हैं, तो आप रहस्यों को प्राप्त करने में सक्षम होंगे:
ETCD में एन्क्रिप्शन जोड़ना
डिफ़ॉल्ट रूप से सभी रहस्य सादा पाठ में etcd के अंदर संग्रहीत होते हैं जब तक कि आप एक एन्क्रिप्शन परत लागू नहीं करते। निम्नलिखित उदाहरण https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ पर आधारित है।
इसके बाद, आपको kube-apiserver पर --encryption-provider-config ध्वज सेट करना होगा ताकि यह बनाए गए कॉन्फ़िग फ़ाइल के स्थान की ओर इशारा करे। आप /etc/kubernetes/manifest/kube-apiserver.yaml को संशोधित कर सकते हैं और निम्नलिखित पंक्तियाँ जोड़ सकते हैं:
नीचे स्क्रॉल करें volumeMounts में:
नीचे volumeMounts में hostPath पर स्क्रॉल करें:
डेटा के एन्क्रिप्टेड होने की पुष्टि करना
डेटा को etcd में लिखते समय एन्क्रिप्ट किया जाता है। अपने kube-apiserver को पुनरारंभ करने के बाद, कोई भी नया या अपडेट किया गया रहस्य संग्रहीत करते समय एन्क्रिप्ट किया जाना चाहिए। जांचने के लिए, आप अपने रहस्य की सामग्री को पुनः प्राप्त करने के लिए etcdctl कमांड लाइन प्रोग्राम का उपयोग कर सकते हैं।
default नामस्थान में secret1 नामक एक नया रहस्य बनाएं:
etcdctl कमांडलाइन का उपयोग करके, उस रहस्य को etcd से पढ़ें:
ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C
जहां [...] आदि सर्वर से कनेक्ट करने के लिए अतिरिक्त तर्क होना चाहिए। 3. पुष्टि करें कि संग्रहीत रहस्य k8s:enc:aescbc:v1: से पूर्ववर्ती है, जो इंगित करता है कि aescbc प्रदाता ने परिणामी डेटा को एन्क्रिप्ट किया है। 4. पुष्टि करें कि API के माध्यम से पुनः प्राप्त करते समय रहस्य सही ढंग से डिक्रिप्ट किया गया है:
को mykey: bXlkYXRh से मेल खाना चाहिए, mydata को एन्कोड किया गया है, रहस्य को पूरी तरह से डिक्रिप्ट करने के लिए एक रहस्य को डिक्रिप्ट करना की जांच करें।
चूंकि रहस्य लिखने पर एन्क्रिप्ट होते हैं, इसलिए एक रहस्य पर अपडेट करना उस सामग्री को एन्क्रिप्ट करेगा:
अंतिम सुझाव:
FS में रहस्य रखने से बचें, उन्हें अन्य स्थानों से प्राप्त करें।
अपने रहस्यों को और अधिक सुरक्षा देने के लिए https://www.vaultproject.io/ पर जाएं।
AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
