[teiid-issues] [JBoss JIRA] (TEIIDSB-92) Provide an openshfit example of a secure transport

[Steven Hawkins (Jira)]

    [ https://issues.jboss.org/browse/TEIIDSB-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13735108#comment-13735108 ] 

Steven Hawkins commented on TEIIDSB-92:
---------------------------------------

[~rareddy] here is what this looks like: https://github.com/shawkins/teiid-openshift-examples/commit/3dba649fcbd57436db041924a68e511e802847fd

Before this is merged it would need to be targeted against the security example instead.

The basic idea is that we need a new svc.yml to define a secure transport.  It has to include the service.alpha.openshift.io/serving-cert-secret-name annotation.

Then in the deploymentconfig there is an initContainer to take the generated certificate and turn it into a keystore, a volume to share it, and additional env properties to enable the secure transport and provide the keystore.

This requires a later version of f-m-p - and it requires that the container name be spring-boot.  If it's named something else, them f-m-p creates an extra invalid container in the generated deployment.  I'll log something with f-m-p just so it's captured.

A minor complication with this approach (or with having a single Teiid ssl config) is when you have both services as secure - you end up with a single key/keystore as they both are given the same name.  It doesn't really matter which one, but if you care about what is presented as the host name it would be good to know.

> Provide an openshfit example of a secure transport
> --------------------------------------------------
>
>                 Key: TEIIDSB-92
>                 URL: https://issues.jboss.org/browse/TEIIDSB-92
>             Project: Teiid Spring Boot
>          Issue Type: Sub-task
>          Components: OpenShift
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Major
>         Attachments: screenshot-1.png
>
>
> Until we have kerberos support, usage of the pg transport will likely need to be secure to prevent plain-text username/password being sent unencrypted.
> It should also be a general option to enable secure transports from our ui.  External exposure is covered in TEIIDSB-86.
> We should use the private key from either based upon a self-signed certificate or using service signing certificates.  I'll provide an example demonstrating one of those approaches.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)