[jira] [Commented] (FLINK-15174) FLINK security using PKI mutual auth needs certificate pinning or Private CA
[ https://issues.apache.org/jira/browse/FLINK-15174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17014222#comment-17014222 ] Stephan Ewen commented on FLINK-15174: -- [~knaufk] We can continue the discussion about whether there are other possible workarounds, but the patch as such works and is meaningful in my opinion, so I would close this issue. > 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)
[jira] [Commented] (FLINK-15174) FLINK security using PKI mutual auth needs certificate pinning or Private CA
[ https://issues.apache.org/jira/browse/FLINK-15174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17014220#comment-17014220 ] Stephan Ewen commented on FLINK-15174: -- The patch is merged in - 1.11.0 via 16eed2928bad97669e13ad521b2ca9fa5db3c582 and 69a727d1f9b6ef39ffb707f6d4ef46c534944ab5 - 1.10.0 via 83db7bc122e48248e8e66b816cbd3ed630878969 and 7ddd746b2b9d26c02826cc92c58ed9134f34bf0b > 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)
[jira] [Commented] (FLINK-15174) FLINK security using PKI mutual auth needs certificate pinning or Private CA
[ https://issues.apache.org/jira/browse/FLINK-15174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17014219#comment-17014219 ] Stephan Ewen commented on FLINK-15174: -- [~knaufk] I tried to describe that above: The limitation in the JDK implementation is that any non-self-signed certificate needs the issuing CA in the TrustStore, which would then cause also all other certificates by that CA to be trusted. Just having the certificate or even only having the purpose-dedicated intermediate CA would not work (validation would fail). > 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)
[jira] [Commented] (FLINK-15174) FLINK security using PKI mutual auth needs certificate pinning or Private CA
[ https://issues.apache.org/jira/browse/FLINK-15174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17014111#comment-17014111 ] Konstantin Knauf commented on FLINK-15174: -- [~dasbh] [~johnlon] I would like to understand your setups/constraints better. If the client certificates are directly signed by a firmwide root ca or even a public ca, this setups is indeed tricky. Have you considered asking for certificates, which are signed by an intermediate ca (trusted by the root ca), which is only used for this particular use case? The truststore would then only contain the intermediate ca. In your setups do you receive exactly one CA-signed key/certificate for all your taskmanagers, or one for each? In the former case, why not just putting just this certificate itself in the truststore instead of the firmwide CA, it should trust itself, right? Regarding your implementation: what would be the source for the fingerprints in case of the FingerprintTrustManagerFactory? Are you envisioning a Flink configuration for this? > 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)
[jira] [Commented] (FLINK-15174) FLINK security using PKI mutual auth needs certificate pinning or Private CA
[ https://issues.apache.org/jira/browse/FLINK-15174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17010492#comment-17010492 ] Stephan Ewen commented on FLINK-15174: -- [~dasbh] Thank you for confirming. Sounds like a strange restriction in the JDK (unless there is a deeper reason I am not immediately seeing). In that case, your proposal sounds like a good workaround. Will try to review/merge this soon. > 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)
[jira] [Commented] (FLINK-15174) FLINK security using PKI mutual auth needs certificate pinning or Private CA
[ https://issues.apache.org/jira/browse/FLINK-15174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17010030#comment-17010030 ] Bhagavan commented on FLINK-15174: -- The proposed setup is as you have noted. * KeyStore = specific certificate (shared secret) * TrustStore = internal CA * Certificate fingerprint = ensuring only that single specific certificate is accepted However, for internal communication one could use the same Keystore file as TrustStore Re: "it really not possible to set up a TrustStore with only a non-self-signed certificate" - correct. Tried that as the first step. JDK does not like this setup. Code throws NPE while validating as the issuer is null. So, It is not possible to have only the actual specific certificate in the TrustStore (and not have the CA in there). > 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)
[jira] [Commented] (FLINK-15174) FLINK security using PKI mutual auth needs certificate pinning or Private CA
[ 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)
[jira] [Commented] (FLINK-15174) FLINK security using PKI mutual auth needs certificate pinning or Private CA
[ https://issues.apache.org/jira/browse/FLINK-15174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17007567#comment-17007567 ] John Lonergan commented on FLINK-15174: --- Hi any update on this PR? Hoping to make use of it urgently. Happy new year folk. > 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)
[jira] [Commented] (FLINK-15174) FLINK security using PKI mutual auth needs certificate pinning or Private CA
[ https://issues.apache.org/jira/browse/FLINK-15174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16993432#comment-16993432 ] Till Rohrmann commented on FLINK-15174: --- Thanks for creating this issue [~dasbh]. I think you are right that this needs to be extended and the documentation to be corrected. Happy to review your PR. I've assigned this issue to you so that you can work on it. > 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)
[jira] [Commented] (FLINK-15174) FLINK security using PKI mutual auth needs certificate pinning or Private CA
[ https://issues.apache.org/jira/browse/FLINK-15174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16992502#comment-16992502 ] John Lonergan commented on FLINK-15174: --- 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", as we know that is MUST be self-signed in order to work as needed. However, the Ververica documentation for AppManager is much clearer on this point and states "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: Major > > 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)
