-
Epic
-
Resolution: Unresolved
-
Major
-
None
-
Support STS Cloudwatch Forwarding to Multiple Outputs
-
False
-
None
-
False
-
NEW
-
OBSDA-1117 - Support Multiple CloudWatch Outputs with unique STS Role Authentication
-
-
NEW
-
60% To Do, 20% In Progress, 20% Done
-
M
-
Log Collection - Sprint 232, Log Collection - Sprint 267
Goals
- The goal of this effort is to enable the creation of forwarder specifications that support multiple CloudWatch outputs, each utilizing unique STS role authentication.
Non-Goals
- Modifying existing authentication cloudwatch API to enable multiple STS roles.
Motivation
- The primary motivation is to allow customers the ability to forward logs, using STS, to multiple cloudwatch outputs, each authenticated with distinct AWS role_arns, enhancing security and flexibility.
Alternatives
- The only current alternative for STS authentication is to create forwarders in unique namespaces for each output/role.
- Without STS, the customer can still use multiple static, long-lived credentials for cloudwatch outputs.
Acceptance Criteria
- Verify CLO can still forward logs using single output to cloudwatch using an STS role.
- Multiple outputs can be forwarded to cloudwatch using unique STS roles.
- Logs can still be forwarded to cloudwatch using static, long-lived credentials.
- Logging docs reflect this capability and removes any mention of known issues.
- Verify the HCP team can forward logs from a single collector to separate AWS Outputs using distinct roleARNs
Risk and Assumptions
- We are assuming that the cluster and AWS STS roles are correctly configured and accessible.
- Potential risks include misconfigured profiles or credentials files leading to authentication failures.
- Currently anaware of any rbac or security related issues with using multiple STS roles?
Documentation Considerations
- Document the pre-reqs needed for a AWS STS-enabled platform to receive logs and provide authorization to the collector serviceaccount
- Document the support of multiple outputs in the log-forwarder spec
- Upstream and public logging docs should reflect this capability and remove any mention of known issues.
Open Questions
- No API changes should be required, so nothing to update for upstream docs?
Additional Notes
- The token path is set by the CLO so users do not need to specify the token path in the secret. role_arn is the only field required/needed in the secret.
- is related to
-
LOG-5539 When log forwarding to cloudWatch using different AWS Role, all logs arrives to the first
-
- Closed
-