- Newest
- Most votes
- Most comments
The issue is two-fold:
1. IAM permissions gap after controller upgrade
When upgrading the AWS Load Balancer Controller, the IAM policy attached to the controller's service account role must be updated to match the new version's requirements. Each controller version may add new API calls. The current policy document is always at:
If the controller lacks permissions like ec2:DescribeSecurityGroups or ec2:AuthorizeSecurityGroupIngress, it cannot resolve security group names/IDs and fails with "couldn't find all securityGroups, nameOrIDs".
2. Conflicting security group annotations in a shared IngressGroup
When multiple Ingress resources share an IngressGroup (via alb.ingress.kubernetes.io/group.name), all members must have consistent security group annotations. If one Ingress specifies alb.ingress.kubernetes.io/security-groups: sg-aaa and another in the same group specifies sg-bbb, the controller cannot reconcile them and throws "conflicting securityGroups".
Resolution:
- Update the IAM policy for the controller's role to the latest version:
curl -o iam_policy.json https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/main/docs/install/iam_policy.json aws iam put-role-policy \ --role-name your-lb-controller-role \ --policy-name AWSLoadBalancerControllerIAMPolicy \ --policy-document file://iam_policy.json
- Ensure all Ingress resources in the same IngressGroup use the same security group annotation, or remove the annotation from all but one and let the controller manage it:
kubectl get ingress -A -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.annotations.alb\.ingress\.kubernetes\.io/security-groups}{"\n"}{end}'
Remove the conflicting annotation from the duplicate:
kubectl annotate ingress <ingress-name> -n <namespace> alb.ingress.kubernetes.io/security-groups-
- Do not manually attach security groups to the ALB via the AWS Console. The controller manages the full lifecycle of resources it creates. Manual modifications cause drift that the controller cannot reconcile.
Key takeaway: Always update the controller IAM policy when upgrading the AWS Load Balancer Controller version, and never mix manual Console changes with controller-managed resources.
References:
- IAM policy requirements: https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/deploy/installation/#iam-permissions
- IngressGroup: https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress/annotations/#ingressgroup
- Security group annotations: https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress/annotations/#security-groups
answered a year ago
Hello, I understand you're experiencing issues with the AWS Load Balancer Controller where new ingresses have empty address/endpoint fields, and you're seeing security group related errors in the controller logs. Based on my analysis, this issue is related to a conflict between manually assigned security groups and the controller's configuration. Let me explain what's happening and provide some solutions. The error messages you're seeing - "couldn't find all securityGroups" and "conflicting securityGroups" - indicate that there's a discrepancy between the security groups specified in your ingress annotations and what's actually configured on the ALB. When you manually added security groups to the ALB via the AWS Console after your EKS upgrade, you created a situation where the Load Balancer Controller's expected configuration doesn't match the actual ALB configuration. This explains why:
New ingresses have empty address fields - the controller can't properly configure the ALB due to security group conflicts
Deletions are failing - the controller can't reconcile the resources due to the configuration mismatch
Here are my recommended steps to resolve this issue: First, decide on your preferred approach: Either let the Load Balancer Controller manage security groups through annotations Or continue managing them manually through the AWS Console If you choose to let the controller manage security groups: Remove the manually assigned security groups from the ALB in the AWS Console Update your ingress resources with the correct security group annotations:
annotations: alb.ingress.kubernetes.io/security-groups: sg-zzzz,sg-yyyy Ensure the security group IDs exist and are accessible to the controller
If you prefer manual management: Add the annotation to explicitly tell the controller not to manage security groups: annotations: alb.ingress.kubernetes.io/manage-backend-security-group-rules: "false"
For any stuck ingress resources that won't delete, continue using the finalizer removal approach that's working for you: kubectl patch ingress <ingress-name> -n <namespace> -p '{"metadata":{"finalizers":[]}}' --type=merge After making these changes, restart the controller to ensure it picks up the new configuration: kubectl rollout restart deployment aws-load-balancer-controller -n kube-system Verify the IAM permissions for the controller to ensure it has the necessary permissions to manage security groups: ec2:DescribeSecurityGroups ec2:CreateSecurityGroup ec2:DeleteSecurityGroup ec2:AuthorizeSecurityGroupIngress ec2:RevokeSecurityGroupIngress
This conflict likely occurred during your EKS upgrade when the controller version changed. The v2.8.1 controller you're running might be handling security groups differently than your previous version, especially if there were changes to how it manages resources. For additional troubleshooting, I recommend checking the controller logs with increased verbosity:
kubectl logs -n kube-system deployment/aws-load-balancer-controller --follow
References: [1] AWS Load Balancer Controller Security Group Management: https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.8/guide/ingress/annotations/#security-groups [2] Troubleshooting AWS Load Balancer Controller: https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.8/troubleshooting/ [3] AWS Load Balancer Controller IAM Permissions: https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.8/deploy/installation/#iam-permissions
answered a year ago

I upgraded the controller as well as referenced controller installation docs and updated the IAM permissions for IAM policy used by the role attached to the controller. Key lesson was to always reference the docs and update IAM permissions accordingly. To resolve the conflicting security group, I removed the annotation for the security group from one of the ingress that had it.