이 콘텐츠는 선택한 언어로 제공되지 않습니다.

Chapter 7. Implementing policy enforcement


Policy enforcement at automation runtime is a feature that uses encoded rules to define, manage, and enforce policies that govern how your users interact with your Ansible Automation Platform instance. Policy enforcement automates policy management, improving security, compliance, and efficiency.

OPA, or Open Policy Agent, is a policy engine that offloads policy decisions from your Ansible instance. When it is triggered, the policy enforcement feature connects to OPA to retrieve policies specified in your configuration, and applies policy rules to your automation content. If OPA detects a policy violation, it will stop the action and give your user information about the policy violation.

Prerequisites

Before you can implement policy enforcement in your Ansible Automation Platform instance, you must have:

  • Access to an OPA server that is reachable from your Ansible Automation Platform deployment.
  • Configured Ansible Automation Platform with settings required for authenticating to your OPA server.
  • Some familiarity with OPA and the Rego language, which is the language policies are written in.

For policy enforcement to work correctly, you must both configure the OPA server in your policy settings, and associate a specific policy with a particular resource. For example, a particular organization, inventory, or job template.

Note

OPA API V1 is the only version currently supported in Ansible Automation Platform.

7.1. Configuring policy enforcement settings

You can specify how your Ansible Automation Platform instance interacts with OPA by modifying your global settings.

Prerequisites

  • To configure policy enforcement, you must have administrative privileges.
Note

If you do not configure the OPA server in your policy settings, policy evaluation will not occur when you run the job.

Procedure

  1. From the navigation panel, select Settings Automation Execution Policy.
  2. Click Edit policy settings.
  3. On the Policy Settings page, fill out the following fields:

    OPA Server hostname
    Enter the name of the host that connects to the OPA service.
    OPA server port
    Enter the port that connects to the OPA service.
    OPA authentication type
    Select the OPA authentication type.
    OPA custom authentication header
    Enter a custom header to append to request headers for OPA authentication.
    OPA request timeout
    Enter the number of seconds until the connection times out.
    OPA request retry count
    Enter a figure for the number of times a request can attempt to connect to the OPA service before failing.
  4. Depending on your authentication type, you might need to fill out the following fields.

    1. If you selected Token as your authentication type:

      OPA authentication token
      Enter the OPA authentication token.
    2. If you selected Certificate as your authentication type:

      OPA client certificate content
      Enter content of the CA certificate for mTLS authentication.
      OPA client key content
      Enter the client key for mTLS authentication.
      OPA CA certificate content
      Enter the content of the CA certificate for mTLS authentication.
  5. Beneath the heading labeled Options:

    Use SSL for OPA connection
    Check this box to enable an SSL connection to the OPA service.
  6. Click Save policy settings.

7.2. Understanding OPA packages and rules

An OPA policy is organized in packages, which are namespaced collections of rules. The basic structure of an OPA policy looks like this:

package aap_policy_examples  # Package name

import rego.v1  # Import required for Rego v1 syntax

# Rules define the policy logic
allowed := {
    "allowed": true,
    "violations": []
}
Copy to Clipboard Toggle word wrap

The key components of the rule’s structure are:

Package declaration
This defines the namespace for your policy.
Rules
This defines the policy’s logic and the decision that it returns.

These components together comprise the OPA policy name, which is formatted as [package]/[rule]. You will enter the OPA policy name when you configure enforcement points.

7.3. Configuring enforcement points

After you have set up your Ansible Automation Platform instance to communicate with the OPA server, you can set up enforcement points where you want the policy to be applied.

You can associate a policy with a job template, an inventory, or an organization. Enforcement then occurs in the following ways:

Organization
Jobs launched from a template owned by an organization will fail if the policy is violated. This configuration provides broad control over automation within organizational boundaries.
Inventory
Jobs using an inventory associated with a policy fail if the policy is violated. This configuration allows you to control access to specific infrastructure resources.
Job template
Jobs launched from a template associated with a policy fail if the job violates the associated policy. This configuration provides granular control over specific automation tasks.
Note

If you do not associate a policy with a resource, policy evaluation will not occur when you run the related job.

7.3.1. Associating a policy with an organization

To associate a policy with an organization, take the following steps.

Procedure

  1. From the navigation panel, select Access Management Organizations.
  2. On the Organizations page:

    1. To edit an existing organization, find the organization you want to edit and click the pencil icon Edit page to go to the editing screen.
    2. To create a new organization, click Create organization.
  3. In the field labeled Policy enforcement, enter the query path associated with the policy you want to implement. You must format the query path as package/rule.
  4. Click Next and then Finish to save your settings.

7.3.2. Associating a policy with an inventory

To associate a policy with an inventory, take the following steps:

Procedure

  1. From the navigation panel, select Automation Execution Infrastructure Inventories.
  2. On the Inventories page:

    1. To edit an existing inventory, find the inventory you want to edit and click the pencil icon Edit page to go to the editing screen.
    2. To create a new inventory, click Create inventory.
  3. In the field titled Policy enforcement, enter the query path associated with the policy you want to implement. You must format the query path as package/rule.
  4. Click Save inventory if you are editing an existing inventory, or click Create inventory if you are creating a new inventory.

7.3.3. Associating a policy with a job template

To associate a policy with a job template, take the following steps:

Procedure

  1. From the navigation panel, select Automation Execution Templates.
  2. On the Automation Templates page:

    1. To edit an existing job template, find the job template you want to edit and click the pencil icon Edit page to go to the editing screen.
    2. To create a new job template, click Create template.
  3. In the field titled Policy enforcement, enter the query path associated with the policy you want to implement. You must format the query path as package/rule.
  4. Click Save job template if you are editing an existing job template, or click Create job template if you are creating a new job template.

7.4. Policy enforcement inputs and outputs

Use the following inputs and outputs to craft policies for use in policy enforcement.

Expand
Table 7.1. Input data
InputTypeDescription

id

Integer

The job’s unique identifier.

name

String

Job template name.

created

Datetime (ISO 8601)

Timestamp indicating when the job was created.

created by

Object

Information about the user who created the job.

  • id(integer): Unique identifier for the user
  • username(string): creator username
  • is_superuser(boolean): indicates if the user is a superuser

credentials

List of objects

Credentials associated with job execution.

  • id (integer): the credential’s unique identifier
  • name (string): credential name
  • description (string): credential description
  • organization (integer or null): organization identifier associated with the credential
  • credential_type (integer): credential type identifier
  • managed (boolean): indicates if the credential is managed internally
  • kind (string): credential type ( such as ssh, cloud, or kubernetes)

execution_environment

Object

Details about the execution environment used for the job.

  • id (integer): the execution environment’s unique identifier
  • name (string): execution environment name
  • image (string): container image used for execution
  • pull (string): pull policy for the execution environment

extra_vars

JSON

Extra variables provided for job execution.

forks

Integer

The number of parallel processes used for job execution.

hosts_count

Integer

The number of hosts targeted by the job.

instance_group

Object

Information about the instance group handling the job, including:

  • id (integer): the instance group’s unique identifier
  • name (string): the instance group name
  • capacity (integer): the available capacity in the group
  • jobs_running (integer): the number of currently running jobs
  • jobs_total (integer): total jobs handled by the group
  • max_concurrent_jobs (integer): maximum concurrent jobs allowed
  • max_forks (integer): maximum forks allowed

inventory

Object

Inventory details used in the job execution, including:

  • id (integer): the inventory’s unique identifier
  • name (string): The inventory’s name
  • description (string): inventory description
  • kind (string): the inventory type
  • total_hosts (integer): the total number of hosts in the inventory
  • total_groups (integer): the total number of groups in the inventory
  • has_inventory_sources (boolean): indicates if the inventory has external sources
  • total_inventory_sources (integer): the number of external inventory sources
  • has_active_failures (boolean): indicates if there are active failures in the inventory
  • hosts_with_active_failures (boolean): the number of hosts with active failures
  • inventory_sources (array): external inventory sources associated with the inventory

job_template

Object

Information about the job template, including:

  • id (integer): the job template’s unique identifier
  • name (string): the job template’s name
  • job_type (string): type of job (for example, run)

job_type

Choice (String)

Type of job execution. Allowed values are:

  • run
  • check
  • scan

job_type_name

String

Human-readable name for the job type.

labels

List of objects

Labels associated with the job, including:

  • id (integer): the label’s unique identifier
  • name (string): the label name
  • organization (object): the organization associated with the label

    • id (integer): the organization’s unique identifier
    • name (string): the organization name

launch_type

Choice (String)

How the job was launched. Allowed values include:

  • manual: manual
  • relaunch: relaunch
  • callback: callback
  • scheduled: scheduled
  • dependency: dependency
  • workflow: workflow
  • webhook: webhook
  • sync: sync
  • scm: SCM update

limit

String

The limit applied to the job execution.

launched_by

Object

Information about the user who launched the job, including:

  • id (integer): the user’s unique identifier
  • name (string): the user name
  • type (type): the user type (for example, user or system)
  • url (string): the user’s API URL

organization

Object

Information about the organization associated with the job, including:

  • id (integer): the organization’s unique identifier
  • name (name): the organization’s name

playbook

String

The playbook used in the job execution.

project

Object

Details about the project associated with the job, including:

  • id (integer): the project’s unique identifier
  • name (string): the project name
  • status (choice-string): the project status

    • successful: Successful
    • failed: failed
    • error: error
  • scm_type(string): source control type (such as`git`, or svn)
  • scm_url (string): the source control repository URL
  • scm_branch (string): the branch used in the repository
  • scm_refspec (string): RefSpec for the repository
  • scm_clean (boolean): whether the SCM is cleaned before updates
  • scm_track_submodules (boolean): whether submodules are tracked
  • scm_delete_on_update (boolean): whether SCM deletes files on update

scm_branch

String

The specific branch to use for SCM.

scm_revision

String

SCM revision used for the job.

workflow_job

Object

Workflow job details, if the job is part of a workflow.

workflow_job_template

Object

Workflow job template details.

The following code block shows example input data from a demo job template launch:

{
  "id": 70,
  "name": "Demo Job Template",
  "created": "2025-03-19T19:07:03.329426Z",
  "created_by": {
    "id": 1,
    "username": "admin",
    "is_superuser": true,
    "teams": []
  },
  "credentials": [
    {
      "id": 3,
      "name": "Example Machine Credential",
      "description": "",
      "organization": null,
      "credential_type": 1,
      "managed": false,
      "kind": "ssh",
      "cloud": false,
      "kubernetes": false
    }
  ],
  "execution_environment": {
    "id": 2,
    "name": "Default execution environment",
    "image": "registry.redhat.io/ansible-automation-platform-25/ee-supported-rhel8@sha256:b9f60d9ebbbb5fdc394186574b95dea5763b045ceff253815afeb435c626914d",
    "pull": ""
  },
  "extra_vars": {
    "example": "value"
  },
  "forks": 0,
  "hosts_count": 0,
  "instance_group": {
    "id": 2,
    "name": "default",
    "capacity": 0,
    "jobs_running": 1,
    "jobs_total": 38,
    "max_concurrent_jobs": 0,
    "max_forks": 0
  },
  "inventory": {
    "id": 1,
    "name": "Demo Inventory",
    "description": "",
    "kind": "",
    "total_hosts": 1,
    "total_groups": 0,
    "has_inventory_sources": false,
    "total_inventory_sources": 0,
    "has_active_failures": false,
    "hosts_with_active_failures": 0,
    "inventory_sources": []
  },
  "job_template": {
    "id": 7,
    "name": "Demo Job Template",
    "job_type": "run"
  },
  "job_type": "run",
  "job_type_name": "job",
  "labels": [
    {
      "id": 1,
      "name": "Demo label",
      "organization": {
        "id": 1,
        "name": "Default"
      }
    }
  ],
  "launch_type": "workflow",
  "limit": "",
  "launched_by": {
    "id": 1,
    "name": "admin",
    "type": "user",
    "url": "/api/v2/users/1/"
  },
  "organization": {
    "id": 1,
    "name": "Default"
  },
  "playbook": "hello_world.yml",
  "project": {
    "id": 6,
    "name": "Demo Project",
    "status": "successful",
    "scm_type": "git",
    "scm_url": "https://github.com/ansible/ansible-tower-samples",
    "scm_branch": "",
    "scm_refspec": "",
    "scm_clean": false,
    "scm_track_submodules": false,
    "scm_delete_on_update": false
  },
  "scm_branch": "",
  "scm_revision": "",
  "workflow_job": {
    "id": 69,
    "name": "Demo Workflow"
  },
  "workflow_job_template": {
    "id": 10,
    "name": "Demo Workflow",
    "job_type": null
  }
}
Copy to Clipboard Toggle word wrap
Expand
Table 7.2. Output data
InputTypeDescription

allowed

Boolean

Indicates whether the action is permitted

violations

List of strings

Reasons why the action is not permitted

The following code block shows an example of expected output from the OPA policy query:

{
  "allowed": false,
  "violations": [
    "No job execution is allowed",
    ...
  ],
  ...
}
Copy to Clipboard Toggle word wrap
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat