Configuring Webhook Allow-lists

When you expose Flyte operations via a webhook, you often need to restrict which specific tasks, apps, or triggers can be accessed to prevent unauthorized execution of sensitive workflows. The FlyteWebhookAppEnvironment in flyte-sdk provides built-in allow-list parameters to enforce these restrictions at the API level.

Restricting Task Execution

To limit which tasks can be run or inspected via the webhook, use the task_allowlist parameter. This parameter supports three levels of specificity:

from flyte.app.extras import FlyteWebhookAppEnvironment
import flyte

webhook_env = FlyteWebhookAppEnvironment(
    name="task-restricted-webhook",
    # Supports: "domain/project/name", "project/name", or "name"
    task_allowlist=[
        "production/flyte-examples/core-task",  # Exact match
        "flyte-examples/utility-task",          # Matches any domain
        "global-cleanup-task"                   # Matches any domain and project
    ],
)

The is_task_allowed logic in src/flyte/app/extras/_webhook_app.py evaluates these strings against incoming requests. If a request targets a task not matching any pattern in the list, the webhook returns a 403 Forbidden error.

Restricting App Management

You can control which other Flyte Apps this webhook is allowed to activate, deactivate, or query by providing a list of app names to app_allowlist.

from flyte.app.extras import FlyteWebhookAppEnvironment

webhook_env = FlyteWebhookAppEnvironment(
    name="app-manager-webhook",
    endpoint_groups=["app"],
    # Only allow management of these specific apps
    app_allowlist=["data-ingestion-service", "model-trainer-app"],
)

Note that a FlyteWebhookAppEnvironment is automatically protected from managing itself; it cannot be used to deactivate its own service regardless of the allow-list configuration.

Restricting Trigger Toggling

To restrict which task triggers can be enabled or disabled, use the trigger_allowlist. This supports both specific task-trigger pairs and global trigger name matches.

from flyte.app.extras import FlyteWebhookAppEnvironment

webhook_env = FlyteWebhookAppEnvironment(
    name="trigger-manager-webhook",
    endpoint_groups=["trigger"],
    # Supports: "task_name/trigger_name" or "trigger_name"
    trigger_allowlist=[
        "daily-etl-task/midnight-trigger",  # Specific task/trigger pair
        "manual-override-trigger"           # Matches this trigger name on any task
    ],
)

Comprehensive Configuration Example

In production environments, it is common to combine these allow-lists with specific endpoint_groups to create a least-privilege gateway.

import flyte
from flyte.app.extras import FlyteWebhookAppEnvironment

webhook_env = FlyteWebhookAppEnvironment(
    name="secure-gateway",
    image=flyte.Image.from_debian_base().with_pip_packages("fastapi", "uvicorn"),
    # Enable only core and task operations
    endpoint_groups=["core", "task"],
    # Apply strict allow-lists
    task_allowlist=["production/my-project/secure-task"],
    app_allowlist=["monitoring-app"],
    trigger_allowlist=["secure-task/cron-trigger"]
)

# Deploy the restricted webhook
flyte.serve(webhook_env)

Troubleshooting and Behavior

• Default Behavior: If an allow-list is set to None (the default), all entities of that type are allowed.
• Blocking All Access: If you provide an empty list [], all entities for that category will be blocked.
• Error Responses: When a user attempts to access an entity not in the allow-list, the webhook returns a 403 Forbidden response.
• Configuration Conflicts: Ensure you do not provide both endpoints and endpoint_groups in the constructor, as this will raise a ValueError. Use one to define the API surface and the allow-lists to define the data access.