Support for Google-managed SSL certificates

[ssmall]

Using the Google Cloud Console or gcloud, I can create a Google-managed SSL certificate. As far as I can tell, there is no way to do the same with a ComputeSSLCertificate. Am I misunderstanding the docs or has this support not yet been added?

[kibbles-n-bytes]

Hey @ssmall , we do not yet support for Google-managed SSL certs. Adding it to our tracker, and we'll let you know when we have an update on support.

[ssmall]

Following up on this, it looks like there is already a CRD for managed certificates: https://cloud.google.com/kubernetes-engine/docs/how-to/managed-certs#setting_up_the_managed_certificate

However, because it is not a ComputeSSLCertificate, it is not possible to reference it from other CNRM resources. And because the actual cert name is generated (it's not the same as metadata.name), referencing it statically is also not possible.

[AlexBulankou]

@ssmall , from which CNRM resource do you need to reference your Google-managed SSL certificate? Thanks.

[ssmall]

I am trying to reference it from a ComputeTargetHTTPSProxy

[travisrandolph-bestbuy]

@AlexBulankou Our team is also interested in being able to manage Google-managed certs through KCC. We'd want to reference it from a ComputeTargetHTTPSProxy, as well be able to create the cert through KCC.

[jcanseco]

Hi @travisrandolph-bestbuy, thanks, we'll note down that you've requested this resource as well. No updates yet, but we do have this in our backlog and we're keeping track of it.

[jcanseco]

@travisrandolph-bestbuy, note that it is possible to reference managed certs from ComputeTargetHTTPSProxy today. However, you can only do so using external. See the ComputeTargetHTTPSProxy example that this one helpful customer shared in this post.

[tonybenchsci]

Any update on if KCC will be able to do what Deployment Manager has been able to do with:

- name: glb-gke-certificate
  type: compute.beta.sslCertificate
  properties:
    type: MANAGED
    managed:
      domains:
      - hello.example.com

[snuggie12]

One caveat trying to use a GKE managed cert is that AFAICT you can only use the project of the k8s cluster. If I'm wrong, I'd love to hear how to do it.

Error when setting up the proxy:

    message: 'Update call failed: error applying desired state: summary: Error creating
      TargetHttpsProxy: googleapi: Error 400: Invalid value for field ''resource.sslCertificates[0]'':
      ''projects/<my_project>/global/sslCertificates/<cert_name>''.
      Cross project referencing is not allowed for this resource., invalid, detail: '

[maqiuyujoyce]

Hi @snuggie12 , thank you for your feedback! As it's not closely related to the original issue (a resource request), I filed #505 to follow up.

[snuggie12]

appreciate it @maqiuyujoyce.

I just wanted to stress the importance of getting this resource in kcc since the workaround doesn't work in all cases.

[mboveri]

Is there any follow up on this issue? We are also running into the same problem. Is it possible to just include the networking.gke.io/v1 ManagedCertificate kind in the config connector project and let it set the name of the certificate the same as the name of the resource?

[xiaobaitusi]

Hi folks,

Sorry that we don't have a good ETA yet for managed ssl certs, however we have recently revisited this topic and been evaluating some options.

I want to quickly run by one possible option to you here and see if that's acceptable for your use case.

Let's say we have ComputeManagedSSLCertificate as a separate CRD to create managed ssl certs similar to what terraform provides - compute_managed_ssl_certificate.

However, one can only reference to ComputeManagedSSLCertificate using 'sslCertificates[].external' field from ComputeTargetHTTPSProxy, at least to start with. We will look into adding native k8s reference following the multi-kind object reference convention in the long term.

Let us know if the proposal and limitation are acceptable from your perspective.

[mboveri]

The problem we have ran into with the proposed solution is that the Terraform cert can be named, but cannot create a wildcard certificate which has implications in how we intend to use GCLBs.

The apiVersion: networking.gke.io/v1 - kind: ManagedCertificate resource can be used to generate managed certs via helm; however, does not appear to have a means to name the cert. This means you get a UUID as the cert name and cannot easily reference this in the sslCertifcates[].external workflow.

If the apiVersion: networking.gke.io/v1 - kind: ManagedCertificate resource could create a named managed SSL certificate the way the terraform module can or the terraform module could create a wildcard cert I would agree that is an acceptable workaround.

[xiaobaitusi]

Hi @mboveri, thanks for your reply.

Can you clarify that if the networking.gke.io/v1 ManagedCertificate CRD is able to create wildcard certs? From the error message from the terraform resource, it seems that the underlying GCE API doesn't support the wildcard domains, terraform or ConfigConnector doesn't have much control as client-side tools.

Error: Error creating ManagedSslCertificate: googleapi: Error 400: Invalid value for field 'resource.managed.domains[0]': '*.example.com'. Wildcard domains not supported., invalid

One thing to clarify is that networking.gke.io/v1 ManagedCertificate per https://cloud.google.com/kubernetes-engine/docs/how-to/managed-certs is some feature owned by the gke-kubernetes-networking team, I'm in the loop with the support team, I'll ask them to route the request to the gke-kubernetes-networking team and see if they can add the support of user-specified names.

Just to ensure that I correctly understand your use case, you will need the support of wildcard certs even if using the proposed ComputeManagedSSLCertificate KCC CRD per namespace

[toumorokoshi]

Hello! Adding this resource is a blocker for #207, so want to cross-reference.

Speaking to the team there's a rather long backlog of resources, so we're looking at a highly tentative target of Q1.

For those who want to see priority raised: the best way to do so is probably working with your GCP partner to be able to communicate priorities and blockers privately.

[bluemalkin]

Any ETA on this please ? This would be super handy, thanks!

[jcanseco]

Hi @bluemalkin, unfortunately no we do not have an update on this. I recommend using something else to manage Google-managed SSL certificates for now since I do not believe we will be able to get to this any time soon.

[nstogner]

Plus one for this feature. Any technical reason this is not on the current roadmap?

[burningalchemist]

Hello and Happy New 2023 year! Any updates/ETA for this year? 🙂

[diviner524]

@burningalchemist We are exploring new ways to accelerate our resource coverage progress, and Google Managed SSL cert will be among the targeted resources. We may be able to share more details by end of Q1 2023.

[ajlopezn]

This resource is released in v1alpha1 version. This is not yet recommended for production use, but you can use it for testing and validate it fulfil your requirements. Any feedback will be welcome before graduating it to GA.

[npitts0811]

We are exploring this CRD, but seeing a consistent error message on our resources. For every managed certificate we create, the certs get created in GCP, but the Kubernetes resource always ends up in an 'UpdateFailed' state with the following error:

Update call failed: error applying desired state: summary: doesn''t support update

Acquisition has similar behavior. The resource still ends up in an 'UpdateFailed state with the same error as above. We were able to confirm acquisition worked by deleting the Kubernetes resource (which resulted in the GCP cert being deleted).

Given this is an alpha resource, I'm not sure if discussion should continue here or if I should open a new issue.

[justinsb]

We are exploring this CRD, but seeing a consistent error message on our resources. For every managed certificate we create, the certs get created in GCP, but the Kubernetes resource always ends up in an 'UpdateFailed' state with the following error:

Update call failed: error applying desired state: summary: doesn''t support update

Sorry about that, and thanks for reporting. I was able to reproduce the issue. The issue I saw was that the certificate_id was being changed (but I had to add logging to see this). It was being changed because of rounding problems - it's a large integer that seems to get truncated to 53 bits, I think because the field in the CRD is an int and not a string. It may actually also be a terraform bug, in that certificate_id may need to also be a string in terraform. Anyway, I am looking into that.

An easy workaround for me was to set:

  annotations:
    cnrm.cloud.google.com/state-into-spec: absent

In general, state-into-spec: absent avoids a bunch of the trickier cases that often leads to bugs. The only downside that I know of is that if you need to read a value generated by GCP, you can't get it from KRM. But we can add fields to status (particularly for alpha APIs) to make sure that any such values are surfaced.

Acquisition has similar behavior. The resource still ends up in an 'UpdateFailed state with the same error as above. We were able to confirm acquisition worked by deleting the Kubernetes resource (which resulted in the GCP cert being deleted).

I think that is consistent with what I saw.

Given this is an alpha resource, I'm not sure if discussion should continue here or if I should open a new issue.

I think this bug is likely specific to ComputeManagedSSLCertificate. I believe this github issue is also specific to ComputeManagedSSLCertificate, so this seems like the right place to me :-)

[npitts0811]

Hey @justinsb thanks for looking into this! The int vs string theory (ha) you mentioned seems sound; I've run into similar in the past.

I tried the suggested annotation in two ways, so following up with my observations:

The first one was recreating a certificate I have created and deleted a few times (i.e, previously used metadata.name and resourceID). For this one, I do see the resource status becoming UpToDate, however it seems to be temporary in that after about a minute the resource state becomes 'UpdateFailed' with the same error message I mentioned previously:

Update call failed: error applying desired state: summary: doesn''t support update

The other ComputeManagedSSLCertificate resource I created used a new metadata.name and resourceID (i.e., not previously used to my knowledge) and the resulting resource has been UpToDate for about 10 minutes now.

Just to verify- by using this annotation and not being able to get GCP values from KRM, does this ultimately mean we would not be able to use this workaround for acquiring existing certificates (only for net-new)?

Update:
the second ComputerManagedSSLCertificate just flipped to 'UpdateFailed' with the same error message after about 12 minutes. I think it was just waiting for me to submit my reply lol

[diviner524]

The fix for ComputeManagedSSLCertificate is expected to be released in v1.111.0. Tentative ETA is late Oct/early Nov.