Summary

ClusterLogForwarder CloudWatch authentication does not expose Vector's built-in assume_role capability, preventing cross-account log forwarding and role chaining scenarios.

Technical Problem Statement

Vector's AWS CloudWatch sink supports dual authentication mechanisms:

1. Primary authentication via ServiceAccount web identity tokens (AWS STS) using environment variables (AWS_ROLE_ARN, AWS_WEB_IDENTITY_TOKEN_FILE)
2. Secondary role assumption via the auth.assume_role configuration field

The ClusterLogForwarder API currently only exposes the primary authentication mechanism through the roleARN field. This prevents users from leveraging Vector's existing auth.assume_role capability, which is essential for:

• Cross-account log forwarding (assume role in target account)
• Role chaining architectures (minimal cluster permissions + specific logging roles)
• Compliance scenarios requiring role separation

Current Technical Gap: The operator generates Vector configuration that only populates primary authentication fields but never populates auth.assume_role, even though Vector natively supports this functionality.

Use Cases Affected

1. Cross-account enterprise logging - Forward logs from Account A clusters to Account B CloudWatch
2. Least privilege architectures - Cluster ServiceAccount has minimal permissions, assumes specific logging roles on-demand
3. Managed cluster scenarios - Cluster operators forward logs to customer-owned accounts
4. Compliance environments - Role separation requirements prevent direct CloudWatch permissions on cluster roles

Acceptance Criteria

AC1: API Enhancement

• [ ] ClusterLogForwarder CloudWatch authentication exposes Vector's assume_role capability as an optional field
• [ ] Additional role ARN sourced from Kubernetes secrets with proper validation
• [ ] Backward compatibility maintained for existing configurations

AC2: Vector Configuration Generation

• [ ] Operator generates Vector config with auth.assume_role when additional role specified
• [ ] ServiceAccount authentication (primary) and assume_role (secondary) work together
• [ ] No conflicting authentication configuration that causes Vector enum errors

AC3: Cross-Account Functionality

• [ ] Successful log forwarding from Account A cluster to Account B CloudWatch
• [ ] Proper AWS STS assume_role flow: ServiceAccount token → Primary role → Assumed role → CloudWatch
• [ ] IAM trust relationships correctly leveraged between accounts/roles

AC4: Technical Validation

• [ ] Generated Vector configuration passes Vector's AWS authentication validation
• [ ] Secret mounting works correctly for assume_role ARN values
• [ ] Clear error messages for IAM permission/trust relationship issues

AC5: Documentation

• [ ] Complete AWS IAM configuration examples (trust policies, permissions)
• [ ] ClusterLogForwarder configuration examples for cross-account scenarios
• [ ] Troubleshooting guide for common IAM configuration issues