Configure certificates subject

[gulecroc]

Motivation

Currently only certificates subject organizations is configurable.

This PR allow to configure full subject properties.

Modifications

Move tls.common.organization to tls.common.subject.organizations.

Fail if tls.common.organization is still used.

Verifying this change

• Make sure that the change passes the CI checks.

[lhotari]

This looks good. I verified locally that the default render is byte-identical to master, the subject block maps correctly onto cert-manager's X509Subject, an empty subject renders nothing rather than subject: null, and values.yaml carries no organization remnant that could trip the guard spuriously.

Render recipe I used, if useful:

helm dependency build charts/pulsar
helm template test charts/pulsar --set "tls.enabled=true,tls.broker.enabled=true,\
tls.proxy.enabled=true,tls.zookeeper.enabled=true,tls.bookie.enabled=true,\
certs.internal_issuer.enabled=true,components.proxy=true" -s templates/tls-certs-internal.yaml

I initially wanted to push back on two things and talked myself out of both — see the inline notes.

One request before merge: document the migration

The diff touches only _certs.tpl and values.yaml. The README's upgrade procedure explicitly says helm get values … > values.yaml and reuse it, which is exactly the path that now aborts. There's good precedent to follow: the "Upgrading to Helm chart version 4.1.0" section covers the structurally identical auth.authentication.provider removal.

Could you add a README "Upgrading to Helm chart version 4.8.0" section showing the before/after:

# before
tls:
  common:
    organization:
      - pulsar
# after
tls:
  common:
    subject:
      organizations:
        - pulsar

Approving so this isn't blocked on me — please land the docs before merging.

Note

#713 also edits _certs.tpl. git merge-tree shows no textual conflict at the current heads, but whichever lands second should be rebased and re-rendered.

_{Reviewed with Codex gpt-5.6-sol and Claude Opus 5; every finding reproduced locally by rendering the chart.}

[lhotari]

I wanted to argue for a deprecation period here, then convinced myself the hard fail is right.

Without it, an existing tls.common.organization: [acme] would be silently dropped while the new default subject.organizations: [pulsar] survives Helm's merge — quietly changing the issued certificate's O with no signal. Failing loudly is the safer trade.

It's also consistent with how the chart already handles removed values (auth.authentication.provider, and cert-manager.io/v1beta1 a few lines above this one).

On placement: I checked whether the guard being inside pulsar.cert.template makes it unreachable when no Certificate renders — it does (with tls.enabled: false the legacy key is silently ignored). But that's fine: in that state the value is genuinely inert, and enabling certificates later produces an immediate, actionable error. No change needed.

[lhotari]

Could you list the other supported X509Subject fields here as comments? Right now organizations is the only one discoverable, so users won't know the rest exist:

    subject:
      organizations:
        - pulsar
      # countries: []
      # organizationalUnits: []
      # localities: []
      # provinces: []
      # streetAddresses: []
      # postalCodes: []
      # serialNumber: ""

Worth doing because the block is a toYaml passthrough and the chart has no values.schema.json — so a typo like subject.organization (singular) gets pruned by the Certificate CRD's structural schema and issues a cert with no O.