SSL certificate name non-unique when namespace + ingress name too long

[anuraaga]

I recently ran into an issue where due to a combination of somewhat long namespace + ingress name, a GCE load balancer was created for each of two ingresses with very similar name

k8s-um-abcdefghijklmn-abcde-prod-abcdefghijklmn-admin-server-p0
k8s-um-abcdefghijklmn-abcde-prod-abcdefghijklmn-admin-server-q0

and the SSL certificate configured for both had the same name

k8s-ssl-abcdefghijklmn-abcde-prod-abcdefghijklmn-admin-server-0

While it seems GCP allows this, other ingress-aware components, in my case cert-manager, can get confused and the issue I saw was the SSL certificate being bounced between the two load balancers. As cert-manager presumably has no idea what the GCP load balancer name / SSL cert name is for an ingress, I guess the issue is in the ingress controller. Either it should correctly operate ingresses of different names which happen to have the same name of load balancer / SSL cert, or ingresses should be rejected if they would result in too long a name to be unique.

[G-Harmon]

A colleague and I were just discussing this yesterday, as a hypothetical issue. I see it's no longer hypothetical.

[nicksardo]

Yes, this has come up several times in discussions. Unfortunately, there's currently no plan to migrate to a better naming scheme.

[anuraaga]

Migrating sounds pretty tough but how about handling the error better?

1. Throw an error when creating an ingress where a backing resource would cause a duplicate. Though not sure if ingress controllers are able to intercept the ingress API request itself.

2. Don't remove the SSL certificate when the same name resource exists on a load balancer already. I have a feeling this may just be tweaking usage of the GCP API.

The behavior I saw is the certificate of an already existing load balancer was removed from it and added to the new one, and then it began bouncing back and forth. As the service uses HSTS, this meant it was completely unavailable during periods where it didn't have the certificate. Luckily this wasn't a user facing service, but it could potentially cause a severe production outage from an innocent looking ingress addition so handling it a little better seems important.

[nikhiljindal]

Yes, this has come up several times in discussions. Unfortunately, there's currently no plan to migrate to a better naming scheme.

Do we have an agreed upon new naming scheme that fixes the problem, so that we can use it for new resources?

[rramkumar1]

This issue should be fixed in v1.1.1. We migrated to a new naming scheme for certs which eliminates the issue of truncation when the name is too long (see #200). Closing for now, but please reopen if you still have issues.
/close