ConfigMap বনাম Secret — কোনটায় কী রাখবেন

নতুন কেউ Kubernetes শিখতে গিয়ে প্রথমেই যে ভুল ধারণাটা করে বসে: "Secret মানে এনক্রিপ্টেড, ConfigMap মানে সাধারণ টেক্সট।" নামটাই তো "Secret" — তাই মনে হয় এটা নিরাপদ একটা ভল্টের মতো কিছু।

আসল ঘটনাটা একটু অন্যরকম, আর এটা না জানলে প্রোডাকশনে DB পাসওয়ার্ড, API key — সবকিছু কার্যত সবার সামনে খোলা রাখার মতো ভুল করে ফেলা সহজ।

দুটোই আসলে key-value স্টোরেজ

ConfigMap আর Secret — দুটো অবজেক্টেরই কাজ একই: কিছু key-value ডেটা কন্টেইনারে পাঠানো, environment variable হিসেবে অথবা ফাইল হিসেবে মাউন্ট করে। কোড থেকে কনফিগারেশনকে আলাদা রাখাই এদের উদ্দেশ্য — যাতে একই Docker image dev, staging, প্রোডাকশনে আলাদা আলাদা ভ্যালু নিয়ে চলতে পারে।

পার্থক্যটা তৈরি হওয়ার কথা ছিল কী ধরনের ডেটা এখানে যাবে তার ভিত্তিতে — কনফিডেনশিয়াল বনাম নন-কনফিডেনশিয়াল। Kubernetes নিজে থেকে এই সীমারেখা জোর করে না, এটা সম্পূর্ণ আপনার সিদ্ধান্ত।

তাহলে Secret কী সুরক্ষা দেয়?

কিছু দেয়, কিন্তু যতটা মানুষ ভাবে তার চেয়ে কম:

• kubectl get configmap বা kubectl describe configmap চালালে ভ্যালু সরাসরি স্ক্রিনে দেখা যায়। Secret-এর ক্ষেত্রে kubectl describe secret ভ্যালু লুকিয়ে রাখে (<redacted>), যদিও kubectl get secret -o yaml দিয়ে ঠিকই বের করা যায় base64 decode করে।
• Secret অবজেক্টগুলো etcd-তে (Kubernetes-এর ডেটাবেসে) সাধারণত plaintext আকারেই সংরক্ষিত হয়, যদি না ক্লাস্টারে আলাদাভাবে encryption at rest চালু করা থাকে।
• RBAC (Role-Based Access Control) দিয়ে secrets রিসোর্সের জন্য আলাদা পারমিশন সেট করা যায় — অর্থাৎ, "কে Secret পড়তে পারবে" এটা ConfigMap থেকে আলাদা করে নিয়ন্ত্রণ করা সম্ভব। এটাই আসল ব্যবহারিক সুবিধা।

apiVersion: v1
kind: ConfigMap
metadata:
  name: db-config
data:
  DB_HOST: 'db.internal'
  DB_PASSWORD: 'p@ssw0rd123'

apiVersion: v1
kind: Secret
metadata:
  name: db-config
type: Opaque
stringData:
  DB_HOST: 'db.internal'
  DB_PASSWORD: 'p@ssw0rd123'

উপরের দুটো YAML প্রায় একই রকম দেখতে, আর kubectl apply করলে দুটোই একইভাবে কাজ করবে অ্যাপের দৃষ্টিকোণ থেকে। পার্থক্যটা তৈরি হয় ক্লাস্টার-লেভেল কনফিগারেশনে — RBAC পলিসি, encryption at rest, আর অডিট লগিং কোন রিসোর্স টাইপের জন্য কতটা কড়া, তার ওপর।

কবে কোনটা বাছবেন

সহজ নিয়ম: যা প্রকাশ পেলে ক্ষতি হবে, সেটা Secret-এ। যা প্রকাশ পেলে কিছু হবে না, সেটা ConfigMap-এ।

DB পাসওয়ার্ড, API key, TLS সার্টিফিকেটের প্রাইভেট কী, third-party টোকেন — Secret। ফিচার ফ্ল্যাগ, লগ লেভেল, API-র বেস URL, রিট্রাই কাউন্ট — ConfigMap। কোনো একটা ভ্যালু নিয়ে দ্বিধায় থাকলে, ধরে নিন সেটা Secret — পরে ConfigMap-এ সরানো সহজ, উল্টোটা করতে গেলে অনেক আগেই এক্সপোজ হয়ে গিয়ে থাকবে।

চেকলিস্ট — নতুন করে সেটআপ করার আগে

Secret ব্যবহার করা মানে "সমস্যা সমাধান হয়ে গেছে" না — এটা শুধু সঠিক জায়গায় সঠিক প্রশ্নটা জিজ্ঞেস করার সুযোগ তৈরি করে দেয়: এই ডেটাটা কে দেখতে পারবে, আর কীভাবে সেটা নিশ্চিত করছি।