class

Analyzer::Specification::Envoy

Inherits Analyzer::Specification::SpecificationEngine < Analyzer < FileHelper < Reference < Object

Extracts HTTP endpoints from Envoy proxy route configuration files (YAML or JSON). virtual_hosts is collected from wherever it sits in the document, because Envoy nests it differently per layout:

  • at the root (xDS RDS RouteConfiguration)
  • under route_config (standalone static RouteConfiguration)
  • under resources[] (xDS resource array)
  • under static_resources.listeners[].filter_chains[].filters[]. typed_config.route_config (bootstrap config — the everyday shape; 30 of the 31 virtual_hosts YAMLs in envoyproxy/envoy look like this)

For each route the analyzer extracts:

  • Path from match.prefix, match.path, match.path_separated_prefix or match.safe_regex.regex
  • HTTP method from match.headers[] where name: ":method"
  • An additional endpoint for route.prefix_rewrite when it differs from the matched path

Constants

DOMAINS_KEY = YAML::Any.new("domains")
MATCH_KEY = YAML::Any.new("match")
MAX_SEARCH_DEPTH = 32

See the detector's constant of the same name: a bound that only exists so a pathologically nested document can't blow the stack. Real configs sit around depth 8.

ROUTE_KEY = YAML::Any.new("route")
ROUTES_KEY = YAML::Any.new("routes")
VIRTUAL_HOSTS_KEY = YAML::Any.new("virtual_hosts")

Hoisted so the per-node lookups in the walks below do not rebuild the wrappers on every mapping they visit.

Class methods

tech_name
Source

Instance methods

analyze
Source
tech

Instance-side view of the same declaration. The per-file rescues live on this base class, which has no way to name the analyzer that is running inside them, so a skipped file could not be attributed to a tech. Deriving it from analyzer_for keeps the name written exactly once.

Source