স্বল্পমেয়াদি SPIFFE/SPIRE SVIDs কেন নোডের অখণ্ডতার ওপর নির্ভরশীল, পরীক্ষাগারে cgroup তথ্য জাল করার পরীক্ষায় কী দেখা গেছে এবং কোন Kubernetes নিয়ন্ত্রণগুলো প্রভাব সীমিত করতে পারে, তার ব্যাখ্যা।
SPIFFE পরিষেবাগুলোকে SVIDs নামে স্বল্পমেয়াদি ক্রিপ্টোগ্রাফিক পরিচয়পত্র দেয়। ওয়ার্কলোডগুলো এগুলো ব্যবহার করে TLS সংযোগ স্থাপন করতে পারে অথবা JWTs-এ স্বাক্ষর করতে ও সেগুলো যাচাই করতে পারে। SPIFFE-এর আনুষ্ঠানিক পরিচিতিতে এই মডেলটির সংজ্ঞা দেওয়া হয়েছে।
পরিচয় নির্ধারণের সিদ্ধান্ত কোথায় নেওয়া হয়
SVIDs ইস্যু করার আগে SPIRE নোড ও ওয়ার্কলোডের অ্যাটেস্টেশন সম্পন্ন করে। ওয়ার্কলোডের অ্যাটেস্টেশনের সময় SPIRE এজেন্ট অপারেটিং সিস্টেমের কার্নেল বা একই নোডের kubelet-এর মতো স্থানীয় উৎস থেকে একটি প্রসেসের বৈশিষ্ট্য নির্ধারণ করে। এরপর এটি নিবন্ধন এন্ট্রিতে থাকা সিলেক্টরের শর্তগুলোর সঙ্গে ওই বৈশিষ্ট্যগুলো মেলায়; শর্ত মিলে গেলে প্রসেসটি কোন SPIFFE ID পাবে, তা নির্ধারিত হয়। SPIRE-এর ধারণাবিষয়ক নথিতে এই প্রক্রিয়ার বর্ণনা রয়েছে।
পরীক্ষাগারে পাওয়া ফলাফলের পরিধি
এই মডেলে কোনো SVID ক্রিপ্টোগ্রাফিকভাবে বৈধ কি না এবং সেটি যে প্রসেসকে দেওয়ার কথা ছিল, তাকেই দেওয়া হয়েছে কি না—এই দুটি আলাদা প্রশ্ন। Unit 42-এর পরীক্ষাগারে পরিচালিত গবেষণায় দেখা গেছে, Kubernetes নোডে আগে থেকেই root অ্যাক্সেস থাকা কোনো আক্রমণকারী Linux cgroup তথ্য জাল করে SPIRE এজেন্টকে বিভ্রান্ত করতে এবং একই নোডের অন্য ওয়ার্কলোডের একটি বৈধ SVID পেতে পারে। Unit 42-এর গবেষণায় এর প্রযুক্তিগত ধাপগুলো নথিভুক্ত করা হয়েছে।
Unit 42 স্পষ্টভাবে জানিয়েছে যে বাস্তব আক্রমণে এই কৌশল ব্যবহৃত হতে তারা দেখেনি। তাই এই ফলাফল সক্রিয়ভাবে কৌশলটি কাজে লাগানোর প্রমাণ নয়; এটি এমন একটি অনুপ্রবেশ-পরবর্তী ঝুঁকির বর্ণনা দেয়, যা root অ্যাক্সেসের কারণে নোডের বিশ্বস্ততা নষ্ট হওয়ার পর তৈরি হয়।
নোডের ঝুঁকি মোকাবিলার প্রতিরক্ষা মডেল
প্রতিরক্ষার পরিকল্পনায় কোনো নোডের নিরাপত্তা ভেঙে গেলে, সেই নোডের আওতাভুক্ত প্রতিটি ওয়ার্কলোডের পরিচয়ের নিরাপত্তাও ভেঙে গেছে বলে ধরে নেওয়া উচিত। Unit 42-এর নির্দেশনায় প্রিভিলেজড কনটেইনার ও হোস্টে সরাসরি অ্যাক্সেস সীমিত করার পাশাপাশি দুর্বল বা সহজে জাল করা যায় এমন সিলেক্টরের ওপর নির্ভরতা কমানোর কথা বলা হয়েছে। এর পরিধি আক্রান্ত নোডটি পর্যন্ত; স্বয়ংক্রিয়ভাবে পুরো ক্লাস্টার নয়।
পড ও নোডের অধিকার সীমিত করুন
Kubernetes Pod Security Standards-এর Restricted প্রোফাইলে প্রিভিলেজড পড নিষিদ্ধ করা, অধিকার বাড়ানোর সুযোগ বন্ধ করা এবং কনটেইনারগুলোকে non-root ব্যবহারকারী হিসেবে চালানোর নির্দেশনা রয়েছে। আনুষ্ঠানিক নিরাপত্তা যাচাইতালিকায় আরও বলা হয়েছে, Linux কার্নেলের যেসব syscall কনটেইনারের ভেতর থেকে ব্যবহার করা যায়, seccomp সেগুলোর পরিসর কমাতে পারে। বিস্তারিত রয়েছে Pod Security Standards এবং Kubernetes নিরাপত্তা যাচাইতালিকায়।
সিলেক্টরকে আস্থার সীমানার অংশ হিসেবে বিবেচনা করুন
সিলেক্টরের কাজ শুধু শর্ত মেলানো নয়: অ্যাটেস্টেশনের সিদ্ধান্তে কোন স্থানীয় বৈশিষ্ট্যগুলো বিবেচনায় নেওয়া হবে, তা এগুলো নির্ধারণ করে। তাই পর্যালোচনায় দেখতে হবে, অপারেটিং সিস্টেম বা kubelet-এর কোন তথ্য প্রতিটি শর্তের ভিত্তি হিসেবে ব্যবহৃত হয় এবং root অ্যাক্সেস থাকলে সেই তথ্য সহজে জাল করা সম্ভব কি না। উদ্দেশ্য হলো ব্যাপক বা দুর্বল শর্তের বদলে এমন সিলেক্টরের ওপর নির্ভর করা, যা সুনির্দিষ্টভাবে ওয়ার্কলোডগুলোকে আলাদা করে শনাক্ত করে।
সংবেদনশীলতার স্তর ও অতিরিক্ত ক্রেডেনশিয়াল আলাদা রাখুন
Kubernetes ভিন্ন সংবেদনশীলতার স্তরের ওয়ার্কলোডগুলো আলাদা নোডে রাখা এবং যেসব পডের সার্ভিস অ্যাকাউন্ট টোকেনের প্রয়োজন নেই, সেগুলোতে এসব টোকেন মাউন্ট না করারও সুপারিশ করে। দুটি নিয়ন্ত্রণেরই বর্ণনা রয়েছে আনুষ্ঠানিক নিরাপত্তা যাচাইতালিকায়।
নোড আলাদা রাখার উদ্দেশ্য হলো কনটেইনারের সীমানা ভেঙে বেরিয়ে আসার পর আরও সংবেদনশীল অ্যাপ্লিকেশনে সরাসরি অনুপ্রবেশ করা আরও কঠিন করা। অপ্রয়োজনীয় সার্ভিস অ্যাকাউন্ট টোকেন মাউন্ট না করলে SVID থেকে আলাদা ওই অতিরিক্ত ক্রেডেনশিয়ালটিও পডের ভেতর থাকে না।
পর্যালোচনার একটি ব্যবহারিক ধাপক্রম
এই আস্থার সীমানা ধরে একটি সংক্ষিপ্ত পর্যালোচনার ধাপক্রম তৈরি করা যায়, যেখানে কনফিগারেশন ও ওয়ার্কলোড কোথায় রাখা হয়েছে, তা একসঙ্গে বিবেচনা করা হবে:
পরিচয়ের পরিধি: প্রতিটি নোডের আওতায় কোন SPIFFE IDs রয়েছে এবং কোন কোন সংবেদনশীলতার স্তরের ওয়ার্কলোড একই নোডে আছে?
অ্যাটেস্টেশনের ইনপুট: অপারেটিং সিস্টেম বা kubelet-এর কোন তথ্য সিলেক্টরগুলো ব্যবহার করে এবং root অ্যাক্সেস দিয়ে কি সেই তথ্য জাল করা সম্ভব?
নোডের অধিকার: কোন পডগুলো প্রিভিলেজড, হোস্টে অ্যাক্সেস করতে পারে, অধিকার বাড়ানোর সুযোগ দেয় বা root হিসেবে চলে?
অতিরিক্ত ক্রেডেনশিয়াল: কোন পডগুলো প্রয়োজন না থাকা সত্ত্বেও সার্ভিস অ্যাকাউন্ট টোকেন পায়?
এর অর্থ এই নয় যে SVIDs-এর কোনো মূল্য নেই। এগুলোর ক্রিপ্টোগ্রাফিক পরিচয়ের নিশ্চয়তা মূল্যায়নের সময় যে নোডে অ্যাটেস্টেশন হয়, তার অখণ্ডতাও একসঙ্গে বিবেচনা করতে হবে। একটি সহনশীল মডেলে স্বল্পমেয়াদি ওয়ার্কলোড পরিচয়ের সঙ্গে পডের নিরাপত্তা জোরদার করা, সুনির্দিষ্ট সিলেক্টর শর্ত, সংবেদনশীলতা অনুযায়ী নোড আলাদা রাখা এবং অপ্রয়োজনীয় ক্রেডেনশিয়াল অপসারণকে একত্র করা হয়।
