কন্টেইনার বনাম microVM আইসোলেশন: সাবপ্রসেস থেকে পূর্ণ VM পর্যন্ত ৪টি স্তরের তুলনা

“এটা স্যান্ডবক্সে চালাও” শুনতে একটি নির্দেশের মতো। বাস্তবে মানুষ এর মাধ্যমে চারটি সাধারণ সীমানার কোনো একটি বোঝায়, আর সেগুলো খুব আলাদা জিনিস আটকায়। ভুলটা বেছে নিলে হয় আপনি অরক্ষিত থাকবেন, নয়তো প্রতিটি রান প্রয়োজনের চেয়ে ধীর আর দামি হবে।

এই তুলনা ধরে নেয় যে কোডটি সত্যিই অবিশ্বস্ত: কোনো ভাষা মডেলের লেখা, কোনো ব্যবহারকারীর জমা দেওয়া, বা অপরিচিত কারও pull request-এ আসা। আপনার নিজের লেখা কোডের প্রয়োজন আলাদা।

কী ভুল হতে পারে

সীমানাগুলো তুলনা করার আগে এগুলো কীসের জন্য, তা বলে নেওয়া সহায়ক। অবিশ্বস্ত কোড যা করতে পারে:

1. যা পড়া উচিত নয় তা পড়া: environment variable, SSH key, আপনার হোম ডিরেক্টরির ফাইল, ক্লাউডের metadata endpoint।
2. রিসোর্স নিঃশেষ করা: অনন্ত লুপ, মেশিন আটকে না যাওয়া পর্যন্ত fork, ডিস্ক ভরে ফেলা।
3. নেটওয়ার্কের অপব্যবহার: অন্য হোস্ট স্ক্যান করা, স্প্যাম পাঠানো, ক্রিপ্টোকারেন্সি মাইন করা, আপনার অভ্যন্তরীণ সার্ভিসে কল করা।
4. টিকে থাকা: এমন cron job বা সার্ভিস বসানো যা কাজ শেষ হওয়ার পরেও থেকে যায়।
5. পালানো: নিচের স্তরের কোনো বাগ ব্যবহার করে খোদ হোস্টে কোড চালানো।

নিচের প্রতিটি স্তর এর কিছু সামলায়, কিছু সামলায় না।

স্তর ১: প্রসেস

সবচেয়ে সরল স্যান্ডবক্স হলো একটি চাইল্ড প্রসেস: timeout-সহ subprocess.run, হয়তো আলাদা ব্যবহারকারীর অধীনে, আর আপনি খুঁতখুঁতে হলে রিসোর্স সীমা ও seccomp ফিল্টারসহ।

আটকায়: লাগামছাড়া সময় (timeout), কিছুটা রিসোর্স নিঃশেষ হওয়া (সীমা), কিছু বিপজ্জনক system call (seccomp)। আটকায় না: সেই ব্যবহারকারী যা পড়তে পারে তার সবকিছু পড়া, নেটওয়ার্ক অ্যাক্সেস, ব্যবহারকারী যেখানে লিখতে পারে সেখান দিয়ে টিকে থাকা, এবং যেকোনো কার্নেল বাগ। সাধারণ ব্যর্থতা: কোড এমন একটি ফাইল পড়ে ফেলে যেটা যে পড়া যায় তা আপনি ভুলে গিয়েছিলেন, অথবা কোনো “সীমিত” ভাষা ইন্টারপ্রেটারে একটি গোপন দরজা বেরিয়ে পড়ে। ইতিহাস এমন ভাষা-অভ্যন্তরীণ স্যান্ডবক্সে ভরা যা টেকেনি।

চালু হওয়ার সময় কার্যত শূন্য। আপনার লেখা কোডের জন্য ঠিক আছে; যে কোড আপনি লেখেননি, তার জন্য এটি কোনো সীমানা নয়।

স্তর ২: কনটেইনার

namespaces কোডকে ফাইল, প্রসেস আর নেটওয়ার্কের নিজস্ব দৃশ্য দেয়; cgroups CPU আর মেমরি সীমিত করে; বাদ দেওয়া capabilities আর seccomp সংকুচিত করে কার্নেলের কাছে সে কী চাইতে পারে।

আটকায়: হোস্টের ফাইল পড়া (মাউন্ট না করা থাকলে), অন্য প্রসেস দেখা, সীমাহীন রিসোর্স ব্যবহার, আর কনটেইনার পরে ফেলে দিলে টিকে থাকার সমস্যার বেশির ভাগ। আটকায় না: ভাগ করা হোস্ট কার্নেলের বাগ। মেশিনের প্রতিটি কনটেইনার একই কার্নেলের সঙ্গে কথা বলে, তাই নাগালের মধ্যে থাকা কার্নেল দুর্বলতাই বেরোনোর পথ। সাধারণ ব্যর্থতা: অদ্ভুত exploit নয়, কনফিগারেশন। privileged কনটেইনার, ভেতরে মাউন্ট করা container runtime-এর socket, “শুধু ডিবাগিংয়ের জন্য” চালু করা হোস্ট নেটওয়ার্কিং। প্রতিটিই চুপচাপ সীমানা সরিয়ে দেয়।

চালু হওয়ার সময় মিলিসেকেন্ড। শক্তিশালী করা সংস্করণও আছে, যার মধ্যে user-space কার্নেল রয়েছে যা system call হোস্টে পৌঁছানোর আগেই আটকে দেয়, গতি ও সামঞ্জস্যের কিছু মূল্যে। যাদের আপনি বিশ্বাস করেন তাদের কোডের জন্য ভালোভাবে কনফিগার করা কনটেইনার একটি যুক্তিসংগত ডিফল্ট।

স্তর ৩: microVM

microVM পূর্ণ VM-এর মতো হাইপারভাইজারের অধীনে নিজের কার্নেল চালায়, কিন্তু এমুলেট করা হার্ডওয়্যারের প্রায় সবই বাদ দেওয়া। Firecracker সবচেয়ে পরিচিত উদাহরণ।

আটকায়: কনটেইনার যা আটকায় তার সবই, সঙ্গে ভাগ করা কার্নেলের সমস্যাও। হোস্টে পৌঁছাতে কোডকে হাইপারভাইজার বা হাতে গোনা কয়েকটি ভার্চুয়াল ডিভাইসের কোনো একটি ভাঙতে হবে, যা কার্নেলের system-call ইন্টারফেসের চেয়ে অনেক ছোট পৃষ্ঠতল। আটকায় না: আপনি যা দেন তার অপব্যবহার। খোলা egress এখনো অপব্যবহার হতে পারে; আপনি যে গোপন তথ্য ঢোকান তা এখনো ফাঁস হতে পারে। সাধারণ ব্যর্থতা: আইসোলেশন নয়, নীতি। কেউ “টেস্ট চালানোর জন্য” প্রোডাকশন টোকেন দিয়ে দেয়, বা এমন ওয়ার্কলোডে আউটবাউন্ড ট্র্যাফিক অবাধ রেখে দেয় যার সেটা দরকারই নেই।

চালু হওয়ার সময় সেকেন্ডের ভগ্নাংশ থেকে প্রায় এক সেকেন্ড, কয়েক মেগাবাইট ওভারহেডসহ। প্রতিটি কাজের জন্য একটি বানিয়ে পরে মুছে ফেলার মতো দ্রুত, যা টিকে থাকার সমস্যাও সমাধান করে: ফিরে আসার মতো কিছুই অবশিষ্ট থাকে না।

স্তর ৪: পূর্ণ ভার্চুয়াল মেশিন

একটি সাধারণ VM, বা VPS, microVM-এর মতো একই ধরনের সীমানা রাখে: হার্ডওয়্যার ভার্চুয়ালাইজেশন আর হাইপারভাইজার। পার্থক্য এর চারপাশের সবকিছুতে: পূর্ণ ডিভাইস মডেল, পুরো OS, চাইলে পাবলিক IP, আর দিন বা মাসে মাপা জীবনচক্র।

আটকায়: microVM-এর মতো একই শ্রেণির সমস্যা, তবে বেশি হার্ডওয়্যার এমুলেট হওয়ায় আক্রমণের পৃষ্ঠতল কিছুটা বড়। আটকায় না: নিজের নেটওয়ার্ক পরিচয়ের অপব্যবহার। পাবলিক IP-সহ যে VM অপব্যবহারমূলক কোড চালায়, সে নিজের IP ব্লকলিস্টে তোলায়, যা গুরুত্বপূর্ণ যদি সেই IP আপনার ইমেলও পাঠায়। (যদি এটা ইতিমধ্যে ঘটে থাকে, দেখুন আপনার IP ব্লকলিস্টে থাকলে কী করবেন।) সাধারণ ব্যর্থতা: এটি বেশি দিন বাঁচে। একটি পরীক্ষার জন্য বানানো VM ক্রেডেনশিয়াল আর অবস্থা জমাতে থাকে, আর ধীরে ধীরে সেই বিশ্বস্ত মেশিনে পরিণত হয় যাকে রক্ষা করার কথা ছিল।

চালু হওয়ার সময় কয়েক দশ সেকেন্ড থেকে কয়েক মিনিট, আর বিলিং সাধারণত মাসিক। ইনবাউন্ড পোর্ট লাগে এমন দীর্ঘস্থায়ী সার্ভিসের জন্য এটি সঠিক আকার, আর ২০ সেকেন্ডের কোড রানের জন্য ভুল আকার।

তুলনা

বেছে নেওয়া

• আপনার বা আপনার দলের লেখা কোড: প্রসেস বা কনটেইনারই যথেষ্ট।
• আপনার নিজের branch-এর CI: আপনার runner-এ কনটেইনার।
• এজেন্টের তৈরি কোড, ব্যবহারকারীর জমা, বাইরের pull request: প্রতি কাজে একটি microVM, পরে মুছে ফেলা।
• এমন অবিশ্বস্ত সার্ভিস যাকে সংযোগ নিতে হবে বা সপ্তাহের পর সপ্তাহ চলতে হবে: নিজস্ব IP-সহ আলাদা VM, যা আপনার ক্রেডেনশিয়াল রাখে বা ইমেল পাঠায় এমন সবকিছু থেকে দূরে।

যা-ই বাছুন, ওপরে দুটি নিয়ম প্রযোজ্য: কোডের লেখকের হাতে যা দিতেন না তা ভেতরে রাখবেন না, আর ভেবেচিন্তে ঠিক করুন নেটওয়ার্ক কী করতে পারবে।

আমাদের পণ্য কোথায়

স্তর ৩-এর জন্য আমরা কোড স্যান্ডবক্স চালাই: প্রায় এক সেকেন্ডে চালু হওয়া Firecracker microVM, আউটবাউন্ড ইন্টারনেটসহ, ইনবাউন্ড পোর্ট ছাড়া এবং প্রতি-সেকেন্ড বিলিংয়ে। এগুলো ঠিক ওপরের তৃতীয় বিন্দুর জন্য; MCP সুরক্ষা ব্যবস্থা পেজে বলা আছে একটি এজেন্ট এগুলো দিয়ে কী করতে পারবে তা কীভাবে সীমিত করবেন। স্তর ৪-এর জন্য AI agent প্ল্যান-এর মতো একটি VPS মাস হিসেবে আপনাকে পুরো একটি মেশিন দেয়। AI এজেন্টের জন্য স্যান্ডবক্স-এর উদাহরণগুলো microVM প্যাটার্ন শুরু থেকে শেষ পর্যন্ত দেখায়, আর AI এজেন্টদের অবকাঠামো থেকে কী দরকার আইসোলেশনকে কয়েকটি চাহিদার একটি হিসেবে দেখে।