Egress CI revisa lo que envía un job en busca de secretos con los detectores de fugas de datos de la pasarela OpenWAF Egress. En enforce, una petición que lleva uno se rechaza; en audit pasa y el resumen lista la detección.
Qué se detecta
| Id de detección | Qué |
|---|---|
dlp.private_key | Una clave privada PEM (-----BEGIN … PRIVATE KEY-----) |
dlp.aws_access_key | Un id de clave de acceso de AWS |
dlp.openai_key | Una clave sk- al estilo de OpenAI |
dlp.github_token | Un token de GitHub, salvo cuando va a GitHub (github.com, githubusercontent.com, ghcr.io, githubapp.com y sus subdominios), donde se espera el token del propio job |
dlp.credit_card | Un número de tarjeta de pago que pasa la comprobación de Luhn |
dns.high_entropy_label | Una etiqueta DNS de 40 caracteres o más con mucha entropía: datos codificados en un nombre |
dns.long_name | Un nombre de 150 caracteres o más |
tls.sni_mismatch | Un CONNECT cuyo SNI de TLS nombra un host fuera de la política |
Las detecciones dns. se marcan, pero no se rechazan por sí solas: el nombre se responde o se rechaza según la política. Un secreto dentro de un nombre DNS o del host de un CONNECT (dlp.… sobre el nombre) se detecta en cualquier destino, porque el nombre se ve sin descifrar nada.
Qué se revisa
| Petición | Qué se revisa |
|---|---|
HTTP en claro por HTTPS_PROXY/HTTP_PROXY | URL, cabeceras y cuerpo |
| HTTP en claro capturado por el bloqueo (una herramienta que ignora el proxy) | Los primeros bytes de la conexión: línea de petición, cabeceras y el principio del cuerpo |
HTTPS a un host de inspect, por HTTPS_PROXY | URL, cabeceras y cuerpo de cada petición |
| Cualquier otro HTTPS | Solo el nombre (host del CONNECT, SNI, nombre DNS), no el contenido |
Los cuerpos se revisan enteros hasta 4 MiB. Los más grandes, y los binarios (application/octet-stream, image/*, video/*, zip, gzip, tar), pasan sin revisar, y el evento lo indica.
inspect
allow:
- api.staging.example.com
inspect:
- api.staging.example.comPara un host de inspect, el proxy termina el TLS del job con un certificado emitido por una CA creada para la ejecución, revisa cada petición y la reenvía por una conexión TLS nueva al host real, cuyo certificado verifica como siempre. La inspección funciona en HTTP/1.1 (el proxy solo ofrece http/1.1 en ALPN) y en las conexiones hechas por HTTPS_PROXY; una herramienta que ignora las variables de proxy llega al host por el proxy transparente, que comprueba el nombre pero no descifra.
Para que el job confíe en la CA de la ejecución, la acción escribe su certificado en $RUNNER_TEMP/egress-ci/ca.pem y un bundle con las CA del sistema, y deja estas variables:
| Variable | La leen |
|---|---|
NODE_EXTRA_CA_CERTS | Node.js |
SSL_CERT_FILE | Las herramientas basadas en OpenSSL, Go, Ruby, el módulo ssl de Python |
REQUESTS_CA_BUNDLE | Python Requests |
CURL_CA_BUNDLE | curl |
GIT_SSL_CAINFO | Git |
El compromiso del TLS
Inspeccionar significa que el job acepta una CA capaz de firmar un certificado para cualquier nombre mientras dura la ejecución. La acción limita lo que eso cuesta:
- La CA se crea al principio de cada ejecución, vale 12 horas y solo para esa ejecución. Su clave privada nunca sale de la memoria del sidecar; solo se escribe el certificado.
- Solo firma certificados para los hosts de
inspect; cualquier otra conexión HTTPS sigue siendo un túnel opaco. - El sidecar sigue verificando el certificado del host real, así que inspeccionar no te oculta un certificado malo: la petición falla.
Y lo que no resuelve:
- Las herramientas con su propio almacén de confianza (el
cacertsde una JVM, algunos gestores de paquetes) o con pinning de certificados fallan en los hosts inspeccionados. Deja esos hosts fuera deinspect. - Los contenedores no reciben las variables; la inspección es para los pasos del propio job.
- Sin
inspect, el contenido de las peticiones HTTPS no se ve nunca. Un secreto enviado por HTTPS a un host permitido no se detecta: la lista de permitidos es el control principal, y el DLP es una segunda línea para el HTTP en claro y para los hosts que elijas inspeccionar.
Inspecciona los hosts donde un secreto en un cuerpo importaría y a los que tus herramientas llegan por el proxy: una API de staging a la que tus tests hacen POST, un webhook, un endpoint de artefactos o de telemetría. No inspecciones los registries ni GitHub.