初めに

• Fluentd、Fluentbitの開発元は同じ
• もっと軽量なFluentdが欲しくてFluentbitが開発された

「Fluentd vs Fluentbit」の日本語の比較記事が見当たらないので以下の記事を紹介します。

https://logz.io/blog/fluentd-vs-fluent-bit/

端的に言うと「Fluentbitは、成熟度(e.g., Plugin数)はFluentdより劣るが従来の10分の1以下のメモリ使用量しか消費しないので大規模ネットワークにおいて有用。Fluentdにログ集約して整形するのもあり」

ぱっと見、大抵の場合はFluentbitだけで事足りるのでは？と思うので公式チュートリアルを見ながら試してみます。

https://docs.fluentbit.io/manual

テスト環境

今回の環境は以下の通り

• AWS EKS 1.22
• OpenSearch (別アカウント)

手順

1. https://docs.fluentbit.io/manual/installation/kubernetes にてhelmインストールを選択
2. デフォルトのvalues.yamlは全てのLogを集約してOpenSearch (ElasticSearch)に送る仕様となっているので、別アカウントのOpenSearchドメインを指定。設定は https://docs.fluentbit.io/manual/pipeline/outputs/elasticsearch を確認。

config:
  ## https://docs.fluentbit.io/manual/pipeline/outputs
  outputs: |
    [OUTPUT]
        Name es
        Match *
        Host <your-opensearch-domain>
        ...

問題は別アカウントのOpenSearchにどうやってアクセスするか。

問題点

• 以下の設定を試すが、OpenSearchに弾かれる

config:
  ## https://docs.fluentbit.io/manual/pipeline/outputs
  outputs: |
    [OUTPUT]
        Name  es
        Match *
        Host  <domain>.eu-west-1.es.amazonaws.com
        Port  443
        tls   On
        AWS_Auth On
        AWS_Region eu-west-1

FluentBit Pod1: {"Message":"User: arn:aws:sts::xxx:assumed-role/yyy/zzz1 is not authorized to perform: es:ESHttpPost because no resource-based policy allows the es:ESHttpPost action"}
FluentBit Pod2: {"Message":"User: arn:aws:sts::xxx:assumed-role/yyy/zzz2 is not authorized to perform: es:ESHttpPost because no resource-based policy allows the es:ESHttpPost action"}

OpenSearch側のセキュリティポリシーにおいてUser: arn:aws:sts::xxx:assumed-role/yyy/*をallowする設定は不可能👉AWSドキュメント

When you specify an assumed-role session in a Principal element, you cannot use a wildcard "*" to mean all sessions. Principals must always name a specific session.

https://medium.com/@bahubalishetti/configuring-fluentd-on-kubernetes-with-aws-elasticsearch-df9f8c4c6123

解決策として以下のパターンが考えられる。

• VPC Peering等でElasticsearchに直接アクセスさせる
• Proxy を使う - https://medium.com/@bahubalishetti/configuring-fluentd-on-kubernetes-with-aws-elasticsearch-df9f8c4c6123

追記

https://dev.classmethod.jp/articles/iam-role-to-which-aws-sso-iam-role-can-assume-role/

Condition句を使えばいけるかも

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::(AccountAのID):root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "ArnLike": {
          "aws:PrincipalArn": "arn:aws:iam::(AccountAのID):role/aws-reserved/sso.amazonaws.com/ap-northeast-1/AWSReservedSSO_AdministratorAccess_*"
        }
      }
    }
  ]
}