[JBoss JIRA] (TEIIDSB-92) Provide an openshfit example of a secure transport
by Ramesh Reddy (Jira)
[ https://issues.jboss.org/browse/TEIIDSB-92?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIIDSB-92:
-------------------------------------
(y)
> 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)
5 years, 7 months
[JBoss JIRA] (TEIIDSB-92) Provide an openshfit example of a secure transport
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIIDSB-92?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIIDSB-92:
---------------------------------------
> we can use whatever OpenShift tools to make sure it is done correct way, IMO no need to put in our own way of doing it for now.
The same annotation for serving certificates (although beta instead of alpha) for operators: https://github.com/openshift/service-ca-operator
However there's nothing built-in that will convert the service certificates to a java keystore. So we'd likely still want to use an initContainer with our operator based logic.
> 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)
5 years, 7 months
[JBoss JIRA] (TEIIDSB-92) Provide an openshfit example of a secure transport
by Ramesh Reddy (Jira)
[ https://issues.jboss.org/browse/TEIIDSB-92?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIIDSB-92:
-------------------------------------
Once we have the Operator going, we can use whatever OpenShift tools to make sure it is done correct way, IMO no need to put in our own way of doing it for now.
> 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)
5 years, 7 months
[JBoss JIRA] (TEIIDSB-92) Provide an openshfit example of a secure transport
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIIDSB-92?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIIDSB-92:
---------------------------------------
> The fastest way to fix is provide a patch, but it was little cryptic when I looked at it, did not get the support I was looking for in a timely manner
I see that a lot looking at their issues. If it's seen as a corner case it's likely to never get attention. It seems like this could be a big effort as I'd first have to figure out what's wrong at a baseline with 4.1.0 / latest, then fix anything related to initContainers. The alternatives are:
1. add keytool and openssl to our image and move the generation logic out of the initContainer. The advantage of the service signed certificates is that it's possible for openshift clients to trust them (for java it likely means another init container to create the truststore).
2. use the keytool-maven-plugin to generate a self-signed cert at build time, then wire that in as a secret. Of course this will rotate the private key on each build, so we'd just have to document using the trust all option for clients. Realistically this is not any better than anonymous ssl - but I could not make anonymous work on openshift for some reason, even with overriding the disabled cipher suites. Also we'd potentially have to know how to enable the anonymous cipher suite across a variety of pg clients - which could be more difficult than just trusting the self-signed certificate.
> 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)
5 years, 7 months
[JBoss JIRA] (TEIIDSB-92) Provide an openshfit example of a secure transport
by Ramesh Reddy (Jira)
[ https://issues.jboss.org/browse/TEIIDSB-92?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIIDSB-92:
-------------------------------------
The fastest way to fix is provide a patch, but it was little cryptic when I looked at it, did not get the support I was looking for in a timely manner :(
> 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)
5 years, 7 months
[JBoss JIRA] (TEIIDSB-92) Provide an openshfit example of a secure transport
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIIDSB-92?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIIDSB-92:
---------------------------------------
This is problematic in general. Backing out the initContainer changes we still fail with the same issues with 4.0.0 and 4.1.0.
> 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)
5 years, 7 months
[JBoss JIRA] (TEIIDSB-92) Provide an openshfit example of a secure transport
by Ramesh Reddy (Jira)
[ https://issues.jboss.org/browse/TEIIDSB-92?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIIDSB-92:
-------------------------------------
[~shawkins] I have not verified the fix afterward.
> 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)
5 years, 7 months
[JBoss JIRA] (TEIIDSB-92) Provide an openshfit example of a secure transport
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIIDSB-92?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIIDSB-92:
---------------------------------------
I tried adding an init container to the deploymentconfig.yml. However f-m-p does not handle init containers well. I checked across several versions:
3.5.41/42 - fails to deploy with: failed to update DeploymentConfig from openshift.yml. io.fabric8.kubernetes.client.KubernetesClientException: Failure executing: PUT at: https://192.168.42.57:8443/apis/apps.openshift.io/v1/namespaces/teiid-dat.... Message: DeploymentConfig.apps.openshift.io "rdbms-example"
4.0.0 - Fails earlier: Failed to execute goal io.fabric8:fabric8-maven-plugin:4.0.0:resource (build) on project rdbms-example: Execution build of goal io.fabric8:fabric8-maven-plugin:4.0.0:resource failed.: NullPointerException ...
4.1.0 - Deploys, but creates the wrong deployment config. Checking the console shows
!screenshot-1.png|thumbnail!
Note the extra spring-boot container. It also reports that it's failing to pull the image and fails to actually create pod.
The most similar bug reports are: https://github.com/fabric8io/fabric8-maven-plugin/issues/1114 and https://github.com/fabric8io/fabric8-maven-plugin/issues/1283 which seems to describe the 3.5.x behavior.
[~rareddy] did you ever get any closure on your issue?
> 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)
5 years, 7 months
[JBoss JIRA] (TEIIDSB-92) Provide an openshfit example of a secure transport
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIIDSB-92?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIIDSB-92:
----------------------------------
Attachment: screenshot-1.png
> 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)
5 years, 7 months
[JBoss JIRA] (TEIIDSB-93) Fix the travis build
by Steven Hawkins (Jira)
Steven Hawkins created TEIIDSB-93:
-------------------------------------
Summary: Fix the travis build
Key: TEIIDSB-93
URL: https://issues.jboss.org/browse/TEIIDSB-93
Project: Teiid Spring Boot
Issue Type: Quality Risk
Reporter: Steven Hawkins
Assignee: Steven Hawkins
It is unclear why the travis builds are not completing testing with a variety of travis changes (repeating steps, separating build from test, etc.) did not improve the situation. It appears to just hang on dependency downloading for no discernible reason.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months