feat: Add support for inline policy for IAM EKS Role

[matandomuertos]

Description

This PR extends the inline policy support to iam-eks-role module.
Original PR: #479

Motivation and Context

Inline policy is supported only by iam-assumable-role-with-oidc and iam-assumable-role modules, this PR extends the support to iam-eks-roles.

Breaking Changes

None

How Has This Been Tested?

• I have updated at least one of the examples/* to demonstrate and validate my change(s)
• I have tested and validated these changes using one or more of the provided examples/* projects
• I have executed pre-commit run -a on my pull request

[bryantbiggs]

just because other modules support, that isn't a valid reason to support it here. we have gone a few years without it so I am inclined to keep pushing for not using inline policies

[matandomuertos]

Hey @bryantbiggs, I’m wondering if there are any plans to deprecate inline policies entirely. When using Terragrunt, we often have to rely on workarounds and dependencies to create custom policies for iam-eks-role, and inline policies could simplify this process.

For example, right now, a common workaround is to use iam-assumable-role-with-oidc, but iam-eks-role is more straightforward because it only requires the cluster name rather than the OIDC ARN. Integrating inline policies into iam-eks-role could effectively combine these approaches.

While this might be less of an issue with raw Terraform, it would be quite helpful with third-party tools like Terragrunt. It would also help maintain consistency across modules. Currently, I’ve only added it to one module where it was needed, but it might be worth discussing the possibility of including it in all IAM modules to ensure uniformity.

Looking forward to your thoughts!

[bryantbiggs]

inline policies sort of defeat the purpose of this sub-module. I would be interested to learn more about the need for inline policies

[matandomuertos]

Hi, @bryantbiggs, based on my understanding, this sub-module is designed to create IAM roles that can be assumed by service accounts in EKS clusters. It functions similarly to iam-role-for-service-accounts-eks, but with a key difference: it configures OIDC assumptions without requiring the exact OIDC ARN, using only the cluster name instead. This approach simplifies the setup, reducing the need for extensive configuration and variables.

Currently, the only way to create roles that service accounts can assume without knowing the OIDC ARN is through iam-eks-role. Attaching policies to these roles necessitates creating an additional resource for policy management, which can add unnecessary lines of code and dependencies. Inline policies could streamline this process.

Here’s a breakdown of how I see the usage of these sub-modules:

• iam-role-for-service-accounts-eks: Best for creating IAM roles for service accounts used by commonly employed controllers or custom resources.
• iam-eks-role: Suitable for creating roles that service accounts will assume with custom policies when the OIDC ARN is unknown.
• iam-assumable-role-with-oidc: Ideal for fully custom roles with specific OIDC configurations.

I hope this clarifies things. Thanks!

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.