Política de egress

Una política de egress define qué conexiones de red salientes puede hacer un sistema, por destino (un dominio o un rango de IP), protocolo y puerto, y qué ocurre con todo lo demás. El filtrado de egress es la aplicación de esa política mediante un firewall, un proxy o una política de red. Un firewall de egress es el dispositivo o la función que la aplica.

Permiso por defecto y denegación por defecto

Una política de permiso por defecto bloquea una lista de destinos maliciosos conocidos y deja pasar todo lo demás. Una política de denegación por defecto permite una lista de destinos de confianza conocidos y bloquea el resto. Kubernetes funciona igual: un pod puede llegar a cualquier sitio hasta que una política de red lo selecciona para egress, y a partir de entonces solo a las conexiones que esa política permite (políticas de red de Kubernetes).

Solo la denegación por defecto detiene el tráfico hacia un destino que nadie previó, y el servidor de un atacante es exactamente eso. El coste es operativo: hay que crear una lista de permitidos y mantenerla al día.

Una política de egress con denegación por defecto en Kubernetes

La documentación de Kubernetes ofrece esta política, que selecciona todos los pods de un namespace y no permite tráfico saliente (Kubernetes network policies):

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
spec:
  podSelector: {}
  policyTypes:
    - Egress

También bloquea el DNS, así que las cargas de trabajo que resuelven nombres necesitan una segunda política que permita el tráfico saliente hacia el servicio DNS del clúster. Cada destino permitido se añade después como otra política, por pod, namespace o rango de IP (ipBlock).

Políticas basadas en FQDN

Una NetworkPolicy estándar selecciona pods, namespaces y rangos de IP, no nombres de dominio. Los registros de paquetes están detrás de redes de distribución de contenido cuyas direcciones cambian, así que sus listas de permitidos se escriben por nombre, como políticas basadas en FQDN que añaden algunos plugins de red. Las reglas toFQDNs de Cilium seleccionan un nombre exacto con matchName o un patrón con matchPattern, y aprenden las direcciones de las respuestas DNS que ve su proxy DNS (Cilium DNS-based policies). Calico Cloud y Calico Enterprise indican domains en las reglas de egress que permiten tráfico (Calico DNS policy).

Por qué la CI necesita una

Un job de build guarda claves de despliegue, credenciales de nube y tokens, y ejecuta scripts de instalación de los paquetes que descarga. Una dependencia comprometida puede enviar esos secretos a cualquier sitio al que llegue el runner de CI, que es como se produce la exfiltración de tokens en la CI. La mayoría de los runners permiten todo el tráfico saliente por defecto.

Tome un script postinstall de npm que envía las variables de entorno del job a un host desconocido. Con una política de denegación por defecto que solo permite el registro de npm y su almacén de artefactos, la petición falla y los secretos se quedan en el job.

Qué ve un build cuando la política lo bloquea

La conexión falla y el build informa de un error de red corriente. Según dónde se aplique la política, será una conexión rechazada o reiniciada, un tiempo de espera agotado, una consulta DNS fallida o un error en el handshake TLS, a menudo después de que el gestor de paquetes lo haya reintentado. Para el desarrollador parece un registro inestable, y por eso una buena política de egress registra cada conexión bloqueada con su destino y el motivo.

Qué tener en cuenta

• Destinos tipados. Registros de paquetes indicados como fuentes, no solo como direcciones IP, porque los registros están detrás de redes de distribución de contenidos cuyas direcciones cambian.
• Validada antes de que empiece el job, para que una política rota falle de forma visible en lugar de aplicarse a medias.
• Bloquea si falla, para que, si la aplicación no está disponible, el job no se ejecute sin protección.

Para implantarla en GitHub Actions, consulte la política de egress de GitHub Actions.

CRACI

CRACI aplica una política de egress en el runner, de denegación o de permiso por defecto, con 24 presets integrados de fuentes de software y fuentes personalizadas tipadas para npm, PyPI, apt, apk, el proxy de Go, Nix, Cargo, registros OCI y Git por HTTPS y SSH. La política se valida antes de que empiece el job y, si falla, bloquea; las infracciones generan alertas. El mismo job registra qué paquetes llegaron por las conexiones permitidas. Consulte la comparativa de seguridad de runners.

Cuando la política de CRACI bloquea una conexión, el job ve un fallo corriente, como un 403 Forbidden, una conexión reiniciada, un EOF o un handshake TLS fallido, y la traza de red del job muestra la conexión entre las infracciones del proxy con un motivo, como no_match cuando ningún preset, fuente ni regla coincidió con el destino. La traza se muestra en directo en la vista del job mientras se ejecuta y también está disponible a través de la API (documentación de CRACI: depurar problemas de red).

Para el control de egress en cargas de trabajo de Kubernetes, servidores o runners alojados por GitHub que conserve, use una política de red, un firewall de nube o un agente en el runner: CRACI aplica su política solo en sus propios runners, y un modo de auditoría previo al bloqueo está en su hoja de ruta.