Outbound Egress Security
Ragty applies a central, fail-closed egress policy to model-provider and observability endpoints. It prevents an unapproved provider URL from being used by chat, embedding, reranking, provider verification, ingestion strategy providers, or Langfuse.
Host allowlist
The backend accepts built-in vendor and local service hosts. Additional exact hostnames must be supplied by the operator through:
The value is a comma-separated list of hostnames. Wildcards and arbitrary suffix matching are not supported. A URL with credentials, a fragment, a non-HTTP(S) scheme, or a hostname outside the allowlist is rejected before the network client is opened and returns a retryable 503.
Development may use the built-in localhost, litellm, and ollama service names. In production those names are also resolved and must be covered by the configured internal-network allowlist; loopback addresses remain blocked.
Protected application paths
The policy is applied before requests to:
LiteLLM and OpenAI-compatible chat endpoints
OpenAI and Ollama embedding endpoints
Reranking providers
Provider and model verification requests from the administration API
Ingestion strategy providers
Langfuse tracing
The existing connector SSRF layer remains responsible for tenant-controlled connector URLs. It validates every DNS result, pins the validated address, and revalidates manual redirects. See Connectors.
Network and deployment requirements
The application policy is an application-layer control, not a replacement for network egress controls. It protects the supported HTTP client paths, but it cannot prevent a compromised process from opening a different socket or using an unguarded library. In production:
Keep
M8TY_RAGTY_EGRESS_ALLOWED_HOSTSunder operator control; never expose it as tenant configuration.Add every approved private provider hostname explicitly and configure its private CIDR through the existing crawler/internal-network policy where applicable.
Apply default-deny outbound traffic to Ragty backend and worker workloads.
Allow only the required DNS, database, Redis, object-storage, vector-store, model-provider, connector, and observability destinations.
Enforce the allowlist with Kubernetes
NetworkPolicy, a firewall, or a service-mesh egress gateway. Use explicit DNS/IP and port rules; do not use unrestricted0.0.0.0/0egress.Treat a
503with erroregress_deniedas a configuration or policy failure, not as permission to bypass the check.
The exact network rules are deployment-specific. Qdrant, MinIO, model providers, connectors, and Langfuse may be internal or external. The network allowlist and M8TY_RAGTY_EGRESS_ALLOWED_HOSTS must therefore be reviewed together.
CI and deployment ownership
The Ragty application CI pipeline can run unit/integration tests and validate configuration or checked-in deployment manifests. It does not provision the runtime network, install firewall rules, or enforce Kubernetes egress policy. That is a deployment-platform responsibility and must be completed before a production rollout.
After deployment, operations must record evidence for both controls:
Check | Expected result |
|---|---|
Approved provider or service endpoint | Request succeeds when application configuration is valid |
Unapproved application hostname | Request is rejected with |
Network-approved destination | Connection is permitted by the workload policy |
Network-denied destination | Connection is blocked even if application code is bypassed |
Network denial is expected to surface as a failed request. It must not be worked around by adding an unrestricted host, a second HTTP client, or a direct socket. Store the applied policy, approved exceptions, and post-rollout test results as deployment evidence.
Related configuration
See Configuration and Deployment for the complete environment-variable reference and LLM and Model Providers for provider setup.