mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-26 20:54:14 -08:00
Translated ['.github/pull_request_template.md', 'src/README.md', 'src/pe
This commit is contained in:
Translator
@@ -1,18 +1,18 @@
|
||||
# OpenShift Pentesting
|
||||
|
||||
## Basic Information
|
||||
## मूल जानकारी
|
||||
|
||||
{{#ref}}
|
||||
openshift-basic-information.md
|
||||
{{#endref}}
|
||||
|
||||
## Security Context Constraints
|
||||
## सुरक्षा संदर्भ प्रतिबंध
|
||||
|
||||
{{#ref}}
|
||||
openshift-scc.md
|
||||
{{#endref}}
|
||||
|
||||
## Privilege Escalation
|
||||
## विशेषाधिकार वृद्धि
|
||||
|
||||
{{#ref}}
|
||||
openshift-privilege-escalation/
|
||||
|
||||
@@ -1,14 +1,14 @@
|
||||
# OpenShift - Basic information
|
||||
# OpenShift - मूल जानकारी
|
||||
|
||||
## Kubernetes prior b**asic knowledge** <a href="#a94e" id="a94e"></a>
|
||||
## Kubernetes पूर्व b**asic knowledge** <a href="#a94e" id="a94e"></a>
|
||||
|
||||
OpenShift के साथ काम करने से पहले, सुनिश्चित करें कि आप Kubernetes वातावरण के साथ सहज हैं। पूरा OpenShift अध्याय मानता है कि आपके पास Kubernetes का पूर्व ज्ञान है।
|
||||
|
||||
## OpenShift - Basic Information
|
||||
## OpenShift - मूल जानकारी
|
||||
|
||||
### Introduction
|
||||
### परिचय
|
||||
|
||||
OpenShift Red Hat का कंटेनर एप्लिकेशन प्लेटफॉर्म है जो Kubernetes सुविधाओं का एक सुपरसेट प्रदान करता है। OpenShift की सुरक्षा नीतियाँ अधिक कठोर हैं। उदाहरण के लिए, एक कंटेनर को रूट के रूप में चलाना मना है। यह सुरक्षा बढ़ाने के लिए एक सुरक्षित-डिफ़ॉल्ट विकल्प भी प्रदान करता है। OpenShift में एक वेब कंसोल है जिसमें एक टच लॉगिन पृष्ठ शामिल है।
|
||||
OpenShift Red Hat का कंटेनर एप्लिकेशन प्लेटफॉर्म है जो Kubernetes सुविधाओं का एक सुपरसेट प्रदान करता है। OpenShift की सुरक्षा नीतियाँ अधिक कठोर हैं। उदाहरण के लिए, एक कंटेनर को रूट के रूप में चलाना मना है। यह सुरक्षा बढ़ाने के लिए एक सुरक्षित-डिफ़ॉल्ट विकल्प भी प्रदान करता है। OpenShift में एक वेब कंसोल है जिसमें एक-टच लॉगिन पृष्ठ शामिल है।
|
||||
|
||||
#### CLI
|
||||
|
||||
@@ -25,9 +25,9 @@ oc login -s=<server> --token=<bearer token>
|
||||
```
|
||||
### **OpenShift - सुरक्षा संदर्भ प्रतिबंध** <a href="#a94e" id="a94e"></a>
|
||||
|
||||
उस [RBAC संसाधनों](https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#architecture-additional-concepts-authorization) के अलावा जो यह नियंत्रित करते हैं कि एक उपयोगकर्ता क्या कर सकता है, OpenShift कंटेनर प्लेटफॉर्म _सुरक्षा संदर्भ प्रतिबंध_ (SCC) प्रदान करता है जो यह नियंत्रित करते हैं कि एक पॉड क्या क्रियाएँ कर सकता है और इसके पास क्या पहुँच है।
|
||||
उपयोगकर्ता क्या कर सकता है, इसे नियंत्रित करने वाले [RBAC संसाधनों](https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#architecture-additional-concepts-authorization) के अलावा, OpenShift कंटेनर प्लेटफॉर्म _सुरक्षा संदर्भ प्रतिबंध_ (SCC) प्रदान करता है जो यह नियंत्रित करता है कि एक पॉड क्या क्रियाएँ कर सकता है और इसके पास क्या पहुँच है।
|
||||
|
||||
SCC एक नीति वस्तु है जिसमें विशेष नियम होते हैं जो बुनियादी ढाँचे के साथ मेल खाते हैं, जबकि RBAC के नियम प्लेटफॉर्म के साथ मेल खाते हैं। यह हमें यह परिभाषित करने में मदद करता है कि कंटेनर को कौन से लिनक्स एक्सेस-नियंत्रण सुविधाओं का अनुरोध/चलाने की अनुमति होनी चाहिए। उदाहरण: लिनक्स क्षमताएँ, SECCOMP प्रोफाइल, लोकलहोस्ट डिर्स को माउंट करना, आदि।
|
||||
SCC एक नीति वस्तु है जिसमें विशेष नियम होते हैं जो बुनियादी ढाँचे के साथ मेल खाते हैं, जबकि RBAC के नियम प्लेटफॉर्म के साथ मेल खाते हैं। यह हमें यह परिभाषित करने में मदद करता है कि कंटेनर को कौन से लिनक्स एक्सेस-नियंत्रण सुविधाएँ अनुरोध/चलाने की अनुमति होनी चाहिए। उदाहरण: लिनक्स क्षमताएँ, SECCOMP प्रोफाइल, लोकलहोस्ट डिर्स को माउंट करना, आदि।
|
||||
|
||||
{{#ref}}
|
||||
openshift-scc.md
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
## अस्वीकरण
|
||||
|
||||
Jenkins इंस्टेंस को Openshift या Kubernetes क्लस्टर में तैनात किया जा सकता है। आपके संदर्भ के आधार पर, आपको किसी भी दिखाए गए पेलोड, yaml या तकनीक को अनुकूलित करने की आवश्यकता हो सकती है। Jenkins पर हमले के बारे में अधिक जानकारी के लिए, आप [इस पृष्ठ](../../../pentesting-ci-cd/jenkins-security/) को देख सकते हैं।
|
||||
Jenkins इंस्टेंस को Openshift या Kubernetes क्लस्टर में तैनात किया जा सकता है। आपके संदर्भ के आधार पर, आपको दिखाए गए किसी भी पेलोड, yaml या तकनीक को अनुकूलित करने की आवश्यकता हो सकती है। Jenkins पर हमले के बारे में अधिक जानकारी के लिए, आप [इस पृष्ठ](../../../pentesting-ci-cd/jenkins-security/) को देख सकते हैं।
|
||||
|
||||
## पूर्वापेक्षाएँ
|
||||
|
||||
@@ -18,7 +18,7 @@ Jenkins इंस्टेंस को Openshift या Kubernetes क्लस
|
||||
|
||||
### निर्माण
|
||||
|
||||
जब एक निर्माण ट्रिगर होता है, तो इसे पहले Jenkins मास्टर नोड द्वारा प्रबंधित/संयोजित किया जाता है और फिर एक एजेंट/स्लेव/वर्कर को सौंपा जाता है। इस संदर्भ में, मास्टर नोड बस एक नियमित पॉड है जो एक नामस्थान में चल रहा है (जो कि उस नामस्थान से भिन्न हो सकता है जहां वर्कर चलते हैं)। यही बात वर्कर्स/स्लेव्स पर भी लागू होती है, हालाँकि वे निर्माण समाप्त होने के बाद नष्ट हो जाते हैं जबकि मास्टर हमेशा चालू रहता है। आपका निर्माण आमतौर पर एक पॉड के अंदर चलाया जाता है, जो Jenkins प्रशासकों द्वारा परिभाषित डिफ़ॉल्ट पॉड टेम्पलेट का उपयोग करता है।
|
||||
जब एक निर्माण ट्रिगर होता है, तो इसे पहले Jenkins मास्टर नोड द्वारा प्रबंधित/संयोजित किया जाता है और फिर एक एजेंट/स्लेव/वर्कर को सौंपा जाता है। इस संदर्भ में, मास्टर नोड बस एक नियमित पॉड है जो एक नामस्थान में चल रहा है (जो उस नामस्थान से भिन्न हो सकता है जहां वर्कर चलते हैं)। यही बात वर्कर्स/स्लेव्स पर भी लागू होती है, हालाँकि वे निर्माण समाप्त होने के बाद नष्ट हो जाते हैं जबकि मास्टर हमेशा चालू रहता है। आपका निर्माण आमतौर पर एक पॉड के अंदर चलता है, जो Jenkins प्रशासकों द्वारा परिभाषित डिफ़ॉल्ट पॉड टेम्पलेट का उपयोग करता है।
|
||||
|
||||
### निर्माण को ट्रिगर करना
|
||||
|
||||
@@ -26,9 +26,9 @@ Jenkins इंस्टेंस को Openshift या Kubernetes क्लस
|
||||
|
||||
1. आपके पास Jenkins तक UI पहुंच है
|
||||
|
||||
एक बहुत आसान और सुविधाजनक तरीका है एक मौजूदा निर्माण की पुनरावृत्ति कार्यक्षमता का उपयोग करना। यह आपको एक पूर्व निष्पादित निर्माण को पुनः चलाने की अनुमति देता है जबकि आपको ग्रूवी स्क्रिप्ट को अपडेट करने की अनुमति देता है। इसके लिए Jenkins फ़ोल्डर पर विशेषाधिकार और एक पूर्व निर्धारित पाइपलाइन की आवश्यकता होती है। यदि आपको छिपकर काम करना है, तो आप अपनी ट्रिगर की गई निर्माणों को हटा सकते हैं यदि आपके पास पर्याप्त अनुमति है।
|
||||
एक बहुत आसान और सुविधाजनक तरीका है मौजूदा निर्माण की पुनरावृत्ति कार्यक्षमता का उपयोग करना। यह आपको एक पूर्व निष्पादित निर्माण को पुनः चलाने की अनुमति देता है जबकि आपको ग्रोवी स्क्रिप्ट को अपडेट करने की अनुमति देता है। इसके लिए Jenkins फ़ोल्डर पर विशेषाधिकार और एक पूर्व निर्धारित पाइपलाइन की आवश्यकता होती है। यदि आपको छिपकर काम करना है, तो आप अपनी ट्रिगर की गई निर्माणों को हटा सकते हैं यदि आपके पास पर्याप्त अनुमति है।
|
||||
|
||||
2. आपके पास SCM पर लिखने की पहुंच है और स्वचालित निर्माण वेबहुक के माध्यम से कॉन्फ़िगर किए गए हैं
|
||||
2. आपके पास SCM में लिखने की पहुंच है और स्वचालित निर्माण वेबहुक के माध्यम से कॉन्फ़िगर किए गए हैं
|
||||
|
||||
आप बस एक निर्माण स्क्रिप्ट (जैसे Jenkinsfile) को संपादित कर सकते हैं, कमिट कर सकते हैं और पुश कर सकते हैं (यदि निर्माण केवल PR मर्ज पर ट्रिगर होते हैं तो अंततः एक PR बना सकते हैं)। ध्यान रखें कि यह मार्ग बहुत शोर करता है और आपके निशान साफ़ करने के लिए उच्च विशेषाधिकार की आवश्यकता होती है।
|
||||
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
**इस पृष्ठ के मूल लेखक हैं** [**Fares**](https://www.linkedin.com/in/fares-siala/)
|
||||
|
||||
## Kubernetes plugin for Jenkins
|
||||
यह प्लगइन ज्यादातर openshift/kubernetes क्लस्टर के अंदर Jenkins के मुख्य कार्यों के लिए जिम्मेदार है। आधिकारिक दस्तावेज़ [यहाँ](https://plugins.jenkins.io/kubernetes/) है।
|
||||
यह प्लगइन ज्यादातर openshift/kubernetes क्लस्टर के अंदर Jenkins के मुख्य कार्यों के लिए जिम्मेदार है। आधिकारिक दस्तावेज़ [यहां](https://plugins.jenkins.io/kubernetes/) है।
|
||||
यह कुछ कार्यात्मकताएँ प्रदान करता है जैसे कि डेवलपर्स को जेनकिंस बिल्ड पॉड की कुछ डिफ़ॉल्ट कॉन्फ़िगरेशन को ओवरराइड करने की क्षमता।
|
||||
|
||||
## Core functionnality
|
||||
@@ -36,7 +36,7 @@ sh 'mvn -B -ntp clean install'
|
||||
```
|
||||
## Some abuses leveraging pod yaml override
|
||||
|
||||
यह किसी भी सुलभ इमेज जैसे कि Kali Linux का उपयोग करने के लिए दुरुपयोग किया जा सकता है और उस इमेज से प्रीइंस्टॉल्ड टूल्स का उपयोग करके मनमाने कमांड निष्पादित किया जा सकता है।
|
||||
हालांकि, इसका दुरुपयोग किसी भी सुलभ इमेज जैसे Kali Linux का उपयोग करने और उस इमेज से प्रीइंस्टॉल्ड टूल्स का उपयोग करके मनमाने कमांड निष्पादित करने के लिए किया जा सकता है।
|
||||
नीचे दिए गए उदाहरण में, हम चल रहे पॉड के सर्विसएकाउंट टोकन को एक्सफिल्ट्रेट कर सकते हैं।
|
||||
```groovy
|
||||
podTemplate(yaml: '''
|
||||
@@ -128,7 +128,7 @@ sh 'env'
|
||||
}
|
||||
}
|
||||
```
|
||||
एक और उदाहरण जो एक serviceaccount को माउंट करने की कोशिश करता है (जिसके पास आपके बिल्ड को चलाने वाले डिफ़ॉल्ट वाले की तुलना में अधिक अनुमतियाँ हो सकती हैं) इसके नाम के आधार पर। आपको पहले मौजूदा serviceaccounts का अनुमान लगाने या उन्हें सूचीबद्ध करने की आवश्यकता हो सकती है।
|
||||
एक और उदाहरण जो एक serviceaccount को माउंट करने की कोशिश करता है (जिसके पास आपके बिल्ड को चलाने वाले डिफ़ॉल्ट वाले से अधिक अनुमतियाँ हो सकती हैं) इसके नाम के आधार पर। आपको पहले मौजूदा serviceaccounts का अनुमान लगाने या उन्हें सूचीबद्ध करने की आवश्यकता हो सकती है।
|
||||
```groovy
|
||||
pipeline {
|
||||
stages {
|
||||
@@ -161,29 +161,29 @@ sh 'env'
|
||||
}
|
||||
}
|
||||
```
|
||||
The same technique applies to try mounting a Secret. The end goal here would be to figure out how to configure your pod build to effectively pivot or gain privileges.
|
||||
समान तकनीक एक Secret को माउंट करने के लिए लागू होती है। यहाँ अंतिम लक्ष्य यह होगा कि आप अपने पोड निर्माण को प्रभावी ढंग से पिवट या विशेषाधिकार प्राप्त करने के लिए कैसे कॉन्फ़िगर करें।
|
||||
|
||||
## Going further
|
||||
## आगे बढ़ना
|
||||
|
||||
Once you get used to play around with it, use your knowledge on Jenkins and Kubernetes/Openshift to find misconfigurations / abuses.
|
||||
एक बार जब आप इसके साथ खेलने के लिए अभ्यस्त हो जाते हैं, तो जेनकिंस और कुबेरनेट्स/ओपनशिफ्ट पर अपने ज्ञान का उपयोग करें ताकि गलत कॉन्फ़िगरेशन/दुरुपयोग खोज सकें।
|
||||
|
||||
Ask yourself the following questions:
|
||||
अपने आप से निम्नलिखित प्रश्न पूछें:
|
||||
|
||||
- Which सेवा खाता is being used to deploy build pods?
|
||||
- What roles and permissions does it have? Can it read secrets of the namespace I am currently in?
|
||||
- Can I further enumerate other build pods?
|
||||
- From a compromised sa, can I execute commands on the master node/pod?
|
||||
- Can I further enumerate the cluster to pivot elsewhere?
|
||||
- Which SCC is applied?
|
||||
- किस सेवा खाते का उपयोग निर्माण पोड को तैनात करने के लिए किया जा रहा है?
|
||||
- इसके पास कौन से भूमिकाएँ और अनुमतियाँ हैं? क्या यह उस नामस्थान के रहस्यों को पढ़ सकता है जिसमें मैं वर्तमान में हूँ?
|
||||
- क्या मैं अन्य निर्माण पोड को और अधिक सूचीबद्ध कर सकता हूँ?
|
||||
- एक समझौता किए गए sa से, क्या मैं मास्टर नोड/पोड पर कमांड निष्पादित कर सकता हूँ?
|
||||
- क्या मैं क्लस्टर को और अधिक सूचीबद्ध कर सकता हूँ ताकि कहीं और पिवट कर सकूँ?
|
||||
- कौन सा SCC लागू है?
|
||||
|
||||
You can find out which oc/kubectl commands to issue [here](../openshift-basic-information.md) and [here](../../kubernetes-security/kubernetes-enumeration.md).
|
||||
आप यह पता लगा सकते हैं कि कौन से oc/kubectl कमांड जारी करने हैं [यहाँ](../openshift-basic-information.md) और [यहाँ](../../kubernetes-security/kubernetes-enumeration.md)।
|
||||
|
||||
### Possible privesc/pivoting scenarios
|
||||
### संभावित privesc/pivoting परिदृश्य
|
||||
|
||||
Let's assume that during your assessment you found out that all jenkins builds run inside a namespace called _worker-ns_. You figured out that a default serviceaccount called _default-sa_ is mounted on the build pods, however it does not have so many permissions except read access on some resources but you were able to identify an existing service account called _master-sa_.
|
||||
Let's also assume that you have the oc command installed inside the running build container.
|
||||
मान लीजिए कि आपकी मूल्यांकन के दौरान आपको पता चला कि सभी जेनकिंस निर्माण एक नामस्थान में चल रहे हैं जिसे _worker-ns_ कहा जाता है। आपने यह पता लगाया कि एक डिफ़ॉल्ट सेवा खाता जिसे _default-sa_ कहा जाता है, निर्माण पोड पर माउंट किया गया है, हालाँकि इसके पास कुछ संसाधनों पर पढ़ने की पहुँच के अलावा इतनी अनुमतियाँ नहीं हैं लेकिन आप एक मौजूदा सेवा खाते को पहचानने में सक्षम थे जिसे _master-sa_ कहा जाता है।
|
||||
मान लीजिए कि आपके पास चल रहे निर्माण कंटेनर के अंदर oc कमांड स्थापित है।
|
||||
|
||||
With the below build script you can take control of the _master-sa_ serviceaccount and enumerate further.
|
||||
नीचे दिए गए निर्माण स्क्रिप्ट के साथ आप _master-sa_ सेवा खाते पर नियंत्रण प्राप्त कर सकते हैं और आगे सूचीबद्ध कर सकते हैं।
|
||||
```groovy
|
||||
pipeline {
|
||||
stages {
|
||||
@@ -220,11 +220,11 @@ sh 'oc --token=$token whoami'
|
||||
```bash
|
||||
oc login --token=$token --server=https://apiserver.com:port
|
||||
```
|
||||
यदि इस sa के पास पर्याप्त अनुमति है (जैसे pod/exec), तो आप मास्टर नोड पॉड के अंदर कमांड निष्पादित करके पूरे jenkins इंस्टेंस पर नियंत्रण भी ले सकते हैं, यदि यह उसी namespace के भीतर चल रहा है। आप आसानी से इस पॉड की पहचान इसके नाम और इस तथ्य के माध्यम से कर सकते हैं कि इसे jenkins डेटा संग्रहीत करने के लिए उपयोग किए जाने वाले PVC (persistant volume claim) को माउंट करना चाहिए।
|
||||
यदि इस sa के पास पर्याप्त अनुमति है (जैसे pod/exec), तो आप मास्टर नोड पॉड के अंदर कमांड निष्पादित करके पूरे jenkins इंस्टेंस पर नियंत्रण प्राप्त कर सकते हैं, यदि यह उसी namespace के भीतर चल रहा है। आप इसके नाम और इस तथ्य के माध्यम से इस पॉड की पहचान आसानी से कर सकते हैं कि इसे jenkins डेटा संग्रहीत करने के लिए उपयोग किए जाने वाले PVC (persistant volume claim) को माउंट करना चाहिए।
|
||||
```bash
|
||||
oc rsh pod_name -c container_name
|
||||
```
|
||||
यदि मास्टर नोड पॉड उसी नामस्थान में नहीं चल रहा है जैसे कि श्रमिक, तो आप मास्टर नामस्थान को लक्षित करके समान हमले करने की कोशिश कर सकते हैं। मान लीजिए कि इसे _jenkins-master_ कहा जाता है। ध्यान रखें कि सेवा खाता master-sa _jenkins-master_ नामस्थान में होना चाहिए (और यह _worker-ns_ नामस्थान में नहीं हो सकता है)
|
||||
यदि मास्टर नोड पॉड उसी नामस्थान में नहीं चल रहा है जैसे कि कार्यकर्ता, तो आप मास्टर नामस्थान को लक्षित करके समान हमले करने की कोशिश कर सकते हैं। मान लीजिए कि इसे _jenkins-master_ कहा जाता है। ध्यान रखें कि सेवा खाता master-sa _jenkins-master_ नामस्थान में होना चाहिए (और यह _worker-ns_ नामस्थान में नहीं हो सकता है)
|
||||
```groovy
|
||||
pipeline {
|
||||
stages {
|
||||
|
||||
@@ -1,18 +1,18 @@
|
||||
# OpenShift - Privilege Escalation
|
||||
# OpenShift - विशेषाधिकार वृद्धि
|
||||
|
||||
## Missing Service Account
|
||||
## सेवा खाता गायब
|
||||
|
||||
{{#ref}}
|
||||
openshift-missing-service-account.md
|
||||
{{#endref}}
|
||||
|
||||
## Tekton
|
||||
## टेकटन
|
||||
|
||||
{{#ref}}
|
||||
openshift-tekton.md
|
||||
{{#endref}}
|
||||
|
||||
## SCC Bypass
|
||||
## SCC बायपास
|
||||
|
||||
{{#ref}}
|
||||
openshift-scc-bypass.md
|
||||
|
||||
@@ -2,13 +2,13 @@
|
||||
|
||||
## Missing Service Account
|
||||
|
||||
यह होता है कि क्लस्टर एक पूर्व-निर्धारित टेम्पलेट के साथ तैनात किया गया है जो स्वचालित रूप से Roles, RoleBindings और यहां तक कि SCC को उस सेवा खाते के लिए सेट करता है जो अभी तक बनाया नहीं गया है। यदि आप उन्हें बना सकते हैं तो यह विशेषाधिकार वृद्धि का कारण बन सकता है। इस मामले में, आप नए बनाए गए SA का टोकन और संबंधित भूमिका या SCC प्राप्त कर सकेंगे। वही मामला तब होता है जब गायब SA एक गायब प्रोजेक्ट का हिस्सा होता है, इस मामले में यदि आप प्रोजेक्ट बना सकते हैं और फिर SA बना सकते हैं, तो आप संबंधित Roles और SCC प्राप्त करते हैं।
|
||||
यह होता है कि क्लस्टर को पूर्व-निर्धारित टेम्पलेट के साथ तैनात किया गया है जो स्वचालित रूप से Roles, RoleBindings और यहां तक कि SCC को सेवा खाते के लिए सेट करता है जो अभी तक बनाया नहीं गया है। यदि आप उन्हें बना सकते हैं तो यह विशेषाधिकार वृद्धि का कारण बन सकता है। इस मामले में, आप नए बनाए गए SA का टोकन और संबंधित भूमिका या SCC प्राप्त कर सकेंगे। समान मामला तब होता है जब गायब SA एक गायब प्रोजेक्ट का हिस्सा होता है, इस मामले में यदि आप प्रोजेक्ट बना सकते हैं और फिर SA बना सकते हैं, तो आप संबंधित Roles और SCC प्राप्त करते हैं।
|
||||
|
||||
<figure><img src="../../../images/openshift-missing-service-account-image1.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
पिछले ग्राफ में हमें कई AbsentProject मिले, जिसका अर्थ है कि कई प्रोजेक्ट जो Roles Bindings या SCC में दिखाई देते हैं लेकिन अभी तक क्लस्टर में बनाए नहीं गए हैं। उसी संदर्भ में हमें एक AbsentServiceAccount भी मिला।
|
||||
पिछले ग्राफ में हमारे पास कई AbsentProject हैं जिसका अर्थ है कि कई प्रोजेक्ट हैं जो Roles Bindings या SCC में दिखाई देते हैं लेकिन अभी तक क्लस्टर में बनाए नहीं गए हैं। उसी संदर्भ में हमारे पास एक AbsentServiceAccount भी है।
|
||||
|
||||
यदि हम एक प्रोजेक्ट और उसमें गायब SA बना सकते हैं, तो SA उस भूमिका या SCC से विरासत में मिलेगा जो AbsentServiceAccount को लक्षित कर रहे थे। जो विशेषाधिकार वृद्धि का कारण बन सकता है।
|
||||
यदि हम एक प्रोजेक्ट और उसमें गायब SA बना सकते हैं, तो SA उस भूमिका या SCC से विरासत में मिलेगा जो AbsentServiceAccount को लक्षित कर रहा था। जो विशेषाधिकार वृद्धि का कारण बन सकता है।
|
||||
|
||||
निम्नलिखित उदाहरण एक गायब SA को दिखाता है जिसे node-exporter SCC दिया गया है:
|
||||
|
||||
@@ -16,7 +16,7 @@
|
||||
|
||||
## Tools
|
||||
|
||||
इस समस्या को सूचीबद्ध करने और सामान्य रूप से एक OpenShift क्लस्टर को ग्राफ करने के लिए निम्नलिखित उपकरण का उपयोग किया जा सकता है:
|
||||
इस समस्या को सूचीबद्ध करने और सामान्य रूप से OpenShift क्लस्टर को ग्राफ करने के लिए निम्नलिखित उपकरण का उपयोग किया जा सकता है:
|
||||
|
||||
{{#ref}}
|
||||
https://github.com/maxDcb/OpenShiftGrapher
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
**इस पृष्ठ के मूल लेखक हैं** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
|
||||
|
||||
## विशेषाधिकार प्राप्त नामस्थान
|
||||
## Privileged Namespaces
|
||||
|
||||
डिफ़ॉल्ट रूप से, SCC निम्नलिखित परियोजनाओं पर लागू नहीं होता है:
|
||||
|
||||
@@ -13,14 +13,14 @@
|
||||
- **openshift-infra**
|
||||
- **openshift**
|
||||
|
||||
यदि आप इन नामस्थानों में से किसी एक में पॉड्स तैनात करते हैं, तो कोई SCC लागू नहीं होगा, जिससे विशेषाधिकार प्राप्त पॉड्स की तैनाती या होस्ट फ़ाइल प्रणाली को माउंट करने की अनुमति मिलती है।
|
||||
यदि आप इन नामस्थान में पॉड्स तैनात करते हैं, तो कोई SCC लागू नहीं होगा, जिससे विशेषाधिकार प्राप्त पॉड्स की तैनाती या होस्ट फ़ाइल सिस्टम को माउंट करने की अनुमति मिलेगी।
|
||||
|
||||
## नामस्थान लेबल
|
||||
## Namespace Label
|
||||
|
||||
RedHat दस्तावेज़ के अनुसार, आपके पॉड पर SCC आवेदन को अक्षम करने का एक तरीका है। आपको निम्नलिखित में से कम से कम एक अनुमति होनी चाहिए:
|
||||
RedHat दस्तावेज़ के अनुसार, आपके पॉड पर SCC एप्लिकेशन को अक्षम करने का एक तरीका है। आपको निम्नलिखित में से कम से कम एक अनुमति होनी चाहिए:
|
||||
|
||||
- एक नामस्थान बनाना और इस नामस्थान पर एक पॉड बनाना
|
||||
- एक नामस्थान संपादित करना और इस नामस्थान पर एक पॉड बनाना
|
||||
- एक Namespace बनाना और इस Namespace पर एक Pod बनाना
|
||||
- एक Namespace को संपादित करना और इस Namespace पर एक Pod बनाना
|
||||
```bash
|
||||
$ oc auth can-i create namespaces
|
||||
yes
|
||||
@@ -28,7 +28,7 @@ yes
|
||||
$ oc auth can-i patch namespaces
|
||||
yes
|
||||
```
|
||||
विशिष्ट लेबल `openshift.io/run-level` उपयोगकर्ताओं को अनुप्रयोगों के लिए SCCs को दरकिनार करने की अनुमति देता है। RedHat दस्तावेज़ के अनुसार, जब इस लेबल का उपयोग किया जाता है, तो उस नामस्थान के भीतर सभी पॉड्स पर कोई SCCs लागू नहीं होते, प्रभावी रूप से किसी भी प्रतिबंध को हटा दिया जाता है।
|
||||
विशिष्ट लेबल `openshift.io/run-level` उपयोगकर्ताओं को अनुप्रयोगों के लिए SCCs को दरकिनार करने की अनुमति देता है। RedHat दस्तावेज़ के अनुसार, जब इस लेबल का उपयोग किया जाता है, तो उस नामस्थान के सभी पॉड्स पर कोई SCCs लागू नहीं होते हैं, प्रभावी रूप से किसी भी प्रतिबंध को हटा देते हैं।
|
||||
|
||||
<figure><img src="../../../images/Openshift-RunLevel4.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -38,7 +38,7 @@ yes
|
||||
```bash
|
||||
$ oc label ns MYNAMESPACE openshift.io/run-level=0
|
||||
```
|
||||
एक YAML फ़ाइल के माध्यम से लेबल के साथ एक नामस्थान बनाने के लिए:
|
||||
YAML फ़ाइल के माध्यम से लेबल के साथ एक नामस्थान बनाने के लिए:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Namespace
|
||||
@@ -86,7 +86,7 @@ volumes:
|
||||
hostPath:
|
||||
path:
|
||||
```
|
||||
अब, होस्ट सिस्टम तक पहुँचने के लिए विशेषाधिकारों को बढ़ाना और इसके बाद पूरे क्लस्टर पर नियंत्रण प्राप्त करना, 'cluster-admin' विशेषाधिकार प्राप्त करना आसान हो गया है। निम्नलिखित पृष्ठ में **Node-Post Exploitation** भाग देखें:
|
||||
अब, होस्ट सिस्टम तक पहुंच के लिए विशेषाधिकार बढ़ाना और इसके बाद पूरे क्लस्टर पर नियंत्रण प्राप्त करना, 'cluster-admin' विशेषाधिकार प्राप्त करना आसान हो गया है। निम्नलिखित पृष्ठ में **Node-Post Exploitation** भाग देखें:
|
||||
|
||||
{{#ref}}
|
||||
../../kubernetes-security/attacking-kubernetes-from-inside-a-pod.md
|
||||
@@ -94,9 +94,9 @@ path:
|
||||
|
||||
### कस्टम लेबल
|
||||
|
||||
इसके अलावा, लक्षित सेटअप के आधार पर, कुछ कस्टम लेबल / एनोटेशन का उपयोग पिछले हमले के परिदृश्य के समान किया जा सकता है। भले ही इसे इसके लिए नहीं बनाया गया हो, लेबल का उपयोग अनुमतियाँ देने, किसी विशेष संसाधन को प्रतिबंधित करने या न करने के लिए किया जा सकता है।
|
||||
इसके अलावा, लक्षित सेटअप के आधार पर, कुछ कस्टम लेबल / एनोटेशन का उपयोग पिछले हमले के परिदृश्य के समान किया जा सकता है। भले ही इसे इसके लिए नहीं बनाया गया हो, लेबल का उपयोग अनुमतियों को देने, किसी विशेष संसाधन को प्रतिबंधित करने या नहीं करने के लिए किया जा सकता है।
|
||||
|
||||
यदि आप कुछ संसाधनों को पढ़ सकते हैं तो कस्टम लेबल की तलाश करें। यहाँ कुछ दिलचस्प संसाधनों की सूची है:
|
||||
यदि आप कुछ संसाधनों को पढ़ सकते हैं तो कस्टम लेबल की तलाश करने का प्रयास करें। यहाँ कुछ दिलचस्प संसाधनों की सूची है:
|
||||
|
||||
- Pod
|
||||
- Deployment
|
||||
@@ -113,11 +113,11 @@ $ oc get project -o yaml | grep 'run-level' -b5
|
||||
```
|
||||
## Advanced exploit
|
||||
|
||||
OpenShift में, जैसा कि पहले दिखाया गया, `openshift.io/run-level` लेबल के साथ एक नामस्थान में एक पॉड को तैनात करने की अनुमति होने से क्लस्टर का सीधा अधिग्रहण हो सकता है। क्लस्टर सेटिंग्स के दृष्टिकोण से, यह कार्यक्षमता **निष्क्रिय नहीं की जा सकती**, क्योंकि यह OpenShift के डिज़ाइन में अंतर्निहित है।
|
||||
OpenShift में, जैसा कि पहले दिखाया गया है, एक namespace में `openshift.io/run-level` लेबल के साथ pod को तैनात करने की अनुमति होना क्लस्टर का सीधा अधिग्रहण करने की ओर ले जा सकता है। क्लस्टर सेटिंग्स के दृष्टिकोण से, यह कार्यक्षमता **अक्षम नहीं की जा सकती**, क्योंकि यह OpenShift के डिज़ाइन में अंतर्निहित है।
|
||||
|
||||
हालांकि, **Open Policy Agent GateKeeper** जैसी शमन उपाय उपयोगकर्ताओं को इस लेबल को सेट करने से रोक सकते हैं।
|
||||
|
||||
GateKeeper के नियमों को बायपास करने और क्लस्टर अधिग्रहण को निष्पादित करने के लिए इस लेबल को सेट करने के लिए, **हमलावरों को वैकल्पिक तरीकों की पहचान करने की आवश्यकता होगी।**
|
||||
GateKeeper के नियमों को बायपास करने और क्लस्टर अधिग्रहण को निष्पादित करने के लिए इस लेबल को सेट करने के लिए, **हमलावरों को वैकल्पिक तरीकों की पहचान करनी होगी।**
|
||||
|
||||
## References
|
||||
|
||||
|
||||
@@ -4,11 +4,11 @@
|
||||
|
||||
### Tekton क्या है
|
||||
|
||||
दस्तावेज़ के अनुसार: _Tekton एक शक्तिशाली और लचीला ओपन-सोर्स ढांचा है जो CI/CD सिस्टम बनाने के लिए है, जिससे डेवलपर्स क्लाउड प्रदाताओं और ऑन-प्रिमाइस सिस्टम पर निर्माण, परीक्षण और तैनाती कर सकते हैं।_ Jenkins और Tekton दोनों का उपयोग एप्लिकेशन का परीक्षण, निर्माण और तैनाती के लिए किया जा सकता है, हालाँकि Tekton क्लाउड नेटिव है। 
|
||||
दस्तावेज़ के अनुसार: _Tekton एक शक्तिशाली और लचीला ओपन-सोर्स ढांचा है जो CI/CD सिस्टम बनाने के लिए है, जिससे डेवलपर्स क्लाउड प्रदाताओं और ऑन-प्रिमाइस सिस्टम पर निर्माण, परीक्षण और तैनाती कर सकते हैं।_ Jenkins और Tekton दोनों का उपयोग अनुप्रयोगों का परीक्षण, निर्माण और तैनाती के लिए किया जा सकता है, हालाँकि Tekton क्लाउड नेटिव है। 
|
||||
|
||||
Tekton के साथ सब कुछ YAML फ़ाइलों द्वारा दर्शाया जाता है। डेवलपर्स `Pipelines` प्रकार के कस्टम संसाधन (CR) बना सकते हैं और उनमें कई `Tasks` निर्दिष्ट कर सकते हैं जिन्हें वे चलाना चाहते हैं। एक Pipeline चलाने के लिए `PipelineRun` प्रकार के संसाधन बनाए जाने चाहिए।
|
||||
|
||||
जब tekton स्थापित किया जाता है, तो हर namespace में एक सेवा खाता (sa) बनाया जाता है जिसे pipeline कहा जाता है। जब एक Pipeline चलाई जाती है, तो YAML फ़ाइल में परिभाषित कार्यों को चलाने के लिए इस sa का उपयोग करके एक pod उत्पन्न किया जाएगा जिसे `pipeline` कहा जाता है।
|
||||
जब tekton स्थापित होता है, तो हर namespace में एक सेवा खाता (sa) बनाया जाता है जिसे pipeline कहा जाता है। जब एक Pipeline चलाई जाती है, तो YAML फ़ाइल में परिभाषित कार्यों को चलाने के लिए इस sa का उपयोग करके एक pod उत्पन्न किया जाएगा जिसे `pipeline` कहा जाता है।
|
||||
|
||||
{{#ref}}
|
||||
https://tekton.dev/docs/getting-started/pipelines/
|
||||
@@ -16,7 +16,7 @@ https://tekton.dev/docs/getting-started/pipelines/
|
||||
|
||||
### Pipeline सेवा खाता क्षमताएँ
|
||||
|
||||
डिफ़ॉल्ट रूप से, pipeline सेवा खाता `pipelines-scc` क्षमता का उपयोग कर सकता है। यह tekton की वैश्विक डिफ़ॉल्ट कॉन्फ़िगरेशन के कारण है। वास्तव में, tekton की वैश्विक कॉन्फ़िगरेशन भी एक YAML है जो एक openshift ऑब्जेक्ट में `TektonConfig` कहा जाता है जिसे आप क्लस्टर में कुछ रीडर भूमिकाएँ होने पर देख सकते हैं।
|
||||
डिफ़ॉल्ट रूप से, pipeline सेवा खाता `pipelines-scc` क्षमता का उपयोग कर सकता है। यह tekton की वैश्विक डिफ़ॉल्ट कॉन्फ़िगरेशन के कारण है। वास्तव में, tekton की वैश्विक कॉन्फ़िगरेशन भी एक YAML है जो एक openshift ऑब्जेक्ट में है जिसे `TektonConfig` कहा जाता है जिसे आप क्लस्टर में कुछ रीडर भूमिकाएँ होने पर देख सकते हैं।
|
||||
```yaml
|
||||
apiVersion: operator.tekton.dev/v1alpha1
|
||||
kind: TektonConfig
|
||||
@@ -43,17 +43,17 @@ name: test-namespace
|
||||
annotations:
|
||||
operator.tekton.dev/scc: privileged
|
||||
```
|
||||
The tekton operator will give to the pipeline service account in `test-namespace` the ability to use the scc privileged. This will allow the mounting of the node.
|
||||
tekton ऑपरेटर `test-namespace` में पाइपलाइन सेवा खाते को scc privileged का उपयोग करने की क्षमता देगा। इससे नोड को माउंट करने की अनुमति मिलेगी।
|
||||
|
||||
### The fix
|
||||
### समाधान
|
||||
|
||||
Tekton documents about how to restrict the override of scc by adding a label in the `TektonConfig` object.
|
||||
Tekton दस्तावेज़ों में `TektonConfig` ऑब्जेक्ट में लेबल जोड़कर scc के ओवरराइड को प्रतिबंधित करने के बारे में बताया गया है।
|
||||
|
||||
{{#ref}}
|
||||
https://tekton.dev/docs/operator/sccconfig/
|
||||
{{#endref}}
|
||||
|
||||
This label is called `max-allowed` 
|
||||
इस लेबल को `max-allowed` कहा जाता है।
|
||||
```yaml
|
||||
apiVersion: operator.tekton.dev/v1alpha1
|
||||
kind: TektonConfig
|
||||
|
||||
@@ -4,14 +4,14 @@
|
||||
|
||||
## परिभाषा
|
||||
|
||||
OpenShift के संदर्भ में, SCC का अर्थ है **Security Context Constraints**। Security Context Constraints नीतियाँ हैं जो OpenShift क्लस्टरों पर चल रहे पॉड्स के लिए अनुमतियों को नियंत्रित करती हैं। ये उन सुरक्षा मानकों को परिभाषित करती हैं जिनके तहत एक पॉड चलने की अनुमति है, जिसमें यह शामिल है कि यह कौन-से कार्य कर सकता है और यह कौन-से संसाधनों तक पहुँच सकता है।
|
||||
OpenShift के संदर्भ में, SCC का अर्थ है **Security Context Constraints**। Security Context Constraints नीतियाँ हैं जो OpenShift क्लस्टरों पर चल रहे पॉड्स के लिए अनुमतियों को नियंत्रित करती हैं। ये उन सुरक्षा मानकों को परिभाषित करती हैं जिनके तहत एक पॉड को चलाने की अनुमति है, जिसमें यह शामिल है कि यह कौन-सी क्रियाएँ कर सकता है और यह कौन-से संसाधनों तक पहुँच सकता है।
|
||||
|
||||
SCCs प्रशासकों को क्लस्टर में सुरक्षा नीतियों को लागू करने में मदद करती हैं, यह सुनिश्चित करते हुए कि पॉड्स उचित अनुमतियों के साथ चल रहे हैं और संगठनात्मक सुरक्षा मानकों का पालन कर रहे हैं। ये प्रतिबंध पॉड सुरक्षा के विभिन्न पहलुओं को निर्दिष्ट कर सकते हैं, जैसे:
|
||||
SCCs प्रशासकों को क्लस्टर में सुरक्षा नीतियों को लागू करने में मदद करते हैं, यह सुनिश्चित करते हुए कि पॉड्स उचित अनुमतियों के साथ चल रहे हैं और संगठनात्मक सुरक्षा मानकों का पालन कर रहे हैं। ये प्रतिबंध पॉड सुरक्षा के विभिन्न पहलुओं को निर्दिष्ट कर सकते हैं, जैसे:
|
||||
|
||||
1. लिनक्स क्षमताएँ: कंटेनरों के लिए उपलब्ध क्षमताओं को सीमित करना, जैसे विशेषाधिकार प्राप्त कार्य करने की क्षमता।
|
||||
2. SELinux संदर्भ: कंटेनरों के लिए SELinux संदर्भों को लागू करना, जो यह परिभाषित करता है कि प्रक्रियाएँ सिस्टम पर संसाधनों के साथ कैसे इंटरैक्ट करती हैं।
|
||||
1. Linux क्षमताएँ: कंटेनरों के लिए उपलब्ध क्षमताओं को सीमित करना, जैसे विशेषाधिकार प्राप्त क्रियाएँ करने की क्षमता।
|
||||
2. SELinux संदर्भ: कंटेनरों के लिए SELinux संदर्भों को लागू करना, जो यह परिभाषित करते हैं कि प्रक्रियाएँ सिस्टम पर संसाधनों के साथ कैसे इंटरैक्ट करती हैं।
|
||||
3. केवल पढ़ने योग्य रूट फ़ाइल सिस्टम: कुछ निर्देशिकाओं में फ़ाइलों को संशोधित करने से कंटेनरों को रोकना।
|
||||
4. अनुमत होस्ट निर्देशिकाएँ और वॉल्यूम: यह निर्दिष्ट करना कि एक पॉड कौन-से होस्ट निर्देशिकाएँ और वॉल्यूम माउंट कर सकता है।
|
||||
4. अनुमत होस्ट निर्देशिकाएँ और वॉल्यूम: यह निर्दिष्ट करना कि कौन-से होस्ट निर्देशिकाएँ और वॉल्यूम एक पॉड माउंट कर सकता है।
|
||||
5. UID/GID के रूप में चलाना: यह निर्दिष्ट करना कि कंटेनर प्रक्रिया किस उपयोगकर्ता और समूह आईडी के तहत चलती है।
|
||||
6. नेटवर्क नीतियाँ: पॉड्स के लिए नेटवर्क पहुँच को नियंत्रित करना, जैसे कि निकासी ट्रैफ़िक को प्रतिबंधित करना।
|
||||
|
||||
@@ -29,7 +29,7 @@ SCCs को कॉन्फ़िगर करके, प्रशासक य
|
||||
|
||||
## SCC सूची
|
||||
|
||||
OpenShift क्लाइंट के साथ सभी SCC की सूची बनाने के लिए:
|
||||
Openshift Client के साथ सभी SCC की सूची बनाने के लिए:
|
||||
```bash
|
||||
$ oc get scc #List all the SCCs
|
||||
|
||||
@@ -46,7 +46,7 @@ $ oc describe scc $SCC #Check SCC definitions
|
||||
$ oc get pod MYPOD -o yaml | grep scc
|
||||
openshift.io/scc: privileged
|
||||
```
|
||||
जब एक उपयोगकर्ता के पास कई SCCs तक पहुंच होती है, तो सिस्टम उस SCC का उपयोग करेगा जो सुरक्षा संदर्भ मानों के साथ मेल खाता है। अन्यथा, यह एक निषिद्ध त्रुटि को सक्रिय करेगा।
|
||||
जब एक उपयोगकर्ता के पास कई SCCs तक पहुंच होती है, तो सिस्टम उस SCC का उपयोग करेगा जो सुरक्षा संदर्भ मानों के साथ मेल खाता है। अन्यथा, यह एक निषिद्ध त्रुटि को ट्रिगर करेगा।
|
||||
```bash
|
||||
$ oc apply -f evilpod.yaml #Deploy a privileged pod
|
||||
Error from server (Forbidden): error when creating "evilpod.yaml": pods "evilpod" is forbidden: unable to validate against any security context constrain
|
||||
|
||||
Reference in New Issue
Block a user