Skip to main content

Introduction to ChaosGuard™

This section introduces you to ChaosGuard and describes how Harness provides RBAC (role-based access control) to users or user groups to access the chaos resources at different levels using ChaosGuard.

What is ChaosGuard?

ChaosGuard, as the name suggests, is an additional level of security that guards chaos experiments from chaos-enabled users (users who have permission to execute chaos experiments).

Advanced environments require higher governance policies, and this level of security aims to minimize the blast radius (or disruption) and mitigate potential security threats from chaos-enabled users with malicious intent. This way, users with permission to execute chaos experiments will be subjected to further levels of security policy enforcement.

The different levels of security policy enforcement include (but are not limited to):

  1. Regulating access to chaos infrastructure (i.e., namespace and clusters) within the environment,
  2. Controlling the types of faults that can be used within these infrastructures,
  3. Freezing runtime permissions accorded for experiment execution within the target infrastructure.

Low-level security governance requirements

The table below elaborates on the regulatory requirements required for advanced environments.

WhatFaults that are allowed or disallowedChaosHub Fault Spec(s)Prevent disruptive faults from being injected
WhereCluster or namespace where the faults will be injectedUser action or Agent manifestProtect critical infrastructure
WhichWorkloads or microservices which will be subjected to faults (Service Names, AppNS, AppLabels)Dynamic or Real-time DiscoveryIsolate faults to lowest possible blast radius
HowThe service account on the Kubernetes cluster that is leveraged to run the fault podsUser Input or Experiment manifestPrevent malicious code or embedded in "custom" faults from running
WhoUsers who are subjected to the above conditionsHarness DB or Identity storeSelective application of conditions to users (for example, contractors, other team members)
WhenThe time window in which chaos is allowed to be executedUser Input or Harness DBMinimize windows for disruptive activity, upon approval/authorization

With ChaosGuard, each experiment run consists of a security step wherein one or more rules are evaluated before execution. Each rule contains one or more conditions describing the constraints specified in the table above. The experiment can proceed only upon a successful evaluation of all the rules.

RBAC at different levels

Harness allows users to exercise fine-grained control, which is sufficient for environments that are local to a team or group. You can perform the following operations:

  1. View/Add (by connecting to the relevant Git repo)/Edit (the access information, refresh durations, etc.)/Delete the chaos artifact sources (ChaosHub).

  2. View/Add (by installing the chaos agent)/Edit/Delete the target infrastructure, where the chaos experiments are carried out (Chaos infrastructure).

  3. View/Add (by selecting fault templates and providing app data)/Edit (fault tunables, validation/probe constraints, execution properties)/Execute (run saved experiments)/Delete the chaos experiments (Chaos Experiment).

  4. View/Add (by selecting one or more experiments against one or more target infrastructures)/Edit (objectives, descriptions, tags, selected experiments)/Delete chaos gamedays.

    fine-grain control

The Harness project admin persona can create a custom role by selecting the desired permissions against the chaos platform resources and binding it to a user.


Next steps