Argo Workflows

Overview

Argo Workflows is a container-native workflow engine for Kubernetes. Use Pomerium to protect the Argo Workflows UI and API.

Argo Workflows can expose sensitive application data or administrative functions. A Pomerium route adds identity-aware policy before a user reaches the selected endpoint while the service keeps its own detailed permissions.

Pomerium controls who can establish the selected route to Argo Workflows. Argo Workflows remains responsible for its application, protocol, data, and service-level permissions.

How it works

Create a Pomerium HTTPS route for the selected private HTTP endpoint. Configure the application public URL, trusted proxy settings, WebSocket forwarding, and suitable timeouts.

Keep application authentication and granular authorization active. Test interactive terminals, streaming views, agents, and other long-lived connections separately.

Install the official Argo Workflows chart. Use Argo Server server authentication mode. Route the private server through the configured Pomerium Ingress Controller, and make Pomerium the only user-facing path.

Example

A platform team runs Argo Workflows in a private Kubernetes cluster. Pomerium policy limits the Argo Server route to the workflow operators group. Argo Server uses its service account after Pomerium approves the request.

Considerations

• Argo Server server mode uses the Argo Server service account. It does not pass each Pomerium user as a Kubernetes identity.
• Argo CD, Argo Rollouts, and Argo Events need separate route configuration.
• Pomerium checks TCP and WebSocket policy when the connection starts. A later policy change does not terminate an established connection.