Dangling AWS Shield Protections after Ingress are deleted
#4 042 ouverte le 5 févr. 2025
Métriques du dépôt
- Stars
- (4 317 étoiles)
- Métriques de merge PR
- (Métriques PR en attente)
Description
Bug Description
We use AWS Load balancer controller to manage ingress. We are using alb.ingress.kubernetes.io/shield-advanced-protection ingress annotation to protect the ingress using AWS Shield. This part works perfectly fine. However, when we delete our ingresses, we see that the Protection resource is not deleted.
Protection resources have below attributes.
"Name" = "managed by aws-load-balancer-controller"
"AWS Resource" = ""
"Resource type" = "Application Load Balancer"
"Status" = "Resource Deleted"
"AWS WAF web ACL" = "Error"
Steps to Reproduce
- Provision an ingress with Annotation
alb.ingress.kubernetes.io/shield-advanced-protection = true - Verify Shield Protection resource is created
- Delete the ingress
Expected Behavior
Since the protection resource is managed by load balancer controller, it should be deleted by the controller.
Actual Behavior
Protection resource still exists in a dangling state.
Regression Was the functionality working correctly in a previous version ? [Yes / No] If yes, specify the last version where it worked as expected Unsure about this.
Current Workarounds
NA
Environment
- AWS Load Balancer controller version: v2.4.6
- Kubernetes version: EKS 1.29
- Using EKS (yes/no), if so version?: 1.29
- Using Service or Ingress: Ingress
- AWS region: All regions
- How was the aws-load-balancer-controller installed:
- If helm was used then please show output of
helm ls -A | grep -i aws-load-balancer-controller - If helm was used then please show output of
helm -n <controllernamespace> get values <helmreleasename> - If helm was not used, then copy/paste the exact command used to install the controller, including flags and options.
- If helm was used then please show output of
- Current state of the Controller configuration:
kubectl -n <controllernamespace> describe deployment aws-load-balancer-controller
- Current state of the Ingress/Service configuration:
kubectl describe ingressclasseskubectl -n <appnamespace> describe ingress <ingressname>kubectl -n <appnamespace> describe svc <servicename>
Possible Solution (Optional)
NA
Contribution Intention (Optional)
- Yes, I'm willing to submit a PR to fix this issue
- No, I cannot work on a PR at this time
Additional Context