[
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:36 PM:
------------------------------------------------------------------
I agree that this problem is a blocker for Flink's use in corporate env's where
self-signing is prohibited.
-
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. The
addition of this optional whitelisted fingerprint is transparent and backwards
compatible and makes the product usable in a wider variety of deployment
environments (especially restrictive corporate envs).
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-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. The
addition of this optional whitelisted fingerprint is transparent and backwards
compatible and makes the product usable in a wider variety of deployment
environments (especially restrictive corporate envs).
> 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)
