यह इस खंड का बहु-पृष्ठ प्रिंट योग्य दृश्य है। प्रिंट करने के लिए यहां क्लिक करें.

इस पृष्ठ के सामान्य दृश्य पर लौटें.

सुरक्षा (Security)

आपके क्लाउड-नेटिव वर्कलोड (cloud-native workload) को सुरक्षित रखने के लिए अवधारणाएँ (Concepts)।

कुबेरनेट्स (Kubernetes) दस्तावेज़ का यह खंड आपको वर्कलोड (workloads) को अधिक सुरक्षित रूप से चलाने के बारे में सीखने और कुबेरनेट्स क्लस्टर (cluster) को सुरक्षित रखने के आवश्यक पहलुओं के बारे में मदद करने के लिए है।

कुबेरनेट्स एक क्लाउड-नेटिव आर्किटेक्चर पर आधारित है, और क्लाउड नेटिव सूचना सुरक्षा के अच्छे अभ्यास के बारे में CNCF से सलाह लेता है।

अपने क्लस्टर और उस पर चल रहे एप्लिकेशन को सुरक्षित करने के व्यापक संदर्भ के लिए क्लाउड नेटिव सुरक्षा और कुबेरनेट्स (Cloud Native Security and Kubernetes) पढ़ें।

कुबेरनेट्स सुरक्षा तंत्र (Kubernetes security mechanisms)

कुबेरनेट्स में कई API और सुरक्षा नियंत्रण (security controls) शामिल हैं, साथ ही नीतियां (policies) परिभाषित करने के तरीके भी हैं जो यह तय कर सकते हैं कि आप सूचना सुरक्षा का प्रबंधन कैसे करते हैं।

कंट्रोल प्लेन सुरक्षा (Control plane protection)

किसी भी कुबेरनेट्स क्लस्टर के लिए एक प्रमुख सुरक्षा तंत्र कुबेरनेट्स API तक पहुंच को नियंत्रित करना है।

कुबेरनेट्स आपसे अपेक्षा करता है कि आप कंट्रोल प्लेन के भीतर, और कंट्रोल प्लेन और इसके क्लाइंट्स के बीच डेटा एन्क्रिप्शन इन ट्रांज़िट (data encryption in transit) प्रदान करने के लिए TLS को कॉन्फ़िगर और उपयोग करें। आप कुबेरनेट्स कंट्रोल प्लेन के भीतर संग्रहीत डेटा के लिए एन्क्रिप्शन एट रेस्ट (encryption at rest) भी सक्षम कर सकते हैं; यह आपके स्वयं के वर्कलोड के डेटा के लिए एन्क्रिप्शन एट रेस्ट का उपयोग करने से अलग है, जो एक अच्छा विचार भी हो सकता है।

सीक्रेट्स (Secrets)

Secret API उन कॉन्फ़िगरेशन मानों के लिए बुनियादी सुरक्षा प्रदान करता है जिनके लिए गोपनीयता की आवश्यकता होती है।

वर्कलोड सुरक्षा (Workload protection)

यह सुनिश्चित करने के लिए कि Pods और उनके कंटेनर उचित रूप से अलग (isolated) हैं, पॉड सुरक्षा मानकों (Pod security standards) को लागू करें। यदि आपको आवश्यकता हो तो कस्टम आइसोलेशन को परिभाषित करने के लिए आप RuntimeClasses का भी उपयोग कर सकते हैं।

नेटवर्क नीतियां (Network policies) आपको Pods के बीच, या Pods और आपके क्लस्टर के बाहर के नेटवर्क के बीच नेटवर्क ट्रैफ़िक को नियंत्रित करने देती हैं।

आप Pods, उनके कंटेनर और उनमें चलने वाली छवियों (images) के आसपास निवारक (preventative) या जासूसी (detective) नियंत्रण लागू करने के लिए व्यापक इकोसिस्टम (ecosystem) से सुरक्षा नियंत्रण तैनात कर सकते हैं।

एडमिशन कंट्रोल (Admission control)

एडमिशन कंट्रोलर (Admission controllers) प्लगइन्स (plugins) हैं जो कुबेरनेट्स API अनुरोधों को इंटरसेप्ट करते हैं और अनुरोध में विशिष्ट फ़ील्ड के आधार पर अनुरोधों को मान्य (validate) या परिवर्तित (mutate) कर सकते हैं। इन नियंत्रकों को सोच-समझकर डिज़ाइन करने से अनपेक्षित व्यवधानों से बचने में मदद मिलती है क्योंकि संस्करण अपडेट (version updates) में कुबेरनेट्स API बदलते हैं। डिज़ाइन संबंधी विचारों (design considerations) के लिए, एडमिशन वेबहुक गुड प्रैक्टिसेज (Admission Webhook Good Practices) देखें।

ऑडिटिंग (Auditing)

कुबेरनेट्स ऑडिट लॉगिंग क्लस्टर में क्रियाओं के अनुक्रम (sequence of actions) का दस्तावेजीकरण करने वाले सुरक्षा-प्रासंगिक (security-relevant), कालानुक्रमिक रिकॉर्ड प्रदान करता है। क्लस्टर उपयोगकर्ताओं द्वारा, कुबेरनेट्स API का उपयोग करने वाले एप्लिकेशन द्वारा, और स्वयं कंट्रोल प्लेन द्वारा उत्पन्न गतिविधियों का ऑडिट करता है।

क्लाउड प्रदाता सुरक्षा (Cloud provider security)

टिप्पणी: Items on this page refer to vendors external to Kubernetes. The Kubernetes project authors aren't responsible for those third-party products or projects. To add a vendor, product or project to this list, read the content guide before submitting a change. More information.

यदि आप कुबेरनेट्स क्लस्टर अपने स्वयं के हार्डवेयर या किसी भिन्न क्लाउड प्रदाता पर चला रहे हैं, तो सुरक्षा सर्वोत्तम प्रथाओं (security best practices) के लिए अपने दस्तावेज़ से परामर्श लें। यहां कुछ लोकप्रिय क्लाउड प्रदाताओं के सुरक्षा दस्तावेज़ों के लिंक दिए गए हैं:

क्लाउड प्रदाता सुरक्षा
IaaS प्रदाता लिंक
Alibaba Cloud https://www.alibabacloud.com/trust-center
Amazon Web Services https://aws.amazon.com/security
Google Cloud Platform https://cloud.google.com/security
Huawei Cloud https://www.huaweicloud.com/intl/en-us/securecenter/overallsafety
IBM Cloud https://www.ibm.com/cloud/security
Microsoft Azure https://docs.microsoft.com/en-us/azure/security/azure-security
Oracle Cloud Infrastructure https://www.oracle.com/security
Tencent Cloud https://www.tencentcloud.com/solutions/data-security-and-information-protection
VMware vSphere https://www.vmware.com/solutions/security/hardening-guides

नीतियां (Policies)

आप कुबेरनेट्स-नेटिव तंत्र (Kubernetes-native mechanisms) का उपयोग करके सुरक्षा नीतियां (security policies) परिभाषित कर सकते हैं, जैसे NetworkPolicy (नेटवर्क पैकेट फ़िल्टरिंग पर घोषणात्मक नियंत्रण (declarative control)) या ValidatingAdmissionPolicy (कुबेरनेट्स API का उपयोग करके कोई क्या परिवर्तन कर सकता है, इस पर घोषणात्मक प्रतिबंध)।

हालाँकि, आप कुबेरनेट्स के आसपास के व्यापक इकोसिस्टम से नीति कार्यान्वयन पर भी भरोसा कर सकते हैं। कुबेरनेट्स उन इकोसिस्टम परियोजनाओं को स्रोत कोड समीक्षा (source code review), कंटेनर इमेज अनुमोदन (container image approval), API पहुंच नियंत्रण, नेटवर्किंग और बहुत कुछ पर अपने स्वयं के नीति नियंत्रण (policy controls) लागू करने देने के लिए विस्तार तंत्र (extension mechanisms) प्रदान करता है।

नीति तंत्र (policy mechanisms) और कुबेरनेट्स के बारे में अधिक जानकारी के लिए, नीतियां (Policies) पढ़ें।

आगे क्या है

संबंधित कुबेरनेट्स सुरक्षा विषयों के बारे में जानें:

संदर्भ जानें:

प्रमाणित हों:

इस अनुभाग में और पढ़ें:

1 - पॉड सुरक्षा नीतियां (Pod Security Policies)

PodSecurityPolicy का उपयोग करने के बजाय, आप इनमें से किसी एक या दोनों का उपयोग करके Pods पर समान प्रतिबंध लागू कर सकते हैं:

माइग्रेशन गाइड के लिए, PodSecurityPolicy से Built-In PodSecurity एडमिशन कंट्रोलर पर माइग्रेट करें देखें। इस API को हटाए जाने के बारे में अधिक जानकारी के लिए, PodSecurityPolicy का हटाया जाना: अतीत, वर्तमान और भविष्य (Past, Present, and Future) देखें।

यदि आप Kubernetes v1.36 नहीं चला रहे हैं, तो अपने Kubernetes संस्करण के लिए दस्तावेज़ देखें।

2 - लिनक्स नोड्स के लिए सुरक्षा

यह पृष्ठ लिनक्स ऑपरेटिंग सिस्टम के लिए विशिष्ट सुरक्षा संबंधी विचारों और सर्वोत्तम प्रथाओं का वर्णन करता है।

नोड्स पर सीक्रेट (Secret) डेटा के लिए सुरक्षा

लिनक्स नोड्स पर, मेमोरी-समर्थित वॉल्यूम (जैसे कि secret वॉल्यूम माउंट्स, या emptyDir के साथ medium: Memory) tmpfs फाइल सिस्टम के साथ कार्यान्वित (implemented) किए जाते हैं।

यदि आपने स्वैप (swap) कॉन्फ़िगर किया है और एक पुराने लिनक्स कर्नेल का उपयोग करते हैं (या वर्तमान कर्नेल और कुबेरनेट्स का असमर्थित कॉन्फ़िगरेशन), तो मेमोरी (memory) समर्थित वॉल्यूम का डेटा परसिस्टेंट स्टोरेज (persistent storage) में लिखा जा सकता है।

लिनक्स कर्नेल आधिकारिक तौर पर संस्करण 6.3 से noswap विकल्प का समर्थन करता है, इसलिए यह अनुशंसा की जाती है कि यदि नोड पर स्वैप सक्षम (enabled) है, तो उपयोग किया जाने वाला कर्नेल संस्करण 6.3 या बाद का हो, या बैकपोर्ट (backport) के माध्यम से noswap विकल्प का समर्थन करता हो।

अधिक जानकारी के लिए स्वैप मेमोरी प्रबंधन (swap memory management) पढ़ें।

3 - विंडोज़ नोड्स के लिए सुरक्षा

यह पृष्ठ विंडोज़ ऑपरेटिंग सिस्टम के लिए विशिष्ट सुरक्षा संबंधी विचारों और सर्वोत्तम प्रथाओं का वर्णन करता है।

नोड्स पर सीक्रेट (Secret) डेटा के लिए सुरक्षा

विंडोज़ पर, सीक्रेट्स (Secrets) का डेटा नोड के स्थानीय स्टोरेज (local storage) पर स्पष्ट पाठ (clear text) में लिखा जाता है (लिनक्स पर tmpfs / इन-मेमोरी फ़ाइल सिस्टम के उपयोग की तुलना में)। एक क्लस्टर ऑपरेटर के रूप में, आपको निम्नलिखित दोनों अतिरिक्त उपाय करने चाहिए:

  1. सीक्रेट्स की फ़ाइल स्थान (file location) को सुरक्षित करने के लिए फ़ाइल ACL का उपयोग करें।
  2. BitLocker का उपयोग करके वॉल्यूम-स्तर एन्क्रिप्शन लागू करें।

कंटेनर उपयोगकर्ता (Container users)

विंडोज़ पॉड्स या कंटेनरों के लिए RunAsUsername निर्दिष्ट किया जा सकता है ताकि कंटेनर प्रक्रियाओं (processes) को विशिष्ट उपयोगकर्ता (user) के रूप में निष्पादित (execute) किया जा सके। यह लगभग RunAsUser के समतुल्य है।

विंडोज़ कंटेनर दो डिफ़ॉल्ट उपयोगकर्ता खाते प्रदान करते हैं, ContainerUser और ContainerAdministrator। इन दो उपयोगकर्ता खातों के बीच के अंतर को माइक्रोसॉफ्ट के Secure Windows containers दस्तावेज़ के भीतर When to use ContainerAdmin and ContainerUser user accounts में कवर किया गया है।

कंटेनर निर्माण (build) प्रक्रिया के दौरान स्थानीय उपयोगकर्ताओं (Local users) को कंटेनर छवियों (images) में जोड़ा जा सकता है।

टिप्पणी:

  • Nano Server आधारित छवियां डिफ़ॉल्ट रूप से ContainerUser के रूप में चलती हैं
  • Server Core आधारित छवियां डिफ़ॉल्ट रूप से ContainerAdministrator के रूप में चलती हैं

विंडोज़ कंटेनर Group Managed Service Accounts का उपयोग करके सक्रिय निर्देशिका पहचानों (Active Directory identities) के रूप में भी चल सकते हैं।

पॉड-स्तरीय सुरक्षा अलगाव (Pod-level security isolation)

लिनक्स-विशिष्ट पॉड सुरक्षा संदर्भ तंत्र (security context mechanisms) (जैसे SELinux, AppArmor, Seccomp, या कस्टम POSIX क्षमताएं) विंडोज़ नोड्स पर समर्थित नहीं हैं।

विशेषाधिकार प्राप्त कंटेनर (Privileged containers) विंडोज़ पर समर्थित नहीं हैं। इसके बजाय लिनक्स पर विशेषाधिकार प्राप्त कंटेनरों द्वारा किए जाने वाले कई कार्यों को करने के लिए विंडोज़ पर HostProcess containers का उपयोग किया जा सकता है।