একটা সার্ভারের চাবি কোথায় রাখবে — তিনটে খারাপ উত্তর আর একটা সঠিক উত্তর। Role কী, তার দুটো নথি কোনটা কী বলে, instance profile দিয়ে সার্ভার কীভাবে পরিচয় পায়, SDK কেন নিজে নিজেই খুঁজে নেয়, hardcoded চাবির আসল পরিণতি, আর assume-role-এর আউটপুট ঘর ধরে ধরে।
একটা খুব সাধারণ কাজ ভাবো। তোমার একটা EC2 সার্ভারে একটা স্ক্রিপ্ট চলে, যেটা প্রতি রাতে একটা ব্যাকআপ ফাইল S3-তে পাঠায়। মোট তিন লাইনের Boto3 কোড।
প্রশ্ন: ওই সার্ভারটা AWS-কে প্রমাণ করবে কীভাবে যে সে এই কাজটা করতে পারে?
পর্ব ৯-এর জ্ঞান দিয়ে স্বাভাবিক উত্তরটা হলো: একটা IAM ব্যবহারকারী বানাও, তাকে S3-তে লেখার অনুমতি দাও, একটা access key বানাও, আর সার্ভারে aws configure চালিয়ে বসিয়ে দাও।
এটা কাজ করে। আর এটাই সবচেয়ে বেশি করা হয়, আর এটাই ভুল। কেন — তিনটে স্তরে:
স্তর ১ — চাবিটা ফাইলে থাকে।
~/.aws/credentials একটা সাধারণ টেক্সট ফাইল। সার্ভারে যে কেউ ঢুকতে পারে, সে ওটা পড়তে পারে। আর শুধু মানুষ নয় — ওই সার্ভারে চলা যেকোনো প্রোগ্রাম ওটা পড়তে পারে, তোমার অ্যাপ্লিকেশন সহ। অ্যাপে একটা দুর্বলতা মানে চাবিটা ফাঁস।
স্তর ২ — চাবিটা ছড়িয়ে পড়ে, আর তুমি জানো না।
এটা সূক্ষ্ম আর গুরুতর। ওই সার্ভারের একটা AMI নিলে — পর্ব ৮-এর "My AMIs" — চাবিটা ওই image-এর ভেতরে চলে যায়। তারপর ওই image থেকে দশটা সার্ভার বানালে, দশটাতেই একই চাবি। একটা snapshot নিলে, ওখানেও। একটা backup নিলে, ওখানেও।
অর্থাৎ চাবিটা কতগুলো জায়গায় আছে, তার হিসাব তুমি হারিয়ে ফেলেছ — আর নিরাপত্তায় হিসাব হারানোটাই পরাজয়।
স্তর ৩ — চাবিটার মেয়াদ শেষ হয় না।
এটাই সবচেয়ে বড় সমস্যা। একটা access key কখনো মেয়াদোত্তীর্ণ হয় না। আজকের চাবি তিন বছর পরেও কাজ করবে। তাই নিরাপত্তার জন্য ওটা নিয়মিত বদলাতে হয় — আর ওই কাজটা কারো মনে রাখার উপর নির্ভরশীল, প্রতিটা সার্ভারে।
আর সবচেয়ে খারাপ অংশটা: চাবিটা ফাঁস হলে সারানোর উপায়টাও যন্ত্রণাদায়ক। চাবিটা মুছে দিলে ওই চাবি ব্যবহার করা সব কিছু সাথে সাথে বন্ধ হয়ে যায় — দশটা সার্ভার, তিনটে স্ক্রিপ্ট, pipeline। তাই বাস্তবে মানুষ দ্বিধা করে। আর ওই দ্বিধাটাই আসল ক্ষতি।
অন্য দুটো "সমাধান" যা মানুষ চেষ্টা করে, আর দুটোই আরো খারাপ:
তাহলে সঠিক উত্তরটা কী? সার্ভারে কোনো চাবি রাখবে না। একটাও না।
প্রথম শোনায় এটা অসম্ভব মনে হয় — চাবি ছাড়া সে নিজের পরিচয় দেবে কীভাবে? উত্তরটা একটা সুন্দর ব্যবস্থা, আর তার নাম role। এই পুরো পর্বটা ওটা নিয়ে।
একটা role দেখতে অনেকটা ব্যবহারকারীর মতো — তারও policy থাকে, তারও একটা ARN থাকে। কিন্তু তিনটে জায়গায় সে সম্পূর্ণ আলাদা, আর তিনটেই গুরুত্বপূর্ণ:
তুলনাটা এভাবে ভাবো: একটা user হলো তোমার নিজের পরিচয়পত্র — তোমার নাম লেখা, স্থায়ী, আর শুধু তোমার। একটা role হলো অফিসের দরজার পাশে ঝোলানো একটা অতিথি-ব্যাজ — ওটায় কারো নাম নেই, যার দরকার সে পরে নেয়, আর দিন শেষে ওটা কাজ করা বন্ধ করে দেয়।
আর তিন নম্বর সারিটা — মেয়াদ — এটাই পুরো যুক্তিটা। এক বাক্যে:
একটা role ব্যবহার করলে কাজ শেষে কিছু বাতিল করার দরকার নেই, কারণ credentials নিজে থেকেই কাজ করা বন্ধ করে দেয়।
এর ফলে যা হয়, সেটা আগের সেকশনের তিনটে স্তরের সরাসরি উত্তর:
স্তর ১-এর উত্তর: ফাইলে কিছু নেই, তাই পড়ার কিছু নেই।
স্তর ২-এর উত্তর: AMI, snapshot বা backup-এ কোনো গোপন তথ্য যায় না — কারণ ডিস্কে কোনো গোপন তথ্য লেখাই হয় না। এই এক কারণেই role ব্যবহার করা উচিত, এমনকি বাকি সুবিধাগুলো বাদ দিলেও।
স্তর ৩-এর উত্তর: চাবিটা এক ঘণ্টায় মেয়াদোত্তীর্ণ হয়, আর নতুনটা আপনাআপনি আসে। কারো কিছু মনে রাখার দরকার নেই।
আর একটা অতিরিক্ত সুবিধা, যেটা পর্ব ১৮-এ কাজে লাগবে: role ব্যবহার করলে CloudTrail-এর হিসাবে কাজটার পাশে লেখা থাকে assumed-role/ec2-s3-reader/i-07a1b... — অর্থাৎ কোন ভূমিকায়, আর কোন instance থেকে। একটা ভাগ করা access key-এর চেয়ে এটা অনেক বেশি তথ্য।
১৩৭টি অংশের ২৮টি দেখানো হয়েছে, ১০৯টি বাকি