Agent Overview

This is an older version of the document. To view the most recent version of the document, click here.

OpsMx Agent consists of two main components. An Agent and a Controller. A "controller" runs outside of the customers firewall typically in the same cluster as that of OpsMx ISD's SaaS offering, and an Agent runs in the customers VPC / firewall. The agent is configured to communicate with specific services (Kubernetes, Jenkins etc) within a customer's security domain.

The Agent is deployed with a manifest provided by OpsMx. This manifest has per-installation credentials to authenticate the Agent to the Controller, the Controller address, etc. The Agent requires very limited resources. Services are configured in the Agent by the customer (refer the Agent Service Configuration page). URL endpoints and ISD account names are specified in the Agent configuration, and sent to the Controller to identify a specific service within ISD.

Agent Controller

OES system receives service information from the controller, and allows an administrator to connect a service with a Spinnaker instance. Per-service health is provided, as well as overall agent health.

The controller provides credentials for Spinnaker to connect to a service, and routes the request to the proper agent for handling.

Agent Security

All communication is over TLS (HTTPS), using mutual TLS where possible. Agent-side credentials are never transmitted to OpsMX. The controller maintains its own certificate authority, and issues certificates for agents, and credentials for spinnaker to use to identity specific services.

The controller also provides a "command" API that ISD uses to monitor and to generate certificates for agents and credentials for services. Services can be adopted into Spinnaker manually or automatically.

Architecture Diagram