Fluent Bit多AWS账号Kinesis Firehose输出role_arn配置排查

问题背景 #

使用Fluent Bit v1.8.12向多个AWS账号下的多个Kinesis Firehose Stream投递日志时，需要正确配置kinesis_firehose OUTPUT插件的role_arn参数。当前环境状态：

• 向账号A下的Firehose A投递日志功能正常
• 向账号B下的Firehose B投递日志持续失败
• 已知IAM权限链路：账号A下的role-a已配置账号B下role-b的AssumeRole权限
  配置目标架构示意图：
  

当前使用的OUTPUT配置 #

[OUTPUT]
    Name              kinesis_firehose
    Match             aaa
    region            eu-west-1
    delivery_stream   a
    time_key          time  
    role_arn          arn:aws:iam::11111111111:role/role-a

# 该配置块投递失败
[OUTPUT]
    Name              kinesis_firehose
    Match             bbb
    region            eu-west-1
    delivery_stream   b
    time_key          time  
    role_arn          arn:aws:iam::22222222222:role/role-b

运行报错日志 #

[2022/06/21 15:03:12] [error] [aws_credentials] STS assume role request failed
[2022/06/21 15:03:12] [ warn] [aws_credentials] No cached credentials are available and a credential refresh is already in progress. The current co-routine will retry.
[2022/06/21 15:03:12] [error] [signv4] Provider returned no credentials, service=firehose
[2022/06/21 15:03:12] [error] [aws_client] could not sign request
[2022/06/21 15:03:12] [error] [output:kinesis_firehose:kinesis_firehose.1] Failed to send log records to b
[2022/06/21 15:03:12] [error] [output:kinesis_firehose:kinesis_firehose.1] Failed to send log records
[2022/06/21 15:03:12] [error] [output:kinesis_firehose:kinesis_firehose.1] Failed to send records

故障根因 #

报错由两个已知问题共同触发：

1. Fluent Bit v1.8.12的AWS凭证模块为全局单例实现，多OUTPUT块配置不同role_arn时存在凭证缓存锁冲突bug，多个输出块并行刷新凭证时会出现互斥，导致部分块拿不到有效凭证。
2. 该版本不支持自动链式AssumeRole：第二个OUTPUT块配置role-b的ARN时，插件会直接使用Pod运行环境的基础凭证（IRSA绑定角色/EC2工作节点角色）调用STS接口请求代入role-b，不会复用第一个OUTPUT块获取到的role-a临时凭证做跳转，而当前role-b的信任策略仅允许role-a代入，因此STS请求直接被拒绝。

修复方案 #

按需选择以下任意一种方案即可修复：

方案1：小版本升级+IAM信任策略调整（成本最低） #

• 将Fluent Bit升级到v1.8系列最新补丁版本（至少v1.8.15），修复多角色凭证缓存锁冲突bug。
• 修改账号B下role-b的信任策略，将Fluent Bit Pod实际使用的基础IAM身份（IRSA服务角色/EC2节点角色）加入受信主体，同时给该基础身份分配指向role-b的sts:AssumeRole权限。
• 保留原有OUTPUT配置不变，重启Fluent Bit即可恢复投递。

方案2：AWS配置文件实现链式AssumeRole（无需升级、不改动现有角色链路） #

• 编写AWS配置文件，定义角色跳转链路：

[profile cross-account-b]
role_arn = arn:aws:iam::22222222222:role/role-b
source_profile = account-a
region = eu-west-1

[profile account-a]
role_arn = arn:aws:iam::11111111111:role/role-a
# 按实际运行环境选择：IRSA环境填EcsContainer，节点角色环境填Ec2InstanceMetadata
credential_source = EcsContainer
region = eu-west-1

• 将该配置文件通过ConfigMap挂载到Fluent Bit Pod的/root/.aws/config路径，确保进程有读取权限。
• 修改第二个OUTPUT块配置，移除role_arn参数，添加profile配置项：

[OUTPUT]
    Name              kinesis_firehose
    Match             bbb
    region            eu-west-1
    delivery_stream   b
    time_key          time  
    profile           cross-account-b

• 重启Fluent Bit后，底层AWS SDK会自动按配置先代入role-a，再使用role-a的临时凭证代入role-b完成请求签名。

方案3：升级到v1.9+版本使用原生链式角色支持 #

• 直接将Fluent Bit升级到v1.9.0及以上稳定版本，该版本重构了AWS凭证模块，既修复了多角色缓存冲突问题，也原生支持链式AssumeRole能力。
• 仅需在第二个OUTPUT块添加source_role_arn arn:aws:iam::11111111111:role/role-a参数，原有role_arn保留为role-b的ARN即可，不需要额外挂载配置文件。

配置校验要点 #

配置完成后观察Fluent Bit运行日志，无STS相关报错、Firehose B可正常接收日志即为生效。如果仍有投递失败，优先排查以下项：

• 角色信任策略的Principal配置是否正确，是否存在Organization、账号ID等限制
• 角色关联的权限策略是否包含目标Firehose的firehose:PutRecord、firehose:PutRecordBatch等必要操作权限
• 跨账号角色是否配置了外部ID、MFA等额外校验，如有需要在OUTPUT块添加external_id参数对应

内容的提问来源于stack exchange，提问作者Stefano Lazzaro