[jira] [Closed] (FLINK-40583) Filter operator keys on the remaining runtime config paths

["Gyula Fora (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/FLINK-40583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gyula Fora closed FLINK-40583.
------------------------------
    Fix Version/s: kubernetes-operator-1.17.0
       Resolution: Fixed

merged to main d407c02661ef245c523e2b4fa9e47bd843562e5f

> Filter operator keys on the remaining runtime config paths
> ----------------------------------------------------------
>
>                 Key: FLINK-40583
>                 URL: https://issues.apache.org/jira/browse/FLINK-40583
>             Project: Flink
>          Issue Type: Bug
>          Components: Kubernetes Operator
>            Reporter: Dennis-Mircea Ciupitu
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: kubernetes-operator-1.17.0
>
>
> As of now, the operator and autoscaler properties ({{{}kubernetes.operator.{}}} and {{{}job.autoscaler.{}}}) can be exchanged between the operator and the Flink cluster in both directions. FLINK-40380 closed one path, but yet 2 are still left.
>  - On the reading path, the operator reads a running job's config from three REST endpoints and merges them. FLINK-40380 added a filter that drops {{kubernetes.operator.}} and {{job.autoscaler.}} keys, but only on one of them, leaving the JobManager endpoint path uncovered.
>  - On the writing path, when a session job is submitted, the jar run request is built from the raw config, and the operator sends its own keys to the JobManager on every submit. Currently, Flink ignores them and never hands them back. Those properties can also hold sensitive information, such as {{{}kubernetes.operator.user.artifacts.http.header{}}}, which holds the header used to download job artifacts, so it is better not to send any of them.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)