LuChengxiang created FLINK-41435:
------------------------------------
Summary: 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.3.0, 2.2.0, 2.1.0, 1.20.0, 2.4.0, 2.0.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
*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.
A second source of divergence is a security module that resets the process
login user to the simple OS user. In that case the refresh thread and the
security context can end up on different UGIs.
*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)
