Certified Kubernetes Security Specialist (CKS) परीक्षा, Kubernetes क्लस्टर पर कमांड लाइन से किए जाने वाले Kubernetes सुरक्षा कार्यों का एक वेंडर-न्यूट्रल (किसी खास कंपनी से न जुड़ा), परफॉर्मेंस-आधारित मूल्यांकन है। इसमें अभी Kubernetes v1.35 का इस्तेमाल होता है, लेकिन Linux Foundation इसके एनवायरनमेंट को Kubernetes के हालिया माइनर रिलीज़ के हिसाब से अपडेट करता रहता है; इसलिए किसी कमांड, फ़ीचर या डोमेन वेटेज पर भरोसा करने से पहले मौजूदा वर्शन और करिकुलम की जाँच कर लें। इसके छह डोमेन हैं: क्लस्टर सेटअप (15%), क्लस्टर हार्डनिंग (15%), सिस्टम हार्डनिंग (10%), माइक्रोसर्विस वल्नरेबिलिटीज़ को कम करना (20%), सप्लाई चेन सिक्योरिटी (20%), और मॉनिटरिंग, लॉगिंग और रनटाइम सिक्योरिटी (20%)। यह परीक्षा परफॉर्मेंस-आधारित है और ऑनलाइन प्रॉक्टरिंग के साथ होती है: इसमें आपको दो घंटे में कमांड लाइन से कई टास्क पूरे करने होते हैं, और इसके लिए ज़रूरी है कि आपने पहले Certified Kubernetes Administrator (CKA) परीक्षा पास की हो।
इसके बाद हम टास्क फ़्लो और मौजूदा डोमेन डिस्ट्रिब्यूशन को देख सकते हैं।
CKS टास्क तब पूरा होता है जब मांगी गई सिक्योरिटी स्थिति मौजूद हो और आपके पास इस बात का सबूत हो कि संबंधित Kubernetes कंट्रोल इसे लागू करता है। कमांड याद करने से ऑब्जेक्ट तो जल्दी बन सकता है, लेकिन इससे यह साबित नहीं होता कि वर्कलोड किसी पॉलिसी द्वारा चुना गया है, किसी आइडेंटिटी के पास सिर्फ़ ज़रूरी API परमिशन है, या कोई डिटेक्शन रूल उम्मीद के मुताबिक रनटाइम व्यवहार को देखता है। कॉन्फ़िगरेशन बदलने से पहले टारगेट रिसोर्स, सिक्योरिटी बाउंड्री और ज़रूरी वेरिफिकेशन सिग्नल की ज़रूरतों को पढ़ें।
समय के दबाव में, छोटे और जांचने लायक आर्टिफैक्ट बनाएं। इनमें आम तौर पर एक मैनिफ़ेस्ट शामिल होता है जो इच्छित स्थिति बताता है, एक सीमित दायरे वाला कमांड जो इसे लागू करता है या इसकी जांच करता है, और बदलाव के बाद ऑब्जेक्ट या व्यवहार दिखाने वाला आउटपुट होता है। मैनिफ़ेस्ट Kubernetes API को सबमिट किए गए कॉन्फ़िगरेशन को साबित करता है। कमांड आउटपुट सिर्फ़ उस समय, चुने गए क्लस्टर और नेमस्पेस के अंदर देखे गए रिसोर्स की स्थिति या रिस्पॉन्स को साबित करता है। इनमें से कोई भी अकेले यह साबित नहीं करता कि हर रास्ता सुरक्षित है।
दोहराए जा सकने वाले लूप का इस्तेमाल करें। सबसे पहले, एक्टिव क्लस्टर कॉन्टेक्स्ट और टारगेट नेमस्पेस की पहचान करें। इसके बाद, मौजूदा ऑब्जेक्ट और लेबल की जांच करें जो पॉलिसी चयन या ऑथराइज़ेशन का दायरा तय करते हैं। बताई गई स्थिति को ठीक करने वाला सबसे छोटा बदलाव लागू करें, फिर उस स्थिति से मेल खाने वाले ऑब्ज़र्वेशन के साथ नतीजे को वेरिफ़ाई करें। आखिर में, गलत बदलाव को वापस लेने के लिए काफ़ी कॉन्टेक्स्ट बनाए रखें, खासकर तब जब क्लस्टर-वाइड कॉन्फ़िगरेशन, नोड फ़ाइलें या API सर्वर सेटिंग्स में बदलाव कर रहे हों।
ऑपरेशनल नियम ऐसे जाने-पहचाने कमांड के बजाय, जो असंबंधित रिसोर्स को बदलते हैं, मांगी गई बाउंड्री से जुड़े सबूतों को प्राथमिकता दें।
इस कोर्स के दौरान, हम shop नेमस्पेस में एक काल्पनिक रिटेल वर्कलोड को सुरक्षित करेंगे। नेमस्पेस एक Kubernetes दायरा है जो नेमस्पेस वाले रिसोर्स को ग्रुप करता है और ऑथराइज़ेशन और पॉलिसी बाउंड्री बना सकता है। वर्कलोड में पोर्ट 8080 पर orders-api:1.0 के लिए बाहरी रूप से पहुंचने योग्य इनग्रेस पाथ है; वह एप्लिकेशन पोर्ट 8443 पर payments-api:1.0 को कॉल करता है; फिर payments-api orders-db का इस्तेमाल करता है। इस मॉडल में इनग्रेस के अलावा कोई भी वर्कलोड क्लस्टर के बाहर से पहुंचने योग्य नहीं है।
हर एप्लिकेशन अपने खुद के ServiceAccount का इस्तेमाल करता है, जो एक Kubernetes आइडेंटिटी है जिसका इस्तेमाल Pod तब कर सकता है जब वह Kubernetes API को कॉल करता है। orders-api orders-sa का इस्तेमाल करता है, जबकि payments-api payments-sa का इस्तेमाल करता है। इन पहचानों को अलग-अलग रखने से हम नेटवर्क रीचेबिलिटी, इमेज के ओरिजिन, पॉड पर लगी पाबंदियों और रनटाइम सिग्नल से अलग, ‘लीस्ट-प्रिविलेज ऑथराइजेशन’ (कम से कम अधिकार वाला ऑथराइजेशन) की जांच कर सकते हैं। सुरक्षा कंट्रोल चुनने से पहले वर्कलोड पाथ और पहचान की सीमा (आइडेंटिटी बाउंड्री) की पहचान करना एक ऐसा नियम है जिसे बार-बार इस्तेमाल किया जा सकता है।
अब हम उस वर्कलोड बाउंड्री का पता लगा सकते हैं जिसे बाद में सुरक्षा उपायों के ज़रिए बनाए रखना ज़रूरी होगा।