[
https://issues.apache.org/jira/browse/FLINK-15174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephan Ewen closed FLINK-15174.
--------------------------------
> 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.10.0, 1.11.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)
