May 2019 - teiid-issues - Jboss List Archives

[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: --------------------------------------- [~rareddy] here is what this looks like: https://github.com/shawkins/teiid-openshift-examples/commit/3dba649fcbd57... 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)

7 years

1
0
0 / 0

[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)

7 years

1
0
0 / 0

[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)

7 years

1
0
0 / 0

[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)

7 years

1
0
0 / 0

[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)

7 years

1
0
0 / 0

[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)

7 years

1
0
0 / 0

[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)

7 years

1
0
0 / 0

[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)

7 years

1
0
0 / 0

[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)

7 years

1
0
0 / 0

[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)

7 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues May 2019