6a.Prevent job execution using extra_vars with non approved keys.md

Validating extra_vars Structure: Limit Inputs to Approved Variables

Overview

In many organizations, the person who launches automation jobs is not necessarily same individual who created or maintains the underlying Job Templates. Ansible Automation Platform allows users to specify extra_vars at job launch that enables customization of Job Templates. However, without guardrails, these variables can be freely defined by anyone launching the job.

This example demonstrates how to use Policy as Code to enforce an allowlist of approved extra_vars keys. This ensures administrators can control what variables are permitted while still allowing flexibility in job customization.

Example Policy aap_policy_examples/extra_vars_allowlist.rego

The following policy defines a list of allowed variable keys and blocks job execution if any other variables are included in the extra_vars.

package aap_policy_examples

import rego.v1

# Define the allowed keys for extra_vars
allowed_extra_var_keys := ["allowed"]

# Default policy result: allowed (no violations)
default extra_vars_allowlist := {
	"allowed": true,
	"violations": [],
}

# Evaluate extra_vars_allowlist, checking if provided extra_vars contain any keys not allowed
extra_vars_allowlist := result if {
	# Extract extra_vars from input, defaulting to empty object if missing
	input_extra_var_keys := object.get(input, ["extra_vars"], {})

	# Identify keys in extra_vars that are not in the allowed list
	violating_keys := [key | input_extra_var_keys[key]; not allowed_key(key)]

	# If violating keys are found, construct result indicating disallowed status and violations
	count(violating_keys) > 0

	result := {
		"allowed": false,
		"violations": [sprintf("Following extra_vars are not allowed: %v. Allowed keys: %v", [violating_keys, allowed_extra_var_keys])],
	}
}

# Helper function: Checks if a given key is in the allowed_extra_var_keys list
allowed_key(key) if {
	allowed_extra_var_keys[_] == key
}

Sample Input and Output

Let's say a user launches a job with the following extra_vars:

{
  "extra_vars": {
    "env": "prod",
    "debug": true,
    "allowed": true
  }
}

Since only specific keys are allowed, the job will be rejected if it includes unapproved variables. In the example above, the keys env and debug are not permitted and will trigger a policy violation since the built in policy did not allowlist either of those two variables.

Expected policy decision output:

{
  "allowed": false,
  "violations": [
    "Following extra_vars are not allowed: [\"env\", \"debug\"]. Allowed keys: [\"allowed\"]"
  ]
}

Enforcement Behavior

This policy is enforced at the Job Template level. Any job launched from a job template with this policy attached will fail if disallowed extra_vars are provided.

#TODO: Need to add Rego link

Real World Use Case: Enforcing Safe extra_vars at Launch

Scenario

A platform team maintains job templates that support limited customization through a small set of predefined extra_vars, such as target_environment and rollback. These variables are explicitly handled in the Job Template to modify behavior. For example, selecting whether a deployment should target an on-prem or a cloud environment, or trigger a rollback to a previously working version.

To prevent jobs from running with unsupported variables, the team enforces a policy that restricts which extra_vars can be passed at launch. If a user includes a variable outside the approved list due to a typo or misuse, the job is blocked before execution. A message is displayed in the Ansible Automation Platform output of the job identifying the policy violation and which variables are allowed.

This approach ensures that job runs with the intended variable allowlist that reduces the risk of misconfiguration and helps maintain predictable automation across teams and environments.

Impact of Policy Enforcement in Ansible Automation Platform

By enforcing structure on extra_vars, teams benefit from:

• Controlled job customization with clearly defined variables
• Fewer misconfigurations and errors at runtime due to misuse of extra_vars
• A consistent automation experience across environments

How AAP Enforces the Policy

Once the allowlist policy is in place:

• Jobs using unapproved extra_vars are rejected before any execution begins
• Only jobs that use the allowed variables can proceed
• Violation messages provide specific feedback on what variables were denied and which are allowed

Why This Matters

• Security: Prevents arbitrary or malicious input from altering job behavior
• Consistency: Enforces naming and input standards across teams
• Clarity: Gives users immediate feedback when unsupported variables are used