gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-01-19 08:00:45 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['.github/pull_request_template.md', 'src/pentesting-cloud/az

Browse Source
This commit is contained in:
Translator
2024-12-31 18:54:26 +00:00
parent 7770a50092
commit 192d97f7b7
244 changed files with 8835 additions and 11676 deletions
Download Patch File Download Diff File Expand all files Collapse all files

72
src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-tekton.md
View File

@@ -1,79 +1,71 @@
# OpenShift - Tekton
**The original author of this page is** [**Haroun**](https://www.linkedin.com/in/haroun-al-mounayar-571830211)
**El autor original de esta página es** [**Haroun**](https://www.linkedin.com/in/haroun-al-mounayar-571830211)
### What is tekton
### ¿Qué es 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. 
Según la documentación: _Tekton es un marco de trabajo de código abierto poderoso y flexible para crear sistemas de CI/CD, permitiendo a los desarrolladores construir, probar y desplegar en proveedores de nube y sistemas locales._ Tanto Jenkins como Tekton pueden ser utilizados para probar, construir y desplegar aplicaciones, sin embargo, Tekton es Cloud Native. 
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.
Con Tekton, todo está representado por archivos YAML. Los desarrolladores pueden crear Recursos Personalizados (CR) de tipo `Pipelines` y especificar múltiples `Tasks` en ellos que desean ejecutar. Para ejecutar un Pipeline, deben crearse recursos de tipo `PipelineRun`.
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.
Cuando tekton está instalado, se crea una cuenta de servicio (sa) llamada pipeline en cada namespace. Cuando se ejecuta un Pipeline, se generará un pod utilizando esta sa llamada `pipeline` para ejecutar las tareas definidas en el archivo 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.
### Las capacidades de la cuenta de servicio de Pipeline
Por defecto, la cuenta de servicio de pipeline puede usar la capacidad `pipelines-scc`. Esto se debe a la configuración global predeterminada de tekton. De hecho, la configuración global de tekton también es un YAML en un objeto de openshift llamado `TektonConfig` que se puede ver si tienes algunos roles de lector en el clúster.
```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"
```
En cualquier namespace, si puedes obtener el token de la cuenta de servicio del pipeline, podrás 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:
### La Misconfiguración
El problema es que el scc predeterminado que la cuenta de servicio del pipeline puede usar es controlable por el usuario. Esto se puede hacer utilizando una etiqueta en la definición del namespace. Por ejemplo, si puedo crear un namespace con la siguiente definición 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
```
El operador tekton otorgará a la cuenta de servicio del pipeline en `test-namespace` la capacidad de usar el scc privilegiado. Esto permitirá el montaje del nodo.
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.
### La solución
### The fix
Tekton documents about how to restrict the override of scc by adding a label in the `TektonConfig` object.
Los documentos de Tekton sobre cómo restringir la anulación de scc añadiendo una etiqueta en el objeto `TektonConfig`.
{{#ref}}
https://tekton.dev/docs/operator/sccconfig/
{{#endref}}
This label is called `max-allowed` 
Esta etiqueta se llama `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"
```