[
https://issues.apache.org/jira/browse/FLINK-15174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16992502#comment-16992502
]
John Lonergan edited comment on FLINK-15174 at 12/10/19 12:32 PM:
------------------------------------------------------------------
I agree.
As it stands the certs can only act as a "shared secret" if +self-signing+ is
being done.
The opensource Flink documentation is misleading where is says "may be
self-signed", however, as we now know it MUST be self-signed in order to work
as needed - self-signing is not optional.
By contrst, the Ververica documentation for AppManager is more accurate on this
point and states the need for "self-signed" all over the docs as a requirement;
and in fact their AppManager component actually generates self-signed certs.
In organisations where self-signing is prohibited (for whatever reason) then
the Flink security implementation is unworkable and Flink cannot be used - so
the proposed solution makes a lot of sense.
The proposed solution removes the need for the certs to be self signed by using
a whitelisted fingerprint, and it does this in optional and transparent and
backwards compatible manner.
was (Author: johnlon):
I agree.
As it stands the certs can only act as a "shared secret" if +self-signing+ is
being done.
The opensource Flink documentation is misleading where is says "may be
self-signed", however, as we now know it MUST be self-signed in order to work
as needed - self-signing is not optional.
By contrst, the Ververica documentation for AppManager is more accurate on this
point and states the need for "self-sighed" all over the docs as a requirement;
and in fact their AppManager component actually generates self-signed certs.
In organisations where self-signing is prohibited (for whatever reason) then
the Flink security implementation is unworkable and Flink cannot be used - so
the proposed solution makes a lot of sense.
The proposed solution removes the need for the certs to be self signed by using
a whitelisted fingerprint, and it does this in optional and transparent and
backwards compatible manner.
> 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
> Reporter: Bhagavan
> Priority: Blocker
>
> 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)
