URL support for https

[greg-pendlebury]

[kind/Feature]

Which functionality do you think we should add?

I would like to be able to generate https URLs using the URL command:
odo url create local-greg --port 8443 --tls=edge

Perhaps a new parameter like --tls=edge would result in adding this to the OCP route:

  tls:
    insecureEdgeTerminationPolicy: Redirect
    termination: edge

This is the simple use case we are looking for, but no doubt there are others:

• --tls=none (default)
• --tls=passthrough
• --tls=reencrypt

I have no personal experience with the last two... perhaps that are too complicated to support, but edge at least seems trivial.

Why is this needed?

Our microservice security layer and keycloak can be sensitive to users not using https for traffic/logins. At the moment I am forced to manually modify the TLS config for the route inside the OCP console after performing odo push.

[kadel]

/kind feature
/priority medium

[girishramnani]

to create a secured route other then these two parameters. We need to have 3 more values present in the route struct

 key: |-                      
      -----BEGIN PRIVATE KEY-----
      [...]
      -----END PRIVATE KEY-----
    certificate: |-              
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
    caCertificate: |-            
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----

The key, certificate and caCertificate.

[girishramnani]

We can provide these certificates and key as flags e.g. --key. And these flags will be location to a file which odo will read and populate the respective attribute

[greg-pendlebury]

Just in case there is concern over complexity here, I think it is worth mentioning that if the cluster is already installed to correctly manage SSL on your behalf (as ours is... assuming we stay within the scope of the SSL domains) then we don't provide any of the certificate information from the client side. Cluster admins have already done it all.

So my feedback was truly about the extremely simple use case where three lines fixes everything. I acknowledge a complete and all encompassing solution would be more complicated.

[girishramnani]

So my feedback was truly about the extremely simple use case where three lines fixes everything.

completely understandable but we need to consider all possible scenarios including the ones where the cluster doesn't have already installed SSL and even allowing the insecureEdgeTerminationPolicy to be set to something other then Redirect ( Allow or None) 🙂

[mik-dass]

@kadel @girishramnani We can have flags for passing the values of insecureEdgeTerminationPolicy, termination so that they can set to something else according to the user's requirement

[girishramnani]

we need to consider kuberenetes here as well.

[mik-dass]

@kadel @girishramnani We can start small and just have --secure flag which will create a HTTPs supported route with default configurations. Later if there is a need, we can add the ability for the user to customize the configurations of the route.

[vandepol]

+1 on this. Was just about to open issue on this and found it.
With OCP coming across the simple case where just need to passthrough flag set, however this can't be done on the odo create url command line.

In addition would like this available in the devfile.yaml
see open issue in devfile on eclipse che...
eclipse-che/che#14622 (comment)

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

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

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

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

/lifecycle rotten
/remove-lifecycle stale

[scottkurz]

Interested in this. Not sure if I have authority to do this but am going to try :)

/remove-lifecycle rotten

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

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

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

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

/lifecycle rotten
/remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

[openshift-ci-robot]

@openshift-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[kevprice83]

I would love to see this added as well. Creating routes with tls options is a standard workflow in my team but currently to configure passthrough we have to go and modify the route after that fact. Reverting to oc in the meantime makes the process easier until odo supports this.

/reopen

[openshift-ci]

@kevprice83: Reopened this issue.

In response to this:

I would love to see this added as well. Creating routes with tls options is a standard workflow in my team but currently to configure passthrough we have to go and modify the route after that fact. Reverting to oc in the meantime makes the process easier until odo supports this.

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[dharmit]

Two concerns w.r.t taking this further:

• it might not be doable for ingress (kubernetes) even if it can be done for routes (OCP)
• this might need support on devfile schema first before adding to odo.

[kadel]

• it might not be doable for ingress (kubernetes) even if it can be done for routes (OCP)

Why wouldn't this be doable for Kubernetes?

• this might need support on devfile schema first before adding to odo.

What would be the extra information that needs to be defined in Devfile?

[yamaszone]

Any update on this? This would be a great feature to allow developers develop securely using a cluster.

[kadel]

This is already possible in odo with devfile.yaml.
Basically you can define your own custom ingress and put it into devfile.yaml as a kubernetes component.

components:
  - name: myroute
    kubernetes:
      inlined: |
        apiVersion: route.openshift.io/v1
        kind: Route
        metadata:
          name: myroute
        spec:
          port:
            targetPort: 8080
          tls:
            insecureEdgeTerminationPolicy: Redirect
            termination: edge
          to:
            kind: Service
            name: frontend

I'm not sure if it makes sense for odo to expose all possible Route/Ingress configuration options on the CLI.

[kadel]

odo v3 uses port-forwarding for exposing the applications, https in this case doesn't make much sense (traffic between odo and cluster is already https).

If users need custom Route or Ingress with https they have an option to define it inside the devfile as kubernetes component

/close

[openshift-ci]

@kadel: Closing this issue.

In response to this:

odo v3 uses port-forwarding for exposing the applications, https in this case doesn't make much sense (traffic between odo and cluster is already https).

If users need custom Route or Ingress with https they have an option to define it inside the devfile as kubernetes component

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.