gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-31 23:15:48 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-cloud/kubernetes-security/kubernetes-pivotin

Browse Source
This commit is contained in:
Translator
2025-01-02 21:34:59 +00:00
parent c14d2efa43
commit bb3733a1c5
7 changed files with 174 additions and 44 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -6,7 +6,7 @@
Si estás ejecutando un clúster de k8s dentro de GCP, probablemente querrás que alguna aplicación que se ejecute dentro del clúster tenga acceso a GCP. Hay 2 formas comunes de hacerlo:
### Montando claves GCP-SA como secreto
### Montando claves de GCP-SA como secreto
Una forma común de dar **acceso a una aplicación de kubernetes a GCP** es:
@@ -23,7 +23,7 @@ Una forma común de dar **acceso a una aplicación de kubernetes a GCP** es:
Una forma de dar acceso a un GSA a un clúster de GKE es vinculándolos de esta manera:
- Crear una cuenta de servicio de Kubernetes en el mismo espacio de nombres que tu clúster de GKE usando el siguiente comando:
- Crear una cuenta de servicio de Kubernetes en el mismo namespace que tu clúster de GKE usando el siguiente comando:
```bash
Copy codekubectl create serviceaccount <service-account-name>
```
@@ -46,7 +46,7 @@ iam.gke.io/gcp-service-account=<gcp-service-account-email>
Con la Identidad de Carga de Trabajo, podemos configurar una [cuenta de servicio de Kubernetes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) para actuar como una [cuenta de servicio de Google](https://cloud.google.com/iam/docs/understanding-service-accounts). Los pods que se ejecutan con la cuenta de servicio de Kubernetes se autenticarán automáticamente como la cuenta de servicio de Google al acceder a las API de Google Cloud.
La **primera serie de pasos** para habilitar este comportamiento es **habilitar la Identidad de Carga de Trabajo en GCP** ([**pasos**](https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c)) y crear la SA de GCP que deseas que k8s imite.
La **primera serie de pasos** para habilitar este comportamiento es **habilitar la Identidad de Carga de Trabajo en GCP** ([**pasos**](https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c)) y crear la SA de GCP que deseas que k8s impersonifique.
- **Habilitar la Identidad de Carga de Trabajo** en un nuevo clúster
```bash
@@ -54,7 +54,7 @@ gcloud container clusters update <cluster_name> \
--region=us-central1 \
--workload-pool=<project-id>.svc.id.goog
```
- **Crear/Actualizar un nuevo nodepool** (los clústeres Autopilot no necesitan esto)
- **Crear/Actualizar un nuevo grupo de nodos** (los clústeres Autopilot no necesitan esto)
```bash
# You could update instead of create
gcloud container node-pools create <nodepoolname> --cluster=<cluser_name> --workload-metadata=GKE_METADATA --region=us-central1
@@ -143,7 +143,7 @@ done | grep -B 1 "gcp-service-account"
Una forma (desactualizada) de dar roles IAM a los Pods es usar un [**Kiam**](https://github.com/uswitch/kiam) o un [**Kube2IAM**](https://github.com/jtblin/kube2iam) **servidor.** Básicamente, necesitarás ejecutar un **daemonset** en tu clúster con un **tipo de rol IAM privilegiado**. Este daemonset será el que dará acceso a los roles IAM a los pods que lo necesiten.
Primero que nada, necesitas configurar **qué roles se pueden acceder dentro del namespace**, y lo haces con una anotación dentro del objeto namespace:
Primero que nada, necesitas configurar **qué roles pueden ser accedidos dentro del namespace**, y lo haces con una anotación dentro del objeto namespace:
```yaml:Kiam
kind: Namespace
metadata: