GITBOOK-631: No subject

pentesting-cloud/openshift-pentesting/openshift-basic-information.md

@@ -18,13 +18,11 @@ OpenShift come with a it's own CLI, that can be found here:
 
 To login using the CLI:
 
-```
+```bash
 oc login -u=<username> -p=<password> -s=<server>
 oc login -s=<server> --token=<bearer token>
 ```
 
-### &#x20;<a href="#a94e" id="a94e"></a>
-
 ### **OpenShift - Security Context Constraints** <a href="#a94e" id="a94e"></a>
 
 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.
@@ -36,4 +34,3 @@ SCC is a policy object that has special rules that correspond with the infrastru
 {% endcontent-ref %}
 
 {% embed url="https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#security-context-constraints" %}
-

pentesting-cloud/openshift-pentesting/openshift-jenkins/README.md

@@ -1,38 +1,32 @@
-# Jenkins in Openshift
+# OpenShift - Jenkins
 
 **The original author of this page is** [**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
 
-
 ## 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/README.md)
+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/)
 
 ## Prerequisites
 
-1a. User acces 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. 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
 
 ## 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.
+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.
 
 ### 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.
+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.
 
 ### Triggering a build
 
 You have multiples main ways to trigger a build such as:
 
-1. You have UI access to jenkins
+1. You have UI access to Jenkins
 
-A very easy and convenient way is to use the Replay functionnality 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.
+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.
 
 2. You have write access to the SCM and automated builds are configured via webhook
 

pentesting-cloud/openshift-pentesting/openshift-scc.md

@@ -4,7 +4,6 @@
 
 ## 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.
 
 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: