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

[RFE] AAP on OpenShift - Support for Service Mesh / Envoy Managed Pod-to-Pod mTLS

XMLWordPrintable

    • False
    • Hide

      None

      Show
      None
    • False

      1. What is the nature and description of the request?  
        The customer is deploying Ansible Automation Platform (AAP 2.6) via the AAP Operator on OpenShift 4.18. The target OpenShift platform is configured with a Service Mesh (e.g., Istio / Envoy or Consul Connect) to provide cluster-wide mTLS, workload identity, and certificate rotation.
         
        Currently, AAP generates and manages its own certificates for internal communication. The customer requests that AAP components (specifically aap-controller-web, aap-controller-task, aap-receptor, and dynamically created automation-job-* pods) be capable of participating in the platform-managed trust layer. This requires AAP to support deployment with Envoy sidecars where pod-to-pod communication is secured and authenticated by the Service Mesh rather than application-managed TLS.
      2. Why does the customer need this? (List the business requirements here)
        • Operational Model Alignment: The customer requires AAP to operate as a standard OpenShift workload within a platform-managed zero-trust networking model.
        • Security & Compliance: Centralized management of certificate issuance, automatic rotation, and policy enforcement via the Service Mesh is a strict requirement for their environment. They need to move away from application-siloed certificate management to platform-managed mTLS.
      3. How would you like to achieve this? (List the functional requirements here)
        • Service Mesh Compatibility: Enable AAP pods to be deployed with Envoy sidecars successfully.
        • mTLS Offloading: Provide a configuration option to allow mTLS to be provided, terminated, and managed by the platform (Istio/Envoy) rather than AAP internal mechanisms.
        • Pod Coverage: Ensure this architecture supports all relevant components, including the web controller, task controller, receptor, and ephemeral automation job pods.
      4. List any affected known dependencies: Doc, UI etc..
        • Documentation: Updates required for reference architectures regarding Service Mesh integration.
        • AAP Operator: Logic may be required to allow sidecar injection and adjust internal TLS settings.
      5. Github Link if any

              Unassigned Unassigned
              rhn-support-dwhitley Daniel Whitley
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated: