Basic Jenkins Information
Access
Username + Password
Jenkins में लॉगिन करने का सबसे सामान्य तरीका उपयोगकर्ता नाम या पासवर्ड के साथ है।
Cookie
यदि एक authorized cookie चोरी हो जाता है, तो इसे उपयोगकर्ता के सत्र तक पहुंचने के लिए उपयोग किया जा सकता है। कुकी आमतौर पर JSESSIONID.* कहलाती है। (एक उपयोगकर्ता अपने सभी सत्र समाप्त कर सकता है, लेकिन उसे पहले यह पता लगाना होगा कि एक कुकी चोरी हो गई है)।
SSO/Plugins
Jenkins को प्लगइन्स का उपयोग करके तीसरे पक्ष के SSO के माध्यम से सुलभ बनाया जा सकता है।
Tokens
उपयोगकर्ता टोकन उत्पन्न कर सकते हैं ताकि CLI या REST API के माध्यम से अनुप्रयोगों को उनकी पहचान में पहुंच प्रदान की जा सके।
SSH Keys
यह घटक Jenkins के लिए एक बिल्ट-इन SSH सर्वर प्रदान करता है। यह Jenkins CLI के लिए एक वैकल्पिक इंटरफ़ेस है, और किसी भी SSH क्लाइंट का उपयोग करके इस तरह से कमांड्स को इनवोक किया जा सकता है। (From the docs)
Authorization
/configureSecurity में यह संभव है कि Jenkins की प्राधिकरण विधि को कॉन्फ़िगर करें। कई विकल्प हैं:
कोई भी कुछ भी कर सकता है: यहां तक कि अनामिक पहुंच भी सर्वर का प्रशासन कर सकती है।
पुरानी विधि: Jenkins <1.164 के समान। यदि आपके पास "admin" भूमिका है, तो आपको सिस्टम पर पूर्ण नियंत्रण दिया जाएगा, और अन्यथा (जिसमें अनामिक उपयोगकर्ता शामिल हैं) आपको पढ़ने की पहुंच होगी।
लॉग-इन उपयोगकर्ता कुछ भी कर सकते हैं: इस मोड में, हर लॉग-इन उपयोगकर्ता को Jenkins का पूर्ण नियंत्रण मिलता है। एकमात्र उपयोगकर्ता जिसे पूर्ण नियंत्रण नहीं मिलेगा वह अनामिक उपयोगकर्ता है, जिसे केवल पढ़ने की पहुंच मिलती है।
मैट्रिक्स-आधारित सुरक्षा: आप एक तालिका में कौन क्या कर सकता है को कॉन्फ़िगर कर सकते हैं। प्रत्येक कॉलम एक अनुमति का प्रतिनिधित्व करता है। प्रत्येक पंक्ति एक उपयोगकर्ता या समूह/भूमिका का प्रतिनिधित्व करती है। इसमें एक विशेष उपयोगकर्ता 'अनामिक' शामिल है, जो अप्रमाणित उपयोगकर्ताओं का प्रतिनिधित्व करता है, साथ ही 'प्रमाणित', जो सभी प्रमाणित उपयोगकर्ताओं का प्रतिनिधित्व करता है।
प्रोजेक्ट-आधारित मैट्रिक्स प्राधिकरण रणनीति: यह मोड "मैट्रिक्स-आधारित सुरक्षा" का एक विस्तार है जो प्रत्येक प्रोजेक्ट के लिए अलग-अलग ACL मैट्रिक्स को परिभाषित करने की अनुमति देता है।
भूमिका-आधारित रणनीति: एक भूमिका-आधारित रणनीति का उपयोग करके प्राधिकरणों को परिभाषित करने की अनुमति देता है।
/role-strategyमें भूमिकाओं का प्रबंधन करें।
Security Realm
/configureSecurity में यह संभव है कि सुरक्षा क्षेत्र को कॉन्फ़िगर करें। डिफ़ॉल्ट रूप से Jenkins कुछ अलग-अलग सुरक्षा क्षेत्रों के लिए समर्थन शामिल करता है:
सर्वलेट कंटेनर को प्रतिनिधि बनाना: Jenkins नियंत्रक को चलाने वाले एक सर्वलेट कंटेनर को प्रमाणीकरण प्रतिनिधि बनाने के लिए, जैसे Jetty।
Jenkins का अपना उपयोगकर्ता डेटाबेस: प्रमाणीकरण के लिए बाहरी सिस्टम को प्रतिनिधि बनाने के बजाय Jenkins का अपना बिल्ट-इन उपयोगकर्ता डेटा स्टोर का उपयोग करें। यह डिफ़ॉल्ट रूप से सक्षम है।
LDAP: सभी प्रमाणीकरण को एक कॉन्फ़िगर किए गए LDAP सर्वर को प्रतिनिधि बनाना, जिसमें उपयोगकर्ता और समूह दोनों शामिल हैं।
Unix उपयोगकर्ता/समूह डेटाबेस: Jenkins नियंत्रक पर अंतर्निहित Unix OS-स्तरीय उपयोगकर्ता डेटाबेस को प्रमाणीकरण प्रतिनिधि बनाना। यह मोड प्राधिकरण के लिए Unix समूहों के पुन: उपयोग की भी अनुमति देगा।
प्लगइन्स अतिरिक्त सुरक्षा क्षेत्रों को प्रदान कर सकते हैं जो मौजूदा पहचान प्रणालियों में Jenkins को शामिल करने के लिए उपयोगी हो सकते हैं, जैसे:
Jenkins Nodes, Agents & Executors
docs से परिभाषाएँ:
Nodes वे मशीनें हैं जिन पर बिल्ड एजेंट्स चलते हैं। Jenkins प्रत्येक संलग्न नोड की डिस्क स्पेस, फ्री टेम्प स्पेस, फ्री स्वैप, क्लॉक टाइम/सिंक और प्रतिक्रिया समय के लिए निगरानी करता है। यदि इनमें से कोई भी मान कॉन्फ़िगर किए गए सीमा से बाहर जाता है तो एक नोड ऑफ़लाइन हो जाता है।
Agents कार्य निष्पादन का प्रबंधन करते हैं Jenkins नियंत्रक की ओर से executors का उपयोग करके। एक एजेंट किसी भी ऑपरेटिंग सिस्टम का उपयोग कर सकता है जो Java का समर्थन करता है। बिल्ड और परीक्षण के लिए आवश्यक उपकरण उस नोड पर स्थापित किए जाते हैं जहां एजेंट चलता है; उन्हें सीधे या एक कंटेनर में स्थापित किया जा सकता है (Docker या Kubernetes)। प्रत्येक एजेंट प्रभावी रूप से होस्ट मशीन पर अपने स्वयं के PID के साथ एक प्रक्रिया है।
एक executor एक कार्य निष्पादन के लिए स्लॉट है; प्रभावी रूप से, यह एजेंट में एक थ्रेड है। एक नोड पर executors की संख्या उस नोड पर एक समय में निष्पादित किए जा सकने वाले समवर्ती कार्यों की संख्या को परिभाषित करती है। दूसरे शब्दों में, यह निर्धारित करता है कि एक समय में उस नोड पर कितने समवर्ती पाइपलाइन stages निष्पादित हो सकते हैं।
Jenkins Secrets
Secrets और Credentials का एन्क्रिप्शन
docs से परिभाषा: Jenkins AES का उपयोग करके secrets, credentials, और उनके संबंधित एन्क्रिप्शन कुंजियों को एन्क्रिप्ट और सुरक्षित करता है। ये एन्क्रिप्शन कुंजियाँ $JENKINS_HOME/secrets/ में संग्रहीत की जाती हैं साथ ही मास्टर कुंजी जो इन कुंजियों की सुरक्षा करती है। इस निर्देशिका को इस प्रकार कॉन्फ़िगर किया जाना चाहिए कि केवल ऑपरेटिंग सिस्टम उपयोगकर्ता जिसके रूप में Jenkins नियंत्रक चल रहा है, इस निर्देशिका तक पढ़ने और लिखने की पहुंच हो (यानी, chmod मान 0700 या उपयुक्त फ़ाइल विशेषताओं का उपयोग करके)। मास्टर कुंजी (कभी-कभी क्रिप्टोजार्गन में "key encryption key" के रूप में संदर्भित) **Jenkins नियंत्रक फाइल सिस्टम पर $JENKINS_HOME/secrets/master.key में असुरक्षित संग्रहीत होती है जो उस फ़ाइल तक सीधे पहुंच वाले हमलावरों के खिलाफ सुरक्षा नहीं करती है। अधिकांश उपयोगकर्ता और डेवलपर्स इन एन्क्रिप्शन कुंजियों का अप्रत्यक्ष रूप से उपयोग करेंगे या तो Secret API के माध्यम से सामान्य गुप्त डेटा को एन्क्रिप्ट करने के लिए या credentials API के माध्यम से। क्रिप्टोक्यूरियस के लिए, Jenkins AES का उपयोग cipher block chaining (CBC) मोड में PKCS#5 padding और random IVs के साथ CryptoConfidentialKey के उदाहरणों को एन्क्रिप्ट करने के लिए करता है जो $JENKINS_HOME/secrets/ में उनकी CryptoConfidentialKey id के अनुरूप फ़ाइल नाम के साथ संग्रहीत होते हैं। सामान्य कुंजी ids में शामिल हैं:
hudson.util.Secret: सामान्य गुप्त डेटा के लिए उपयोग किया जाता है;com.cloudbees.plugins.credentials.SecretBytes.KEY: कुछ credentials प्रकारों के लिए उपयोग किया जाता है;jenkins.model.Jenkins.crumbSalt: CSRF सुरक्षा तंत्र द्वारा उपयोग किया जाता है; और
Credentials Access
Credentials को वैश्विक प्रदाताओं (/credentials/) के लिए स्कोप किया जा सकता है जो किसी भी कॉन्फ़िगर किए गए प्रोजेक्ट द्वारा एक्सेस किए जा सकते हैं, या विशिष्ट प्रोजेक्ट्स (/job/<project-name>/configure) के लिए स्कोप किया जा सकता है और इसलिए केवल विशिष्ट प्रोजेक्ट से एक्सेस किया जा सकता है।
docs के अनुसार: स्कोप में credentials को बिना किसी सीमा के पाइपलाइन में उपलब्ध कराया जाता है। बिल्ड लॉग में आकस्मिक एक्सपोजर को रोकने के लिए, credentials को नियमित आउटपुट से मास्क किया जाता है, इसलिए env (Linux) या set (Windows) का आह्वान, या उनके वातावरण या पैरामीटर प्रिंट करने वाले प्रोग्राम उन्हें बिल्ड लॉग में प्रकट नहीं करेंगे उन उपयोगकर्ताओं के लिए जिनके पास credentials तक पहुंच नहीं होगी।
यही कारण है कि credentials को बाहर निकालने के लिए एक हमलावर को, उदाहरण के लिए, उन्हें base64 करना होगा।
References
Last updated
