[
https://issues.apache.org/jira/browse/FLINK-31966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17774130#comment-17774130
]
Tony Garrard commented on FLINK-31966:
--------------------------------------
Hi [~gyfora] , [~martijnvisser] I did some initial coding of a solution. I
modified the AbstractFlinkService's getClusterClient method so that it would
copy the relevent certs from the secret mount and place them into a defined
directory of /tmp/\{namespace}/\{clusterId} and override the config of the
cluster client to point to these files. This means that all the rest calls the
operator makes work well. However, I can't find a way of merging the config the
operator has and that of the flinkdeployment so they can interoperate and
currently when the operator runs either the submitApplicationCluster or
submitSessionCluster the operator emits a stacktrace complaining it can't find
the relevant file. However after a short time the application or session
cluster starts up fine and the status of the relevant flink cluster corrects
itself.
I currently can't see a way of getting the ssl config to work in the operator
and in the cluster unless the certs are placed in the same location. Do you
have any ideas ? My only thought would be to mount an emptydir in the operator
e.g /flink/certs and then document that the kubernetes.secret mount points be
defined on the CR so that they would be placed in a unique directory within
that folder
E.g
{{kubernetes.secrets: my-ssl-cert-secret:/flink/certs/\{clusterid}}}
{{security.ssl.rest.keystore: /flink/certs/\{clusterid}/keystore.jks}}
This way, the operator would be able to copy the certs from the secret and
place them in the same location defined in the config. Do you think this is an
acceptable approach ?
> 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)
