2.Prevent job execution by platform admin.md

2. Prevent job execution by platform admin

In the previous example we looked at a simple policy that does not take in any data. In this example we will demonstrate how to use data provided from Ansible Automation Platform to craft a policy that makes decisions based on the situation.

Example policy aap_policy_examples/superuser_allowed_false.rego:

package aap_policy_examples

import rego.v1

default superuser_allowed_false := {
	"allowed": true,
	"violations": [],
}

superuser_allowed_false := {
	"allowed": false,
	"violations": ["System/Platform Administrator is not allow to launch jobs"],
} if {
	input.created_by.is_superuser
}

Example input provided by Ansible Automation Platform during query:

{
  "id": 785,
  "name": "Demo Job Template",
  "created": "2025-02-27T20:32:14.874821Z",
  "created_by": {
    "id": 1,
    "username": "admin",
    "is_superuser": true
  },
  ...
}

Example output from policy query:

{
  "allowed": false,
  "violations": [
    "SuperUser is not allow to launch jobs",
  ],
}

This policy will use the created_by.is_superuser data from the input to decide if the job execution is allowed. In this case, if the job is created by a superuser (platform admin) the job execution will be prevented.

When applied at different enforcement points, this policy prevents job execution accordingly:

• Job Template: All jobs launched from the template by a superuser will ERROR and playbook execution will be prevented.
• Inventory: All jobs launched by a superuser using the inventory will ERROR and playbook execution will be prevented.
• Organization: All jobs launched by a superuser using a job template that belongs to the organization will ERROR and playbook execution will be prevented.

The Policy as Code feature in Ansible Automation Platform is capable of providing all relevant data around the job launch. For more details about the input data that Ansible Automation Platform provides for the OPA policy query see policy input data.