[
https://issues.apache.org/jira/browse/FLINK-31966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17764117#comment-17764117
]
Tony Garrard commented on FLINK-31966:
--------------------------------------
Hi [~gyfora] I think I can take this on, but can I discuss the approach before
I start working on it.
Most users will be placing their certificates into kubernetes secrets (either
by using cert-manager or creating them manually). We should be able to link the
kubernetes.secrets property to the path used in the security.ssl sections to
find the secret used for the rest service. The operator will need to create
those stores locally onto it's disk (probably into /tmp). Then the relevant
config when creating the rest client needs to be modified to point to the
location we've created those files. The locations I've identified that will
need modifications to the flink config appear to be in AbstractFlinkService's
getClusterClient. Though there is another section in submitClusterInternal
where it is using the default
ClusterClientFactory where we would also somehow need to make changes.
Do you think this is the right approach and have a missed any other place where
the config would need to be changed ?
> 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)
