Self-Hosted Server को सुरक्षित करना
network isolation, authentication, TLS, custom Python restrictions, और URL image input पर SSRF controls के साथ self-hosted Roboflow Inference server को सुरक्षित करें।
जब आप अपने हार्डवेयर पर Inference चलाते हैं, उसकी सुरक्षा स्थिति की ज़िम्मेदारी आपकी होती है. एक स्थानीय रूप से परिनियोजित सर्वर डिफ़ॉल्ट रूप से प्रमाणीकरण, एन्क्रिप्शन, या नेटवर्क प्रतिबंध लागू नहीं करता: इसे शुरू करना आसान बनाने के लिए बनाया गया है, इसे सुरक्षित रूप से उजागर करने के लिए नहीं। बॉक्स से बाहर, यह उस तक पहुँचने वाले किसी भी अनुरोध का जवाब देता है, जिसमें मॉडल चलाने और Workflows निष्पादित करने के अनुरोध भी शामिल हैं।
यह पृष्ठ उन पाँच नियंत्रणों को कवर करता है जिनकी हर self-hosted परिनियोजन को स्थानीय विकास ट्रैफ़िक से आगे कुछ भी संभालने से पहले समीक्षा करनी चाहिए। ये एक-दूसरे के पूरक हैं, इसलिए जितने आपके वातावरण में संभव हों उतने लागू करें।
यह आपकी ज़िम्मेदारी है। Roboflow प्रबंधित Serverless Cloud API और समर्पित परिनियोजन सेवाएँ। जिस सर्वर को आप स्वयं चलाते हैं, उसके होस्ट, उसके आसपास के नेटवर्क और उसके द्वारा स्वीकार किए जाने वाले क्रेडेंशियल्स को सुरक्षित रखना आपकी ज़िम्मेदारी है। यदि आपका सर्वर नीचे दिए गए नियंत्रणों के बिना किसी अविश्वसनीय नेटवर्क से पहुँच योग्य है, तो उसे पूरी दुनिया के लिए खुला मानें।
1. नेटवर्क पहुँच सीमित करें
सबसे प्रभावी नियंत्रण है कि सर्वर को शुरू से ही उजागर न किया जाए। Inference पोर्ट पर सुनता है 9001 डिफ़ॉल्ट रूप से और इसमें "विश्वसनीय" नेटवर्क की कोई अवधारणा नहीं है: जो भी उस पोर्ट तक पहुँच सकता है, वह इसका उपयोग कर सकता है।
localhost से बाँधें जब केवल उसी होस्ट पर चल रही प्रक्रियाओं को इसकी आवश्यकता हो, उदाहरण के लिए कंटेनर पोर्ट को इस रूप में प्रकाशित करें
127.0.0.1:9001:9001के बजाय9001:9001.इसे निजी नेटवर्क या VPC पर रखें और इसे सार्वजनिक IP के बजाय VPN, SSH टनल, या सेवा मेष के माध्यम से पहुँचें।
होस्ट और क्लाउड फ़ायरवॉल या सुरक्षा समूहों का उपयोग करें ताकि पोर्ट को अनुमति दें
9001सिर्फ़ उन विशिष्ट क्लाइंट्स से जिन्हें इसकी आवश्यकता है।इसके सामने एक रिवर्स प्रॉक्सी लगाएँ (nginx, Traefik, Caddy, या क्लाउड लोड बैलेंसर) यदि आपको इसे व्यापक रूप से उजागर करना है। इससे आपको TLS, दर-सीमितीकरण, और पहुँच लॉगिंग जोड़ने के लिए एक एकल स्थान मिलता है।
प्रमाणीकरण और TLS के बिना inference पोर्ट को सीधे सार्वजनिक इंटरनेट पर कभी प्रकाशित न करें।
2. प्रमाणीकरण लागू करें
डिफ़ॉल्ट रूप से एक self-hosted सर्वर नहीं अनुरोध करने के लिए API कुंजी की आवश्यकता होती। प्लेटफ़ॉर्म से डेटा लाते समय Roboflow API स्तर पर होने वाले प्रमाणीकरण के अलावा, सर्वर स्वयं पर कोई अतिरिक्त सुरक्षा नहीं होती। प्रमाणीकरण चालू करने के लिए, सेट करें WORKSPACES_WHITELISTED_FOR_LOCAL_DEPLOYMENT उन Roboflow workspace slugs की अल्पविराम से अलग की गई सूची पर सेट करें जिन्हें सर्वर का उपयोग करने की अनुमति है:
docker run --rm -p 9001:9001 \\
-e WORKSPACES_WHITELISTED_FOR_LOCAL_DEPLOYMENT=your-workspace-url-slug,another-workspace-url-slug \\
roboflow/roboflow-inference-server-cpu:latestयह सेट होने पर, सर्वर एक प्राधिकरण middleware स्थापित करता है। हर inference और Workflow अनुरोध में एक api_key (क्वेरी पैरामीटर के रूप में या JSON body में) होना चाहिए, जो Roboflow के माध्यम से whitelisted workspaces में से किसी एक से जुड़ता है। गुम, अमान्य, या गैर-श्वेतसूचीबद्ध कुंजी वाले अनुरोधों को अस्वीकृत किया जाता है 401 अनधिकृत.
API-कुंजी जाँच के दायरे में क्या शामिल नहीं है। प्रमाणीकरण-रहित endpoints का एक छोटा सेट खुला रहता है ताकि सर्वर उपयोग योग्य और निरीक्षण योग्य बना रहे: /, /docs, /redoc, /info, /healthz, /readiness, /metrics, /openapi.json, और स्थिर परिसंपत्तियाँ (/static/..., /_next/...). इसे समझें /info और /metrics ऐसी जानकारी के रूप में जिसे सर्वर तक पहुँच सकने वाला कोई भी व्यक्ति पढ़ सकता है, और यह सीमित करने के लिए नेटवर्क प्रतिबंधों (नियंत्रण 1) पर भरोसा करें कि वह कौन है।
अपना स्वयं का प्रमाणीकरण उपयोग करें। अंतर्निर्मित जाँच प्राधिकरण को Roboflow workspaces से जोड़ती है। यदि आपके पास अपना identity model है, तो सर्वर के सामने एक रिवर्स प्रॉक्सी या प्रमाणीकरण middleware रखें, जो OAuth/OIDC, mTLS, हस्ताक्षरित headers, API gateway, या आपकी संस्था पहले से जो भी उपयोग करती है, उसे लागू करे, और केवल प्रमाणित ट्रैफ़िक को पोर्ट तक जाने दें 9001. दोनों तरीकों को मिलाया जा सकता है।
3. जब नेटवर्क इसकी माँग करे, TLS सक्षम करें
अंतर्निहित API-कुंजी जाँच क्रेडेंशियल्स को अनुरोध में भेजती है। यदि वे अनुरोध किसी ऐसे नेटवर्क से होकर जाते हैं जिसे आप पूरी तरह नियंत्रित नहीं करते, तो कनेक्शन को एन्क्रिप्ट किया जाना चाहिए, अन्यथा कुंजियाँ और payloads plaintext में उजागर हो जाएँगे।
आपके पास दो विकल्प हैं:
रिवर्स प्रॉक्सी या लोड बैलेंसर पर TLS समाप्त करें सर्वर के सामने। जब आप पहले से ऐसा एक चलाते हैं, तो यही सामान्य विकल्प होता है।
HTTPS को सीधे सर्वर से प्रदान करें एक प्रमाणपत्र और key माउंट करके तथा सेट करके
ENABLE_HTTPS=true. देखें HTTPS के माध्यम से Inference प्रदान करना पूरी मार्गदर्शिका के लिए, जिसमें mutual TLS (client certificates) भी शामिल हैं, के माध्यम सेSSL_CA_CERTS.
केवल स्थानीय, लूपबैक-केवल ट्रैफ़िक के लिए (नियंत्रण 1, बंधा हुआ 127.0.0.1) TLS वैकल्पिक है। जब भी अनुरोध किसी अविश्वसनीय नेटवर्क के माध्यम से होस्ट को छोड़ते हैं, TLS आवश्यक है।
4. Workflows में कस्टम Python निष्पादन अक्षम करें
Workflows में शामिल हो सकते हैं कस्टम Python ब्लॉक: सर्वर प्रक्रिया के अंदर चलने वाला मनमाना Python। यह एक शक्तिशाली सुविधा है, लेकिन इसका अर्थ यह है कि जो कोई भी सर्वर पर Workflow सबमिट कर सकता है, वह आपके होस्ट पर मनमाना कोड चला सकता है। अविश्वसनीय क्लाइंट्स से पहुँच योग्य सर्वर पर, यह remote code execution है।
यह नियंत्रित होता है ALLOW_CUSTOM_PYTHON_EXECUTION_IN_WORKFLOWS.
सत्य (वर्तमान डिफ़ॉल्ट)
Workflows कस्टम Python ब्लॉक परिभाषित और चलाए जा सकते हैं।
असत्य
कस्टम Python ब्लॉक अस्वीकृत कर दिए जाते हैं; Workflow की बाकी सभी सुविधाएँ फिर भी काम करती हैं।
यदि आपके Workflows कस्टम Python पर निर्भर नहीं हैं, तो इसे सेट करें असत्य:
डिफ़ॉल्ट 2026-06-19 को बदल रहा है। आज यह फ़्लैग डिफ़ॉल्ट रूप से सत्य पिछली संगतता के लिए। 2026-06-19 को डिफ़ॉल्ट बदलकर असत्य। ALLOW_CUSTOM_PYTHON_EXECUTION_IN_WORKFLOWS=true स्पष्ट रूप से, ताकि उस तारीख के बाद भी वे काम करते रहें। अन्यथा इसे अक्षम ही छोड़ें, और इसे केवल उन परिनियोजनों पर सक्षम करना बेहतर है जहाँ ऊपर दिए गए नेटवर्क और प्रमाणीकरण नियंत्रण पहले से मौजूद हों।
5. URL से छवियाँ लाने को सीमित करें (SSRF)
Inference अनुरोध में दिए गए URL से सीधे छवियाँ लोड कर सकता है ({"image": {"type": "url", "value": "https://..."}})। जब भी कोई सर्वर ऐसे URL को लाता है जिसे कॉलर नियंत्रित करता है, कॉलर उसे अपनी ओर से अनुरोध करने के लिए मजबूर करने की कोशिश कर सकता है, जिसे हमले की एक श्रेणी कहा जाता है server-side request forgery (SSRF). जो व्यक्ति आपके आंतरिक नेटवर्क तक सीधे नहीं पहुँच सकता, वह आपके सर्वर से, उदाहरण के लिए, यह लाने के लिए कह सकता है:
http://169.254.169.254/latest/meta-data/, क्लाउड मेटाडेटा सेवा (AWS, GCP, Azure), जो instance credentials वापस दे सकती है।http://127.0.0.1:9001/...और अन्य localhost सेवाएँ: एडमिन पैनल, डेटाबेस, या Inference server के अपने प्रमाणीकरण-रहित endpoints.http://10.0.0.5/,http://192.168.1.1/, और आपके परिधि के पीछे मौजूद अन्य private (RFC1918), link-local, CGNAT, या IPv6 ULA hosts.
सार्वजनिक दिखने वाला hostname किसी सार्वजनिक target का प्रमाण नहीं है: वह निजी IP पर resolve हो सकता है, उसी पर redirect कर सकता है, या उपयोग कर सकता है DNS rebinding (सत्यापन जाँच के लिए सार्वजनिक IP पर resolve होना, फिर वास्तविक कनेक्शन के लिए private IP पर)। Inference इन सभी के लिए नियंत्रण प्रदान करता है।
यदि आपको इसकी आवश्यकता नहीं है, तो URL इनपुट बंद करें
सबसे मजबूत नियंत्रण है कि URL छवियाँ बिल्कुल स्वीकार ही न करें। यदि आपके क्लाइंट हमेशा छवियाँ base64 या फ़ाइल अपलोड के रूप में भेजते हैं, तो URL fetching को पूरी तरह अक्षम कर दें:
जब आपको URL इनपुट की आवश्यकता हो, तो उसे सख्त करें
जब URL छवियाँ आवश्यक हों, ये फ़्लैग सीमित करते हैं कि सर्वर क्या ला सकता है। मिलकर ये आंतरिक targets को अस्वीकार करते हैं, कनेक्शन को सत्यापित IP से पिन करते हैं (DNS rebinding को निष्फल करते हुए), और हर redirect hop की दोबारा जाँच करते हैं।
ALLOW_URL_INPUT
सत्य
URL image इनपुट के लिए मुख्य स्विच। असत्य सभी URL छवियों को अस्वीकार करता है।
ALLOW_URL_TO_NON_GLOBAL_ADDRESSES
सत्य
जब असत्य, तब ऐसा URL जिसका host किसी non-global address (loopback, private, link-local/metadata, CGNAT, IPv6 ULA, आदि) पर resolve होता है, अस्वीकार कर दिया जाता है, और connection को validated IP से pin किया जाता है ताकि दूसरा DNS उत्तर target को बदल न सके।
VALIDATE_IMAGE_URL_REDIRECTS
असत्य
जब सत्य, redirects को एक-एक hop करके फ़ॉलो किया जाता है और हर hop URL को फिर से सत्यापित किया जाता है, बजाय इसके कि उन्हें आँख बंद करके फ़ॉलो किया जाए।
MAX_IMAGE_URL_REDIRECTS
30
redirect hops पर सख्त सीमा, ऊपर दिए गए फ़्लैग की परवाह किए बिना लागू।
ALLOW_NON_HTTPS_URL_INPUT
असत्य
जब असत्य, केवल https:// URLs स्वीकार किए जाते हैं।
ALLOW_URL_INPUT_WITHOUT_FQDN
असत्य
जब असत्य, जिन URLs का host एक साधारण IP है या जिनमें public suffix नहीं है, उन्हें अस्वीकार किया जाता है, इसलिए कॉलर्स को वास्तविक domain name का उपयोग करना होगा।
WHITELISTED_DESTINATIONS_FOR_URL_INPUT
असेट
गंतव्यों की अल्पविराम से अलग की गई अनुमति सूची (subdomain.domain.suffix). जब यह सेट हो, केवल इन्हीं की अनुमति होती है।
BLACKLISTED_DESTINATIONS_FOR_URL_INPUT
असेट
गंतव्यों की अल्पविराम से अलग की गई अवरोध सूची जिन्हें हमेशा अस्वीकार किया जाता है।
एक सख्त कॉन्फ़िगरेशन जो फिर भी सार्वजनिक HTTPS image URLs की अनुमति देता है:
सबसे कड़े नियंत्रण के लिए, एक अनुमति सूची जोड़ें ताकि सर्वर केवल उन्हीं exact hosts तक पहुँच सके जिनसे आप images serve करते हैं:
Q4 2026 में दो डिफ़ॉल्ट बदल रहे हैं। ALLOW_URL_TO_NON_GLOBAL_ADDRESSES (से असत्य) और VALIDATE_IMAGE_URL_REDIRECTS (से सत्य) वर्तमान में पिछली संगतता के लिए विरासती, उदार व्यवहार पर डिफ़ॉल्ट हैं। दोनों डिफ़ॉल्टों को Q4 2026 में सुरक्षित मानों में बदलने की योजना है। उन्हें अभी स्पष्ट रूप से सेट करें—या तो जल्दी अपनाने के लिए सुरक्षित मानों पर, या यदि कोई Workflow सचमुच आंतरिक URLs लाने पर निर्भर है तो विरासती मानों पर—ताकि यह बदलाव आपको चौंकाए नहीं।
प्रॉक्सी इस सुरक्षा को बायपास कर देते हैं। यदि सर्वर के लिए कोई HTTP(S) proxy कॉन्फ़िगर किया गया है, तो destination को proxy (Inference नहीं) resolve करता है, इसलिए non-global blocking और connection pinning लागू नहीं किए जा सकते। जब सर्वर इसे पहचानता है, तो वह एक चेतावनी जारी करता है। यदि आप इन नियंत्रणों पर निर्भर हैं, तो इस बात को सीमित करें कि proxy स्वयं कहाँ तक पहुँच सकता है।
Python SDK में वही नियंत्रण। यह inference-sdk client URL से images लोड करते समय वही URL policy और SSRF protections लागू करता है, और वही environment variables पढ़ता है, इसलिए जो client भेजने से पहले URL images को hydrate करता है, वह भी कवर होता है।
अनुशंसित आधारभूत सेटअप
किसी भी self-hosted सर्वर के लिए जो इससे आगे पहुँच योग्य है localhost:
नेटवर्क पहुँच ज्ञात क्लाइंट्स तक सीमित (फ़ायरवॉल, निजी नेटवर्क, या प्रॉक्सी)।
WORKSPACES_WHITELISTED_FOR_LOCAL_DEPLOYMENTसेट करें, या सामने अपना स्वयं का प्रमाणीकरण रखें।TLS सर्वर पर या upstream प्रॉक्सी पर समाप्त किया गया।
ALLOW_CUSTOM_PYTHON_EXECUTION_IN_WORKFLOWS=falseजब तक आपको वास्तव में इसकी आवश्यकता न हो।URL image इनपुट अक्षम (
ALLOW_URL_INPUT=false), या इसके साथ सख्त किया गयाALLOW_URL_TO_NON_GLOBAL_ADDRESSES=falseऔरVALIDATE_IMAGE_URL_REDIRECTS=true, और जहाँ संभव हो वहाँ एक अनुमति सूची भी।
यह भी देखें स्वीकृत इनपुट स्वरूप pickled-numpy इनपुट नियंत्रण के लिए, और उत्पादन-तैयारी चेकलिस्ट त्रुटि प्रबंधन और दर सीमाओं के लिए।
अंतिम अपडेट
क्या यह उपयोगी था?