Normalize Lambda and OpenSearch client config

[JPrevost]

Why are these changes being introduced:

• Lambda needed role assumption capabilities
• Clients were doing the same thing two different ways

Relevant ticket(s):

• https://mitlibraries.atlassian.net/browse/TIMX-680

How does this address that need:

• Normalized the configuration for Lambda and OpenSearch clients to use consistent role assumption and credential handling by implementing a common AWS authentication abstraction.

Developer

• All new ENV is documented in README
• All new ENV has been added to Heroku Pipeline, Staging and Prod
• ANDI or Wave has been run in accordance to
  our guide and
  all issues introduced by these changes have been resolved or opened as new
  issues (link to those issues in the Pull Request details above)
• Stakeholder approval has been confirmed (or is not needed)

Code Reviewer

• The commit message is clear and follows our guidelines
  (not just this pull request message)
• There are appropriate tests covering any new functionality
• The documentation has been updated or is unnecessary
• The changes have been verified
• New dependencies are appropriate or there were no changes

Requires database migrations?

NO

Includes new or updated dependencies?

NO

[Copilot]

Pull request overview

Normalizes AWS credential and role-assumption handling for Lambda and OpenSearch clients.

Changes:

• Adds shared AWS authentication and configuration validation.
• Updates Lambda and OpenSearch initialization.
• Renames AOSS role configuration to AWS_ROLE_ARN.
• Updates documentation and tests.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Summary
test/initializers/lambda_config_test.rb	Tests Lambda credential configuration.
test/initializers/aws_config_validator_test.rb	Updates shared configuration validation tests.
README.md	Documents AWS authentication settings; credential precedence requires clarification.
lib/opensearch_config_validator.rb	Removes the superseded validator.
lib/aws_config_validator.rb	Centralizes validation; migration support for AWS_AOSS_ROLE_ARN is required.
lib/aws_auth.rb	Provides shared credential and role-assumption helpers.
config/initializers/opensearch.rb	Uses shared OpenSearch authentication.
config/initializers/lambda.rb	Adds Lambda validation and role-based credentials.

Suppressed comments (1)

config/initializers/lambda.rb:12

• When both AWS_ROLE_ARN and AWS_SESSION_TOKEN are set, Lambda takes this role-assumption branch, while aws_aoss_client takes the session-token branch and uses the original credentials. The shared configuration can therefore make the two clients authenticate as different principals, contrary to the stated normalization (and the generic README text that a session token is used directly). Define one precedence rule—or reject the combination—and apply it consistently.

  if AwsAuth.role_arn_present?
    Rails.logger.debug 'Configuring Lambda client with assumed role credentials'
    return AwsAuth.assume_role_credentials(role_session_name: 'timdex-lambda')

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[JPrevost]

Normalized how the two clients work. This was a good call out.

[qltysh]

❌ 1 blocking issue (1 total)

Tool	Category	Rule	Count
rubocop	Style	Line is too long. [121/120]	1	❌

[qltysh]

Line is too long. [121/120] [rubocop:Layout/LineLength]

[matt-bernhardt]

This seems to work, so on that basis I'm happy to approve as-is if that's your preference on the question I'm asking.

My question is described more fully in the inline comment, but I wonder whether there's a dependency between the AwsAuth and AwsConfigValidator classes that isn't necessary, and could be cleaner / more maintainable if we moved the two validate_* methods out of AwsAuth and into AwsConfigValidator.

If I'm wrong about this, then go ahead and

[matt-bernhardt]

Would it be cleaner to move validate_base_aws_config! and validate_required_vars! to the AwsConfigValidator class?

My understanding of the functionality here is that, for each of the three validation pathways, we follow this logic:

1. Create a Hash based on the current environment, using nil as the default value each time.
2. Pass that hash through the validate_required_vars! method, making sure that no nil values are present.

This feels pretty solid as an approach, could be extended to other configuration validation, and could also be applied to TIMDEX UI when that application integrates with all the services it consumes - so I really like it.

When I compare the three routes implemented in AwsConfigValidator, though, there is a difference between which class handles what - the lambda config gets passed to AwsAuth for building the hash, while the hash gets built directly in AwsConfigValidator for the AWS OS paths. Those two locations then each call the hash validation method in AwsAuth.

I wonder whether it would be self-contained if all three paths built the hash in AwsConfigValidator, and the hash validation method was part of the same class? That would leave AwsAuth to focus on interacting with the lambda and opensearch initializers as they are now, using the _credentials and _arn_present? methods.

[JPrevost]

Good call out. I'm going to see if it is as clean as I think it should be to do this refactor now.

[matt-bernhardt]

This looks good to me - the layout of AwsConfigValidator and AwsAuth are much cleaner. I like the additional method documentation blocks as well. Thanks!