Hindi - Ht Cloud

Kubernetes Basics

Kubernetes Basics

Support HackTricks

The original author of this page is Jorge (read his original post here)

Architecture & Basics

What does Kubernetes do?

  • कंटेनर/को कंटेनर इंजन में चलाने की अनुमति देता है।

  • शेड्यूल कंटेनरों को मिशन कुशल बनाता है।

  • कंटेनरों को जीवित रखता है।

  • कंटेनर संचार की अनुमति देता है।

  • तैनाती तकनीकों की अनुमति देता है।

  • जानकारी की मात्रा को संभालता है।

Architecture

  • Node: ऑपरेटिंग सिस्टम जिसमें पॉड या पॉड्स होते हैं।

  • Pod: एक कंटेनर या कई कंटेनरों के चारों ओर लपेटने वाला। एक पॉड में केवल एक एप्लिकेशन होना चाहिए (इसलिए आमतौर पर, एक पॉड केवल 1 कंटेनर चलाता है)। पॉड वह तरीका है जिससे कुबेरनेट्स चल रहे कंटेनर तकनीक को अमूर्त करता है।

  • Service: प्रत्येक पॉड का 1 आंतरिक IP पता होता है जो नोड के आंतरिक रेंज से होता है। हालाँकि, इसे एक सेवा के माध्यम से भी उजागर किया जा सकता है। सेवा का भी एक IP पता है और इसका लक्ष्य पॉड्स के बीच संचार बनाए रखना है ताकि यदि एक मर जाता है तो नया प्रतिस्थापन (एक अलग आंतरिक IP के साथ) उसी सेवा के IP पर उपलब्ध होगा। इसे आंतरिक या बाहरी के रूप में कॉन्फ़िगर किया जा सकता है। सेवा तब लोड बैलेंसर के रूप में कार्य करती है जब 2 पॉड्स एक ही सेवा से जुड़े होते हैं। जब एक सेवा बनाई जाती है तो आप प्रत्येक सेवा के अंत बिंदुओं को kubectl get endpoints चलाकर पा सकते हैं।

  • Kubelet: प्राथमिक नोड एजेंट। वह घटक जो नोड और कुबectl के बीच संचार स्थापित करता है, और केवल पॉड्स चला सकता है (API सर्वर के माध्यम से)। कुबलेट उन कंटेनरों का प्रबंधन नहीं करता है जो कुबेरनेट्स द्वारा नहीं बनाए गए थे।

  • Kube-proxy: वह सेवा है जो apiserver और नोड के बीच संचार (सेवाओं) के लिए जिम्मेदार है। आधार नोड्स के लिए IPtables है। सबसे अनुभवी उपयोगकर्ता अन्य विक्रेताओं से अन्य kube-proxies स्थापित कर सकते हैं।

  • Sidecar container: साइडकार कंटेनर वे कंटेनर हैं जो पॉड में मुख्य कंटेनर के साथ चलने चाहिए। यह साइडकार पैटर्न मौजूदा कंटेनरों की कार्यक्षमता को बढ़ाता और बढ़ाता है बिना उन्हें बदले। आजकल, हम जानते हैं कि हम कंटेनर तकनीक का उपयोग सभी निर्भरताओं को लपेटने के लिए करते हैं ताकि एप्लिकेशन कहीं भी चल सके। एक कंटेनर केवल एक काम करता है और वह काम बहुत अच्छा करता है।

  • Master process:

  • Api Server: यह वह तरीका है जिससे उपयोगकर्ता और पॉड मास्टर प्रक्रिया के साथ संवाद करते हैं। केवल प्रमाणित अनुरोधों की अनुमति दी जानी चाहिए।

  • Scheduler: शेड्यूलिंग का तात्पर्य यह सुनिश्चित करने से है कि पॉड्स को नोड्स से मिलाया जाए ताकि कुबलेट उन्हें चला सके। इसमें यह तय करने के लिए पर्याप्त बुद्धिमत्ता है कि कौन सा नोड अधिक उपलब्ध संसाधनों के साथ है और नए पॉड को उसे सौंपता है। ध्यान दें कि शेड्यूलर नए पॉड्स शुरू नहीं करता है, यह केवल नोड के अंदर चल रहे कुबलेट प्रक्रिया के साथ संवाद करता है, जो नए पॉड को लॉन्च करेगा।

  • Kube Controller manager: यह संसाधनों की जांच करता है जैसे कि रिप्लिका सेट या तैनाती यह जांचने के लिए कि, उदाहरण के लिए, सही संख्या में पॉड्स या नोड्स चल रहे हैं। यदि कोई पॉड गायब है, तो यह एक नया शुरू करने के लिए शेड्यूलर के साथ संवाद करेगा। यह API के लिए पुनरुत्पादन, टोकन और खाता सेवाओं को नियंत्रित करता है।

  • etcd: डेटा भंडारण, स्थायी, सुसंगत, और वितरित। यह कुबेरनेट्स का डेटाबेस है और कुबेरनेट्स क्लस्टर की पूरी स्थिति को रखने के लिए कुंजी-मूल्य भंडारण है (यहाँ प्रत्येक परिवर्तन लॉग किया जाता है)। शेड्यूलर या कंट्रोलर प्रबंधक जैसे घटक इस डेटा पर निर्भर करते हैं यह जानने के लिए कि कौन से परिवर्तन हुए हैं (नोड्स के उपलब्ध संसाधन, चल रहे पॉड्स की संख्या...)।

  • Cloud controller manager: यह प्रवाह नियंत्रण और अनुप्रयोगों के लिए विशिष्ट नियंत्रक है, यानी: यदि आपके पास AWS या OpenStack में क्लस्टर हैं।

ध्यान दें कि चूंकि कई नोड्स (कई पॉड्स चला रहे हैं) हो सकते हैं, इसलिए कई मास्टर प्रक्रियाएँ भी हो सकती हैं जिनका एपीआई सर्वर तक पहुंच लोड संतुलित होती है और उनका etcd समन्वयित होता है।

Volumes:

जब एक पॉड डेटा बनाता है जिसे पॉड के गायब होने पर खोना नहीं चाहिए, तो इसे एक भौतिक वॉल्यूम में संग्रहीत किया जाना चाहिए। कुबेरनेट्स एक पॉड में डेटा को स्थायी बनाने के लिए एक वॉल्यूम संलग्न करने की अनुमति देता है। वॉल्यूम स्थानीय मशीन में या दूरस्थ भंडारण में हो सकता है। यदि आप विभिन्न भौतिक नोड्स में पॉड्स चला रहे हैं, तो आपको एक दूरस्थ भंडारण का उपयोग करना चाहिए ताकि सभी पॉड्स इसे एक्सेस कर सकें।

Other configurations:

  • ConfigMap: आप सेवाओं तक पहुँचने के लिए URLs कॉन्फ़िगर कर सकते हैं। पॉड यहाँ से डेटा प्राप्त करेगा यह जानने के लिए कि बाकी सेवाओं (पॉड्स) के साथ कैसे संवाद करना है। ध्यान दें कि यह क्रेडेंशियल्स को सहेजने के लिए अनुशंसित स्थान नहीं है!

  • Secret: यह गुप्त डेटा जैसे पासवर्ड, API कुंजी... को B64 में एन्कोड करने के लिए स्टोर करने का स्थान है। पॉड इस डेटा को आवश्यक क्रेडेंशियल्स का उपयोग करने के लिए एक्सेस कर सकेगा।

  • Deployments: यह वह स्थान है जहाँ कुबेरनेट्स द्वारा चलाए जाने वाले घटकों को इंगित किया जाता है। एक उपयोगकर्ता आमतौर पर पॉड्स के साथ सीधे काम नहीं करेगा, पॉड्स को ReplicaSets (एक समान पॉड्स की संख्या जो दोहराई जाती है) में अमूर्त किया जाता है, जिन्हें तैनातियों के माध्यम से चलाया जाता है। ध्यान दें कि तैनातियाँ stateless अनुप्रयोगों के लिए होती हैं। तैनाती के लिए न्यूनतम कॉन्फ़िगरेशन नाम और चलाने के लिए छवि है।

  • StatefulSet: यह घटक विशेष रूप से डेटाबेस जैसे अनुप्रयोगों के लिए है जिन्हें एक ही भंडारण तक पहुँचने की आवश्यकता होती है।

  • Ingress: यह वह कॉन्फ़िगरेशन है जिसका उपयोग URL के साथ एप्लिकेशन को सार्वजनिक रूप से उजागर करने के लिए किया जाता है। ध्यान दें कि यह बाहरी सेवाओं का उपयोग करके भी किया जा सकता है, लेकिन यह एप्लिकेशन को उजागर करने का सही तरीका है।

  • यदि आप एक इनग्रेस लागू करते हैं तो आपको Ingress Controllers बनाने की आवश्यकता होगी। इनग्रेस कंट्रोलर एक पॉड है जो वह अंत बिंदु होगा जो अनुरोध प्राप्त करेगा और उन्हें सेवाओं में लोड संतुलित करेगा। इनग्रेस कंट्रोलर कॉन्फ़िगर किए गए इनग्रेस नियमों के आधार पर अनुरोध भेजेगा। ध्यान दें कि इनग्रेस नियम विभिन्न पथों या यहां तक कि विभिन्न आंतरिक कुबेरनेट्स सेवाओं के लिए उपडोमेन की ओर इशारा कर सकते हैं।

  • एक बेहतर सुरक्षा प्रथा यह होगी कि किसी भी कुबेरनेट्स क्लस्टर के भाग को उजागर न करने के लिए एक क्लाउड लोड बैलेंसर या प्रॉक्सी सर्वर का उपयोग किया जाए।

  • जब कोई अनुरोध प्राप्त होता है जो किसी भी इनग्रेस नियम से मेल नहीं खाता है, तो इनग्रेस कंट्रोलर इसे "डिफ़ॉल्ट बैकएंड" की ओर निर्देशित करेगा। आप इस पैरामीटर के पते को प्राप्त करने के लिए इनग्रेस कंट्रोलर का describe कर सकते हैं।

  • minikube addons enable ingress

PKI infrastructure - Certificate Authority CA:

  • CA क्लस्टर के भीतर सभी प्रमाणपत्रों के लिए विश्वसनीय रूट है।

  • घटकों को एक-दूसरे को मान्य करने की अनुमति देता है।

  • सभी क्लस्टर प्रमाणपत्र CA द्वारा हस्ताक्षरित होते हैं।

  • ETCd का अपना प्रमाणपत्र है।

  • प्रकार:

  • apiserver cert.

  • kubelet cert.

  • scheduler cert.

Basic Actions

Minikube

Minikube का उपयोग कुछ त्वरित परीक्षण करने के लिए किया जा सकता है कुबेरनेट्स पर बिना पूरे कुबेरनेट्स वातावरण को तैनात किए। यह एक मशीन में मास्टर और नोड प्रक्रियाओं को चलाएगा। Minikube नोड चलाने के लिए वर्चुअल बॉक्स का उपयोग करेगा। यहाँ देखें कि इसे कैसे स्थापित करें.

$ minikube start
😄  minikube v1.19.0 on Ubuntu 20.04
✨  Automatically selected the virtualbox driver. Other choices: none, ssh
💿  Downloading VM boot image ...
> minikube-v1.19.0.iso.sha256: 65 B / 65 B [-------------] 100.00% ? p/s 0s
> minikube-v1.19.0.iso: 244.49 MiB / 244.49 MiB  100.00% 1.78 MiB p/s 2m17.
👍  Starting control plane node minikube in cluster minikube
💾  Downloading Kubernetes v1.20.2 preload ...
> preloaded-images-k8s-v10-v1...: 491.71 MiB / 491.71 MiB  100.00% 2.59 MiB
🔥  Creating virtualbox VM (CPUs=2, Memory=3900MB, Disk=20000MB) ...
🐳  Preparing Kubernetes v1.20.2 on Docker 20.10.4 ...
▪ Generating certificates and keys ...
▪ Booting up control plane ...
▪ Configuring RBAC rules ...
🔎  Verifying Kubernetes components...
▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟  Enabled addons: storage-provisioner, default-storageclass
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by defaul

$ minikube status
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

---- ONCE YOU HAVE A K8 SERVICE RUNNING WITH AN EXTERNAL SERVICE -----
$ minikube service mongo-express-service
(This will open your browser to access the service exposed port)

$ minikube delete
🔥  Deleting "minikube" in virtualbox ...
💀  Removed all traces of the "minikube" cluster

Kubectl Basics

Kubectl क्यूबेरनेट्स क्लस्टर के लिए कमांड लाइन टूल है। यह क्यूबेरनेट्स में क्रियाएँ करने या डेटा मांगने के लिए मास्टर प्रक्रिया के एपीआई सर्वर के साथ संवाद करता है।

kubectl version #Get client and server version
kubectl get pod
kubectl get services
kubectl get deployment
kubectl get replicaset
kubectl get secret
kubectl get all
kubectl get ingress
kubectl get endpoints

#kubectl create deployment <deployment-name> --image=<docker image>
kubectl create deployment nginx-deployment --image=nginx
#Access the configuration of the deployment and modify it
#kubectl edit deployment <deployment-name>
kubectl edit deployment nginx-deployment
#Get the logs of the pod for debbugging (the output of the docker container running)
#kubectl logs <replicaset-id/pod-id>
kubectl logs nginx-deployment-84cd76b964
#kubectl describe pod <pod-id>
kubectl describe pod mongo-depl-5fd6b7d4b4-kkt9q
#kubectl exec -it <pod-id> -- bash
kubectl exec -it mongo-depl-5fd6b7d4b4-kkt9q -- bash
#kubectl describe service <service-name>
kubectl describe service mongodb-service
#kubectl delete deployment <deployment-name>
kubectl delete deployment mongo-depl
#Deploy from config file
kubectl apply -f deployment.yml

Minikube Dashboard

डैशबोर्ड आपको यह देखने की अनुमति देता है कि मिनीक्यूब क्या चला रहा है, आप इसे एक्सेस करने के लिए URL यहाँ पा सकते हैं:

minikube dashboard --url


🔌  Enabling dashboard ...
▪ Using image kubernetesui/dashboard:v2.3.1
▪ Using image kubernetesui/metrics-scraper:v1.0.7
🤔  Verifying dashboard health ...
🚀  Launching proxy ...
🤔  Verifying proxy health ...
http://127.0.0.1:50034/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/

YAML configuration files examples

प्रत्येक कॉन्फ़िगरेशन फ़ाइल में 3 भाग होते हैं: metadata, specification (क्या लॉन्च करना है), status (इच्छित स्थिति)। डिप्लॉयमेंट कॉन्फ़िगरेशन फ़ाइल की स्पेसिफिकेशन के अंदर आप एक टेम्पलेट पा सकते हैं जो चलाने के लिए इमेज को परिभाषित करने वाली एक नई कॉन्फ़िगरेशन संरचना के साथ परिभाषित है:

Example of Deployment + Service declared in the same configuration file (from here)

चूंकि एक सेवा आमतौर पर एक डिप्लॉयमेंट से संबंधित होती है, इसलिए दोनों को एक ही कॉन्फ़िगरेशन फ़ाइल में घोषित करना संभव है (इस कॉन्फ़िगरेशन में घोषित सेवा केवल आंतरिक रूप से सुलभ है):

apiVersion: apps/v1
kind: Deployment
metadata:
name: mongodb-deployment
labels:
app: mongodb
spec:
replicas: 1
selector:
matchLabels:
app: mongodb
template:
metadata:
labels:
app: mongodb
spec:
containers:
- name: mongodb
image: mongo
ports:
- containerPort: 27017
env:
- name: MONGO_INITDB_ROOT_USERNAME
valueFrom:
secretKeyRef:
name: mongodb-secret
key: mongo-root-username
- name: MONGO_INITDB_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: mongodb-secret
key: mongo-root-password
---
apiVersion: v1
kind: Service
metadata:
name: mongodb-service
spec:
selector:
app: mongodb
ports:
- protocol: TCP
port: 27017
targetPort: 27017

बाहरी सेवा कॉन्फ़िगरेशन का उदाहरण

यह सेवा बाहरी रूप से सुलभ होगी (चेक करें nodePort और type: LoadBlancer विशेषताएँ):

---
apiVersion: v1
kind: Service
metadata:
name: mongo-express-service
spec:
selector:
app: mongo-express
type: LoadBalancer
ports:
- protocol: TCP
port: 8081
targetPort: 8081
nodePort: 30000

यह परीक्षण के लिए उपयोगी है लेकिन उत्पादन के लिए आपको केवल आंतरिक सेवाएँ और एप्लिकेशन को उजागर करने के लिए एक Ingress होना चाहिए।

Ingress कॉन्फ़िग फ़ाइल का उदाहरण

यह एप्लिकेशन को http://dashboard.com पर उजागर करेगा।

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: dashboard-ingress
namespace: kubernetes-dashboard
spec:
rules:
- host: dashboard.com
http:
paths:
- backend:
serviceName: kubernetes-dashboard
servicePort: 80

Example of secrets config file

ध्यान दें कि पासवर्ड B64 में एन्कोडेड हैं (जो सुरक्षित नहीं है!)

apiVersion: v1
kind: Secret
metadata:
name: mongodb-secret
type: Opaque
data:
mongo-root-username: dXNlcm5hbWU=
mongo-root-password: cGFzc3dvcmQ=

ConfigMap का उदाहरण

एक ConfigMap वह कॉन्फ़िगरेशन है जो पॉड्स को दिया जाता है ताकि वे जान सकें कि अन्य सेवाओं को कैसे ढूंढना और उन तक पहुंचना है। इस मामले में, प्रत्येक पॉड को पता होगा कि नाम mongodb-service एक पॉड का पता है जिसके साथ वे संवाद कर सकते हैं (यह पॉड एक mongodb निष्पादित करेगा):

apiVersion: v1
kind: ConfigMap
metadata:
name: mongodb-configmap
data:
database_url: mongodb-service

फिर, एक deployment config के अंदर, इस पते को इस प्रकार निर्दिष्ट किया जा सकता है ताकि यह पोड के env के अंदर लोड हो जाए:

[...]
spec:
[...]
template:
[...]
spec:
containers:
- name: mongo-express
image: mongo-express
ports:
- containerPort: 8081
env:
- name: ME_CONFIG_MONGODB_SERVER
valueFrom:
configMapKeyRef:
name: mongodb-configmap
key: database_url
[...]

उदाहरण वॉल्यूम कॉन्फ़िगरेशन

आप विभिन्न स्टोरेज कॉन्फ़िगरेशन yaml फ़ाइलों के उदाहरण https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes पर पा सकते हैं। ध्यान दें कि वॉल्यूम नामस्पेस के अंदर नहीं होते हैं

नामस्पेस

Kubernetes एक ही भौतिक क्लस्टर द्वारा समर्थित कई आभासी क्लस्टर का समर्थन करता है। इन आभासी क्लस्टरों को नामस्पेस कहा जाता है। ये उन वातावरणों में उपयोग के लिए बनाए गए हैं जिनमें कई उपयोगकर्ता कई टीमों या परियोजनाओं में फैले हुए हैं। कुछ से लेकर दर्जनों उपयोगकर्ताओं वाले क्लस्टरों के लिए, आपको नामस्पेस बनाने या उनके बारे में सोचने की आवश्यकता नहीं होनी चाहिए। आपको केवल नामस्पेस का उपयोग करना शुरू करना चाहिए ताकि आप kubernetes में तैनात प्रत्येक भाग के बेहतर नियंत्रण और संगठन को प्राप्त कर सकें।

नामस्पेस नामों के लिए एक दायरा प्रदान करते हैं। संसाधनों के नाम को एक नामस्पेस के भीतर अद्वितीय होना चाहिए, लेकिन नामस्पेस के बीच नहीं। नामस्पेस एक-दूसरे के अंदर नहीं हो सकते और प्रत्येक Kubernetes संसाधन केवल एक नामस्पेस में ही हो सकता है।

यदि आप minikube का उपयोग कर रहे हैं तो डिफ़ॉल्ट रूप से 4 नामस्पेस हैं:

kubectl get namespace
NAME              STATUS   AGE
default           Active   1d
kube-node-lease   Active   1d
kube-public       Active   1d
kube-system       Active   1d

  • kube-system: यह उपयोगकर्ताओं के लिए नहीं है और आपको इसे छूना नहीं चाहिए। यह मास्टर और kubectl प्रक्रियाओं के लिए है।

  • kube-public: सार्वजनिक रूप से सुलभ डेटा। इसमें एक configmap है जो क्लस्टर की जानकारी रखता है।

  • kube-node-lease: एक नोड की उपलब्धता निर्धारित करता है।

  • default: वह नामस्थान जिसे उपयोगकर्ता संसाधन बनाने के लिए उपयोग करेगा।

#Create namespace
kubectl create namespace my-namespace

ध्यान दें कि अधिकांश Kubernetes संसाधन (जैसे pods, services, replication controllers, और अन्य) कुछ namespaces में होते हैं। हालाँकि, अन्य संसाधन जैसे namespace संसाधन और निम्न-स्तरीय संसाधन, जैसे nodes और persistentVolumes किसी namespace में नहीं होते हैं। यह देखने के लिए कि कौन से Kubernetes संसाधन namespace में हैं और कौन से नहीं:

kubectl api-resources --namespaced=true #In a namespace
kubectl api-resources --namespaced=false #Not in a namespace

आप उस संदर्भ में सभी बाद के kubectl कमांड के लिए नामस्थान को सहेज सकते हैं।

kubectl config set-context --current --namespace=<insert-namespace-name-here>

Helm

Helm Kubernetes के लिए पैकेज प्रबंधक है। यह YAML फ़ाइलों को पैकेज करने और उन्हें सार्वजनिक और निजी रिपॉजिटरी में वितरित करने की अनुमति देता है। इन पैकेजों को Helm Charts कहा जाता है।

helm search <keyword>

Helm एक टेम्पलेट इंजन भी है जो वेरिएबल के साथ कॉन्फ़िग फ़ाइलें उत्पन्न करने की अनुमति देता है:

Kubernetes secrets

एक Secret एक ऑब्जेक्ट है जो संवेदनशील डेटा जैसे पासवर्ड, टोकन या कुंजी को धारण करता है। ऐसी जानकारी अन्यथा एक Pod स्पेसिफिकेशन या एक इमेज में रखी जा सकती है। उपयोगकर्ता Secrets बना सकते हैं और सिस्टम भी Secrets बनाता है। एक Secret ऑब्जेक्ट का नाम एक मान्य DNS उपडोमेन नाम होना चाहिए। यहाँ पढ़ें आधिकारिक दस्तावेज़।

Secrets कुछ इस प्रकार हो सकते हैं:

  • API, SSH Keys.

  • OAuth tokens.

  • Credentials, Passwords (plain text या b64 + encryption)।

  • जानकारी या टिप्पणियाँ।

  • डेटाबेस कनेक्शन कोड, स्ट्रिंग्स…।

Kubernetes में विभिन्न प्रकार के secrets होते हैं

Builtin TypeUsage

Opaque

मनमाने उपयोगकर्ता-परिभाषित डेटा (डिफ़ॉल्ट)

kubernetes.io/service-account-token

सेवा खाता टोकन

kubernetes.io/dockercfg

अनुक्रमित ~/.dockercfg फ़ाइल

kubernetes.io/dockerconfigjson

अनुक्रमित ~/.docker/config.json फ़ाइल

kubernetes.io/basic-auth

मूल प्रमाणीकरण के लिए क्रेडेंशियल्स

kubernetes.io/ssh-auth

SSH प्रमाणीकरण के लिए क्रेडेंशियल्स

kubernetes.io/tls

TLS क्लाइंट या सर्वर के लिए डेटा

bootstrap.kubernetes.io/token

बूटस्ट्रैप टोकन डेटा

Opaque प्रकार डिफ़ॉल्ट है, उपयोगकर्ताओं द्वारा परिभाषित सामान्य कुंजी-मूल्य जोड़ी।

Secrets कैसे काम करते हैं:

निम्नलिखित कॉन्फ़िगरेशन फ़ाइल एक secret को परिभाषित करती है जिसे mysecret कहा जाता है जिसमें 2 कुंजी-मूल्य जोड़े username: YWRtaW4= और password: MWYyZDFlMmU2N2Rm होते हैं। यह एक pod को भी परिभाषित करता है जिसे secretpod कहा जाता है जो mysecret में परिभाषित username और password को environment variables SECRET_USERNAME __ और __ SECRET_PASSWOR में उजागर करेगा। यह 0640 अनुमतियों के साथ /etc/foo/my-group/my-username पथ में mysecret के अंदर username secret को भी mount करेगा।

secretpod.yaml
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: MWYyZDFlMmU2N2Rm
---
apiVersion: v1
kind: Pod
metadata:
name: secretpod
spec:
containers:
- name: secretpod
image: nginx
env:
- name: SECRET_USERNAME
valueFrom:
secretKeyRef:
name: mysecret
key: username
- name: SECRET_PASSWORD
valueFrom:
secretKeyRef:
name: mysecret
key: password
volumeMounts:
- name: foo
mountPath: "/etc/foo"
restartPolicy: Never
volumes:
- name: foo
secret:
secretName: mysecret
items:
- key: username
path: my-group/my-username
mode: 0640
kubectl apply -f <secretpod.yaml>
kubectl get pods #Wait until the pod secretpod is running
kubectl exec -it  secretpod -- bash
env | grep SECRET && cat /etc/foo/my-group/my-username && echo

Secrets in etcd

etcd एक सुसंगत और उच्च उपलब्धता वाला की-वैल्यू स्टोर है, जिसका उपयोग Kubernetes द्वारा सभी क्लस्टर डेटा के लिए बैकिंग स्टोर के रूप में किया जाता है। चलिए etcd में संग्रहीत रहस्यों तक पहुँचते हैं:

cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep etcd

आप देखेंगे कि सर्ट्स, कीज़ और यूआरएल फ़ाइल सिस्टम में कहां स्थित हैं। एक बार जब आप इसे प्राप्त कर लेते हैं, तो आप etcd से कनेक्ट करने में सक्षम होंगे।

#ETCDCTL_API=3 etcdctl --cert <path to client.crt> --key <path to client.ket> --cacert <path to CA.cert> endpoint=[<ip:port>] health

ETCDCTL_API=3 etcdctl --cert /etc/kubernetes/pki/apiserver-etcd-client.crt --key /etc/kubernetes/pki/apiserver-etcd-client.key --cacert /etc/kubernetes/pki/etcd/etcd/ca.cert endpoint=[127.0.0.1:1234] health

एक बार जब आप संचार स्थापित कर लेते हैं, तो आप रहस्यों को प्राप्त करने में सक्षम होंगे:

#ETCDCTL_API=3 etcdctl --cert <path to client.crt> --key <path to client.ket> --cacert <path to CA.cert> endpoint=[<ip:port>] get <path/to/secret>

ETCDCTL_API=3 etcdctl --cert /etc/kubernetes/pki/apiserver-etcd-client.crt --key /etc/kubernetes/pki/apiserver-etcd-client.key --cacert /etc/kubernetes/pki/etcd/etcd/ca.cert endpoint=[127.0.0.1:1234] get /registry/secrets/default/secret_02

ETCD में एन्क्रिप्शन जोड़ना

डिफ़ॉल्ट रूप से सभी रहस्य सादा पाठ में etcd के अंदर संग्रहीत होते हैं जब तक कि आप एक एन्क्रिप्शन परत लागू नहीं करते। निम्नलिखित उदाहरण https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ पर आधारित है।

encryption.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
- secrets
providers:
- aescbc:
keys:
- name: key1
secret: cjjPMcWpTPKhAdieVtd+KhG4NN+N6e3NmBPMXJvbfrY= #Any random key
- identity: {}

इसके बाद, आपको kube-apiserver पर --encryption-provider-config ध्वज सेट करना होगा ताकि यह बनाए गए कॉन्फ़िग फ़ाइल के स्थान की ओर इशारा करे। आप /etc/kubernetes/manifest/kube-apiserver.yaml को संशोधित कर सकते हैं और निम्नलिखित पंक्तियाँ जोड़ सकते हैं:

containers:
- command:
- kube-apiserver
- --encriyption-provider-config=/etc/kubernetes/etcd/<configFile.yaml>

नीचे स्क्रॉल करें volumeMounts में:

- mountPath: /etc/kubernetes/etcd
name: etcd
readOnly: true

नीचे volumeMounts में hostPath पर स्क्रॉल करें:

- hostPath:
path: /etc/kubernetes/etcd
type: DirectoryOrCreate
name: etcd

डेटा के एन्क्रिप्टेड होने की पुष्टि करना

डेटा को etcd में लिखते समय एन्क्रिप्ट किया जाता है। अपने kube-apiserver को पुनरारंभ करने के बाद, कोई भी नया या अपडेट किया गया सीक्रेट स्टोर करते समय एन्क्रिप्ट किया जाना चाहिए। जांचने के लिए, आप अपने सीक्रेट की सामग्री को पुनः प्राप्त करने के लिए etcdctl कमांड लाइन प्रोग्राम का उपयोग कर सकते हैं।

  1. default नामस्थान में secret1 नामक एक नया सीक्रेट बनाएं:

kubectl create secret generic secret1 -n default --from-literal=mykey=mydata

  1. etcdctl कमांडलाइन का उपयोग करके, उस सीक्रेट को etcd से पढ़ें:

ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C

जहां [...] आदि सर्वर से कनेक्ट करने के लिए अतिरिक्त तर्क होना चाहिए। 3. पुष्टि करें कि स्टोर किया गया सीक्रेट k8s:enc:aescbc:v1: से प्रारंभ होता है, जो इंगित करता है कि aescbc प्रदाता ने परिणामी डेटा को एन्क्रिप्ट किया है। 4. पुष्टि करें कि API के माध्यम से पुनः प्राप्त करते समय सीक्रेट सही ढंग से डिक्रिप्ट किया गया है:

kubectl describe secret secret1 -n default

को mykey: bXlkYXRh से मेल खाना चाहिए, mydata को एन्कोड किया गया है, पूरी तरह से सीक्रेट को डिक्रिप्ट करने के लिए एक सीक्रेट को डिक्रिप्ट करना की जांच करें।

चूंकि सीक्रेट लिखने पर एन्क्रिप्ट होते हैं, इसलिए एक सीक्रेट पर अपडेट करना उस सामग्री को एन्क्रिप्ट करेगा:

kubectl get secrets --all-namespaces -o json | kubectl replace -f -

अंतिम सुझाव:

संदर्भ

kubesectips v1sickrov.github.io
HackTricks का समर्थन करें
PreviousKubernetes PentestingNextPentesting Kubernetes Services

Last updated