ingress-gce
ingress-gce copied to clipboard
GCP certificate-manager support?
When will GCE ingress support certificates generated by certificate-manager? The certificates have a separate path, and don't seem to work if you specify them in the annotation ingress.gcp.kubernetes.io/pre-shared-cert
(https://cloud.google.com/kubernetes-engine/docs/how-to/load-balance-ingress#ingress_annotations).
Hi @thequailman
I had a call with GCP support today, it's not supported and they GKE team has an internal discussion about how to support this feature.
Hi @thequailman,
Thanks for your question. Cloud Certificate Manager will natively be supported using the Gateway API in GKE. Current support with Ingress is K8s secret, Self-managed certs, or Google-managed certs.
Thanks, Pierre-Louis
Hi @plgingembre,
Thanks for your clarification! So, you mean that there is no plan for Ingress to attach certificates generated by Certificate Manager, right?
+1 for getting this on gce ingress.
Currently it seems to be working when setting the certificate map manually on the https target proxy.
But maybe this will stop working once cert-manager is not beta.
According to [1] Certificate Manager now reached GA status.
Is it really not possible to use it with the GKE offering ?!?
[1] https://cloud.google.com/certificate-manager/docs/release-notes
I would also be interested by this feature!
We'd also be interested in this feature. Considering that Gateway is in Preview state right now and it doesn't support cdn/iap which Ingress supports: https://cloud.google.com/kubernetes-engine/docs/how-to/gatewayclass-capabilities
I am in the same position.
I have a need to assign hundreds of SSL certificates to a GKE ingress but am capped by the 15 limit via the ingress object. We are running on a premium network tier and a global load balancer behind Cloud CDN and Cloud Armor, but seemingly have no way of having GKE and certificate manager talk to each other, and as mentioned by the post previously gateway api does not support CDN or Armor.
As mentioned by @hjorth, setting the certificate map manually on the target https proxy seems to be working. But I had to attach a dummy ManagedCertificate
on the ingress (the domain name can be anything), to force GCP to provision an HTTPS proxy. Not sure if there's a simpler way
I attached a certificate-map to the target https proxy of my GKE ingress, and this took down my site (browsers were no longer able to connect to existing k8s certs). I've reported this to GCP via the support channel, but would advice caution to others going down this route.
I attached a certificate-map to the target https proxy of my GKE ingress, and this took down my site (browsers were no longer able to connect to existing k8s certs).
The minute you activate certificate-map - the existing certificates are no longer used.
You need to have all your certificates provisioned in certificate-manager and map entres as well.
It might take a few minutes before the Google managed certificates is generated and provisioned. But its much faster than Managed Certificates.
Note: even though I got it working with a single cluster ingress, attaching a certificate map manually to the target https proxy of a multi cluster ingress does not seem to work. The certificate map does not seem to be used at all, and the target https proxy configuration gets reverted automatically after a while.
Sharing what I learnt after reached out to Google Cloud Support about the matter of having a service that supports both cert manager + CDN + Armor:
They told me that there was no support for this setup at the moment but that it will come with the eventual GA of the Gateway API, but there is no fixed timeline for when that might be expected to arrive, other than after the first half of 2023.
An internal feature request was already raised and a public tracker issue was created here: https://issuetracker.google.com/issues/263437663
@markrandall thanks for following up with support. Still, disappointing. Ultimately, I'd just like the DNSAuth/ACME support that certificate manager product brings.
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/stale
is applied - After 30d of inactivity since
lifecycle/stale
was applied,lifecycle/rotten
is applied - After 30d of inactivity since
lifecycle/rotten
was 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
/remove-lifecycle stale
Is there any progress on this? ingress-gce does not seem to be able to solve some basic fuction, and wants us all to use Gateway API https://github.com/kubernetes/ingress-gce/issues/109
As mentioned earlier in https://github.com/kubernetes/ingress-gce/issues/1692#issuecomment-1133470810, we do not plan to add support for Certificate Manager in Ingress. The Gateway API does currently have an integration with certificate manager: https://cloud.google.com/kubernetes-engine/docs/how-to/secure-gateway#secure-using-certificate-manager
As someone coming from AWS (where you have alb.ingress.kubernetes.io/certificate-arn
annotation), this seems like a very basic functionality since most community helm charts support ingress and ingress annotation configurations, so having this workaround to use a Gateway API doesn't seem like an optimal solution.
I would appreciate if you could give it a second thought, having an annotation to specify the certificate from the Certificate Manager which will just attach it directly to the balancer.
Until you're a client with a very big bill and an enterprise support, they don't give a shit so it's useless to attempt communicate them.
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/stale
is applied - After 30d of inactivity since
lifecycle/stale
was applied,lifecycle/rotten
is applied - After 30d of inactivity since
lifecycle/rotten
was 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/stale
is applied - After 30d of inactivity since
lifecycle/stale
was applied,lifecycle/rotten
is applied - After 30d of inactivity since
lifecycle/rotten
was 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
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
- After 90d of inactivity,
lifecycle/stale
is applied - After 30d of inactivity since
lifecycle/stale
was applied,lifecycle/rotten
is applied - After 30d of inactivity since
lifecycle/rotten
was applied, the issue is closed
You can:
- Reopen this issue with
/reopen
- Mark this issue as fresh with
/remove-lifecycle rotten
- Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
In response to this:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
- After 90d of inactivity,
lifecycle/stale
is applied- After 30d of inactivity since
lifecycle/stale
was applied,lifecycle/rotten
is applied- After 30d of inactivity since
lifecycle/rotten
was applied, the issue is closedYou can:
- Reopen this issue with
/reopen
- Mark this issue as fresh with
/remove-lifecycle rotten
- Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.