Skip to content

feat(tls): substrate-aware CharmState SAN/CN accessors (2/4)#173

Draft
marceloneppel wants to merge 1 commit into
tls-1-statefrom
tls-2-state-accessors
Draft

feat(tls): substrate-aware CharmState SAN/CN accessors (2/4)#173
marceloneppel wants to merge 1 commit into
tls-1-statefrom
tls-2-state-accessors

Conversation

@marceloneppel

Copy link
Copy Markdown
Member

Part 2/4, stacked on tls-1-state. Adds the substrate-aware CharmState accessors that compose the peer/workload primitives from part 1 into the cert-request SANs and common names.

What's here (core/state.py)

  • client_addresses / peer_addresses, client_common_name / peer_common_name (VM host-derived; K8s endpoints-FQDN parity with the >64-char wildcard rule), K8s common_hosts (Service FQDNs), and the CharmBase-widening so CharmState accepts any charm.

These accessors read the part-1 peer/databag primitives; the part-3 events handler feeds them into the TLSCertificatesRequiresV4 certificate requests. ~249 lines. Draft — not ready for review.

(Recreated from the closed #166 after a branch rename; identical commit.)

Layer the certificate-SAN and common-name policy onto CharmState, on top of the raw peer-databag accessors from the previous branch, so the substrate-specific certificate identity is reviewable as a unit with its own tests before any manager or handler consumes it.

K8s must regain the parity the migration had dropped: common_hosts has to advertise the primary/replicas Service FQDNs and the resolved pod FQDN, and the operator-cert common name has to be the endpoints FQDN (wildcarded past the 64-char CN limit) rather than the VM-style host/address; the peer SAN set must exclude the ip key the original K8s charm never emitted. VM behaviour is left host/address-derived as before. The CharmState charm parameter is also widened to ops.CharmBase so the state object no longer depends on the concrete charm type.

These accessors are additive and only read state, so the existing charm keeps constructing unchanged.

Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant