Migrate to using mdbook

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

@@ -0,0 +1,68 @@
+# Openshift - SCC
+
+**The original author of this page is** [**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.
+
+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:
+
+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.
+
+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.
+
+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 :
+
+```bash
+$ oc get scc #List all the SCCs
+
+$ oc auth can-i --list | grep securitycontextconstraints #Which scc user can use
+
+$ oc describe scc $SCC #Check SCC definitions
+```
+
+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 :
+
+```bash
+$ oc get pod MYPOD -o yaml | grep scc
+  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.
+
+```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
+```
+
+## SCC Bypass
+
+{{#ref}}
+openshift-privilege-escalation/openshift-scc-bypass.md
+{{#endref}}
+
+## References
+
+- [https://www.redhat.com/en/blog/managing-sccs-in-openshift](https://www.redhat.com/en/blog/managing-sccs-in-openshift)