# Kubernetes Hardening

{{#include ../../../banners/hacktricks-training.md}}

## Tools to analyse a cluster

### [**Kubescape**](https://github.com/armosec/kubescape)

[**Kubescape**](https://github.com/armosec/kubescape) एक K8s ओपन-सोर्स टूल है जो एक मल्टी-क्लाउड K8s सिंगल पेन ऑफ ग्लास प्रदान करता है, जिसमें जोखिम विश्लेषण, सुरक्षा अनुपालन, RBAC विज़ुअलाइज़र और इमेज कमजोरियों की स्कैनिंग शामिल है। Kubescape K8s क्लस्टर्स, YAML फ़ाइलों और HELM चार्ट्स को स्कैन करता है, कई ढांचों के अनुसार गलत कॉन्फ़िगरेशन का पता लगाता है (जैसे [NSA-CISA](https://www.armosec.io/blog/kubernetes-hardening-guidance-summary-by-armo) , [MITRE ATT\&CK®](https://www.microsoft.com/security/blog/2021/03/23/secure-containerized-environments-with-updated-threat-matrix-for-kubernetes/)), सॉफ़्टवेयर कमजोरियों, और RBAC (भूमिका-आधारित-एक्सेस-नियंत्रण) उल्लंघनों का पता लगाता है CI/CD पाइपलाइन के प्रारंभिक चरणों में, तुरंत जोखिम स्कोर की गणना करता है और समय के साथ जोखिम प्रवृत्तियों को दिखाता है।
```bash
kubescape scan --verbose
```
### [**Kube-bench**](https://github.com/aquasecurity/kube-bench)

उपकरण [**kube-bench**](https://github.com/aquasecurity/kube-bench) एक ऐसा उपकरण है जो यह जांचता है कि क्या Kubernetes सुरक्षित रूप से तैनात किया गया है, [**CIS Kubernetes Benchmark**](https://www.cisecurity.org/benchmark/kubernetes/) में दस्तावेजीकृत जांचों को चलाकर।\
आप चुन सकते हैं:

- kube-bench को एक कंटेनर के अंदर चलाना (होस्ट के साथ PID नामस्थान साझा करना)
- एक कंटेनर चलाना जो होस्ट पर kube-bench स्थापित करता है, और फिर सीधे होस्ट पर kube-bench चलाना
- [Releases page](https://github.com/aquasecurity/kube-bench/releases) से नवीनतम बाइनरी स्थापित करना,
- स्रोत से संकलित करना।

### [**Kubeaudit**](https://github.com/Shopify/kubeaudit)

उपकरण [**kubeaudit**](https://github.com/Shopify/kubeaudit) एक कमांड लाइन उपकरण और विभिन्न सुरक्षा चिंताओं के लिए **Kubernetes क्लस्टर** का ऑडिट करने के लिए एक Go पैकेज है।

Kubeaudit यह पहचान सकता है कि क्या यह किसी क्लस्टर में एक कंटेनर के भीतर चल रहा है। यदि हां, तो यह उस क्लस्टर में सभी Kubernetes संसाधनों का ऑडिट करने की कोशिश करेगा:
```
kubeaudit all
```
इस उपकरण में `autofix` तर्क भी है जो **पाई गई समस्याओं को स्वचालित रूप से ठीक करता है।**

### [**Kube-hunter**](https://github.com/aquasecurity/kube-hunter)

उपकरण [**kube-hunter**](https://github.com/aquasecurity/kube-hunter) Kubernetes क्लस्टरों में सुरक्षा कमजोरियों की खोज करता है। इस उपकरण को Kubernetes वातावरण में सुरक्षा मुद्दों के प्रति जागरूकता और दृश्यता बढ़ाने के लिए विकसित किया गया था।
```bash
kube-hunter --remote some.node.com
```
### [**Kubei**](https://github.com/Erezf-p/kubei)

[**Kubei**](https://github.com/Erezf-p/kubei) एक कमजोरियों की स्कैनिंग और CIS Docker बेंचमार्क टूल है जो उपयोगकर्ताओं को उनके kubernetes क्लस्टरों का सटीक और तात्कालिक जोखिम मूल्यांकन प्राप्त करने की अनुमति देता है। Kubei सभी छवियों को स्कैन करता है जो Kubernetes क्लस्टर में उपयोग की जा रही हैं, जिसमें एप्लिकेशन पॉड और सिस्टम पॉड की छवियाँ शामिल हैं।

### [**KubiScan**](https://github.com/cyberark/KubiScan)

[**KubiScan**](https://github.com/cyberark/KubiScan) Kubernetes के Role-based access control (RBAC) प्राधिकरण मॉडल में जोखिम भरे अनुमतियों के लिए Kubernetes क्लस्टर को स्कैन करने के लिए एक उपकरण है।

### [Managed Kubernetes Auditing Toolkit](https://github.com/DataDog/managed-kubernetes-auditing-toolkit)

[**Mkat**](https://github.com/DataDog/managed-kubernetes-auditing-toolkit) अन्य उपकरणों की तुलना में उच्च जोखिम की जांच के अन्य प्रकारों का परीक्षण करने के लिए बनाया गया एक उपकरण है। इसमें मुख्य रूप से 3 विभिन्न मोड हैं:

- **`find-role-relationships`**: जो यह पता लगाएगा कि कौन से AWS भूमिकाएँ किस पॉड में चल रही हैं
- **`find-secrets`**: जो Pods, ConfigMaps, और Secrets जैसे K8s संसाधनों में रहस्यों की पहचान करने की कोशिश करता है।
- **`test-imds-access`**: जो पॉड्स को चलाने और मेटाडेटा v1 और v2 तक पहुँचने की कोशिश करेगा। चेतावनी: यह क्लस्टर में एक पॉड चलाएगा, बहुत सावधान रहें क्योंकि शायद आप यह नहीं करना चाहते!

## **Audit IaC Code**

### [**Popeye**](https://github.com/derailed/popeye)

[**Popeye**](https://github.com/derailed/popeye) एक उपयोगिता है जो लाइव Kubernetes क्लस्टर को स्कैन करती है और **तैनात संसाधनों और कॉन्फ़िगरेशन के साथ संभावित समस्याओं की रिपोर्ट करती है**। यह आपके क्लस्टर को तैनात किए गए आधार पर स्वच्छ करता है और डिस्क पर क्या है, इसके आधार पर नहीं। अपने क्लस्टर को स्कैन करके, यह गलत कॉन्फ़िगरेशन का पता लगाता है और आपको यह सुनिश्चित करने में मदद करता है कि सर्वोत्तम प्रथाएँ लागू हैं, इस प्रकार भविष्य की समस्याओं को रोकता है। इसका उद्देश्य एक Kubernetes क्लस्टर को संचालित करते समय सामना करने वाले संज्ञानात्मक \_over_load को कम करना है। इसके अलावा, यदि आपके क्लस्टर में एक मेट्रिक-सर्वर है, तो यह संभावित संसाधनों के अधिक/कम आवंटन की रिपोर्ट करता है और यदि आपका क्लस्टर क्षमता से बाहर हो जाता है तो आपको चेतावनी देने का प्रयास करता है।

### [**KICS**](https://github.com/Checkmarx/kics)

[**KICS**](https://github.com/Checkmarx/kics) निम्नलिखित **Infrastructure as Code solutions** में **सुरक्षा कमजोरियों**, अनुपालन मुद्दों, और बुनियादी ढांचे की गलत कॉन्फ़िगरेशन को खोजता है: Terraform, Kubernetes, Docker, AWS CloudFormation, Ansible, Helm, Microsoft ARM, और OpenAPI 3.0 विशिष्टताएँ

### [**Checkov**](https://github.com/bridgecrewio/checkov)

[**Checkov**](https://github.com/bridgecrewio/checkov) बुनियादी ढांचे के कोड के लिए एक स्थैतिक कोड विश्लेषण उपकरण है।

यह [Terraform](https://terraform.io), Terraform योजना, [Cloudformation](https://aws.amazon.com/cloudformation/), [AWS SAM](https://aws.amazon.com/serverless/sam/), [Kubernetes](https://kubernetes.io), [Dockerfile](https://www.docker.com), [Serverless](https://www.serverless.com) या [ARM Templates](https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/overview) का उपयोग करके प्रदान की गई क्लाउड बुनियादी ढांचे को स्कैन करता है और ग्राफ-आधारित स्कैनिंग का उपयोग करके सुरक्षा और अनुपालन गलत कॉन्फ़िगरेशन का पता लगाता है।

### [**Kube-score**](https://github.com/zegl/kube-score)

[**kube-score**](https://github.com/zegl/kube-score) एक उपकरण है जो आपके Kubernetes ऑब्जेक्ट परिभाषाओं का स्थैतिक कोड विश्लेषण करता है।

इंस्टॉल करने के लिए:

| वितरण                                            | कमांड / लिंक                                                                          |
| ------------------------------------------------ | ------------------------------------------------------------------------------------- |
| macOS, Linux, और Windows के लिए पूर्व-निर्मित बाइनरी | [GitHub releases](https://github.com/zegl/kube-score/releases)                        |
| Docker                                           | `docker pull zegl/kube-score` ([Docker Hub)](https://hub.docker.com/r/zegl/kube-score/) |
| Homebrew (macOS और Linux)                       | `brew install kube-score`                                                             |
| [Krew](https://krew.sigs.k8s.io/) (macOS और Linux) | `kubectl krew install score`                                                          |

## टिप्स

### Kubernetes PodSecurityContext और SecurityContext

आप **Pods के सुरक्षा संदर्भ** ( _PodSecurityContext_ के साथ) और **कंटेनरों** का सुरक्षा संदर्भ ( _SecurityContext_ के साथ) कॉन्फ़िगर कर सकते हैं जो चलाए जाने वाले हैं। अधिक जानकारी के लिए पढ़ें:

{{#ref}}
kubernetes-securitycontext-s.md
{{#endref}}

### Kubernetes API Hardening

Kubernetes Api Server तक पहुँच की **सुरक्षा करना** बहुत महत्वपूर्ण है क्योंकि एक दुर्भावनापूर्ण अभिनेता जिसके पास पर्याप्त विशेषाधिकार हैं, इसका दुरुपयोग कर सकता है और वातावरण को कई तरीकों से नुकसान पहुँचा सकता है।\
यह **पहुँच** (API सर्वर तक पहुँचने के लिए **व्हाइटलिस्ट** मूल और किसी अन्य कनेक्शन को अस्वीकार करना) और [**प्रमाणीकरण**](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) ( **कम से कम** **विशेषाधिकार** के सिद्धांत का पालन करते हुए) दोनों को सुरक्षित करना महत्वपूर्ण है। और निश्चित रूप से **कभी भी** **गुमनाम** **अनुरोधों** की **अनुमति** **नहीं** दें।

**सामान्य अनुरोध प्रक्रिया:**\
उपयोगकर्ता या K8s ServiceAccount –> प्रमाणीकरण –> प्राधिकरण –> प्रवेश नियंत्रण।

**टिप्स**:

- पोर्ट बंद करें।
- गुमनाम पहुँच से बचें।
- NodeRestriction; API से विशिष्ट नोड्स से कोई पहुँच नहीं।
- [https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction)
- मूल रूप से kubelets को node-restriction.kubernetes.io/ उपसर्ग के साथ लेबल जोड़ने/हटाने/अपडेट करने से रोकता है। यह लेबल उपसर्ग प्रशासकों के लिए उनके नोड ऑब्जेक्ट्स को कार्यभार अलगाव के उद्देश्यों के लिए लेबल करने के लिए आरक्षित है, और kubelets को उस उपसर्ग के साथ लेबल को संशोधित करने की अनुमति नहीं होगी।
- और साथ ही, kubelets को इन लेबलों और लेबल उपसर्गों को जोड़ने/हटाने/अपडेट करने की अनुमति देता है।
- लेबल के साथ सुरक्षित कार्यभार अलगाव सुनिश्चित करें।
- API पहुँच से विशिष्ट पॉड्स को बचें।
- इंटरनेट पर ApiServer के प्रदर्शन से बचें।
- अनधिकृत पहुँच RBAC से बचें।
- फ़ायरवॉल और IP व्हाइटलिस्टिंग के साथ ApiServer पोर्ट।

### SecurityContext Hardening

डिफ़ॉल्ट रूप से, यदि कोई अन्य उपयोगकर्ता निर्दिष्ट नहीं किया गया है, तो एक पॉड शुरू होने पर रूट उपयोगकर्ता का उपयोग किया जाएगा। आप निम्नलिखित में से एक टेम्पलेट का उपयोग करके एक अधिक सुरक्षित संदर्भ के भीतर अपने आवेदन को चला सकते हैं:
```yaml
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo
spec:
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
volumes:
- name: sec-ctx-vol
emptyDir: {}
containers:
- name: sec-ctx-demo
image: busybox
command: [ "sh", "-c", "sleep 1h" ]
securityContext:
runAsNonRoot: true
volumeMounts:
- name: sec-ctx-vol
mountPath: /data/demo
securityContext:
allowPrivilegeEscalation: true
```
- [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
- [https://kubernetes.io/docs/concepts/policy/pod-security-policy/](https://kubernetes.io/docs/concepts/policy/pod-security-policy/)

### सामान्य हार्डनिंग

आपको अपने Kubernetes वातावरण को आवश्यकतानुसार अपडेट करना चाहिए ताकि:

- निर्भरताएँ अद्यतित हों।
- बग और सुरक्षा पैच।

[**रिलीज़ चक्र**](https://kubernetes.io/docs/setup/release/version-skew-policy/): हर 3 महीने में एक नया माइनर रिलीज़ होता है -- 1.20.3 = 1(मुख्य).20(माइनर).3(पैच)

**Kubernetes क्लस्टर को अपडेट करने का सबसे अच्छा तरीका है (यहां से** [**यहां**](https://kubernetes.io/docs/tasks/administer-cluster/cluster-upgrade/)**):**

- मास्टर नोड के घटकों को इस अनुक्रम का पालन करते हुए अपग्रेड करें:
- etcd (सभी उदाहरण)।
- kube-apiserver (सभी नियंत्रण विमान होस्ट)।
- kube-controller-manager।
- kube-scheduler।
- क्लाउड कंट्रोलर प्रबंधक, यदि आप एक का उपयोग करते हैं।
- कार्यकर्ता नोड के घटकों जैसे kube-proxy, kubelet को अपग्रेड करें।

{{#include ../../../banners/hacktricks-training.md}}