Share single certificate between units in HA deployment

[alexdlukens]

Enhancement Proposal

Currently the haproxy-operator charm uses the TLSCertificateRequiresV4 in UNIT mode:

haproxy-operator/haproxy-operator/src/charm.py

Lines 128 to 138 in 120f97f

	self.certificates = TLSCertificatesRequiresV4(
	charm=self,
	relationship_name=TLS_CERT_RELATION,
	certificate_requests=self._get_certificate_requests(),
	refresh_events=[
	self.on.config_changed,
	self.haproxy_route_provider.on.data_available,
	self.haproxy_route_provider.on.data_removed,
	],
	mode=Mode.UNIT,
	)

This means that in HA deployments, a separate certificate is requested for each unit. Let's Encrypt only permits a maximum of 5 certificates to be requested for a given domain across 168h. This means if there is there is an error with the initial certificate issuing, users must potentially wait several days before requesting a new cert.

We have regularly seen this issue in production use with PS7 ingress environments.

This feature request is to request using mode.APP for TLSCertificateRequiresV4 and sharing the single certificate to other units in the HA deployment.

[syncronize-issues-to-jira]

Thank you for reporting your feedback to us!

The internal ticket has been created: https://warthogs.atlassian.net/browse/ISD-5156.

This message was autogenerated

[Thanhphan1147]

The issue here is that we don't have a reliable way to know if we're in HA mode with keepalived which is one of the charm that we support in our terraform module. The first thing that I can think of is looking at juju-info and see if there's charm related on the other side, but keepalived can be deployed with a different name and I'm not sure if we can get information about the charm from the juju-info relation. We can also inspect the machine of haproxy units to detect the presence of keepalived but that'll run into false-positives if somehow keepalived is manually installed on the haproxy unit.

I guess the easiest way would be to use APP mode regardless of the deployment situation but I'll need to investigate further since we potentially need to make code changes to propagate the certificate AND the private key from the leader unit to the peer units via the peers relation.

[alexdlukens]

@Thanhphan1147 I agree that the best would be to use APP mode regardless.

To your point of we potentially need to make code changes to propagate the certificate AND the private key from the leader unit:

The private key for the tls certificates interface is automatically stored in an application juju secret (since: canonical/charmlibs#267). It will be picked up by the leader unit during leadership changes without any charm-specific code.

But indeed code-changes would be needed for sharing certs + their private keys between the units. I have an implementation of that here: https://github.com/canonical/tls-certificates-sink/blob/master/src/peer_data.py that could be used as inspiration