You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In my opinion, this feature request is more related to potential security issues, and specifically how the Certificate Discovery algorithm works.
My understanding, by reading the source code, is that Certificate Discovery will give precedence to wildcard certificates with respect to matching, non-wildcard certificates. As an example, if a Kubernetes Ingress for host foo.example.com is created that does not say which certificate ARN to use, Certificate Discovery will be triggered. Let's say that two certificates exist in AWS ACM, a wildcard certificate for *.example.com and a non-wildcard certificate for foo.example.com. The Certificate Discovery algorithm will select the wildcard certificate, as I understand by looking at the code [1]:
From a security point of view, selecting the wildcard certificate over another, non-wildcard one, that also matches the requested host is not ideal. This will leads to (ab)use of the wildcard certificate. In case it gets compromised, all ELBs that rely on it will also be compromised. Besides the risk, they will all need to get rotated, etc. I think this can be avoided by changing the Certificate Discovery algorithm to give precedence to non-wildcard certificates that match the TLS host.
To make the change to the algorithm more controllable, you can introduce some command-line flag gate to the AWS Load Balancer Controller that allows selecting the "old" behaviour (wildcard takes precedence) or the "new' behaviour (non-wildcard takes precedence). Hence, users of the AWS Load Balancer can select which behaviour they want, and to avoid unexpected breakages.
Describe alternatives you've considered
Unfortunately, there are no alternatives for us. Using the wildcard certificate works for us, but introduces undesired risk of having it compromised and exposing all data incoming through ELBs using this wildcard. Mostly because we also have Certificates in AWS ACM that match specifically all the TLS hosts that are involved here.
And we cannot remove the wildcard certificate, because we have also Ingress resources that are associated with an equilvalent DNS wildcard. However, for Ingress resources that have an specific TLS host, we would like to use the Certificate whose SN matches the TLS host, instead of relying on the wildcard certificate.
Is your feature request related to a problem?
In my opinion, this feature request is more related to potential security issues, and specifically how the Certificate Discovery algorithm works.
My understanding, by reading the source code, is that Certificate Discovery will give precedence to wildcard certificates with respect to matching, non-wildcard certificates. As an example, if a Kubernetes Ingress for host
foo.example.com
is created that does not say which certificate ARN to use, Certificate Discovery will be triggered. Let's say that two certificates exist in AWS ACM, a wildcard certificate for*.example.com
and a non-wildcard certificate forfoo.example.com
. The Certificate Discovery algorithm will select the wildcard certificate, as I understand by looking at the code [1]:Describe the solution you'd like
From a security point of view, selecting the wildcard certificate over another, non-wildcard one, that also matches the requested host is not ideal. This will leads to (ab)use of the wildcard certificate. In case it gets compromised, all ELBs that rely on it will also be compromised. Besides the risk, they will all need to get rotated, etc. I think this can be avoided by changing the Certificate Discovery algorithm to give precedence to non-wildcard certificates that match the TLS host.
To make the change to the algorithm more controllable, you can introduce some command-line flag gate to the AWS Load Balancer Controller that allows selecting the "old" behaviour (wildcard takes precedence) or the "new' behaviour (non-wildcard takes precedence). Hence, users of the AWS Load Balancer can select which behaviour they want, and to avoid unexpected breakages.
Describe alternatives you've considered
Unfortunately, there are no alternatives for us. Using the wildcard certificate works for us, but introduces undesired risk of having it compromised and exposing all data incoming through ELBs using this wildcard. Mostly because we also have Certificates in AWS ACM that match specifically all the TLS hosts that are involved here.
And we cannot remove the wildcard certificate, because we have also Ingress resources that are associated with an equilvalent DNS wildcard. However, for Ingress resources that have an specific TLS host, we would like to use the Certificate whose SN matches the TLS host, instead of relying on the wildcard certificate.
[1]
aws-load-balancer-controller/pkg/ingress/cert_discovery.go
Line 169 in 356c904
The text was updated successfully, but these errors were encountered: