validate the presence of specified issuer or clusterisssuer in tlspolicy

[laurafitzgerald]

What

Closes #581

Verification
Follow https://docs.kuadrant.io/getting-started/
Follow https://docs.kuadrant.io/multicluster-gateway-controller/docs/how-to/multicluster-gateways-walkthrough/ until the creation of the TLSPolicy

Error should be reported in status for ClusterIssuer that doesn't exist in cluster

Create TLSPolicy pointing to ClusterIssuer with a name that doesn't exist in the cluster
Validate that error is present in the status of the TLSPolicy

 - lastTransitionTime: "2023-09-21T10:13:13Z"
      message: ClusterIssuer.cert-manager.io "blah" not found
      reason: ReconciliationError
      status: "False"
      type: Ready

Error should be reported in status for Issuer that doesn't exist in the namespace of the tlspolicy

Create an issuer in a namespace that is different to the TLSPolicy - steps here to do that https://github.com/Kuadrant/multicluster-gateway-controller/blob/main/docs/tlspolicy/tls-policy.md#lets-encrypt-issuer-for-route53-hosted-domain - update the namespace in the issuer in the steps to another namespace in the cluster

Validate that error is present in the status of the TLSPolicy

- lastTransitionTime: "2023-09-21T10:13:13Z"
      message: Issuer.cert-manager.io "le-staging" not found
      reason: ReconciliationError
      status: "False"
      type: Ready

Error should NOT be reported in status for Issuer that does exist in the same namespace as the tlspolicy

Create the same issuer but in the same namespace as the tlspolicy e.g. multi-cluster-gateways
Validate the status is good

    - lastTransitionTime: "2023-09-21T10:21:11Z"
      message: Gateway is TLS Enabled
      reason: GatewayTLSEnabled
      status: "True"
      type: Ready

Error should NOT be reported in status for ClusterIssuer that does exist in the same namespace as the tlspolicy

Update the policy to have a valid ClusterIssuer glbc
e.g.

issuerRef:
      group: cert-manager.io
      kind: ClusterIssuer
      name: glbc-ca

Validate the status is good

    - lastTransitionTime: "2023-09-21T10:21:11Z"
      message: Gateway is TLS Enabled
      reason: GatewayTLSEnabled
      status: "True"
      type: Ready

Error should NOT be reported in status for Issuer that does not specify kind

Update the policy to have the following issuerRef - create the issuer in the same namespace if needed
e.g.

issuerRef:
      group: cert-manager.io
      name: le-staging

Validate the status is good

    - lastTransitionTime: "2023-09-21T10:21:11Z"
      message: Gateway is TLS Enabled
      reason: GatewayTLSEnabled
      status: "True"
      type: Ready

[laurafitzgerald]

the e2e tests are passing locally for me. so i'm looking into that.

[mikenairn]

Couple of comments, but looks fine i think.

It did make me wonder if this is the best way to do this kind of thing, ideally we wouldn't be doing validation that is expected to be done by cert manager (the thing this policy is wrapping), but rather rely on aggregating the status of created cert manager resources (Certificates), or expected generated resources (CertificateRequests), since this would be a truer reflection of the state of the policy.

Example CertificateRequests status(cert manager 1.13.0), that we could get this info from:

kubectl get certificaterequests mn-hcpapps-net-tls-1 -n single-cluster-gateways -o json | jq '.status.conditions[] | select(.type == "Ready")'
{
  "lastTransitionTime": "2023-09-22T07:42:03Z",
  "message": "Referenced \"ClusterIssuer\" not found: clusterissuer.cert-manager.io \"glbc-caaaaa\" not found",
  "reason": "Pending",
  "status": "False",
  "type": "Ready"
}

Since we aren't going to do that aggregation now, and will likely be done in line with the proposed kuadrant policy status/conditions, a basic check like this is probably fine to avoid unnecessary confusion in the meantime.

[mikenairn]

/lgtm
/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: laurafitzgerald, mikenairn

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 [mikenairn]

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