feat: enable certificates relation on istio-pilot

[DnPlas]

Enabling the certificates relation enables the integration with tls-certificates-operator and other charms that provide CA certificates. These CA certificates are used by istio-pilot to configure TLS on the ingress Gateway resource.
In the past this was done exclusively via charm configuration, which is now removed in favour of CA certificates provided through the certificates relation.

Manual testing

1. Deploy the following:

juju deploy istio-gateway istio-ingressgateway --trust --config kind=ingress --channel latest/edge
juju deploy self-signed-certificates --channel edge

2. In parallel, build istio-pilot from this PR's branch
3. Deploy istio-pilot and relate

juju deploy ./istio-pilot*.charm --trust
juju relate istio-pilot istio-ingressgateway
juju relate istio-pilot:certificates self-signed-certificates:certificates

5. Get the Gateway (kubectl get Gateway <name of default-gateway> -n<namespace> -oyaml) and Secret (secret name should be -gateway-secret) to see the certificate in place. The Gateway should show this:

    port:
      name: https
      number: 8443
      protocol: HTTPS
    tls:
      mode: SIMPLE

The Secret should have a cert and key in a long encoded string.

7. Additionally you can curl the ingressgateway (curl -v IP.nio.io usually) to see TLS in action

TODO:

• Increase test coverage
• Fix linting issues
• Provide manual testing instructions

[DnPlas]

CI failures should be fixed by #341

[kimwnasptd]

What if a user accidentally sets the ingressgateway's Service to be nodeport, instead of loadbalancer?

[NohaIhab]

thanks @DnPlas
left small comments and I think a good addition would be an integration test that deploys self-signed-certificates or any example provider, and makes sure to reach the ingressgateway with TLS.

[DnPlas]

What if a user accidentally sets the ingressgateway's Service to be nodeport, instead of loadbalancer?

Well, the istio-pilot charm is smart enough to handle these scenarios through the _get_gateway_service method. Is there anything that worries you?

[orfeas-k]

Tried the manual testing steps and confirm the following output

*   Trying 10.64.140.43:443...
* Connected to 10.64.140.43.nip.io (10.64.140.43) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS header, Unknown (21):
* TLSv1.3 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

[DnPlas]

Tried the manual testing steps and confirm the following output

*   Trying 10.64.140.43:443...
* Connected to 10.64.140.43.nip.io (10.64.140.43) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS header, Unknown (21):
* TLSv1.3 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Thanks for confirming, ultimately, since this is a self signed certificate, it has to be loaded to your local trusted certificate location for your OS so that curl can establish the connection, but at least we see the TLS handshake, which helps us visualise the attempt.

[NohaIhab]

Changes LGTM, but the CI seems flaky. Let's merge once CI passes.