Simplify public-only egress configuration with deny rules or CIDR exclusions
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 30/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Activo
- Stack tecnológico
- go
- Área
- networking, security
Línea de trabajo
No files or tests are named. Start by locating the current CIDRRule and public-egress policy entry points, then read how allowed CIDRs are evaluated and tested. Done requires a decided policy model, documented precedence or exclusion semantics, and implementation with coverage for public and private ranges.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Problem
Allowing public internet access while blocking private networks is cumbersome with the current allow-only API.
CIDRRule only accepts allowed CIDRs. Using 0.0.0.0/0 also allows private addresses, so users must enumerate the remaining address space as many separate prefixes.
Although technically expressible, this is difficult to author, review, and maintain for a common use case.
Possible approaches
Two options could simplify this configuration:
- Explicit deny rules: allow broad address ranges and deny private/internal ranges, with clearly defined precedence.
- CIDR exclusions: allow a broad CIDR with an except list that removes specified ranges from that match.
Would either approach fit the intended policy model, or is there another recommended way to express public-only access?
- Lenguaje dominante
- Go
- Estrellas
- 4k
- Forks
- 473
- Merge medio
- 2 d 3 h
- PR fusionados (30 d)
- 265
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de agent-substrate/substrate
-
area/dev-infra area/microVM kind/feature
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
agent-substrate/substrate#1826 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
area/benchmarking kind/feature
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
agent-substrate/substrate#1750 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
atelet: no checkpoint timing breakdown log, so suspend has no stage attribution without OTelAbiertoarea/node area/observability good first issue kind/feature prio/P2
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
agent-substrate/substrate#1647 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
area/demos kind/bug
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100
agent-substrate/substrate#1579 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
area/network kind/bug kind/docs prio/P0
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
agent-substrate/substrate#1525 ·
Los mantenedores suelen responder en 1 día
Todos los issues de agent-substrate/substrate
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
status: ready for dev
Dificultad 1/5 1-3 horas Aptitud para principiantes 92/100
hyperledger-labs/fabric-smart-client#2004 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
apache/datasketches-go#189 ·
Los mantenedores suelen responder en 1 día