mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-30 22:50:43 -08:00
Translated ['.github/pull_request_template.md', 'src/pentesting-cloud/az
This commit is contained in:
@@ -1,36 +1,35 @@
|
||||
# Openshift - SCC
|
||||
|
||||
**The original author of this page is** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
|
||||
**Der ursprüngliche Autor dieser Seite ist** [**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.
|
||||
Im Kontext von OpenShift steht SCC für **Security Context Constraints**. Security Context Constraints sind Richtlinien, die Berechtigungen für Pods steuern, die auf OpenShift-Clustern ausgeführt werden. Sie definieren die Sicherheitsparameter, unter denen ein Pod ausgeführt werden darf, einschließlich der Aktionen, die er ausführen kann, und der Ressourcen, auf die er zugreifen kann.
|
||||
|
||||
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 helfen Administratoren, Sicherheitsrichtlinien im gesamten Cluster durchzusetzen, indem sichergestellt wird, dass Pods mit angemessenen Berechtigungen ausgeführt werden und den organisatorischen Sicherheitsstandards entsprechen. Diese Einschränkungen können verschiedene Aspekte der Podsicherheit spezifizieren, wie zum Beispiel:
|
||||
|
||||
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. Linux-Fähigkeiten: Einschränkung der für Container verfügbaren Fähigkeiten, wie die Fähigkeit, privilegierte Aktionen auszuführen.
|
||||
2. SELinux-Kontext: Durchsetzung von SELinux-Kontexten für Container, die definieren, wie Prozesse mit Ressourcen im System interagieren.
|
||||
3. Nur-Lese-Wurzel-Dateisystem: Verhinderung, dass Container Dateien in bestimmten Verzeichnissen ändern.
|
||||
4. Erlaubte Hostverzeichnisse und -volumes: Spezifizierung, welche Hostverzeichnisse und -volumes ein Pod einbinden kann.
|
||||
5. Ausführen als UID/GID: Spezifizierung der Benutzer- und Gruppen-IDs, unter denen der Containerprozess läuft.
|
||||
6. Netzwerkrichtlinien: Steuerung des Netzwerkzugriffs für Pods, wie z.B. Einschränkung des ausgehenden Datenverkehrs.
|
||||
|
||||
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.
|
||||
Durch die Konfiguration von SCCs können Administratoren sicherstellen, dass Pods mit dem angemessenen Maß an Sicherheitsisolierung und Zugriffskontrollen ausgeführt werden, wodurch das Risiko von Sicherheitsanfälligkeiten oder unbefugtem Zugriff innerhalb des Clusters verringert wird.
|
||||
|
||||
Basically, every time a pod deployment is requested, an admission process is executed as the following:
|
||||
Grundsätzlich wird jedes Mal, wenn eine Pod-Bereitstellung angefordert wird, ein Zulassungsprozess wie folgt ausgeführt:
|
||||
|
||||
<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.
|
||||
Diese zusätzliche Sicherheitsschicht verbietet standardmäßig die Erstellung von privilegierten Pods, das Einbinden des Host-Dateisystems oder das Setzen von Attributen, die zu einer Privilegieneskalation führen könnten.
|
||||
|
||||
{{#ref}}
|
||||
../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/pod-escape-privileges.md
|
||||
{{#endref}}
|
||||
|
||||
## List SCC
|
||||
|
||||
To list all the SCC with the Openshift Client :
|
||||
## Liste SCC
|
||||
|
||||
Um alle SCC mit dem Openshift-Client aufzulisten:
|
||||
```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
|
||||
```
|
||||
Alle Benutzer haben Zugriff auf die Standard-SCC "**restricted**" und "**restricted-v2**", die die strengsten SCCs sind.
|
||||
|
||||
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 :
|
||||
## Verwendung von SCC
|
||||
|
||||
Die für ein Pod verwendete SCC ist in einer Annotation definiert:
|
||||
```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.
|
||||
|
||||
Wenn ein Benutzer Zugriff auf mehrere SCCs hat, verwendet das System diejenige, die mit den Sicherheitskontextwerten übereinstimmt. Andernfalls wird ein Fehler "verboten" ausgelöst.
|
||||
```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