Applied Kubernetes Hardening: A Practical Playbook

Kubernetes এর ডিফল্ট অবস্থান হল নমনীয়তা, নিরাপত্তা নয়। প্রতিটি খোলা পোর্ট, অনুমতিপ্রাপ্ত RBAC ভূমিকা এবং সীমাহীন pod একটি আমন্ত্রণ। একটি ক্লাস্টার হার্ডেন করা মানে সেই ফাঁক গুলি পদ্ধতিগতভাবে বন্ধ করা এবং সেগুলির উপর নির্ভরশীল workloads ভাঙা নয়। এটি একটি চেকলিস্ট ব্যায়াম নয়—এটি একটি চলমান শৃঙ্খলা যা identity, network, workload এবং supply chain স্তরগুলি স্পর্শ করে।

প্রথমে Control Plane লক ডাউন করুন

API server যেকোনো ক্লাস্টারে একক সবচেয়ে মূল্যবান লক্ষ্য। anonymous authentication অক্ষম করে এবং শক্তিশালী authentication পদ্ধতি কার্যকর করে শুরু করুন—আপনার identity provider এর সাথে OIDC integration স্ট্যাটিক টোকেন বা কখনো মেয়াদ শেষ না হওয়া client certificates এর চেয়ে পছন্দনীয়। etcd datastore এ অ্যাক্সেস সীমিত করুন, কারণ এটি প্রতিটি secret এবং config object plaintext এ রাখে যদি rest এ encryption সক্ষম না হয়। KMS provider ব্যবহার করে secrets এর জন্য encryption সক্ষম করুন base64 encoding এর উপর নির্ভর করার পরিবর্তে, যা শূন্য প্রকৃত সুরক্ষা প্রদান করে। দিন এক থেকে audit logging চালু করা উচিত; এটি ছাড়া, যখন কিছু ভুল হয় তখন আপনার কোনো forensic trail নেই।

RBAC: সুবিধার জন্য নয়, সর্বনিম্ন বিশেষাধিকার

Production ক্লাস্টারে সবচেয়ে সাধারণ misconfiguration হল অত্যন্ত বিস্তৃত RBAC bindings—service accounts এ cluster-admin অনুদান যা শুধুমাত্র এক namespace এ pods পড়ার প্রয়োজন। আসল job functions এর চারপাশে roles তৈরি করুন এবং যেখানে সম্ভব সেগুলি namespaces এ scope করুন। Role এবং ClusterRole definitions এ wildcard verbs এবং resources এড়িয়ে চলুন। kubectl auth can-i --list বা rbac-lookup এর মতো tools দিয়ে নিয়মিত bindings audit করুন privilege creep ধরতে। Service accounts মানব ব্যবহারকারীদের মতো একই scrutiny প্রাপ্য—pods এর জন্য service account tokens automounting অক্ষম করুন যা API access প্রয়োজন না।

Pod Security: Compromise মনে করুন

Pod Security Admission (যা deprecated PodSecurityPolicy প্রতিস্থাপন করেছে) আপনাকে namespace স্তরে baseline বা restricted profiles কার্যকর করতে দেয়। ন্যূনতম, privileged containers, host namespace sharing এবং privilege escalation অনুমতি না দিন। runAsNonRoot: true সেট করুন এবং সব Linux capabilities ডিফল্টভাবে ড্রপ করুন, শুধুমাত্র স্পষ্টভাবে প্রয়োজন যা যুক্ত করে। Read-only root filesystems আক্রমণকারীদের একটি running container এ malicious binaries লেখা থেকে রোধ করে। এই controls গুরুত্বপূর্ণ কারণ একটি container escape বা exploited application vulnerability সম্পূর্ণ node compromise এ অনুবাদ করা উচিত নয়।

Network Policies ঐচ্ছিক নয়

ডিফল্টরূপে, Kubernetes ক্লাস্টারে প্রতিটি pod প্রতিটি অন্যান্য pod এর সাথে কথা বলতে পারে। সেই flat network model আক্রমণকারীদের জন্য একটি lateral movement স্বর্গ। NetworkPolicy resources কার্যকর করুন default-deny ingress এবং egress কার্যকর করতে, তারপর স্পষ্টভাবে শুধুমাত্র traffic flows অনুমতি দিন যা আপনার applications প্রয়োজন। এটি একটি CNI plugin প্রয়োজন যা actually NetworkPolicy enforcement সমর্থন করে—Calico, Cilium এবং others এই ভূমিকা পূরণ করে কারণ base Kubernetes network model এর নিজের উপর কিছুই কার্যকর করে না। trust boundary দ্বারা namespaces segmenting এবং শীর্ষে layering policies আপনাকে প্রকৃত defense in depth প্রদান করে।

Image এবং Supply Chain Integrity

Hardening runtime configuration এ থামে না—এটি যা আপনি deploy করে তা দিয়ে শুরু হয়। যে container images আপনার registry এ পৌঁছায় তার আগে known vulnerabilities এর জন্য scan করুন এবং কার্যকর করুন যে শুধুমাত্র signed, verified images Kyverno বা OPA Gatekeeper এর মতো admission controllers ব্যবহার করে আপনার ক্লাস্টারে চলতে পারে। image tags মutable tags এর পরিবর্তে digests এ pin করুন যেমন latest, যা আপনার অধীনে নিরলসভাবে পরিবর্তন করতে পারে। যে registries pods থেকে pull করার অনুমতি আছে তা সীমিত করুন, একটি সাধারণ path বন্ধ করুন supply chain attacks এর জন্য যেখানে compromised বা typosquatted images production এ স্লিপ করে।

Secrets Management Kubernetes Defaults এর বাইরে

Native Kubernetes Secrets কিছু না হওয়ার চেয়ে ভাল, কিন্তু তারা একটি true secrets management solution নয়। একটি external secrets manager integrate করা বিবেচনা করুন—Vault, AWS Secrets Manager বা similar—এবং runtime এ secrets inject করুন cluster objects হিসাবে সংরক্ষণের পরিবর্তে। আপনি যদি native Secrets ব্যবহার করতে হবে, etcd encryption সক্ষম এবং RBAC tightly read access সীমাবদ্ধ নিশ্চিত করুন, কারণ একটি namespace এ secrets এর জন্য get permission আছে এমন কোনো pod বা user credentials exfiltrate করতে পারে।

Continuous Verification, এক-সময়ের সেটআপ নয়

Hardening configurations সময়ের সাথে drift করে নতুন workloads deploy হওয়ার সাথে সাথে এবং priorities গতি দিকে shift করে security এর উপর। kube-bench এর মতো tools CIS Kubernetes Benchmark এর বিরুদ্ধে compliance পরীক্ষা করে, যখন kube-hunter আপনার ক্লাস্টারের বিরুদ্ধে attacker reconnaissance simulate করতে পারে। এই checks CI/CD pipelines এ bake করুন যাতে misconfigurations ধরা পড়ে production এ পৌঁছানোর আগে একটি incident response call এর সময় নয়।

Kubernetes hardening একটি একক silver-bullet control এর চেয়ে কম এবং identity, network, workload এবং supply chain এর উপর layering defenses এর বেশি—যাতে এক স্তরে একটি failure সম্পূর্ণ compromise এ cascade না হয়। cloud infrastructure security patterns এবং defensive tooling এ আরও জানতে, Korra Studio এর DEFENSE_GRID platform এ সম্পর্কিত segments অন্বেষণ করুন।