@ancient-wolf-19325 In the official doc for multi-cluster deployment (https://www.union.ai/docs/v1/flyte/deployment/flyte-deployment/multicluster/#control-plane-configuration) it is stated that cross-cluster authentication requires to setup long-lived bearer token. Is it possible to use IRSA instead for cross-EKS communication in AWS environment?

Reasoning Complete! 🤖 🔍 Searched knowledge base: You want to know if IRSA can be used for cross-cluster authentication in Flyte on AWS EKS instead of bearer tokens. I'll look for any official guidance or examples on using IRSA for this purpose. • Searching over 10 data sources from the following: File, Github File, Github Issue, Web • Found 64 documents that could be relevant from the following data sources: Bing, Github File, Github Issue, Github Pull Request, Web Content. • Filtered down to the top 30 most relevant documents. ✍️ Generated answer: Based on the official documentation and community discussions, Flyte currently requires long-lived Kubernetes service account bearer tokens for cross-cluster authentication. IRSA is not supported for this use case, as it is designed for AWS API access, not Kubernetes API authentication. There is interest in supporting cloud-native mechanisms in the future, but this is not yet available.

@ancient-wolf-19325 any recommendations how to refresh authentication token in control plane if my tokens are short-lived?

Reasoning Complete! 🤖 🔍 Searched knowledge base: You want to know how to handle token refresh in the Flyte control plane if your authentication tokens are short-lived. I'll look for official guidance or community best practices on automating or managing token refresh in this scenario. • Searching over 10 data sources from the following: File, Github File, Github Issue, Web • Found 50 documents that could be relevant from the following data sources: Bing, Github File, Github Issue, Github Pull Request, Web Content. • Filtered down to the top 30 most relevant documents. ✍️ Generated answer: Based on the information found, Flyte does not natively handle automatic refresh of short-lived Kubernetes service account tokens for cross-cluster authentication. The best practice is to set up an external process or automation that regularly retrieves the latest valid token from the data plane cluster and updates the Flyte control plane's configuration. This ensures that authentication remains valid even as tokens are rotated by Kubernetes.