Uploaded image for project: 'Ansible Automation Platform RFEs'
  1. Ansible Automation Platform RFEs
  2. AAPRFE-2646

[RFE] Ensure the integrity and authenticity of Ansible Automation Platform (AAP) job tasks, projects, and templates.

XMLWordPrintable

    • False
    • Hide

      None

      Show
      None
    • False

      1. What is the nature and description of the request?
        1. Summary: Provide a mechanism to ensure the integrity and authenticity of job tasks, projects, and templates within Ansible Automation Platform (AAP). Specifically, implement cryptographic signing and/or encryption of tasks at rest within the PostgreSQL database to prevent unauthorized job execution or credential targeting by actors with database-level access.
        2. Description: In the current architecture of AAP 2.6, if a malicious actor or unauthorized administrator gains direct access to the PostgreSQL database, they can manipulate the state of the automation platform by bypassing the API and RBAC layers. Specifically:
          • Job Injection: An attacker can insert rows into the job queue tables to trigger unauthorized execution.
          • Arbitrary Resource Creation: An attacker can create malicious projects or job templates that target existing encrypted credentials, effectively using the platform as a confused deputy to exfiltrate data or impact managed nodes.
          • Lack of Verifiability: There is currently no mechanism for the execution engine (Control/Execution Planes) to verify that a task sitting in the database was legitimately scheduled by the AAP Dispatcher/API.
      2. Why does the customer need this? (List the business requirements here)
        1. The lack of this feature is impending security controls for AAP to be allowed to run. For additional context:
          • Zero Trust Architecture: As organizations move toward Zero Trust, "trusting the database" is no longer a sufficient security posture.
          • Compliance: Many regulatory frameworks (SOC2, HIPAA, FedRAMP) require strict integrity controls. The ability to manipulate execution via the database represents a significant audit finding.
          • Mitigation of Insider Threats: This enhancement protects the environment from rogue database administrators or compromised service accounts that have DB-level permissions but should not have the authority to run automation.
      3. How would you like to achieve this? (List the functional requirements here)
        1. We request the following features to harden the platform against database-layer tampering:
          1. Task Signing: The AAP API/Dispatcher should cryptographically sign job definitions before inserting them into the database. The Execution Plane should then verify this signature against a trusted public key before proceeding with execution.
          2. Encrypted Task Payloads: Optionally encrypt sensitive job parameters or the job definition itself at rest within the database, ensuring that even with read access, the intent of the automation cannot be easily reverse-engineered or modified.
          3. Project/Template Integrity Checks: Implement a "sealed" or "signed" state for Job Templates and Project definitions to ensure they haven't been altered via back-end database manipulation.
      4. List any affected known dependencies: Doc, UI etc..
        1. Database
      5. Github Link if any

              dysilva Dylan Silva
              rhn-support-dwhitley Daniel Whitley
              Votes:
              4 Vote for this issue
              Watchers:
              10 Start watching this issue

                Created:
                Updated: