Allow internal service URLs for integrations

Configure an allowlist so that automation orchestrator accepts integration endpoints that use internal OpenShift service URLs.

Before you begin

  • You have oc CLI access to the OpenShift cluster where automation orchestrator is deployed.
  • You have permission to modify Deployment resources in the automation orchestrator namespace.
  • You know the internal service hostnames for Automation Gateway and any other integration endpoints.

About this task

When automation orchestrator runs on the same OpenShift cluster as its integration endpoints, any integration—including Ansible Automation Platform, an LLM provider, or MCP server integrations—can use internal service URLs with .svc hostnames. These hostnames resolve to private cluster addresses that automation orchestrator rejects by default.

If a connection test fails with the following error, you must add the internal hostnames to an allowlist:

Connection test failed
base_url must not resolve to a private, reserved, or cloud metadata address.

Configure the APP_INTEGRATION_URL_ALLOWED_HOSTS environment variable to specify the internal hostnames that automation orchestrator must accept.

Procedure

  1. Identify the internal service hostnames for your integrations.

    For example, if Automation Gateway runs in the aap namespace, the hostname is aap-gateway.aap.svc.cluster.local.

  2. Set the APP_INTEGRATION_URL_ALLOWED_HOSTS environment variable on the backend, worker, and background-worker deployments.

    The value must be a JSON array of hostnames. Include hostnames only. Do not include the URL scheme, port, path, or query string.

    oc set env \
  deployment/automation-orchestrator-backend \
  deployment/automation-orchestrator-worker \
  deployment/automation-orchestrator-background-worker \
  -n orchestrator_namespace \
  'APP_INTEGRATION_URL_ALLOWED_HOSTS=["hostname_1","hostname_2"]'

    Replace orchestrator_namespace with the namespace where automation orchestrator is deployed. Replace hostname_1 and hostname_2 with your internal service hostnames.

    For example:

    oc set env \
  deployment/automation-orchestrator-backend \
  deployment/automation-orchestrator-worker \
  deployment/automation-orchestrator-background-worker \
  -n automation-orchestrator \
  --env='APP_INTEGRATION_URL_ALLOWED_HOSTS=[\"aap-gateway.aap.svc.cluster.local\",\"automation-orchestrator-api.automation-orchestrator.svc.cluster.local\"]'
  3. Verify that all three deployments rolled out successfully. 
    oc rollout status deployment/automation-orchestrator-backend -n orchestrator_namespace
oc rollout status deployment/automation-orchestrator-worker -n orchestrator_namespace
oc rollout status deployment/automation-orchestrator-background-worker -n orchestrator_namespace
  4. Confirm that the environment variable is set on each deployment. 
    oc set env deployment/automation-orchestrator-backend \
  -n orchestrator_namespace --list | grep APP_INTEGRATION_URL_ALLOWED_HOSTS
  5. In the automation orchestrator UI, test the integration connection to verify that the internal service URL is accepted.

What to do next

Important:
  • Apply the setting to all three deployments. If you set the environment variable on only the backend deployment, integration connection tests succeed but workflow executions can fail because workers process integration requests independently.
  • Operator reconciliation can overwrite manual changes. The automation orchestrator operator manages these deployments. Operator upgrades, reconciliation cycles, or redeployments can remove environment variables that you set directly on a Deployment resource. After an operator upgrade, verify that the APP_INTEGRATION_URL_ALLOWED_HOSTS variable is still configured.
  • Keep the allowlist narrow. Add only the specific hostnames that your integrations require. Do not use wildcard entries. A narrow allowlist reduces the risk of unintended access to internal services.