mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-17 07:11:47 -08:00
Translated ['.github/pull_request_template.md', 'src/README.md', 'src/pe
This commit is contained in:
Translator
@@ -1,6 +1,6 @@
|
||||
# OpenShift - Información básica
|
||||
|
||||
## Kubernetes conocimiento b**ásico** <a href="#a94e" id="a94e"></a>
|
||||
## Conocimientos previos de Kubernetes <a href="#a94e" id="a94e"></a>
|
||||
|
||||
Antes de trabajar con OpenShift, asegúrate de estar cómodo con el entorno de Kubernetes. Todo el capítulo de OpenShift asume que tienes conocimientos previos de Kubernetes.
|
||||
|
||||
@@ -23,9 +23,9 @@ Para iniciar sesión usando la CLI:
|
||||
oc login -u=<username> -p=<password> -s=<server>
|
||||
oc login -s=<server> --token=<bearer token>
|
||||
```
|
||||
### **OpenShift - Security Context Constraints** <a href="#a94e" id="a94e"></a>
|
||||
### **OpenShift - Restricciones de Contexto de Seguridad** <a href="#a94e" id="a94e"></a>
|
||||
|
||||
Además de los [recursos RBAC](https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#architecture-additional-concepts-authorization) que controlan lo que un usuario puede hacer, OpenShift Container Platform proporciona _security context constraints_ (SCC) que controlan las acciones que un pod puede realizar y a qué tiene la capacidad de acceder.
|
||||
Además de los [recursos RBAC](https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#architecture-additional-concepts-authorization) que controlan lo que un usuario puede hacer, OpenShift Container Platform proporciona _restricciones de contexto de seguridad_ (SCC) que controlan las acciones que un pod puede realizar y a qué tiene la capacidad de acceder.
|
||||
|
||||
SCC es un objeto de política que tiene reglas especiales que corresponden con la infraestructura misma, a diferencia de RBAC que tiene reglas que corresponden con la Plataforma. Nos ayuda a definir qué características de control de acceso de Linux el contenedor debería poder solicitar/ejecutar. Ejemplo: Capacidades de Linux, perfiles SECCOMP, montar directorios de localhost, etc.
|
||||
|
||||
|
||||
@@ -10,7 +10,7 @@ Una instancia de Jenkins puede ser desplegada tanto en un clúster de Openshift
|
||||
|
||||
## Requisitos previos
|
||||
|
||||
1a. Acceso de usuario en una instancia de Jenkins O 1b. Acceso de usuario con permiso de escritura a un repositorio SCM donde se activa una construcción automatizada después de un push/merge.
|
||||
1a. Acceso de usuario en una instancia de Jenkins O 1b. Acceso de usuario con permiso de escritura a un repositorio SCM donde se activa una construcción automática después de un push/merge.
|
||||
|
||||
## Cómo funciona
|
||||
|
||||
@@ -24,11 +24,11 @@ Cuando se activa una construcción, primero es gestionada/orquestada por el nodo
|
||||
|
||||
Tienes múltiples formas principales de activar una construcción, tales como:
|
||||
|
||||
1. Tienes acceso a la UI de Jenkins
|
||||
1. Tienes acceso a la interfaz de usuario de Jenkins
|
||||
|
||||
Una forma muy fácil y conveniente es usar la funcionalidad de Repetir de una construcción existente. Te permite repetir una construcción ejecutada previamente mientras te permite actualizar el script groovy. Esto requiere privilegios en una carpeta de Jenkins y un pipeline predefinido. Si necesitas ser sigiloso, puedes eliminar tus construcciones activadas si tienes suficientes permisos.
|
||||
|
||||
2. Tienes acceso de escritura al SCM y las construcciones automatizadas están configuradas a través de webhook
|
||||
2. Tienes acceso de escritura al SCM y las construcciones automáticas están configuradas a través de webhook
|
||||
|
||||
Puedes simplemente editar un script de construcción (como Jenkinsfile), hacer commit y push (eventualmente crear un PR si las construcciones solo se activan en merges de PR). Ten en cuenta que este camino es muy ruidoso y necesita privilegios elevados para limpiar tus huellas.
|
||||
|
||||
|
||||
@@ -3,10 +3,10 @@
|
||||
**El autor original de esta página es** [**Fares**](https://www.linkedin.com/in/fares-siala/)
|
||||
|
||||
## Plugin de Kubernetes para Jenkins
|
||||
Este plugin es principalmente responsable de las funciones centrales de Jenkins dentro de un clúster de openshift/kubernetes. Documentación oficial [aquí](https://plugins.jenkins.io/kubernetes/)
|
||||
Ofrece algunas funcionalidades como la capacidad de los desarrolladores para sobrescribir algunas configuraciones predeterminadas de un pod de construcción de Jenkins.
|
||||
Este plugin es principalmente responsable de las funciones centrales de Jenkins dentro de un clúster de openshift/kubernetes. Documentación oficial [aquí](https://plugins.jenkins.io/kubernetes/)
|
||||
Ofrece algunas funcionalidades como la capacidad para que los desarrolladores sobrescriban algunas configuraciones predeterminadas de un pod de construcción de jenkins.
|
||||
|
||||
## Funcionalidad central
|
||||
## Funcionalidad principal
|
||||
|
||||
Este plugin permite flexibilidad a los desarrolladores al construir su código en un entorno adecuado.
|
||||
```groovy
|
||||
@@ -215,7 +215,7 @@ sh 'oc --token=$token whoami'
|
||||
}
|
||||
}
|
||||
```
|
||||
Dependiendo de su acceso, ya sea que necesite continuar su ataque desde el script de construcción o puede iniciar sesión directamente como este sa en el clúster en ejecución:
|
||||
Dependiendo de su acceso, o necesita continuar su ataque desde el script de construcción o puede iniciar sesión directamente como este sa en el clúster en ejecución:
|
||||
```bash
|
||||
oc login --token=$token --server=https://apiserver.com:port
|
||||
```
|
||||
|
||||
@@ -34,11 +34,11 @@ La etiqueta específica `openshift.io/run-level` permite a los usuarios eludir l
|
||||
|
||||
## Agregar Etiqueta
|
||||
|
||||
Para agregar la etiqueta en su espacio de nombres:
|
||||
Para agregar la etiqueta en tu espacio de nombres:
|
||||
```bash
|
||||
$ oc label ns MYNAMESPACE openshift.io/run-level=0
|
||||
```
|
||||
Para crear un namespace con la etiqueta a través de un archivo YAML:
|
||||
Para crear un espacio de nombres con la etiqueta a través de un archivo YAML:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Namespace
|
||||
@@ -86,7 +86,7 @@ volumes:
|
||||
hostPath:
|
||||
path:
|
||||
```
|
||||
Ahora, se ha vuelto más fácil escalar privilegios para acceder al sistema host y, posteriormente, apoderarse de todo el clúster, obteniendo privilegios de 'cluster-admin'. Busca la parte de **Node-Post Exploitation** en la siguiente página:
|
||||
Ahora, se ha vuelto más fácil escalar privilegios para acceder al sistema host y, posteriormente, tomar el control de todo el clúster, obteniendo privilegios de 'cluster-admin'. Busca la parte de **Node-Post Exploitation** en la siguiente página:
|
||||
|
||||
{{#ref}}
|
||||
../../kubernetes-security/attacking-kubernetes-from-inside-a-pod.md
|
||||
@@ -94,7 +94,7 @@ Ahora, se ha vuelto más fácil escalar privilegios para acceder al sistema host
|
||||
|
||||
### Etiquetas personalizadas
|
||||
|
||||
Además, según la configuración objetivo, se pueden utilizar algunas etiquetas / anotaciones personalizadas de la misma manera que en el escenario de ataque anterior. Incluso si no están destinadas a ello, las etiquetas podrían usarse para otorgar permisos, restringir o no un recurso específico.
|
||||
Además, según la configuración del objetivo, se pueden utilizar algunas etiquetas / anotaciones personalizadas de la misma manera que en el escenario de ataque anterior. Incluso si no están destinadas para ello, las etiquetas podrían usarse para otorgar permisos, restringir o no un recurso específico.
|
||||
|
||||
Intenta buscar etiquetas personalizadas si puedes leer algunos recursos. Aquí hay una lista de recursos interesantes:
|
||||
|
||||
@@ -111,7 +111,7 @@ $ oc get namespace -o yaml | grep labels -A 5
|
||||
```bash
|
||||
$ oc get project -o yaml | grep 'run-level' -b5
|
||||
```
|
||||
## Advanced exploit
|
||||
## Explotación avanzada
|
||||
|
||||
En OpenShift, como se demostró anteriormente, tener permiso para desplegar un pod en un namespace con la etiqueta `openshift.io/run-level` puede llevar a una toma de control directa del clúster. Desde la perspectiva de la configuración del clúster, esta funcionalidad **no se puede desactivar**, ya que es inherente al diseño de OpenShift.
|
||||
|
||||
@@ -119,7 +119,7 @@ Sin embargo, medidas de mitigación como **Open Policy Agent GateKeeper** pueden
|
||||
|
||||
Para eludir las reglas de GateKeeper y establecer esta etiqueta para ejecutar una toma de control del clúster, **los atacantes necesitarían identificar métodos alternativos.**
|
||||
|
||||
## References
|
||||
## Referencias
|
||||
|
||||
- [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)
|
||||
|
||||
@@ -2,21 +2,21 @@
|
||||
|
||||
**El autor original de esta página es** [**Haroun**](https://www.linkedin.com/in/haroun-al-mounayar-571830211)
|
||||
|
||||
### ¿Qué es tekton?
|
||||
### Qué es tekton
|
||||
|
||||
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. 
|
||||
Según la documentación: _Tekton es un marco de código abierto poderoso y flexible para crear sistemas CI/CD, permitiendo a los desarrolladores construir, probar y desplegar en proveedores de nube y sistemas locales._ Tanto Jenkins como Tekton se pueden usar para probar, construir y desplegar aplicaciones, sin embargo, Tekton es Cloud Native. 
|
||||
|
||||
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`.
|
||||
|
||||
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.
|
||||
Cuando se instala tekton, 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}}
|
||||
|
||||
### Las capacidades de la cuenta de servicio de Pipeline
|
||||
### Las capacidades de la cuenta de servicio del 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.
|
||||
Por defecto, la cuenta de servicio del pipeline puede usar la capacidad `pipelines-scc`. Esto se debe a la configuración predeterminada global 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
|
||||
@@ -30,11 +30,11 @@ 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`.
|
||||
En cualquier espacio de nombres, si puedes obtener el token de la cuenta de servicio del pipeline, podrás usar `pipelines-scc`.
|
||||
|
||||
### La Misconfiguración
|
||||
### La mala configuració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:
|
||||
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 espacio de nombres. Por ejemplo, si puedo crear un espacio de nombres con la siguiente definición yaml:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Namespace
|
||||
|
||||
@@ -4,18 +4,18 @@
|
||||
|
||||
## Definición
|
||||
|
||||
En el contexto de OpenShift, SCC significa **Security Context Constraints**. Las Security Context Constraints son políticas que controlan los permisos para los pods que se ejecutan en los clústeres de OpenShift. Definen los parámetros de seguridad bajo los cuales se permite que un pod se ejecute, incluyendo qué acciones puede realizar y qué recursos puede acceder.
|
||||
En el contexto de OpenShift, SCC significa **Security Context Constraints**. Los Security Context Constraints son políticas que controlan los permisos para los pods que se ejecutan en los clústeres de OpenShift. Definen los parámetros de seguridad bajo los cuales se permite que un pod se ejecute, incluyendo qué acciones puede realizar y qué recursos puede acceder.
|
||||
|
||||
Las SCC ayudan a los administradores a hacer cumplir las políticas de seguridad en todo el clúster, asegurando que los pods se ejecuten con los permisos apropiados y cumplan con los estándares de seguridad organizacionales. Estas restricciones pueden especificar varios aspectos de la seguridad del pod, tales como:
|
||||
Los SCC ayudan a los administradores a hacer cumplir las políticas de seguridad en todo el clúster, asegurando que los pods se ejecuten con los permisos apropiados y cumplan con los estándares de seguridad organizacionales. Estas restricciones pueden especificar varios aspectos de la seguridad del pod, tales como:
|
||||
|
||||
1. Capacidades de Linux: Limitando las capacidades disponibles para los contenedores, como la capacidad de realizar acciones privilegiadas.
|
||||
2. Contexto SELinux: Haciendo cumplir los contextos SELinux para los contenedores, que definen cómo los procesos interactúan con los recursos en el sistema.
|
||||
3. Sistema de archivos raíz de solo lectura: Impidiendo que los contenedores modifiquen archivos en ciertos directorios.
|
||||
3. Sistema de archivos raíz de solo lectura: Previniendo que los contenedores modifiquen archivos en ciertos directorios.
|
||||
4. Directorios y volúmenes de host permitidos: Especificando qué directorios y volúmenes de host puede montar un pod.
|
||||
5. Ejecutar como UID/GID: Especificando los IDs de usuario y grupo bajo los cuales se ejecuta el proceso del contenedor.
|
||||
6. Políticas de red: Controlando el acceso a la red para los pods, como restringir el tráfico de salida.
|
||||
|
||||
Al configurar las SCC, los administradores pueden asegurarse de que los pods se ejecuten con el nivel apropiado de aislamiento de seguridad y controles de acceso, reduciendo el riesgo de vulnerabilidades de seguridad o acceso no autorizado dentro del clúster.
|
||||
Al configurar los SCC, los administradores pueden asegurarse de que los pods se ejecuten con el nivel apropiado de aislamiento de seguridad y controles de acceso, reduciendo el riesgo de vulnerabilidades de seguridad o acceso no autorizado dentro del clúster.
|
||||
|
||||
Básicamente, cada vez que se solicita un despliegue de pod, se ejecuta un proceso de admisión como el siguiente:
|
||||
|
||||
@@ -27,9 +27,9 @@ Esta capa de seguridad adicional por defecto prohíbe la creación de pods privi
|
||||
../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/pod-escape-privileges.md
|
||||
{{#endref}}
|
||||
|
||||
## Lista SCC
|
||||
## Lista de SCC
|
||||
|
||||
Para listar todas las SCC con el cliente de Openshift:
|
||||
Para listar todos los SCC con el cliente de Openshift:
|
||||
```bash
|
||||
$ oc get scc #List all the SCCs
|
||||
|
||||
@@ -37,11 +37,11 @@ $ oc auth can-i --list | grep securitycontextconstraints #Which scc user can use
|
||||
|
||||
$ oc describe scc $SCC #Check SCC definitions
|
||||
```
|
||||
Todos los usuarios tienen acceso a los SCC predeterminados "**restricted**" y "**restricted-v2**", que son los SCC más estrictos.
|
||||
Todos los usuarios tienen acceso a la SCC predeterminada "**restricted**" y "**restricted-v2**", que son las SCC más estrictas.
|
||||
|
||||
## Usar SCC
|
||||
|
||||
El SCC utilizado para un pod se define dentro de una anotación:
|
||||
La SCC utilizada para un pod se define dentro de una anotación:
|
||||
```bash
|
||||
$ oc get pod MYPOD -o yaml | grep scc
|
||||
openshift.io/scc: privileged
|
||||
@@ -51,7 +51,7 @@ Cuando un usuario tiene acceso a múltiples SCCs, el sistema utilizará el que s
|
||||
$ 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
|
||||
```
|
||||
## SCC Bypass
|
||||
## Bypass de SCC
|
||||
|
||||
{{#ref}}
|
||||
openshift-privilege-escalation/openshift-scc-bypass.md
|
||||
|
||||
Reference in New Issue
Block a user