प्रमाणीकरण

समर्थित प्रमाणीकरण

Crateview अनाम रजिस्ट्रियों, मूल htpasswd Basic Auth और टोकन मोड में वैकल्पिक Crateview auth सेवा का समर्थन करता है। यह /v2/ की जांच करता है और जब रजिस्ट्री को मूल प्रमाणीकरण की आवश्यकता होती है तो साइन-इन फॉर्म प्रदर्शित करता है।

बाहरी Bearer-टोकन सेवाएँ और OIDC एकीकृत नहीं हैं। अपुष्ट बाहरी टोकन सेवाएँ एक स्पष्ट असमर्थित-auth नोटिस उत्पन्न करती हैं।

रजिस्ट्री-पक्ष Basic Auth

bcrypt पासवर्ड हैश के साथ एक htpasswd फ़ाइल बनाएं। निम्नलिखित उदाहरण एक अस्थायी आधिकारिक अपाचे कंटेनर का उपयोग करता है; उदाहरण क्रेडेंशियल बदलें और परिणामी फ़ाइल को सुरक्षित रखें:

mkdir -p auth
docker run --rm --entrypoint htpasswd httpd:2   -Bbn your-user choose-a-strong-password > auth/htpasswd

उदाहरण Distribution सेटिंग्स:

auth:
  htpasswd:
    realm: Registry
    path: /auth/htpasswd

जेनरेट की गई फ़ाइल को /auth/htpasswd पर रजिस्ट्री कंटेनर में माउंट करें। रजिस्ट्री कॉन्फ़िगरेशन Crateview कॉन्फ़िगरेशन से अलग है। रिमोट एक्सेस के लिए HTTPS का उपयोग करें; Basic Auth एक एन्कोडिंग है, ट्रांसपोर्ट एन्क्रिप्शन नहीं। साझा शेल इतिहास या सार्वजनिक उदाहरणों में वास्तविक पासवर्ड छोड़ने से बचें।

यूआई सत्र

Nitro सर्वर रजिस्ट्री के विरुद्ध क्रेडेंशियल मान्य करता है। यह उन्हें एन्क्रिप्टेड, HttpOnly, सेमसाइट=स्ट्रिक्ट कुकी में संग्रहीत करता है। ब्राउज़र जावास्क्रिप्ट और localStorage को क्रेडेंशियल प्राप्त नहीं होते हैं। सत्र आठ घंटे के बाद समाप्त हो जाते हैं।

एक यादृच्छिक उत्पादन सत्र रहस्य सेट करें:

openssl rand -base64 32

उत्पन्न मान का उपयोग NUXT_SESSION_PASSWORD के रूप में करें, जिसमें कम से कम 32 अक्षर हों। लोड बैलेंसर के पीछे प्रत्येक फ्रंटएंड इंस्टेंस को समान मान का उपयोग करना चाहिए। कॉन्फ़िगरेशन के बिना, Crateview एक प्रक्रिया-स्थानीय रहस्य उत्पन्न करता है, इसलिए पुनरारंभ मौजूदा सत्रों को अमान्य कर देता है।

HTTPS और लॉगआउट

जब सार्वजनिक अनुरोध प्रोटोकॉल HTTPS होता है तो सत्र कुकी सिक्योर का उपयोग करती है। रिवर्स प्रॉक्सी के अग्रेषित प्रोटोकॉल को सही ढंग से कॉन्फ़िगर करें। साइन आउट करने से यूआई सत्र साफ़ हो जाता है; यह रजिस्ट्री उपयोगकर्ताओं को हटाता या संशोधित नहीं करता है।

Docker और अन्य CLI क्लाइंट अपने सामान्य रजिस्ट्री क्रेडेंशियल्स का उपयोग करके सीधे /v2/** प्रॉक्सी के माध्यम से प्रमाणित करते हैं। वेब यूआई में साइन इन करने से Docker CLI स्वचालित रूप से साइन इन नहीं होता है।

वैकल्पिक खाता प्रबंधन

एक स्वतंत्र auth/प्रबंधन सेवा खाता निर्माण और स्वयं-पासवर्ड परिवर्तन का समर्थन करती है। Docker सीधे रजिस्ट्री से जुड़ता है और यूआई कंटेनर के बिना काम करता है। उपयोगकर्ता और bcrypt हैश htpasswd में रहते हैं; टोकन अनुमतियाँ permissions.json में रहती हैं। खाता संग्रहण SQLite का उपयोग नहीं करता है.

• बेसिक मोड: Distribution साझा htpasswd फ़ाइल की जाँच करता है; सभी उपयोगकर्ताओं के पास समान रजिस्ट्री पहुंच है। Docker को चलाने के लिए प्रबंधन सेवा की आवश्यकता नहीं है।
• टोकन मोड: स्वतंत्र auth सेवा पांच मिनट के टोकन पर हस्ताक्षर करती है; Distribution रिपॉजिटरी अनुमतियाँ लागू करता है। Docker को रजिस्ट्री और auth सेवा की आवश्यकता है। नए उपयोगकर्ताओं के पास प्रारंभ में कोई रिपॉजिटरी पहुंच नहीं है।
• यूआई: उपयोगकर्ता वर्तमान पासवर्ड प्रदान करके अपना पासवर्ड बदलते हैं। NUXT_USER_CREATION_ALLOWED_USERS डिफ़ॉल्ट रूप से खाली हो जाता है; alice,bob केवल उन्हीं उपयोगकर्ताओं को खाते बनाने की अनुमति देता है, * प्रत्येक प्रमाणित उपयोगकर्ता को अनुमति देता है। यह नीति सर्वर-साइड लागू की गई है।
• अनुमतियाँ: सीएलआई अनुदान सटीक रिपॉजिटरी, नेमस्पेस (team/*) या सब कुछ (*) को लक्षित करता है; प्रोफ़ाइल reader (pull), writer (pull/push), और manager (pull/push/delete) हैं। बेसिक मोड में कोई रजिस्ट्री भूमिका नहीं है।

NUXT_AUTH_MODE=htpasswd या token को स्पष्ट रूप से सक्षम करें और आंतरिक NUXT_AUTH_SERVICE_URL और केवल सर्वर NUXT_AUTH_SERVICE_SECRET को कॉन्फ़िगर करें। टोकन मोड को अतिरिक्त रूप से सार्वजनिक टोकन एंडपॉइंट से सटीक रूप से मेल खाने के लिए NUXT_AUTH_TOKEN_REALM की आवश्यकता होती है। अनाम रजिस्ट्रियां और बाहरी टोकन सेवाएँ स्थानीय खाता प्रबंधन का समर्थन नहीं करती हैं। अनुमतियाँ और प्रशासनिक पासवर्ड रीसेट auth CLI का उपयोग करते हैं; यूआई अन्य उपयोगकर्ताओं के पासवर्ड नहीं बदल सकता या अनुमतियाँ निर्दिष्ट नहीं कर सकता।

Compose ओवरले, सेटअप, माइग्रेशन और सीएलआई कमांड के लिए खाता सेवा गाइड देखें। यूआई से स्वतंत्र रूप से सार्वजनिक Docker पहुंच को सीधे रजिस्ट्री तक रूट करें। पहले जारी किए गए टोकन पासवर्ड परिवर्तन या अनुमति निरस्तीकरण के बाद पांच मिनट तक वैध रहते हैं।