[jira] [Commented] (FLINK-31966) Flink Kubernetes operator lacks TLS support

["Adrian Vasiliu (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FLINK-31966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17718031#comment-17718031 ] 

Adrian Vasiliu commented on FLINK-31966:
----------------------------------------

[~MartijnVisser] Referring to your changes of the issue type and priority:
* We opened the issue with type = bug, not "new feature", because the operator breaks when configuring Flink with TLS, and there is no indication in the documentation that this is not supported.
* Priority = critical was our take because not being able to secure the Flink deployment is perceived as critical for enterprise deployments.

> Flink Kubernetes operator lacks TLS support 
> --------------------------------------------
>
>                 Key: FLINK-31966
>                 URL: https://issues.apache.org/jira/browse/FLINK-31966
>             Project: Flink
>          Issue Type: New Feature
>          Components: Kubernetes Operator
>    Affects Versions: kubernetes-operator-1.4.0
>            Reporter: Adrian Vasiliu
>            Priority: Major
>
> *Summary*
> The Flink Kubernetes operator lacks support inside the FlinkDeployment operand for configuring Flink with TLS (both one-way and mutual) for the internal communication between jobmanagers and taskmanagers, and for the external REST endpoint. Although a workaround exists to configure the job and task managers, this breaks the operator and renders it unable to reconcile.
> *Additional information*
>  * The Apache Flink operator supports passing through custom flink configuration to be applied to job and task managers.
>  * If you supply SSL-based properties, the operator can no longer speak to the deployed job manager. The operator is reading the flink conf and using it to create a connection to the job manager REST endpoint, but it uses the truststore file paths within flink-conf.yaml, which are unresolvable from the operator. This leaves the operator hanging in a pending state as it cannot complete a reconcile.
> *Proposal*
> Our proposal is to make changes to the operator code. A simple change exists that would be enough to enable anonymous SSL at the REST endpoint, but more invasive changes would be required to enable full mTLS throughout.
> The simple change to enable anonymous SSL would be for the operator to parse flink-conf and podTemplate to identify the Kubernetes resource that contains the certificate from the job manager keystore and use it inside the operator’s trust store.
> In the case of mutual TLS, further changes are required: the operator would need to generate a certificate signed by the same issuing authority as the job manager’s certificates and then use it in a keystore when challenged by that job manager. We propose that the operator becomes responsible for making CertificateSigningRequests to generate certificates for job manager, task manager and operator. The operator can then coordinate deploying the job and task managers with the correct flink-conf and volume mounts. This would also work for anonymous SSL.



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