Initialize Cert-manager and Gateway API workflow

[lonelyCZ]

Fixes #25

The result resources are below:

[root@master68 cm-gateway]# kubectl get clusterissuer,issuer,gatewayclass,gateway,secret -n gateway-demo
NAME                                              READY   AGE
clusterissuer.cert-manager.io/selfsigned-issuer   True    4m57s

NAME                                    READY   AGE
issuer.cert-manager.io/gateway-issuer   True    4m53s

NAME                                              CONTROLLER                                 ACCEPTED   AGE
gatewayclass.gateway.networking.k8s.io/cmsolver   projectcontour.io/projectcontour/contour   True       4m45s

NAME                                         CLASS      ADDRESS   READY   AGE
gateway.gateway.networking.k8s.io/cmsolver   cmsolver             True    4m43s

NAME                          TYPE                                  DATA   AGE
secret/cmsolver-gateway-tls   kubernetes.io/tls                     3      4m42s
secret/default-token-skftd    kubernetes.io/service-account-token   3      5m1s
secret/selfsigned-ca-tls      kubernetes.io/tls                     3      4m55s

[lonelyCZ]

/assign @irbekrm

[irbekrm]

Thanks @lonelyCZ I think this is great work and good practices like using variables and parameterizing values instead of hardcoding - well done 👍🏼 👍🏼

I have left a bunch of suggestions- let me know what you think. I will try out this feature on GKE once it is possible to use an ACME issuer with LetsEncrypt - I left a comment for that, let me know what you think!

Again- well done 👏🏼

[irbekrm]

I've tried to use the resources deployed in this PR together with an HTTPRoute, Service and a Deployment similar to https://raw.githubusercontent.com/projectcontour/contour/v1.22.0/examples/example-workload/gatewayapi/kuard/kuard.yaml on GKE with the Gateway exposed on a public IP- after a few modification all worked as expected and I saw that Gateway controller uses the newly provisioned cert from selfsigned-ca:

irbe@testing-addons$ curl -kivL -H 'Host: <my-hostname>'  <my-dns-name>
*   Trying 34.89.11.176:443...
* Connected to <my-dns-name> (<my-ip>) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
...
* Server certificate:
*  subject: [NONE]
*  start date: Aug  9 11:33:05 2022 GMT
*  expire date: Nov  7 11:33:05 2022 GMT
*  issuer: CN=selfsigned-ca
...

I think we want to make the envoy service type configurable to allow accessing it from outside if needed. This might be easier to do if we are able to use the Helm chart

[lonelyCZ]

Thanks for your tests! I will fix these comments ASAP.

I think we want to make the envoy service type configurable to allow accessing it from outside if needed. This might be easier to do if we are able to use the Helm chart

Indeed, but the Helm chart doesn't seem to work very well for gateway. What should we do?

[irbekrm]

Indeed, but the Helm chart doesn't seem to work very well for gateway. What should we do?

I only looked at this very briefly- I do see that it does not work out of the box (it does not pick up the GatewayClass that we deploy). I think the reason for this is that we don't have the Configmap with these options deployed by default with the Helm chart. I see that it is possible to configure it with the Helm chart via this param.

I haven't actually tried it, but I believe it should work, I see that support for Gateway API was added to this chart in bitnami/charts#9029

but it seems not to support Gateway Provisioner

I think we don't need the Gateway Provisioner, it belongs to the 'dynamic' Contour configuration, but we use static https://projectcontour.io/guides/gateway-api/

I think we should try to set the missing configmap values.

Let me know what you think- I can look at this some more tomorrow as well

[lonelyCZ]

Indeed, but the Helm chart doesn't seem to work very well for gateway. What should we do?

I only looked at this very briefly- I do see that it does not work out of the box (it does not pick up the GatewayClass that we deploy). I think the reason for this is that we don't have the Configmap with these options deployed by default with the Helm chart. I see that it is possible to configure it with the Helm chart via this param.

I haven't actually tried it, but I believe it should work, I see that support for Gateway API was added to this chart in bitnami/charts#9029

but it seems not to support Gateway Provisioner

I think we don't need the Gateway Provisioner, it belongs to the 'dynamic' Contour configuration, but we use static https://projectcontour.io/guides/gateway-api/

I think we should try to set the missing configmap values.

Let me know what you think- I can look at this some more tomorrow as well

Thanks for your guidences, I found it can work fine after configurating the gateway rbac.

[lonelyCZ]

I haven't actually tried it, but I believe it should work, I see that support for Gateway API was added to this chart in bitnami/charts#9029

Althought bitnami/charts#9029 has been merged, but the latest version of the chart hasn't released, how should we do?

It is not this problem, I continue to research it.

time="2022-08-11T07:22:14Z" level=info msg="pkg/mod/k8s.io/client-go@v0.24.2/tools/cache/reflector.go:167: failed to list *v1alpha2.ReferenceGrant: referencegrants.gateway.networking.k8s.io is forbidden: User "system:serviceaccount:projectcontour:bitnami-contour-contour" cannot list resource "referencegrants" in API group "gateway.networking.k8s.io" at the cluster scope\n" caller="reflector.go:324" context=kubernetes

It seemingly lacks referencegrants resource rbac at chart rbac. I have opened a issue.

[lonelyCZ]

/assign @irbekrm

[lonelyCZ]

/cc @irbekrm

[lonelyCZ]

/cc @irbekrm

[irbekrm]

Thanks for this great work!

I've ran the latest version of the PR locally and saw the certs get created successfully 👍🏼

It would be awesome if we can also do #33 then we'll be able to test this with and actual e2e flow easier, but let me know if you think there will be issues with testing the ACME issuer.

/lgtm

[irbekrm]

/approve

[jetstack-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: irbekrm, lonelyCZ

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [irbekrm]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment