Support custom certificates for route about hawtio-operator HOT 12 CLOSED

It should be free to define another Route along with the default one.

If, when you patch the default Route, the changes are reverted by reconcilation loop, then we could change the operator and let it ignore the changes so that such patching is allowed by users as a short-term solution. In the long term, I agree there should be a way to specify a custom certificate for the Route created in the Hawtio CRD.

from hawtio-operator.

Thanks for the quick response. I tried creating another Route, that points to the same service, but getting this error from https://oauth-openshift.apps.mycluster.com when I try to use it:
{"error":"invalid_request","error_description":"The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed.","state":"https://my-fuse-console.mycluster.com/online/"}

This is on OpenShift4 and I assume the OAuthClient (?) created only works with the hostname of the route created by operator. Obviously I can't create my custom Route with the same hostname as it's used already. So it seems that oauth only works for the route created by the operator and that can't be patched or disabled. Is there a workaround for this error?
(Hawt.io is deployed "type: Namespace")

from hawtio-operator.

Hi,

Probably it's because you use the same spec.host value for the Route. You should be able to create another Route with a different host URL.

from hawtio-operator.

Hi @tadayosi , Thanks for looking into this.
We have a hostname like fuse-console.mycluster.com for the Route by the operator, set in routeHostName and we create another Route manually with host my-fuse-console.mycluster.com, so they have a different hostname. The manually created Route drops that error.
The Fuse Console operator creates - and the Fuse Console Pod uses - an OAuth client and I think that only works if the user is coming the hostname set in routeHostName.

from hawtio-operator.

Hi @bszeti, yes you're right. My bad.

For the namespace type deployment, actually a service account is created and used as an OAuth client by the console and it requires a set of annotations regarding OAuth redirect.
https://docs.openshift.com/container-platform/4.10/authentication/using-service-accounts-as-oauth-client.html

However, I double-checked with the code and the service account is managed by the operator reconcilation loop so users aren't allowed to manually modify it.

So in conclusion there is no way other than patching the operator. Sorry for guiding a wrong solution!

from hawtio-operator.

Thanks for the confirmation. We're kinda stuck then, I'll think what else we can do in short terms...

from hawtio-operator.

In the short term, you might be able to directly deploy hawtio-online instead of using the hawtio operator:
https://github.com/hawtio/hawtio-online
This way, you are free to patch the deployed Route to customise it further.

from hawtio-operator.

I will look into this.

from hawtio-operator.

@bszeti Hi,
So please clarify, what's the goal here? Being able to change hostname or rather use custom certificates. (I assume the 2)

from hawtio-operator.

@mmelko Changing the route hostname is already possible via "routeHostname" field. The problem is using custom certificates for TLS in environments where the default cluster level wildcard certificate is not allowed by company policy.

from hawtio-operator.

@bszeti Thanks.

To use another route is necessary to annotate service account to do proper redirect (as @tadayosi mentioned above)):

oc annotate sa fuse-console serviceaccounts.openshift.io/oauth-redirectreference.newroute='{"kind":"OAuthRedirectReference","apiVersion":"v1","reference":{"kind":"Route","name":"new-route"}}'

However after reconciling hawtio this change will be probably deleted. The operator does reconcile service account but doesn't watch it so it will be changed until something else will trigger the reconcile loop.

I can see two options here:

• Add a new parameter in hawtio CRD something like routeLists and Service account will be properly annotated with new route(s)
• adding TLS parameter with the certificate secret and instead of autogenerated certificate by Openshift , service would use provided one and Route would change TLS termination to passthrough

Or I can (and probably will)do both :) what would you prefer ?

from hawtio-operator.

Yes, that's exactly what we do now in our pipelines: we start the operator, wait for deployment, stop the operator, patch the SA. Kinda complicated...
I like the idea of an optional field like "routeTLSSecret" that should contain the key/cert/storepassword and it's added to the Route/Ingress by the operator.

from hawtio-operator.