লঞ্চার পণ্য Bitnami ডকুমেন্টেশনimaxe CLI ব্লগ যোগাযোগ

সিক্রেট ব্যবস্থাপনা: ক্রেডেনশিয়াল কখনো AMI-তে বেক করবেন না

ইমেজের ভেতরে রাখা পাসওয়ার্ড মানে ঘটতে চলা এক ফাঁস: সেটি কপি হয়, ভাগ হয়, আর চিরকাল কোনো স্ন্যাপশটে থেকে যায়। নিয়মটি সরল এবং ব্যতিক্রমহীন: সিক্রেট কখনো ইমেজে যায় না। সঠিক উপায়টি এখানে।

ব্যাংকের ভল্টের বর্মাবৃত দরজা
ব্যাংকের ভল্টের বর্মাবৃত দরজা ছবি: Aldo Moisio · পাবলিক ডোমেইন · Wikimedia Commons

আপনি যখন কোনো ক্রেডেনশিয়াল AMI-তে গেঁথে দেন, সেটি ইমেজের প্রতিটি কপির সঙ্গে ছড়িয়ে পড়ে, স্ন্যাপশটে খোদাই হয়ে থাকে, আর এমন সব অ্যাকাউন্ট বা অঞ্চলে গিয়ে পৌঁছতে পারে যা আপনি কল্পনাও করেননি। ইমেজে পড়ার অনুমতি আছে এমন কারও পক্ষে সেটি বের করে নেওয়াই যথেষ্ট। আর যেহেতু ইমেজ সংস্করণ ধরে সংরক্ষিত হয়, সিক্রেটটি আপনার ঘোরানোর ধারণার অনেক পরেও বেঁচে থাকতে পারে।

সোনালি নিয়ম: ইমেজ মেশিনকে সংজ্ঞায়িত করে; সিক্রেট দেওয়া হয় রানটাইমে

সিক্রেট কোথায় থাকা উচিত

সেবাক্লাউড বা পরিবেশকীসের জন্য আদর্শ
AWS Secrets ManagerAWSঘোরানো যায় এমন ক্রেডেনশিয়াল, নেটিভ সংহতি
AWS SSM Parameter StoreAWSসরল প্যারামিটার ও সিক্রেট, কম খরচ
HashiCorp Vaultমাল্টিক্লাউডগতিশীল সিক্রেট ও সূক্ষ্ম নিয়ন্ত্রণ
Azure Key Vault / Google Secret ManagerAzure / GCPপ্রতিটি ক্লাউডের নেটিভ সমতুল্য

সিক্রেট রাখুন নিবেদিত ম্যানেজারে — কখনোই ইমেজে বা খোলা user-data-তে নয়।

সঠিক প্যাটার্ন: পাসওয়ার্ড নয়, পরিচয়

কোনো ইনস্ট্যান্সকে রিসোর্সে পৌঁছাতে দেওয়ার সবচেয়ে নিরাপদ উপায় তাকে পাসওয়ার্ড দেওয়া নয়, বরং একটি পরিচয় দেওয়া। AWS-এ ইনস্ট্যান্সের সঙ্গে যুক্ত IAM রোল তাকে অস্থায়ী ও স্বয়ংক্রিয়ভাবে ঘোরানো ক্রেডেনশিয়াল এনে দেয়, কোনো কী ইমেজে না নিয়েই।

  • ইনস্ট্যান্স IAM রোল: ইনস্ট্যান্স একটি রোল ধারণ করে অস্থায়ী ক্রেডেনশিয়াল পায়।
  • Kubernetes-এ IRSA: প্রতি পডে পরিচয়, নোডে কোনো শেয়ার করা কী ছাড়াই।
  • Vault-এর গতিশীল সিক্রেট: চাহিদামাফিক তৈরি স্বল্পায়ু ক্রেডেনশিয়াল।
  • রানটাইম ইনজেকশন: অ্যাপ্লিকেশন চালুর সময় ম্যানেজার থেকে সিক্রেট পড়ে, বেক করা ফাইল থেকে নয়।

মেটাডেটা রক্ষা করুন: IMDSv2

রোলের অস্থায়ী ক্রেডেনশিয়াল আসে ইনস্ট্যান্স মেটাডেটা সেবা থেকে। SSRF ত্রুটি কাজে লাগিয়ে আক্রমণকারী সেগুলো চুরির চেষ্টা করতে পারে। IMDSv2 সেশন টোকেন দাবি করে এবং এই শ্রেণির আক্রমণ কমায়: নিজের লঞ্চে একে বাধ্যতামূলক করুন।

পরিচ্ছন্নতা: ইমেজে চিহ্ন রাখবেন না

  • AMI সিল করার আগে শেল ইতিহাস, ক্রেডেনশিয়ালযুক্ত লগ, অস্থায়ী SSH কী ও সিক্রেটসহ কনফিগারেশন ফাইল মুছে ফেলুন
  • ফাইল সিস্টেমের উপযোগী gitleaks বা trufflehog-এর মতো সরঞ্জাম দিয়ে ইমেজে সিক্রেট খুঁজুন।
  • ~/.ssh/authorized_keys-এ বাড়তি অনুমোদিত কী রেখে দেবেন না।
  • সিক্রেটসহ পাবলিক AMI এড়ান: প্রকাশ করলে নিশ্চিত হন কিছুই ফাঁস হচ্ছে না।

দ্রুত চেকলিস্ট

  • ইমেজে শূন্য বেক করা সিক্রেট।
  • রোল বা ফেডারেটেড পরিচয়সহ সিক্রেট ম্যানেজার।
  • IMDSv2 বাধ্যতামূলক।
  • পাইপলাইনে সিক্রেট স্ক্যান।
  • সিল করার আগে চিহ্ন মুছে ফেলা।

প্রায়শই জিজ্ঞাসিত প্রশ্ন

আমার অ্যাপ্লিকেশনের যদি বুটেই সিক্রেট লাগে?

সেটি যেন ইনস্ট্যান্সের পরিচয় ব্যবহার করে রানটাইমে সিক্রেট ম্যানেজার থেকে পড়ে নেয়। তাতে সিক্রেট কখনো ইমেজের ভেতরে যায় না এবং পুনর্নির্মাণ ছাড়াই ঘোরানো যায়।

সিক্রেট পাঠাতে user-data ব্যবহার কি নিরাপদ?

খোলা টেক্সটে নয়: user-data মেটাডেটা থেকে পড়া যায়। বড়জোর এটি দিয়ে বলুন ম্যানেজার থেকে কোন সিক্রেট আনতে হবে, আর মেটাডেটা IMDSv2 দিয়ে সুরক্ষিত রাখুন।

কোনো ইমেজে আগেই বেক করা সিক্রেট আছে কি না বুঝব কীভাবে?

তার ফাইল সিস্টেমে সিক্রেট শনাক্তকরণ সরঞ্জাম দিয়ে স্ক্যান করে, এবং ব্যবহারের আগে কনফিগারেশন ফাইল, ইতিহাস ও অনুমোদিত কী পরীক্ষা করে।

imaxe.cloud-এ আমরা ক্রেডেনশিয়ালমুক্ত ইমেজ বানাই, যা সিক্রেট ম্যানেজার ও ফেডারেটেড পরিচয়ের সঙ্গে মিলে কাজ করার কথা ভেবেই তৈরি।

সিক্রেটvaultiamimdsv2secrets manager
IM

imaxe দল

আমরা ক্যাটালগের AMI তৈরি ও রক্ষণাবেক্ষণ করি। একটি সংস্করণ প্রকাশ করার সময়, আমরা সবার আগে প্রোডাকশনে এটি ব্যবহার করি।

ক্যাটালগ থেকে

এই নিবন্ধের সঙ্গে সম্পর্কিত AMI

পড়া চালিয়ে যান

সম্পর্কিত নিবন্ধ