AWS EKS中配置Fluent-Bit对接CloudWatch的IAM权限问题排查

1. IAM角色信任策略配置错误（核心问题） #

你的aws_iam_role.cloudwatch_logs_role信任策略设置为允许logs.amazonaws.com扮演角色，但EKS服务账号IRSA（IAM Roles for Service Accounts）需要的是EKS OIDC提供商作为信任主体，而非CloudWatch Logs服务。这是导致凭证获取失败的根本原因。

修正后的IAM角色信任策略 #

先添加EKS集群OIDC提供商的数据源，再更新角色的信任策略：

data "aws_eks_cluster" "main" {
  name = "xxxx-kubernetes-sandbox" # 替换为你的EKS集群名称
}

data "aws_iam_openid_connect_provider" "eks_oidc" {
  url = data.aws_eks_cluster.main.identity.0.oidc.0.issuer
}

resource "aws_iam_role" "cloudwatch_logs_role" {
  name = "cloudwatch-logs-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Action = "sts:AssumeRoleWithWebIdentity",
        Effect = "Allow",
        Principal = {
          Federated = data.aws_iam_openid_connect_provider.eks_oidc.arn
        },
        Condition = {
          StringEquals = {
            "${replace(data.aws_iam_openid_connect_provider.eks_oidc.url, "https://", "")}:sub" = "system:serviceaccount:${var.fluentbit_namespace}:${var.fluentbit_service_account_name}"
          }
        }
      }
    ]
  })
}

2. 调整Fluent-Bit配置 #

移除Output中的role_arn配置 #

通过IRSA关联角色后，Fluent-Bit会自动通过Pod内的Web Identity凭证获取权限，无需手动指定role_arn，否则会触发额外的STS AssumeRole请求导致错误。

修正Filter的Match规则 #

你的Input标签是kube.*，但Filter的Match是application.*，这会导致Filter完全不生效，日志无法被Kubernetes元数据处理。将Filter的Match改为kube.*：

[FILTER]
    Name                kubernetes
    Match               kube.* # 修正此处
    Kube_URL            https://kubernetes.default.svc:443
    Kube_Tag_Prefix     kube.var.log.containers. # 同步修正Tag前缀
    Merge_Log           On
    Merge_Log_Key       log_processed
    K8S-Logging.Parser  On
    K8S-Logging.Exclude Off
    Labels              Off
    Annotations         Off
    Use_Kubelet         On
    Kubelet_Port        10250
    Buffer_Size         0

优化Log Stream名称（可选） #

使用动态变量生成Log Stream名称，避免固定名称导致冲突：

log_stream_name     ${TAG_NAME}-${HOSTNAME}

3. 验证IRSA关联有效性 #

进入Fluent-Bit Pod，检查是否存在IRSA相关环境变量：

kubectl exec -n <fluentbit-namespace> <fluentbit-pod-name> -- env | grep AWS_

应输出类似内容：

AWS_ROLE_ARN=arn:aws:iam::123456789012:role/cloudwatch-logs-role
AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount/token

如果没有这些变量，说明服务账号与IAM角色的关联未生效，需检查：

• 服务账号的eks.amazonaws.com/role-arn注解是否正确
• EKS集群是否已启用OIDC提供商（可通过AWS控制台EKS集群详情查看）

4. 其他排查步骤 #

• 检查IAM权限：确认aws_iam_policy.cloudwatch_logs_policy已正确附加到角色，且权限包含所需的CloudWatch Logs操作
• 检查Log Group存在性：aws_cloudwatch_log_group.cloudwatch_log_group已创建，且名称与Fluent-Bit配置中的log_group_name一致
• 检查Pod权限：Fluent-Bit DaemonSet的Pod模板是否指定了正确的服务账号
• 查看Fluent-Bit完整日志：获取Pod的完整日志，排查是否有其他隐藏错误：

  kubectl logs -n <fluentbit-namespace> <fluentbit-pod-name> -f
  

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