[teiid-issues] [JBoss JIRA] (TEIIDSB-86) Plans for secure socket transports

[ https://issues.jboss.org/browse/TEIIDSB-86?page=com.atlassian.jira.plugin... ] Steven Hawkins edited comment on TEIIDSB-86 at 5/14/19 12:44 PM: ----------------------------------------------------------------- an sni passthrough route works as expected, with the caveat that using anonymous ssl seems problematic. Using a static security.setproperty to update the disabled did not work - it does work in the same spring boot app locally. That's something we can look at later. This is where things stand without utilizing a stunnel: ||Secure Transport Options||Teiid JDBC||PG|| |End-to-end (internal and external) - Need to allow ssl configuration with either a user-provided cert or a generated one|passthrough route or loadbalancer for external|loadbalancer for external| |Secure External and Clear Internal - Same as above for external - need to allow ssl configuration with either a user-provided cert or a generated one|Would require separate transports|Would require separate transports or an update to the logic requiring a secure connection based upon internal vs. external traffic| |Clear|loadbalancer for external|loadbalancer for external| Based upon all of this we should probably offer the following: * clear transports (current), or 1-way secure transports using the service generated certificate (I'll validate that this works as expected) * optional external exposure with a loadbalancer, which works for both transports with or without ssl. It could be documented how to utilize a router for secure jdbc as well. Two-way authentication and user supplied certs could be considered later. Going the stunnel route looks like: ||Secure Transport Options||Teiid JDBC||PG|| |End-to-end (internal and external) - Need to allow ssl configuration with either a self-signed or a generated one|stunnel for external, internal clients (other pods) need to be configured with an appropriate truststore|same as jdbc, with the caveat that pg would effectively be double encrypted unless more logic were added about when to secure| |Secure External and Clear Internal|stunnel for external|stunnel for external| |Clear|loadbalancer for external|loadbalancer for external| was (Author: shawkins): an sni passthrough route works as expected, with the caveat that using anonymous ssl seems problematic. Using a static security.setproperty to update the disabled did not work - it does work in the same spring boot app locally. That's something we can look at later. This is where things stand: ||Secure Transport Options||Teiid JDBC||PG|| |End-to-end (internal and external) - Need to allow ssl configuration with either a user-provided cert or a generated one|passthrough route or loadbalancer for external|loadbalancer for external| |Secure External and Clear Internal - Same as above for external - need to allow ssl configuration with either a user-provided cert or a generated one|Would require separate transports|Would require separate transports or an update to the logic requiring a secure connection based upon internal vs. external traffic| |Clear|loadbalancer for external|loadbalancer for external| Based upon all of this we should probably offer the following: * clear transports (current), or 1-way secure transports using the service generated certificate (I'll validate that this works as expected) * optional external exposure with a loadbalancer, which works for both transports with or without ssl. It could be documented how to utilize a router for secure jdbc as well. Two-way authentication and user supplied certs could be considered later. -- This message was sent by Atlassian Jira (v7.12.1#712002)