Design a unified allowlisting mechanism for Kedro components

[ElenaKhaustova]

Goal

Investigate and document a consistent approach to allowlisting external sources for config and code loading across Kedro, rather than solving it component-by-component.

Context

Two separate efforts have tackled the same underlying problem independently:

• OmegaConfigLoader (#5636) — proposes allowed_schemes / allowed_hosts constructor params to restrict remote conf_source URLs.
• HTTP Server runner validation (#5568, re-added in #5576) — validates runner modules against settings.RUNNER_MODULES_WHITELIST before importing. This is already live on main.

Both solve "restrict what Kedro will load from external sources at runtime" but with completely different APIs and mechanisms. The runner validation uses a settings.py entry (RUNNER_MODULES_WHITELIST), while the config loader proposal uses constructor parameters. The main concern is that we don't want to end up with N different allowlist patterns across N components.

Scope

This spike covers allowlisting for config sources and module/code loading. These share the same threat model: an attacker who controls what Kedro loads can alter pipeline behavior or achieve code execution.

Catalog/dataset allowlisting is explicitly out of scope. Reasons:

• The catalog is defined in config. If config sources are locked down, an attacker cannot inject malicious dataset entries.
• The SSRF/RCE chain from the security report requires config control as the first step — blocking that kills the rest of the chain.
• Data source restriction is a platform/infrastructure concern best handled by IAM, credential scoping, and network segmentation rather than framework-level validation.
• Edge cases (e.g. multi-tenant platforms accepting user-submitted catalog definitions) are the application's responsibility, not Kedro's.

Questions to answer

1. What components need this? Audit config and code loading paths — config sources, runner modules, plugin modules, hooks, templates, etc.
2. Centralised vs per-component? One global config (e.g. a settings.py entry) vs individual constructor params vs a hybrid.
3. What granularity? Scheme-only, scheme+host, URL prefix, module path prefix?
4. Where does the config live? settings.py, environment variable, dedicated security config, or constructor parameters?
5. Should code loading and config loading share one mechanism or just a consistent API pattern? They have the same threat model but different shapes (URLs vs module paths).
6. Backwards compatibility — default must be "no restriction" so local/single-project workflows aren't affected.

Expected output

A short design doc recommending the approach, API surface, and a set of implementation tickets to follow.

References

• #5636 — Add opt-in URL scheme/host allowlist to OmegaConfigLoader
• #5568 — Validate runner modules before loading for HTTP server