CryoThrust commented on issue #12766: URL: https://github.com/apache/seatunnel/issues/12766#issuecomment-6415810316
Thanks for confirming the distribution and the gap. I'd like to take this on. I rechecked the issue timeline and open PR search and found no linked/competing Hudi Kerberos fix. Proposed first-PR contract: 1. Add `use.kerberos` (default `false`), `kerberos.principal` and `kerberos.principal.file` to the sink and catalog option rules. Require both nonblank credential options only when enabled; the file must be readable in each process that initializes the catalog or writer. Keep the current path unchanged when disabled. 2. Create a runtime authentication context for each catalog/writer instance. Use a returned UGI (`loginUserFromKeytabAndReturnUGI`), not `loginUserFromKeytab`/`setLoginUser`. Establish it before catalog filesystem access and before either the direct provider or cached multi-table manager constructs a Hudi client. The UGI itself must not be serialized with job configuration or cached across unrelated jobs. 3. Run connector-owned catalog/client operations under that context, including initialization, write/delete, commit and close. Check keytab relogin before authenticated operations and keep clients scoped to their owning context. I will also trace Hudi's executor/background paths; wrapping only the top-level write is insufficient if work escapes to an existing pool. 4. Treat Hadoop's JVM-wide security-mode initialization as a separate constraint: per-UGI login does not make `UGI.setConfiguration` job-local. My preference is to require a consistently Kerberos-configured worker and fail clearly on an incompatible initialized mode, rather than switch the mode for each job. This would require Hadoop security configuration at worker startup, but not an external worker keytab login. Is that deployment prerequisite acceptable here? 5. Cover conditional options, non-Kerberos behavior, catalog and both writer creation paths, identity handoff, renewal failure and cleanup with credential-free tests. Document a real-KDC verification recipe and distinguish it from unit coverage; no keytab will be committed. Authentication diagnostics must not print principals, keytab paths or credentials, including through exception causes. I will keep this to one PR once the option/security-mode contract is settled. The remaining question above is about safe shared-worker behavior, not whether loading XML performs a keytab login—it does not. -- 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]
