## Summary Octavia uses a [two-way TLS authentication with certificates](https://docs.openstack.org/octavia/latest/admin/guides/certificates.html) between its load balancer instances (Amphora VMs) and its control plane services (Health Manger, Worker etc.). Currently, YAOOK only provides a [sample script at `tools/create_octavia_certs.sh`](https://gitlab.com/yaook/operator/-/blob/5f99090ca0a7bf6bfc4df82fff59121596daec8d/tools/create_octavia_certs.sh) that builds a local CA and produces the necessary keys and certificates to be pushed as static Kubernetes Secrets. The current process is described in [this handbook chapter](https://docs.yaook.cloud/user/guides/octavia-operator.html#preparing-the-tls-certificates). YAOOK should get rid of the need for building a local CA and pushing Kubernetes secrets manually. Instead, the necessary key and certificate handling should be automated using cert-manager. ### Use cases The current approach establishes a local CA and sets certificate expiration lifetimes not suited for production. Furthermore, no rotation is implemented or documented. A cloud operator does not want to manage a local CA (incl. CA root key storage and backup) and desires a fully automated process with production-ready defaults for certificate expiration and rotation. ## Proposal - adjust the YAOOK Octavia operator to use cert-manager resources to generate the necessary keys and certificates - add support for rotation of expiring certificates - remove `tools/create_octavia_certs.sh` - remove the handbook chapter about manual script execution and Kubernetes Secret registration - add a short note about the certificate automation to the handbook ## Specification The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this issue are to be interpreted *in the spirit of* [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119), even though we're not technically doing protocol design. <!-- Bullet-point list of MUST, SHOULD, MAY, SHOULD NOT and MUST NOT. will be added as a result of the proposal discussion process. -->