What are Custom Variables?
Custom Variables are global entities that can be inserted into compliance checks. These variables are designed for organizations to more flexibly create policy-based controls that require different elements of information depending on the level of the hierarchy. Simply put, Custom Variables allow you to do text-replacement of policies on a per-account basis.
Example: Automate tag compliance
Automated tag compliance is a common requirement for organizations who need to automate cloud operations. Tags are critical for use cases like cost allocation, tracking application owners, and ensuring policies target the correct cloud resources. With Custom Variables, you can configure a Kion compliance check to enforce your organization’s tagging schema by requiring a specific tag-key on all resources. With this feature, organizations can configure a single check to enforce the tag-key they desire globally and have it inherit through the organization chart.
Example: Compliance check to enforce tagging policies on Security Groups
--- vars: # Edit the list of tags below to meet the policy of your organization absent-tags-filter: &absent-tags - or: - "tag:data_class": absent - "tag:owner": absent - "tag:service": absent policies: - name: security-group-with-non-compliant-tags resource: aws.security-group description: | Identify Security Groups that are not compliant with tagging policies filters: *absent-tags actions: - type: webhook url: '{{CT::CallbackURL}}' method: POST batch: true headers: Authorization: '`{{CT::Authorization}}`' body: |- { "compliance_check_id": `{{CT::CheckId}}`, "account_number": account_id, "region": region, "scan_started_at": execution_start, "findings": resources[].{resource_name: GroupId, resource_type: `security-group`, "data_json": {"GroupName": GroupName, "Description": Description, "MissingTags": "c7n:MatchedFilters"[]}} } - type: tag tags: data_class: {{CT::Environment}} owner: {{CT::AppOwner}} service: Security Groups
Overrides
Although custom variables are created globally, overrides can be set at the OU, Project, and Account levels, allowing organizations to customize their checks at various levels. When an override exists, the default value(s) or key-value pairs will be swapped with the overrides for any associated checks at that level. When an override is set at an OU or Project, the override values inherit to descendants (meaning an OU override impacts the Projects associated with it). Kion always makes use of the override at the lowest hierarchical level, meaning an account-level override will take precedence over a project-level override when both are present.
An example of an override in action would be customizing a tag-key that is globally enforced by a Custom Variable, but the organization specifies the specific key:value pairs that are required at various levels of the org chart. In this instance, you could create an override that project A requires a specific key:value tag, while project B simply inherits the global check already in place.
Any changes to a custom variable or an override being added will take effect in the next compliance check scan.