Setting up Workload Automation Agent with HTTPS in OpenShift to work with AutoSys

Products

• Workload Automation Agent

Issue/Introduction

When deploying the Workload Automation Agent in an OpenShift environment using HTTPS, connectivity issues often arise due to firewall restrictions, certificate mismatches between build-time and runtime, or incorrect route configurations. This document outlines the findings from a successful deployment involving mutual TLS (mTLS) and custom certificate bundles.

Attempts to connect the AutoSys Manager to an agent deployed in OpenShift via HTTPS result in "503 Service Unavailable" or timeout errors. Common symptoms include:

• curl commands from the manager to the agent route failing with 503 errors.
• autoping failure despite the pod appearing to be "Running."
• successful local connectivity within the pod but failed external ingress.

Cause

Detailed analysis of the containerized deployment revealed three primary areas of divergence:

1. Certificate Layer Conflict: Certificates baked into the image at build-time (via unix_installer.properties) were being silently overridden at runtime by agentparm.txt pointing to Secret-mounted volumes.
2. Network Configuration: External firewalls (on-prem) were blocking traffic between the agent and the manager on specific communication ports.
3. Probing Logic: Standard HTTP health/ready probes fail when clientauthrequired=true (mTLS) is enabled because the OpenShift ingress/prober lacks the required client certificate.

Resolution

• Port and Connectivity Management

Dual Port Support: If you need to support both legacy TCP (e.g., port 7520) and HTTPS (e.g., port 8443), you must define two separate machine definitions in the manager—one for each protocol.
Firewall Rules: Ensure on-prem firewalls allow traffic for as_server and event_demon ports from the agent back to the manager.

• Runtime Certificate Configuration

Prioritize Secrets: Use OpenShift Secrets to project certificates into the pod at /tmp/WA_AGENT/.
ConfigMap Alignment: Ensure agentparm.txt (delivered via ConfigMap) explicitly points to these mounted secret paths (agent-server.p12, truststore.p12). Note that runtime settings in agentparm.txt will supersede build-time settings in unix_installer.properties.

• Health Check Adjustments (OpenShift)

When using mTLS (clientauthrequired=true), standard httpGet probes will fail.
Solution: Downgrade to tcpSocket checks in the StatefulSet for the agent's listening port (e.g., 8443) to ensure the pod is marked as healthy without requiring certificate-based authentication for the probe.

• Route Verification

Verify the ingress route matches the agent_uri defined in the machine definition.
Test connectivity using curl from the scheduler server with the appropriate client

curl --cert [client_cert_path] --key [client_key_path] -v https://[agent-route-url]

 

Additional Information

To speak with a customer representative or a Support Engineer see Contact Support. Scroll to the bottom of the page and click on the respective region.