aws/config: validate credentials before SigV4 signing

[kcreddy]

Proposed commit message

aws/config: validate credentials before SigV4 signing

The AWS Config CEL program accesses state.secret_key and
state.access_key without guards. When a user configures the
integration with Role ARN or no credentials (both valid for other
AWS data streams), the program crashes with the unhelpful error
"no such key: secret_key".

Add a credential check at the top of the CEL program that detects
missing or empty access_key_id / secret_access_key and returns a
clear error explaining that static credentials are required and
Role ARN is not supported for this data stream. The check uses
optional field access (state.?secret_key.orValue("")) to handle
both absent and empty-string cases safely.

Update the data stream docs and manifest description to state the
Role ARN limitation upfront. Add a script test that verifies the
error message is emitted when credentials are missing.

Fixes #18332

Checklist

• I have reviewed tips for building integrations and this pull request is aligned with them.
• I have verified that all data streams collect metrics or logs.
• I have added an entry to my package's changelog.yml file.
• I have verified that Kibana version constraints are current according to guidelines.
• I have verified that any added dashboard complies with Kibana's Dashboard good practices

How to test this PR locally

Script tests run sucessfully

# Test that the AWS Config data stream emits a clear error event when
# access_key_id and secret_access_key are not provided. (41.941s)
# The credential check fires before any HTTP request, so exactly one error
# event should be indexed per evaluation cycle. Wait for at least 1. (8.027s)
# Verify the error message names the missing credentials. (0.039s)
# Verify no data events were produced — only error events. (0.023s)
# Clean up. (12.967s)
PASS

--- Test results for package: aws - START ---
╭─────────┬─────────────┬───────────┬─────────────────────┬────────┬────────────────╮
│ PACKAGE │ DATA STREAM │ TEST TYPE │ TEST NAME           │ RESULT │   TIME ELAPSED │
├─────────┼─────────────┼───────────┼─────────────────────┼────────┼────────────────┤
│ aws     │ config      │ script    │ env                 │ PASS   │    32.725625ms │
│ aws     │ config      │ script    │ missing_credentials │ PASS   │ 1m3.002499542s │
╰─────────┴─────────────┴───────────┴─────────────────────┴────────┴────────────────╯
--- Test results for package: aws - END   ---
Done

Related issues

• Closes [aws] AWS Config: improve error when credentials are missing and clarify Role ARN limitation in docs #18332

Screenshots

[elasticmachine]

Pinging @elastic/security-service-integrations (Team:Security-Service Integrations)

[github-actions]

✅ Vale Linting Results

No issues found on modified lines!

---

The Vale linter checks documentation changes against the Elastic Docs style guide.

To use Vale locally or report issues, refer to Elastic style guide for Vale.

[elastic-vault-github-plugin-prod]

🚀 Benchmarks report

To see the full report comment with /test benchmark fullreport

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: fae22ac

History

• 💚 Build #41225 succeeded da6c965

cc @kcreddy

[elastic-vault-github-plugin-prod]

Package aws - 6.5.1 containing this change is available at https://epr.elastic.co/package/aws/6.5.1/

[efd6]

Note that v8.19.4 and v9.2.1 both have access to AWS SigV4 signing functions which offer env, shared and static credentials.

[kcreddy]

Note that v8.19.4 and v9.2.1 both have access to AWS SigV4 signing functions which offer env, shared and static credentials.

In another discussion #10784 (comment), there was another feature auth.aws (now backported into 8.19: elastic/beats#50141) which can also do this. The idea here was to use this auth.aws once it is available in 8.19.

Is there any preferred method between the two (mito signing functions vs auth.aws)?

[efd6]

I completely forgot about that. The discussion here is good for knowing which. If it was your plan to wait for that, that's fine.