[LFXV2-1318]: Create lfx-mcp secretstore

[agaetep]

This PR creates an lfx-mcp service account for the lfx-mcp-secrets secret store defined as a custom resource in the lfx-v2-argocd repository. It does not cut over the current secrets to pull from the new secretstore, that will be in another PR

[claude]

Claude Code Review

This repository is configured for manual code reviews. Comment @claude review to trigger a review.

_{Tip: disable this comment in your organization's Code Review settings.}

[Copilot]

Pull request overview

This PR adds Helm chart configuration and templates to support External Secrets Operator (ESO) integration for lfx-mcp, including creating a dedicated Kubernetes ServiceAccount and defining a SecretStore/ExternalSecret to sync credentials from AWS Secrets Manager.

Changes:

• Add serviceAccount and externalSecretsOperator configuration to values.yaml.
• Add a ServiceAccount template for lfx-mcp.
• Add ESO SecretStore and ExternalSecret templates to materialize Kubernetes Secrets from AWS Secrets Manager.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 7 comments.

File	Description
charts/lfx-mcp/values.yaml	Adds values for service account + ESO secret mapping defaults.
charts/lfx-mcp/templates/serviceaccount.yaml	Creates a chart-managed ServiceAccount.
charts/lfx-mcp/templates/secretstore.yaml	Adds a namespaced SecretStore using AWS Secrets Manager + SA JWT auth.
charts/lfx-mcp/templates/externalsecret.yaml	Adds an ExternalSecret to sync remote values into a Kubernetes Secret.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[emsearcy]

I understand that we'd need logic to create or specify a service account (that seems like a "normal" Helm thing); however: I'd like to see if we can keep these open source repos "agnostic" of LF infrastructure (like ESO configuration and references to our AWS secrets manager paths).

If we were deploying an off-the-shelf Helm chart (like Heimdall), it would certainly also require references to secrets. But how those secrets are themselves managed is (IMO) outside the scope of the Helm chart for the "software distribution".

[agaetep]

I understand that we'd need logic to create or specify a service account (that seems like a "normal" Helm thing); however: I'd like to see if we can keep these open source repos "agnostic" of LF infrastructure (like ESO configuration and references to our AWS secrets manager paths).

If we were deploying an off-the-shelf Helm chart (like Heimdall), it would certainly also require references to secrets. But how those secrets are themselves managed is (IMO) outside the scope of the Helm chart for the "software distribution".

That makes sense. If I'm understanding the setup correctly, right now the only way we pull secrets from AWS is through these service accounts. Are you proposing more of a direct secrets management approach, from lfx-secrets-management straight to a Kubernetes secret?