[
https://issues.apache.org/jira/browse/FLINK-41435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated FLINK-41435:
-----------------------------------
Labels: pull-request-available (was: )
> SecurityUtils.install should be idempotent for equivalent security
> configurations
> ---------------------------------------------------------------------------------
>
> Key: FLINK-41435
> URL: https://issues.apache.org/jira/browse/FLINK-41435
> Project: Flink
> Issue Type: Bug
> Components: Runtime / Configuration
> Affects Versions: 2.0.0, 1.20.0, 2.1.0, 2.2.0, 2.3.0, 2.4.0
> Environment: Flink 1.20.x and 2.0 through 2.4 (including master)
> Kubernetes Application Mode with Kerberos and HDFS delegation tokens.
> Reporter: LuChengxiang
> Priority: Major
> Labels: pull-request-available
>
> *Background*
> In application mode, Flink installs the security context twice:
> * KubernetesApplicationClusterEntrypoint and
> StandaloneApplicationClusterEntryPoint call
> ClusterEntrypoint.installSecurityContext() before fetching user artifacts.
> * ClusterEntrypoint.startCluster() calls installSecurityContext() again.
> Each call creates a new SecurityConfiguration and runs the security modules
> and context factory again. With Kerberos this performs another login and can
> replace the process login UGI.
> Components created under the first UGI, for example Hadoop clients used while
> fetching artifacts, then remain bound to a UGI that no longer receives
> refreshed delegation tokens. Token refresh can silently stop; the job later
> fails with errors such as SecretManager$InvalidToken or an expired HDFS
> delegation token.
> *How it is triggered*
> The two configurations are not identical.
> ApplicationClusterEntryPoint.configureExecution() adds pipeline.jars,
> pipeline.classpaths and execution.target between the two install calls, so a
> plain Configuration equality check cannot be used to skip the second install.
> *Root cause*
> SecurityUtils.install() unconditionally runs the security modules and creates
> a new security context. It does not remember the last successfully installed
> configuration, so an equivalent configuration is treated as a real
> re-installation.
> *Proposed change*
> * Give SecurityConfiguration value semantics for the options consumed by the
> bundled security modules: security.*, zookeeper.sasl.*, flink.hadoop.*,
> fs.hdfs.* and io.tmp.dirs. Include the configured security context and module
> factories.
> * Remember the last successfully installed SecurityConfiguration in
> SecurityUtils.
> * Make SecurityUtils.install() synchronized and return early when the new
> configuration equals the installed one.
> * Clear the remembered configuration in SecurityUtils.uninstall().
> * Do not reinstall because of unrelated runtime options such as
> pipeline.jars, pipeline.classpaths or execution.target.
> *Scope*
> This issue only covers idempotent installation. Delegation token
> receiver/provider target-UGI handling, module rollback and file-system
> cleanup during token acquisition are out of scope.
> *Testing*
> * Install an equal configuration after adding pipeline options: modules and
> context must be unchanged.
> * Change a security-relevant option: modules and context must be reinstalled.
> * Install after uninstall: a new context/modules must be installed.
> * Security-relevant prefixes affect equality; unrelated options do not.
> *Acceptance criteria*
> * Repeated install() with an equivalent security configuration keeps the
> existing context and modules.
> * A different security-relevant configuration still installs a new context
> and modules.
> * uninstall() clears the stored installation state.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
