जैसे-जैसे कुबेरनेट्स अग्रणी कंटेनर ऑर्केस्ट्रेशन प्लेटफ़ॉर्म के रूप में परिपक्व हो रहा है, कंटेनरीकृत अनुप्रयोगों को तैनात करने वाले संगठनों के लिए सुरक्षा एक सर्वोपरि चिंता बनी हुई है। कुबेरनेट्स के सुरक्षा शस्त्रागार में मूलभूत उपकरणों में से, पॉड सुरक्षा नीतियों (पीएसपी) ने एक बार महत्वपूर्ण भूमिका निभाई थी। पीएसपी ने प्रशासकों को पॉड्स पर सुरक्षा बाधाओं को सावधानीपूर्वक परिभाषित करने और लागू करने की अनुमति दी, यह सुनिश्चित करते हुए कि केवल विशिष्ट सुरक्षा मानकों को पूरा करने वाले कंटेनर ही क्लस्टर के भीतर काम कर सकते हैं।
हालाँकि, कुबेरनेट्स सुरक्षा का परिदृश्य तेजी से विकसित हो रहा है, और यह ध्यान रखना महत्वपूर्ण है कि पीएसपी को अब कुबेरनेट्स 1.25 से शुरू करके हटा दिया गया है (कुबेरनेट्स 1.25 तत्काल रिलीज़ नोट्स का लिंक देखें)। यह परिवर्तन विभिन्न कारकों से उत्पन्न होता है, जिसमें पीएसपी नीतियों के प्रबंधन और रखरखाव की जटिलता भी शामिल है, जो अक्सर उपयोगकर्ताओं के लिए परिचालन चुनौतियों का कारण बनती है।
बहिष्कार के जवाब में, संगठन अब पीएसपी के आधुनिक विकल्पों की तलाश कर रहे हैं, जो न केवल सुरक्षा आवश्यकताओं को संबोधित करते हैं बल्कि कुबेरनेट्स में वर्कलोड को सुरक्षित करने की प्रक्रिया को भी सुव्यवस्थित करते हैं।
इस व्यापक गाइड में, हम कुबेरनेट्स सुरक्षा प्रथाओं में इस बदलाव को नेविगेट करने के लिए एक यात्रा शुरू करते हैं, जो पॉड सुरक्षा प्रवेश (पीएसए) में संक्रमण पर ध्यान केंद्रित करता है। पीएसए उपलब्ध सबसे मजबूत विकल्पों में से एक है, और यह लेख इसकी गहराई से पड़ताल करता है। हालाँकि, यह उल्लेखनीय है कि दो अन्य विकल्प, किवर्नो और ओपीए गेटकीपर, इस श्रृंखला के भीतर अलग-अलग लेखों में शामिल किए जाएंगे।
इस पूरे लेख में, आपको पीएसए की स्थापना और स्थापना के लिए विस्तृत निर्देश, पीएसपी से पीएसए में आसानी से संक्रमण के लिए चरण-दर-चरण माइग्रेशन गाइड और मौजूदा पीएसपी नियमों को पीएसए में स्थानांतरित करने के लिए सटीक आदेश मिलेंगे। इसके अतिरिक्त, आप पीएसए के अनुरूप ड्राई-रन कमांड का उपयोग करके माइग्रेशन तैयारी के लिए नेमस्पेस का आकलन करने का ज्ञान प्राप्त करेंगे।
इस गाइड के अंत तक, आप पीएसए की शक्तियों और सीमाओं की व्यापक समझ प्राप्त कर लेंगे, जो आपको आपके संगठन की विशिष्ट सुरक्षा आवश्यकताओं और कुबेरनेट्स पर्यावरण के आधार पर एक सूचित निर्णय लेने में सक्षम बनाएगी।
इस गाइड के साथ, आप आत्मविश्वास से अपनी कुबेरनेट्स सुरक्षा प्रथाओं को आधुनिक बना सकते हैं, यह सुनिश्चित करते हुए कि पॉड सुरक्षा नीतियों के युग को अलविदा कहते समय आपका कार्यभार सुरक्षित रहे।
पीएसए कुबेरनेट्स सुरक्षा मानकों को लागू करता है: पीएसए सुनिश्चित करता है कि कंटेनर कुबेरनेट्स के मूल सुरक्षा मानकों का पालन करें, जो पॉड सुरक्षा मानकों द्वारा परिभाषित हैं। ये मानक सुरक्षा नीतियों को तीन अलग-अलग प्रोफाइलों में वर्गीकृत करते हैं, जिनमें से प्रत्येक में प्रतिबंधात्मकता का एक अलग स्तर होता है:
विशेषाधिकार प्राप्त : विशेषाधिकार नीति जानबूझकर खुली और पूरी तरह से अप्रतिबंधित है। आमतौर पर, यह नीति विश्वसनीय उपयोगकर्ताओं द्वारा प्रबंधित सिस्टम- और बुनियादी ढांचे-स्तरीय वर्कलोड को लक्षित करती है। यह प्रतिबंधों की अनुपस्थिति की विशेषता है। जबकि गेटकीपर जैसे डिफ़ॉल्ट-अनुमति तंत्र को स्वाभाविक रूप से विशेषाधिकार प्राप्त हो सकता है, पॉड सुरक्षा नीति (पीएसपी) जैसे इनकार-दर-डिफ़ॉल्ट तंत्र के लिए, विशेषाधिकार प्राप्त नीति को सभी प्रतिबंधों को निष्क्रिय करना चाहिए।
बेसलाइन : बेसलाइन नीति ज्ञात विशेषाधिकार वृद्धि को रोकते हुए सामान्य कंटेनरीकृत कार्यभार द्वारा आसानी से अपनाने के लिए डिज़ाइन की गई है। यह एप्लिकेशन ऑपरेटरों और गैर-महत्वपूर्ण एप्लिकेशन के डेवलपर्स को सेवाएं प्रदान करता है।
प्रतिबंधित : प्रतिबंधित नीति कठोर पॉड सख्त सर्वोत्तम प्रथाओं को लागू करने पर केंद्रित है, भले ही कुछ अनुकूलता की संभावित कीमत पर। यह मुख्य रूप से सुरक्षा-महत्वपूर्ण अनुप्रयोगों के ऑपरेटरों और डेवलपर्स के साथ-साथ कम-भरोसेमंद उपयोगकर्ताओं को लक्षित करता है। प्रत्येक प्रोफ़ाइल के अंतर्गत लागू या अस्वीकृत किए जाने वाले नियंत्रणों की विस्तृत सूची के लिए, आप आधिकारिक दस्तावेज़ का संदर्भ ले सकते हैं।
कोई प्रत्यक्ष पीएसपी नियम स्थानांतरण नहीं: कुछ अन्य समाधानों के विपरीत, पीएसए पॉड सुरक्षा नीति (पीएसपी) नियमों को सीधे स्थानांतरित करने या संशोधित करने के लिए एक सीधी विधि प्रदान नहीं करता है। पीएसए का प्राथमिक ध्यान ऊपर उल्लिखित प्रोफाइल सहित स्थापित कुबेरनेट्स सुरक्षा मानकों के खिलाफ पॉड्स को मान्य करने पर है।
कोई उत्परिवर्तन नहीं : जबकि पीएसए सत्यापन में प्रभावी है, यह पीएसपी की तरह पॉड विनिर्देशों को संशोधित या अनुकूलित नहीं कर सकता है। पीएसए का मुख्य उद्देश्य पूर्वनिर्धारित कुबेरनेट्स सुरक्षा मानकों को लागू करना है और इसमें पॉड विनिर्देशों को बदलने या बदलने की सुविधाएँ शामिल नहीं हैं। यह मुख्य रूप से इन स्थापित मानकों के विरुद्ध पॉड्स को मान्य करने पर केंद्रित है।
चूंकि पीएसए एक कुबेरनेट्स नेटिव घटक है, इसे काम करने के लिए, आपको बस यह सुनिश्चित करना होगा कि आपके कुबेरनेट्स क्लस्टर में पॉड सिक्योरिटी एडमिशन (पीएसए) नियंत्रक सक्षम है। आप निम्न आदेश चलाकर ऐसा कर सकते हैं:
kubectl api-versions | grep admission
पॉड सुरक्षा प्रवेश का नियंत्रण नेमस्पेस लेबल से प्रभावित होता है। इसका तात्पर्य यह है कि नामस्थानों को अद्यतन करने, पैच करने या बनाने की क्षमता रखने वाले व्यक्तियों के पास उन नामस्थानों के लिए पॉड सुरक्षा सेटिंग्स को संशोधित करने का अधिकार भी है। यह संशोधन संभावित रूप से कड़ी सुरक्षा नीतियों को दरकिनार कर सकता है। आगे बढ़ने से पहले, यह सत्यापित करना आवश्यक है कि नेमस्पेस अनुमतियाँ विशेष रूप से विश्वसनीय और विशेषाधिकार प्राप्त उपयोगकर्ताओं को सौंपी गई हैं। यह सलाह दी जाती है कि उन उपयोगकर्ताओं को ये उन्नत अनुमतियाँ देने से परहेज करें जिन्हें ऐसी पहुँच की आवश्यकता नहीं है। यदि नेमस्पेस ऑब्जेक्ट पर पॉड सुरक्षा लेबल को कॉन्फ़िगर करने के लिए अतिरिक्त बाधाओं की आवश्यकता है, तो उन प्रतिबंधों को लागू करने के लिए प्रवेश वेबहुक का उपयोग करने पर विचार करें।
पॉड सिक्योरिटी एडमिशन (पीएसए) में स्थानांतरित होने से पहले, अपनी पॉड सिक्योरिटी पॉलिसी (पीएसपी) को सामान्य बनाना फायदेमंद है:
असमर्थित फ़ील्ड हटाएं : पॉड सुरक्षा मानकों द्वारा कवर नहीं किए गए विकल्पों को हटा दें। इन विकल्पों में शामिल हैं:
.spec.allowedHostPaths .spec.allowedFlexVolumes .spec.allowedCSIDrivers .spec.forbiddenSysctls .spec.runtimeClass
.spec.defaultAllowPrivilegeEscalation .spec.runtimeClass.defaultRuntimeClassName .metadata.annotations['seccomp.security.alpha.kubernetes.io/defaultProfileName'] .metadata.annotations['apparmor.security.beta.kubernetes.io/defaultProfileName'] .spec.defaultAddCapabilities
महत्वपूर्ण लेख:
इन फ़ील्ड्स को हटाने से कार्यभार में आवश्यक कॉन्फ़िगरेशन की कमी हो सकती है, जो संभावित रूप से परिचालन संबंधी समस्याएं पैदा कर सकती है। यह सुनिश्चित करना महत्वपूर्ण है कि कार्यभार सरलीकृत नीतियों के साथ सही ढंग से कार्य कर सके।
अपने नेमस्पेस के लिए उचित पॉड सुरक्षा स्तर का निर्धारण करते समय, आपके पास विचार करने के लिए कई तरीके हैं:
यदि आप नेमस्पेस के लिए अपेक्षित पहुंच स्तर और सुरक्षा आवश्यकताओं से परिचित हैं, तो आप उन विशिष्ट आवश्यकताओं के आधार पर एक उपयुक्त पॉड सुरक्षा स्तर का चयन कर सकते हैं। यह दृष्टिकोण उसी के समान है कि आप किसी नए क्लस्टर में सुरक्षा सेटिंग्स तक कैसे पहुंचेंगे।
अपनी प्रत्येक मौजूदा पॉड सुरक्षा नीतियों (पीएसपी) को संबंधित पॉड सुरक्षा मानक स्तर पर मैप करने के लिए "पॉड सुरक्षा नीतियों को पॉड सुरक्षा मानकों पर मैप करना" संदर्भ का उपयोग करें।
यदि आपके पीएसपी मूल रूप से पॉड सुरक्षा मानकों पर आधारित नहीं हैं, तो आपको निर्णय लेने की आवश्यकता हो सकती है। ऐसा पॉड सुरक्षा स्तर चुनें जो कम से कम आपके पीएसपी जितना अनुमेय हो, या ऐसा स्तर चुनें जो कम से कम प्रतिबंधात्मक हो। यह पहचानने के लिए कि किसी विशिष्ट नामस्थान के भीतर पॉड्स के लिए कौन से पीएसपी उपयोग में हैं, निम्नलिखित कमांड का उपयोग करें:
kubectl get pods -n $NAMESPACE -o jsonpath="{.items[*].metadata.annotations.kubernetes\.io\/psp}" | tr " " "\n" | sort -u
बेसलाइन और प्रतिबंधित पॉड सुरक्षा दोनों स्तरों का परीक्षण करने के लिए ड्राई रन करें और अगले अनुभाग से लेबल कमांड लागू करें। इससे आपको यह आकलन करने में मदद मिलती है कि क्या ये स्तर आपके मौजूदा कार्यभार के लिए पर्याप्त रूप से स्वीकार्य हैं। सबसे कम-विशेषाधिकार प्राप्त वैध स्तर चुनें जो आपके मौजूदा कार्यभार के साथ संरेखित हो।
यह ध्यान रखना महत्वपूर्ण है कि उल्लिखित विकल्प मौजूदा पॉड्स पर आधारित हैं, जो वर्तमान में नहीं चल रहे वर्कलोड के लिए जिम्मेदार नहीं हो सकते हैं। इसमें क्रोनजॉब्स, स्केल-टू-ज़ीरो वर्कलोड, या अन्य वर्कलोड शामिल हैं जिन्हें अभी तक तैनात नहीं किया गया है।
एक बार जब आप अपने नेमस्पेस के लिए पॉड सुरक्षा स्तर निर्धारित कर लेते हैं (विशेषाधिकार प्राप्त स्तर को छोड़कर), तो चुनी गई नीति को मान्य करना महत्वपूर्ण है। पॉड सिक्योरिटी सुचारू रोलआउट और सुरक्षा मानकों का अनुपालन सुनिश्चित करने के लिए परीक्षण विकल्प प्रदान करता है।
ड्राई रन परीक्षण:
तत्काल कार्यान्वयन के बिना चयनित नीति के प्रभाव का आकलन करने के लिए इस पद्धति का उपयोग करें।
ड्राई रन करने के लिए, निम्नलिखित कमांड का उपयोग करें, जो किसी भी मौजूदा पॉड को हाइलाइट करेगा जो निर्दिष्ट नीति स्तर को पूरा नहीं करता है:
kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/enforce=$LEVEL
ऑडिट मोड आपको नीति उल्लंघनों को लागू किए बिना रिकॉर्ड करने की अनुमति देता है। उल्लंघन करने वाले पॉड्स को बाद में समीक्षा के लिए ऑडिट रिकॉर्ड में लॉग किया जाता है। कमांड के साथ ऑडिट मोड सक्षम करें:
kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/audit=$LEVEL
यदि परीक्षण के दौरान अप्रत्याशित नीति उल्लंघन उत्पन्न होता है, तो आप यह कर सकते हैं:
एक बार जब आप आश्वस्त हो जाएं कि चयनित पॉड सुरक्षा स्तर आपके नेमस्पेस के लिए उपयुक्त है, तो आप इसे लागू करने के लिए आगे बढ़ सकते हैं। यह चरण सुनिश्चित करता है कि वांछित सुरक्षा मानक नामस्थान के भीतर आपके कार्यभार पर सक्रिय रूप से लागू होते हैं।
नेमस्पेस पर वांछित पॉड सुरक्षा स्तर लागू करने के लिए, निम्नलिखित कमांड का उपयोग करें:
kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/enforce=$LEVEL
इस आदेश को निष्पादित करने से निर्दिष्ट पॉड सुरक्षा स्तर सक्रिय और लागू हो जाएगा, जिससे आपके नेमस्पेस की सुरक्षा स्थिति बढ़ जाएगी।
YAML कॉन्फ़िगरेशन फ़ाइल, जैसे कि विशेषाधिकार प्राप्त-psp.yaml लागू करके एक पूर्ण विशेषाधिकार प्राप्त पॉड सुरक्षा नीति (PSP) बनाएं। इस पीएसपी को पॉड्स को सभी आवश्यक विशेषाधिकार प्रदान करने चाहिए और पॉड सुरक्षा नीतियों (पीएसपी) के उपयोग की अनुमति देने के लिए विशेषाधिकार प्राप्त-पीएसपी नामक एक क्लस्टर भूमिका बनानी चाहिए और इसे विशेषाधिकार प्राप्त पीएसपी के साथ जोड़ना चाहिए:
kubectl apply -f privileged-psp.yaml kubectl create clusterrole privileged-psp --verb use --resource podsecuritypolicies.policy --resource-name privileged
विशेषाधिकार प्राप्त-पीएसपी क्लस्टर भूमिका को system:serviceaccounts:$NAMESPACE
समूह के साथ संबद्ध करने के लिए लक्ष्य नामस्थान में एक भूमिका बाइंडिंग बनाएं। यह बाइंडिंग प्रभावी रूप से नेमस्पेस के भीतर सभी सेवा खातों को PodSecurityPolicy को दरकिनार करते हुए पूरी तरह से विशेषाधिकार प्राप्त PSP तक पहुंच प्रदान करती है:
kubectl create -n $NAMESPACE rolebinding disable-psp --clusterrole privileged-psp --group system:serviceaccounts:$NAMESPACE
इस सेटअप के साथ, विशेषाधिकार प्राप्त PSP गैर-परिवर्तनशील है, और PodSecurityPolicy प्रवेश नियंत्रक हमेशा गैर-परिवर्तनशील PSP को प्राथमिकता देता है। परिणामस्वरूप, इस नेमस्पेस में पॉड्स को अब PodSecurityPolicy द्वारा संशोधित या प्रतिबंधित नहीं किया जाएगा।
इस दृष्टिकोण का एक लाभ इसकी प्रतिवर्तीता है। यदि कोई समस्या आती है, तो आप PodSecurityPolicy को अक्षम करने से जुड़े रोलबाइंडिंग को हटाकर आसानी से परिवर्तन को वापस ले सकते हैं। सुनिश्चित करें कि इस प्रक्रिया के दौरान पहले से मौजूद पॉड सुरक्षा नीतियां लागू रहें।
नेमस्पेस के लिए PodSecurityPolicy अक्षमता को वापस लाने के लिए, बस पहले बनाई गई रोलबाइंडिंग को हटा दें:
kubectl delete -n $NAMESPACE rolebinding disable-psp
पॉड सुरक्षा प्रवेश को लागू करने के लिए मौजूदा नेमस्पेस को अपडेट करने के साथ, नए नेमस्पेस बनाने के लिए अपनी प्रक्रियाओं और नीतियों की समीक्षा करना और उन्हें अपडेट करना आवश्यक है। यह सुनिश्चित करता है कि नए नेमस्पेस शुरू से ही उपयुक्त पॉड सुरक्षा प्रोफ़ाइल के साथ कॉन्फ़िगर किए गए हैं।
नेमस्पेस निर्माण प्रक्रियाओं को बढ़ाने के लिए निम्नलिखित चरणों पर विचार करें:
नेमस्पेस निर्माण नीतियों को समायोजित करें : वांछित पॉड सुरक्षा स्तर के चयन और अनुप्रयोग को शामिल करने के लिए नए नेमस्पेस बनाने के लिए अपने संगठन की नीतियों और प्रक्रियाओं को अपडेट करें। सुनिश्चित करें कि निर्माण चरण से ही सुरक्षा मानक स्थापित हो जाएं।
स्थैतिक कॉन्फ़िगरेशन: आप बिना लेबल वाले नामस्थानों के लिए डिफ़ॉल्ट प्रवर्तन, ऑडिट और/या चेतावनी स्तरों को परिभाषित करने के लिए पॉड सुरक्षा प्रवेश नियंत्रक को स्थिर रूप से कॉन्फ़िगर कर सकते हैं। यह दृष्टिकोण सुनिश्चित करता है कि स्पष्ट पॉड सुरक्षा लेबल की कमी वाले नामस्थान अभी भी डिफ़ॉल्ट रूप से आपके निर्दिष्ट सुरक्षा मानकों का पालन करते हैं।
अपने नेमस्पेस निर्माण प्रक्रियाओं पर दोबारा गौर करके, आप हमारे कुबेरनेट्स वातावरण में पॉड सुरक्षा मानकों को निर्बाध रूप से एकीकृत कर सकते हैं और पुराने और नए सभी नेमस्पेस पर एक सुसंगत और सुरक्षित दृष्टिकोण बनाए रख सकते हैं।
एक बार जब आप आश्वस्त हो जाते हैं कि पॉड सिक्योरिटी पॉलिसी (पीएसपी) प्रवेश नियंत्रक की अब आवश्यकता नहीं है और पॉड सुरक्षा प्रवेश (पीएसए) सफलतापूर्वक लागू और मान्य हो गया है, तो आप पीएसपी प्रवेश नियंत्रक को अक्षम करने के लिए आगे बढ़ सकते हैं।
PSP प्रवेश नियंत्रक को अक्षम करने के चरण यहां दिए गए हैं:
क्यूब-एपिसर्वर कॉन्फ़िगरेशन संशोधित करें:
/etc/kubernetes/manifests/kube-apiserver.yaml.
--disable-admission-plugins
ध्वज जोड़ें। सुनिश्चित करें कि इसे सक्रिय प्रवेश प्लगइन्स की सूची से हटा दिया गया है। kube-apiserver --disable-admission-plugins=PodSecurityPolicy
क्यूब-एपिसर्वर पुनः प्रारंभ करें:
systemctl restart kubelet
पर्याप्त "सोख समय" के बाद यह आश्वस्त होने के लिए कि आपको पीएसपी पर वापस जाने की आवश्यकता नहीं होगी, अगले चरण पर आगे बढ़ें।
PSP प्रवेश नियंत्रक अक्षम और PSA के साथ, आप अपनी मौजूदा PodSecurityPolicies, साथ ही किसी भी संबद्ध भूमिका, ClusterRoles, RoleBindings और ClusterRoleBindings को सुरक्षित रूप से हटा सकते हैं।
kubectl delete podsecuritypolicies --all kubectl delete roles,clusterroles,rolebindings,clusterrolebindings --selector=rbac.authorization.kubernetes.io/autoupdate=true
यह सफ़ाई चरण सुनिश्चित करता है कि आपके क्लस्टर में कोई अवशिष्ट PSP कॉन्फ़िगरेशन नहीं है।
पीएसपी प्रवेश नियंत्रक को निष्क्रिय करके और पीएसपी-संबंधित संसाधनों को समाप्त करके, आप पॉड सुरक्षा प्रवेश में संक्रमण को पूरा करते हुए, अपने क्लस्टर की सुरक्षा वास्तुकला को सरल बनाते हैं।
इस व्यापक गाइड में, हमने आपके कुबेरनेट्स क्लस्टर के सुरक्षा ढांचे को पॉड सुरक्षा नीतियों (पीएसपी) से पॉड सुरक्षा प्रवेश (पीएसए) में सुचारू रूप से परिवर्तित करने के लिए आवश्यक कदमों और विचारों का पता लगाया है। यह माइग्रेशन सुनिश्चित करता है कि कुबेरनेट्स के विकसित सुरक्षा मानकों के अनुरूप आपका कार्यभार सुरक्षित रूप से चलता रहे।
यह मार्गदर्शिका आपको पीएसपी से पीएसए में आत्मविश्वास से स्थानांतरित करने के लिए आवश्यक ज्ञान और कदमों से लैस करती है, जो आपके कुबेरनेट्स वर्कलोड की सुरक्षा करते हुए एक सुरक्षित और कुशल संक्रमण सुनिश्चित करती है। आगामी लेखों के लिए बने रहें, जहां मैं किवर्नो और ओपीए गेटकीपर के लिए वैकल्पिक प्रवास पथ तलाशूंगा।