KMS-654: Ensure KMS logs from the lambdas are available in Splunk

[htranho]

Overview

What is the feature?

Ensure KMS logs from the lambdas are available in Splunk

What is the Solution?

1. Added new helper class, LogForwardingSetup.ts, that:

• Creates CloudWatch Log Groups for each Lambda function with retention policy
• Sets up Subscription Filters to forward logs to NGAP SecLog destination
• Uses cross-account destination ARN (no IAM role needed)
• Validates required parameters

2. KmsLambdaFunctions.ts

• Add stage name to function names

3. KmsStack.ts

• Add logDestinationAccount and secLogAccount to interface.
• Add LogForwardingSetup

4. CmrEventProcessingStack.js

• Add logDestinationAccount and secLogAccount to interface.
• Add LogForwardingSetup

5. main.ts

• Read new env vars, added validation, pass to stacks.

6. deploy_bamboo.sh

• Added 2 new environment variables to Docker run

What areas of the application does this impact?

Logging now forwarded to Splunk. Example for sit env:
log_group="/aws/lambda/kms-sit*"

Testing

Invoke kms endpoints, use log_group above in Splunk to search for logs.

Attachments

N/A

Checklist

• I have added automated tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.67%. Comparing base (df3adc1) to head (349f3bc).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #101   +/-   ##
=======================================
  Coverage   99.67%   99.67%           
=======================================
  Files         153      153           
  Lines        3070     3070           
  Branches      738      737    -1     
=======================================
  Hits         3060     3060           
  Misses          9        9           
  Partials        1        1           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[cgokey]

Did you deploy this already? I know AWS automatically creates log groups, does this override the existing log groups already created? I'm wondering if you'll get conflicts trying to explicity create a log group with a retention policy that was automatically already created.

[cgokey]

maybe something like this: const logRetention = new logs.LogRetention(scope, `${sanitizedKey}-LogRetention`, { logGroupName, retention: this.logRetentionDays }). then you are not recreating the log group.

[cgokey]

I think this may be over-parameterized. If the destination name is always keyed by the current/source account, shouldn’t this just be this.account? Carrying a separate logDestinationAccount here feels redundant unless we have a real case where that suffix differs from the current account.`

[htranho]

Now using logDestinationArn.

[cgokey]

One thing I’d like to double-check here: changing the function name to ${prefix}-${stage}-${functionName} looks like it will replace all existing KMS Lambdas on deploy, not just add log forwarding. Was that intentional for this ticket? If not, it may be worth avoiding the rename so we don’t widen the rollout impact of a logging change.`

[cgokey]

I can see the value in this even though it forces a one-time Lambda replacement. It gives us consistent stage-aware naming and makes the log-group/log-forwarding story cleaner.

[cgokey]

Since SEC_LOG_ACCOUNT is already validated in main.ts for non-localstack deploys, could we make it required in the stack/construct props as well instead of carrying it as optional and asserting with !? I think that would make the contract a little clearer and keep the typing aligned with the actual runtime requirement.

[htranho]

Now using logDestinationArn