Kubernetes Security: আপনার কুবারনেটিস ক্লাস্টারের ডেটা এবং কনটেইনারের নিরাপত্তা!

Kubernetes Security বুঝতে গেলে প্রথমেই 4C মডেলটি বোঝা দরকার - Cloud, Cluster, Container, এবং Code। এই চারটি স্তরে নিরাপত্তা গড়ে তুলতে হয়। সবচেয়ে বাইরের স্তর হলো Cloud, যেখানে Underlying Infrastructure যেমন AWS, GCP, বা Azure-এর নিরাপত্তা নিশ্চিত করতে হয়। দ্বিতীয় স্তর হলো Cluster, যেখানে API Server, etcd, এবং Worker Node-এর কনফিগারেশন নিরাপদ রাখতে হয়।

তৃতীয় স্তর হলো Container, যেখানে Image Scanning, Runtime Protection, এবং Privilege Management গুরুত্বপূর্ণ। আর সবচেয়ে ভেতরের স্তর হলো Code, যেখানে অ্যাপ্লিকেশন কোডের নিরাপত্তা, Dependency Management, এবং Secret Handling অপরিহার্য। প্রতিটি স্তরের নিরাপত্তা স্বাধীন কিন্তু পরস্পর সংযুক্ত - একটি স্তরের দুর্বলতা পুরো সিস্টেমকে ঝুঁকির মধ্যে ফেলতে পারে।

Control Plane হলো Kubernetes ক্লাস্টারের মস্তিষ্ক, যা কে কী করতে পারবে তার সমস্ত সিদ্ধান্ত নেয়। kube-apiserver, etcd, kube-scheduler, এবং kube-controller-manager - এই চারটি প্রধান কম্পোনেন্ট নিরাপদ রাখা অত্যন্ত গুরুত্বপূর্ণ। সবচেয়ে প্রথমে kube-apiserver-এ Anonymous Authentication বন্ধ করতে হবে, এবং --anonymous-auth=false ফ্ল্যাগ সেট করতে হবে।

etcd, যা ক্লাস্টারের সমস্ত State এবং Secret সংরক্ষণ করে, সেটি অবশ্যই TLS Encryption দিয়ে সুরক্ষিত রাখতে হবে। --cert-file, --key-file, এবং --client-cert-auth ফ্ল্যাগ সঠিকভাবে কনফিগার করতে হবে। Encryption at Rest সক্ষম করার জন্য EncryptionConfiguration ফাইল ব্যবহার করতে হয়, যেখানে aescbc বা KMS প্রোভাইডার সেট করা যায়:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources: ["secrets"]
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <base64-encoded-secret>
      - identity: {}

Managed Kubernetes Service যেমন EKS, GKE, বা AKS ব্যবহার করলে এই Hardening-এর অনেকটাই প্রোভাইডার নিজেই করে দেয়, তবে নিজস্ব ক্লাস্টার (Self-managed) চালালে সবকিছু নিজে কনফিগার করতে হয়।

Role-Based Access Control (RBAC) হলো Kubernetes-এর সবচেয়ে গুরুত্বপূর্ণ নিরাপত্তা ফিচার। প্রতিটি API অনুরোধ RBAC নিয়ম অনুযায়ী Authorize হয়। Least Privilege Principle অনুসরণ করে RBAC কনফিগার করা অপরিহার্য। কোনোভাবেই Default ServiceAccount-কে cluster-admin Role দেওয়া উচিত নয়।

প্রতিটি অ্যাপ্লিকেশনের জন্য একটি স্বতন্ত্র ServiceAccount তৈরি করতে হবে এবং সেটিকে শুধুমাত্র যে Resource-এ অ্যাক্সেস প্রয়োজন সেটুকুই Permission দিতে হবে। Wildcard * ব্যবহার থেকে যথাসম্ভব বিরত থাকতে হবে। RoleBinding এবং ClusterRoleBinding-এর পার্থক্য বোঝা গুরুত্বপূর্ণ - RoleBinding শুধু একটি namespace-এ কাজ করে, যেখানে ClusterRoleBinding পুরো ক্লাস্টার জুড়ে।

Human User-দের জন্য OIDC-ভিত্তিক Authentication ব্যবহার করা উচিত, যেখানে Azure AD, Google Workspace, বা Okta-র সাথে ইন্টিগ্রেশন করা যায়। এতে কর্মী চাকরি ছেড়ে গেলে স্বয়ংক্রিয়ভাবে অ্যাক্সেস বাতিল হয়ে যায়।

পূর্বে PodSecurityPolicy (PSP) ব্যবহার করা হলেও Kubernetes 1.25 থেকে এটি সরিয়ে নিয়ে Pod Security Admission (PSA) চালু করা হয়েছে। PSA তিনটি স্তরে Security Profile প্রয়োগ করে - Privileged (কোনো বিধিনিষেধ নেই), Baseline (পরিচিত privilege escalation থেকে রক্ষা), এবং Restricted (সবচেয়ে কঠোর, Hardened Pod-এর জন্য)।

একটি Namespace-এ PSA সক্ষম করতে হলে:

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Restricted profile-এ Container অবশ্যই Non-root User হিসেবে চলতে হবে, allowPrivilegeEscalation: false থাকতে হবে, এবং readOnlyRootFilesystem: true সেট করতে হবে। আরও Granular Control-এর জন্য OPA Gatekeeper বা Kyverno-র মতো Admission Controller ব্যবহার করা যায়।

Kubernetes-এ ডিফল্ট নেটওয়ার্ক মডেল হলো "Flat Network" - প্রতিটি Pod অন্য সব Pod-এর সাথে যোগাযোগ করতে পারে। এটি একটি বড় নিরাপত্তা ঝুঁকি, বিশেষত যদি একটি Pod Compromised হয়। NetworkPolicy ব্যবহার করে এই Default Behavior পরিবর্তন করতে হয়।

একটি সাধারণ Deny-all NetworkPolicy যা একটি namespace-এ Incoming traffic বন্ধ করে দেয়:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

আধুনিক ক্লাস্টারে Service Mesh যেমন Istio, Linkerd, বা Cilium Service Mesh ব্যবহার করা হয়, যা mTLS-এর মাধ্যমে Pod-to-Pod যোগাযোগ এনক্রিপ্ট করে এবং Fine-grained Traffic Policy প্রয়োগ করে। Zero Trust Network Architecture বাস্তবায়নে Service Mesh অপরিহার্য।

Kubernetes Secrets ডিফল্টভাবে base64 এনকোডিং ব্যবহার করে, যা এনক্রিপশন নয়। যেকেউ যার get secrets Permission আছে সে সহজেই Secret দেখতে পারে। তাই Secret-এর জন্য External Secret Management সলিউশন যেমন HashiCorp Vault, AWS Secrets Manager, বা Azure Key Vault ব্যবহার করা উচিত।

External Secrets Operator বা Secrets Store CSI Driver ব্যবহার করে External Vault থেকে Secret সরাসরি Pod-এ Inject করা যায়, যাতে Kubernetes etcd-তে Secret সংরক্ষিত না হয়। SealedSecrets বা SOPS ব্যবহার করে GitOps Workflow-এ এনক্রিপ্টেড Secret সংরক্ষণ করা যায়।

Kubernetes Security-এর একটি গুরুত্বপূর্ণ অংশ হলো Container Image-এর নিরাপত্তা। প্রতিটি Image-এ থাকা Library এবং OS Package-এ Vulnerability থাকতে পারে। Trivy, Grype, Snyk, বা Clair-এর মতো টুল ব্যবহার করে CI/CD pipeline-এ Image Scanning বাধ্যতামূলক করতে হবে।

Image Signing-এর জন্য Sigstore-এর Cosign ব্যবহার করা যেতে পারে, যা একটি Public-private Key Pair দিয়ে Image স্বাক্ষর করে। Admission Controller-এ Image Signature যাচাই করার নিয়ম যোগ করলে শুধুমাত্র Trusted Image-ই ক্লাস্টারে চালানো যাবে। Distroless বা Scratch Image ব্যবহার করে Attack Surface ছোট রাখা যায়, কারণ এদের মধ্যে অপ্রয়োজনীয় Shell বা Package থাকে না।

স্ট্যাটিক স্ক্যানিং-এর পাশাপাশি Runtime Protection অত্যন্ত গুরুত্বপূর্ণ। Falco হলো CNCF-এর একটি জনপ্রিয় ওপেন সোর্স টুল, যা Kernel-level Events মনিটর করে অস্বাভাবিক কার্যকলাপ শনাক্ত করে। উদাহরণস্বরূপ, একটি Container-এ অপ্রত্যাশিত Shell Spawn, /etc/passwd পরিবর্তন, বা Sensitive ফাইল পড়ার চেষ্টা Falco দ্রুত ধরতে পারে।

Tetragon, Cilium-এর তৈরি eBPF-ভিত্তিক টুল, আরও কম Overhead-এ Deep Observability প্রদান করে। বাণিজ্যিক সলিউশনের মধ্যে রয়েছে Aqua Security, Sysdig Secure, এবং Wiz, যা Cloud-native পরিবেশের জন্য Comprehensive Security Posture Management প্রদান করে।

Audit Logging সক্ষম করা অপরিহার্য - kube-apiserver-এর Audit Log SIEM সিস্টেম যেমন Splunk বা ELK-তে পাঠিয়ে Anomaly Detection করতে হবে।

Sigstore প্রজেক্ট এবং SLSA (Supply chain Levels for Software Artifacts) ফ্রেমওয়ার্ক Container পরিবেশের Supply Chain Security-তে বিপ্লব এনেছে। SBOM (Software Bill of Materials) তৈরি করে প্রতিটি Image-এ কী কী Component আছে তার একটি বিস্তারিত তালিকা রাখা যায়। Syft বা Trivy ব্যবহার করে SBOM তৈরি করা সহজ।

GitOps Workflow-এ ArgoCD বা Flux ব্যবহার করে Configuration drift কমানো এবং Auditability বাড়ানো যায়। Infrastructure as Code (IaC) স্ক্যানিং-এর জন্য Checkov, tfsec, বা KICS ব্যবহার করে Terraform বা Helm Chart-এ Misconfiguration আগেই ধরা যায়।

একটি সুরক্ষিত Kubernetes ক্লাস্টার গড়ে তুলতে CIS Kubernetes Benchmark অনুসরণ করতে হবে। kube-bench টুল ব্যবহার করে স্বয়ংক্রিয়ভাবে Benchmark Compliance যাচাই করা যায়। নিয়মিত Penetration Testing এবং Red Team Exercise চালিয়ে ক্লাস্টারের নিরাপত্তা পরীক্ষা করতে হবে।

Disaster Recovery পরিকল্পনার অংশ হিসেবে নিয়মিত etcd Backup নিতে হবে এবং সেই Backup-গুলো এনক্রিপ্টেড এবং অফসাইটে সংরক্ষণ করতে হবে। Velero একটি জনপ্রিয় ওপেন সোর্স টুল যা Kubernetes Resource এবং Persistent Volume উভয়ই ব্যাকআপ করে।

কর্মীদের নিয়মিত প্রশিক্ষণ দেওয়া অপরিহার্য - Kubernetes-এর জটিলতার কারণে অনেক Misconfiguration জ্ঞানের অভাবে ঘটে। CKS (Certified Kubernetes Security Specialist) সার্টিফিকেশন একটি ভালো শুরু হতে পারে।