System-Level Domain Restriction

Users can define system-level domain restrictions directly in the gateway_config.yaml file using allowed_domains and blocked_domains configurations. This feature enables broad, global control over domain access without requiring complex flow definitions. It provides a simpler, declarative way to specify domain allow/block lists, acting as a first line of defense before requests are processed by specific flows or processors.

System-Level Configuration through gateway_config.yaml

/etc/lunar-proxy/gateway_config.yaml

allowed_domains:
  - "^httpbin\\.org$"
  - "^([a-zA-Z0-9-]+\\.)?example\\.com$"

blocked_domains:
  - "^google\\.com$"
  - "^([a-zA-Z0-9-]+\\.)?malicious-site\\.com$"

How It Works

• allowed_domains: Defines a list of regular expressions for domains that are explicitly permitted. If allowed_domains is specified, any request to a domain not matching these patterns is blocked by default.
• blocked_domains: Defines a list of regular expressions for domains that are explicitly denied access. These domains are blocked regardless of any entries in allowed_domains.

Default Behavior of Domain Restrictions

• If allowed_domains is not defined: All domains are allowed by default.
• If allowed_domains is defined: Any domain not matching an entry in allowed_domains will be blocked.
• If blocked_domains is not defined: No domains are blocked by default.

note

If you make changes to gateway_config.yaml after the container is already running, you must reload the configuration for the changes to take effect. Run the following command:

docker exec lunar-proxy load_flows

Key Benefits of System-Level Domain Restriction

• Global Enforcement: The configuration applies to all API traffic at the proxy level, offering a broad, system-wide restriction on domain access.
• Simpler Setup: It requires fewer configurations compared to defining a domain access control flow, making it easier to manage.
• Efficiency: The system-level check is performed before any flow processing, reducing overhead by filtering unwanted requests early in the processing pipeline.
• Declarative Configuration: Allows users to quickly declare domain rules without writing complex flow logic.

Comparison with Domain Access Control Flow

Aspect	System-Level Domain Restriction	Domain Access Control Flow
Scope	Global, affecting all API traffic handled by the proxy.	Flow-specific, tailored to specific API streams or conditions.
Configuration Location	Defined in gateway_config.yaml.	Defined in individual flow files flows/flow.yaml.
Setup Complexity	Simple and declarative configuration.	Requires defining flows, processors, and conditions, which can be more complex.
Flexibility	Matches based on domain regex patterns only.	Offers dynamic filtering based on headers, request methods, and additional conditions.
Processing Overhead	Minimal, as it performs domain checks at the system level before any flow processing.	Higher, due to additional evaluation within the flow processors.
Use Case	Suitable for broad, static domain restrictions (e.g., blocking known malicious domains globally).	Ideal for context-specific access control, such as conditional blocking based on request headers or user roles.
Response Handling	Requests are blocked early without invoking any flow processors.	Allows custom responses and actions via GenerateResponse processor in the flow.

When to Use Each Approach

• Use System-Level Restrictio when you need a simple, global allow/block list that applies universally to all traffic. This is ideal for scenarios where specific domains need to be blocked across the board (e.g., known malicious domains).
• Use Domain Access Control Flow when you require more granular control based on request attributes or need to apply different access rules depending on the API stream or specific user contexts.