Skip to main content
Version: 2.2.x

Securing

opscotch was built to operate in the most securely demanding environments and has been designed with many features to increase its security posture. The single most governing principal of opscotch is to "keep the customers data in the customers network".

Given the nature of opscotch, we've taken as many opportunities to prevent data exfiltration that we can think of - please let us know if you find any!

Encryption​

The opscotch agent employs encryption technology to protect both opscotch and the customer - it means that only opscotch tools can send configurations to the opscotch agent, and only customer secured opscotch agents can read the data (not opscotch staff or partners!).

Keys​

Opscotch encryption use "public-private key" technology: this allows encryption with one key (public) that is unable to decrypt: only the decryption key (private) can do that.

Even though the encryption key is known as a "public" key - it is NOT to be considered public - this is an encryption key and allows anyone with access to the key and opscotch tooling, to be able to send instructions that the opscotch agent will trust.

DO NOT SHARE THE PUBLIC/ENCRYPT KEYS WITH UNTRUSTED PARTIES

Protect keys

Do not share or reuse your keys. Generate new keys for each agent instance - this prevents mistaken deployments.

Bootstrap keys​

The bootstap is a sensitive file that is loaded into the agent at start up: it contains all the customer specific data that is used in conjunction with workflows, like hosts and credentials.

The bootstrap key is used to encrypt bootstraps and host data like credential environment variables.

DO NOT SHARE THE ENCRYPTION OR DECRYPTION KEYS OUTSIDE YOUR ORGANISATION. RESTRICT ACCESS TO THESE KEYS INSIDE YOUR ORGANISATION

Workflow keys​

The workflow is a file that can be authored by 3rd parties other than the customer. The encryption key can be distributed to parties trusted to author workflows, while the decryption key is stored in the bootstrap.

Opscotch keys​

The opscotch tools uses an internal set of keys to protect the contents of files from tampering.

Opscotch double encryption​

opscotch double encryption uses two encryption keys to encrypt data: the workflow key and an opscotch key.

The opscotch encryption key ensures that the data was packaged with opscotch tooling an can only be read by the opscotch agent, and the workflow key encryption ensures that the data will only be read by an agent provided with the corresponding workflow decryption key.

The use of the workflow key means that only the customer's opscotch agent can read the data - not even opscotch engineers with access to the source code could read the data.

Protect keys

RESTRICT ACCESS TO CUSTOMER PRIVATE KEYS. NEVER SHARE CUSTOMER PRIVATE KEYS OUTSIDE YOUR ORGANISATION. .

Separation of control​

Controlling configuration is split into two different files, with different natures of access: bootstrap and workflow.

Bootstrap configuration​

The bootstrap configuration is designed to secure sensitive information and service specific data.

The bootstrap configuration:

  • is authored by the (customer) installer of the opscotch agent.
  • is encrypted with the packaging tool using a customer secret encryption key.
  • contains a workflow private key used to decrypt workflow configurations.
  • applys environment variable substitution.
  • is loaded at agent start up and is immutable while the agent is running.
  • contents are not accessible by the agent workflow context, except for the Host.data which is accessible from workflow authentication context (this is locked down when in Production mode).
    • Host.data accepts double encrypted properties (see here)
    • Host.data applies environment variable substitution (for encrypted credentials not stored in the bootstrap)
  • refers to a workflow configuration - see below.
Use the bootstrap correctly
  • Use the bootstrap for sensitive and service/host specific information
  • Use encrypted credentials/sensitive data
  • Use an encrypted bootstrap file
  • Use environment variables to separate storage of raw bootstrap and sensitive data
  • Store encrypted bootstrap files separate from the the storage of the bootstrap keys
  • Do not leak sensitive data into the workflow by using a data property

Workflow configuration​

The workflow configuration is designed to have no sensitive information or service specific data.

The workflow configuration:

  • is authored by anyone (your team, opscotch consultants, community workflows etc).
  • is considered un-trusted.
  • is packaged by your team or your opscotch consultants.
  • is signed during the packaging stage and will not be loaded by your agent if the signature is not recognised.
  • is encrypted during packaging using opscotch double encryption.

Authentication context​

The workflow authentication context has elevated access to bootstrap host data, but also has restricted capabilities:

  • not permitted to send metrics.
  • not permitted to forward to a non-authentication context (step).
  • in production mode it is not permitted to log anything.
  • any urls, headers or properties set in the authentication context are redacted from logs.
  • decrypts any encrypted host data.
  • is only permitted access to hosts declared as an authenticationHost
Use Authentication Processor
  • Always use Step.authenticationProcessor to perform authentication flows.
  • Use a remote key store if possible with access restricted to the opscotch instance.
  • Use opscotch encrypted secrets.

Production Mode​

The agent is release as two different binaries: Development mode and Production mode. Development mode can not simply be "turned on" - you need to use a different binary.

In production mode:

  • Logging is not permitted from authentication context.
  • Diagnostic logging is only enabled for a time limited period via diagnostic messaging.
  • Workflow flow information is not emitted.
Use Production Mode

Use production mode in production to increase security posture

Access control / internal firewall​

Workflow configurations are not trusted, and do not have access to host information.

Workflow configurations request the agent to execute HTTP calls to hosts, however the workflow can not access the host details: it only refers to a name that the configuration gives it.

Host configuration allows the definition of "access controls" or "URI firewalls" in the form of regular expressions of allowed URI and HTTP methods - this allows the bootstrap to define which HTTP URI and methods are allowed.

Prior to executing HTTP requests, the agent sanitizes headers to remove known attack vectors.

Use Allow List

Always use Host.allowlist to define allowed requests

Logging​

There are various logging precautions to prevent data exfiltration:

  • local logging can be disabled, only using a remote logging platform, or vice-versa.
  • log redaction patterns can be used to mask sensitive data: data set in the authentication processor is automatically redacted.
  • hashing can be used to obfuscate raw data.
  • the audit log will record new metrics, license events, workflow change events, remote logging change events, access attempts to restricted data, flushing of persistence, allow list violations, new headers.
Responsible Logging

Only log what is necessary. Use redaction to remove sensitive data.

Vulnerability Scanned​

The opscotch code base is scanned frequently and prior to each release for known vulnerabilities using Snyk.

opscotch prides itself on having NO currently known vulnerabilities and makes every attempt to remove or neutralize them.

Please contact us for the current list of known vulnerabilities.

Binary File​

The opscotch agent is distributed as a compiled binary file and is extremely difficult to reverse engineer or extract details such as keys from.

Opscotch external precautions​

There are additional precautions that can be taken outside the scope of opscotch to increase your security posture. These include:

  • don't store secrets in plain text in your raw bootstraps, use encrypted properties and/or environment variables
  • restrict access to encryption keys to as few people as possible
  • use network file walls to restrict network access to allowed services