OpenWAF Egress CI es una GitHub Action, openwaf-dev/egress-action (enlace externo), que pone el tráfico de salida de un job de CI detrás de una lista de destinos permitidos. Cada conexión y cada consulta DNS del job y de sus contenedores queda con nombre y registrada. Lo que no está en .github/egress.yml se informa (audit) o se rechaza (enforce), lo que sale se revisa en busca de secretos con los mismos detectores que la pasarela OpenWAF Egress, y el resumen del job lista todos los destinos con los que habló.
Es la versión para CI de la pasarela: una dependencia, un script de build o una acción comprometidos que intenten mandar tus secretos o tu código a otro sitio se encuentran el camino cerrado, y tú ves el intento en el resumen.
La acción funciona como un sidecar dentro del job, en el propio runner. No necesita cuenta de OpenWAF y no envía nada a ningún sitio salvo que actives el envío de eventos a OpenWAF. Es una beta en acceso anticipado, con licencia Apache 2.0, y está en el GitHub Marketplace (enlace externo).
Antes de empezar
- Un runner Linux, x64 o arm64. Los runners Ubuntu de GitHub funcionan tal cual. En un runner self-hosted, el usuario del job necesita
sudosin contraseña o acceso al daemon de Docker, y el host necesitanft(nftables) eip(iproute2). - Permiso de escritura en el workflow y en
.github/del repositorio.
1. Añade la acción
Añádela como primer paso después de actions/checkout. Los pasos anteriores no quedan cubiertos.
name: test
on: [push, pull_request]
permissions:
contents: read
jobs:
test:
runs-on: ubuntu-24.04
steps:
- uses: actions/checkout@v5
- uses: openwaf-dev/egress-action@v0.3.2
- run: make testEn producción, fija el SHA completo del commit de la versión en vez de la etiqueta, con la versión como comentario para que Dependabot pueda actualizarlo: uses: openwaf-dev/egress-action@5a956e8bdeff9c34c13f2277f9096fddc6e6e51a # v0.3.2.
2. Escribe la política
version: 1
mode: audit # solo informa, no rechaza nada
presets: [github-actions] # los nombres que GitHub publica para los runners de Actions
allow:
- proxy.golang.org # puertos 80 y 443
- "*.npmjs.org" # cualquier nombre bajo npmjs.orggithub-actions cubre lo que necesita cualquier job: el servicio del propio runner, el checkout, la API, la caché, el almacenamiento de artefactos y logs, y raw.githubusercontent.com. Todas las claves están en la referencia de egress.yml.
3. Lee el resumen del job
Haz push y abre la ejecución. El resumen del job empieza por OpenWAF Egress CI: audit y una tabla de destinos:
12 destinations, 2 outside the policy (enforce would block them), 0 detections.
| Destination | Ports | Via | Conn. | Up | Down | Policy | Detections |
| proxy.golang.org | 443 | proxy | 3 | 4.1 KiB | 2.3 MiB | allowed | |
| sum.golang.org | 443 | proxy | 1 | 812 B | 6.2 KiB | not allowed | |Via dice por dónde salió la conexión: proxy por HTTPS_PROXY, direct capturada por el bloqueo (una herramienta que ignora las variables de proxy), container desde uno de los contenedores del job, udp para los flujos que no son TCP. En Names outside the policy, el resumen da un bloque allow listo para copiar con todos los nombres que enforce rechazaría.
4. Pasa a enforce
Copia esos nombres en allow, vuelve a ejecutar hasta que el resumen no muestre nada fuera de la política y pon mode: enforce. A partir de ahí, un nombre fuera de la política recibe un 403 del proxy, un NXDOMAIN del DNS o un reset, y el resumen dice cuál y por qué. De audit a enforce lo explica paso a paso.
Siguientes pasos
docker build y pulls de imágenes bajo la misma política.Inspección y DLPqué peticiones se revisan en busca de secretos y el compromiso del TLS.Límitesqué cubre la acción y qué no.Escrito a partir de github.com/openwaf-dev/egress-action@v0.3.2 (enlace externo).