6c.Prevent job execution based on user limitations for extra vars.md

Enforcing team based access to extra_vars values

Overview

In many organizations, responsibilities are divided among teams, each responsible for a specific environment such as development or production. While Ansible Automation Platform allows users to provide extra_vars at job launch, it becomes critical to ensure those values are appropriate for the user's team to prevent unauthorized or unsafe deployments.

This example demonstrates how to use Policy as Code to enforce extra_vars value restrictions based on what team the user belongs too.

Example Policy aap_policy_examples/team_based_extra_vars_restriction.rego

The following policy ensures that only approved extra_vars values are accepted for users based on what team they're are on. If a user supplies a value outside of what their team is allowed to use, the job is blocked and a detailed violation message is returned.

package aap_policy_examples

import rego.v1

# Define allowed values for specific keys in extra_vars based on teams
valid_extra_var_values_by_team := {
	"dev_team": {"environment": ["dev", "staging"]},
	"prod_team": {"environment": ["prod", "staging"]},
}

# Default response allowing extra_vars unless violations occur
default team_based_extra_vars_restriction := {
	"allowed": true,
	"violations": [],
}

# Evaluate extra_vars against allowed values considering team memberships
team_based_extra_vars_restriction := result if {
	# Extract extra_vars from input
	input_extra_vars := object.get(input, ["extra_vars"], {})

	# Extract user's team names
	user_teams := {team | team := input.created_by.teams[_].name}

	violating_keys := [key |
		allowed_vals := allowed_values_for_key_and_teams(key, user_teams)
		input_value := input_extra_vars[key]
		allowed_values_for_key_and_teams(key, user_teams)
		not allowed_value(input_value, allowed_vals)
	]

	count(violating_keys) > 0

	result := {
		"allowed": false,
		"violations": [sprintf("extra_vars contain disallowed values for keys: %v. Allowed extra_vars for your teams (%v): %v", [violating_keys, user_teams, allowed_values_for_user_teams(user_teams)])],
	}
}

# Retrieve allowed values for a specific key based on user's teams
allowed_values_for_key_and_teams(key, teams) := values if {
	values := {val | team := teams[_]; val := valid_extra_var_values_by_team[team][key][_]; valid_extra_var_values_by_team[team][key]}
}

# Retrieve all allowed values based on user's teams
allowed_values_for_user_teams(teams) := team_values if {
	team_values := {team: valid_extra_var_values_by_team[team] | team := teams[_]; valid_extra_var_values_by_team[team]}
}

# Check if given value is in allowed values set
allowed_value(value, allowed_values) if {
	allowed_values[_] == value
}

Sample Input and Output

Suppose a user from the dev_team attempts to launch a job with the following extra_vars:

{
  "extra_vars": {
    "environment": "prod"
  },
  "created_by": {
    "teams": [
      { "name": "dev_team" }
    ]
  }
}

The policy only allows dev_team members to use ["dev", "staging"] for the environment variable.

Because prod is not an approved value for that team, the job is blocked and fails.

Expected policy decision output:

{
  "allowed": false,
  "violations": [
    "extra_vars contain disallowed values for keys: [\"environment\"]. Allowed extra_vars for your teams ([\"dev_team\"]): {\"dev_team\": {\"environment\": [\"dev\", \"staging\"]}}"
  ]
}

Enforcement Behavior

This policy is attached to a Job Template. During launch, it checks if the user belongs to a team and verifies that the provided extra_vars are within the set of allowed values for their teams. If any value is not allowed, the job is blocked with a clear violation message.

Use Case: Team Based extra_vars Control

An enterprise automation team supports Job Templates shared across multiple departments. Each department has access only to specific environments. To enforce this, the platform team implements a policy that only allows certain extra_vars values depending on what team the user belongs too.

For instance, the dev_team can deploy to dev or staging environments, while the prod_team can deploy to prod. This prevents accidental or unauthorized changes across environments.

Impact of Policy Enforcement in Ansible Automation Platform

By tying extra_vars validation to a user's team membership, platform teams can:

• Ensure separation of duties and environment access
• Prevent accidental deployment to production by unauthorized teams

How AAP Enforces the Policy

When this policy is attached to a Job Template:

• It checks each variable within extra_vars against the team's allowed values
• Jobs are blocked and fail immediately if any value is unauthorized
• A message explains the violation, including the allowed values for the user's team

This enforcement occurs before the playbook runs, helping catch misconfigurations early.

Why This Matters

Enforcing approved variable values based on team ownership improves both security and stability. It ensures that automation jobs only execute in contexts explicitly approved for the user running them. This is especially useful when different teams manage different lifecycle environments, reducing the chance of critical mistakes and maintaining environment integrity.