Skip to main content

Overview

The Runops agent is a small, reliable, and cross-platform task runner, making it easy to run tasks on your infrastructure. Its primary responsibilities are polling Runops for work, running tasks, and reporting the task's status code and output log.

How it works#

The agent works by polling Runops' infrastructure over HTTPS. There is no need to forward ports or provide incoming firewall access. You can run the agents 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 posting the final exit status.

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:

  • Keep all your data and secrets in your cloud account.
  • Run Tasks on Targets in private networks

The agent running inside your infrastructure ensures that any credentials to your internal systems or access results with potentially sensitive data never leave your infrastructure.

After polling a task from the Runops API, the agent queries your Secrets Management solution to get temporary access to the credentials.

You can use Hashicorp Vault, AWS Secrets Manager, and GCP Secrets. Alternatively, you can use Kubernetes Secrets to store credentials when you deploy the agent to Kubernetes.

The agent will then perform the access and notify the API. The Agent redacts any PII data from the logs and only then forwards the result to the user.

You can use multiple agents to access different networks and environments. You add tags to Agents that tell them which tasks they should fetch from the Runops API.

One additional benefit from this architecture is that you don't need a VPN to access resources in private networks.

Summary#

  • Self-host agents to access private networks.
  • Improved security by keeping secrets on-premises.
  • Shutdown your VPN.

AWS Reference Architecture#

Here is what it would look like to run the Agent in AWS.

Security#

The primary design constraint for Runops is to make sure your sensitive data never leaves your infrastructure. Credentials stay in your Secrets Management tool. Access results are redacted before they get sent to users.

We make sure every component of our infrastructure uses the highest security and compliance standards. Here is how every element of the Runops API infrastructure behaves:

Storage#

All our storage mechanisms are encrypted. Additionally, data transferred to and from Runops' backend database is encrypted using TLS.

Network#

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.

Compliance#

If you need help during compliance audits, please reach out. The Runops team has experience going through all the major certifications. We can help you get the data you need to certify the Runops architecture during audits. Below is an overview of how Runops impacts some certifications and regulations.

PCI#

Runops don't access card data. Runops-managed components are out of the PCI scope. The only component that may access card data is the Runops agent that runs inside your infrastructure. It's an open-source application that you can apply the same controls you have for your internal PCI-scoped applications.

Let's dive deeper. To understand how this is possible you need to understand that the Runops architecture has two parts:

  1. the Runops Agent is a component that runs inside your infrastructure and is where you set all the configurations on CDE access, and
  2. the Runops API, which backs user interfaces, chatbot integrations, webhooks, and others. There are no configurations you can make in the Runops API (hosted by us) that have impacts on the CDE.
tip

Runops is a super fast way to comply with PCI requirement 6.4.3, lern more here.

Runops Access Flow#

  1. When a user makes an access request the Runops API makes it available to the agent to pull. The Agent pulls exections as they become available in the API

  2. Once the Agent finds an execution for that environment in the API it proceeds to checking the user identity. The Agent checks the signatura of the JWT generated by the session of the user that initiated the request against the JWK configuration set in the Agent.

  3. After checking the user identity, the agent then asks the Secrets Manager solution for a temporary hold of the credentials to the system being accessed.

  4. With the credentials, the agent executes the access requested by the user against the system.

  5. The results of the execution potentially containing CHD and SAD are sent to the PCI-compliant GCP service for identification and removal of CHD and SAD. The configuration of the DLP is made by the client, or the Agent in this case. If the DLP gets deactivated in GCP, the request will fail and no CHD or SAD leaves the agent.

Google Data Loss Prevention service PCI compliance can be verified here: https://cloud.google.com/security/compliance/pci-dss

  1. 
After ensuring that the access is clean of any CHD or SAD, the agent sends the results back to the API.
tip

The Identity Provider and DLP configurations are set by the Agent hosted by you. It is not possible to change these configurations from outside your infrastructure in any way.

Considering that Runops Agent is already part of your PCI audit process happening inside your infrastructure, we need to analyze how the Runops API impacts the CDE.

Let's analyze the behaviours of the Runops API with the PCI DDS Scoping Categories diagram from the Guidance for PCI DDS Scoping and Network Segmentation document:

drawing

CDE Systems#

drawing

System component stores, processes, or transmits CHD,SAD#

No Runops component stores CHD or SAD. The Runops Agent processes and transmits, but removes this data through the DLP process using a PCI compliant service before communicating with the Runops API. The Runops API doesn't stores, processes, or transmits CHD,SAD.

System component is on the same network segment as system(s) that store, processes, or transmit cardholder data.#

The Runops API isn't part or has any connections to your network. The Runops Agent is the component actively connecting to the API to request work. There is no communication from the API to Agents. Only from the Agent (which is part of your PCI scope) to the API.

Connected-to or Security-impacting Systems#

drawing

System component directly connects to CDE#

Runops API has no direct connections to CDE. The Runops Agent could have direct access to CDE depending on your setup, but the agent is part of your PCI scope. The Agent is the component communicating with the Runops-hosted API. There are no communications from the API to the Agent.

System component indirectly connects to CDE#

Runops API has no indirect connections to CDE. The Runops Agent could have indirect access to CDE depending on your setup, but the agent is part of your PCI scope. The Agent is the component communicating with the Runops-hosted API. There are no communications from the API to the Agent.

System component impacts configuration or security of the CDE#

All configurations impacting CDE stay inside the Agent. Namely:

  1. Managing credentials of CDE systems
  2. Identity verification: ensuring that any interaction with CDE was initiated by an authorized user
  3. Data Loss Prevention: ensuring that any CHD or SAD won't leave the CDE

Considering that all configurations impacting CDE systems are kept inside your Agent, there are no impacts to the security of the environment that could be created by the Runops-hosted API.

System component providers security services to the CDE#

The component providing security to CDE services is the Runops Agent. The Runops API only builds on top of metadata generated by the Agent, clean of any CHD or SAD.

System component segments CDE systems from out-of-scope systems and networks#

This is a great definition of what the Runops Agent does. The Runops API is out-of-scope exactly because of this behaviour. The Agent executes all the CDE-related work, isolating it from all other systems, including the Runops API.

System component supports PCI DDS requirements#

There is a bit of work on your side on this requirement. You can't use the Runops API as the source of truth for you audit events. So, you need to use Runops webhooks to send these events in real-time to your SIEM used to back the PCI auditing.

Out-of-Scope Systems#

System component does NOT store, process, or transmit CHD,SAD#

The open-source and self-hosted Runops Agent removes all CHD and SAD before communicating with the Runops-hosted API.

System component is NOT in the same network segment as systems that store, process, or transmit CHD,SAD#

The Runops-hosted API is inside a Runops-hosted network.

System component cannot connect to any system in the CDE#

The Runops-hosted API has not connection to the customers' premises or networks. The Runops Agent (self-hosted) is the component connecting to the Runops API.

System component cannot connect to any system in the CDE#

The Runops-hosted API has not connection to the customers' premises or networks. The Runops Agent (self-hosted) is the component connecting to the Runops API.

System component does NOT meet any criteria described for connected-to or security-impacting systems#

The Runops-hosted API does NOT meet these criteria as detailed in the Connected-to or Security-impacting Systems section of this document.

GDPR#

Runops helps you adhere to GDPR. The automatic redacting of any Personally Identifiable Information (PII) data from human data access drastically reduces the risks of a leak while keeping your existing workflows in place.

SOC2#

Runops has all the SOC2 Type 1 and Type 2 systems requirements in place. We are working on the policies and should be ready for the audit soon. If you need more information on our stage in the certification process, please reach out. Runops is not yet SOC2 certified.

Summary#

  • Credentials of your internal systems never leave your infrastructure.
  • Tasks results with potentially sensitive data are redacted before reaching Runops servers and the users.
  • Despite not accessing sensitive data, the Runops API applies the highest standards of security and compliance.