🥇 कुबर्नेट्स क्लस्टरमध्ये छिद्र पाडणे. DevOpsConf कडून अहवाल आणि उतारा

Pavel Selivanov, Southbridge Solutions आर्किटेक्ट आणि Slurm शिक्षक, यांनी DevOpsConf 2019 मध्ये एक सादरीकरण दिले. हे चर्चा कुबर्नेट्स “स्लर्म मेगा” वरील सखोल अभ्यासक्रमाच्या विषयांपैकी एक भाग आहे.

स्लर्म बेसिक: कुबर्नेट्सचा परिचय 18-20 नोव्हेंबर रोजी मॉस्को येथे होत आहे.
स्लर्म मेगा: कुबर्नेट्सच्या हुड अंतर्गत पहात आहे - मॉस्को, नोव्हेंबर 22-24.
स्लर्म ऑनलाइन: दोन्ही कुबर्नेट्स अभ्यासक्रम नेहमी उपलब्ध.

कट खाली अहवालाचा उतारा आहे.

शुभ दुपार, सहकारी आणि जे त्यांच्याबद्दल सहानुभूती दाखवतात. आज मी सुरक्षिततेबद्दल बोलणार आहे.

मी पाहतो की आज सभागृहात अनेक सुरक्षा रक्षक आहेत. जर मी सुरक्षिततेच्या जगामधील अटी तुमच्यासाठी प्रथेप्रमाणे नसतील तर मी तुमची आगाऊ माफी मागतो.

असे घडले की सुमारे सहा महिन्यांपूर्वी मला एक सार्वजनिक कुबर्नेट्स क्लस्टर भेटला. पब्लिक म्हणजे नेमस्पेसेसचा एक नवा क्रमांक आहे; या नेमस्पेसमध्ये वापरकर्ते त्यांच्या नेमस्पेसमध्ये वेगळे असतात. हे सर्व वापरकर्ते वेगवेगळ्या कंपन्यांचे आहेत. बरं, हे क्लस्टर सीडीएन म्हणून वापरले जावे असे गृहीत धरले होते. म्हणजेच, ते तुम्हाला क्लस्टर देतात, ते तुम्हाला तेथे वापरकर्ता देतात, तुम्ही तेथे तुमच्या नेमस्पेसवर जा, तुमचे मोर्चे तैनात करा.

माझ्या आधीच्या कंपनीने अशी सेवा विकण्याचा प्रयत्न केला. आणि हा उपाय योग्य आहे की नाही हे पाहण्यासाठी मला क्लस्टर पोक करण्यास सांगितले.

मी या क्लस्टरमध्ये आलो. मला मर्यादित अधिकार, मर्यादित नेमस्पेस देण्यात आली. तिथल्या मुलांना सुरक्षितता काय असते हे समजले. त्यांनी कुबर्नेट्समध्ये रोल-बेस्ड ऍक्सेस कंट्रोल (RBAC) बद्दल वाचले - आणि त्यांनी ते वळवले जेणेकरून मी तैनातीपासून वेगळे पॉड लॉन्च करू शकत नाही. उपयोजनाशिवाय पॉड लॉन्च करून मी सोडवण्याचा प्रयत्न करत असलेली समस्या मला आठवत नाही, परंतु मला खरोखर फक्त एक पॉड लॉन्च करायचा होता. नशीबासाठी, क्लस्टरमध्ये मला कोणते अधिकार आहेत, मी काय करू शकतो, मी काय करू शकत नाही आणि त्यांनी तिथे काय बिघडले आहे हे पाहण्याचे मी ठरवले. त्याच वेळी, RBAC मध्ये त्यांनी काय चुकीचे कॉन्फिगर केले आहे ते मी तुम्हाला सांगेन.

असे घडले की दोन मिनिटांत मला त्यांच्या क्लस्टरवर एक प्रशासक मिळाला, शेजारच्या सर्व नेमस्पेसेस पाहिल्या, तेथे सेवा खरेदी केलेल्या आणि तैनात केलेल्या कंपन्यांचे चालू उत्पादन आघाडी पाहिले. मी स्वतःला कोणाच्यातरी समोर जाण्यापासून आणि मुख्य पृष्ठावर काही शपथ घेण्यापासून रोखू शकलो नाही.

मी हे कसे केले आणि यापासून स्वतःचे संरक्षण कसे करावे हे मी उदाहरणांसह सांगेन.

पण आधी मी माझी ओळख करून देतो. माझे नाव पावेल सेलिवानोव आहे. मी साउथब्रिज येथे आर्किटेक्ट आहे. मला Kubernetes, DevOps आणि सर्व प्रकारच्या फॅन्सी गोष्टी समजतात. साऊथब्रिजचे अभियंते आणि मी हे सर्व बांधत आहोत आणि मी सल्ला घेत आहे.

आमच्या मुख्य उपक्रमांव्यतिरिक्त, आम्ही अलीकडे स्लर्म्स नावाचे प्रकल्प सुरू केले आहेत. Kubernetes सोबत काम करण्याची आमची क्षमता लोकांपर्यंत पोहोचवण्याचा, इतर लोकांना K8s सोबत काम करायला शिकवण्याचा आमचा प्रयत्न आहे.

आज मी काय बोलणार? अहवालाचा विषय स्पष्ट आहे - कुबर्नेट्स क्लस्टरच्या सुरक्षिततेबद्दल. परंतु मला लगेच सांगायचे आहे की हा विषय खूप मोठा आहे - आणि म्हणूनच मी निश्चितपणे कशाबद्दल बोलणार नाही हे मला त्वरित स्पष्ट करायचे आहे. इंटरनेटवर आधीपासून शंभर वेळा वापरल्या गेलेल्या हॅकनीड शब्दांबद्दल मी बोलणार नाही. सर्व प्रकारचे RBAC आणि प्रमाणपत्रे.

कुबर्नेट्स क्लस्टरमधील सुरक्षिततेबद्दल मला आणि माझ्या सहकाऱ्यांना काय त्रास होतो याबद्दल मी बोलेन. Kubernetes क्लस्टर प्रदान करणाऱ्या प्रदात्यांमध्ये आणि आमच्याकडे येणाऱ्या ग्राहकांमध्येही आम्हाला या समस्या दिसतात. आणि इतर सल्लागार प्रशासक कंपन्यांमधून आमच्याकडे येणाऱ्या ग्राहकांकडूनही. म्हणजेच शोकांतिकेचे प्रमाण खरे तर खूप मोठे आहे.

शब्दशः तीन मुद्दे आहेत ज्याबद्दल मी आज बोलणार आहे:

वापरकर्ता हक्क वि पॉड अधिकार. वापरकर्ता हक्क आणि पॉड अधिकार एकाच गोष्टी नाहीत.
क्लस्टरची माहिती गोळा करणे. या क्लस्टरमध्ये विशेष अधिकार नसतानाही तुम्ही क्लस्टरमधून तुम्हाला आवश्यक असलेली सर्व माहिती गोळा करू शकता हे मी दाखवतो.
क्लस्टरवर DoS हल्ला. आम्ही माहिती गोळा करू शकत नसल्यास, आम्ही कोणत्याही परिस्थितीत क्लस्टर ठेवण्यास सक्षम आहोत. मी क्लस्टर नियंत्रण घटकांवरील DoS हल्ल्यांबद्दल बोलेन.

आणखी एक सामान्य गोष्ट जी मी नमूद करेन ती म्हणजे मी या सर्व गोष्टींची चाचणी केली, ज्यावर मी निश्चितपणे म्हणू शकतो की हे सर्व कार्य करते.

आम्ही Kubespray वापरून Kubernetes क्लस्टरच्या स्थापनेचा आधार घेतो. जर कोणाला माहित नसेल तर, हा प्रत्यक्षात Ansible च्या भूमिकांचा संच आहे. ते आपण आपल्या कामात सतत वापरतो. चांगली गोष्ट अशी आहे की तुम्ही ते कोठेही रोल करू शकता - तुम्ही ते लोखंडाच्या तुकड्यांवर किंवा कुठेतरी ढगावर रोल करू शकता. प्रत्येक गोष्टीसाठी एक स्थापना पद्धत तत्त्वतः कार्य करते.

या क्लस्टरमध्ये माझ्याकडे Kubernetes v1.14.5 असेल. संपूर्ण क्यूब क्लस्टर, ज्याचा आपण विचार करू, नेमस्पेसमध्ये विभागलेला आहे, प्रत्येक नेमस्पेस वेगळ्या टीमशी संबंधित आहे आणि या टीमच्या सदस्यांना प्रत्येक नेमस्पेसमध्ये प्रवेश आहे. ते वेगवेगळ्या नेमस्पेसेसवर जाऊ शकत नाहीत, फक्त त्यांच्या स्वतःच्या. परंतु एक विशिष्ट प्रशासक खाते आहे ज्याकडे संपूर्ण क्लस्टरचे अधिकार आहेत.

मी वचन दिले आहे की आम्ही पहिली गोष्ट करू जी क्लस्टरचे प्रशासक अधिकार मिळवू. आम्हाला खास तयार केलेल्या पॉडची गरज आहे जी कुबर्नेट्स क्लस्टर तोडेल. आम्हाला फक्त ते Kubernetes क्लस्टरवर लागू करायचे आहे.

kubectl apply -f pod.yaml

हे पॉड कुबर्नेट्स क्लस्टरच्या मास्टर्सपैकी एकाकडे येईल. आणि यानंतर क्लस्टर आम्हाला admin.conf नावाची फाईल आनंदाने परत करेल. क्यूबमध्ये, ही फाइल सर्व प्रशासक प्रमाणपत्रे संग्रहित करते आणि त्याच वेळी क्लस्टर API कॉन्फिगर करते. माझ्या मते, 98% Kubernetes क्लस्टर्समध्ये प्रशासक प्रवेश मिळवणे किती सोपे आहे.

मी पुन्हा सांगतो, हा पॉड तुमच्या क्लस्टरमधील एका डेव्हलपरने बनवला होता ज्याला त्याचे प्रस्ताव एका छोट्या नेमस्पेसमध्ये उपयोजित करण्याचा अॅक्सेस आहे, हे सर्व RBAC द्वारे क्लॅम्प केलेले आहे. त्याला कोणतेही अधिकार नव्हते. मात्र तरीही प्रमाणपत्र परत करण्यात आले.

आणि आता खास तयार केलेल्या शेंगा बद्दल. आम्ही ते कोणत्याही प्रतिमेवर चालवतो. उदाहरण म्हणून debian:jessie घेऊ.

आमच्याकडे ही गोष्ट आहे:

tolerations:
-   effect: NoSchedule 
    operator: Exists 
nodeSelector: 
    node-role.kubernetes.io/master: ""

सहिष्णुता म्हणजे काय? कुबर्नेट्स क्लस्टरमधील मास्टर्स सामान्यतः कलंक नावाच्या एखाद्या गोष्टीने चिन्हांकित केले जातात. आणि या "संक्रमण" चे सार असे आहे की ते म्हणतात की पॉड्स मास्टर नोड्सना नियुक्त केले जाऊ शकत नाहीत. परंतु कोणत्याही पॉडमध्ये ते "संसर्ग" सहनशील आहे हे दर्शविण्यास कोणीही त्रास देत नाही. सहनशीलता विभाग फक्त असे म्हणतो की जर काही नोडमध्ये NoSchedule असेल, तर आमचा नोड अशा संसर्गास सहन करतो - आणि कोणतीही समस्या नाही.

पुढे, आम्ही म्हणतो की आमचा अंडर फक्त सहनशील नाही, परंतु मास्टरला विशेषतः लक्ष्य करू इच्छित आहे. कारण मास्टर्सकडे आपल्याला आवश्यक असलेली सर्वात स्वादिष्ट गोष्ट आहे - सर्व प्रमाणपत्रे. म्हणून, आम्ही nodeSelector म्हणतो - आणि आमच्याकडे मास्टर्सवर एक मानक लेबल आहे, जे तुम्हाला क्लस्टरमधील सर्व नोड्समधून नेमके तेच नोड्स निवडण्याची परवानगी देते जे मास्टर्स आहेत.

या दोन विभागांसह तो मास्टरकडे नक्कीच येईल. आणि त्याला तिथे राहण्याची परवानगी दिली जाईल.

पण केवळ सद्गुरूकडे येणे आपल्यासाठी पुरेसे नाही. हे आम्हाला काहीही देणार नाही. तर पुढे आपल्याकडे या दोन गोष्टी आहेत:

hostNetwork: true 
hostPID: true

आम्ही निर्दिष्ट करतो की आमचा पॉड, जो आम्ही लॉन्च करतो, तो कर्नल नेमस्पेसमध्ये, नेटवर्क नेमस्पेसमध्ये आणि PID नेमस्पेसमध्ये राहील. मास्टरवर पॉड लाँच झाल्यानंतर, ते या नोडचे सर्व वास्तविक, थेट इंटरफेस पाहण्यास, सर्व ट्रॅफिक ऐकण्यास आणि सर्व प्रक्रियेचा PID पाहण्यास सक्षम असेल.

मग छोट्या छोट्या गोष्टींचा मुद्दा आहे. etcd घ्या आणि तुम्हाला काय हवे ते वाचा.

सर्वात मनोरंजक गोष्ट म्हणजे कुबर्नेट्स वैशिष्ट्य, जे तेथे डीफॉल्टनुसार उपस्थित आहे.

volumeMounts:
- mountPath: /host 
  name: host 
volumes:
- hostPath: 
    path: / 
    type: Directory 
  name: host

आणि त्याचे सार हे आहे की आम्ही पॉडमध्ये असे म्हणू शकतो की आम्ही लॉन्च करतो, अगदी या क्लस्टरच्या अधिकारांशिवाय, आम्हाला होस्टपाथ प्रकाराचा व्हॉल्यूम तयार करायचा आहे. याचा अर्थ आपण ज्या होस्टवर लाँच करणार आहोत त्या यजमानाकडून मार्ग घेणे - आणि ते व्हॉल्यूम म्हणून घेणे. आणि मग आम्ही त्याला नाव म्हणतो: होस्ट. आम्ही हा संपूर्ण होस्टपाथ पॉडच्या आत माउंट करतो. या उदाहरणात, /host डिरेक्ट्रीमध्ये.

मी ते पुन्हा पुन्हा सांगेन. आम्ही पॉडला मास्टरकडे येण्यास सांगितले, तेथे होस्टनेटवर्क आणि होस्टपीआयडी मिळवा - आणि या पॉडमध्ये मास्टरचे संपूर्ण रूट माउंट करा.

तुम्हाला समजले आहे की डेबियनमध्ये आमच्याकडे बॅश चालू आहे आणि हा बॅश रूट अंतर्गत चालतो. म्हणजेच, कुबर्नेट्स क्लस्टरमध्ये कोणतेही अधिकार नसताना, आम्हाला मास्टर वर रूट मिळाले आहे.

मग संपूर्ण कार्य म्हणजे उप-डिरेक्टरी /host /etc/kubernetes/pki वर जाणे, जर माझी चूक नसेल, तर तेथे क्लस्टरची सर्व मास्टर प्रमाणपत्रे घ्या आणि त्यानुसार, क्लस्टर प्रशासक व्हा.

जर तुम्ही या प्रकारे पाहिले तर, हे पॉड्समधील काही सर्वात धोकादायक अधिकार आहेत - वापरकर्त्याला कोणते अधिकार आहेत याची पर्वा न करता:

जर मला क्लस्टरच्या काही नेमस्पेसमध्ये पॉड चालवण्याचे अधिकार असतील, तर या पॉडला हे अधिकार बाय डीफॉल्ट आहेत. मी प्रिव्हिलेज्ड पॉड्स चालवू शकतो, आणि हे सर्वसाधारणपणे सर्व अधिकार आहेत, व्यावहारिकरित्या नोडवर रूट आहेत.

माझा आवडता रूट वापरकर्ता आहे. आणि Kubernetes मध्ये हा Run As Non-Rot पर्याय आहे. हा हॅकरपासून संरक्षणाचा एक प्रकार आहे. तुम्हाला माहीत आहे का "मोल्डाव्हियन व्हायरस" म्हणजे काय? जर तुम्ही अचानक हॅकर असाल आणि माझ्या कुबर्नेट्स क्लस्टरमध्ये आलात, तर आम्ही, गरीब प्रशासक, विचारू: “कृपया तुमच्या पॉड्समध्ये सूचित करा ज्याने तुम्ही माझे क्लस्टर हॅक कराल, रूट नसलेल्या म्हणून चालवा. अन्यथा, असे होईल की तुम्ही तुमच्या पॉडमध्ये रूट अंतर्गत प्रक्रिया चालवा, आणि मला हॅक करणे तुमच्यासाठी खूप सोपे होईल. कृपया स्वतःपासून स्वतःचे रक्षण करा."

होस्ट पाथ व्हॉल्यूम, माझ्या मते, Kubernetes क्लस्टरमधून इच्छित परिणाम मिळविण्याचा सर्वात जलद मार्ग आहे.

पण या सगळ्याचं करायचं काय?

कुबर्नेट्सचा सामना करणार्‍या कोणत्याही सामान्य प्रशासकाला हा विचार आला पाहिजे: “हो, मी तुम्हाला सांगितले, कुबर्नेट्स काम करत नाही. त्यात छिद्रे आहेत. आणि संपूर्ण घन बकवास आहे.” खरं तर, दस्तऐवज म्हणून एक गोष्ट आहे, आणि आपण तेथे पाहिले तर, एक विभाग आहे पॉड सुरक्षा धोरण.

ही एक yaml ऑब्जेक्ट आहे - आम्ही ती Kubernetes क्लस्टरमध्ये तयार करू शकतो - जे विशेषतः पॉड्सच्या वर्णनात सुरक्षा पैलू नियंत्रित करते. म्हणजेच, खरं तर, ते स्टार्टअपच्या वेळी पॉड्समध्ये असलेले कोणतेही होस्टनेटवर्क, होस्टपीआयडी, विशिष्ट व्हॉल्यूम प्रकार वापरण्याचे अधिकार नियंत्रित करते. पॉड सिक्युरिटी पॉलिसीच्या मदतीने हे सर्व वर्णन केले जाऊ शकते.

पॉड सिक्युरिटी पॉलिसीबद्दल सर्वात मनोरंजक गोष्ट अशी आहे की कुबर्नेट्स क्लस्टरमध्ये, सर्व PSP इंस्टॉलर्सचे वर्णन कोणत्याही प्रकारे केले जात नाही, ते फक्त डीफॉल्टनुसार अक्षम केले जातात. प्रवेश प्लगइन वापरून पॉड सुरक्षा धोरण सक्षम केले आहे.

ठीक आहे, क्लस्टरमध्ये पॉड सिक्युरिटी पॉलिसी उपयोजित करूया, असे म्हणूया की आमच्याकडे नेमस्पेसमध्ये काही सर्व्हिस पॉड्स आहेत, ज्यामध्ये फक्त प्रशासकांना प्रवेश आहे. समजा, इतर सर्व प्रकरणांमध्ये, शेंगांना मर्यादित अधिकार आहेत. कारण बहुधा विकसकांना तुमच्या क्लस्टरमध्ये विशेषाधिकार प्राप्त पॉड्स चालवण्याची गरज नाही.

आणि असे दिसते की आमच्याबरोबर सर्व काही ठीक आहे. आणि आमचे Kubernetes क्लस्टर दोन मिनिटांत हॅक केले जाऊ शकत नाही.

एक समस्या आहे. बहुधा, जर तुमच्याकडे कुबर्नेट्स क्लस्टर असेल, तर तुमच्या क्लस्टरवर मॉनिटरिंग इंस्टॉल केले आहे. तुमच्या क्लस्टरमध्ये जर मॉनिटरिंग असेल तर त्याला प्रोमिथियस म्हटले जाईल असे भाकीत करण्यासाठी मी अगदी पुढे जाईन.

मी तुम्हाला जे सांगणार आहे ते प्रोमिथियस ऑपरेटर आणि प्रोमिथियस या दोघांसाठीही वैध असेल जे त्याच्या शुद्ध स्वरूपात वितरित केले जाईल. प्रश्न असा आहे की जर मला क्लस्टरमध्ये एवढ्या लवकर प्रशासक मिळू शकला नाही, तर याचा अर्थ मला अधिक पाहण्याची आवश्यकता आहे. आणि मी तुमच्या मॉनिटरिंगच्या मदतीने शोधू शकतो.

कदाचित प्रत्येकजण Habré वरील समान लेख वाचत असेल आणि मॉनिटरिंग नेमस्पेसमध्ये आहे. हेल्म चार्ट प्रत्येकासाठी अंदाजे समान म्हटले जाते. माझा अंदाज आहे की जर तुम्ही हेल्म स्टेबल/प्रोमिथियस स्थापित केले तर तुमची जवळजवळ समान नावे असतील. आणि बहुधा मला तुमच्या क्लस्टरमधील DNS नावाचा अंदाज लावावा लागणार नाही. कारण ते मानक आहे.

पुढे आमच्याकडे एक विशिष्ट devns आहे, ज्यामध्ये तुम्ही विशिष्ट पॉड चालवू शकता. आणि मग या पॉडमधून असे काहीतरी करणे खूप सोपे आहे:

$ curl http://prometheus-kube-state-metrics.monitoring

prometheus-kube-state-metrics हा Prometheus निर्यातदारांपैकी एक आहे जो कुबर्नेट्स API मधूनच मेट्रिक्स गोळा करतो. तुमच्या क्लस्टरमध्ये काय चालू आहे, ते काय आहे, तुम्हाला त्यात काय समस्या आहेत, तेथे भरपूर डेटा आहे.

एक साधे उदाहरण म्हणून:

kube_pod_container_info{namespace=“kube-system”,pod=”kube-apiserver-k8s- 1″,container=”kube-apiserver”,image=

"gcr.io/google-containers/kube-apiserver:v1.14.5"

,image_id=»docker-pullable://gcr.io/google-containers/kube- apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989″,container_id=»docker://7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b»} 1

अनाधिकृत पॉडकडून एक साधी कर्ल विनंती करून, आपण खालील माहिती मिळवू शकता. आपण कुबरनेटची कोणती आवृत्ती चालवत आहात हे आपल्याला माहित नसल्यास, ते आपल्याला सहजपणे सांगेल.

आणि सर्वात मनोरंजक गोष्ट अशी आहे की क्यूबे-स्टेट-मेट्रिक्समध्ये प्रवेश करण्याव्यतिरिक्त, आपण प्रॉमिथियसमध्ये थेट प्रवेश करू शकता. तिथून तुम्ही मेट्रिक्स गोळा करू शकता. तुम्ही तिथून मेट्रिक्स देखील तयार करू शकता. जरी सैद्धांतिकदृष्ट्या, आपण प्रोमिथियसमधील क्लस्टरमधून अशी क्वेरी तयार करू शकता, जे ते फक्त बंद करेल. आणि तुमचे निरीक्षण क्लस्टरमधून पूर्णपणे कार्य करणे थांबवेल.

आणि येथे प्रश्न उद्भवतो की कोणतेही बाह्य निरीक्षण आपल्या मॉनिटरिंगवर लक्ष ठेवते. मला नुकतेच कुबर्नेट्स क्लस्टरमध्ये स्वतःवर कोणतेही परिणाम न होता ऑपरेट करण्याची संधी मिळाली. तुम्हाला हे देखील कळणार नाही की मी तेथे कार्यरत आहे, कारण यापुढे कोणतेही निरीक्षण नाही.

PSP प्रमाणेच, समस्या अशी आहे की हे सर्व फॅन्सी तंत्रज्ञान - कुबर्नेट्स, प्रोमिथियस - ते कार्य करत नाहीत आणि छिद्रांनी भरलेले आहेत. खरंच नाही.

अशी एक गोष्ट आहे - नेटवर्क धोरण.

जर तुम्ही एक सामान्य प्रशासक असाल, तर बहुधा तुम्हाला नेटवर्क पॉलिसीबद्दल माहित असेल की ही आणखी एक yaml आहे, ज्यापैकी बरेच क्लस्टरमध्ये आधीच आहेत. आणि काही नेटवर्क धोरणांची नक्कीच गरज नाही. आणि नेटवर्क पॉलिसी काय आहे हे जरी तुम्ही वाचले असेल, की ती कुबर्नेट्सची yaml फायरवॉल आहे, ती तुम्हाला नेमस्पेसमध्ये, पॉड्समधील प्रवेश अधिकार मर्यादित करू देते, तर तुम्ही निश्चितपणे ठरवले आहे की Kubernetes मधील yaml फॉरमॅटमधील फायरवॉल पुढील अॅब्स्ट्रॅक्शन्सवर आधारित आहे. ... नाही, नाही . हे निश्चितपणे आवश्यक नाही.

जरी तुम्ही तुमच्या सुरक्षा तज्ञांना हे सांगितले नाही की तुमच्या कुबर्नेट्सचा वापर करून तुम्ही एक अतिशय सोपी आणि साधी फायरवॉल तयार करू शकता आणि त्यामध्ये खूप दाणेदार आहे. जर त्यांना अद्याप हे माहित नसेल आणि ते तुम्हाला त्रास देत नसेल: “ठीक आहे, मला द्या, मला द्या...” मग कोणत्याही परिस्थितीत, तुमच्या क्लस्टरमधून काढल्या जाऊ शकतील अशा काही सेवा स्थानांवर प्रवेश अवरोधित करण्यासाठी तुम्हाला नेटवर्क धोरणाची आवश्यकता आहे. कोणत्याही अधिकृततेशिवाय.

मी दिलेल्या उदाहरणाप्रमाणे, तुम्ही कुबर्नेट्स क्लस्टरमधील कोणत्याही नेमस्पेसमधून कुबे स्टेट मेट्रिक्स काढू शकता. नेटवर्क धोरणांनी इतर सर्व नेमस्पेसमधून मॉनिटरिंग नेमस्पेसमध्ये प्रवेश बंद केला आहे आणि तेच आहे: प्रवेश नाही, कोणतीही समस्या नाही. अस्तित्त्वात असलेल्या सर्व चार्ट्समध्ये, मानक प्रोमिथियस आणि प्रॉमिथियस दोन्ही ऑपरेटरमध्ये आहेत, त्यांच्यासाठी नेटवर्क धोरणे सक्षम करण्यासाठी हेल्म व्हॅल्यूजमध्ये फक्त एक पर्याय आहे. आपण फक्त ते चालू करणे आवश्यक आहे आणि ते कार्य करतील.

येथे खरोखर एक समस्या आहे. एक सामान्य दाढी असलेला प्रशासक असल्याने, तुम्ही बहुधा ठरवले असेल की नेटवर्क धोरणांची आवश्यकता नाही. आणि Habr सारख्या संसाधनांवरील सर्व प्रकारचे लेख वाचल्यानंतर, आपण ठरवले की फ्लॅनेल, विशेषत: होस्ट-गेटवे मोडसह, आपण निवडू शकता ही सर्वोत्तम गोष्ट आहे.

मी काय करावे?

तुम्ही तुमच्या Kubernetes क्लस्टरमध्ये असलेले नेटवर्क सोल्यूशन पुन्हा लागू करण्याचा प्रयत्न करू शकता, ते अधिक कार्यक्षमतेने बदलण्याचा प्रयत्न करू शकता. त्याच कॅलिकोसाठी, उदाहरणार्थ. परंतु मला लगेच सांगायचे आहे की कुबर्नेट्स वर्किंग क्लस्टरमध्ये नेटवर्क सोल्यूशन बदलण्याचे कार्य अगदी क्षुल्लक आहे. मी ते दोनदा सोडवले (दोन्ही वेळा, तथापि, सैद्धांतिकदृष्ट्या), परंतु आम्ही ते स्लर्म्समध्ये कसे करायचे ते देखील दाखवले. आमच्या विद्यार्थ्यांसाठी, आम्ही Kubernetes क्लस्टरमध्ये नेटवर्क सोल्यूशन कसे बदलायचे ते दाखवले. तत्वतः, आपण उत्पादन क्लस्टरवर कोणताही डाउनटाइम नसल्याचे सुनिश्चित करण्याचा प्रयत्न करू शकता. परंतु आपण कदाचित यशस्वी होणार नाही.

आणि प्रत्यक्षात समस्या अगदी सोप्या पद्धतीने सोडवली जाते. क्लस्टरमध्ये प्रमाणपत्रे आहेत आणि तुम्हाला माहिती आहे की तुमची प्रमाणपत्रे एका वर्षात कालबाह्य होतील. ठीक आहे, आणि सामान्यत: क्लस्टरमधील प्रमाणपत्रांसह एक सामान्य उपाय - आम्ही काळजी का करत आहोत, आम्ही जवळच एक नवीन क्लस्टर वाढवू, जुने सडू देऊ आणि सर्वकाही पुन्हा तैनात करू. खरे आहे, जेव्हा ते कुजले जाते, तेव्हा आम्हाला एक दिवस बसावे लागेल, परंतु येथे एक नवीन क्लस्टर आहे.

जेव्हा तुम्ही नवीन क्लस्टर वाढवता, त्याच वेळी फ्लॅनेलऐवजी कॅलिको घाला.

जर तुमचे प्रमाणपत्र शंभर वर्षांसाठी जारी केले गेले आणि तुम्ही क्लस्टर पुन्हा तैनात करणार नसाल तर काय करावे? कुबे-आरबीएसी-प्रॉक्सी अशी एक गोष्ट आहे. हा एक अतिशय छान विकास आहे, तो तुम्हाला कुबर्नेट्स क्लस्टरमधील कोणत्याही पॉडमध्ये साइडकार कंटेनर म्हणून एम्बेड करण्याची परवानगी देतो. आणि हे खरंतर कुबर्नेट्सच्या RBAC द्वारे या पॉडमध्ये अधिकृतता जोडते.

एक समस्या आहे. पूर्वी, हे Kube-RBAC-Proxy सोल्यूशन ऑपरेटरच्या Prometheus मध्ये तयार केले गेले होते. पण नंतर तो निघून गेला होता. आता आधुनिक आवृत्त्या या वस्तुस्थितीवर अवलंबून आहेत की आपल्याकडे नेटवर्क धोरण आहे आणि ते वापरून ते बंद करा. आणि म्हणून आपल्याला चार्ट थोडे पुन्हा लिहावे लागेल. खरं तर, आपण गेलात तर हे भांडार, हे साइडकार म्हणून कसे वापरायचे याची उदाहरणे आहेत आणि चार्ट कमीत कमी पुन्हा लिहावे लागतील.

अजून एक छोटी समस्या आहे. प्रोमिथियस हा एकटाच नाही जो त्याचे मेट्रिक्स फक्त कोणाला देतो. आमचे सर्व Kubernetes क्लस्टर घटक देखील त्यांचे स्वतःचे मेट्रिक्स परत करण्यास सक्षम आहेत.

परंतु मी आधीच म्हटल्याप्रमाणे, जर तुम्ही क्लस्टरमध्ये प्रवेश करू शकत नसाल आणि माहिती गोळा करू शकत नसाल, तर तुम्ही किमान काही नुकसान करू शकता.

म्हणून मी कुबर्नेट्स क्लस्टरचा नाश कसा करता येईल याचे दोन मार्ग पटकन दाखवतो.

जेव्हा मी तुम्हाला हे सांगेन तेव्हा तुम्ही हसाल, ही दोन वास्तविक जीवनातील प्रकरणे आहेत.

पद्धत एक. संसाधन कमी होणे.

चला आणखी एक विशेष पॉड लाँच करूया. त्यात असा विभाग असेल.

resources: 
    requests: 
        cpu: 4 
        memory: 4Gi

तुम्हाला माहिती आहे की, विनंत्या म्हणजे CPU आणि मेमरीची रक्कम जी होस्टवर विनंत्यांसह विशिष्ट पॉड्ससाठी राखीव असते. आमच्याकडे कुबर्नेट्स क्लस्टरमध्ये चार-कोर होस्ट असल्यास, आणि चार CPU पॉड्स विनंत्यांसह तेथे पोहोचले, तर याचा अर्थ असा की या होस्टकडे विनंती असलेले कोणतेही पॉड्स येऊ शकणार नाहीत.

जर मी असा पॉड चालवला तर मी कमांड रन करेन:

$ kubectl scale special-pod --replicas=...

मग कुबर्नेट्स क्लस्टरमध्ये इतर कोणीही तैनात करू शकणार नाही. कारण सर्व नोड्स विनंत्या संपतील. आणि अशा प्रकारे मी तुमचा कुबर्नेट्स क्लस्टर थांबवीन. जर मी हे संध्याकाळी केले, तर मी बराच काळ तैनाती थांबवू शकतो.

जर आपण कुबर्नेट्स डॉक्युमेंटेशन पुन्हा पाहिलं, तर आपल्याला मर्यादा रेंज नावाची गोष्ट दिसेल. हे क्लस्टर ऑब्जेक्ट्ससाठी संसाधने सेट करते. तुम्ही yaml मध्ये लिमिट रेंज ऑब्जेक्ट लिहू शकता, काही नेमस्पेसेसवर लागू करू शकता - आणि नंतर या नेमस्पेसमध्ये तुम्ही पॉड्ससाठी डिफॉल्ट, कमाल आणि किमान संसाधने आहेत असे म्हणू शकता.

अशा गोष्टीच्या मदतीने, आम्ही वापरकर्त्यांना त्यांच्या शेंगांवर सर्व प्रकारच्या ओंगळ गोष्टी सूचित करण्याच्या क्षमतेमध्ये संघांच्या विशिष्ट उत्पादन नेमस्पेसमध्ये मर्यादित करू शकतो. परंतु दुर्दैवाने, जरी तुम्ही वापरकर्त्याला सांगितले की ते एकापेक्षा जास्त CPU च्या विनंतीसह पॉड्स लाँच करू शकत नाहीत, अशी एक अद्भुत स्केल कमांड आहे, किंवा ते डॅशबोर्डद्वारे स्केल करू शकतात.

आणि येथूनच पद्धत क्रमांक दोन येते. आम्ही 11 पॉड लाँच करतो. ते अकरा अब्ज आहे. मी असा नंबर घेऊन आलो म्हणून नाही, तर मी ते स्वतः पाहिले आहे म्हणून.

खरी कथा. संध्याकाळी उशिरा मी ऑफिसला निघणार होतो. मला दिसले की विकासकांचा एक गट कोपऱ्यात बसून त्यांच्या लॅपटॉपसह काहीतरी करत आहे. मी मुलांकडे जातो आणि विचारतो: "तुला काय झाले?"

थोड्या वेळापूर्वी, संध्याकाळी नऊच्या सुमारास, एक विकासक घरी जाण्याच्या तयारीत होता. आणि मी ठरवले: "मी आता माझा अर्ज एक पर्यंत कमी करेन." मी एक दाबले, पण इंटरनेट थोडे कमी झाले. त्याने पुन्हा एक दाबला, त्याने एक दाबला आणि एंटर क्लिक केले. मी शक्य तितक्या सर्व गोष्टींवर जोर दिला. मग इंटरनेट जिवंत झाले - आणि सर्वकाही या संख्येपर्यंत कमी होऊ लागले.

खरे आहे, ही कथा कुबर्नेट्सवर घडली नाही; त्यावेळी ती भटक्या होती. हे या वस्तुस्थितीसह समाप्त झाले की आम्ही भटक्याला मापन करण्याच्या सतत प्रयत्नांपासून थांबवण्याच्या एका तासानंतर, भटक्याने उत्तर दिले की तो स्केलिंग थांबवणार नाही आणि दुसरे काहीही करणार नाही. "मी थकलो आहे, मी निघत आहे." आणि तो कुरवाळला.

साहजिकच, मी कुबर्नेट्सवरही असेच करण्याचा प्रयत्न केला. कुबर्नेट्स अकरा अब्ज पॉड्सवर खूश नव्हते, तो म्हणाला: “मी करू शकत नाही. अंतर्गत माउथ गार्ड्सपेक्षा जास्त आहे." पण 1 शेंगा करू शकतात.

एक अब्जच्या प्रतिसादात, क्यूब स्वतःमध्ये मागे हटला नाही. त्याने खरोखर स्केलिंग सुरू केले. प्रक्रिया जितकी पुढे गेली, तितकाच त्याला नवीन शेंगा तयार करायला जास्त वेळ लागला. पण तरीही प्रक्रिया सुरूच होती. एकच अडचण अशी आहे की जर मी माझ्या नेमस्पेसमध्ये अमर्यादितपणे पॉड्स लाँच करू शकलो, तर विनंत्या आणि मर्यादेशिवायही मी काही टास्कसह इतक्या पॉड्स लाँच करू शकेन की या टास्कच्या मदतीने नोड्स मेमरीमध्ये, CPU मध्ये जोडू लागतील. जेव्हा मी इतक्या पॉड्स लाँच करतो तेव्हा त्यातील माहिती स्टोरेजमध्ये, म्हणजे इ. डी. आणि जेव्हा खूप जास्त माहिती तिथे पोहोचते, तेव्हा स्टोरेज खूप हळू परत येऊ लागते - आणि कुबर्नेट्स निस्तेज होऊ लागतात.

आणि आणखी एक समस्या... तुम्हाला माहिती आहे की, कुबर्नेट्स कंट्रोल एलिमेंट्स ही एक मध्यवर्ती गोष्ट नसून अनेक घटक आहेत. विशेषतः, एक नियंत्रक व्यवस्थापक, शेड्यूलर आणि असेच आहे. ही सर्व मुले एकाच वेळी अनावश्यक, मूर्ख काम करण्यास सुरवात करतील, जे कालांतराने अधिकाधिक वेळ घेईल. कंट्रोलर मॅनेजर नवीन शेंगा तयार करेल. शेड्युलर त्यांच्यासाठी नवीन नोड शोधण्याचा प्रयत्न करेल. तुमच्या क्लस्टरमधील नवीन नोड्स लवकरच संपतील. Kubernetes क्लस्टर हळू आणि हळू काम करण्यास सुरवात करेल.

पण मी अजून पुढे जायचं ठरवलं. तुम्हाला माहिती आहेच, कुबर्नेट्समध्ये सेवा नावाची एक गोष्ट आहे. बरं, तुमच्या क्लस्टरमध्ये डीफॉल्टनुसार, बहुधा, सेवा IP टेबल वापरून कार्य करते.

उदाहरणार्थ, तुम्ही एक अब्ज पॉड्स चालवल्यास, आणि नंतर कुबरनेटिसला नवीन सेवा तयार करण्यास भाग पाडण्यासाठी स्क्रिप्ट वापरा:

for i in {1..1111111}; do
    kubectl expose deployment test --port 80  
        --overrides="{"apiVersion": "v1", 
           "metadata": {"name": "nginx$i"}}"; 
done

क्लस्टरच्या सर्व नोड्सवर, अधिकाधिक नवीन iptables नियम अंदाजे एकाच वेळी तयार केले जातील. शिवाय, प्रत्येक सेवेसाठी एक अब्ज iptables नियम तयार केले जातील.

मी ही संपूर्ण गोष्ट अनेक हजारांवर, दहा पर्यंत तपासली. आणि समस्या अशी आहे की आधीच या उंबरठ्यावर नोडला ssh करणे खूप समस्याप्रधान आहे. कारण अनेक साखळ्यांमधून जाणारी पॅकेट्स फारशी चांगली वाटत नाहीत.

आणि हे देखील, कुबर्नेट्सच्या मदतीने सोडवले जाते. असा रिसोर्स कोटा ऑब्जेक्ट आहे. क्लस्टरमधील नेमस्पेससाठी उपलब्ध संसाधने आणि ऑब्जेक्ट्सची संख्या सेट करते. Kubernetes क्लस्टरच्या प्रत्येक नेमस्पेसमध्ये आपण yaml ऑब्जेक्ट तयार करू शकतो. या ऑब्जेक्टचा वापर करून, आम्ही असे म्हणू शकतो की आमच्याकडे या नेमस्पेससाठी काही विनंत्या आणि मर्यादा वाटप केल्या आहेत आणि नंतर आम्ही असे म्हणू शकतो की या नेमस्पेसमध्ये 10 सेवा आणि 10 पॉड तयार करणे शक्य आहे. आणि एकच विकासक किमान संध्याकाळी स्वतःला गुदमरवू शकतो. कुबर्नेट्स त्याला सांगतील: "तुम्ही तुमच्या शेंगा त्या प्रमाणात वाढवू शकत नाही, कारण संसाधन कोटा ओलांडत आहे." बस्स, समस्या सोडवली. येथे दस्तऐवजीकरण.

या संदर्भात एक समस्याप्रधान मुद्दा उद्भवतो. कुबर्नेट्समध्ये नेमस्पेस तयार करणे किती कठीण होत आहे असे तुम्हाला वाटते. ते तयार करण्यासाठी, आपल्याला बर्याच गोष्टी विचारात घ्याव्या लागतील.

संसाधन कोटा + मर्यादा श्रेणी + RBAC
• एक नेमस्पेस तयार करा
• आत एक मर्यादा तयार करा
• आत संसाधन कोटा तयार करा
• CI साठी सेवा खाते तयार करा
• CI आणि वापरकर्त्यांसाठी रोलबाइंडिंग तयार करा
• वैकल्पिकरित्या आवश्यक सेवा पॉड लाँच करा

म्हणून, मी माझ्या घडामोडी शेअर करण्याची ही संधी घेऊ इच्छितो. SDK ऑपरेटर नावाची अशी एक गोष्ट आहे. Kubernetes क्लस्टरसाठी ऑपरेटर लिहिण्याचा हा एक मार्ग आहे. तुम्ही Ansible वापरून विधाने लिहू शकता.

सुरुवातीला ते Ansible मध्ये लिहिले होते, आणि नंतर मी पाहिले की तेथे एक SDK ऑपरेटर आहे आणि ऑपरेटरमध्ये उत्तरदायी भूमिका पुन्हा लिहिली. हे विधान तुम्हाला कुबर्नेट्स क्लस्टरमध्ये कमांड नावाचे ऑब्जेक्ट तयार करण्यास अनुमती देते. कमांडच्या आत, ते तुम्हाला yaml मध्ये या कमांडसाठी वातावरणाचे वर्णन करण्यास अनुमती देते. आणि संघाच्या वातावरणात, हे आम्हाला वर्णन करण्यास अनुमती देते की आम्ही बर्याच संसाधनांचे वाटप करत आहोत.

थोडे ही संपूर्ण जटिल प्रक्रिया सुलभ करणे.

आणि शेवटी. या सगळ्याचं करायचं काय?
पहिला. पॉड सुरक्षा धोरण चांगले आहे. आणि कुबर्नेट्स इंस्टॉलरपैकी कोणीही आजपर्यंत त्यांचा वापर करत नसले तरीही, तुम्हाला ते तुमच्या क्लस्टरमध्ये वापरण्याची आवश्यकता आहे.

नेटवर्क पॉलिसी हे फक्त आणखी एक अनावश्यक वैशिष्ट्य नाही. क्लस्टरमध्ये याची खरोखर गरज आहे.

LimitRange/ResourceQuota - ते वापरण्याची वेळ आली आहे. आम्ही हे खूप पूर्वी वापरायला सुरुवात केली होती आणि बर्याच काळापासून मला खात्री होती की प्रत्येकजण ते वापरत आहे. हे दुर्मिळ असल्याचे निष्पन्न झाले.

अहवालादरम्यान मी नमूद केलेल्या गोष्टींव्यतिरिक्त, तेथे अदस्तांकित वैशिष्ट्ये आहेत जी तुम्हाला क्लस्टरवर हल्ला करण्याची परवानगी देतात. नुकतेच प्रसिद्ध झाले Kubernetes असुरक्षा विस्तृत विश्लेषण.

काही गोष्टी खूप दुःखद आणि दुखावणाऱ्या असतात. उदाहरणार्थ, काही विशिष्ट परिस्थितींमध्ये, कुबर्नेट्स क्लस्टरमधील क्यूबलेट्स वॉरलॉक डिरेक्टरीची सामग्री अनधिकृत वापरकर्त्यास देऊ शकतात.

येथे मी तुम्हाला सांगितलेल्या सर्व गोष्टींचे पुनरुत्पादन कसे करावे याबद्दल सूचना आहेत. रिसोर्सक्वोटा आणि पॉड सिक्युरिटी पॉलिसी कशी दिसते याची उत्पादन उदाहरणे असलेल्या फाइल्स आहेत. आणि आपण हे सर्व स्पर्श करू शकता.

सर्वांचे आभार.

स्त्रोत: www.habr.com

कुबर्नेट्स क्लस्टरमध्ये छिद्रे निश्चित करणे. DevOpsConf कडून अहवाल आणि उतारा

एक टिप्पणी जोडा Отменить ответ