🥇कुबर्नेट्समधील सेककॉम्प: सुरुवातीपासूनच तुम्हाला माहित असायला हव्या असलेल्या ७ गोष्टी

नोंद. अनुवाद: ब्रिटीश कंपनी ASOS.com मधील वरिष्ठ ऍप्लिकेशन सुरक्षा अभियंता यांच्या लेखाचे भाषांतर आम्ही तुमच्या लक्षात आणून देत आहोत. यासह, तो seccomp च्या वापराद्वारे Kubernetes मध्ये सुरक्षा सुधारण्यासाठी समर्पित प्रकाशनांची मालिका सुरू करतो. जर वाचकांना प्रस्तावना आवडली, तर आम्ही लेखकाचे अनुसरण करू आणि या विषयावरील त्यांचे भविष्यातील साहित्य चालू ठेवू.

कुबर्नेट्समधील सेककॉम्प: 7 गोष्टी ज्या तुम्हाला अगदी सुरुवातीपासूनच माहित असणे आवश्यक आहे

जादू आणि जादूटोण्यांचा अवलंब न करता, SecDevOps च्या भावनेने seccomp प्रोफाइल कसे तयार करावे यावरील पोस्टच्या मालिकेतील हा लेख पहिला आहे. भाग XNUMX मध्ये, मी Kubernetes मध्ये seccomp लागू करण्याच्या मूलभूत गोष्टी आणि अंतर्गत तपशील समाविष्ट करेन.

कुबर्नेट्स इकोसिस्टम कंटेनर सुरक्षित करण्यासाठी आणि वेगळे करण्याचे विविध मार्ग प्रदान करते. लेख सुरक्षित संगणन मोड या नावानेही ओळखला जातो याबद्दल आहे सेकॉम्प. कंटेनरद्वारे अंमलबजावणीसाठी उपलब्ध सिस्टम कॉल फिल्टर करणे हे त्याचे सार आहे.

ते महत्त्वाचे का आहे? कंटेनर ही केवळ विशिष्ट मशीनवर चालणारी प्रक्रिया आहे. आणि ते इतर ऍप्लिकेशन्सप्रमाणेच कर्नल वापरते. जर कंटेनर कोणतेही सिस्टम कॉल करू शकत असतील, तर लवकरच मालवेअर कंटेनर अलगाव बायपास करण्यासाठी याचा फायदा घेईल आणि इतर अनुप्रयोगांवर परिणाम करेल: माहिती रोखणे, सिस्टम सेटिंग्ज बदलणे इ.

seccomp प्रोफाइल परिभाषित करतात की कोणत्या सिस्टम कॉलला अनुमती द्यावी किंवा अक्षम करावी. कंटेनर रनटाइम सुरू झाल्यावर त्यांना सक्रिय करतो जेणेकरून कर्नल त्यांच्या अंमलबजावणीचे निरीक्षण करू शकेल. अशा प्रोफाईलचा वापर केल्याने तुम्हाला अटॅक वेक्टर मर्यादित करता येतो आणि कंटेनरमधील कोणताही प्रोग्राम (म्हणजे तुमची अवलंबित्वे किंवा त्यांचे अवलंबित्व) असे काही करू लागल्यास नुकसान कमी करू शकते जे करण्याची परवानगी नाही.

मूलभूत गोष्टी समजून घेणे

मूलभूत seccomp प्रोफाइलमध्ये तीन घटक समाविष्ट आहेत: defaultAction, architectures (किंवा archMap) आणि syscalls:

{
    "defaultAction": "SCMP_ACT_ERRNO",
    "architectures": [
        "SCMP_ARCH_X86_64",
        "SCMP_ARCH_X86",
        "SCMP_ARCH_X32"
    ],
    "syscalls": [
        {
            "names": [
                "arch_prctl",
                "sched_yield",
                "futex",
                "write",
                "mmap",
                "exit_group",
                "madvise",
                "rt_sigprocmask",
                "getpid",
                "gettid",
                "tgkill",
                "rt_sigaction",
                "read",
                "getpgrp"
            ],
            "action": "SCMP_ACT_ALLOW"
        }
    ]
}

(medium-basic-seccomp.json)

defaultAction विभागात निर्दिष्ट न केलेल्या कोणत्याही सिस्टम कॉलचे डीफॉल्ट भविष्य निर्धारित करते syscalls. गोष्टी सुलभ करण्यासाठी, वापरल्या जाणार्‍या दोन मुख्य मूल्यांवर लक्ष केंद्रित करूया:

SCMP_ACT_ERRNO - सिस्टम कॉलची अंमलबजावणी अवरोधित करते,
SCMP_ACT_ALLOW - परवानगी देते.

विभाग architectures लक्ष्य आर्किटेक्चर सूचीबद्ध आहेत. हे महत्त्वाचे आहे कारण फिल्टर स्वतः, कर्नल स्तरावर लागू केले जाते, सिस्टम कॉल आयडेंटिफायर्सवर अवलंबून असते, प्रोफाइलमध्ये निर्दिष्ट केलेल्या त्यांच्या नावांवर नाही. कंटेनर रनटाइम वापरण्यापूर्वी ओळखकर्त्यांशी जुळेल. कल्पना अशी आहे की सिस्टम कॉलमध्ये सिस्टम आर्किटेक्चरवर अवलंबून पूर्णपणे भिन्न ID असू शकतात. उदाहरणार्थ, सिस्टम कॉल recvfrom (सॉकेटमधून माहिती प्राप्त करण्यासाठी वापरला जातो) x64 सिस्टमवर ID = 64 आणि x517 वर ID = 86 आहे. तो आहे तुम्ही x86-x64 आर्किटेक्चरसाठी सर्व सिस्टम कॉल्सची सूची शोधू शकता.

विभागात syscalls सर्व सिस्टम कॉल्सची यादी करते आणि त्यांचे काय करायचे ते निर्दिष्ट करते. उदाहरणार्थ, तुम्ही सेटिंग करून श्वेतसूची तयार करू शकता defaultAction वर SCMP_ACT_ERRNO, आणि विभागात कॉल करा syscalls नियुक्त करणे SCMP_ACT_ALLOW. अशा प्रकारे, तुम्ही विभागामध्ये निर्दिष्ट केलेल्या कॉललाच अनुमती देता syscalls, आणि इतर सर्व प्रतिबंधित करा. काळ्या सूचीसाठी तुम्ही मूल्ये बदलली पाहिजेत defaultAction आणि उलट क्रिया.

आता आपण अशा सूक्ष्म गोष्टींबद्दल काही शब्द बोलले पाहिजेत जे इतके स्पष्ट नाहीत. कृपया लक्षात घ्या की खाली दिलेल्या शिफारसी असे गृहीत धरतात की तुम्ही Kubernetes वर व्यवसाय अनुप्रयोगांची एक ओळ उपयोजित करत आहात आणि त्यांना शक्य तितक्या कमीत कमी विशेषाधिकारांसह चालवायचे आहे.

1. AllowPrivilegeEscalation=false

В securityContext कंटेनरमध्ये पॅरामीटर आहे AllowPrivilegeEscalation. मध्ये स्थापित केले असल्यास false, कंटेनर यासह सुरू होतील (on) बिट no_new_priv. या पॅरामीटरचा अर्थ नावावरून स्पष्ट आहे: ते कंटेनरला स्वतःपेक्षा अधिक विशेषाधिकारांसह नवीन प्रक्रिया सुरू करण्यापासून प्रतिबंधित करते.

या पर्यायाचा एक दुष्परिणाम सेट केला जात आहे true (डिफॉल्ट) म्हणजे कंटेनर रनटाइम स्टार्टअप प्रक्रियेच्या अगदी सुरुवातीला seccomp प्रोफाइल लागू करतो. अशा प्रकारे, अंतर्गत रनटाइम प्रक्रिया चालविण्यासाठी आवश्यक असलेले सर्व सिस्टम कॉल (उदा. वापरकर्ता/ग्रुप आयडी सेट करणे, विशिष्ट क्षमता सोडणे) प्रोफाइलमध्ये सक्षम करणे आवश्यक आहे.

क्षुल्लक गोष्टी करणाऱ्या कंटेनरला echo hi, खालील परवानग्या आवश्यक असतील:

{
    "defaultAction": "SCMP_ACT_ERRNO",
    "architectures": [
        "SCMP_ARCH_X86_64",
        "SCMP_ARCH_X86",
        "SCMP_ARCH_X32"
    ],
    "syscalls": [
        {
            "names": [
                "arch_prctl",
                "brk",
                "capget",
                "capset",
                "chdir",
                "close",
                "execve",
                "exit_group",
                "fstat",
                "fstatfs",
                "futex",
                "getdents64",
                "getppid",
                "lstat",
                "mprotect",
                "nanosleep",
                "newfstatat",
                "openat",
                "prctl",
                "read",
                "rt_sigaction",
                "statfs",
                "setgid",
                "setgroups",
                "setuid",
                "stat",
                "uname",
                "write"
            ],
            "action": "SCMP_ACT_ALLOW"
        }
    ]
}

(hi-pod-seccomp.json)

...या ऐवजी:

{
    "defaultAction": "SCMP_ACT_ERRNO",
    "architectures": [
        "SCMP_ARCH_X86_64",
        "SCMP_ARCH_X86",
        "SCMP_ARCH_X32"
    ],
    "syscalls": [
        {
            "names": [
                "arch_prctl",
                "brk",
                "close",
                "execve",
                "exit_group",
                "futex",
                "mprotect",
                "nanosleep",
                "stat",
                "write"
            ],
            "action": "SCMP_ACT_ALLOW"
        }
    ]
}

(hi-container-seccomp.json)

पण पुन्हा, ही समस्या का आहे? व्यक्तिशः, मी खालील सिस्टम कॉल्सची व्हाइटलिस्ट करणे टाळेन (जोपर्यंत त्यांची खरी गरज नसेल): capset, set_tid_address, setgid, setgroups и setuid. तथापि, खरे आव्हान हे आहे की ज्या प्रक्रियेवर तुमचे कोणतेही नियंत्रण नाही अशा प्रक्रियांना परवानगी देऊन तुम्ही कंटेनर रनटाइम अंमलबजावणीसाठी प्रोफाइल बांधत आहात. दुसऱ्या शब्दांत, एके दिवशी तुम्हाला आढळेल की कंटेनर रनटाइम वातावरण (एकतर तुमच्याद्वारे किंवा बहुधा, क्लाउड सेवा प्रदात्याद्वारे) अद्यतनित केल्यानंतर, कंटेनर अचानक चालू होणे थांबवतात.

टीप # 1: सह कंटेनर चालवा AllowPrivilegeEscaltion=false. हे seccomp प्रोफाइल्सचा आकार कमी करेल आणि कंटेनर रनटाइम वातावरणातील बदलांना कमी संवेदनशील करेल.

2. कंटेनर स्तरावर seccomp प्रोफाइल सेट करणे

seccomp प्रोफाइल पॉड स्तरावर सेट केले जाऊ शकते:

annotations:
  seccomp.security.alpha.kubernetes.io/pod: "localhost/profile.json"

...किंवा कंटेनर स्तरावर:

annotations:
  container.security.alpha.kubernetes.io/<container-name>: "localhost/profile.json"

Kubernetes seccomp तेव्हा वरील वाक्यरचना बदलेल याची कृपया नोंद घ्या GA होईल (हा कार्यक्रम Kubernetes - 1.18 - अंदाजे अनुवादाच्या पुढील प्रकाशनात अपेक्षित आहे).

कुबर्नेट्स नेहमीच होते हे फार कमी लोकांना माहित आहे किडाज्यामुळे seccomp प्रोफाइल लागू केले गेले कंटेनर विराम द्या. रनटाइम वातावरण अंशतः या कमतरतेची भरपाई करते, परंतु हे कंटेनर पॉड्समधून अदृश्य होत नाही, कारण ते त्यांच्या पायाभूत सुविधा कॉन्फिगर करण्यासाठी वापरले जाते.

समस्या अशी आहे की हा कंटेनर नेहमीच सुरू होतो AllowPrivilegeEscalation=true, परिच्छेद 1 मध्ये आवाज उठवलेल्या समस्यांकडे अग्रगण्य, आणि हे बदलले जाऊ शकत नाही.

कंटेनर स्तरावर seccomp प्रोफाइल वापरून, तुम्ही हा त्रास टाळता आणि विशिष्ट कंटेनरसाठी तयार केलेली प्रोफाइल तयार करू शकता. विकासक बगचे निराकरण करेपर्यंत आणि नवीन आवृत्ती (कदाचित 1.18?) प्रत्येकासाठी उपलब्ध होईपर्यंत हे करावे लागेल.

टीप # 2: कंटेनर स्तरावर seccomp प्रोफाइल सेट करा.

व्यावहारिक अर्थाने, हा नियम सहसा या प्रश्नाचे सार्वत्रिक उत्तर म्हणून काम करतो: “माझे seccomp प्रोफाइल का काम करते? docker runपरंतु कुबर्नेट्स क्लस्टरमध्ये तैनात केल्यानंतर कार्य करत नाही?

3. फक्त शेवटचा उपाय म्हणून रनटाइम/डिफॉल्ट वापरा

कुबर्नेट्सकडे अंगभूत प्रोफाइलसाठी दोन पर्याय आहेत: runtime/default и docker/default. दोन्ही कंटेनर रनटाइमद्वारे अंमलात आणले जातात, कुबेरनेटेसने नव्हे. म्हणून, वापरलेले रनटाइम वातावरण आणि त्याची आवृत्ती यावर अवलंबून ते भिन्न असू शकतात.

दुसऱ्या शब्दांत, रनटाइम बदलण्याच्या परिणामी, कंटेनरला सिस्टम कॉलच्या वेगळ्या सेटमध्ये प्रवेश असू शकतो, जो तो वापरू शकतो किंवा करू शकत नाही. बहुतेक रनटाइम वापरतात डॉकर अंमलबजावणी. तुम्ही हे प्रोफाइल वापरू इच्छित असल्यास, कृपया ते तुमच्यासाठी योग्य असल्याची खात्री करा.

प्रोफाइल docker/default Kubernetes 1.11 पासून नापसंत केले गेले आहे, त्यामुळे ते वापरणे टाळा.

माझ्या मते, प्रोफाइल runtime/default ज्या उद्देशासाठी ते तयार केले गेले त्या उद्देशासाठी पूर्णपणे अनुकूल: कमांड कार्यान्वित करण्याशी संबंधित जोखमीपासून वापरकर्त्यांचे संरक्षण करणे docker run त्यांच्या गाड्यांवर. तथापि, जेव्हा कुबर्नेट्स क्लस्टर्सवर चालणार्‍या व्यवसाय अनुप्रयोगांचा विचार केला जातो तेव्हा मी असा युक्तिवाद करण्याचे धाडस करेन की असे प्रोफाइल खूप खुले आहे आणि विकासकांनी त्यांच्या अनुप्रयोगांसाठी (किंवा अनुप्रयोगांचे प्रकार) प्रोफाइल तयार करण्यावर लक्ष केंद्रित केले पाहिजे.

टीप # 3: विशिष्ट अनुप्रयोगांसाठी seccomp प्रोफाइल तयार करा. हे शक्य नसल्यास, अनुप्रयोग प्रकारांसाठी प्रोफाइल तयार करा, उदाहरणार्थ, एक प्रगत प्रोफाइल तयार करा ज्यामध्ये Golang अनुप्रयोगाचे सर्व वेब API समाविष्ट आहेत. फक्त शेवटचा उपाय म्हणून रनटाइम/डीफॉल्ट वापरा.

भविष्यातील पोस्टमध्ये, मी SecDevOps-प्रेरित seccomp प्रोफाइल कसे तयार करावे, ते स्वयंचलित कसे करावे आणि पाइपलाइनमध्ये त्यांची चाचणी कशी करावी हे सांगेन. दुसऱ्या शब्दांत, तुमच्याकडे अनुप्रयोग-विशिष्ट प्रोफाइल्सवर अपग्रेड न करण्याचे कोणतेही निमित्त असणार नाही.

4. Unconfined हा पर्याय नाही.

इझ प्रथम कुबर्नेट्स सुरक्षा ऑडिट हे डीफॉल्टनुसार बाहेर वळले seccomp अक्षम. याचा अर्थ असा की जर तुम्ही सेट केले नाही PodSecurityPolicy, जे ते क्लस्टरमध्ये सक्षम करेल, सर्व पॉड्स ज्यासाठी seccomp प्रोफाइल परिभाषित केलेले नाही seccomp=unconfined.

या मोडमध्ये कार्य करणे म्हणजे इन्सुलेशनचा संपूर्ण थर नष्ट होतो जो क्लस्टरचे संरक्षण करतो. सुरक्षा तज्ञांनी या पद्धतीची शिफारस केलेली नाही.

टीप # 4: क्लस्टरमधील कोणताही कंटेनर आत चालू नसावा seccomp=unconfined, विशेषतः उत्पादन वातावरणात.

5. "ऑडिट मोड"

हा मुद्दा कुबर्नेट्ससाठी अद्वितीय नाही, परंतु तरीही "शुरू करण्यापूर्वी जाणून घ्यायच्या गोष्टी" श्रेणीत येतो.

जसे घडते तसे, seccomp प्रोफाइल तयार करणे नेहमीच आव्हानात्मक असते आणि चाचणी आणि त्रुटीवर खूप अवलंबून असते. वस्तुस्थिती अशी आहे की वापरकर्त्यांना अनुप्रयोग "ड्रॉप" करण्याचा धोका न घेता उत्पादन वातावरणात त्यांची चाचणी घेण्याची संधी नसते.

गाभा दिसल्यानंतर Linux 4.14 मध्ये प्रोफाइलचे काही भाग ऑडिट मोडमध्ये चालवण्याची क्षमता सादर करण्यात आली, ज्यामुळे सर्व सिस्टम कॉल्सना ब्लॉक न करता त्यांची माहिती syslog मध्ये लॉग केली जाते. हा मोड पॅरामीटर वापरून सक्रिय केला जाऊ शकतो. SCMT_ACT_LOG:

SCMP_ACT_LOG: seccomp सिस्टीम कॉल करणार्‍या थ्रेडवर परिणाम करणार नाही जर ते फिल्टरमधील कोणत्याही नियमाशी जुळत नसेल, परंतु सिस्टम कॉलबद्दल माहिती लॉग केली जाईल.

हे वैशिष्ट्य वापरण्यासाठी येथे एक विशिष्ट धोरण आहे:

आवश्यक असलेल्या सिस्टम कॉलला अनुमती द्या.
तुम्हाला माहीत असलेल्या सिस्टीममधील कॉल्स ब्लॉक करा.
लॉगमध्ये इतर सर्व कॉल्सची माहिती रेकॉर्ड करा.

एक सरलीकृत उदाहरण असे दिसते:

{
    "defaultAction": "SCMP_ACT_LOG",
    "architectures": [
        "SCMP_ARCH_X86_64",
        "SCMP_ARCH_X86",
        "SCMP_ARCH_X32"
    ],
    "syscalls": [
        {
            "names": [
                "arch_prctl",
                "sched_yield",
                "futex",
                "write",
                "mmap",
                "exit_group",
                "madvise",
                "rt_sigprocmask",
                "getpid",
                "gettid",
                "tgkill",
                "rt_sigaction",
                "read",
                "getpgrp"
            ],
            "action": "SCMP_ACT_ALLOW"
        },
        {
            "names": [
                "add_key",
                "keyctl",
                "ptrace"
            ],
            "action": "SCMP_ACT_ERRNO"
        }
    ]
}

(मध्यम-मिश्र-seccomp.json)

परंतु लक्षात ठेवा की तुम्हाला माहित असलेले सर्व कॉल्स ब्लॉक करणे आवश्यक आहे जे वापरले जाणार नाहीत आणि ते क्लस्टरला हानी पोहोचवू शकतात. यादी संकलित करण्यासाठी एक चांगला आधार म्हणजे अधिकृत डॉकर दस्तऐवजीकरण. डीफॉल्ट प्रोफाइलमध्ये कोणते सिस्टम कॉल ब्लॉक केले आहेत आणि का ते तपशीलवार स्पष्ट करते.

तथापि, एक झेल आहे. तरी SCMT_ACT_LOG कर्नलद्वारे समर्थित Linux २०१७ च्या अखेरीस ते नुकतेच कुबरनेटीस इकोसिस्टममध्ये दाखल झाले आहे. त्यामुळे, ही पद्धत वापरण्यासाठी तुम्हाला कर्नलची आवश्यकता असेल. Linux ४.१४ आणि runC आवृत्ती त्यापेक्षा कमी नसावी. v1.0.0-rc9.

टीप # 5: उत्पादनातील चाचणीसाठी ऑडिट मोड प्रोफाइल ब्लॅक आणि व्हाईट याद्या एकत्र करून तयार केले जाऊ शकते आणि सर्व अपवाद लॉग केले जाऊ शकतात.

6. श्वेतसूची वापरा

व्हाइटलिस्टिंगसाठी अतिरिक्त प्रयत्न आवश्यक आहेत कारण तुम्हाला अनुप्रयोगाला आवश्यक असणारा प्रत्येक कॉल ओळखावा लागेल, परंतु हा दृष्टीकोन मोठ्या प्रमाणात सुरक्षा सुधारतो:

श्वेतसूची पद्धत वापरण्याची अत्यंत शिफारस केली जाते कारण ती सोपी आणि अधिक विश्वासार्ह आहे. जेव्हा जेव्हा संभाव्य धोकादायक सिस्टम कॉल (किंवा ब्लॅकलिस्टमध्ये असल्यास धोकादायक ध्वज/पर्याय) जोडला जातो तेव्हा ब्लॅकलिस्ट अपडेट करणे आवश्यक असेल. याव्यतिरिक्त, पॅरामीटरचे सार न बदलता त्याचे प्रतिनिधित्व बदलणे आणि त्याद्वारे ब्लॅकलिस्टच्या निर्बंधांना बायपास करणे शक्य आहे.

गो ऍप्लिकेशन्ससाठी, मी एक विशेष टूल विकसित केले आहे जे ऍप्लिकेशन सोबत असते आणि अंमलबजावणी दरम्यान केलेले सर्व कॉल गोळा करते. उदाहरणार्थ, खालील अनुप्रयोगासाठी:

package main

import "fmt"

func main() {
	fmt.Println("test")
}

... चला लॉन्च करूया gosystract त्यामुळे:

go install https://github.com/pjbgf/gosystract
gosystract --template='{{- range . }}{{printf ""%s",n" .Name}}{{- end}}' application-path

... आणि आम्हाला खालील परिणाम मिळतात:

"sched_yield",
"futex",
"write",
"mmap",
"exit_group",
"madvise",
"rt_sigprocmask",
"getpid",
"gettid",
"tgkill",
"rt_sigaction",
"read",
"getpgrp",
"arch_prctl",

आत्तासाठी, हे फक्त एक उदाहरण आहे—साधनांबद्दल अधिक तपशीलांचे अनुसरण केले जाईल.

टीप # 6: तुम्हाला खरोखर आवश्यक असलेल्या कॉललाच अनुमती द्या आणि इतर सर्व ब्लॉक करा.

7. योग्य पाया घाला (किंवा अनपेक्षित वर्तनासाठी तयारी करा)

कर्नल तुम्ही त्यात काय लिहीता याची पर्वा न करता प्रोफाइलची अंमलबजावणी करेल. अगदी तुम्हाला हवं होतं ते नसलं तरीही. उदाहरणार्थ, जर तुम्ही कॉलमध्ये प्रवेश अवरोधित केला तर exit किंवा exit_group, कंटेनर योग्यरितीने बंद करू शकणार नाही आणि अगदी साधी कमांड सारखी echo hi त्याला फाशी द्याo अनिश्चित काळासाठी. परिणामी, तुम्हाला क्लस्टरमध्ये उच्च CPU वापर मिळेल:

कुबर्नेट्समधील सेककॉम्प: 7 गोष्टी ज्या तुम्हाला अगदी सुरुवातीपासूनच माहित असणे आवश्यक आहे

अशा परिस्थितीत, एक उपयुक्तता बचावासाठी येऊ शकते strace - हे दर्शवेल की समस्या काय असू शकते:

कुबर्नेट्समधील सेककॉम्प: 7 गोष्टी ज्या तुम्हाला अगदी सुरुवातीपासूनच माहित असणे आवश्यक आहे
sudo strace -c -p 9331

रनटाइममध्ये अनुप्रयोगास आवश्यक असलेले सर्व सिस्टम कॉल्स प्रोफाइलमध्ये आहेत याची खात्री करा.

टीप # 7: तपशिलांकडे लक्ष द्या आणि सर्व आवश्यक सिस्टम कॉल श्वेतसूचीबद्ध असल्याची खात्री करा.

हे SecDevOps च्या भावनेने Kubernetes मध्ये seccomp वापरण्यावरील लेखांच्या मालिकेतील पहिल्या भागाची समाप्ती करते. हे महत्त्वाचे का आहे आणि प्रक्रिया स्वयंचलित कशी करावी याबद्दल आपण पुढील भागांमध्ये चर्चा करू.

अनुवादकाकडून पुनश्च

आमच्या ब्लॉगवर देखील वाचा:

स्त्रोत: www.habr.com