PavelZeger opened a new pull request, #26021: URL: https://github.com/apache/pulsar/pull/26021
PIP: #484 ### Motivation Pulsar's built-in TLS auth provider (`AuthenticationProviderTls`, in `pulsar-broker-common`) derives a client's role only from the certificate's first Common Name (CN), and the extraction is hardcoded; if the CN is empty or missing, authentication fails outright. That is a poor fit for two increasingly common deployments: - **Enterprise PKI**, where identity lives in another DN field (an `OU`, `emailAddress`, or the full DN) and re-issuing certificates just to populate the CN isn't practical. - **SPIFFE/SPIRE and service meshes**, where workload identity is a URI SAN (`spiffe://...`) and the CN is intentionally empty — those certificates are rejected today even though they carry a valid, cryptographically-bound identity. Apache Kafka solves this declaratively with `ssl.principal.mapping.rules` (KIP-371). Pulsar has no equivalent for its built-in provider, and writing a custom `AuthenticationProvider` is a high bar for what should be a few lines of config. ### Modifications This PR adds the **PIP-484 design document** (`pip/pip-484.md`) for community discussion and vote. **It contains no code changes.** The proposal describes two backward-compatible config options for `AuthenticationProviderTls`: - `tlsCertIdentitySource` — choose the raw identity: `CN` (default), `DN`, or `SAN:URI|DNS|EMAIL`. - `tlsAuthPrincipalMappingRules` — an ordered list of Kafka-style `RULE:`/`DEFAULT` mapping rules. With both unset, behavior is identical to today (first CN, fail on empty CN). The document also covers the proxy config plumbing, new auth-failure error codes, security considerations, and upgrade/rollback compatibility. ### Verifying this change - [x] Make sure that the change passes the CI checks. This change is a trivial rework / code cleanup without any test coverage. > Documentation only: this PR adds the PIP-484 proposal markdown file and contains > no production code. Implementation (with tests) will follow in separate PRs that > reference this PIP, after the proposal is accepted. ### Does this pull request potentially affect one of the following parts: - [ ] Dependencies (add or upgrade a dependency) - [ ] The public API - [ ] The schema - [ ] The default values of configurations - [ ] The threading model - [ ] The binary protocol - [ ] The REST endpoints - [ ] The admin CLI options - [ ] The metrics - [ ] Anything that affects deployment -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
