aws-load-balancer-controller
aws-load-balancer-controller copied to clipboard
Allow parameters like wafv2-acl-arn to be referenced via Kubernetes Secrets or ConfigMaps
Describe the feature you are requesting
We're looking for a way to manage AWS resources like Web ACLs and Certificates using Kubernetes Secrets or ConfigMaps instead of relying solely on ingress annotations. This change would allow us to deploy these resources within EKS using Terraform and then reference them in our Kubernetes configurations, making our setup more cohesive and efficient. Also it would align with the current prevalent GitOps Bridge Strategy.
Motivation
In our current workflow, we use Terraform to create infrastructure components such as Certificates and Web ACLs, while ArgoCD handles the deployment of Kubernetes Workloads. The existing method of managing these resources through ingress annotations feels a bit clunky and doesn't fit well with our infrastructure management strategy. By enabling the use of Kubernetes Secrets or ConfigMaps, we could streamline our processes, reduce complexity, and better align with our existing tools and practices.
Describe the proposed solution you'd like
We envision a solution where the AWS Load Balancer Controller can reference AWS resources like Web ACLs and Certificates directly from Kubernetes Secrets or ConfigMaps. This would mean we could deploy these resources using Terraform and then simply point to them in our ingress configurations. Such a feature would greatly enhance our ability to manage infrastructure in a more integrated and efficient manner.
Describe alternatives you've considered
We've thought about sticking with the current approach of using ingress annotations, but it doesn't really meet our needs as it complicates our workflow and doesn't fully utilize our Terraform capabilities. Another option would be to manage everything through Terraform, but that would require significant changes to our current setup with ArgoCD, which isn't ideal for us.
@RamazanKara Thank you for reaching out to us and providing such a great feature request description. I understand your current challenges. However, Instead of using the k8 secrets and configMaps, we can add/modify annotations to accept the name of these resources along with their arns so that we can fetch the resource for you based on its name instead of arn. This way you dont have to rely on the arns for your resources created through terraform. Would that be acceptable for you?
That would be an even better solution @shraddhabang thanks for your feedback.
@shraddhabang can I work on this? Also what resources do we consider for this? ACM's dont have a name but have an identifier. WAF ACLs do have a name so that might work with the approach you suggested.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle rotten - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
Any updates on this? We follow the same approach: using Terraform to create the WAF WebACL and configuring the ALB through Ingress with the AWS Load Balancer Controller. Unfortunately, we need to provide the WebACL ARN or ID in the annotation. It would be ideal if we could specify the WAF by name instead.
It would be much simpler if something like the following worked:
alb.ingress.kubernetes.io/wafv2-acl-name: '<webacl_name>'
/remove-lifecycle rotten
Taking the liberty to remove the rotten label.
I would be very much interested in this.
My costly workaround for now, in AWS, is to enable FMS with auto-remediation, which happened to fail today.
I think this Feature has now been implemented? Can somebody from the Contributor Team confirm?