Summary

Similar to BAM-25871 (which I am going to plagiarize since it's so well written), in AWS, the OpenSearch configuration expects an instance profile attached to the instance running confluence. In an EKS environment, using Service Accounts and assuming roles at a pod level is highly preferred; this will enhance security and align with AWS best practices.

Background

Currently, Confluence supports connecting to OpenSearch using EC2 InstanceProfiles and direct AWS access keys. While these methods are functional, they don't leverage the security and flexibility benefits offered by IAM roles for Service Accounts in EKS environments. As more organizations migrate to EKS, the need for native support for IRSA in Confluence becomes critical.

Problem Statement

Organizations using Confluence in EKS environments are currently required to use less secure or less integrated methods to connect to OpenSearch. The available workarounds involve:

• Using EC2 InstanceProfiles, which is not directly applicable to EKS.
• Employing direct AWS access keys, which requires managing credentials and does not follow AWS's recommended security practices.
  These workarounds increase operational overhead and can lead to potential security vulnerabilities.

Proposed Solution

Introduce native support for IAM roles for Service Accounts in Confluence to connect to OpenSearch. This feature would involve:

System Properties and confluence.cfg.xml updates: Introduce a property "opensearch.aws.role" (-Dopensearch.aws.role) to be assumed when connecting to OpenSearch.

Backend Processing Adaptation: Modify the Confluence backend to authenticate with AWS using the IAM role "opensearch.aws.role" associated with the Kubernetes ServiceAccount, leveraging the AWS SDK's support for IRSA.

Additional Information

Refer to AWS documentation on IAM roles for Service Accounts for more details on configuring IRSA in EKS.