mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['src/pentesting-cloud/kubernetes-security/exposing-services-
This commit is contained in:
Translator
@@ -2,11 +2,11 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Kubernetes में **services को expose करने के अलग-अलग तरीके** हैं ताकि **internal** endpoints और **external** endpoints दोनों उन्हें access कर सकें। यह Kubernetes configuration काफी critical है, क्योंकि administrator **attackers को उन services तक access** दे सकता है जिन्हें उन्हें access नहीं करना चाहिए।
|
||||
Kubernetes में services को expose करने के **different ways** हैं ताकि **internal** endpoints और **external** endpoints दोनों उन तक access कर सकें। यह Kubernetes configuration काफी critical है क्योंकि administrator **attackers को ऐसे services तक access** दे सकता है जिन्हें उन्हें access नहीं करना चाहिए।
|
||||
|
||||
### Automatic Enumeration
|
||||
|
||||
K8s public को services expose करने के लिए जो तरीके देता है, उन्हें enumerate करना शुरू करने से पहले, यह जान लें कि अगर आप namespaces, services और ingresses list कर सकते हैं, तो आप public के लिए exposed सब कुछ इस तरह ढूंढ सकते हैं:
|
||||
K8s public को services expose करने के लिए जो ways offer करता है, उन्हें enumerate शुरू करने से पहले यह जान लें कि अगर आप namespaces, services और ingresses list कर सकते हैं, तो आप public के लिए exposed सब कुछ इस तरह find कर सकते हैं:
|
||||
```bash
|
||||
kubectl get namespace -o custom-columns='NAME:.metadata.name' | grep -v NAME | while IFS='' read -r ns; do
|
||||
echo "Namespace: $ns"
|
||||
@@ -20,9 +20,9 @@ done | grep -v "ClusterIP"
|
||||
```
|
||||
### ClusterIP
|
||||
|
||||
एक **ClusterIP** service Kubernetes की **default** **service** है। यह आपको आपके cluster के **अंदर एक service** देता है जिसे आपके cluster के अंदर की दूसरी apps access कर सकती हैं। इसमें **कोई external access** नहीं होता।
|
||||
एक **ClusterIP** service Kubernetes की **default** **service** है। यह आपके cluster के **अंदर एक service** देती है, जिसे आपके cluster के अंदर की दूसरी apps access कर सकती हैं। इसका **कोई external access** नहीं होता।
|
||||
|
||||
हालांकि, इसे Kubernetes Proxy का उपयोग करके access किया जा सकता है:
|
||||
हालाँकि, इसे Kubernetes Proxy का उपयोग करके access किया जा सकता है:
|
||||
```bash
|
||||
kubectl proxy --port=8080
|
||||
```
|
||||
@@ -30,7 +30,7 @@ kubectl proxy --port=8080
|
||||
|
||||
`http://localhost:8080/api/v1/proxy/namespaces/<NAMESPACE>/services/<SERVICE-NAME>:<PORT-NAME>/`
|
||||
|
||||
उदाहरण के लिए, आप following URL का use कर सकते हैं:
|
||||
उदाहरण के लिए, आप निम्न URL का उपयोग कर सकते हैं:
|
||||
|
||||
`http://localhost:8080/api/v1/proxy/namespaces/default/services/my-internal-service:http/`
|
||||
|
||||
@@ -50,21 +50,21 @@ port: 80
|
||||
targetPort: 80
|
||||
protocol: TCP
|
||||
```
|
||||
_इस method के लिए आपको `kubectl` को एक **authenticated user** के रूप में चलाना होगा।_
|
||||
_यह method आपको `kubectl` को एक **authenticated user** के रूप में run करने की आवश्यकता होती है।_
|
||||
|
||||
सभी ClusterIPs सूचीबद्ध करें:
|
||||
सभी ClusterIPs की सूची:
|
||||
```bash
|
||||
kubectl get services --all-namespaces -o=custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,TYPE:.spec.type,CLUSTER-IP:.spec.clusterIP,PORT(S):.spec.ports[*].port,TARGETPORT(S):.spec.ports[*].targetPort,SELECTOR:.spec.selector' | grep ClusterIP
|
||||
```
|
||||
### NodePort
|
||||
|
||||
जब **NodePort** का उपयोग किया जाता है, तो सभी Nodes (Virtual Machines का प्रतिनिधित्व करते हुए) पर एक निर्धारित port उपलब्ध कराया जाता है। इस विशिष्ट port की ओर निर्देशित **Traffic** को फिर व्यवस्थित रूप से **service** तक **routed** किया जाता है। आमतौर पर, इसकी कमियों के कारण यह तरीका recommended नहीं है।
|
||||
जब **NodePort** का उपयोग किया जाता है, तो एक निर्धारित पोर्ट सभी Nodes (जो Virtual Machines का प्रतिनिधित्व करते हैं) पर उपलब्ध कराया जाता है। **Traffic** जो इस specific port की ओर directed होता है, उसे फिर systematicaly **service की ओर routed** किया जाता है। आमतौर पर, इसके drawbacks के कारण इस method की recommendation नहीं की जाती है।
|
||||
|
||||
सभी NodePorts सूचीबद्ध करें:
|
||||
सभी NodePorts की सूची बनाएं:
|
||||
```bash
|
||||
kubectl get services --all-namespaces -o=custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,TYPE:.spec.type,CLUSTER-IP:.spec.clusterIP,PORT(S):.spec.ports[*].port,NODEPORT(S):.spec.ports[*].nodePort,TARGETPORT(S):.spec.ports[*].targetPort,SELECTOR:.spec.selector' | grep NodePort
|
||||
```
|
||||
NodePort specification का एक example:
|
||||
NodePort specification का एक उदाहरण:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
@@ -81,30 +81,41 @@ targetPort: 80
|
||||
nodePort: 30036
|
||||
protocol: TCP
|
||||
```
|
||||
यदि आप yaml में **nodePort** निर्दिष्ट **नहीं करते** हैं (यह वही पोर्ट है जो खुला होगा), तो **30000–32767** की रेंज में से एक पोर्ट उपयोग किया जाएगा।
|
||||
यदि आप yaml में **nodePort** को **specify** नहीं करते हैं (यह वही port है जो open होगा), तो **range 30000–32767** में से एक port **use** किया जाएगा।
|
||||
|
||||
जब NodePort या LoadBalancer Services की review कर रहे हों, तो traffic-policy fields की भी जांच करें क्योंकि वे यह बदलते हैं कि किसी given source से कौन-से nodes और backends useful हैं:
|
||||
```bash
|
||||
kubectl get services --all-namespaces \
|
||||
-o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,TYPE:.spec.type,ETP:.spec.externalTrafficPolicy,ITP:.spec.internalTrafficPolicy,AFFINITY:.spec.sessionAffinity,DIST:.spec.trafficDistribution,NODEPORTS:.spec.ports[*].nodePort'
|
||||
```
|
||||
- `externalTrafficPolicy: Local` NodePort/LoadBalancer traffic के लिए original client source IP को preserve करता है और दूसरे nodes पर endpoints को forward करने से बचाता है। जिस node पर local ready endpoint नहीं है, वह traffic को drop कर सकता है, भले ही Service के पास कहीं और endpoints हों।
|
||||
- `externalTrafficPolicy: Cluster` default है और किसी भी node के through forward कर सकता है, लेकिन backend logs में real external client IP की बजाय node IPs दिख सकती हैं।
|
||||
- `internalTrafficPolicy: Local` in-cluster Service traffic को source node के local endpoints तक सीमित करता है। यह locality routing है, authorization boundary नहीं।
|
||||
- `sessionAffinity: ClientIP` एक ही client से repeated tests में same backend hit करवा सकता है, जिससे manual checks के दौरान दूसरे ready endpoints छिप सकते हैं।
|
||||
- `trafficDistribution` और EndpointSlice topology hints newer clusters पर same-zone या same-node endpoints को prefer कर सकते हैं; इन्हें hard security policy की बजाय routing preferences की तरह treat करें।
|
||||
|
||||
### LoadBalancer
|
||||
|
||||
Service को बाहरी रूप से **cloud provider के load balancer का उपयोग करके** expose करता है। GKE पर, यह एक [Network Load Balancer](https://cloud.google.com/compute/docs/load-balancing/network/) शुरू करेगा, जो आपको एक single IP address देगा और वह सभी traffic को आपकी service तक forward करेगा। AWS में यह एक Load Balancer लॉन्च करेगा।
|
||||
यह Service को बाहरी रूप से **cloud provider के load balancer** का उपयोग करके expose करता है। GKE पर, यह एक [Network Load Balancer](https://cloud.google.com/compute/docs/load-balancing/network/) spin up करेगा जो आपको एक single IP address देगा जो सभी traffic को आपकी service तक forward करेगा। AWS में यह एक Load Balancer launch करेगा।
|
||||
|
||||
आपको हर exposed service के लिए एक LoadBalancer का भुगतान करना होगा, जो महंगा हो सकता है।
|
||||
आपको हर exposed service के लिए एक LoadBalancer की pay करनी होती है, जो expensive हो सकता है।
|
||||
|
||||
सभी LoadBalancers सूचीबद्ध करें:
|
||||
सभी LoadBalancers की list करें:
|
||||
```bash
|
||||
kubectl get services --all-namespaces -o=custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,TYPE:.spec.type,CLUSTER-IP:.spec.clusterIP,EXTERNAL-IP:.status.loadBalancer.ingress[*],PORT(S):.spec.ports[*].port,NODEPORT(S):.spec.ports[*].nodePort,TARGETPORT(S):.spec.ports[*].targetPort,SELECTOR:.spec.selector' | grep LoadBalancer
|
||||
```
|
||||
### External IPs
|
||||
|
||||
> [!TIP]
|
||||
> External IPs services of type Load Balancers द्वारा exposed होते हैं और आम तौर पर तब उपयोग किए जाते हैं जब external Cloud Provider Load Balancer का उपयोग किया जा रहा हो।
|
||||
> External IPs को services of type Load Balancers द्वारा expose किया जाता है और ये आम तौर पर तब उपयोग किए जाते हैं जब external Cloud Provider Load Balancer उपयोग हो रहा होता है।
|
||||
>
|
||||
> उन्हें खोजने के लिए, `EXTERNAL-IP` फ़ील्ड में values वाले load balancers को check करें।
|
||||
> इन्हें खोजने के लिए, `EXTERNAL-IP` field में values वाले load balancers को check करें।
|
||||
|
||||
जो traffic cluster में **external IP** के साथ (**destination IP** के रूप में), Service port पर ingress करता है, उसे **Service endpoints में से एक** की ओर **routed** किया जाएगा। `externalIPs` Kubernetes द्वारा managed नहीं होते और cluster administrator की responsibility होते हैं।
|
||||
जो traffic cluster में **external IP** को **destination IP** के रूप में, Service port पर ingress करता है, उसे **Service के endpoints में से एक** पर **routed** किया जाएगा। `externalIPs` को Kubernetes manage नहीं करता और ये cluster administrator की responsibility हैं।
|
||||
|
||||
`externalIPs` एक sensitive route-control field है क्योंकि कोई user जो इसे set कर सकता है, वह ऐसे IP address के लिए traffic claim कर सकता है जिसे Service owner control नहीं करना चाहिए, यदि surrounding network उस IP को cluster की ओर route करता है। Kubernetes ने v1.36 में Service `externalIPs` की deprecation और planned removal की घोषणा की है, इसलिए जहाँ संभव हो वहाँ LoadBalancer integrations या Gateway API जैसे controller-owned exposure mechanisms को prefer करें, और जब तक यह मौजूद है, इस field को carefully restrict/admit करें।
|
||||
`externalIPs` एक sensitive route-control field है क्योंकि जो user इसे set कर सकता है, वह उस IP address के लिए traffic claim कर सकता है जिसे Service owner नियंत्रित नहीं करना चाहिए, अगर आसपास का network उस IP को cluster तक route करता है। Kubernetes ने v1.36 में Service `externalIPs` के deprecation और planned removal की घोषणा की है, इसलिए जहां संभव हो, LoadBalancer integrations या Gateway API जैसे controller-owned exposure mechanisms को prefer करें, और जब तक यह field मौजूद है, इसे carefully restrict/admit करें।
|
||||
|
||||
Service spec में, `externalIPs` को किसी भी `ServiceTypes` के साथ specified किया जा सकता है। नीचे दिए गए example में, "`my-service`" को clients "`80.11.12.10:80`" (`externalIP:port`) पर access कर सकते हैं
|
||||
Service spec में, `externalIPs` को किसी भी `ServiceTypes` के साथ specify किया जा सकता है। नीचे दिए गए example में, "`my-service`" को clients द्वारा "`80.11.12.10:80`" (`externalIP:port`) पर access किया जा सकता है।
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
@@ -123,9 +134,9 @@ externalIPs:
|
||||
```
|
||||
### ExternalName
|
||||
|
||||
[**From the docs:**](https://kubernetes.io/docs/concepts/services-networking/service/#externalname) type ExternalName वाले Services एक Service को DNS name पर **map** करते हैं, न कि `my-service` या `cassandra` जैसे typical selector पर। आप इन Services को `spec.externalName` parameter के साथ specify करते हैं।
|
||||
[**Docs से:**](https://kubernetes.io/docs/concepts/services-networking/service/#externalname) ExternalName type की Services एक Service को एक DNS name पर **map** करती हैं, न कि `my-service` या `cassandra` जैसे typical selector पर। आप इन Services को `spec.externalName` parameter के साथ specify करते हैं।
|
||||
|
||||
उदाहरण के लिए, यह Service definition `prod` namespace में `my-service` Service को `my.database.example.com` पर map करती है:
|
||||
यह Service definition, उदाहरण के लिए, `prod` namespace में `my-service` Service को `my.database.example.com` पर map करती है:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
@@ -136,7 +147,7 @@ spec:
|
||||
type: ExternalName
|
||||
externalName: my.database.example.com
|
||||
```
|
||||
जब host `my-service.prod.svc.cluster.local` को look up किया जाता है, तो cluster DNS Service `my.database.example.com` value के साथ एक `CNAME` record return करती है। `my-service` को access करना अन्य Services की तरह ही काम करता है, लेकिन एक महत्वपूर्ण अंतर के साथ कि **redirection DNS level पर होता है** न कि proxying या forwarding के जरिए।
|
||||
जब host `my-service.prod.svc.cluster.local` को look up किया जाता है, तो cluster DNS Service `CNAME` record के रूप में `my.database.example.com` value लौटाती है। `my-service` को access करना अन्य Services की तरह ही काम करता है, लेकिन एक महत्वपूर्ण अंतर के साथ: **redirection DNS level पर होती है** न कि proxying या forwarding के जरिए।
|
||||
|
||||
सभी ExternalNames की सूची:
|
||||
```bash
|
||||
@@ -144,26 +155,26 @@ kubectl get services --all-namespaces | grep ExternalName
|
||||
```
|
||||
### EndpointSlices
|
||||
|
||||
EndpointSlices किसी Service के लिए वर्तमान में जिन concrete backend addresses और ports पर route किया जा रहा है, उन्हें दिखाते हैं। ये खास तौर पर तब उपयोगी होते हैं जब किसी Service में selector नहीं होता, जब labels traffic path को स्पष्ट नहीं करते, या जब केवल कुछ backends ready होते हैं।
|
||||
EndpointSlices एक Service जिन concrete backend addresses और ports की ओर currently route करती है, उन्हें दिखाते हैं। ये खास तौर पर तब useful होते हैं जब किसी Service का selector नहीं होता, जब labels traffic path को explain नहीं करते, या जब केवल कुछ backends ready होते हैं।
|
||||
|
||||
Services से जुड़े EndpointSlices की सूची देखें:
|
||||
Services से जुड़े EndpointSlices list करें:
|
||||
```bash
|
||||
kubectl get endpointslices --all-namespaces
|
||||
kubectl get endpointslice -n <namespace> -l kubernetes.io/service-name=<service-name> -o yaml
|
||||
kubectl get endpointslice -n <namespace> -l kubernetes.io/service-name=<service-name> \
|
||||
-o custom-columns='NAME:.metadata.name,ADDR:.endpoints[*].addresses,READY:.endpoints[*].conditions.ready,PORTS:.ports[*].port'
|
||||
```
|
||||
एक exposure की समीक्षा करते समय, Service selector की तुलना EndpointSlice `targetRef`, endpoint addresses, readiness conditions, और ports के साथ करें। एक selectorless Service को manually managed EndpointSlices के साथ जोड़ा जा सकता है और traffic को non-Pod या unexpected destinations की ओर route किया जा सकता है।
|
||||
एक exposure की समीक्षा करते समय, Service selector की तुलना EndpointSlice `targetRef`, endpoint addresses, readiness conditions, और ports से करें। एक selectorless Service को manually managed EndpointSlices के साथ pair किया जा सकता है और traffic को non-Pod या unexpected destinations की ओर route किया जा सकता है।
|
||||
|
||||
### Ingress
|
||||
|
||||
ऊपर के सभी examples के विपरीत, **Ingress service का प्रकार नहीं है**। इसके बजाय, यह **multiple services के सामने** बैठता है और cluster में entrypoint के रूप में **“smart router”** की तरह काम करता है।
|
||||
ऊपर दिए गए सभी examples के विपरीत, **Ingress service का type नहीं है**। इसके बजाय, यह **multiple services के सामने बैठता है और एक “smart router”** या आपके cluster के लिए entrypoint की तरह act करता है।
|
||||
|
||||
आप Ingress के साथ कई अलग-अलग चीजें कर सकते हैं, और **Ingress controllers के कई types होते हैं जिनकी capabilities अलग-अलग होती हैं**।
|
||||
आप Ingress के साथ कई अलग-अलग चीजें कर सकते हैं, और **Ingress controllers के कई types हैं जिनकी capabilities अलग-अलग होती हैं**।
|
||||
|
||||
Default GKE ingress controller आपके लिए एक [HTTP(S) Load Balancer](https://cloud.google.com/compute/docs/load-balancing/http/) spin up करेगा। इससे आप path based और subdomain based routing दोनों backend services तक कर सकते हैं। उदाहरण के लिए, आप foo.yourdomain.com पर आने वाला सब कुछ foo service की ओर भेज सकते हैं, और yourdomain.com/bar/ path के नीचे आने वाला सब कुछ bar service की ओर भेज सकते हैं।
|
||||
Default GKE ingress controller आपके लिए एक [HTTP(S) Load Balancer](https://cloud.google.com/compute/docs/load-balancing/http/) spin up करेगा। इससे आप path based और subdomain based routing दोनों को backend services तक कर सकेंगे। उदाहरण के लिए, आप foo.yourdomain.com पर आने वाला सब कुछ foo service पर भेज सकते हैं, और yourdomain.com/bar/ path के अंदर आने वाला सब कुछ bar service पर भेज सकते हैं।
|
||||
|
||||
GKE पर एक [L7 HTTP Load Balancer](https://cloud.google.com/compute/docs/load-balancing/http/) के साथ एक Ingress object का YAML ऐसा दिख सकता है:
|
||||
GKE पर एक [L7 HTTP Load Balancer](https://cloud.google.com/compute/docs/load-balancing/http/) के साथ एक Ingress object के लिए YAML कुछ इस तरह दिख सकता है:
|
||||
```yaml
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: Ingress
|
||||
@@ -201,7 +212,7 @@ number: 8080
|
||||
```bash
|
||||
kubectl get ingresses --all-namespaces -o=custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,RULES:spec.rules[*],STATUS:status'
|
||||
```
|
||||
हालाँकि इस मामले में इसे बेहतर तरीके से पढ़ने के लिए एक-एक करके हर एक की जानकारी लेना बेहतर है:
|
||||
हालाँकि इस मामले में, इसे बेहतर पढ़ने के लिए हर एक की जानकारी एक-एक करके लेना बेहतर है:
|
||||
```bash
|
||||
kubectl get ingresses --all-namespaces -o=yaml
|
||||
```
|
||||
@@ -217,13 +228,16 @@ kubectl get httproutes --all-namespaces
|
||||
kubectl get gateway -n <namespace> <gateway-name> -o yaml
|
||||
kubectl get httproute -n <namespace> <route-name> -o yaml
|
||||
```
|
||||
Gateway listeners, allowed route namespaces, Route `parentRefs`, hostnames, filters, backend references, और status conditions जैसे कि route accepted हुआ था या नहीं, की जांच करें। एक Route जो shared Gateway द्वारा accepted है, वह backend expose कर सकता है, भले ही कोई legacy Ingress object मौजूद न हो।
|
||||
Gateway listeners, allowed route namespaces, Route `parentRefs`, hostnames, filters, backend references, और status conditions जैसे कि Route accepted हुआ था या नहीं, उन्हें check करें। एक Route जिसे shared Gateway द्वारा accepted किया गया है, backend को expose कर सकता है, भले ही कोई legacy Ingress object मौजूद न हो।
|
||||
|
||||
### References
|
||||
|
||||
- [https://medium.com/google-cloud/kubernetes-nodeport-vs-loadbalancer-vs-ingress-when-should-i-use-what-922f010849e0](https://medium.com/google-cloud/kubernetes-nodeport-vs-loadbalancer-vs-ingress-when-should-i-use-what-922f010849e0)
|
||||
- [https://kubernetes.io/docs/concepts/services-networking/service/](https://kubernetes.io/docs/concepts/services-networking/service/)
|
||||
- [https://kubernetes.io/blog/2026/05/14/kubernetes-v1-36-deprecation-and-removal-of-service-externalips/](https://kubernetes.io/blog/2026/05/14/kubernetes-v1-36-deprecation-and-removal-of-service-externalips/)
|
||||
- [https://kubernetes.io/docs/concepts/services-networking/service-traffic-policy/](https://kubernetes.io/docs/concepts/services-networking/service-traffic-policy/)
|
||||
- [https://kubernetes.io/docs/tutorials/services/source-ip/](https://kubernetes.io/docs/tutorials/services/source-ip/)
|
||||
- [https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/)
|
||||
- [https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/](https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/)
|
||||
- [https://gateway-api.sigs.k8s.io/](https://gateway-api.sigs.k8s.io/)
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
**इस पेज के original author हैं** [**Jorge**](https://www.linkedin.com/in/jorge-belmonte-a924b616b/) **(उनका original post पढ़ें** [**here**](https://sickrov.github.io)**)**
|
||||
**इस पेज का मूल लेखक है** [**Jorge**](https://www.linkedin.com/in/jorge-belmonte-a924b616b/) **(उसका मूल पोस्ट पढ़ें** [**यहाँ**](https://sickrov.github.io)**)**
|
||||
|
||||
## Architecture & Basics
|
||||
|
||||
@@ -13,42 +13,44 @@
|
||||
- containers को alive रखता है।
|
||||
- container communications की अनुमति देता है।
|
||||
- deployment techniques की अनुमति देता है।
|
||||
- volumes of information को handle करता है।
|
||||
- information के volumes को संभालता है।
|
||||
|
||||
### Architecture
|
||||
|
||||
|
||||
|
||||
- **Node**: pod या pods के साथ operating system।
|
||||
- **Pod**: एक container या multiple containers के around Wrapper with. एक pod में केवल एक application होना चाहिए (इसलिए आमतौर पर, एक pod सिर्फ 1 container run करता है)। pod वह तरीका है जिससे kubernetes running container technology को abstract करता है।
|
||||
- **Service**: हर pod के पास node की internal range से 1 internal **IP address** होता है। हालांकि, इसे service के जरिए expose भी किया जा सकता है। **service के पास भी एक IP address होता है** और इसका goal pods के बीच communication बनाए रखना है, ताकि अगर एक मर जाए तो **new replacement** (different internal IP के साथ) **same IP of the service** पर exposed होकर accessible रहे। इसे internal या external के रूप में configure किया जा सकता है। जब 2 pods same service से जुड़े होते हैं, तो service **load balancer** की तरह भी act करती है।\
|
||||
जब एक **service** **create** होती है, आप हर service के endpoints `kubectl get endpoints` चलाकर देख सकते हैं
|
||||
- **Kubelet**: Primary node agent. यह component node और kubectl के बीच communication establish करता है, और केवल pods चला सकता है (API server के through)। kubelet उन containers को manage नहीं करता जो Kubernetes द्वारा create नहीं किए गए थे।
|
||||
- **Kube-proxy**: यह service apiserver और node के बीच communications (services) की charge में है। इसका base nodes के लिए IPtables है। अधिक experienced users अन्य vendors के दूसरे kube-proxies install कर सकते हैं।
|
||||
- **Sidecar container**: Sidecar containers वे containers हैं जो pod में main container के साथ run होने चाहिए। यह sidecar pattern मौजूदा containers की functionality को उन्हें बदले बिना extend और enhance करता है। आजकल, हम जानते हैं कि हम container technology का उपयोग application की सभी dependencies को wrap करने के लिए करते हैं ताकि वह कहीं भी run हो सके। एक container सिर्फ एक चीज करता है और वह काम बहुत अच्छी तरह करता है।
|
||||
- **Node**: pod या pods के साथ operating system.
|
||||
- **Pod**: container या multiple containers के चारों ओर एक Wrapper. एक pod में केवल एक application होनी चाहिए (इसलिए आमतौर पर, एक pod सिर्फ 1 container चलाता है). Pod वह तरीका है जिससे kubernetes चल रही container technology को abstract करता है.
|
||||
- **Service**: हर pod के पास node की internal range से 1 internal **IP address** होता है. हालांकि, इसे service के जरिए expose भी किया जा सकता है. **service के पास भी एक IP address** होता है और इसका goal pods के बीच communication बनाए रखना है, ताकि अगर एक मर जाए तो **नई replacement** (एक अलग internal IP के साथ) **उसी service IP पर** accessible रहे। इसे internal या external के रूप में configure किया जा सकता है। service **load balancer** की तरह भी काम करती है जब 2 pods एक ही service से जुड़े हों।\
|
||||
जब एक **service** **created** होती है, तो आप `kubectl get endpoints` चलाकर हर service के endpoints देख सकते हैं
|
||||
- **Kubelet**: Primary node agent. वह component जो node और kubectl के बीच communication स्थापित करता है, और केवल pods चला सकता है (API server के through). kubelet उन containers को manage नहीं करता जो Kubernetes द्वारा created नहीं किए गए थे.
|
||||
- **Kube-proxy**: यह service है जो apiserver और node के बीच communications (services) की जिम्मेदार है. इसका base nodes के लिए IPtables है. अधिक अनुभवी users अन्य vendors के दूसरे kube-proxies install कर सकते हैं.
|
||||
- **Sidecar container**: Sidecar containers वे containers हैं जो pod में main container के साथ चलने चाहिए। यह sidecar pattern मौजूदा containers की functionality को बिना उन्हें बदले extend और enhance करता है। आजकल, हम जानते हैं कि application को कहीं भी run करने के लिए उसकी सभी dependencies को wrap करने के लिए container technology का उपयोग करते हैं। एक container सिर्फ एक काम करता है और उस काम को बहुत अच्छे से करता है।
|
||||
- **Master process:**
|
||||
- **Api Server:** यह वह तरीका है जिससे users और pods master process से communicate करते हैं। केवल authenticated request ही allowed होने चाहिए।
|
||||
- **Scheduler**: Scheduling का मतलब है यह सुनिश्चित करना कि Pods Nodes से match हों ताकि Kubelet उन्हें run कर सके। इसमें इतना intelligence होता है कि वह तय कर सके कि किस node के पास अधिक available resources हैं और new pod को उसे assign कर दे। ध्यान दें कि scheduler नए pods start नहीं करता, वह सिर्फ node के अंदर चल रहे Kubelet process से communicate करता है, जो नया pod launch करेगा।
|
||||
- **Kube Controller manager**: यह replica sets या deployments जैसे resources check करता है ताकि, उदाहरण के लिए, सही number of pods या nodes running हों। अगर कोई pod missing है, तो यह scheduler से communicate करके नया one start करेगा। यह replication, tokens, और account services को API के लिए control करता है।
|
||||
- **etcd**: Data storage, persistent, consistent, और distributed. यह Kubernetes’s database और key-value storage है जहाँ यह clusters की complete state रखता है (हर change यहाँ logged होता है)। Scheduler या Controller manager जैसे components इस data पर depend करते हैं ताकि वे जान सकें कि कौन से changes हुए हैं (nodes के available resources, running pods की number...)
|
||||
- **Cloud controller manager**: यह flow controls और applications के लिए specific controller है, यानी: अगर आपके clusters AWS या OpenStack में हैं।
|
||||
- **Api Server:** यह वह तरीका है जिससे users और pods master process के साथ communicate करते हैं। केवल authenticated request allowed होने चाहिए।
|
||||
- **Scheduler**: Scheduling का मतलब यह सुनिश्चित करना है कि Pods Nodes से match हों ताकि Kubelet उन्हें चला सके। इसमें इतनी intelligence होती है कि वह तय कर सके कि किस node के पास अधिक available resources हैं और नए pod को उसी पर assign कर दे। ध्यान दें कि scheduler नए pods start नहीं करता, वह बस node के अंदर चल रहे Kubelet process के साथ communicate करता है, जो नए pod को launch करेगा।
|
||||
- **Kube Controller manager**: यह replica sets या deployments जैसे resources को check करता है ताकि, उदाहरण के लिए, सही संख्या में pods या nodes चल रहे हों। यदि कोई pod missing हो, तो यह scheduler के साथ communicate करके एक नया शुरू करेगा। यह replication, tokens, और account services को API तक control करता है।
|
||||
- **etcd**: Data storage, persistent, consistent, और distributed. यह Kubernetes का database है और key-value storage है जहाँ यह clusters की complete state रखता है (हर change यहाँ logged होता है). Scheduler या Controller manager जैसे components इस date पर depend करते हैं ताकि वे जान सकें कि कौन से changes हुए हैं (nodes की available resourced, चल रहे pods की संख्या...)
|
||||
- **Cloud controller manager**: यह flow controls और applications के लिए specific controller है, जैसे: यदि आपके पास AWS या OpenStack में clusters हैं।
|
||||
|
||||
ध्यान दें कि जैसे कई nodes (कई pods चला रहे) हो सकते हैं, वैसे ही कई master processes भी हो सकते हैं जिनकी Api server तक access load balanced होती है और उनका etcd synchronized होता है।
|
||||
ध्यान दें कि जैसा कि कई nodes (कई pods चलाते हुए) हो सकते हैं, वैसे ही कई master processes भी हो सकते हैं जिनकी Api server तक access load balanced होती है और उनका etcd synchronized होता है।
|
||||
|
||||
**Volumes:**
|
||||
|
||||
जब कोई pod data create करता है जिसे pod disappear होने पर lost नहीं होना चाहिए, उसे physical volume में store करना चाहिए। **Kubernetes एक pod से volume attach करने की अनुमति देता है ताकि data persist रहे**। volume local machine में हो सकता है या **remote storage** में। अगर आप अलग-अलग physical nodes पर pods चला रहे हैं, तो आपको remote storage use करना चाहिए ताकि सभी pods उसे access कर सकें।
|
||||
जब कोई pod ऐसा data create करता है जिसे pod के disappear होने पर खोना नहीं चाहिए, तो उसे physical volume में store किया जाना चाहिए। **Kubernetes एक volume को pod के साथ attach करने की अनुमति देता है ताकि data persist रहे**। volume local machine पर हो सकता है या **remote storage** में। यदि आप अलग-अलग physical nodes पर pods चला रहे हैं, तो आपको remote storage का उपयोग करना चाहिए ताकि सभी pods उसे access कर सकें।
|
||||
|
||||
Kubernetes recent versions में **image volumes** को भी support करता है। एक `image` volume एक OCI image या artifact को Pod के अंदर **read-only** filesystem source के रूप में mount करता है, `volumes[].image.reference` और `volumes[].image.pullPolicy` जैसे fields का उपयोग करके। kubelet उसी credential sources के साथ artifact pull करता है जो container images के लिए उपयोग होते हैं, जिनमें node credentials, Pod `imagePullSecrets`, और ServiceAccount `imagePullSecrets` शामिल हैं। एक security review के दौरान, image volumes को runtime inputs और supply-chain dependencies की तरह treat करें: जांचें कि reference digest से pinned है या नहीं, कौन से registry credentials इसे fetch कर सकते हैं, इसे कहाँ mount किया गया है, और क्या `subPath` visible directory को सीमित करता है।
|
||||
|
||||
**Other configurations:**
|
||||
|
||||
- **ConfigMap**: आप services तक पहुंचने के लिए **URLs** configure कर सकते हैं। pod यहाँ से data लेगा ताकि वह बाकी services (pods) के साथ कैसे communicate करना है, यह जान सके। ध्यान दें कि credentials save करने के लिए यह recommended place नहीं है!
|
||||
- **Secret**: यह **secret data** जैसे passwords, API keys... को B64 में encoded करके **store** करने की जगह है। pod इस data को access करके required credentials use कर पाएगा।
|
||||
- **Deployments**: यहीं वे components indicated होते हैं जो kubernetes द्वारा run किए जाने हैं। आमतौर पर user सीधे pods के साथ काम नहीं करेगा, pods **ReplicaSets** (same pods की replicated number) में abstract होते हैं, जो deployments के through run होते हैं। ध्यान दें कि deployments **stateless** applications के लिए हैं। deployment की minimum configuration name और run होने वाली image है।
|
||||
- **StatefulSet**: यह component खास तौर पर **databases** जैसे applications के लिए meant है जिन्हें **same storage** access करने की जरूरत होती है।
|
||||
- **Ingress**: यह वह configuration है जिसका उपयोग application को **URL के साथ publicly expose करने** के लिए किया जाता है। ध्यान दें कि यह external services का उपयोग करके भी किया जा सकता है, लेकिन application को expose करने का यही सही तरीका है।
|
||||
- अगर आप Ingress implement करते हैं, तो आपको **Ingress Controllers** बनाना होगा। Ingress Controller एक **pod** है जो endpoint होगा जो requests receive करेगा और उन्हें check करेगा तथा services तक load balance करेगा। ingress controller **configured ingress rules के आधार पर request send करेगा**। ध्यान दें कि ingress rules अलग-अलग paths या यहां तक कि subdomains को different internal kubernetes services की ओर point कर सकते हैं।
|
||||
- बेहतर security practice यह होगी कि cloud load balancer या proxy server को entrypoint के रूप में use किया जाए ताकि Kubernetes cluster का कोई भी भाग exposed न हो।
|
||||
- जब कोई request जो किसी भी ingress rule से match नहीं करती receive होती है, तो ingress controller उसे "**Default backend**" की ओर direct करेगा। आप इस parameter का address पाने के लिए ingress controller को `describe` कर सकते हैं।
|
||||
- **ConfigMap**: आप services तक access करने के लिए **URLs** configure कर सकते हैं। pod यहाँ से data प्राप्त करेगा ताकि पता चल सके कि बाकी services (pods) के साथ कैसे communicate करना है। ध्यान दें कि credentials save करने के लिए यह recommended जगह नहीं है!
|
||||
- **Secret**: यह **secret data** जैसे passwords, API keys... को B64 में encoded करके store करने की जगह है। pod इस data को access करके required credentials use कर सकेगा।
|
||||
- **Deployments**: यह वह जगह है जहाँ kubernetes द्वारा run किए जाने वाले components indicated होते हैं। आमतौर पर user सीधे pods के साथ काम नहीं करेगा, pods को **ReplicaSets** (same pods की replicated संख्या) में abstract किया जाता है, जो deployments के through run होते हैं। ध्यान दें कि deployments **stateless** applications के लिए होते हैं। deployment की minimum configuration name और चलाने के लिए image है।
|
||||
- **StatefulSet**: यह component विशेष रूप से **databases** जैसे applications के लिए meant है जिन्हें **same storage** तक access करना होता है।
|
||||
- **Ingress**: यह वह configuration है जिसका उपयोग application को **URL के साथ publicly expose** करने के लिए किया जाता है। ध्यान दें कि यह external services का उपयोग करके भी किया जा सकता है, लेकिन application को expose करने का यही सही तरीका है।
|
||||
- यदि आप Ingress implement करते हैं, तो आपको **Ingress Controllers** बनाने होंगे। Ingress Controller एक **pod** है जो endpoint होगा जो requests receive करेगा और उन्हें check करेगा तथा services तक load balance करेगा। ingress controller **configured ingress rules के आधार पर request भेजेगा**। ध्यान दें कि ingress rules अलग-अलग paths या even subdomains को अलग-अलग internal kubernetes services की ओर point कर सकते हैं।
|
||||
- एक बेहतर security practice यह होगी कि cloud load balancer या proxy server को entrypoint के रूप में use किया जाए ताकि Kubernetes cluster का कोई भी part exposed न हो।
|
||||
- जब कोई request जो किसी भी ingress rule से match नहीं करती received होती है, तो ingress controller उसे "**Default backend**" पर direct करेगा। आप इस parameter का address पाने के लिए ingress controller को `describe` कर सकते हैं।
|
||||
- `minikube addons enable ingress`
|
||||
|
||||
### PKI infrastructure - Certificate Authority CA:
|
||||
@@ -58,7 +60,7 @@
|
||||
- CA cluster के अंदर सभी certificates के लिए trusted root है।
|
||||
- components को एक-दूसरे को validate करने की अनुमति देता है।
|
||||
- सभी cluster certificates CA द्वारा signed होते हैं।
|
||||
- ETCd का अपना certificate है।
|
||||
- ETCd का अपना certificate होता है।
|
||||
- types:
|
||||
- apiserver cert.
|
||||
- kubelet cert.
|
||||
@@ -68,7 +70,7 @@
|
||||
|
||||
### Minikube
|
||||
|
||||
**Minikube** का उपयोग kubernetes पर कुछ **quick tests** करने के लिए किया जा सकता है, बिना पूरे kubernetes environment को deploy किए। यह **master और node processes को एक ही machine में run** करेगा। Minikube node run करने के लिए virtualbox का उपयोग करेगा। इसे install करने का तरीका [**यहाँ देखें**](https://minikube.sigs.k8s.io/docs/start/).
|
||||
**Minikube** का उपयोग kubernetes पर कुछ **quick tests** करने के लिए किया जा सकता है, बिना पूरे kubernetes environment को deploy किए। यह **master और node processes को एक ही machine पर** चलाएगा। Minikube node चलाने के लिए virtualbox का उपयोग करेगा। इसे install करने का तरीका [**यहाँ देखें**](https://minikube.sigs.k8s.io/docs/start/).
|
||||
```
|
||||
$ minikube start
|
||||
😄 minikube v1.19.0 on Ubuntu 20.04
|
||||
@@ -105,7 +107,7 @@ $ minikube delete
|
||||
```
|
||||
### Kubectl Basics
|
||||
|
||||
**`Kubectl`** kubernetes clusters के लिए command line tool है। यह master process के Api server के साथ communicate करता है ताकि kubernetes में actions perform कर सके या data request कर सके।
|
||||
**`Kubectl`** kubernetes clusters के लिए command line tool है। यह actions करने या data मांगने के लिए master process के Api server के साथ communicate करता है।
|
||||
```bash
|
||||
kubectl version #Get client and server version
|
||||
kubectl get pod
|
||||
@@ -138,7 +140,7 @@ kubectl apply -f deployment.yml
|
||||
```
|
||||
### Minikube Dashboard
|
||||
|
||||
Dashboard आपको यह आसानी से देखने देता है कि minikube क्या चला रहा है, आप इसे एक्सेस करने के लिए URL यहां पा सकते हैं:
|
||||
dashboard आपको यह आसानी से देखने देता है कि minikube क्या चला रहा है, आप इसे access करने के लिए URL यहाँ पा सकते हैं:
|
||||
```
|
||||
minikube dashboard --url
|
||||
|
||||
@@ -153,12 +155,12 @@ http://127.0.0.1:50034/api/v1/namespaces/kubernetes-dashboard/services/http:kube
|
||||
```
|
||||
### YAML configuration files examples
|
||||
|
||||
प्रत्येक configuration file के 3 भाग होते हैं: **metadata**, **specification** (क्या launch करना है), **status** (desired state)।\
|
||||
Deployment configuration file की specification के अंदर आप template पा सकते हैं, जो एक नई configuration structure के साथ defined है, जिसमें run होने वाली image define होती है:
|
||||
प्रत्येक configuration file के 3 हिस्से होते हैं: **metadata**, **specification** (क्या launch करना है), **status** (desired state)।\
|
||||
deployment configuration file के specification के अंदर आपको template मिलेगा, जो एक नए configuration structure के साथ defined है और जिसमें run करने के लिए image define होती है:
|
||||
|
||||
**एक ही configuration file में declared Deployment + Service का Example (from** [**here**](https://gitlab.com/nanuchi/youtube-tutorial-series/-/blob/master/demo-kubernetes-components/mongo.yaml)**)**
|
||||
**Same configuration file में declared Deployment + Service का Example (from** [**here**](https://gitlab.com/nanuchi/youtube-tutorial-series/-/blob/master/demo-kubernetes-components/mongo.yaml)**)**
|
||||
|
||||
चूंकि एक service आमतौर पर एक deployment से related होती है, इसलिए दोनों को एक ही configuration file में declare करना possible है (इस config में declared service केवल internally accessible है):
|
||||
क्योंकि एक service आमतौर पर एक deployment से related होती है, इसलिए दोनों को same configuration file में declare करना possible है (इस config में declared service केवल internally accessible है):
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
@@ -205,9 +207,9 @@ ports:
|
||||
port: 27017
|
||||
targetPort: 27017
|
||||
```
|
||||
**बाहरी service config का Example**
|
||||
**बाहरी service config का उदाहरण**
|
||||
|
||||
यह service external रूप से accessible होगी (`nodePort` और `type: LoadBlancer` attributes को check करें):
|
||||
यह service externally accessible होगी ( `nodePort` और `type: LoadBlancer` attributes चेक करें):
|
||||
```yaml
|
||||
---
|
||||
apiVersion: v1
|
||||
@@ -229,7 +231,7 @@ nodePort: 30000
|
||||
|
||||
**Ingress config file का Example**
|
||||
|
||||
यह application को `http://dashboard.com` में expose करेगा।
|
||||
यह application को `http://dashboard.com` पर expose करेगा।
|
||||
```yaml
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: Ingress
|
||||
@@ -260,7 +262,7 @@ mongo-root-password: cGFzc3dvcmQ=
|
||||
```
|
||||
**ConfigMap का उदाहरण**
|
||||
|
||||
एक **ConfigMap** वह configuration है जो pods को दी जाती है ताकि वे जान सकें कि दूसरे services को कैसे locate और access करना है। इस case में, हर pod को पता होगा कि नाम `mongodb-service` एक ऐसे pod का address है जिससे वे communicate कर सकते हैं (यह pod एक mongodb execute कर रहा होगा):
|
||||
एक **ConfigMap** वह configuration है जो pods को दी जाती है ताकि वे जान सकें कि अन्य services को कैसे locate और access करना है। इस मामले में, हर pod को पता होगा कि `mongodb-service` नाम उस pod का address है जिससे वे communicate कर सकते हैं (यह pod एक mongodb execute कर रहा होगा):
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
@@ -269,7 +271,7 @@ name: mongodb-configmap
|
||||
data:
|
||||
database_url: mongodb-service
|
||||
```
|
||||
फिर, एक **deployment config** के अंदर इस address को निम्न तरीके से specify किया जा सकता है ताकि यह pod के env के अंदर load हो जाए:
|
||||
फिर, एक **deployment config** के अंदर इस address को निम्न तरीके से specify किया जा सकता है ताकि यह pod के env के अंदर loaded हो:
|
||||
```yaml
|
||||
[...]
|
||||
spec:
|
||||
@@ -290,18 +292,18 @@ name: mongodb-configmap
|
||||
key: database_url
|
||||
[...]
|
||||
```
|
||||
**वॉल्यूम config का उदाहरण**
|
||||
**वॉल्यूम config का Example**
|
||||
|
||||
आप [https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes](https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes) में storage configuration yaml files के अलग-अलग example पा सकते हैं।\
|
||||
आप storage configuration yaml files के अलग-अलग example [https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes](https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes) में पा सकते हैं।\
|
||||
**ध्यान दें कि volumes namespaces के अंदर नहीं होते**
|
||||
|
||||
### Namespaces
|
||||
|
||||
Kubernetes **multiple virtual clusters** को support करता है, जो एक ही physical cluster पर आधारित होते हैं। इन virtual clusters को **namespaces** कहा जाता है। ये उन environments में use के लिए intended हैं जहाँ कई users अलग-अलग teams या projects में फैले होते हैं। कुछ से लेकर कुछ दर्जन users वाले clusters के लिए, आपको namespaces बनाने या उनके बारे में सोचने की ज़रूरत नहीं होनी चाहिए। आपको namespaces का use तभी शुरू करना चाहिए जब आप kubernetes में deployed application के हर हिस्से पर बेहतर control और organization चाहते हों।
|
||||
Kubernetes **multiple virtual clusters** को support करता है, जो same physical cluster पर backed होते हैं। इन virtual clusters को **namespaces** कहा जाता है। इन्हें ऐसे environments में use करने के लिए बनाया गया है जहाँ कई users अलग-अलग teams या projects में फैले हों। कुछ से लेकर दर्जनों users वाले clusters के लिए, आपको namespaces बनाने या उनके बारे में सोचने की ज़रूरत नहीं होनी चाहिए। आपको namespaces का use तभी शुरू करना चाहिए जब आप kubernetes में deploy किए गए application के हर part पर बेहतर control और organization चाहते हों।
|
||||
|
||||
Namespaces names के लिए एक scope provide करते हैं। Resources के names किसी namespace के अंदर unique होने चाहिए, लेकिन अलग-अलग namespaces के बीच नहीं। Namespaces को एक-दूसरे के अंदर nest नहीं किया जा सकता, और **हर** Kubernetes **resource** केवल **एक** **namespace** में ही हो सकता है।
|
||||
Namespaces names के लिए एक scope provide करते हैं। resources के names किसी namespace के अंदर unique होने चाहिए, लेकिन different namespaces के बीच नहीं। Namespaces एक-दूसरे के अंदर nested नहीं हो सकते और **हर** Kubernetes **resource** केवल **एक** **namespace** में ही हो सकता है।
|
||||
|
||||
यदि आप minikube use कर रहे हैं, तो default रूप से 4 namespaces होते हैं:
|
||||
अगर आप minikube use कर रहे हैं तो by default 4 namespaces होते हैं:
|
||||
```
|
||||
kubectl get namespace
|
||||
NAME STATUS AGE
|
||||
@@ -310,23 +312,23 @@ kube-node-lease Active 1d
|
||||
kube-public Active 1d
|
||||
kube-system Active 1d
|
||||
```
|
||||
- **kube-system**: यह users के use करने के लिए meant नहीं है और आपको इसे touch नहीं करना चाहिए। यह master और kubectl processes के लिए है।
|
||||
- **kube-system**: इसका उपयोग users द्वारा नहीं किया जाना चाहिए और आपको इसे touch नहीं करना चाहिए. यह master और kubectl processes के लिए है.
|
||||
- **kube-public**: Publicly accessible date. इसमें एक configmap होता है जिसमें cluster information होती है
|
||||
- **kube-node-lease**: किसी node की availability निर्धारित करता है
|
||||
- **kube-node-lease**: एक node की availability निर्धारित करता है
|
||||
- **default**: वह namespace जिसे user resources create करने के लिए use करेगा
|
||||
```bash
|
||||
#Create namespace
|
||||
kubectl create namespace my-namespace
|
||||
```
|
||||
> [!NOTE]
|
||||
> ध्यान दें कि अधिकांश Kubernetes resources (e.g. pods, services, replication controllers, और अन्य) किसी namespace में होते हैं। हालांकि, अन्य resources जैसे namespace resources और low-level resources, जैसे nodes और persistenVolumes, namespace में नहीं होते। यह देखने के लिए कि कौन से Kubernetes resources namespace में हैं और कौन से नहीं:
|
||||
> ध्यान दें कि अधिकांश Kubernetes resources (जैसे pods, services, replication controllers, और अन्य) कुछ namespaces में होते हैं। हालांकि, namespace resources और low-level resources, जैसे nodes और persistenVolumes, namespace में नहीं होते। यह देखने के लिए कि कौन-से Kubernetes resources namespace में हैं और कौन-से नहीं:
|
||||
>
|
||||
> ```bash
|
||||
> kubectl api-resources --namespaced=true #In a namespace
|
||||
> kubectl api-resources --namespaced=false #Not in a namespace
|
||||
> ```
|
||||
|
||||
आप उस context में बाद के सभी kubectl commands के लिए namespace save कर सकते हैं।
|
||||
आप उस context में आने वाले सभी subsequent kubectl commands के लिए namespace save कर सकते हैं।
|
||||
```bash
|
||||
kubectl config set-context --current --namespace=<insert-namespace-name-here>
|
||||
```
|
||||
@@ -340,14 +342,14 @@ Helm भी एक template engine है जो variables के साथ conf
|
||||
|
||||
## Kubernetes secrets
|
||||
|
||||
एक **Secret** एक object है जो **sensitive data** जैसे password, token या key को **contain** करता है। ऐसी जानकारी अन्यथा Pod specification या image में रखी जा सकती है। Users Secrets बना सकते हैं और system भी Secrets बनाता है। किसी Secret object का name एक valid **DNS subdomain name** होना चाहिए। यहाँ पढ़ें [the official documentation](https://kubernetes.io/docs/concepts/configuration/secret/)।
|
||||
एक **Secret** एक object है जिसमें **sensitive data** जैसे password, token, या key होता है। ऐसी जानकारी अन्यथा Pod specification या image में रखी जा सकती है। Users Secrets बना सकते हैं और system भी Secrets बनाता है। किसी Secret object का name एक valid **DNS subdomain name** होना चाहिए। यहाँ पढ़ें [the official documentation](https://kubernetes.io/docs/concepts/configuration/secret/)।
|
||||
|
||||
Secrets कुछ इस तरह के हो सकते हैं:
|
||||
Secrets कुछ इस तरह हो सकते हैं:
|
||||
|
||||
- API, SSH Keys.
|
||||
- OAuth tokens.
|
||||
- Credentials, Passwords (plain text or b64 + encryption).
|
||||
- Information or comments.
|
||||
- Credentials, Passwords (plain text या b64 + encryption).
|
||||
- Information या comments.
|
||||
- Database connection code, strings… .
|
||||
|
||||
Kubernetes में secrets के अलग-अलग types होते हैं
|
||||
@@ -358,19 +360,19 @@ Kubernetes में secrets के अलग-अलग types होते ह
|
||||
| kubernetes.io/service-account-token | service account token |
|
||||
| kubernetes.io/dockercfg | serialized \~/.dockercfg file |
|
||||
| kubernetes.io/dockerconfigjson | serialized \~/.docker/config.json file |
|
||||
| kubernetes.io/basic-auth | basic authentication के लिए credentials |
|
||||
| kubernetes.io/ssh-auth | SSH authentication के लिए credentials |
|
||||
| kubernetes.io/tls | TLS client या server के लिए data |
|
||||
| kubernetes.io/basic-auth | credentials for basic authentication |
|
||||
| kubernetes.io/ssh-auth | credentials for SSH authentication |
|
||||
| kubernetes.io/tls | data for a TLS client or server |
|
||||
| bootstrap.kubernetes.io/token | bootstrap token data |
|
||||
|
||||
> [!NOTE]
|
||||
> **Opaque type default वाला है, जो users द्वारा defined typical key-value pair है।**
|
||||
> **Opaque type default होता है, जो users द्वारा defined typical key-value pair है।**
|
||||
|
||||
**secrets कैसे work करते हैं:**
|
||||
**Secrets कैसे काम करते हैं:**
|
||||
|
||||
|
||||
|
||||
निम्न configuration file एक **secret** `mysecret` define करती है जिसमें 2 key-value pairs `username: YWRtaW4=` और `password: MWYyZDFlMmU2N2Rm` हैं। यह एक **pod** `secretpod` भी define करती है, जिसमें `mysecret` में defined `username` और `password` को **environment variables** `SECRET_USERNAME` \_\_ और \_\_ `SECRET_PASSWOR` में exposed किया जाएगा। यह `mysecret` के अंदर `username` secret को path `/etc/foo/my-group/my-username` में `0640` permissions के साथ **mount** भी करेगा।
|
||||
निम्न configuration file एक **secret** परिभाषित करती है जिसका नाम `mysecret` है, जिसमें 2 key-value pairs `username: YWRtaW4=` और `password: MWYyZDFlMmU2N2Rm` हैं। यह एक **pod** भी परिभाषित करती है जिसका नाम `secretpod` है, जिसमें `mysecret` में परिभाषित `username` और `password` को **environment variables** `SECRET_USERNAME` \_\_ और \_\_ `SECRET_PASSWOR` में exposed किया जाएगा। यह `mysecret` के अंदर के `username` secret को path `/etc/foo/my-group/my-username` में `0640` permissions के साथ **mount** भी करेगा।
|
||||
```yaml:secretpod.yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
@@ -426,13 +428,13 @@ env | grep SECRET && cat /etc/foo/my-group/my-username && echo
|
||||
```bash
|
||||
cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep etcd
|
||||
```
|
||||
आप देखेंगे कि certs, keys और url’s FS में स्थित हैं। एक बार जब आप उन्हें प्राप्त कर लेते हैं, तो आप etcd से connect करने में सक्षम होंगे।
|
||||
आप देखेंगे कि certs, keys और url’s FS में located हैं। Once you get it, you would be able to connect to etcd.
|
||||
```bash
|
||||
#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
|
||||
```
|
||||
जब आप संचार स्थापित कर लेते हैं, तो आप secrets प्राप्त कर सकेंगे:
|
||||
एक बार जब आप संचार स्थापित कर लेते हैं, तो आप secrets प्राप्त कर सकेंगे:
|
||||
```bash
|
||||
#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>
|
||||
|
||||
@@ -440,7 +442,7 @@ ETCDCTL_API=3 etcdctl --cert /etc/kubernetes/pki/apiserver-etcd-client.crt --key
|
||||
```
|
||||
**ETCD में encryption जोड़ना**
|
||||
|
||||
By default सभी secrets **plain** text में etcd के अंदर stored होते हैं, जब तक कि आप encryption layer लागू न करें। निम्न उदाहरण [https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) पर आधारित है
|
||||
डिफ़ॉल्ट रूप से सभी secrets **plain** text में etcd के अंदर stored होते हैं, जब तक कि आप एक encryption layer लागू न करें। निम्नलिखित उदाहरण [https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) पर आधारित है
|
||||
```yaml:encryption.yaml
|
||||
apiVersion: apiserver.config.k8s.io/v1
|
||||
kind: EncryptionConfiguration
|
||||
@@ -454,7 +456,7 @@ keys:
|
||||
secret: cjjPMcWpTPKhAdieVtd+KhG4NN+N6e3NmBPMXJvbfrY= #Any random key
|
||||
- identity: {}
|
||||
```
|
||||
इसके बाद, आपको `kube-apiserver` पर `--encryption-provider-config` flag सेट करना होगा ताकि यह बनाए गए config file के location की ओर point करे। आप `/etc/kubernetes/manifest/kube-apiserver.yaml` को modify कर सकते हैं और निम्न lines जोड़ सकते हैं:
|
||||
उसके बाद, आपको `kube-apiserver` पर `--encryption-provider-config` flag को सेट करना होगा ताकि वह बनाए गए config file के location की ओर point करे। आप `/etc/kubernetes/manifest/kube-apiserver.yaml` को modify करके निम्न lines जोड़ सकते हैं:
|
||||
```yaml
|
||||
containers:
|
||||
- command:
|
||||
@@ -467,18 +469,18 @@ volumeMounts में नीचे स्क्रॉल करें:
|
||||
name: etcd
|
||||
readOnly: true
|
||||
```
|
||||
volumeMounts में नीचे स्क्रॉल करें और hostPath पर जाएं:
|
||||
volumeMounts में नीचे स्क्रॉल करें to hostPath:
|
||||
```yaml
|
||||
- hostPath:
|
||||
path: /etc/kubernetes/etcd
|
||||
type: DirectoryOrCreate
|
||||
name: etcd
|
||||
```
|
||||
**यह सत्यापित करना कि data encrypted है**
|
||||
**डेटा एन्क्रिप्टेड है, यह सत्यापित करना**
|
||||
|
||||
Data को etcd में लिखते समय encrypted किया जाता है। अपने `kube-apiserver` को restart करने के बाद, कोई भी नया बनाया गया या updated secret stored होने पर encrypted होना चाहिए। जांचने के लिए, आप `etcdctl` command line program का उपयोग करके अपने secret की contents retrieve कर सकते हैं।
|
||||
etcd में लिखे जाने पर डेटा एन्क्रिप्ट होता है। अपने `kube-apiserver` को restart करने के बाद, कोई भी नया बनाया गया या updated secret store किए जाने पर encrypted होना चाहिए। इसे check करने के लिए, आप `etcdctl` command line program का उपयोग करके अपने secret की contents retrieve कर सकते हैं।
|
||||
|
||||
1. `default` namespace में `secret1` नाम का एक नया secret बनाएं:
|
||||
1. `default` namespace में `secret1` नाम का नया secret बनाएं:
|
||||
|
||||
```
|
||||
kubectl create secret generic secret1 -n default --from-literal=mykey=mydata
|
||||
@@ -488,25 +490,25 @@ kubectl create secret generic secret1 -n default --from-literal=mykey=mydata
|
||||
|
||||
`ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C`
|
||||
|
||||
जहां `[...]` etcd server से connect करने के लिए अतिरिक्त arguments होने चाहिए।
|
||||
जहाँ `[...]` etcd server से connect करने के लिए अतिरिक्त arguments होने चाहिए।
|
||||
|
||||
3. Verify करें कि stored secret के आगे `k8s:enc:aescbc:v1:` लगा है, जो दर्शाता है कि `aescbc` provider ने resulting data को encrypted किया है।
|
||||
4. Verify करें कि API के माध्यम से retrieve करने पर secret सही तरह से decrypted होता है:
|
||||
3. Verify करें कि stored secret `k8s:enc:aescbc:v1:` से prefixed है, जो indicate करता है कि `aescbc` provider ने resulting data को encrypt किया है।
|
||||
4. Verify करें कि API के through retrieve करने पर secret correctly decrypted होता है:
|
||||
|
||||
```
|
||||
kubectl describe secret secret1 -n default
|
||||
```
|
||||
|
||||
`mykey: bXlkYXRh` से match होना चाहिए, mydata encoded है, secret को पूरी तरह decode करने के लिए [decoding a secret](https://kubernetes.io/docs/concepts/configuration/secret#decoding-a-secret) देखें।
|
||||
को `mykey: bXlkYXRh` से match करना चाहिए, mydata encoded है, secret को पूरी तरह decode करने के लिए [decoding a secret](https://kubernetes.io/docs/concepts/configuration/secret#decoding-a-secret) check करें।
|
||||
|
||||
**Since secrets are encrypted on write, performing an update on a secret will encrypt that content:**
|
||||
```
|
||||
kubectl get secrets --all-namespaces -o json | kubectl replace -f -
|
||||
```
|
||||
**Final tips:**
|
||||
**अंतिम tips:**
|
||||
|
||||
- कोशिश करें कि secrets को FS में न रखें, उन्हें दूसरी जगहों से प्राप्त करें।
|
||||
- अपने secrets को और अधिक protection देने के लिए [https://www.vaultproject.io/](https://www.vaultproject.io) देखें।
|
||||
- कोशिश करें कि secrets को FS में न रखें, उन्हें दूसरी जगहों से लें।
|
||||
- अपने secrets को और protection देने के लिए [https://www.vaultproject.io/](https://www.vaultproject.io) देखें।
|
||||
- [https://kubernetes.io/docs/concepts/configuration/secret/#risks](https://kubernetes.io/docs/concepts/configuration/secret/#risks)
|
||||
- [https://docs.cyberark.com/Product-Doc/OnlineHelp/AAM-DAP/11.2/en/Content/Integrations/Kubernetes_deployApplicationsConjur-k8s-Secrets.htm](https://docs.cyberark.com/Product-Doc/OnlineHelp/AAM-DAP/11.2/en/Content/Integrations/Kubernetes_deployApplicationsConjur-k8s-Secrets.htm)
|
||||
|
||||
@@ -520,4 +522,12 @@ https://sickrov.github.io/
|
||||
https://www.youtube.com/watch?v=X48VuDVv0do
|
||||
{{#endref}}
|
||||
|
||||
{{#ref}}
|
||||
https://kubernetes.io/docs/concepts/storage/volumes/#image
|
||||
{{#endref}}
|
||||
|
||||
{{#ref}}
|
||||
https://kubernetes.io/docs/tasks/configure-pod-container/image-volumes/
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
+43
-37
@@ -6,79 +6,85 @@
|
||||
|
||||
[**From the docs:**](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core)
|
||||
|
||||
Pod के security context को specify करते समय आप कई attributes का use कर सकते हैं। defensive security point of view से आपको consider करना चाहिए:
|
||||
जब आप किसी Pod का security context निर्दिष्ट करते हैं, तो आप कई attributes उपयोग कर सकते हैं। defensive security के दृष्टिकोण से आपको यह विचार करना चाहिए:
|
||||
|
||||
- **runASNonRoot** को **True** रखना
|
||||
- **runAsUser** को configure करना
|
||||
- यदि संभव हो, तो **seLinuxOptions** और **seccompProfile** बताकर **permissions** को **limit** करना
|
||||
- **runAsGroup** और **supplementaryGroups** के जरिए **privilege** **group** access **NOT** देना
|
||||
- **runAsUser** configure करना
|
||||
- यदि संभव हो, तो **seLinuxOptions** और **seccompProfile** बताकर **permissions** को **limit** करने पर विचार करें
|
||||
- **runAsGroup** और **supplementaryGroups** के जरिए **privilege** **group** access **NOT** दें
|
||||
|
||||
| Parameter | Description |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>fsGroup</strong></a><br><em>integer</em></p> | <p>एक special supplemental group जो एक pod के <strong>सभी containers</strong> पर apply होती है। कुछ volume types Kubelet को उस volume का <strong>ownership बदलने</strong> देते हैं ताकि वह pod के owned हो:<br>1. owning GID, FSGroup होगा<br>2. setgid bit set होगा (volume में बनी नई files, FSGroup की owned होंगी)<br>3. permission bits rw-rw---- के साथ OR'd होंगे। अगर unset हो, तो Kubelet किसी भी volume के ownership और permissions को modify नहीं करेगा</p> |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>fsGroup</strong></a><br><em>integer</em></p> | <p>एक special supplemental group जो pod के <strong>सभी containers</strong> पर लागू होती है। कुछ volume types Kubelet को उस volume का <strong>ownership बदलने</strong> की अनुमति देती हैं ताकि वह pod के owned हो:<br>1. owning GID, FSGroup होगा<br>2. setgid bit set होगा (volume में बने नए files, FSGroup के owned होंगे)<br>3. permission bits, rw-rw---- के साथ OR'd होंगे। अगर unset हो, तो Kubelet किसी भी volume के ownership और permissions को modify नहीं करेगा</p> |
|
||||
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>fsGroupChangePolicy</strong></a><br><em>string</em></p> | यह Pod के अंदर expose किए जाने से पहले **volume के ownership और permission बदलने** के behavior को define करता है। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>runAsGroup</strong></a><br><em>integer</em></p> | container process के entrypoint को चलाने के लिए **GID**। unset होने पर runtime default use होता है। यह SecurityContext में भी set किया जा सकता है। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>runAsNonRoot</strong></a><br><em>boolean</em></p> | बताता है कि container को non-root user के रूप में चलना चाहिए। अगर true हो, तो Kubelet runtime पर image validate करेगा ताकि सुनिश्चित हो कि वह UID 0 (root) के रूप में नहीं चलती, और अगर ऐसा है तो container start होने में fail करेगा। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>runAsUser</strong></a><br><em>integer</em></p> | container process के entrypoint को चलाने के लिए **UID**। अगर specify न किया हो, तो image metadata में दिए गए user को default माना जाता है। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>seLinuxOptions</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#selinuxoptions-v1-core"><em>SELinuxOptions</em></a><br><em>More info about</em> <em><strong>seLinux</strong></em></p> | सभी containers पर apply होने वाला **SELinux context**। अगर specify न हो, तो container runtime हर container के लिए एक random SELinux context allocate करेगा। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>seccompProfile</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#seccompprofile-v1-core"><em>SeccompProfile</em></a><br><em>More info about</em> <em><strong>Seccomp</strong></em></p> | इस pod में containers द्वारा use किए जाने वाले **seccomp options**। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>supplementalGroups</strong></a><br><em>integer array</em></p> | container की primary GID के अलावा, प्रत्येक container में चलने वाले पहले process पर apply होने वाले **groups** की सूची। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>sysctls</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#sysctl-v1-core"><em>Sysctl</em></a> <em>array</em><br><em>More info about</em> <a href="https://www.garron.me/en/go2linux/sysctl-linux.html"><em><strong>sysctls</strong></em></a></p> | Sysctls में pod के लिए use होने वाले **namespaced sysctls** की सूची होती है। unsupported sysctls वाले Pods (container runtime द्वारा) launch होने में fail हो सकते हैं। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>windowsOptions</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#windowssecuritycontextoptions-v1-core"><em>WindowsSecurityContextOptions</em></a></p> | सभी containers पर apply होने वाली Windows-specific settings। अगर specify न हो, तो container के SecurityContext के अंदर की options use होंगी। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>fsGroupChangePolicy</strong></a><br><em>string</em></p> | यह Pod के अंदर expose किए जाने से पहले **volume के ownership और permission बदलने** का behavior define करता है। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>runAsGroup</strong></a><br><em>integer</em></p> | container process के entrypoint को चलाने के लिए **GID**। अगर unset हो, तो runtime default use होता है। इसे SecurityContext में भी set किया जा सकता है। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>runAsNonRoot</strong></a><br><em>boolean</em></p> | यह बताता है कि container को non-root user के रूप में चलना चाहिए। अगर true हो, तो Kubelet runtime पर image validate करेगा ताकि सुनिश्चित हो सके कि वह UID 0 (root) के रूप में नहीं चलती, और ऐसा होने पर container start नहीं होगा। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>runAsUser</strong></a><br><em>integer</em></p> | container process के entrypoint को चलाने के लिए **UID**। अगर unspecified हो, तो image metadata में specified user default होगा। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>seLinuxOptions</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#selinuxoptions-v1-core"><em>SELinuxOptions</em></a><br><em>More info about</em> <em><strong>seLinux</strong></em></p> | सभी containers पर apply किए जाने वाला **SELinux context**। अगर unspecified हो, तो container runtime हर container के लिए एक random SELinux context allocate करेगा। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>seccompProfile</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#seccompprofile-v1-core"><em>SeccompProfile</em></a><br><em>More info about</em> <em><strong>Seccomp</strong></em></p> | इस pod में containers द्वारा उपयोग किए जाने वाले **seccomp options**। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>supplementalGroups</strong></a><br><em>integer array</em></p> | container के primary GID के अलावा, हर container में पहले चलने वाली process पर apply होने वाले **groups** की एक सूची। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>sysctls</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#sysctl-v1-core"><em>Sysctl</em></a> <em>array</em><br><em>More info about</em> <a href="https://www.garron.me/en/go2linux/sysctl-linux.html"><em><strong>sysctls</strong></em></a></p> | Sysctls में pod के लिए उपयोग होने वाले **namespaced sysctls** की एक सूची होती है। unsupported sysctls (container runtime द्वारा) वाले pods launch होने में fail हो सकते हैं। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>windowsOptions</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#windowssecuritycontextoptions-v1-core"><em>WindowsSecurityContextOptions</em></a></p> | सभी containers पर लागू होने वाली Windows-specific settings। अगर unspecified हो, तो container के SecurityContext के भीतर दिए गए options उपयोग किए जाएंगे। |
|
||||
|
||||
## SecurityContext
|
||||
|
||||
[**From the docs:**](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core)
|
||||
|
||||
यह context **containers definitions** के अंदर set किया जाता है। defensive security point of view से आपको consider करना चाहिए:
|
||||
यह context **containers definitions** के अंदर set किया जाता है। defensive security के दृष्टिकोण से आपको यह विचार करना चाहिए:
|
||||
|
||||
- **allowPrivilegeEscalation** को **False** रखना
|
||||
- sensitive **capabilities** न जोड़ें (और जो ज़रूरी नहीं हैं उन्हें remove करें)
|
||||
- sensitive **capabilities** add न करें (और जो ज़रूरी नहीं हैं उन्हें remove करें)
|
||||
- **privileged** को **False** रखना
|
||||
- यदि संभव हो, तो **readOnlyFilesystem** को **True** set करना
|
||||
- **runAsNonRoot** को **True** set करें और एक **runAsUser** set करें
|
||||
- यदि संभव हो, तो **seLinuxOptions** और **seccompProfile** बताकर **permissions** को **limit** करना
|
||||
- **runAsGroup** के जरिए **privilege** **group** access **NOT** देना
|
||||
- यदि संभव हो, तो **readOnlyFilesystem** को **True** सेट करें
|
||||
- **runAsNonRoot** को **True** सेट करें और एक **runAsUser** सेट करें
|
||||
- यदि संभव हो, तो **seLinuxOptions** और **seccompProfile** बताकर **permissions** को **limit** करने पर विचार करें
|
||||
- **runAsGroup** के जरिए **privilege** **group** access **NOT** दें।
|
||||
|
||||
ध्यान दें कि **SecurityContext और PodSecurityContext** दोनों में set किए गए attributes के लिए, **SecurityContext** में specified value को **precedence** मिलती है।
|
||||
ध्यान दें कि **SecurityContext** और **PodSecurityContext** दोनों में set किए गए attributes में, **SecurityContext** में specified value को **precedence** मिलती है।
|
||||
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>allowPrivilegeEscalation</strong></a><br><em>boolean</em></p> | **AllowPrivilegeEscalation** यह नियंत्रित करता है कि कोई process अपने parent process से **अधिक privileges** प्राप्त कर सकता है या नहीं। यह bool सीधे नियंत्रित करता है कि container process पर no_new_privs flag set होगा या नहीं। जब container **Privileged** mode में चल रहा हो या उसके पास **CAP_SYS_ADMIN** हो, तब AllowPrivilegeEscalation हमेशा true होता है |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>allowPrivilegeEscalation</strong></a><br><em>boolean</em></p> | **AllowPrivilegeEscalation** नियंत्रित करता है कि क्या कोई process अपने parent process से **ज्यादा privileges** प्राप्त कर सकता है। यह bool सीधे नियंत्रित करता है कि container process पर no_new_privs flag set होगा या नहीं। जब container को **Privileged** रूप में चलाया जाता है या उसके पास **CAP_SYS_ADMIN** हो, तब AllowPrivilegeEscalation हमेशा true होता है |
|
||||
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>capabilities</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#capabilities-v1-core"><em>Capabilities</em></a><br><em>More info about</em> <em><strong>Capabilities</strong></em></p> | containers चलाते समय add/drop करने के लिए **capabilities**। Default capabilities set ही default होता है। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>privileged</strong></a><br><em>boolean</em></p> | container को privileged mode में चलाएं। privileged containers में processes मूल रूप से **host पर root के बराबर** होती हैं। Default false है। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>procMount</strong></a><br><em>string</em></p> | procMount यह दर्शाता है कि containers के लिए **किस प्रकार का proc mount** use करना है। default DefaultProcMount है, जो readonly paths और masked paths के लिए container runtime defaults use करता है। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>capabilities</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#capabilities-v1-core"><em>Capabilities</em></a><br><em>More info about</em> <em><strong>Capabilities</strong></em></p> | container चलाते समय add/drop की जाने वाली **capabilities**। Default set of capabilities default होती हैं। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>privileged</strong></a><br><em>boolean</em></p> | container को privileged mode में चलाएँ। privileged containers में processes essentially host पर **root के equivalent** होती हैं। Default false है। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>procMount</strong></a><br><em>string</em></p> | procMount **containers के लिए किस type का proc mount use होगा** यह दर्शाता है। default DefaultProcMount है, जो readonly paths और masked paths के लिए container runtime defaults use करता है। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>readOnlyRootFilesystem</strong></a><br><em>boolean</em></p> | क्या इस **container का root filesystem read-only** है। Default false है। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>runAsGroup</strong></a><br><em>integer</em></p> | container process का entrypoint चलाने के लिए **GID**। unset होने पर runtime default use होता है। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>runAsNonRoot</strong></a><br><em>boolean</em></p> | बताता है कि container को **non-root user** के रूप में चलना चाहिए। अगर true हो, तो Kubelet runtime पर image validate करेगा ताकि सुनिश्चित हो कि वह UID 0 (root) के रूप में नहीं चलती, और अगर ऐसा है तो container start होने में fail करेगा। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>runAsUser</strong></a><br><em>integer</em></p> | container process का entrypoint चलाने के लिए **UID**। अगर specify न किया हो, तो image metadata में दिए गए user को default माना जाता है। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>seLinuxOptions</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#selinuxoptions-v1-core"><em>SELinuxOptions</em></a><br><em>More info about</em> <em><strong>seLinux</strong></em></p> | container पर apply होने वाला **SELinux context**। अगर specify न हो, तो container runtime हर container के लिए एक random SELinux context allocate करेगा। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>seccompProfile</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#seccompprofile-v1-core"><em>SeccompProfile</em></a></p> | इस container द्वारा use किए जाने वाले **seccomp options**। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>windowsOptions</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#windowssecuritycontextoptions-v1-core"><em>WindowsSecurityContextOptions</em></a></p> | सभी containers पर apply होने वाली **Windows specific settings**। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>runAsGroup</strong></a><br><em>integer</em></p> | container process का entrypoint चलाने के लिए **GID**। अगर unset हो, तो runtime default use होता है। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>runAsNonRoot</strong></a><br><em>boolean</em></p> | यह बताता है कि container को **non-root user** के रूप में चलना चाहिए। अगर true हो, तो Kubelet runtime पर image validate करेगा ताकि सुनिश्चित हो सके कि वह UID 0 (root) के रूप में नहीं चलती, और ऐसा होने पर container start नहीं होगा। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>runAsUser</strong></a><br><em>integer</em></p> | container process का entrypoint चलाने के लिए **UID**। अगर unspecified हो, तो image metadata में specified user default होगा। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>seLinuxOptions</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#selinuxoptions-v1-core"><em>SELinuxOptions</em></a><br><em>More info about</em> <em><strong>seLinux</strong></em></p> | container पर apply किए जाने वाला **SELinux context**। अगर unspecified हो, तो container runtime हर container के लिए एक random SELinux context allocate करेगा। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>seccompProfile</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#seccompprofile-v1-core"><em>SeccompProfile</em></a></p> | इस container के लिए उपयोग किए जाने वाले **seccomp options**। |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>windowsOptions</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#windowssecuritycontextoptions-v1-core"><em>WindowsSecurityContextOptions</em></a></p> | सभी containers पर लागू होने वाली **Windows specific settings**। |
|
||||
|
||||
## Practical workload review checklist
|
||||
|
||||
किसी Pod या workload template की review करते समय, `spec.securityContext` और `containers`, `initContainers`, तथा `ephemeralContainers` के अंदर हर container-level `securityContext` दोनों inspect करें। Container-level fields pod-level defaults को override कर सकते हैं, इसलिए safe दिखने वाला pod default यह guarantee नहीं देता कि हर container safe है।
|
||||
किसी Pod या workload template की समीक्षा करते समय, `spec.securityContext` और `containers`, `initContainers`, तथा `ephemeralContainers` के अंतर्गत हर container-level `securityContext` दोनों inspect करें। Container-level fields, pod-level defaults को override कर सकते हैं, इसलिए सुरक्षित दिखने वाला pod default यह guarantee नहीं करता कि हर container सुरक्षित है।
|
||||
|
||||
High-risk combinations जिन्हें प्राथमिकता देनी चाहिए:
|
||||
|
||||
- `privileged: true`, खासकर `hostPID`, `hostIPC`, `hostNetwork`, `hostPath`, host ports, या runtime socket mounts के साथ।
|
||||
- `SYS_ADMIN`, `NET_ADMIN`, `SYS_PTRACE`, `SYS_MODULE`, `DAC_READ_SEARCH`, या `DAC_OVERRIDE` जैसी added capabilities।
|
||||
- attacker-controlled code execute कर सकने वाले containers में `allowPrivilegeEscalation: true` या unset।
|
||||
- `SYS_ADMIN`, `NET_ADMIN`, `SYS_PTRACE`, `SYS_MODULE`, `DAC_READ_SEARCH`, या `DAC_OVERRIDE` जैसी capabilities add करना।
|
||||
- `allowPrivilegeEscalation: true` या उन containers में unset होना जो attacker-controlled code execute कर सकते हैं।
|
||||
- `seccompProfile: Unconfined`, `procMount: Unmasked`, या sensitive workloads पर missing runtime profiles।
|
||||
- Writable root filesystems या broad writable volume mounts, उन workloads में जो untrusted input process करते हैं।
|
||||
- ऐसे workloads में writable root filesystems या broad writable volume mounts जो untrusted input process करते हैं।
|
||||
- multi-tenant namespaces में CPU, memory, या ephemeral-storage requests और limits का missing होना।
|
||||
- Pod-level `spec.resources` budgets का missing या unrealistic होना, और `patch` या `update` principals का Pod `resize` subresource पर होना, क्योंकि supported clusters Pod recreate किए बिना चल रहे CPU और memory desired state को बदल सकते हैं।
|
||||
|
||||
अधिकांश application workloads के लिए एक अच्छा baseline यह है कि non-root UID के रूप में चलाएं, `runAsNonRoot: true` set करें, `allowPrivilegeEscalation: false` set करें, सभी capabilities drop करें और केवल minimum required ones वापस add करें, `seccompProfile: RuntimeDefault` use करें, read-only root filesystem prefer करें, और host namespaces, hostPath mounts, तथा privileged mode से बचें।
|
||||
Resource controls `securityContext` का हिस्सा नहीं हैं, लेकिन उन्हें उसी workload pass में review करें क्योंकि वे availability boundary define करते हैं। Modern Kubernetes Pod level पर `spec.resources` के तहत CPU, memory, और hugepage budgets define कर सकता है, साथ ही container-level `resources` भी। sidecars वाले Pod को aggregate Pod envelope द्वारा bound किया जा सकता है, भले ही किसी एक container के पास individual limits न हों, जबकि local ephemeral storage को अभी भी अलग `ephemeral-storage` limits, `emptyDir.sizeLimit`, LimitRanges, और ResourceQuotas की जरूरत होती है। साथ ही in-place resize request के बाद Pod spec में desired resources की तुलना `status.containerStatuses[].resources` से करें; failed या pending resize से requested value `spec` में रह सकती है जबकि kubelet previous runtime allocation बनाए रखता है और `PodResizePending` condition report करता है।
|
||||
|
||||
cluster level पर, जहां संभव हो, Kubernetes [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/) को enforce करने के लिए [Pod Security Admission](https://kubernetes.io/docs/concepts/security/pod-security-admission/) namespace labels use करें। जिन namespaces में support हो उनके लिए `restricted` use करें, सामान्य application namespaces के लिए कम से कम `baseline`, और privileged exceptions को narrow, documented, तथा trusted platform namespaces या node pools तक isolated रखें।
|
||||
अधिकांश application workloads के लिए एक अच्छा baseline है non-root UID के रूप में run करना, `runAsNonRoot: true` set करना, `allowPrivilegeEscalation: false` set करना, सभी capabilities drop करना और केवल minimum required ones वापस add करना, `seccompProfile: RuntimeDefault` use करना, read-only root filesystem prefer करना, और host namespaces, hostPath mounts, तथा privileged mode से बचना।
|
||||
|
||||
Cluster level पर, संभव हो तो Kubernetes [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/) को enforce करने के लिए [Pod Security Admission](https://kubernetes.io/docs/concepts/security/pod-security-admission/) namespace labels का उपयोग करें। जो namespaces इसे support कर सकते हैं उनके लिए `restricted` use करें, सामान्य application namespaces के लिए कम से कम `baseline`, और privileged exceptions को narrow, documented, तथा trusted platform namespaces या node pools तक isolated रखें।
|
||||
|
||||
## References
|
||||
|
||||
- [https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core)
|
||||
- [https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core)
|
||||
- [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/configuration/manage-resources-containers/](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/)
|
||||
- [https://kubernetes.io/docs/concepts/security/linux-kernel-security-constraints/](https://kubernetes.io/docs/concepts/security/linux-kernel-security-constraints/)
|
||||
- [https://kubernetes.io/docs/concepts/security/pod-security-standards/](https://kubernetes.io/docs/concepts/security/pod-security-standards/)
|
||||
- [https://kubernetes.io/docs/concepts/security/pod-security-admission/](https://kubernetes.io/docs/concepts/security/pod-security-admission/)
|
||||
- [https://kubernetes.io/docs/tasks/configure-pod-container/assign-pod-level-resources/](https://kubernetes.io/docs/tasks/configure-pod-container/assign-pod-level-resources/)
|
||||
- [https://kubernetes.io/docs/tasks/configure-pod-container/resize-container-resources/](https://kubernetes.io/docs/tasks/configure-pod-container/resize-container-resources/)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user