Skip to main content

Overview

The Runops agent is a small, reliable, and cross-platform task runner that makes it easy to run tasks on your own infrastructure. Its main responsibilities are polling Runops for work, running tasks, and reporting back the status code and output log of the task.

How it works#

The agent works by polling Runops' infrastructure over HTTPS. There is no need to forward ports or provide incoming firewall access, and the agents can be run across any number of machines and networks.

The agent starts by registering itself with Runops, and once registered it’s placed into your organization’s agents pool. The agent periodically polls Runops looking for new work, waiting to accept an available job.

After accepting a task the agent will execute the command, streaming back the script’s output and then posting the final exit status.

Runops-hosted agents#

Runops-hosted agents are the default place where your scripts will execute. They run in a secure cloud environment detailed in this guide. There is no work on your side to use them. When you set up your Targets, commands run in these agents if not otherwise specified.

Our hosted agents are fully managed and easy to use. You don't have to worry about security patches, network isolation, monitoring, and others.

We take an extreme approach when it comes to security: the execution of every command or script spins up a fresh new container. Nothing is shared across commands. After execution, everything is destroyed except the result logs, which is what the user needs.

Private Networks#

These agents run in our infrastructure and won't be able to access your private networks. To use our agents the Target must have a public endpoint. They are a great fit for Cloud providers targets like AWS and GCP, as most of their APIs are public. Some of our customers also use them for databases and other resources that have public endpoints. To access private networks, check out the Self-hosted agents.

We don't support allowing access to your Targets using IP allow-lists. The list of IPs is too big and it's challenging to keep your firewall up to date with such a dynamic list without custom automation.

We have early access to proxies and Bastion hosts access using SSH. Let us know if you want to use this feature and we can get your setup.

Summary#

  • Runops-hosted is the default place where tasks run
  • No setup required
  • They can only accesses public endpoints
  • They are ephemeral on the command-level

Self-hosted agents#

Self-hosted agents enable you to deploy Runops agents inside your infrastructure. There are two main reasons why you may want to use them:

  1. Run Tasks on Targets in private networks
  2. Keep your secrets on-premises

The agent architecture is the same for both Runops-hosted and self-hosted agents. As mentioned in this guide, we leverage Github's infrastructure for agents. The agent running inside your infrastructure will be this open-source project. We created a wrapper around this application to make it easier to deploy.

We take an extreme approach when it comes to security: the execution of every command or script spins up a fresh new container. Nothing is shared across commands. After execution, everything is destroyed except the result logs, which is what the user needs.

drawing

To make this work on-premises, you need to set up a separated agent process or container for every Target. You can have target resources such as databases and Kubernetes clusters in multiple private networks. Each agent can be deployed in different environments and will run tasks only from its target resource. We support deployments to Linux hosts, Kubernetes, ECS, and others, as described in the configuration guide.

Summary#

  • Access to private networks
  • Improved security by keeping secrets on-premises
  • Require additional to setup

Security#

We chose Github as the partner to run our agent infrastructure. Github Actions is the secure and flexible environment where scripts and commands run. Every command spins up a new Github Actions job that gets completely destroyed when finished.

We understand that Runops touches sensitive data such as credentials to your cloud resources and databases. For this reason, we designed Runops to remove our own access to this type of data, ensuring only our customers can access and use their own secrets.

Secrets Management#

One of the most important features for us to choose Github was due to the way they manage Secrets. Github secrets:

  1. Are RSA-encrypted in storage
  2. Can only be decrypted by agents during execution

This makes it impossible for anyone to access secrets after they are configured, i.e., secrets are write-only. No one can see the secrets, neither you as a user or anyone at Runops. When adding a new secret to a Target, we make sure that the Runops API only proxies the request to Github's Secrets vault. Our servers don't log, store, or process secrets in any way. The only component that can retrieve and decrypt secrets is the agent. The agent also makes sure that if the user tries to get secrets out in any way, it gets blocked. Users can try to print a secret value, but the agent will mask the result.

Compliance#

Runops runs on top of Github Enterprise. We made sure to choose a solution with all the compliance requirements to delegate this component of Runops. This ensures that you can use Runops and keep all your compliance requirements in place.

GitHub Enterprise Cloud is compliant with AICPA Service Organization (SOC) 1 Type 2 and SOC 2 Type 2—and with IAASB International Standards on Assurance Engagements, ISAE 2000, and ISAE 3402.

Even though Runops doesn't access sensitive or critical data, we make sure every component of our infrastructure uses the highest security and compliance standards. Here is how every component of the Runops API infrastructure behaves:

  • Storage - Runops doesn't store sensitive data or secrets. Our databases and storage mechanisms store metadata and metrics. All our storage mechanisms are encrypted. Additionally, data transferred to and from Runops' backend database is encrypted using TLS.
  • Network - This is the only component that temporarily accesses secrets. They pass through our API when a user configures them. All our traffic uses HTTPS. All data transferred in and out of Runops is encrypted using hardened TLS. Runops is also protected by HTTP Strict Transport Security.
  • Compute - Runops uses Kubernetes with the highest standards of hardening. We use hardened VMs and container images. Our containers run using GKE Sandbox, powered by gVisor, improving isolation security beyond Docker.

Summary#

  • We don't store or have any permanent access to your secrets
  • We use GitHub Enterprise to make sure anything touching sensitive data is compliant
  • We keep secrets in a certified encrypted vault
  • You can use self-hosted agents to keep secrets on-premises
  • Secrets are write-only: users can't access, print, or retrieve secrets during executions
  • We redact result logs before they reach storage
Custom markup