FluentBit Helm add-on throws multiple errors

[vara-bonthu]

Description

Please provide a clear and concise description of the issue you are encountering, and a reproduction of your configuration (see the examples/* directory for references that you can copy+paste and tailor to match your configs if you are unable to copy your exact configuration). The reproduction MUST be executable by running terraform init && terraform apply without any further changes.

If your request is for a new feature, please use the Feature request template.

• ✋ I have searched the open/closed issues and my issue is not listed.

⚠️ Note

Before you submit an issue, please perform the following first:

1. Remove the local .terraform directory (! ONLY if state is stored remotely, which hopefully you are following that best practice!): rm -rf .terraform/
2. Re-initialize the project root to pull down modules: terraform init
3. Re-attempt your terraform plan or apply and check if the issue still persists

Versions

• Module version [Required]:

• Terraform version:

• Provider version(s):

Reproduction Code [Required]

Steps to reproduce the behavior:

My yaml config for deploying the FluentBit add-on

cloudWatchLogs:
  enabled: true
  logGroupName: "/mycluster/myloggroup/"

FluentBit Helm Chart is trying to create a new CW Log Group by default with name /aws/eks/fluentbit-cloudwatch/logs even if i specify the name. Its because the default value is autoCreateGroup: true. Since, this module is creating the CW Log group, I have set this to false in set values in my PR.

You can also update the config below but its still throwing an error. This time its due to cloudWatchLogs.logGroupTemplate which is overriding the logGroupName. I have set this value to null in the new PR.

cloudWatchLogs:
  enabled: true
  logGroupName: "/mycluster/myloggroup/"
  autoCreateGroup: false

Second issue: FluentBit add-on is successfully deployed however, the log throws an error that IAM role doesn't have access to DescribeLogStreams and CreateLogStream etc.

This issue is due to missing :* in IAM policy

Expected behaviour

Actual behaviour

Terminal Output Screenshot(s)

Additional context