Translated ['src/pentesting-ci-cd/ansible-tower-awx-automation-controlle

2026-07-04 03:45:51 -07:00 · 2025-08-01 10:12:24 +00:00
parent 4231f7f6db
commit 7c8a3576f4
47 changed files with 435 additions and 255 deletions
@@ -1,4 +1,6 @@
-# OpenShift - Escalada de Privilégios
+# OpenShift - Escalação de Privilégios
+
+{{#include ../../../banners/hacktricks-training.md}}

 ## Conta de Serviço Ausente

@@ -17,3 +19,7 @@ openshift-tekton.md
 {{#ref}}
 openshift-scc-bypass.md
 {{#endref}}
+
+
+
+{{#include ../../../banners/hacktricks-training.md}}
@@ -1,23 +1,27 @@
-# OpenShift - Conta de Serviço Ausente
+# OpenShift - Missing Service Account

-## Conta de Serviço Ausente
+{{#include ../../../banners/hacktricks-training.md}}

-Acontece que o cluster é implantado com um modelo pré-configurado que define automaticamente Roles, RoleBindings e até mesmo SCC para uma conta de serviço que ainda não foi criada. Isso pode levar a uma escalada de privilégios no caso de você conseguir criá-las. Nesse caso, você seria capaz de obter o token da SA recém-criada e o papel ou SCC associado. O mesmo caso ocorre quando a SA ausente faz parte de um projeto ausente; nesse caso, se você conseguir criar o projeto e, em seguida, a SA, você obterá os Roles e SCC associados.
+## Missing Service Account
+
+Acontece que o cluster é implantado com um modelo pré-configurado que define automaticamente Roles, RoleBindings e até mesmo SCC para uma conta de serviço que ainda não foi criada. Isso pode levar a uma escalada de privilégios no caso de você conseguir criá-las. Nesse caso, você seria capaz de obter o token da SA recém-criada e o papel ou SCC associado. O mesmo caso ocorre quando a SA ausente faz parte de um projeto ausente; nesse caso, se você puder criar o projeto e, em seguida, a SA, você obterá os Roles e SCC associados.

 <figure><img src="../../../images/openshift-missing-service-account-image1.png" alt=""><figcaption></figcaption></figure>

-No gráfico anterior, temos múltiplos AbsentProject, significando múltiplos projetos que aparecem em Roles Bindings ou SCC, mas que ainda não foram criados no cluster. Da mesma forma, também temos uma AbsentServiceAccount.
+No gráfico anterior, temos múltiplos AbsentProject, significando múltiplos projetos que aparecem em Roles Bindings ou SCC, mas que ainda não foram criados no cluster. Da mesma forma, também temos um AbsentServiceAccount.

-Se conseguirmos criar um projeto e a SA ausente nele, a SA herdará do Role ou do SCC que estavam direcionando a AbsentServiceAccount. O que pode levar a uma escalada de privilégios.
+Se conseguirmos criar um projeto e a SA ausente nele, a SA herdará o Role ou o SCC que estavam direcionados para a AbsentServiceAccount. O que pode levar a uma escalada de privilégios.

 O seguinte exemplo mostra uma SA ausente que é concedida ao SCC node-exporter:

 <figure><img src="../../../images/openshift-missing-service-account-image2.png" alt=""><figcaption></figcaption></figure>

-## Ferramentas
+## Tools

 A seguinte ferramenta pode ser usada para enumerar esse problema e, de forma mais geral, para mapear um cluster OpenShift:

 {{#ref}}
 https://github.com/maxDcb/OpenShiftGrapher
 {{#endref}}
+
+{{#include ../../../banners/hacktricks-training.md}}
@@ -1,5 +1,7 @@
 # Openshift - SCC bypass

+{{#include ../../../banners/hacktricks-training.md}}
+
 **O autor original desta página é** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)

 ## Namespaces Privilegiados
@@ -86,7 +88,7 @@ volumes:
 hostPath:
 path:
 ```
-Agora, tornou-se mais fácil escalar privilégios para acessar o sistema host e, subsequentemente, assumir todo o cluster, ganhando privilégios de 'cluster-admin'. Procure pela parte **Node-Post Exploitation** na página a seguir:
+Agora, tornou-se mais fácil escalar privilégios para acessar o sistema host e, subsequentemente, assumir todo o cluster, ganhando privilégios de 'cluster-admin'. Procure pela parte **Node-Post Exploitation** na seguinte página:

 {{#ref}}
 ../../kubernetes-security/attacking-kubernetes-from-inside-a-pod.md
@@ -94,7 +96,7 @@ Agora, tornou-se mais fácil escalar privilégios para acessar o sistema host e,

 ### Rótulos personalizados

-Além disso, com base na configuração alvo, alguns rótulos / anotações personalizados podem ser usados da mesma forma que no cenário de ataque anterior. Mesmo que não seja feito para isso, rótulos podem ser usados para conceder permissões, restringir ou não um recurso específico.
+Além disso, com base na configuração alvo, alguns rótulos / anotações personalizados podem ser usados da mesma forma que o cenário de ataque anterior. Mesmo que não seja feito para isso, rótulos podem ser usados para conceder permissões, restringir ou não um recurso específico.

 Tente procurar por rótulos personalizados se você puder ler alguns recursos. Aqui está uma lista de recursos interessantes:

@@ -111,7 +113,7 @@ $ oc get namespace -o yaml | grep labels -A 5
 ```bash
 $ oc get project -o yaml | grep 'run-level' -b5
 ```
-## Exploit Avançado
+## Exploração Avançada

 No OpenShift, como demonstrado anteriormente, ter permissão para implantar um pod em um namespace com o rótulo `openshift.io/run-level` pode levar a uma tomada de controle direta do cluster. Do ponto de vista das configurações do cluster, essa funcionalidade **não pode ser desativada**, pois é inerente ao design do OpenShift.

@@ -124,3 +126,7 @@ Para contornar as regras do GateKeeper e definir esse rótulo para executar uma
 - [https://docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html](https://docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html)
 - [https://docs.openshift.com/container-platform/3.11/admin_guide/manage_scc.html](https://docs.openshift.com/container-platform/3.11/admin_guide/manage_scc.html)
 - [https://github.com/open-policy-agent/gatekeeper](https://github.com/open-policy-agent/gatekeeper)
+
+
+
+{{#include ../../../banners/hacktricks-training.md}}
@@ -1,12 +1,14 @@
 # OpenShift - Tekton

+{{#include ../../../banners/hacktricks-training.md}}
+
 **O autor original desta página é** [**Haroun**](https://www.linkedin.com/in/haroun-al-mounayar-571830211)

 ### O que é tekton

-De acordo com a documentação: _Tekton é uma estrutura poderosa e flexível de código aberto para criar sistemas de CI/CD, permitindo que os desenvolvedores construam, testem e implantem em provedores de nuvem e sistemas locais._ Tanto Jenkins quanto Tekton podem ser usados para testar, construir e implantar aplicações, no entanto, Tekton é Cloud Native.&#x20;
+De acordo com a documentação: _Tekton é uma estrutura poderosa e flexível de código aberto para criar sistemas de CI/CD, permitindo que os desenvolvedores construam, testem e implantem em provedores de nuvem e sistemas locais._ Tanto o Jenkins quanto o Tekton podem ser usados para testar, construir e implantar aplicações, no entanto, o Tekton é nativo da nuvem.

-Com Tekton, tudo é representado por arquivos YAML. Os desenvolvedores podem criar Recursos Personalizados (CR) do tipo `Pipelines` e especificar várias `Tasks` neles que desejam executar. Para executar um Pipeline, recursos do tipo `PipelineRun` devem ser criados.
+Com o Tekton, tudo é representado por arquivos YAML. Os desenvolvedores podem criar Recursos Personalizados (CR) do tipo `Pipelines` e especificar várias `Tasks` neles que desejam executar. Para executar um Pipeline, recursos do tipo `PipelineRun` devem ser criados.

 Quando o tekton é instalado, uma conta de serviço (sa) chamada pipeline é criada em cada namespace. Quando um Pipeline é executado, um pod será gerado usando esta sa chamada `pipeline` para executar as tarefas definidas no arquivo YAML.

@@ -16,7 +18,7 @@ https://tekton.dev/docs/getting-started/pipelines/

 ### As capacidades da conta de serviço do Pipeline

-Por padrão, a conta de serviço do pipeline pode usar a capacidade `pipelines-scc`. Isso se deve à configuração padrão global do tekton. Na verdade, a configuração global do tekton também é um YAML em um objeto openshift chamado `TektonConfig` que pode ser visto se você tiver alguns papéis de leitor no cluster.
+Por padrão, a conta de serviço do pipeline pode usar a capacidade `pipelines-scc`. Isso se deve à configuração padrão global do tekton. Na verdade, a configuração global do tekton também é um YAML em um objeto do openshift chamado `TektonConfig` que pode ser visto se você tiver alguns papéis de leitor no cluster.
 ```yaml
 apiVersion: operator.tekton.dev/v1alpha1
 kind: TektonConfig
@@ -43,7 +45,7 @@ name: test-namespace
 annotations:
 operator.tekton.dev/scc: privileged
 ```
-O operador tekton dará à conta de serviço do pipeline em `test-namespace` a capacidade de usar o scc privilegiado. Isso permitirá a montagem do nó.
+O operador tekton dará à conta de serviço da pipeline em `test-namespace` a capacidade de usar o scc privilegiado. Isso permitirá a montagem do nó.

 ### A correção

@@ -53,7 +55,7 @@ Os documentos do Tekton sobre como restringir a substituição do scc adicionand
 https://tekton.dev/docs/operator/sccconfig/
 {{#endref}}

-Esse rótulo é chamado de `max-allowed`&#x20;
+Esse rótulo é chamado de `max-allowed`
 ```yaml
 apiVersion: operator.tekton.dev/v1alpha1
 kind: TektonConfig
@@ -68,4 +70,4 @@ scc:
 default: "restricted-v2"
 maxAllowed: "privileged"
 ```
-
+{{#include ../../../banners/hacktricks-training.md}}