# Inicio rápido de Egress CI

> Pon el tráfico de salida de un job de GitHub Actions detrás de una lista de permitidos con la acción OpenWAF Egress CI, primero en audit y después en enforce.

OpenWAF Egress CI es una GitHub Action, [`openwaf-dev/egress-action`](https://github.com/openwaf-dev/egress-action), 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](https://developers.openwaf.dev/es/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](https://developers.openwaf.dev/es/egress/ci/send-events/). Es una beta en acceso anticipado, con licencia Apache 2.0, y está en el [GitHub Marketplace](https://github.com/marketplace/actions/openwaf-egress-ci).

## Antes de empezar

- **Un runner Linux**, x64 o arm64. Los runners Ubuntu de GitHub funcionan tal cual. En un [runner self-hosted](https://developers.openwaf.dev/es/egress/ci/self-hosted-runners/), el usuario del job necesita `sudo` sin contraseña o acceso al daemon de Docker, y el host necesita `nft` (nftables) e `ip` (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.

```yaml
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 test
```

En 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

```yaml
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.org
```

`github-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](https://developers.openwaf.dev/es/egress/ci/reference/).

## 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:

```text
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](https://developers.openwaf.dev/es/egress/ci/audit-to-enforce/) lo explica paso a paso.

## Siguientes pasos

- [Referencia de egress.yml](https://developers.openwaf.dev/es/egress/ci/reference/): cada clave de la política, cada entrada de la acción y lo que deja preparado para el job.
- [Docker y builds](https://developers.openwaf.dev/es/egress/ci/docker/): contenedores, `docker build` y pulls de imágenes bajo la misma política.
- [Inspección y DLP](https://developers.openwaf.dev/es/egress/ci/inspect-and-dlp/): qué peticiones se revisan en busca de secretos y el compromiso del TLS.
- [Límites](https://developers.openwaf.dev/es/egress/ci/limits/): qué cubre la acción y qué no.


Escrito a partir de [github.com/openwaf-dev/egress-action@v0.3.2](https://github.com/openwaf-dev/egress-action/tree/v0.3.2).