gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-02-05 03:16:37 -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:31 +00:00
parent f8203f6660
commit 1f68119fe8
7 changed files with 179 additions and 49 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -46,7 +46,7 @@ iam.gke.io/gcp-service-account=<gcp-service-account-email>
Dzięki Workload Identity możemy skonfigurować [konto usługi Kubernetes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/), aby działało jako [konto usługi Google](https://cloud.google.com/iam/docs/understanding-service-accounts). Podsy działające z kontem usługi Kubernetes będą automatycznie uwierzytelniane jako konto usługi Google podczas uzyskiwania dostępu do interfejsów API Google Cloud.
**Pierwsza seria kroków** w celu włączenia tego zachowania to **włączenie Workload Identity w GCP** ([**kroki**](https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c)) i utworzenie SA GCP, które chcesz, aby k8s naśladowało.
**Pierwsza seria kroków** w celu włączenia tego zachowania to **włączenie Workload Identity w GCP** ([**kroki**](https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c)) i utworzenie GCP SA, które chcesz, aby k8s udawało.
- **Włącz Workload Identity** na nowym klastrze
```bash
@@ -124,9 +124,9 @@ gcloud auth activate-service-account --key-file=/var/run/secrets/google/service-
```
> [!WARNING]
> Jako atakujący wewnątrz K8s powinieneś **szukać SAs** z **adnotacją `iam.gke.io/gcp-service-account`**, ponieważ wskazuje to, że SA może uzyskać dostęp do czegoś w GCP. Inną opcją byłoby spróbować wykorzystać każdy KSA w klastrze i sprawdzić, czy ma dostęp.\
> Z GCP zawsze warto enumerować powiązania i wiedzieć **jakie uprawnienia przyznajesz SA wewnątrz Kubernetes**.
> Z GCP zawsze warto enumerować powiązania i wiedzieć **jakie uprawnienia przyznajesz SAs wewnątrz Kubernetes**.
To jest skrypt do łatwego **iterowania po wszystkich definicjach podów** **w poszukiwaniu** tej **adnotacji**:
To jest skrypt do łatwego **iterowania po wszystkich definicjach podów** **szukając** tej **adnotacji**:
```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
@@ -143,7 +143,7 @@ done | grep -B 1 "gcp-service-account"
Jednym (przestarzałym) sposobem na przyznanie ról IAM Podom jest użycie [**Kiam**](https://github.com/uswitch/kiam) lub [**Kube2IAM**](https://github.com/jtblin/kube2iam) **serwera.** W zasadzie musisz uruchomić **daemonset** w swoim klastrze z **rodzajem uprzywilejowanej roli IAM**. Ten daemonset będzie tym, który przyzna dostęp do ról IAM podom, które tego potrzebują.
Przede wszystkim musisz skonfigurować **które role mogą być dostępne w obrębie przestrzeni nazw**, a robisz to za pomocą adnotacji wewnątrz obiektu przestrzeni nazw:
Przede wszystkim musisz skonfigurować **które role mogą być dostępne wewnątrz przestrzeni nazw**, a robisz to za pomocą adnotacji wewnątrz obiektu przestrzeni nazw:
```yaml:Kiam
kind: Namespace
metadata:
@@ -199,7 +199,7 @@ To jest **zalecany sposób przez AWS**.
1. Przede wszystkim musisz [utworzyć dostawcę OIDC dla klastra](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html).
2. Następnie tworzysz rolę IAM z uprawnieniami, które będą wymagane przez SA.
3. Utwórz [relację zaufania między rolą IAM a SA](https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html) (lub przestrzeniami nazw, które dają dostęp do roli wszystkim SA w przestrzeni nazw). _Relacja zaufania będzie głównie sprawdzać nazwę dostawcy OIDC, nazwę przestrzeni nazw i nazwę SA_.
4. Na koniec **utwórz SA z adnotacją wskazującą ARN roli**, a podsy działające z tą SA będą miały **dostęp do tokena roli**. **Token** jest **zapisywany** w pliku, a ścieżka jest określona w **`AWS_WEB_IDENTITY_TOKEN_FILE`** (domyślnie: `/var/run/secrets/eks.amazonaws.com/serviceaccount/token`)
4. Na koniec **utwórz SA z adnotacją wskazującą ARN roli**, a podsy działające z tą SA będą miały **dostęp do tokena roli**. **Token** jest **zapisany** w pliku, a ścieżka jest określona w **`AWS_WEB_IDENTITY_TOKEN_FILE`** (domyślnie: `/var/run/secrets/eks.amazonaws.com/serviceaccount/token`)
```bash
# Create a service account with a role
cat >my-service-account.yaml <<EOF
@@ -221,12 +221,12 @@ Aby **uzyskać aws za pomocą tokena** z `/var/run/secrets/eks.amazonaws.com/ser
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]
> Jako atakujący, jeśli możesz enumerować klaster K8s, sprawdź **kontrola serwisowe z tym adnotacją**, aby **eskalować do AWS**. Aby to zrobić, po prostu **exec/create** **pod** używając jednego z **uprzywilejowanych kont serwisowych IAM** i ukradnij token.
> Jako atakujący, jeśli możesz enumerować klaster K8s, sprawdź **konta serwisowe z tym adnotacją**, aby **eskalować do AWS**. Aby to zrobić, po prostu **exec/create** **pod** używając jednego z **uprzywilejowanych kont serwisowych IAM** i ukradnij token.
>
> Ponadto, jeśli jesteś wewnątrz pod, sprawdź zmienne środowiskowe takie jak **AWS_ROLE_ARN** i **AWS_WEB_IDENTITY_TOKEN.**
> Ponadto, jeśli jesteś wewnątrz poda, sprawdź zmienne środowiskowe takie jak **AWS_ROLE_ARN** i **AWS_WEB_IDENTITY_TOKEN.**
> [!CAUTION]
> Czasami **Polityka Zaufania roli** może być **źle skonfigurowana** i zamiast dawać dostęp AssumeRole do oczekiwanego konta serwisowego, daje go do **wszystkich kont serwisowych**. Dlatego, jeśli możesz napisać adnotację na kontrolowanym koncie serwisowym, możesz uzyskać dostęp do roli.
> Czasami **Polityka Zaufania roli** może być **źle skonfigurowana** i zamiast dawać dostęp AssumeRole do oczekiwanego konta serwisowego, daje go do **wszystkich kont serwisowych**. Dlatego, jeśli masz możliwość zapisania adnotacji na kontrolowanym koncie serwisowym, możesz uzyskać dostęp do roli.
>
> Sprawdź **następującą stronę po więcej informacji**:
@@ -234,9 +234,9 @@ aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/
../aws-security/aws-basic-information/aws-federation-abuse.md
{{#endref}}
### Znajdź Podsy i SAs z rolami IAM w klastrze
### Znajdź Pody i Konta Serwisowe z Rolami IAM w Klastrze
To jest skrypt do łatwego **iterowania po wszystkich podach i definicjach sas** **szukając** tej **adnotacji**:
To jest skrypt do łatwego **iterowania po wszystkich podach i definicjach sas**, **szukając** tej **adnotacji**:
```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