mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-01 10:35:06 -07:00
Translated ['src/pentesting-ci-cd/ansible-tower-awx-automation-controlle
This commit is contained in:
Translator
@@ -1,5 +1,7 @@
|
||||
# OpenShift Pentesting
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Informações Básicas
|
||||
|
||||
{{#ref}}
|
||||
@@ -17,3 +19,7 @@ openshift-scc.md
|
||||
{{#ref}}
|
||||
openshift-privilege-escalation/
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
# OpenShift - Informações básicas
|
||||
|
||||
## Kubernetes conhecimento b**ásico** <a href="#a94e" id="a94e"></a>
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Kubernetes conhecimento b**ásico** prévio <a href="#a94e" id="a94e"></a>
|
||||
|
||||
Antes de trabalhar com OpenShift, certifique-se de que está confortável com o ambiente Kubernetes. Todo o capítulo do OpenShift assume que você tem conhecimento prévio de Kubernetes.
|
||||
|
||||
@@ -23,9 +25,9 @@ Para fazer login usando o CLI:
|
||||
oc login -u=<username> -p=<password> -s=<server>
|
||||
oc login -s=<server> --token=<bearer token>
|
||||
```
|
||||
### **OpenShift - Restrições de Contexto de Segurança** <a href="#a94e" id="a94e"></a>
|
||||
### **OpenShift - Security Context Constraints** <a href="#a94e" id="a94e"></a>
|
||||
|
||||
Além dos [recursos RBAC](https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#architecture-additional-concepts-authorization) que controlam o que um usuário pode fazer, a OpenShift Container Platform fornece _restrições de contexto de segurança_ (SCC) que controlam as ações que um pod pode realizar e o que ele tem a capacidade de acessar.
|
||||
Além dos [recursos RBAC](https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#architecture-additional-concepts-authorization) que controlam o que um usuário pode fazer, a OpenShift Container Platform fornece _security context constraints_ (SCC) que controlam as ações que um pod pode realizar e o que ele tem a capacidade de acessar.
|
||||
|
||||
SCC é um objeto de política que possui regras especiais que correspondem à infraestrutura em si, ao contrário do RBAC que possui regras que correspondem à Plataforma. Ele nos ajuda a definir quais recursos de controle de acesso do Linux o contêiner deve ser capaz de solicitar/executar. Exemplo: Capacidades do Linux, perfis SECCOMP, Montar diretórios localhost, etc.
|
||||
|
||||
@@ -36,3 +38,7 @@ openshift-scc.md
|
||||
{{#ref}}
|
||||
https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#security-context-constraints
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,12 +1,14 @@
|
||||
# OpenShift - Jenkins
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
**O autor original desta página é** [**Fares**](https://www.linkedin.com/in/fares-siala/)
|
||||
|
||||
Esta página fornece algumas dicas sobre como você pode atacar uma instância do Jenkins em execução em um cluster Openshift (ou Kubernetes).
|
||||
|
||||
## Isenção de responsabilidade
|
||||
|
||||
Uma instância do Jenkins pode ser implantada tanto em um cluster Openshift quanto em um cluster Kubernetes. Dependendo do seu contexto, você pode precisar adaptar qualquer payload, yaml ou técnica mostrada. Para mais informações sobre como atacar o Jenkins, você pode dar uma olhada [nesta página](../../../pentesting-ci-cd/jenkins-security/).
|
||||
Uma instância do Jenkins pode ser implantada tanto em um cluster Openshift quanto em um cluster Kubernetes. Dependendo do seu contexto, você pode precisar adaptar qualquer payload, yaml ou técnica mostrada. Para mais informações sobre como atacar o Jenkins, você pode dar uma olhada [nesta página](../../../pentesting-ci-cd/jenkins-security/index.html).
|
||||
|
||||
## Pré-requisitos
|
||||
|
||||
@@ -18,7 +20,7 @@ Fundamentalmente, quase tudo nos bastidores funciona da mesma forma que uma inst
|
||||
|
||||
### Construções
|
||||
|
||||
Quando uma construção é acionada, ela é primeiro gerenciada/orquestrada pelo nó mestre do Jenkins e, em seguida, delegada a um agente/escravo/trabalhador. Nesse contexto, o nó mestre é apenas um pod regular em execução em um namespace (que pode ser diferente daquele onde os trabalhadores são executados). O mesmo se aplica aos trabalhadores/escravos, no entanto, eles são destruídos uma vez que a construção é concluída, enquanto o mestre sempre permanece ativo. Sua construção é geralmente executada dentro de um pod, usando um modelo de pod padrão definido pelos administradores do Jenkins.
|
||||
Quando uma construção é acionada, ela é primeiro gerenciada/orquestrada pelo nó mestre do Jenkins e, em seguida, delegada a um agente/escravo/trabalhador. Nesse contexto, o nó mestre é apenas um pod regular em execução em um namespace (que pode ser diferente daquele onde os trabalhadores estão em execução). O mesmo se aplica aos trabalhadores/escravos, no entanto, eles são destruídos uma vez que a construção é concluída, enquanto o mestre sempre permanece ativo. Sua construção é geralmente executada dentro de um pod, usando um modelo de pod padrão definido pelos administradores do Jenkins.
|
||||
|
||||
### Acionando uma construção
|
||||
|
||||
@@ -26,7 +28,7 @@ Você tem várias maneiras principais de acionar uma construção, como:
|
||||
|
||||
1. Você tem acesso à interface do usuário do Jenkins
|
||||
|
||||
Uma maneira muito fácil e conveniente é usar a funcionalidade Replay de uma construção existente. Isso permite que você reproduza uma construção executada anteriormente, permitindo que você atualize o script groovy. Isso requer privilégios em uma pasta do Jenkins e um pipeline pré-definido. Se você precisar ser discreto, pode excluir suas construções acionadas se tiver permissão suficiente.
|
||||
Uma maneira muito fácil e conveniente é usar a funcionalidade Replay de uma construção existente. Isso permite que você reproduza uma construção executada anteriormente, permitindo que você atualize o script groovy. Isso requer privilégios em uma pasta do Jenkins e um pipeline predefinido. Se você precisar ser discreto, pode excluir suas construções acionadas se tiver permissão suficiente.
|
||||
|
||||
2. Você tem acesso de gravação ao SCM e construções automatizadas estão configuradas via webhook
|
||||
|
||||
@@ -37,3 +39,5 @@ Você pode simplesmente editar um script de construção (como Jenkinsfile), faz
|
||||
{{#ref}}
|
||||
openshift-jenkins-build-overrides.md
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+11
-5
@@ -1,10 +1,12 @@
|
||||
# Jenkins no Openshift - substituições de pod de build
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
**O autor original desta página é** [**Fares**](https://www.linkedin.com/in/fares-siala/)
|
||||
|
||||
## Plugin Kubernetes para Jenkins
|
||||
Este plugin é principalmente responsável pelas funções principais do Jenkins dentro de um cluster openshift/kubernetes. Documentação oficial [aqui](https://plugins.jenkins.io/kubernetes/)
|
||||
Ele oferece algumas funcionalidades, como a capacidade de os desenvolvedores substituírem algumas configurações padrão de um pod de build do jenkins.
|
||||
Ele oferece algumas funcionalidades, como a capacidade de os desenvolvedores substituírem algumas configurações padrão de um pod de build do Jenkins.
|
||||
|
||||
## Funcionalidade principal
|
||||
|
||||
@@ -34,7 +36,7 @@ sh 'mvn -B -ntp clean install'
|
||||
}
|
||||
}
|
||||
```
|
||||
## Alguns abusos aproveitando a sobreposição de yaml do pod
|
||||
## Alguns abusos aproveitando a sobreposição do yaml do pod
|
||||
|
||||
No entanto, pode ser abusado para usar qualquer imagem acessível, como Kali Linux, e executar comandos arbitrários usando ferramentas pré-instaladas dessa imagem.
|
||||
No exemplo abaixo, podemos exfiltrar o token da serviceaccount do pod em execução.
|
||||
@@ -128,7 +130,7 @@ sh 'env'
|
||||
}
|
||||
}
|
||||
```
|
||||
Outro exemplo que tenta montar um serviceaccount (que pode ter mais permissões do que o padrão, executando sua build) com base em seu nome. Você pode precisar adivinhar ou enumerar serviceaccounts existentes primeiro.
|
||||
Outro exemplo que tenta montar um serviceaccount (que pode ter mais permissões do que o padrão, executando sua build) com base em seu nome. Você pode precisar adivinhar ou enumerar os serviceaccounts existentes primeiro.
|
||||
```groovy
|
||||
pipeline {
|
||||
stages {
|
||||
@@ -170,7 +172,7 @@ Uma vez que você se acostume a brincar com isso, use seu conhecimento sobre Jen
|
||||
Pergunte a si mesmo as seguintes questões:
|
||||
|
||||
- Qual conta de serviço está sendo usada para implantar pods de construção?
|
||||
- Quais papéis e permissões ela possui? Pode ler secrets do namespace em que estou atualmente?
|
||||
- Quais funções e permissões ela possui? Pode ler segredos do namespace em que estou atualmente?
|
||||
- Posso enumerar outros pods de construção?
|
||||
- A partir de um sa comprometido, posso executar comandos no nó/pod mestre?
|
||||
- Posso enumerar mais o cluster para pivotar para outro lugar?
|
||||
@@ -220,7 +222,7 @@ Dependendo do seu acesso, você precisa continuar seu ataque a partir do script
|
||||
```bash
|
||||
oc login --token=$token --server=https://apiserver.com:port
|
||||
```
|
||||
Se este sa tiver permissões suficientes (como pod/exec), você também pode assumir o controle de toda a instância do jenkins executando comandos dentro do pod do nó master, se estiver sendo executado dentro do mesmo namespace. Você pode identificar facilmente este pod pelo seu nome e pelo fato de que ele deve estar montando um PVC (persistent volume claim) usado para armazenar dados do jenkins.
|
||||
Se este sa tiver permissões suficientes (como pod/exec), você também pode assumir o controle de toda a instância do jenkins executando comandos dentro do pod do nó master, se estiver rodando dentro do mesmo namespace. Você pode identificar facilmente este pod pelo seu nome e pelo fato de que ele deve estar montando um PVC (persistent volume claim) usado para armazenar dados do jenkins.
|
||||
```bash
|
||||
oc rsh pod_name -c container_name
|
||||
```
|
||||
@@ -258,3 +260,7 @@ sh 'env'
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -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}}
|
||||
|
||||
+10
-6
@@ -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}}
|
||||
|
||||
+9
-3
@@ -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}}
|
||||
|
||||
+8
-6
@@ -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. 
|
||||
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` 
|
||||
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}}
|
||||
|
||||
@@ -1,15 +1,17 @@
|
||||
# Openshift - SCC
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
**O autor original desta página é** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
|
||||
|
||||
## Definição
|
||||
|
||||
No contexto do OpenShift, SCC significa **Security Context Constraints**. Security Context Constraints são políticas que controlam permissões para pods em execução em clusters OpenShift. Elas definem os parâmetros de segurança sob os quais um pod pode ser executado, incluindo quais ações ele pode realizar e quais recursos pode acessar.
|
||||
|
||||
SCCs ajudam administradores a impor políticas de segurança em todo o cluster, garantindo que os pods estejam sendo executados com permissões apropriadas e aderindo aos padrões de segurança organizacionais. Essas restrições podem especificar vários aspectos da segurança do pod, como:
|
||||
SCCs ajudam os administradores a impor políticas de segurança em todo o cluster, garantindo que os pods estejam sendo executados com permissões apropriadas e aderindo aos padrões de segurança organizacionais. Essas restrições podem especificar vários aspectos da segurança do pod, como:
|
||||
|
||||
1. Capacidades do Linux: Limitando as capacidades disponíveis para contêineres, como a capacidade de realizar ações privilegiadas.
|
||||
2. Contexto SELinux: Aplicando contextos SELinux para contêineres, que definem como os processos interagem com recursos no sistema.
|
||||
2. Contexto SELinux: Impor contextos SELinux para contêineres, que definem como os processos interagem com recursos no sistema.
|
||||
3. Sistema de arquivos raiz somente leitura: Impedindo que contêineres modifiquem arquivos em certos diretórios.
|
||||
4. Diretórios e volumes de host permitidos: Especificando quais diretórios e volumes de host um pod pode montar.
|
||||
5. Executar como UID/GID: Especificando os IDs de usuário e grupo sob os quais o processo do contêiner é executado.
|
||||
@@ -21,7 +23,7 @@ Basicamente, toda vez que um pedido de implantação de pod é solicitado, um pr
|
||||
|
||||
<figure><img src="../../images/Managing SCCs in OpenShift-1.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Esta camada de segurança adicional, por padrão, proíbe a criação de pods privilegiados, a montagem do sistema de arquivos do host ou a definição de quaisquer atributos que possam levar à escalada de privilégios.
|
||||
Esta camada adicional de segurança, por padrão, proíbe a criação de pods privilegiados, a montagem do sistema de arquivos do host ou a definição de quaisquer atributos que possam levar à escalada de privilégios.
|
||||
|
||||
{{#ref}}
|
||||
../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/pod-escape-privileges.md
|
||||
@@ -60,3 +62,7 @@ openshift-privilege-escalation/openshift-scc-bypass.md
|
||||
## Referências
|
||||
|
||||
- [https://www.redhat.com/en/blog/managing-sccs-in-openshift](https://www.redhat.com/en/blog/managing-sccs-in-openshift)
|
||||
|
||||
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user