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.
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 ?
Deployment Manager does this as well:
name: glb-gke-certificate
type: compute.beta.sslCertificate
properties:
type: MANAGED
managed:
domains: example.com
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?
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
...
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.
@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.
Most helpful comment
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 ?