# Openshift - SCC

**L'auteur original de cette page est** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)

## Définition

Dans le contexte d'OpenShift, SCC signifie **Security Context Constraints**. Les Security Context Constraints sont des politiques qui contrôlent les permissions pour les pods exécutés sur les clusters OpenShift. Elles définissent les paramètres de sécurité sous lesquels un pod est autorisé à s'exécuter, y compris les actions qu'il peut effectuer et les ressources auxquelles il peut accéder.

Les SCC aident les administrateurs à appliquer des politiques de sécurité à travers le cluster, garantissant que les pods s'exécutent avec des permissions appropriées et respectent les normes de sécurité organisationnelles. Ces contraintes peuvent spécifier divers aspects de la sécurité des pods, tels que :

1. Capacités Linux : Limiter les capacités disponibles pour les conteneurs, comme la capacité d'effectuer des actions privilégiées.
2. Contexte SELinux : Appliquer des contextes SELinux pour les conteneurs, qui définissent comment les processus interagissent avec les ressources sur le système.
3. Système de fichiers racine en lecture seule : Empêcher les conteneurs de modifier des fichiers dans certains répertoires.
4. Répertoires et volumes hôtes autorisés : Spécifier quels répertoires et volumes hôtes un pod peut monter.
5. Exécuter en tant que UID/GID : Spécifier les identifiants d'utilisateur et de groupe sous lesquels le processus du conteneur s'exécute.
6. Politiques réseau : Contrôler l'accès réseau pour les pods, comme restreindre le trafic sortant.

En configurant les SCC, les administrateurs peuvent s'assurer que les pods s'exécutent avec le niveau approprié d'isolement de sécurité et de contrôles d'accès, réduisant ainsi le risque de vulnérabilités de sécurité ou d'accès non autorisé au sein du cluster.

Fondamentalement, chaque fois qu'un déploiement de pod est demandé, un processus d'admission est exécuté comme suit :

<figure><img src="../../images/Managing SCCs in OpenShift-1.png" alt=""><figcaption></figcaption></figure>

Cette couche de sécurité supplémentaire interdit par défaut la création de pods privilégiés, le montage du système de fichiers hôte, ou la définition d'attributs pouvant conduire à une élévation de privilèges.

{{#ref}}
../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/pod-escape-privileges.md
{{#endref}}

## Liste SCC

Pour lister tous les SCC avec le client Openshift :
```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
```
Tous les utilisateurs ont accès aux SCC par défaut "**restricted**" et "**restricted-v2**" qui sont les SCC les plus stricts.

## Utiliser SCC

Le SCC utilisé pour un pod est défini dans une annotation :
```bash
$ oc get pod MYPOD -o yaml | grep scc
openshift.io/scc: privileged
```
Lorsque un utilisateur a accès à plusieurs SCC, le système utilisera celui qui correspond aux valeurs de contexte de sécurité. Sinon, cela déclenchera une erreur d'interdiction.
```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
```
## Contournement de SCC

{{#ref}}
openshift-privilege-escalation/openshift-scc-bypass.md
{{#endref}}

## Références

- [https://www.redhat.com/en/blog/managing-sccs-in-openshift](https://www.redhat.com/en/blog/managing-sccs-in-openshift)
