Policy Types

Policies within the StackGuardian platform serve as a set of rules or guardrails, enforceable on workflows or cloud infrastructure. These policies facilitate a self-service model with granular control.

You group rules into Policy Sets. For an introduction, see the Policy Sets overview.

Custom Policy Frameworks

For specialized policy requirements:

• Tirith (StackGuardian Policy Framework), Explore a JSON-based framework designed for IaC & workflow compliance.
• Open Policy Agent, Utilize detailed policy definitions using the Rego language.

Types of Enforceable Policies

StackGuardian's Tirith engine supports a variety of policies for efficient and secure cloud infrastructure management:

1. Infrastructure Policies

• Enforce Terraform best practices and configurations. Example: Enforce VPCs to use default tenancy.

2. Workflow and Stack Policies

• Enforce custom compliance and guardrail rules for Workflows and Stacks with approval processes for security and efficiency. Example: Approval required for changes to production environments.

• Workflow and Stack policies can also be used in conjunction with Context Tags to reference the attributes of a dependent Workflow or Stack in the policy. Example: Block the execution of a Workflow/Stack until a certain Workflow/Stack has a COMPLETED status.

Tip: A policy with an evaluator that uses a ${curr_workflow reference will only apply to Workflows. Similarly, if ${curr_stack is used, it will only apply to Stacks. Generic policies (without these curr_ references) will be applied to both Workflows and Stacks, depending on the Policy Enforcement configuration.

🔗 Click here to view an example of a Workflow Policy using Context Tags.
🔗 Click here to view an example of a Stack Policy using Context Tags.

3. Cost Control Policies (Upcoming)

• Implement budget limits and dynamic cost optimization. Example: Limit EC2 monthly costs to under $100

4. Security and Compliance Policies

• Apply security measures and meet compliance standards (e.g., CIS, PCI DSS). Example: Ensure all security groups block inbound SSH from the public internet.

5. Tagging and Resource Management Policies

• Require consistent tagging for all resources for better management. Example: Enforce 'Environment' and 'Owner' tags on all resources.

6. Drift Detection and Continuous Compliance

• Detect and correct configuration drifts to maintain continuous compliance. Example: Alert on unapproved changes to infrastructure.

Access or subscribe to policies via the StackGuardian Marketplace, or create customized policies using the Open Policy Agent or the StackGuardian Policy Framework.

Policy Structure and Configuration

Scope configuration

The Scope tab of a Policy Set defines where StackGuardian enforces its rules. You can enforce a Policy Set on Workflows, Workflow Groups, Stacks, Connectors, connector groups, or your entire organization. For steps, see Scope. StackGuardian determines the type of each policy automatically and enforces it on the Workflow or infrastructure configuration as appropriate.

Tip: You can use 200+ cloud best practice policies from SGMarketplace, or create your own.

Each Policy Set contains multiple rules that influence a Workflow or Stack run when they're evaluated. The Action when Policy passes and Action when Policy errors settings of each rule determine the outcome. To bypass a rule, turn on Skipped during evaluation.

Implementing Policies

Marketplace Policy Templates

Easily adopt Marketplace templates by subscribing to them within the StackGuardian Marketplace, allowing for a simplified policy application process.

Open Policy Agent Integration

On StackGuardian you will find first class support for Open Policy Agent and you can source your Rego configuration from a GitHub or git based repository.

To add an OPA rule to a Policy Set:

1. Open the Rules tab of the Policy Set and select Add policy rule.
2. Under Select your policy configuration, select Open Policy Agent.
3. Enter a Name for the rule.
4. In Version Control, select Git Others (SSH, Secrets or Public Repo) or one of your VCS connectors. To add a connector, select Add new VCS Connector.
5. In Repository, enter the repository that stores your Rego policies.
6. Optional: In Branch, Tag or Commit, enter a Git reference such as main or v1.0.0. If you leave it empty, StackGuardian uses the default branch.
7. Optional: In Working dir, enter the path to your policies, for example /modules/vm.
8. Optional: In Git Sparse Checkout Config, enter the paths to check out, one per line.
9. Optional: Select Enable git core.autocrlf to convert line endings in text files when they are checked out or committed.
10. Optional: In OPA Deciding Query, enter the rule that StackGuardian uses to decide the final policy result, in the format <opa-package-path>.<rule-name-returning-boolean>. The query must return a boolean. OPA Deciding Query used to be required. It's now optional, and StackGuardian continues to support it as before.
11. Optional: Turn on Pass JSON inputs to provide JSON data in the code editor. StackGuardian passes this data to the OPA runtime as policy data, in addition to the Rego policies fetched from Git. This lets you template your Rego policies and reuse them to build different policies.
12. Under Enforcement, set Action when Policy passes and Action when Policy errors.
13. In the Unsaved changes bar, select Save changes.

Tirith: StackGuardian Policy Framework

The Tirith Policy Framework by StackGuardian offers a user-friendly alternative to OPA for policy enforcement, directly integrating with code editors and planning support for git-based policy management. Designed for simplicity, Tirith facilitates the scanning of Terraform and CloudFormation configurations, making policy definition and enforcement straightforward without delving into complexities. This approach ensures easy compliance with infrastructure policies. For more details, visit the GitHub repository.

Examples

Prevent accidental delete of VPC

Set VPC default tenancy and safeguard EC2 instances against deletion

Using Code-Editor

{
  "meta": {
    "required_provider": "stackguardian/terraform_plan",
    "version": "v1"
  },
  "evaluators": [
    {
      "description": "",
      "condition": {
        "type": "NotEquals",
        "value": "delete",
        "error_tolerance": 1
      },
      "id": "eval-id-1",
      "provider_args": {
        "operation_type": "action",
        "terraform_resource_attribute": "",
        "terraform_resource_type": "aws_vpc"
      }
    }
  ],
  "eval_expression": "eval-id-1"
}

Using No-Code

Cost control policy (Terraform)

EC2 instance cost is lower than 100 USD per month

Using Code-Editor

{
  "meta": {
    "required_provider": "stackguardian/infracost",
    "version": "v1"
  },
  "evaluators": [
    {
      "provider_args": {
        "operation_type": "total_monthly_cost",
        "resource_type": ["aws_ec2"]
      },
      "condition": {
        "type": "LessThanEqualTo",
        "value": 100
      },
      "id": "ec2_cost_below_100_per_month"
    }
  ],
  "eval_expression": "ec2_cost_below_100_per_month"
}

Using No-Code

Scheduling Policy

Ensure enabled cron jobs for destroy action workflows

Using Code-Editor

{
  "meta": {
    "required_provider": "stackguardian/json",
    "version": "v1"
  },
  "evaluators": [
    {
      "description": "Cron job exists for the workflow",
      "condition": {
        "type": "IsNotEmpty",
        "value": "",
        "error_tolerance": 0
      },
      "id": "eval-id-1",
      "provider_args": {
        "operation_type": "get_value",
        "key_path": "UserSchedules.*.cron"
      }
    },
    {
      "description": "Action must be destroy",
      "condition": {
        "type": "ContainedIn",
        "value": [["destroy"]],
        "error_tolerance": 0
      },
      "id": "eval-id-2",
      "provider_args": {
        "operation_type": "get_value",
        "key_path": "UserSchedules.*.inputs.TerraformAction.action"
      }
    },
    {
      "description": "Schedule must be enabled",
      "condition": {
        "type": "ContainedIn",
        "value": [["ENABLED"]],
        "error_tolerance": 0
      },
      "id": "eval-id-3",
      "provider_args": {
        "operation_type": "get_value",
        "key_path": "UserSchedules.*.state"
      }
    }
  ],
  "eval_expression": "eval-id-1 && eval-id-2 && eval-id-3"
}

Using No-Code

Tagging Policy

Validate 'costcenter:workshop' tag on AWS EKS node groups

Using Code-Editor

{
  "meta": {
    "required_provider": "stackguardian/terraform_plan",
    "version": "v1"
  },
  "evaluators": [
    {
      "description": "",
      "condition": {
        "type": "Contains",
        "value": {
          "costcenter": "workshop"
        },
        "error_tolerance": 1
      },
      "id": "eval-id-1",
      "provider_args": {
        "operation_type": "attribute",
        "terraform_resource_attribute": "tags",
        "terraform_resource_type": "aws_eks_node_group"
      }
    }
  ],
  "eval_expression": "eval-id-1"
}

Using No-Code

Workflow Policy Using Context Tags

Use a Workflow Policy to restrict execution of a production Workflow until the staging Workflow has completed successfully for an apply action with the same template group ID and revision.

This policy uses Context Tags to reference a dependent Workflow and checks for several conditions:

• The dependent Workflow must have a status of COMPLETED.
• The dependent Workflow must have performed an apply action.
• The dependent Workflow’s iacTemplateId must be less than or equal to that of the current workflow.

To reference another workflow, use the ${workflow::...} syntax. For example, you can reference a workflow directly by using ${workflow::workflowGroupName.workflowName} where you replace workflowGroupName and workflowName with the actual values.

In this scenario, the current workflow has a context tag named depWf, which stores a reference to another workflow. You can access attributes of the current workflow using ${curr_workflow.attrs...} within a workflow reference string.

Workflow reference strings are evaluated from the innermost key outward. For example: ${workflow::${curr_workflow.attrs.ContextTags.depWf}.attrs.LatestWfrunStatus}

This expression works as follows:

1. It first retrieves the value of the context tag named depWf from the current workflow.
2. It then uses this value to reference the dependent workflow.
3. Finally, it fetches the LatestWfrunStatus attribute from the dependent workflow.

This allows you to create dynamic policies that depend on the state or attributes of other workflows, enabling advanced automation and governance scenarios.

Using Code-Editor

{
    "evaluators": [
        {
            "provider_args": {
                "operation_type": "get_value",
                "key_path": "${workflow::${curr_workflow.attrs.ContextTags.depWf}.attrs.LatestWfrunStatus}"
            },
            "condition": {
                "type": "Equals",
                "value": "COMPLETED"
            },
            "id": "dependent_workflow_completed"
        },
        {
            "provider_args": {
                "operation_type": "get_value",
                "key_path": "${workflow::${curr_workflow.attrs.ContextTags.depWf}.attrs.LatestTerraformAction}"
            },
            "condition": {
                "type": "Equals",
                "value": "apply"
            },
            "id": "dependent_workflow_applied"
        },
        {
            "provider_args": {
                "operation_type": "get_value",
                "key_path": "VCSConfig.iacVCSConfig.iacTemplateId"
            },
            "condition": {
                "type": "LessThanEqualTo",
                "value": "${workflow::${curr_workflow.attrs.ContextTags.depWf}.attrs.VCSConfig.iacVCSConfig.iacTemplateId}"
            },
            "id": "staging_template_version_greater_equal"
        }
    ],
    "meta": {
        "required_provider": "stackguardian/json",
        "version": "v1"
    },
    "eval_expression": "dependent_workflow_completed && dependent_workflow_applied && staging_template_version_greater_equal"
}

Stack Policy Using Context Tags

Use a Stack Policy to restrict execution of a Production stack until a Staging Stack has completed successfully with the same template group ID and revision.

This policy uses Context Tags to reference a dependent Stack and checks for several conditions:

• The template group ID (the template revision) of the current stack must be equal to that of the dependent stack.
• The dependent Stack must have a status of COMPLETED.
• The resource name of the Stack must contain prod-.

To reference another stack, use the ${stack::...} syntax. For example, you can reference a stack directly by using ${stack::workflowGroupName.stackName} where you replace workflowGroupName and stackName with the actual values.

In this scenario, the current stack has a context tag named depStack, which stores a reference to another stack. You can access attributes of the current stack using ${curr_stack.attrs...} within a stack reference string.

Stack reference strings are evaluated from the innermost key outward. For example: ${stack::${curr_stack.attrs.ContextTags.depStack}.attrs.LatestWfStatus}

This expression works as follows:

1. It first retrieves the value of the context tag named depStack from the current stack.
2. It then uses this value to reference the dependent stack.
3. Finally, it fetches the LatestWfStatus attribute from the dependent stack.

This allows you to create dynamic policies that depend on the state or attributes of other stacks, enabling advanced automation and governance scenarios.

Using Code-Editor

{
    "evaluators": [
        {
            "description": "",
            "id": "current_template_version_matches_dependent_stack",
            "provider_args": {
                "operation_type": "get_value",
                "key_path": "TemplateGroupId"
            },
            "condition": {
                "type": "Equals",
                "value": "${stack::${curr_stack.attrs.ContextTags.depStack}.attrs.TemplateGroupId}",
                "error_tolerance": 0
            }
        },
        {
            "provider_args": {
                "operation_type": "get_value",
                "key_path": "${stack::${curr_stack.attrs.ContextTags.depStack}.attrs.LatestWfStatus}"
            },
            "condition": {
                "type": "Equals",
                "value": "COMPLETED"
            },
            "id": "dependent_stack_completed"
        },
        {
            "provider_args": {
                "operation_type": "get_value",
                "key_path": "ResourceName"
            },
            "condition": {
                "type": "Contains",
                "value": "prod-"
            },
            "id": "resource_name_contains_prod"
        }
    ],
    "meta": {
        "required_provider": "stackguardian/json",
        "version": "v1"
    },
    "eval_expression": "resource_name_contains_prod && current_template_version_matches_dependent_stack && dependent_stack_completed"
}