Skip to main content

NoCode Policy Builder

In the following documentation, we will explore the utilization of StackGuardian's NoCode Policy Builder for crafting policies. Additionally, we will delve into the various provider types, operation types, conditions, and understand the significance of the error tolerance value, along with guidelines for its application.

Setting Rules​

Following the steps below will enable you to create a new policy and set rules:

  1. Navigate through Orchestrator > Policies > Create Policy.
  2. Scope Selection: Determine the policy's scope in the "Meta" tab.
  • Organization Wide: Apply the policy across the entire organization.
  • Workflow Groups: Choose workflow groups from the dropdown to apply policies to particular operational areas.
  • Connectors: For specific AWS Accounts, Azure Subscriptions, or GCP Projects, select the corresponding connector from the dropdown to apply the policy. "Save" after selection.
  1. Next, click on the "Rules" tab and click on "Add new Policy Rule".
  2. Uncheck "Marketplace Policy Template" and from the "Source Config Kind" dropdown, select Tirith (Stackguardian Policy Framework) and "sourceConfigDestKind" as inline.
  3. Scroll down and select the "No Code" option to enable Stackguardian's NoCode Policy Builder.
  4. Choose "Select Provider," click "Add Evaluator," and provide a unique Evaluator Id.

Select Provider​

Stackguardian offers 4 types of Providers:

  1. Terraform Plan: Define and enforce infrastructure configurations using declarative code.
  2. InfraCost: Monitor and manage your cloud spending across multiple services.
  3. SG Workflow (JSON): Automate and validate JSON-based workflows and processes.
  4. Kubernetes: Manage and scale containerized applications using Kubernetes resources.

Let's discuss each of these providers and the operations associated with each of them.

Terraform Plan​

  • Operation Type: Specify the operation to evaluate Terraform configurations. There are several options:

    a) Check for terraform resource attribute: Verify specific attributes of Terraform resources.
    b) Check for terraform action: Check if a resource is being created, deleted (or no-op)
    c) Check for terraform resource count: Assess the number of specific resources.
    d) Check for terraform resource direct references: Make sure one resources is referenced by another resource (i.e. bucket is referenced by lifecycle-policy)
    e) Check for terraform resource direct dependencies: Check for dependencies between resources.

    note

    Select the Cloud Provider and Terraform Resource Type as per the operation types. For direct references, you can use the 'to' or 'by' reference dropdown.

  • Condition Type: Choose how to compare values, with options like Equals, NotEquals, GreaterThan, and LessThan. Additional types provide greater flexibility in defining conditions.

  • Condition Value: Input the expected value for comparison in conditions. For Example: For a GreaterThan condition type, you might set a condition value like '10'.

  • Error Tolerance Value: Determines which values need to be set at deployment, and which can be skipped:

    • 0: All values (Resource Type, Resource Attribute and Condition value) need to be set correctly in the deployment otherwise the policy fails
    • 1: If the specified Resource Type is not present, the policy will be skipped
    • 2: If the Resource Type or the Resource Attribute is not configured, the policy will be skipped

  • Final Expression: Combine different conditions and operations using logical operators. Example: Combine evaluations using "&&" (AND), "||" (OR), and "!" (NOT) for comprehensive checks: "check_id_1 && check_id_2 || !check_id_3".

InfraCost​

  • Operation Type: Define the cost analysis operation, such as Total Monthly Cost or Total Hourly Cost.

  • Cloud Provider: Specify the cloud provider for which the policy applies, e.g., AWS, Azure, GCP.

  • Resource Type: Use the ALL ()* operator for broad policy application across resources, or select specific ones for targeted analysis.

  • Condition Type: Set the comparison method, with choices like Equals, NotEquals, GreaterThan, and LessThan. Example: Use "GreaterThan" to trigger alerts when costs exceed a certain threshold.

  • Condition Value: Specify the benchmark figure for cost evaluations. Example: For "GreaterThan", set a condition value like "$1000" to monitor excessive spending.

  • Final Expression: Construct a logical formula combining different conditions and operations. Example: "total_monthly_cost > $1000 && total_hourly_cost < $50" evaluates whether monthly costs are too high while maintaining lower hourly expenses.

SG Workflow (JSON)​

Operation Type: Focuses on retrieving specific values within JSON structures, as demonstrated by the "Get Value" operation.

Workflow Attribute: Delve into specific JSON workflow attributes. Example, "TerraformConfig.driftCheck" is targeted to verify the activation status of Terraform Drift.

Condition Type: Set up conditions to assess the workflow attributes. Example: An "Equals" condition is used to check if "TerraformConfig.driftCheck" is set to true, indicating that Terraform Drift activation is required.

Condition Value: Specify the precise value that the condition must meet. Example: For ensuring Terraform Drift is active, the condition value is set to true.

Final Expression: Combine multiple conditions and operations using logical expressions to define complex policy rules. Instead of crafting a single condition, evaluators like "eval-id-1" can be logically combined with others using "&&" (AND), "||" (OR), and "!" (NOT). Example: If you have two evaluators, evaluator1 for checking drift activation and evaluator2 for another condition, a possible expression could be "evaluator1 && evaluator2", ensuring both conditions must be true for the policy to apply.

Kubernetes​

  • Operation Type: Specifies the action on Kubernetes resource attributes, notably as an "Attribute."
  • Kubernetes Kind: Relates to "Pod" resources specifically.
  • Attribute: Example: spec.containers.*.livenessProbe, which ensures all containers have defined liveness probes.
  • Condition Type: Illustrates various condition types, with an example: "Contains," to check for the presence of certain settings.
  • Condition Value: Specify the expected condition value, e.g., "null," to verify that every container has a liveness probe configured.
  • Final Expression: Example: !kinds_have_null_liveness_probe, which represents the policy rule to enforce the existence of liveness probes in Pods for standard compliance.