Can not refer to managed cert in ComputeSSLCertificate

[jlpettersson]

Describe the bug

When creating a ComputeSSLCertificate there is no way to specify a domain-name so that I can get a manage certificate.

It is possible to declare a domain that should get a managed certificate in the REST documentation

  "managed": {
    "domains": [
      string
    ],
    "status": enum,
    "domainStatus": {
      object
    }
  },

and go to a shop to buy a domain name SSL certificate is unrealistic 5 years after LetsEncrypt.

ConfigConnector Version

1.9.2

To Reproduce Steps to reproduce the behavior:

YAML snippets:

apiVersion: compute.cnrm.cloud.google.com/v1beta1
kind: ComputeSSLCertificate
metadata:
  name: my-domain-cert
spec:
  location: global

It would be good to be able to refer to a DNSRecordSet or a DNSManagedZone CR.

[tonybenchsci]

Our company would like this as well. Relates to https://github.com/GoogleCloudPlatform/k8s-config-connector/issues/107 It seems like all the moving parts are there (managed certs CRD, and KCC ComputeSslCertificate) but missing some API glue; does that seem like a fair guess @kibbles-n-bytes ?

[tonybenchsci]

Deployment Manager does this as well:

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

[caieo]

Hi @jlpettersson and @tonybenchsci , we marked #107 as a "Resource request"/"Enhancement" but never fully updated the thread.

The reason we have yet to implement managed certs in ComputeSSLCertificate is because there is a separate resource for ComputeManagedSSLCertificates (I'm showing this TF resource because we rely on TF). We still are investigating whether we should merge the two resources or just implement the ComputeManagedSSLCertificate as a separate resource.

Just to get an understanding, can you explain if supporting managed certs is an important use-case to you?

[gorankarlic]

Any updates on config connector support for Google-managed SSL certificates?

Exporting via config-connector bulk-export --project my_project_id --on-error continue --output all.yaml right now creates the following invalid configuration:

apiVersion: compute.cnrm.cloud.google.com/v1beta1
kind: ComputeSSLCertificate
metadata:
  annotations:
    cnrm.cloud.google.com/project-id: my_project_id
  name: my_managed_ssl_cert
spec:
  location: global

But one can reference an external, existing, manually created, managed SSL certificate in aComputeTargetHTTPSProxy like this:

apiVersion: compute.cnrm.cloud.google.com/v1beta1
kind: ComputeTargetHTTPSProxy
metadata:
  annotations:
    cnrm.cloud.google.com/project-id: my_project_id
  name: my_target_https_proxy
spec:
  location: global
  quicOverride: NONE
  sslCertificates:
  - external: https://www.googleapis.com/compute/v1/projects/my_project_id/global/sslCertificates/my_managed_ssl_cert
...

[jcanseco]

Hi @gorankarlic, no updates yet on support for managed certs in general. We do have it in our backlog and we're continuing to keep track of it. We'll let you know when we have any updates.

[tedelwartowski-bestbuy]

@jcanseco - I am looking to understand where this in the backlog and if you have an ETA? This is actually a blocker for us at the moment, preventing us from full automating our application deployment stack.

[xiaobaitusi]

Hey @tedelwartowski-bestbuy, apologize for the late reply.

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 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 here.

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

To get a better understanding of the priority, can you provide some insights into the ordered priority of all bestbuy resource requests?

Thanks

[zsgilber]

@xiaobaitusi

My company has a use case for the managed SSL certificate that matches the scenario you outline. We want to create Cloud CDN load balancers via config-connector and right now we have to manually provision the managed SSL cert. If we could at least reference it from ComputeTargetHTTPSProxy as you proposed that should be sufficient for this use case. I hope the feedback is helpful!

[tedelwartowski-bestbuy]

@xiaobaitusi - I am going to have one of my engineers comment on your suggestion; thank you.

[travisrandolph-bestbuy]

Hey @tedelwartowski-bestbuy, apologize for the late reply.

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 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 here.

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

To get a better understanding of the priority, can you provide some insights into the ordered priority of all bestbuy resource requests?

Thanks

@xiaobaitusi I think this proposal works for us. This is pretty high on our list of priorities as we'd like to control the creation of the managed certs through KCC vs having teams create them through the GKE controller or manually.

[toumorokoshi]

@xiaobaitusi I think this proposal works for us. This is pretty high on our list of priorities as we'd like to control the creation of the managed certs through KCC vs having teams create them through the GKE controller or manually.

Thank you for the response! I spoke to @xiaobaitusi a little bit, and as a start we'll focus on getting the Managed SSL Certificate resource into KCC first. I'll update an ETA there.

[travisrandolph-bestbuy]

@toumorokoshi Any ETA on this?

[toumorokoshi]

Hi @travisrandolph-bestbuy,

We'll add this functionality once we add support for the Google-managed SSL certificate, which currently has an ETA of Q1.

I've confirmed internally that this is still the right expected date. Apologies it's a ways away, we're moving through a rather big backlog at the moment.

[zzorica]

any updates on support for managed certs?

[diviner524]

Hi @zzorica Managed certs is definitely an important resource request and we should be able to share some updates in Q1, 2023. Sorry the team has a long backlog and we cannot give a concrete date right now. Again please consider creating a GCP support ticket if possible, this will help us to better prioritize our investment of limited capacities.

[buker]

do you have any update in this topic. There is no way to automatically renew cert for internal load balancer because it can't be updated.

[diviner524]

Managed SSL certificate is supported as a v1alpha1(preview) CRD.

https://github.com/GoogleCloudPlatform/k8s-config-connector/blob/master/crds/compute_v1alpha1_computemanagedsslcertificate.yaml

Instructions on how to install the v1alpha1 CRDs.

https://cloud.google.com/config-connector/docs/how-to/install-alpha-crds