[
https://issues.apache.org/jira/browse/FLINK-15174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17010016#comment-17010016
]
Stephan Ewen commented on FLINK-15174:
--------------------------------------
Thanks for filing this. Just to clarify, let me rephrase this:
* If you cannot use self-signed certificates, then the TrustStore needs to
contain the CA that issued that certificate, otherwise the certificate would
not be trusted.
* It is not possible to have only the actual specific certificate in the
TrustStore (and not have the CA in there) to signal "trust that certificate
directly" so that the TrustManager would not try and validating up the chain of
signers to a trusted root. (This is different from the original assumption).
* A soon as a CA is in the TrustStore, any certificate from that CA gets you
access.
So the setup you are proposing is:
* KeyStore = specific certificate (shared secret)
* TrustStore = internal CA
* Certificate fingerprint = ensuring only that single specific certificate is
accepted
I think that makes sense to have this mode in any case.
Just to be sure, and to make the docs accurate, can we double-check that it
really not possible to set up a TrustStore with only a non-self-signed
certificate (omitting the CA) so that the TrustManager trusts that single
certificate directly and no other? (I can try and find some tome to do that in
the next days, unless someone is quicker).
> FLINK security using PKI mutual auth needs certificate pinning or Private CA
> ----------------------------------------------------------------------------
>
> Key: FLINK-15174
> URL: https://issues.apache.org/jira/browse/FLINK-15174
> Project: Flink
> Issue Type: Improvement
> Components: Runtime / Configuration, Runtime / REST
> Affects Versions: 1.9.0, 1.9.1, 1.10.0
> Reporter: Bhagavan
> Assignee: Bhagavan
> Priority: Critical
> Labels: pull-request-available
> Fix For: 1.9.2, 1.10.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The current design for Flink security for internal/REST relies on PKI mutual
> authentication. However, the design is not robust if CA used for generating
> certificates are public CA or Firwide internal CA. This is due to how the
> chain of trust works whilst validating the client certificate. i.e. Any
> certificate signed by same CA would be able to make a connection to internal
> Flink network.
> Proposed improvement.
> An environment where operators are constrained to use firmwide Internal
> public CA, Allow the operator to specify the certificate fingerprint to
> further protect the cluster allowing only specific certificate.
> This change should be a backward compatible change where one can use just
> certificate with private CA.
> Changes are easy to implement as all network communications are done using
> netty and netty provides FingerprintTrustManagerFactory.
> Happy to send PR if we agree on the change.
> Document corrections.
> From security documentation.
> [https://ci.apache.org/projects/flink/flink-docs-stable/ops/security-ssl.html]
> _"All internal connections are SSL authenticated and encrypted. The
> connections use *mutual authentication*, meaning both server and client-side
> of each connection need to present the certificate to each other. The
> certificate acts effectively as a shared secret."_
> _-_ This not exactly true. Any party who obtains the client certificate from
> CA would be able to form the connection even though the certificate
> public/private keys are different. So it's not *a* shared secret ( merely a
> common signature)
> _Further doc says - "A common setup is to generate a dedicated certificate
> (maybe self-signed) for a Flink deployment._
> - I think this is the only way to make the cluster secure. i.e. create
> private CA just for the cluster.
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
