When unencrypted traffic leaks between a planner and its executor, an attacker can read secrets, alter job parameters, or inject malicious commands, turning a routine automation into a data breach or a supply‑chain compromise. The financial and reputational cost of such a breach often far exceeds the modest effort required to protect the channel.
Why encryption in transit matters for planner‑executor agents
Planner‑executor architectures typically involve a central scheduler (the planner) that dispatches work to remote workers (the executors). Communication may travel over HTTP, gRPC, or custom TCP streams, and it often carries API keys, database credentials, or proprietary code. If that traffic traverses a public network or an uncontrolled internal segment, it becomes visible to anyone with network access, including compromised hosts, rogue insiders, or misconfigured routers.
Regulatory frameworks and internal policies frequently require that any data crossing a network boundary be encrypted. Even when an organization trusts its internal network, modern threat models assume lateral movement is possible, making encryption a baseline defense rather than an optional hardening step.
Typical setup without a dedicated gateway
In many teams, the planner authenticates to the executor using a static token stored in a configuration file. The executor trusts the token and opens a plain‑text socket. The token is often shared across many jobs, and the connection is left unsecured because the developers assume the internal VLAN is safe. This approach satisfies the immediate need to run jobs but leaves two critical gaps:
- There is no guarantee that the traffic is encrypted; any sniffing tool on the network can capture credentials.
- The static token provides standing access, so any compromised executor can be used to reach other services without additional checks.
Both gaps are addressed only when the communication passes through a controlled data path that can enforce encryption and apply additional guardrails.
How hoop.dev provides encryption in transit
hoop.dev acts as a Layer 7 gateway that sits between the planner and the executor. The gateway terminates TLS, validates the planner’s identity via OIDC or SAML, and then re‑establishes a separate TLS session to the executor. Because the gateway controls both inbound and outbound connections, it can guarantee that every byte traveling between the two parties is encrypted.
When a request arrives, hoop.dev authenticates the caller (the setup phase) and then routes the traffic through its data path. The encryption in transit guarantee originates from hoop.dev, not from the planner’s token or the executor’s host configuration. If hoop.dev were removed, the connection would revert to the insecure plain‑text channel described earlier.
Practical guidance for securing planner‑executor traffic
1. Deploy the hoop.dev gateway close to the executor nodes, preferably on the same subnet, to minimize latency.
2. Configure the gateway with a trusted TLS certificate, either a public‑trusted CA or an internal PKI. Enable mutual TLS if you want the executor to verify the gateway’s identity as well.
3. Use OIDC or SAML to issue short‑lived identity tokens for the planner. The tokens are validated by hoop.dev before any traffic is allowed through. 4. Keep the executor’s service credentials inside hoop.dev; the planner never sees them, reducing credential sprawl. 5. Enable session recording in hoop.dev if you need forensic evidence of what commands were executed.
These steps ensure that encryption in transit is enforced at the gateway, that identity is verified before any data moves, and that credentials remain hidden from the planner process.
Attribution of responsibilities
Setup: Identity providers (OIDC/SAML) issue tokens that identify the planner. This step decides who may start a request but does not encrypt the traffic.
The data path: hoop.dev is the only component that can enforce encryption, because it sits directly in the communication flow between planner and executor.
Enforcement outcomes: hoop.dev encrypts the channel, records each session, and can mask sensitive fields in responses. These outcomes exist solely because hoop.dev occupies the data path.
Getting started
For a step‑by‑step walkthrough of deploying the gateway and configuring TLS, see the getting‑started guide. The learn section contains deeper discussions of identity integration and session replay.
FAQ
- Do I need to manage certificates myself? hoop.dev can use certificates from any standard PKI. You may also rely on automatically generated self‑signed certs for testing, but production deployments should use a trusted CA.
- Will enabling encryption add noticeable latency? The gateway terminates TLS once per connection and re‑establishes it to the executor. In most environments the overhead is a few milliseconds, far outweighed by the security benefit.
- Can I still use my existing planner code? Yes. The planner connects to hoop.dev using the same client libraries (HTTP, gRPC, etc.). No code changes are required beyond pointing the endpoint to the gateway.
Ready to protect your automation pipeline? Explore the open‑source repository on GitHub and start securing planner‑executor traffic with hoop.dev today.
