Cherry-pick #20929 to 7.8: Clarify use for shared_credential_file #21083
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Cherry-pick of PR #20929 to 7.8 branch. Original message:
When starting Beats as a service, the Beat's PID will be owned by the user that manages the service. This would be root in most cases.
Users tend to run tests as non-root, running beats directly (./metricbeat) on the command line. Without the shared_credential_file path the beat checks for credentials under the user's home directory.
As a service, the home directory of the user managing the service (typically root) tends to be different than that of the user in testing and development, which can be difficult to figure out.
What does this PR do?
Clarifies AWS module's credential lookup behavior and when to use shared_credential_file to avoid ambiguity.
Why is it important?
Helps users avoid credential lookup issues, especially deviations between environments where Beats run as standalone process vs service.