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

This commit is contained in:
Translator
2025-01-02 21:34:43 +00:00
parent 17d930d963
commit 8391396ffb
7 changed files with 176 additions and 46 deletions
@@ -27,7 +27,7 @@ Uma maneira de dar acesso a um GSA a um cluster GKE é vinculá-los desta forma:
```bash
Copy codekubectl create serviceaccount <service-account-name>
```
- Crie um Kubernetes Secret que contenha as credenciais da conta de serviço GCP à qual você deseja conceder acesso ao cluster GKE. Você pode fazer isso usando a ferramenta de linha de comando `gcloud`, conforme mostrado no seguinte exemplo:
- Crie um Kubernetes Secret que contenha as credenciais da conta de serviço GCP à qual você deseja conceder acesso ao cluster GKE. Você pode fazer isso usando a ferramenta de linha de comando `gcloud`, conforme mostrado no exemplo a seguir:
```bash
Copy codegcloud iam service-accounts keys create <key-file-name>.json \
--iam-account <gcp-service-account-email>
@@ -44,7 +44,7 @@ iam.gke.io/gcp-service-account=<gcp-service-account-email>
### Identidade de Workload GKE
Com a Identidade de Workload, podemos configurar uma [conta de serviço Kubernetes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) para agir como uma [conta de serviço Google](https://cloud.google.com/iam/docs/understanding-service-accounts). Pods executando com a conta de serviço Kubernetes se autenticarão automaticamente como a conta de serviço Google ao acessar APIs do Google Cloud.
Com a Identidade de Workload, podemos configurar uma [conta de serviço Kubernetes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) para agir como uma [conta de serviço Google](https://cloud.google.com/iam/docs/understanding-service-accounts). Pods executando com a conta de serviço Kubernetes serão automaticamente autenticados como a conta de serviço Google ao acessar APIs do Google Cloud.
A **primeira série de passos** para habilitar esse comportamento é **habilitar a Identidade de Workload no GCP** ([**passos**](https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c)) e criar a SA GCP que você deseja que o k8s impersonifique.
@@ -124,7 +124,7 @@ gcloud auth activate-service-account --key-file=/var/run/secrets/google/service-
```
> [!WARNING]
> Como um atacante dentro do K8s, você deve **procurar por SAs** com a **anotação `iam.gke.io/gcp-service-account`**, pois isso indica que a SA pode acessar algo no GCP. Outra opção seria tentar abusar de cada KSA no cluster e verificar se ela tem acesso.\
> Do GCP, é sempre interessante enumerar as ligações e saber **qual acesso você está dando às SAs dentro do Kubernetes**.
> Do GCP, é sempre interessante enumerar as ligações e saber **qual acesso você está concedendo às SAs dentro do Kubernetes**.
Este é um script para facilmente **iterar sobre todas as definições de pods** **procurando** por essa **anotação**:
```bash
@@ -171,7 +171,7 @@ annotations:
iam.amazonaws.com/role: reportingdb-reader
```
> [!WARNING]
> Como um atacante, se você **encontrar essas anotações** em pods ou namespaces ou um servidor kiam/kube2iam em execução (provavelmente no kube-system) você pode **impersonar qualquer r**ole que já está **sendo usada por pods** e mais (se você tiver acesso à conta AWS, enumere os roles).
> Como um atacante, se você **encontrar essas anotações** em pods ou namespaces ou um servidor kiam/kube2iam em execução (provavelmente no kube-system), você pode **impersonar qualquer r**ole que já está **sendo usada por pods** e mais (se você tiver acesso à conta AWS, enumere os roles).
#### Criar Pod com Role IAM
@@ -196,7 +196,7 @@ args: ["-c", "sleep 100000"]' | kubectl apply -f -
Esta é a **maneira recomendada pela AWS**.
1. Primeiro de tudo, você precisa [criar um provedor OIDC para o cluster](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html).
1. Primeiro, você precisa [criar um provedor OIDC para o cluster](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html).
2. Em seguida, você cria um papel IAM com as permissões que a SA precisará.
3. Crie uma [relação de confiança entre o papel IAM e a SA](https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html) nome (ou os namespaces que dão acesso ao papel para todas as SAs do namespace). _A relação de confiança verificará principalmente o nome do provedor OIDC, o nome do namespace e o nome da SA_.
4. Finalmente, **crie uma SA com uma anotação indicando o ARN do papel**, e os pods executando com essa SA terão **acesso ao token do papel**. O **token** é **escrito** dentro de um arquivo e o caminho é especificado em **`AWS_WEB_IDENTITY_TOKEN_FILE`** (padrão: `/var/run/secrets/eks.amazonaws.com/serviceaccount/token`)
@@ -226,7 +226,7 @@ aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/
> Além disso, se você estiver dentro de um pod, verifique variáveis de ambiente como **AWS_ROLE_ARN** e **AWS_WEB_IDENTITY_TOKEN.**
> [!CAUTION]
> Às vezes, a **Política de Confiança de um papel** pode estar **mal configurada** e, em vez de dar acesso AssumeRole à conta de serviço esperada, ela o dá para **todas as contas de serviço**. Portanto, se você for capaz de escrever uma anotação em uma conta de serviço controlada, poderá acessar o papel.
> Às vezes, a **Política de Confiança de um papel** pode estar **mal configurada** e, em vez de dar acesso AssumeRole à conta de serviço esperada, dá acesso a **todas as contas de serviço**. Portanto, se você for capaz de escrever uma anotação em uma conta de serviço controlada, poderá acessar o papel.
>
> Verifique a **página seguinte para mais informações**:
@@ -236,7 +236,7 @@ aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/
### Encontrar Pods e SAs com Papéis IAM no Cluster
Este é um script para facilmente **iterar sobre todas as definições de pods e sas** **procurando** por essa **anotação**:
Este é um script para facilmente **iterar sobre todos os pods e definições de sas** **procurando** por essa **anotação**:
```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