Scoped configuration for load-balancer-controller #618
Description
Is your request related to a new offering from AWS?
Yes ✅: This functionality leverages existing AWS IAM conditional access features. The IAM condition keys used (aws:RequestTag, aws:ResourceTag) are standard AWS IAM features. This enhancement uses existing AWS provider functionality (version 3.0+) to implement more granular permission scoping.
Is your request related to a problem? Please describe.
Currently, the AWS Load Balancer Controller IAM policy grants overly broad permissions that allow the controller to manage AWS resources (security groups, load balancers, target groups) across ALL EKS clusters in an AWS account. This creates several security concerns:
Cross-cluster access: A compromised Load Balancer Controller in one cluster can modify resources belonging to other clusters
Principle of least privilege violation: The controller has more permissions than necessary for its designated cluster
Multi-tenant environments: Organizations running multiple EKS clusters cannot isolate Load Balancer Controller permissions per cluster
Compliance issues: Broad permissions make it difficult to meet security compliance requirements that mandate resource-level access controls
For example, if an organization has prod-cluster, staging-cluster, and dev-cluster, the current implementation allows the Load Balancer Controller in dev-cluster to potentially modify load balancers and security groups created by prod-cluster, which is a significant security risk.
Describe the solution you'd like.
Similar to the cluster autoscaler policy, add a new optional variable load_balancer_controller_cluster_names that allows users to scope AWS Load Balancer Controller IAM permissions to specific EKS clusters while maintaining full backward compatibility.
Key features:
Cluster-scoped permissions: When cluster names are provided, IAM conditions restrict actions to resources tagged with specific cluster identifiers
Backward compatibility: When no cluster names are provided, maintain current broad permissions (no breaking changes)
Multiple cluster support: Support for multiple clusters in the same IAM role
Consistent implementation: Apply the same scoping pattern used successfully in the Cluster Autoscaler policy
Describe alternatives you've considered.
Custom IAM policy outside the module: Create custom policies with cluster-specific conditions
Pros: Full control over permissions
Cons: Loses benefits of the community-maintained module, requires users to maintain complex IAM policies manually
Additional context
It is suggested in AWS load balancer controller docs