https-endpoint with tls-termination passtrough on openshift

[wgbeckmann]

Hi,
I have in my devfile an endpoint, that servs a https application.
So I defined the following in my devfile:

...
  - mountSources: true
    type: dockerimage
    image: 'airhacks/payara'
    alias: payara
    endpoints:
      - name: root
        port: 8080
      - name: payara-console
        port: 4848
        attributes:
           protocol: https
           secure: 'false'
           public: 'true'
           discoverable: 'true'
...

But Openshift creates a normal http-route.
When I configure the generatet openshift route manualy to secure and TLS-termination to passtrough it works. But I want to configure it via the devfile.

So, how do I do it?

If you want to test it:
Here is the complete devfile:

metadata:
  name: java-vue
components:
  - id: redhat/java/latest
    type: chePlugin
  - mountSources: true
    memoryLimit: 512Mi
    type: dockerimage
    volumes:
      - name: m2
        containerPath: /home/user/.m2
    image: 'quay.io/eclipse/che-java11-maven:nightly'
    alias: maven
    env:
      - value: /home/user/.m2
        name: MAVEN_CONFIG
      - value: >-
          -XX:MaxRAMPercentage=50 -XX:+UseParallelGC -XX:MinHeapFreeRatio=10
          -XX:MaxHeapFreeRatio=20 -XX:GCTimeRatio=4
          -XX:AdaptiveSizePolicyWeight=90 -Dsun.zip.disableMemoryMapping=true
          -Xms20m -Djava.security.egd=file:/dev/./urandom -Duser.home=/home/user
        name: MAVEN_OPTS
      - value: >-
          -XX:MaxRAMPercentage=50 -XX:+UseParallelGC -XX:MinHeapFreeRatio=10
          -XX:MaxHeapFreeRatio=20 -XX:GCTimeRatio=4
          -XX:AdaptiveSizePolicyWeight=90 -Dsun.zip.disableMemoryMapping=true
          -Xms20m -Djava.security.egd=file:/dev/./urandom
        name: JAVA_OPTS
      - value: >-
          -XX:MaxRAMPercentage=50 -XX:+UseParallelGC -XX:MinHeapFreeRatio=10
          -XX:MaxHeapFreeRatio=20 -XX:GCTimeRatio=4
          -XX:AdaptiveSizePolicyWeight=90 -Dsun.zip.disableMemoryMapping=true
          -Xms20m -Djava.security.egd=file:/dev/./urandom
        name: JAVA_TOOL_OPTIONS
  - mountSources: true
    type: dockerimage
    image: 'centos/postgresql-10-centos7'
    alias: pgsqldb
    env:
      - value: admin
        name: POSTGRESQL_USER
      - value: admin
        name: POSTGRESQL_PASSWORD
      - value: devdb
        name: POSTGRESQL_DATABASE
      - value: admin
        name: POSTGRESQL_ADMIN_PASSWORD
    command:
      - run-postgresql
  - mountSources: true
    type: dockerimage
    image: 'airhacks/payara'
    alias: payara
    endpoints:
      - name: root
        port: 8080
      - name: payara-console
        port: 4848
        attributes:
           protocol: https
           secure: 'false'
           public: 'true'
           discoverable: 'true'           
apiVersion: 1.0.0

After you start the workspace you have to configure the payara. (not yet automated)
Start a new terminal in the payara user-runtime and:

sh-4.2$ asadmin --host localhost --port 4848 change-admin-password
Enter admin user name [default: admin]>
Enter the admin password> 
Enter the new admin password> admin
Enter the new admin password again> admin
Command change-admin-password executed successfully.
sh-4.2$ asadmin --host localhost --port 4848 enable-secure-admin
Enter admin user name>  admin
Enter admin password for user "admin">  admin
You must restart all running servers for the change in secure admin to take effect.
Command enable-secure-admin executed successfully.
sh-4.2$ asadmin --host localhost --port 4848 restart-domain
Successfully restarted the domain
Command restart-domain executed successfully.

After this you edit the generated route directly in openshift as described above.

[rhopp]

@skabashnyuk This seems like a bug, right?

[skabashnyuk]

@wgbeckmann I think that the situation (che on http but some endpoints on https) that you've described was never considered as "working". The only suggestion that I have is to enable TLS for the whole Che environment https://github.com/eclipse/che/blob/master/assembly/assembly-wsmaster-war/src/main/webapp/WEB-INF/classes/che/che.properties#L558

[wgbeckmann]

@skabashnyuk: Ok, but what does that mean in concrete for a server if I set the attribut in a tls enabled environment to http, would openshift`s router automaticaly remove the https encryption?
And what happens when a sevice itselfs serves https? Do Openshift uses passthrough or reencryption and how do I influence it?
The docu says:

protocol: For public endpoints the protocol is a hint to the UI on how to construct the URL for the endpoint access. Typical values are http, https, ws, wss.
(Doku)

That sounds for me: Your traffic is only tunneld and not mainpulated.
But that is not possible in openshift. So perhaps there are more attribute parameters needet for configuring the endpoints right.

[skabashnyuk]

Ok, but what does that mean in concrete for a server if I set the attribut in a tls enabled environment to http

That means that che server will override this property and set https instead of http. Opposite situation afaik never tested/checked.

And what happens when a sevice itselfs serves https? Do Openshift uses passthrough or reencryption and how do I influence it?

I would say in "production" scenario we should always enable TLS

[wgbeckmann]

@skabashnyuk: Before I change everything. Again the question: What happens when a sevice itselfs serves https? Do Openshift uses passthrough or reencryption?
Just because. if I want to use Payara, I must configure the server to expose tls. Otherwise I cannot use the admin-console of payara. So openshift must create a passthrough route.

[skabashnyuk]

What happens when a sevice itselfs serves https? Do Openshift uses passthrough or reencryption?

@wgbeckmann I don't know.
@davidfestal @sleshchenko any idea about that?

[vandepol]

Is there any update on this? I'm trying to use odo with devfiles and it's creating application route as tls termination: edge. Manually creating route with tls termination passthrough works fine, but like @wgbeckmann I'd like to configure this through the devfile.

Thanks

[sleshchenko]

@davidfestal @l0rd Is it something at least addressed in the Devfile 2.0 Spec?

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.